GDPR, Immutability, and Erasure

Reconciling append-only committed facts with rectification and the right to be forgotten

Regulation reference

GDPR does not require silent rewrite of history — it requires lawful processing, accurate data, and erasure where applicable; immutability and GDPR reconcile through forward commits, tombstones, and scoped retention — not mutable audit logs.

EUR-Lex — GDPR (Arts. 5, 16, 17, 30)

MARKO ŽIVKOVIĆ In review

Immutability of facts and GDPR are often presented as in conflict. They are not — if “immutability” is understood correctly.

Immutability means: what was committed ** happened in the record**; correction is forward through new events (supersession, correction events, compensating actions) — not silent UPDATE or delete that pretends the past never existed (mutable history).

GDPR requires (among other things):

Accuracy (Art. 5(1)(d)) — inaccurate data rectified (Art. 16).
Erasure in defined cases (Art. 17 — “right to be forgotten”).
Records of processing (Art. 30) — not necessarily indefinite retention of all personal data in all forms.

The tension is real at the engineering layer: naive “immutable” systems that store personal data forever in plain text without lawful basis or erasure path fail GDPR. Naive “GDPR compliance” that hard-deletes audit history fails accountability and record falsification norms.

Reconciliation pattern

Requirement	Principled approach
Rectification	Forward correction event referencing original; consumers read corrected view
Erasure	L0 ErasureCommitted / tombstone event — processing stops; projections redact; crypto-shred or keyed destruction where lawful; do not pretend the original commit never occurred if law requires audit retention of that erasure was ordered
Retention limits	Policy-bound lifecycle; separate operational projections from legal-hold archives with access control
Personal data in logs	Minimise at capture; pseudonymise where possible; document lawful basis (document before apply)

Destroy vs commit: Physical destruction of media may be a committed act in the log (“key destroyed at … under Art. 17 request id …”) — the meta-record of lawful erasure can remain while payload becomes unreadable.

What not to do

Silent row delete in “immutable” event store → mutable history + GDPR breach risk.
Refuse all erasure citing “immutable architecture” → confuses technical convenience with truth.
Erasure that removes evidence of who decided on a contested automated bind → destroys contestability audit trail unlawfully or unethically depending on scope.

Corpus stance

Context A2 — architectural direction for teams building both GDPR-aligned data subject rights and append-only judgment infrastructure. Not legal advice; DPIA, lawful basis, and sector rules (finance, health) may impose stricter retention.

Open A3 — deployment-specific T12 — jurisdiction-specific interpretation of erasure vs freedom of expression, legal claims, and public interest archiving — document in deployment spec, not assumed here.