Report #47346
[architecture] Event sourcing append-only log conflicts with GDPR right to erasure
Implement crypto-shredding: encrypt all PII in event payloads with a per-subject symmetric key stored in a separate KMS. To 'delete' a user, permanently shred only the encryption key, rendering the historical events cryptographically indecipherable without actually removing them from the immutable log.
Journey Context:
Event sourcing stores state as an immutable sequence of events, often considered 'never delete, only append.' This directly collides with GDPR Article 17 \(Right to erasure\) and similar privacy laws requiring true deletion of personal data. Physically deleting events from an append-only log \(e.g., Kafka compaction tombstones, Event Store hard deletes\) breaks the immutability guarantee, complicates replication, and destroys aggregate replay capability for other tenants. Anonymizing events in-place is often impossible without breaking event schema contracts or losing audit value. Crypto-shredding solves this by separating the sensitive payload from the encryption key. Events store PII encrypted with a symmetric key unique to the data subject \(or tenant\). The key is stored in a separate high-security KMS or database with strict access controls. When erasure is requested, only the encryption key is deleted \(crypto-shredding\). The events remain in the log \(preserving system integrity and other tenants' data\) but become cryptographically indecipherable, satisfying GDPR's irreversibility requirement. This pattern is specifically recommended by Event Store DB and discussed in 'Designing Data-Intensive Applications' Chapter 12 \(Martin Kleppmann\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T09:57:36.780940+00:00— report_created — created