On 7 July 2026, the European Data Protection Board adopted the final version of its Guidelines 02/2025 on the processing of personal data through blockchain technologies, closing a process that began with a first public version in April 2025 and ran through a public consultation from 14 April to 9 June 2025.

In this post, we go through what the guidelines say about the areas of GDPR that blockchain struggles with most: the data subject’s rights to erasure and rectification, and the principle of storage limitation, and where we think the EDPB’s proposed technical fixes hold up and where they don’t.

Blockchain in Plain Terms: Distributed Ledgers, Centralised Registers, and Why the Architecture Matters

Blockchain is a specific type of distributed ledger technology (DLT): an architecture for recording and storing information, used to log transactions or other interactions in a way that answers directly to a demand for transparency. Among its defining, flagship features are the integrity, immutability, and authenticity of whatever data is recorded through it. Those same guarantees also mean that, once information has been written into the ledger, it cannot unilaterally be changed or removed by any single participant.

A distributed ledger, in general, is a database that exists across several locations, or among several participants, rather than in one place. Traditionally, registers are centralised: a single entity holds, maintains, and updates the database, and everyone relying on that register places a certain amount of trust in that entity – think of a national companies register, a shareholder register, or a university’s student records system. A distributed ledger removes the need for that central manager or intermediary. Every participant holds a full copy of the ledger, and no single participant can unilaterally introduce a change; a change is only accepted once it has been validated by the other participants, through what is generally called a consensus mechanism. Because every participant sees every change and its content, the ledger is inherently transparent, and that transparency is precisely what allows a distributed ledger to function without the layer of trust a centralised register requires.

Blockchain is a specific, and now the most recognisable, implementation of this idea. Its key attributes, decentralisation, distribution across many network participants, encryption, and, to varying degrees, anonymity, combine to guarantee the integrity, immutability, and authenticity of whatever has been entered into the register. In practice, this means data written to the chain cannot, in the ordinary course of operation, be altered or deleted by anyone. Not every distributed ledger on the market today fully implements every one of these original design goals (Bitcoin remains the standard reference point for a system that does), but the term “blockchain” is now used loosely for any distributed, chain-of-blocks register, whether or not it delivers on the full original blueprint.

Technically, a blockchain is exactly what the name says: a chain of blocks. A block is a defined package of information that, once created, cannot be altered. Except for the very first block in the chain (the genesis block), every block contains an encrypted reference to the block before it, additional data specific to that block (typically the transactions or changes it records), and an encrypted reference to itself. That “encrypted reference” is a hash: the output of a mathematical function that takes information of any size and reduces it to a short, fixed-length string that is unique to that exact input. Change even a single character in the original information and the resulting hash changes completely and unpredictably. Hashing is also, by design, a one-way function: you can always generate the same hash from the same input, but you cannot work backwards from a hash to reconstruct the information that produced it, at least not with currently available computing power.

This is the mechanism that gives blockchain its tamperproof character, and it is also, not coincidentally, the exact mechanism the EDPB guidelines come back to when they discuss hashing as a mitigation technique. Because each block’s hash depends on the content of the block before it, altering any historical entry would break every hash calculated after it – an inconsistency every node in the network would immediately detect. This does not mean a blockchain can never register a change. It means a change can only ever be added, never substituted: a new block recording that “what was previously X is now Y” is entirely possible, and preserves the chain’s continuity, transparency, and integrity. What is not possible, by design, is rewriting or deleting the original entry itself, and that one architectural fact is the root of almost everything the EDPB has to say about erasure, rectification, and storage limitation.

What the Guidelines Are Saying

The guidelines analyse how blockchain’s technical properties – distributed, disintermediated, consistent, tamperproof, and transparent – interact with the principles in Article 5 GDPR, which applies whenever personal data touches a blockchain, regardless of use case.

