SAIHM × GDPR Article 17 crosswalk
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (the General Data Protection Regulation, “GDPR”) has applied since 25 May 2018. Article 17 — Right to erasure (“right to be forgotten”) gives data subjects the right to obtain erasure of personal data without undue delay, on the grounds listed in Article 17(1)(a)–(f).
SAIHM’s saihm_forget tool is built to provide cryptographic-grade evidence of erasure: stronger than soft-delete or operator-policy-only erasure. The mechanism is DEK destruction + tombstone publication + content-address blacklist + on-chain audit receipt. The operator cannot revive the data because the operator never held the key.
Article 17 grounds, mapped
| Article 17 ground | SAIHM mechanism |
|---|---|
| 17(1)(a) — Personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed. | Holder calls saihm_forget(cellId). The DEK is destroyed, a tombstone is published, the CID is blacklisted, and an audit receipt is anchored on chain. |
| 17(1)(b) — The data subject withdraws consent on which the processing is based. | Same mechanism. Consent withdrawal triggers immediate cryptographic erasure; no operator-side delay. |
| 17(1)(c) — The data subject objects to the processing under Article 21 and there are no overriding legitimate grounds. | Holder invokes saihm_forget. The audit log records the cellId, the timestamp, and the holder signature. |
| 17(1)(d) — The personal data have been unlawfully processed. | Holder invokes saihm_forget. The audit chain provides independently verifiable timing. |
| 17(1)(e) — The personal data have to be erased for compliance with a legal obligation under Union or Member State law. | Cryptographic erasure satisfies the requirement to erase “without undue delay”: the act is atomic and irreversible. |
| 17(1)(f) — The personal data have been collected in relation to the offer of information society services referred to in Article 8(1). | Same mechanism; SAIHM is agnostic to data-subject category. |
| 17(2) — Where the controller has made the personal data public, reasonable steps to inform other controllers processing the data. | Tombstone publication + CID blacklist serve as the public “erasure notice”. The blacklist is reachable from chain receipt; downstream operators can verify the cell is forgotten. |
| 17(3) — Exceptions (freedom of expression, legal obligation to retain, public interest, scientific research, defence of legal claims). | Out of scope for saihm_forget. Where retention is legally required, the holder simply does not invoke forget. The protocol does not enforce policy; it provides the cryptographic tool. |
Supporting articles — Privacy by Design & Security
| Article | SAIHM mechanism |
|---|---|
| Article 5(1)(e) — Storage limitation. Personal data kept in a form which permits identification of data subjects for no longer than is necessary. | Cryptographic erasure is the storage-limitation primitive. When data is no longer necessary, it ceases to be readable by any party, anywhere. |
| Article 25 — Data protection by design and by default. Technical and organisational measures designed to implement data-protection principles. | Wallet-bound HKDF (MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1). Per-cell DEK. Encryption-before-egress. The operator never holds plaintext. |
| Article 30 — Records of processing activities. Maintained in writing, including in electronic form. | The on-chain audit log is the records-of-processing artefact. Each operation is signed, time-stamped, and reproducible. |
| Article 32 — Security of processing. Appropriate technical and organisational measures, including pseudonymisation and encryption of personal data. | ML-DSA-65 post-quantum signatures (FIPS-204). Per-cell DEK. KEK rotation. Documented threat model. |
| Article 33 — Notification of a personal data breach to the supervisory authority. | Operator cannot read SAIHM cell contents at rest. A storage breach at the operator does not expose plaintext personal data; the breach analysis can cite the encryption-before-egress invariant. |
| Article 35 — Data protection impact assessment. | This crosswalk and the I-D §7 (Privacy considerations) provide the DPIA-ready evidence on memory-protocol design. |
Why cryptographic erasure beats soft-delete
- Operator cannot revive data. The DEK is destroyed at the holder side. Even if the operator retained ciphertext indefinitely, the ciphertext is computationally meaningless without the destroyed key.
- Backup & replica safety. Backups and replicas store ciphertext only. Erasure of the DEK propagates erasure semantics to every copy of the ciphertext, anywhere, automatically.
- Audit-grade evidence. The chain receipt for
saihm_forgetis a time-stamped, signed record. A supervisory authority can verify when erasure happened without trusting the operator. - No race conditions. The operation is atomic at the cryptographic layer. There is no “deletion queue” the operator could fail to drain.
How to cite SAIHM in a DPIA or Article 30 register
- Reference this crosswalk URL.
- Reference the protocol spec: Internet-Draft
draft-saihm-memory-protocol-00(in preparation). - Reference the reference implementation:
npx @saihm/mcp-server(Apache 2.0). - For Article 30 records: each cell’s lifecycle is a discrete processing activity with chain-anchored receipts (write, read, share, revoke, erase).
- For Article 35 DPIA: cite the I-D §7 (Privacy considerations) and the operator-honest-but-curious threat model in §6.4.