Erasure vs. immutability — the honest answer

Every immutable ledger faces the same question: if the record can’t be changed, how do you honor the right to erasure?

The two requirements

1. Tamper-detection requires that a changed record shows it was changed — the hash chain breaks. That’s the product’s core guarantee.
2. GDPR Art 17 requires that personal data be erasable on request.

These look contradictory. They aren’t, if you separate the data from the proof of the data.

ISNAD’s approach: tombstone / hash-first redaction

When erasure is required:

1. Redact the personal data in the record (name, claim text, identifiers → a tombstone marker like [erased]).
2. Keep the hash of the pre-redaction content, so the chain still verifies as un-broken — the fact that a record existed and hasn’t been silently altered remains provable, while the PII itself is gone.
3. Log the erasure event itself, so the redaction is auditable, not silent.

The result: the record is still tamper-detecting, and the personal data is gone.

The honest limit

This is the standard resolution in immutable systems (blockchains, Certificate Transparency), but the exact mechanism should be confirmed with your counsel against your specific regulatory posture. ISNAD gives you the mechanism; your DPO decides whether it satisfies the obligation in your context.