GDPR requires personal data to be corrected or removed once it’s no longer needed or a data subject validly asks for that. Blockchain, by design, resists exactly that. Once a transaction is validated and enough blocks sit on top of it, altering or removing it would be detected as an inconsistency by every node. The guidelines put it plainly: blockchains “do not have a default process to support the deletion of transactions” and “do not allow for a gradual adoption” once introduced.

The Core Problem: An Immutable Ledger Meets a Deletable Right

The EDPB’s position on erasure is very clear: “technical impossibility cannot be invoked to justify non-compliance with GDPR requirements.” This sentence forecloses the argument, made repeatedly during the consultation, that a technology’s inherent properties can excuse it from a legal obligation. The EDPB’s answer is that the obligation does not move; the architecture has to.

The guidelines acknowledge that actual deletion of a transaction from a live blockchain is often technically impracticable. Their proposed solution is effective anonymisation: rendering the on-chain data unable to identify a data subject, by means reasonably likely to be used, once an erasure request or objection is received. That requires two things to hold simultaneously:

1. The on-chain transaction data itself must not allow direct identification, and
2. Any off-chain data that could allow indirect identification must actually be erased.

If either piece is missing, the “anonymisation” is not applied effectively. In practice, this means the erasure mechanism has to be designed before the first transaction is written, not retrofitted once a data subject exercises their rights.

Rectification: A Patch, Not a Fix

Rectification fares no better structurally, and the guidelines are candid about the workaround rather than pretending it solves the underlying problem. In some cases, the right to rectification can be met by recording a subsequent transaction that announces the cancellation of the earlier, incorrect one. The first transaction will still appear in the chain. Therefore, the record itself is not corrected as the original record continues to exist, unaltered, alongside the new one.

Where rectification genuinely requires erasure of the underlying data rather than a superseding entry, the guidelines fall back on the same tools used for deletion requests – meaning the same off-chain anonymisation mechanism.

Storage Limitation: Why “The Blockchain Lives Forever” is Not a Retention Policy

The third leg of this problem is subtler and probably one most likely to be overlooked in practice. It would be easy to reason that because a blockchain is tamperproof for its entire lifetime, that lifetime is simply the retention period. The EDPB rejects this explicitly: the tamperproof nature of a blockchain “is not a reason to assume that the lifetime of the blockchain is an appropriate data retention period.” Retention has to be tied to the purpose of the processing, exactly as it would for any other technology, and data (including the identifiers embedded in transaction metadata) must be deleted or anonymised once that purpose has been served.

The guidelines then draw a sharper line than many organisations will be expecting: where the processing does not require a retention period equal to or longer than the blockchain’s own lifetime, personal data simply should not be written to the chain in the first place, unless it is written in a way that effectively prevents future identification of the data subject by means reasonably likely to be used. If a controller does decide that the retention period should run for the life of the blockchain, that decision cannot be a default. It has to be justified as necessary and proportionate to the purpose, and that reasoning has to be documented. In other words: the permanence of a public ledger is not a convenience feature.

The Technical Toolkit: Encryption, Hashing, and Commitments, and Where They Fall Short

The guidelines offer three main technical measures for cases where storing something on-chain is genuinely unavoidable:

• encryption,
• hashing, and
• cryptographic commitments.

Encrypting personal data before writing it on-chain means the data is unintelligible without the decryption key. Delete the key, and the data becomes practically inaccessible. The guidelines are careful to note two things here:

1. Encrypted personal data is still personal data, and
2. Even state-of-the-art encryption has a shelf life.

If a blockchain is retained indefinitely, the encryption protecting it eventually will not be, whether through advances in cryptanalysis, quantum computing, or simple key compromise. An encryption-based erasure strategy is therefore not a permanent solution, but rather a race against decreasing cryptographic strength over an increasing time horizon, and that horizon has to be actively monitored.

