Erasure is anonymization: the GDPR data-lifecycle model

Status: accepted

“Completely deleting” a learner cannot literally mean deleting every trace — that would over-delete records retained under other lawful bases (org award registries, audit integrity, Art. 89 research) and implies absurdities like rewriting archival backups. GDPR agrees: genuine anonymization satisfies Art. 17 (Recital 26 puts anonymous data outside the regulation), and the re-identification standard is “means reasonably likely to be used” — the motivated intruder, not the nation-state. We target meaningful privacy, claimable with a straight face, not theatrical deletion.

Decision

• Erasure = anonymization by default. Hard deletion applies only to pure-identity rows (person, identity_binding, person_profile); everything value-bearing is anonymized in place.
• Severing must clear Recital 26: per-row breaking of person linkage (null or per-row random re-key). Never a shared surviving tombstone identifier — that is pseudonymization, which is still personal data and is not erasure.
• Every person-linked table declares exactly one erasure class, in schema metadata, enforced by a schema-smoke test (an undeclared person-referencing table fails CI):
  • cascade — pure identity rows; deleted.
  • scrub — row survives; PII payload columns rewritten (change_audit_entry before/after, activity_event jsonb).
  • sever — row survives under a lawful basis; person linkage irreversibly broken (scores, sessions, evidence, award registries).
  • retain-deidentified — Research Projections under Art. 89 safeguards (ADR-0008).
  • external — handled by protocol: sync delete propagation, credential revocation.
• Backups are handled “beyond use” (ICO/CNIL doctrine): live systems are erased within the Art. 12(3) window (one month, extendable); backups expire via normal rotation; restores replay erasures; the data subject is told this is how it works. Archival media are never rewritten.
• Erasure Receipt: each erasure leaves a non-personal record (timestamp, scope hash, legal basis). It is the Art. 5(2) accountability proof and the restore-replay log — one artifact, two duties.
• Devices are out of scope beyond ordinary sync delete propagation. A data subject’s local copy of their own data is theirs; learner data on a teacher device is removed by the next sync; a never-reconnecting device is a device-security problem, not an erasure problem.
• Exported credentials are out of scope: wallet/verifier copies are signed documents the subject chose to export. Art. 17(2) “reasonable steps” = revocation/status-list update.
• Controller/processor split: in org deployments the org is controller and requests route through it (we assist, Art. 28); for independent learners we are controller. Same machinery, different button-pusher.
• qualification_award.person_id flips from cascade FK to sever (the issuing org may be legally required to retain the award record).

Considered and rejected

• Hard-delete everything. Over-deletes lawful-basis records, breaks audit integrity, and implies backup rewriting no DPA requires.
• Shared tombstone person stub. Referentially convenient but fails Recital 26: one surviving identifier linking all retained rows is pseudonymization.
• No declared classes (handle requests ad hoc). Compliance would silently rot: every new person-linked table is a potential leak the day it ships.

Consequences

• Erasure-class declaration is added to schema metadata (alongside the defineSyncTable governance block) with a CI smoke test.
• change_audit_entry and activity_event need scrub implementations.
• The LRS takes the cascade class (resolved): the erased person’s statements, xapi_agent_canonical row, and agent-keyed xapi_document rows are deleted, located via the indexed actor-ifi / context-agent-ifi statement relations. Anonymize-in-place was rejected for the LRS because its post-erasure value is already extracted into sever-class projections (item_session, package_progress, Research Projections), and rewriting signed-hash payloads (payload_sha256) carrying free-text inference risk buys nothing. Severed evidence rows keep dangling source_statement_ids, documented as “redacted by erasure”. xAPI voiding is a protocol concern only — never an erasure mechanism.
• The restore runbook must include erasure replay from receipts.
• Public “GDPR-compliant” claims may reference this model: anonymization-first, beyond-use backups, Art. 89 research carve-outs.