Privacy and Retention

Data without a classification is handled by guess: personal facts sit beside public ones with nothing marking which is which. A meaning with a classification of public, internal, personal, or sensitive tells every later reader how each field is handled, and the data class ties the field to its erasure position and its retention row. The fields live in data on the aggregate record file.

Reviewed forWhich aggregate data fields lack a meaning, a classification, or a data class? Look at data on each aggregate page.

Marked guidance: a reviewer answers this question.

Erasure declared per field drifts: one field keeps a new position while its twin keeps the old one. Declaring the position once per class, with per-field exceptions beside it, keeps one decision in one place. The position is erase, pseudonymize, anonymize, retain, exempt, tombstone, discard, cascade-only, or transferred; the basis is statute, business, or engineering; the period is an ISO 8601 duration or { "mode": "none", "reason": "..." }; the enforcement is reaction/..., job/..., record-expiry, store-ttl, or query-filter. A pseudonymized class stays personal with its basis, and an anonymized class can no longer identify anyone. The erasure-undeclared check reports a personal or sensitive field with no declared position, and retention-enforcement-missing reports a class nothing enforces.

The submitter-contact class declares personal, pseudonymize, its purpose, and its accepting requirement, while the expense-ledger class declares internal, retain, a statutory seven years, and the finance expiry job.

Checked bylitespec model check reports erasure-undeclared for a personal or sensitive field with no declared position and retention-enforcement-missing for a class nothing enforces.

Marked checkable: the tool named here checks it.

Keeping personal data past erasure is a business choice, not a technical default: the statute or the business accepts it, with the reason on record. Pseudonymized data stays personal data, so it needs the same acceptance as retained data. Naming those requirements or decisions in basedOn keeps the keeping reviewable where the promise lives. The risk-acceptance-missing check reports a pseudonymized, retained, or exempt personal or sensitive class with no Intent acceptance.

Reviewed forWhich pseudonymized, retained, or exempt personal or sensitive classes name no accepting requirement or decision? Look at basedOn on each data class.

Marked guidance: a reviewer answers this question.

Personal data forwarded to a processor without an erasure route stays there past erasure: the product forgets while the processor remembers. Declaring { "mode": "call", "operation": "external-system/<name>#<operation>" } naming the operation, { "mode": "event", "event": "integration-event/<name>" } naming the forwarding integration event, or { "mode": "impossible", "reason": "..." } with its reason and its Intent acceptance states the route beside the system.

Reviewed forWhich external systems declare no erasure call, forwarding event, or impossible reason with acceptance? Look at the external systems beside their erasure routes.

Marked guidance: a reviewer answers this question.

Retention decided per aggregate scatters: one module erases in days what another keeps for years, and no page shows the whole. Listing every data class on one schedule with its purpose, basis, period, enforcement, processors with their forwarding and acceptance, and the conflict rule where keeping and erasing collide states the whole as rows a reviewer judges together. The schedule states the time limits of a record of processing. Personal or sensitive keeping cites its Intent requirement. The retention-enforcement-missing check reports a row nothing enforces.

Checked bylitespec model check reports retention-enforcement-missing for a data class nothing enforces.

Marked checkable: the tool named here checks it.

Some rows are referenced after they are gone: remote servers hold copies, audit trails cite row ids, and support tools link to deleted accounts. Erasing the row breaks those references, while keeping it breaks the erasure duty. A tombstone keeps the row id and the erasure date and drops every other field, so references resolve to a marker that says the subject is gone.

ZITADEL deletes a user by moving it to a terminal state and deleting its read-model rows while the events stay for audit, and Sentry writes a tombstone for a discarded issue so that later events for it are dropped at intake instead of stored again.

Reviewed forThe aggregate pages mark referenced-after-erasure classes tombstone with the marker fields each keeps.

Marked guidance: a reviewer answers this question.

A tombstone is still a row: it occupies storage, appears in counts, and invites readers to treat a gone subject as present. Where no reference and no audit needs the marker, deleting the row outright keeps the store honest.

