EDPB blockchain and GDPR guidelines: what they change for your digital evidence

On 8 July 2026, the European Data Protection Board (EDPB) adopted the final version of its guidelines on processing personal data through blockchain technologies. The text was overdue: since distributed ledgers took off, one question kept going unanswered: how do you reconcile a database designed to be immutable with a regulation that enshrines the right to erasure?

For anyone who uses blockchain for proof (timestamping, anchoring priority, verifiable archiving), these guidelines deserve close reading. They do not condemn the technology. They draw a clear line between a risky use and a controlled one. And that line matches, almost exactly, how a well-designed timestamp works.

What the EDPB actually adopted

The EDPB is the body that brings together the data protection authorities of the Union, including France's CNIL. Its guidelines are not a regulation, but they carry weight: national regulators rely on them to assess whether a processing operation is compliant.

The document, titled Guidelines 02/2025 on processing of personal data through blockchain technologies, first explains how the different architectures work (public, private, permissioned or not), then draws the consequences under the General Data Protection Regulation.

Three messages run through the text.

Message 1: do not put personal data on the chain

This is the most direct recommendation. The EDPB writes that "in general, it is not advisable to store personal data on the blockchain, and it should not be stored in the content of transactions."

The reason is as much technical as legal. A blockchain is append-only: you add, you do not erase. That property, which makes it powerful for proof, collides head-on with two rights guaranteed by the GDPR:

• the right to erasure (Article 17),
• the right to rectification (Article 16).

As the EDPB notes, "the append-only and ever-growing nature of a blockchain challenges the data minimisation principle," all the more so because the data is replicated across many nodes. You cannot promise a person the erasure of their data if that data is written to thousands of immutable copies.

Message 2: anchor only a cryptographic commitment

Since the data itself must not appear on the chain, what can you publish there? The EDPB's answer is a cryptographic commitment: a fingerprint that represents the data without revealing it.

The text is explicit. It recommends "protecting the confidentiality of the original data by putting only the commitment on-chain, while storing the original data off-chain. This will allow the use of the blockchain for proving the integrity of the commitment."

Concretely, this describes exactly how fingerprint-based timestamping works: you compute the SHA-256 hash of a file, you anchor that hash, and the file stays with its owner. The chain proves that a fingerprint existed on a given date; it does not store any content.

Message 3: justify the use of blockchain, and document it

The third axis is a methodological requirement. The EDPB recalls that "the choice of this technology among others has to comply with the necessity principle enshrined in the GDPR" and that "it is thus important to document why this has been chosen."

Where required, this assessment must appear in a Data Protection Impact Assessment (DPIA, Article 35 GDPR). The controller must be able to answer simple questions: does the data written to the chain contain personal information? Is the level of publicity of the chain justified? Have the risks to individuals been addressed?

What it proves, what it does not

Beware of an over-enthusiastic reading. These guidelines do not declare that "blockchain is GDPR-compliant." They say the opposite: blockchain creates specific risks that must be neutralised through a careful architecture.

Two caveats are worth repeating.

Moreover, following the EDPB's logic on anchoring does not, by itself, cover all GDPR obligations (informing individuals, legal basis, retention period for off-chain data, security). Timestamping handles the "integrity and priority" link; it is not a substitute for full compliance.

Where does LegalStamp fit in?

LegalStamp's architecture matches, point by point, what the EDPB recommends.

• The SHA-256 hash is computed locally in your browser: the file never leaves your machine, only the hash is transmitted. The original data stays off-chain, by design.
• Only that fingerprint is anchored to the Bitcoin blockchain, via OpenTimestamps. The chain receives neither the content nor a nominative identifier, only a cryptographic commitment, exactly the use the EDPB describes.
• The receipt produced serves to prove the integrity and priority of the fingerprint, not to store any personal data.

In other words, the privacy by design we have applied from the start was never a marketing line: it is how a blockchain anchor must be built to stay compatible with the GDPR. You can check how it works on our how it works page and read our privacy policy.

One honest note remains: LegalStamp is a non-qualified timestamping service under eIDAS. Article 41(1) of the eIDAS regulation prohibits denying legal effect to a timestamp solely because it is not qualified, but the reliability of the method is assessed case by case by the court.

Conclusion

The EDPB guidelines of 8 July 2026 clarify a debate that had lingered: blockchain is not incompatible with the GDPR, provided you never write personal data to it and settle for anchoring a fingerprint, with the data kept off-chain. That is the very definition of hash-based timestamping.

For controllers, the practical message is simple: separate proof of integrity (a fingerprint is enough) from the storage of content (which has no place on a public chain). Done well, that distinction turns a source of risk into a compliance tool.

FAQ

Disclaimer: this article is provided for informational and educational purposes. It does not constitute legal advice. To assess the GDPR compliance of a processing operation involving blockchain, have your analysis validated by a legal professional or your data protection officer.