Scope of Processing in Living Mode

Bottom line: We collect only what is required to operate your fiduciary plan.

Aftera processes identity data, account metadata, vault objects, and execution preferences for the purpose of delivering living audit, notary assistance, and fiduciary planning services. Identity data can include legal name, verified identifiers, jurisdiction metadata, and trust-assurance signals. Account metadata can include institution labels, account categories, and event timestamps. Vault objects can include documents and user-authored instructions. We intentionally separate these classes so access controls can be applied with the precision expected in high-trust systems. We split storage across countries so one legal order cannot expose everything.

We process only what is necessary for declared functions. For example, living audit workflows require transaction descriptors and account classification metadata, but they do not require unrestricted ingestion of unrelated communications. Privacy boundaries are enforced at ingestion, where data minimization, category tagging, and encryption envelope assignment occur before downstream processing. This reduces risk and supports user expectations that a trust platform should collect intentionally rather than opportunistically. In plain English: We process only what is necessary for declared functions.

Users can review and update planning preferences throughout living mode. Preferences include heir permissions, data disclosure scopes, delete-on-death directives, and notification sequencing. These preferences are recorded as policy artifacts and bound to the execution manifest. The binding prevents informal override during high-stress transitions. Policy updates are auditable and versioned, so users can verify when a rule changed and which identity context authorized the change. Your delete-on-death settings run first, before heir access opens.

In living mode, data access follows least-privilege principles. Support operations receive scoped access only for diagnostic tasks under audited approvals. Internal analytics use aggregated or pseudonymized signals where possible. Security monitoring may process telemetry relevant to abuse detection and system integrity. None of these pathways are intended to re-purpose vault content for advertising or unrelated profiling. Our policy position is that fiduciary trust and behavioral monetization are structurally incompatible. In plain English: In living mode, data access follows least-privilege principles.

Post-Mortem Data Rights and Heir Boundaries

Bottom line: Heirs receive only what you explicitly allow.

Post-mortem mode does not convert private history into open inheritance. Aftera applies policy-bound disclosure so heirs receive only what is required to execute responsibilities and rights assigned by the user or controlling legal framework. This distinction is central to our design: responsibility transfer is not blanket surveillance transfer. Users can define separate channels for financial records, legal records, memory archives, and private materials designated for deletion. In plain English: Post-mortem mode does not convert private history into open inheritance.

Heir permissions are claim-based and explicit. A claim can authorize a heir to view a class of documents, request transfer evidence, or receive status notifications without granting broad vault access. Claims can also be conditional, for example requiring another co-heir confirmation before access to certain materials. This model reduces over-disclosure risk and mirrors modern authorization systems where rights are granular, revocable, and purpose-scoped. Each heir gets only the specific access you granted, nothing broader.

During execution, disclosure logs are generated for every authorized release. Logs include actor identity, scope requested, scope granted, timestamp, and policy reference. Heirs can view these receipts in their interface, and authorized legal representatives can request structured exports for audit or dispute resolution. This transparency reduces ambiguity and prevents silent privilege expansion. It also helps families maintain trust in the process during emotionally difficult periods. In plain English: During execution, disclosure logs are generated for every authorized release.

Where local law imposes additional obligations, Aftera applies jurisdiction-specific overlays. These overlays can limit or expand certain disclosure pathways. Our baseline remains privacy-preserving, but lawful directives from competent authorities are handled through formal channels with minimum necessary disclosure and full logging. We do not treat legal compliance as an exception to transparency; we treat it as an auditable event with explicit rationale and constrained scope. We split storage across countries so one legal order cannot expose everything.

Right to be Forgotten (Post-Death) and Erasure Controls

Bottom line: Your private zones are wiped before inheritance unlocks.

Users may designate classes of data for secure erasure upon verified finality. This is implemented through delete-on-death policies attached to object categories or specific vault folders. Once trigger conditions are satisfied, erasure workflows execute before general heir access to those categories. The workflow is designed to avoid race conditions where data could be disclosed and then erased without traceability. In short, policy order is deterministic, and evidence is preserved without retaining erased content. Your delete-on-death settings run first, before heir access opens.

Secure erasure routines are applied according to storage media and architecture constraints. In distributed storage contexts, practical erasure combines encrypted object invalidation, key destruction pathways, replica revocation, and retention policy updates that prevent resurrection through backup drift. We document this as cryptographic erasure with operational verification. While no digital process can claim metaphysical deletion certainty, we design for strong practical irrecoverability aligned with contemporary standards. Your delete-on-death settings run first, before heir access opens.