Lago discards a customer: the profile is hidden and its relations end, while finalized invoices and credit notes stay as the ledger.

Reviewed forThe onErasure entries on the aggregate pages carry discard where no marker duty exists.

Marked guidance: a reviewer answers this question.

Some rows have no subject of their own: line items belong to an invoice, receipt files belong to an expense, usage rows belong to a customer. A direct erasure request names the parent, never the child, so the child follows the parent's erasure and refuses a request addressed to itself.

Cal.com deletes a user by removing the account and letting the database cascade remove the rows that hang off it, with no retention schedule; a product at this rung declares cascade-only and names the cascade path.

Reviewed forThe child class entries name cascade-only with the parent class, and the parent erasure tests clear the children.

Marked guidance: a reviewer answers this question.

Erasure is not the only end of custody: a branch closes and a successor takes its readers, a company is acquired, a contract moves to a new processor. The data survives under a new controller, so the record names the receiver and the handover both sides signed instead of a deletion that never happened.

A support tool sends a loan summary and the reader message to a hosted AI model to draft a reply; the position names the model provider, its region and its retention, and the product stores none of it.

Reviewed forThe handed-over class entries name transferred with the receiver and the handover record.

Marked guidance: a reviewer answers this question.

A subject who asks to delete one order does not ask to delete the account, and a subject who asks to delete the account names everything. The requested reach ties the erasure to the request it answers, so a narrow request cannot widen into a broad deletion and a broad request cannot stop at one row.

A request naming one hold erases that hold and leaves the reader's other loans untouched.

Reviewed forThe erasure use cases cite the request they answer and touch only the data it names.

Marked guidance: a reviewer answers this question.

The sentence on the confirmation screen is the promise: what goes, what stays, and for how long. Behavior cannot word it, because only the product team decides what the product promises. Stating it in Intent puts the exact sentence readers see beside the requirement it fulfils.

Mastodon shows on its account deletion form that content other servers have cached may persist, next to the promise that the account and its posts are removed; that sentence is the user-facing copy for a requested reach.

Reviewed forThe confirmation sentence in the Intent requirement stands before the release that shows it.

Marked guidance: a reviewer answers this question.

Erasure destroys the only copy of data the subject may still want: identity documents, message history, purchase records. Completing the export first gives the subject their data while it still exists, so erasure never destroys what the subject asked to keep elsewhere.

Claimwick makes finance download the tax-relevant data before a shredder runs, and refuses to shred when anything changed after that download.

Reviewed forThe export-first classes show a completed export before each erasure run in the run evidence.

Marked guidance: a reviewer answers this question.

An export taken last month does not cover rows written yesterday. When the data changed since the last export, erasing on the stale copy destroys rows the subject never received. Stopping for a fresh export keeps the export-first promise true at the moment of erasure.

A reader who corrected their address after exporting it gets a fresh export first, and the erasure waits for it.

Reviewed forThe erasure runs after mid-window edits show a fresh export completed first.

Marked guidance: a reviewer answers this question.

A backup holds data as it was, including rows erased since: restoring it resurrects subjects the product promised to forget. The sweep job re-applies every erasure decided before the restore, so the restore brings the system back without bringing the erased data back with it.

The database restore runbook names job/privacy.sweep-restored-erasure, which runs before traffic returns and deletes every row erased since the backup.

Reviewed forWhich restore runbooks name no sweep job? Look at the restore runbooks.

Marked guidance: a reviewer answers this question.

Keeping for audit and erasing for the subject collide on the same row: the invoice the statute keeps sits beside the name the subject erases. Silence lets each implementer pick a winner. Naming the winning duty with its basis keeps one decision where every reader finds it.

Claimwick keeps the expense ledger for seven years under tax law while erasing the submitter contact. ZITADEL keeps its audit events while erasing the user they describe, under the same rule.

Reviewed forThe retention schedule rows name the winning duty with its basis.

Marked guidance: a reviewer answers this question.