LoyalChain: Erasure Requests Against an Immutable Ledger

Is it personal data? Test identifiability, not format. An unsalted keccak hash of an ID document number is trivially reversible by brute force, because the input space is small and enumerable. That makes it pseudonymised data, and under Article 4(1) and Recital 26 pseudonymised data remains personal data where the controller can re-identify using information it holds. LoyalChain holds the ID numbers, so it can re-identify. The hash is personal data.

Can it erase? Article 17 requires erasure 'without undue delay', but erasure is an outcome, not a prescribed technical act. Compliance options, in order of preference:

1. Crypto-shred: destroy the KMS key material and the key-derivation inputs. The linked PDFs become unrecoverable ciphertext, which is widely accepted as effective erasure.
2. Off-chain deletion: delete all PDFs from LoyalChain-controlled storage and issue contractual deletion instructions to all three pinning services; switch to a private gateway so cached copies are not served.
3. On-chain: no deletion is possible on a public chain without a destructive fork, and a fork to erase one hash would be disproportionate and would not erase archival nodes.

The correct answer is not 'impossible, therefore refused'. It is: take every step that is technically and organisationally available, document why on-chain deletion is not, and explain the residual to the data subject within one month.

Also check exemptions: data needed for legal claims arising from the breach may be retained, narrowly and with a documented retention period.

Timing. The clock starts on 'awareness', not on the end of the investigation. Article 33 gives 72 hours to notify the lead supervisory authority - here the Irish authority, as LoyalChain's main establishment is in Ireland - unless the breach is unlikely to result in a risk. Twelve thousand identity documents is high risk of identity fraud; notification is required.

The 11-day exposure is not an excuse. It is an aggravating fact. The notification should state when the breach occurred, when it was detected, and why detection took 11 days, including what monitoring was in place. Regulators consistently treat detection delay as a separate governance failure.

Who else. Article 34 requires communication to affected data subjects without undue delay where there is high risk. Consider notifying the banks and identity providers whose customers may be impersonated, and any sectoral regulator with a parallel reporting duty.

Content. Nature of the breach and categories and approximate numbers of data subjects and records; DPO contact; likely consequences (account takeover, identity fraud); measures taken and proposed, including any mitigation such as credit monitoring; and any cross-border dimension.

Internally. Log in the breach register, preserve forensic evidence, and do not destroy the misconfigured bucket logs. If a processor caused the exposure, the Article 28 contract and its 24-hour processor notification clause should be examined, but the controller's 72-hour clock runs regardless.

Architecture

• Keep all KYC artefacts off-chain. Put only a non-reversible, per-user salted commitment on-chain, with the salt held off-chain and deletable - this preserves verifiability while making erasure meaningful.
• Alternatively, store a random pseudonymous identifier on-chain and keep the mapping in an access-controlled off-chain store that can be deleted.
• Move from IPFS public pinning to encrypted, access-controlled storage with a documented key lifecycle: generation, rotation, escrow, and destruction.
• Add DLP and bucket posture scanning, and a data-map that flags any field containing special-category or identity data before it is written to a shared ledger.
• Run a DPIA for the on-chain processing, including a technical-impossibility register explaining what cannot be deleted and why.

Contracts with the three pinning providers

• Article 28 processor terms: process only on documented instructions, deletion or return on termination, assistance with data subject rights, breach notification within 24 hours, and audit rights.
• Explicit obligation to unpin on instruction and to confirm in writing, with a defined window.
• A schedule listing the exact CIDs covered so deletion can be evidenced.

Governance Assign a named owner for erasure requests, a 30-day SLA with a documented extension route, and a standing test in which a sample subject is erased end-to-end once a quarter. Test the crypto-shred; an untested key-destruction procedure is a promise, not a control.