Erasure Request on a Blockchain: Immutability, Blocking and Proof

An erasure request creates a particular technical problem where personal data are stored on a blockchain. Depending on the architecture, a confirmed block cannot simply be overwritten. The first questions are therefore which information is actually on chain, whether it can be linked to an individual and which connected data are stored outside the blockchain.

This article addresses erasure requests involving immutable blockchain structures. It explains how to assess the personal-data link, separate on-chain and off-chain data, limit access and record the response. General backups, anonymisation, data portability and data breaches are separate subjects.

Article 17 GDPR concerns personal data. For a blockchain, the label of a field is therefore less important than whether the information can be linked to an individual. A hash value, wallet address or technical identifier may have different significance depending on the additional information available. The assessment must follow the actual architecture and the knowledge held by controllers, providers or other participants.

Review the on-chain entry together with the off-chain systems. A blockchain address may be connected with a customer profile, contract, identity check or mapping table. An entry without a name can still remain personal data when it can be combined with other information. This review is the basis for every further decision.

The request must also be recorded according to its substance. Does it concern an on-chain value, a linked profile, key material, documents outside the chain or all of these elements? The article on access requests under Article 15 GDPR shows how a request can first be organised by systems and data types. An erasure request then requires its own assessment of conditions and exceptions.

The technical architecture determines which response is possible. Record every type of information created by the blockchain process: transaction data, hash values, keys, wallet mappings, user profiles, documents, logs, backups and data in connected applications. Mark which values are immutable on chain and which are held elsewhere.

Off-chain data can usually be handled in their own systems. This may concern a customer profile, a mapping table or a document referenced by a blockchain entry. Erasing data outside the chain answers the request only to the extent that it changes the personal-data link and further use in practice. The connection with the blockchain needs its own assessment.

Article 5 GDPR includes purpose limitation, data minimisation and storage limitation. These principles matter when the architecture is planned. Store as little personal information as possible directly on a structure that cannot later be adjusted. Future erasure requests will then be easier to assess and control.

Blocking prevents or limits the use of data. It may concern applications, permissions, interfaces or access to mapping keys. This can stop further processing in practice. Whether it also amounts to erasure under Article 17 GDPR depends on the technical and actual access position.

An immutable record remains present where it is merely removed from a user interface or hidden in an application. The same applies where one application is blocked but other systems can still reach the value, a copy or the mapping to a person. Explain precisely which use has ended and which access options remain.

Article 25 GDPR requires data protection by design and by default. Access blocking can form part of that safeguard. It must be connected to the individual request and should not be used as a blanket answer for every blockchain arrangement.

In blockchain applications, key material may determine whether data can be read, linked or processed further. Review who manages the keys, which applications use them, whether copies exist and whether providers have their own access. A key must not automatically be treated as identical to the personal data.

Destroying or blocking a key can be a technical measure that makes access more difficult. It does not by itself prove that every personal-data link has disappeared. The assessment must cover copies, alternative keys, exported data and other routes to an allocation. Record the specific technical effect of the measure.

Article 32 GDPR requires a level of security appropriate to the risk. In the individual system, this can include access controls, separated roles, protected interfaces and reviewable management of privileged access. The measure must match the architecture and sensitivity of the affected data.

Article 17 GDPR also covers situations where continued processing must be assessed. These include legal obligations, tasks in the public interest and the establishment, exercise or defence of legal claims. An exception cannot be justified merely by the technical immutability of a blockchain. Record the concrete condition and the scope of continued storage.

Record receipt, the requester’s identity, the affected transactions or data sets, identified storage locations and available allocation routes. Then decide on each relevant data set. An on-chain value, an off-chain profile and an access key may require different measures.

The evidence must explain the decision without collecting unnecessary new personal data. Article 5 GDPR requires responsible and traceable processing. Record responsibility, checks, technical implementation, control and result in a form that remains understandable later.

Start with a complete record of the request. Secure the time of receipt and allocate the requested data to blockchain and off-chain systems. Then review personal-data links, purposes, storage locations, recipients, access and possible exceptions. A technical description should remain understandable for the legal assessment.

Set the measure for each data set. This may be erasure of an off-chain record, removal of a mapping, blocking of an application or another technical change. Where an on-chain entry cannot be altered, describe and assess the remaining access options openly.

Control implementation against the systems and copies identified at the start. Review applications, interfaces, key management and provider access. Record what was checked, who performed the control and the result. Evidence should support the decision rather than simply assert it.

The blockchain is treated as an automatic exception: Technical immutability alone does not answer whether Article 17 GDPR applies or an exception is available.

A hash is automatically called anonymous: The link to an individual depends on additional information, the architecture and available knowledge.

The interface is cleaned while the entry remains reachable: Hiding a value in one application does not end other access, copies or allocation routes.

Key destruction is equated with erasure: Its technical effect and remaining identifiability require a separate assessment.

Off-chain systems are ignored: Profiles, documents, mapping tables, exports and provider copies may be decisive for the response.

The evidence records only the result: Without architecture, checks, responsibility and control, the decision is difficult to explain later.

We review the technical architecture, personal-data link, on-chain and off-chain data, keys, access and possible exceptions with you. The request, a data-flow description, affected transactions or hash values, system and provider records and the previous response help with an initial assessment. This shows which data can be erased, which access can be limited and which steps must be evidenced. If a security incident is involved, the process for a data breach at a processor must be assessed separately.