Is Hashing a Document Compatible With GDPR?

Is Hashing a Document Compatible With GDPR?

Hashing a document does not take it outside the GDPR by itself. A SHA-256 hash is a one-way fingerprint of a file, and whether that fingerprint counts as personal data depends on three things: who holds it, what else they can get their hands on, and how easy the original would be to guess. For a long, unpredictable document, a hash is a sensible way to prove a file existed without revealing it. For a short form where only a name and a date change from copy to copy, the hash can work as a lookup key for anyone willing to try candidates.

So the honest answer is that hashing can be a good design choice that supports GDPR principles, but it is not a magic anonymiser. The rest of this piece explains where the line sits, using what EU regulators and courts have actually written.

The law doesn’t care about your algorithm

The GDPR never mentions hashing as a way out. What it does is define personal data broadly: any information relating to an identified or identifiable natural person (Article 4(1)). Recital 26 then tells you how to judge “identifiable”: look at all the means reasonably likely to be used, by the controller or by anyone else, to identify the person.

That test is about facts, not techniques. A hash isn’t inside or outside the GDPR by nature. It is inside when someone has a realistic way to link it back to a person, and outside when nobody does.

The Court of Justice made the same point years ago in Breyer (C-582/14, 2016). A dynamic IP address looks like meaningless numbers, but it can be personal data for a website operator if the operator has legal means to obtain the extra information that identifies the visitor. Opaque-looking data is not automatically safe.

Hashing is pseudonymisation at best, and often not even that

Article 4(5) defines pseudonymisation as processing data so it can no longer be attributed to a person without additional information, kept separately. Hashing a name is a textbook example. The GDPR is explicit that pseudonymised data remains personal data when it could be attributed to someone using that additional information.

Anonymisation is a much higher bar. It means identification is not reasonably likely for anyone. Most hashes of personal data never get there, and people often confuse the two.

What the EDPB says about hashes on a blockchain

This is the guidance most relevant to timestamping. The European Data Protection Board adopted the final version 2.0 of its blockchain guidelines on 7 July 2026, and they describe storing only a salted or keyed hash on-chain, with the original data and the secret key or salt held off-chain. They are equally clear that the GDPR still applies to that off-chain processing and that the hash is itself considered personal data. The same text adds that unsalted or unkeyed hashes should generally not be regarded as enough to protect personal data stored on a public blockchain.

Two other passages matter. The EDPB says that where personal data really must be referenced on a chain, it is better to do it in a form meant to work as a proof of existence, such as a pointer, a commitment, or a keyed hash, with the data needed to verify kept elsewhere under strong confidentiality. Elsewhere it warns that rectifying or erasing clear-text, encrypted or hashed data on a chain is hard, and advises against registering personal data in those forms at all, preferring off-chain storage.

Read together, the position is more nuanced than “hashing is fine” or “hashing is forbidden.” Hash-based proof of existence is the preferred shape when you must reference personal data. But the hash does not stop being personal data just because it is a hash, and keeping personal data off the chain is better still.

One thing worth noticing: all of this applies when the thing being hashed is personal data. If you timestamp an unpublished engineering drawing or a manuscript that identifies nobody, there is no personal data in the document for the hash to represent, and these passages have little to bite on. The separate question of what identifiers appear in the transaction metadata (account or wallet identifiers, for example) is one the EDPB also addresses, and it deserves its own look.

When a hash is just a lookup key

Here is the part most articles skip. SHA-256 cannot be run backwards, so nobody can “decrypt” a hash into the original file. But a hash can be confirmed by guessing. If I suspect what the input was, I hash my guess and compare.

A hypothetical example. A clinic timestamps a standard consent form with the patient’s name and the date filled in. The template is common knowledge, and only two fields vary. Anyone holding the template and a list of plausible names could generate candidate documents, hash each one, and see which matches. For that attacker, the hash is effectively a name tag.

Now take a sixty-page negotiation draft full of unpredictable prose. Guessing the exact bytes is not realistic. The hash reveals nothing useful to anyone who doesn’t already hold the file.

The practical idea is entropy: how much unpredictability the document contains. If your document is low-entropy and contains personal data, add randomness before hashing. One simple way is to put the file into an archive together with a file of random bytes, hash the archive, and keep that exact archive for later verification. A keyed hash (HMAC) does the same job in a more formal way. Either way, you are responsible for storing the secret part safely, because losing it means you can’t verify later.

Personal for you, perhaps not for everyone else