Post-death erasure may be constrained by mandatory legal retention obligations, such as tax, probate, anti-fraud, or litigation preservation requirements. In those cases, Aftera retains only the minimum legally required artifacts and records the legal basis for retention. Retained artifacts remain scoped and inaccessible to unauthorized parties. Once the retention obligation expires, deletion workflows continue automatically according to the original policy intent where lawful. Your delete-on-death settings run first, before heir access opens.

Users and authorized representatives can request policy review if they believe erasure behavior was misconfigured. The review process includes retrieval of audit records, policy versions, and execution receipts. If a defect is confirmed, corrective controls are applied and logged. This review process is part of our duty of care: privacy guarantees are meaningful only if users can challenge outcomes and receive evidence-backed remediation. Your delete-on-death settings run first, before heir access opens.

• Delete-on-death flags are user-authored and versioned.
• Erasure executes before broad heir disclosure on protected categories.
• Legal retention exceptions are documented with explicit basis.
• Post-event reviews are supported with audit evidence.

GDPR Compliance, Legal Bases, and International Transfers

Bottom line: Your privacy rights stay enforceable across jurisdictions.

Aftera acts as controller for core platform processing and may act as processor in partner-integrated contexts depending on contractual boundaries. GDPR legal bases include contract performance, legitimate interest in security and abuse prevention, legal obligation compliance, and user consent where required for optional workflows. We avoid broad consent bundling and present meaningful controls where user decisions materially alter processing scope. In plain English: Aftera acts as controller for core platform processing and may act as processor in partner-integrated contexts depending on contractual boundaries.

Data subject rights include access, rectification, deletion, restriction, portability, and objection where applicable. Requests can be initiated through support channels and are handled under identity verification safeguards to prevent social-engineering misuse. Response timelines follow applicable legal requirements and may vary based on jurisdiction and request complexity. When requests cannot be fully honored due to legal obligations, we provide explanation and the legal basis for limitation. We split storage across countries so one legal order cannot expose everything.

International transfers are governed by appropriate safeguards such as standard contractual clauses, technical controls, and regional processing boundaries where available. Transfer risk is evaluated in relation to data category and sensitivity. Highly sensitive categories are prioritized for strict encryption and minimized movement. Our objective is to reduce cross-border exposure while supporting users who maintain legitimate multi-jurisdictional asset portfolios. We split storage across countries so one legal order cannot expose everything.

We maintain incident response procedures for confidentiality, integrity, and availability events. If a reportable breach occurs, notification and remediation follow legal requirements and internal escalation policy. Breach response includes containment, evidence capture, impact analysis, and corrective action planning. Privacy is treated as a continuity function, not a one-time checklist, because fiduciary systems must remain trustworthy over long horizons and changing regulatory landscapes. In plain English: We maintain incident response procedures for confidentiality, integrity, and availability events.

Children's Data and COPPA Context

Bottom line: Sensitive family data remains purpose-limited and protected.

Aftera is designed for adult fiduciary planning and is not directed to children under 13. We do not knowingly collect personal information directly from children under 13 in a manner that would trigger independent youth onboarding pathways. If we learn that such information has been provided without appropriate authorization, we take steps to delete or restrict that information consistent with legal obligations and safety considerations. This service is built for adults and avoids child-targeted data collection patterns.

In family scenarios where a guardian references dependent information for planning purposes, processing remains limited to what is necessary for lawful fiduciary context and is handled under the guardian's account controls. We do not provide independent child-facing social features, behavioral advertising modules, or open community posting surfaces that would create additional youth privacy exposure. The platform's architecture intentionally avoids these risk categories. In plain English: In family scenarios where a guardian references dependent information for planning purposes, processing remains limited to what is necessary for lawful fiduciary context and is ...

Guardians can request review of dependent-related records and can define post-mortem disclosure restrictions where local law permits. These safeguards ensure that family planning data remains purpose-bound and does not become an uncontrolled archive. Where regional laws provide additional youth protections, we apply those requirements through policy overlays. Our approach prioritizes restraint, transparency, and minimization. In plain English: Guardians can request review of dependent-related records and can define post-mortem disclosure restrictions where local law permits.

For questions regarding child privacy treatment, users may contact the support and legal channels listed in the help center and impressum pages. We treat these requests with heightened review priority and provide traceable outcomes. This commitment reflects our broader principle: privacy rights should remain clear and enforceable even when life circumstances become complex. In plain English: For questions regarding child privacy treatment, users may contact the support and legal channels listed in the help center and impressum pages.