Hashing works differently, and this is where the guidelines get more technical. The recommended approach is not to hash the data on its own, but to hash it together with a secret key or a long, randomly generated salt, and to store that unhashed original data, plus the key or salt, off-chain and confidentially. The advantage is that a hash produced this way is more resistant against reverse engineering techniques. However, you do not, and cannot, delete the hash sitting on the chain. What you delete is the secret key or salt held off-chain. Once that secret is gone, the on-chain hash should no longer be linkable to the original data, but only under three conditions holding simultaneously:

1. The hash algorithm has not been broken,
2. The key or salt was never compromised or leaked, and
3. The salt itself was not poorly chosen in the first place.

The guidelines are also blunt that an unsalted or unkeyed hash is not considered strong enough to guarantee confidentiality on a public chain, and the hash itself, until that unlinkability is achieved, is still personal data under GDPR. Therefore, hashing functions here only serve as pseudonymisation with a planned expiry date.

Additionally, storing the original data and its key or salt somewhere else does not make the personal data problem disappear – it just relocates it. That off-chain system is now itself processing personal data, with its own access controls, its own breach risk, and its own retention obligations to get right. Therefore, a hashing strategy that is designed around the on-chain side of the equation and treats the off-chain storage as an afterthought has not reduced risk – it only moved it to another place.

Cryptographic commitments are the cleanest of the three mechanisms conceptually:

• store a commitment to a value on-chain,
• keep the original value and the witness needed to open that commitment off-chain, and
• once both are deleted, the commitment on-chain becomes genuinely useless, neither recoverable nor recognisable as related to any specific original value, provided the scheme used a properly hiding construction.

This is the closest the guidelines come to describing a technique that produces a real, durable dead end rather than a fragile, time-limited one. It is also the least mature and least deployed of the three in production blockchain systems today.

Proof of Existence: The EDPB’s Preferred Middle Ground

Where personal data absolutely must touch the chain, the guidelines converge on a specific recommendation: store on-chain only a form of the data intended to function as a proof of existence, meaning a pointer, a cryptographic commitment, or a hash generated through a keyed hash function, while keeping the data actually needed to verify that proof outside the blockchain entirely, under a high level of confidentiality.

This is a narrower and more disciplined version of “store it off-chain” than most organisations currently practise. It is about designing the on-chain artefact so that it never needs to carry more evidentiary weight than proving that something existed at a point in time.

There is one explicit exception the EDPB carves out: in some cases, a controller may genuinely need to make certain information public and accessible for a retention period equal to the life of the blockchain. Where that is true, storing personal data on a public blockchain in a directly identifiable form can be appropriate, but only if the purpose of the processing actually justifies it, and only where a DPIA has concluded that the resulting risks to data subjects have been properly addressed and mitigated.

What This Means for You

If your organisation is already running, or actively evaluating, a blockchain-based processing activity involving personal data, the practical takeaways from the final guidelines are fairly concrete:

• Treat the erasure and rectification strategy as an architecture decision made before the first transaction,
• If you are relying on hashing for confidentiality, check specifically whether it is salted or keyed, where the salt or key actually lives, who controls its deletion, and whether the off-chain system holding it has its own documented security measures and retention controls,
• Do not treat “the blockchain is permanent” as a retention justification. Document why the specific retention period you have chosen is necessary and proportionate to the purpose of the processing,
• If you are evaluating a permissionless or public blockchain for a new use case, be ready to explain why a permissioned architecture would not serve the same purpose.

Where White Label Consultancy Can Help

The guidelines are demanding because the underlying tension is real. Reconciling an append-only, tamperproof ledger with a legal framework built around correction and deletion means getting the architecture right at the design stage, documenting the reasoning behind every choice, and being honest about which solutions genuinely resolve risk versus which ones simply relocate it.

That is exactly the assessment we help clients work through before they build: whether blockchain is actually necessary, whether the proposed on-chain and off-chain architecture holds up against erasure, rectification, and storage limitation, and what the resulting DPIA needs to cover. We’d rather help you ask these questions now than answer them after a regulator does.

Schedule a call with us.