In September 2025 the CJEU decided EDPS v SRB (C-413/23 P). The Court rejected the view that pseudonymised data must always be treated as personal data for everyone, even when the person receiving it has no realistic means of re-identifying anyone. The same dataset can stay personal for the party holding the identifying key and be non-personal for a recipient who cannot get at it.

The EDPB built on this in its draft Guidelines 02/2026 on Anonymisation. They were adopted on 7 July 2026, and public consultation runs until 30 October 2026, so they are still a draft and could change. The direction of travel is that identifiability is assessed from the point of view of each party that might handle the data.

For hashes, this is helpful but not a free pass. Someone who only sees a hash on a public chain, with no file and no candidate list, probably cannot identify anyone. The person who holds the file can verify instantly, so for them the hash is tied to the document. But the blockchain guidelines were adopted the very same day and still say the hash is personal data. And on a public chain, “the recipient” could be anyone, including someone who happens to hold a good candidate list. You still have to run the assessment rather than assume the answer.

How this plays out with Certelo

Certelo’s design is relevant here because of where the hashing happens. The SHA-256 hash is generated locally in the browser, before any blockchain record is created, and the original file is not uploaded to Certelo merely to create the proof. What gets anchored to the Electra Protocol blockchain is the digest, not the document.

That has a few practical consequences under GDPR:

Minimisation and design:

The content of the document never reaches Certelo or the chain, which fits the data minimisation principle (Article 5(1)(c)) and data protection by design (Article 25).

Who decides:

If you timestamp a file containing other people’s data, you are the one deciding to process it, so you will usually be the party who needs a lawful basis, a purpose, and a retention plan. The hash does not supply any of those.

Erasure:

A blockchain record can’t be deleted. The route the EDPB describes is making the on-chain element non-linkable by erasing the off-chain material that would allow identification. In practice that means deleting the original file and any internal register tying that hash to a person. For an unpredictable document, that leaves a fingerprint pointing at nothing. For a guessable one, remember the section above.

Everything else Certelo holds:

Any account or payment details Certelo itself keeps are a separate matter, covered by its privacy policy rather than by anything said here.

Certelo’s record shows that a particular digital fingerprint existed at or before the recorded blockchain time. It does not by itself show who created the document, who owns it, or that the processing around it is lawful.

A short check before you timestamp

1- Does the document contain personal data at all? If not, most of this analysis falls away.

2- If it does, do you have a lawful basis and a defined purpose for timestamping it?

3- How guessable is the document? If it is a template with a few filled fields, add randomness first.

4- Who will hold the original, and for how long? Your retention rule is what makes later erasure realistic.

5- If your processing is likely to be high risk, are the blockchain-related risks in your DPIA?

6- Have you written down your reasoning? The accountability principle expects you to be able to show it.

What hashing cannot fix

Hashing is itself a processing operation when you run it on a file containing personal data. It does not give you a legal basis, tell data subjects what you’re doing, or set a retention period. It reduces exposure. It does not replace the rest of the compliance work.

A note on scope: this article discusses EU GDPR. The UK GDPR, the Swiss FADP and other regimes are similar in places and different in others, and national supervisory authorities may apply the guidance differently. This is general information, not legal advice. Anything involving real personal data and real risk deserves a conversation with a qualified privacy lawyer or your DPO.

To clarify

Is a SHA-256 hash of a file personal data?

It can be. If the file contains personal data and someone can reasonably link the hash back to a person, by holding the file or by guessing its contents, the hash is personal data in their hands. For a document with no personal data, the question usually doesn’t arise.

Can you reverse a hash to recover the document?

No. SHA-256 is a one-way function. What an attacker can do is hash guesses and compare, which is why predictable documents are a weak spot.

Is hashing the same as encrypting?

No. Encryption is designed to be reversed with a key. Hashing isn’t reversible. The EDPB treats both as measures that may still leave personal data in scope when the underlying data is personal.

Does the right to erasure apply to a hash on a blockchain?

If the hash is personal data in context, the right can apply, subject to the exceptions in Article 17. Since the on-chain record can’t be removed, the EDPB’s approach is to make it non-linkable by erasing the off-chain data.

Does Certelo upload my original file?

No. The hash is calculated locally, and the original file is not uploaded merely to create the proof.

Is a blockchain timestamp enough to make my processing GDPR-compliant?

No. A timestamp is evidence that a fingerprint existed at a given time. Lawful basis, transparency, minimisation and retention still have to be handled separately.