GDPR and Blockchain Timestamping: 2026 Compliance Guide

You want to timestamp contracts, HR files, customer exchanges to build solid evidence. Excellent idea. But one question always comes up: is this compatible with GDPR?

Short answer: yes, provided you understand a few simple principles. Long answer: you must distinguish data that stays off-chain (protectable, erasable, GDPR-compliant) from what gets inscribed on-chain (immutable, public, to be minimized).

The compliance secret fits in one word: hash. Inscribing only the document's fingerprint, never the content, is the foundation of a GDPR-compliant timestamping strategy.

GDPR and blockchain: the false debate

Many believe blockchain and GDPR are incompatible. They are not — provided usage is well-architected.

What CNIL says (French data protection authority — "Blockchain and GDPR" report, 2018, updated 2024):

Blockchain is not illegal under GDPR.
Inscribing raw personal data on a public blockchain is, however, strongly discouraged.
Inscribing a hash (fingerprint) is acceptable, provided the data linking that hash to a person is managed off-chain in a compliant environment.

What EDPB says (European Data Protection Board): hashes remain pseudonymized data under GDPR, not anonymized. This means they remain subject to GDPR, but pseudonymization is a risk-reduction factor (recital 28).

Pseudonymization ≠ anonymization

A hash is pseudonymized data: irreversible, but potentially re-identifiable if you have access to the source. True anonymization would be irreversible — hashing alone is not.

The 6 GDPR principles applied to timestamping

GDPR principle	Application to timestamping
Lawfulness (art. 6)	Clear legal basis (consent, legitimate interest, legal obligation)
Minimization (art. 5.1.c)	Inscribe only the hash, never the content
Storage limitation (art. 5.1.e)	Define a retention period for off-chain data
Integrity and confidentiality (art. 5.1.f)	The hash guarantees integrity; off-chain encryption ensures confidentiality
Right to erasure (art. 17)	Destroying off-chain data renders the on-chain hash inoperative
Accountability (art. 5.2)	Document architecture choices in the records of processing

Compliant architecture: on-chain vs off-chain

This is the heart of the matter. Here is the recommended architecture:

1
Off-chain document storage
The contract, HR file, or customer exchange is stored in your GDPR-compliant information system (encrypted server, access logs, defined retention).
2
Local hash computation
The SHA-256 hash is computed on the source file. This operation requires no transmission of the content to a third party.
3
Hash inscription on the blockchain
Only the hash (a 64-character hexadecimal string) is sent to the timestamping server and inscribed on the public blockchain. No identifying data is exposed.
4
Timestamp proof storage
The .ots file (or equivalent) is kept locally with the source document. The proof allows verifying integrity later.
5
Punctual verification
To verify a proof, you recompute the hash locally and compare. No transmission of content to third parties — verification stays confidential.

✓

The hash travels, the content stays

This architecture respects minimization (art. 5.1.c GDPR): you never send more than strictly necessary for the purpose (prior-art and integrity proof).

Right to erasure applied to blockchain

Article 17 GDPR gives any person the right to request erasure of their data. On a public blockchain, you cannot delete a transaction. How can you respect this right?

CNIL doctrine: erase what is erasable

If only a hash is inscribed on-chain, and the data linking that hash to the person is off-chain, then destroying that off-chain data renders the hash inoperative for identifying the person. The hash persists on the blockchain but becomes an orphan string of characters with no identifying value.

Recommended procedure:

The person exercises their right to erasure.
You identify the relevant files in your off-chain storage.
You destroy: the source file, the hash↔person correspondence key, the backups (per your policy).
You document the operation in your records of processing.
You inform the person that the on-chain hash persists but no longer allows tracing back to them.

Mind the backups

If you keep off-site backups, you must apply the erasure procedure to them too (or prove they will be purged within a reasonable timeframe per your policy).

The 4 typical use cases (and how to secure them)

Customer or supplier contracts

Off-chain: contract PDF, parties' identity, clauses, amounts.
On-chain: contract hash.
Precautions: retention aligned with accounting and commercial obligations (typically 6-10 years).

HR files (employment contracts, sanctions, payslips)

Off-chain: full content, in your GDPR-compliant HRIS.
On-chain: hash of each key document.
Precautions: retention per applicable employment law (typically 5+ years for payslips, career duration + several years for individual files).

Customer dispute evidence

Off-chain: email exchanges, screenshots, invoices.
On-chain: hash of each item.
Precautions: plan for erasure after dispute prescription (typically 3-6 years for civil claims).

Works with embedded personal data

Example: a photographer timestamping a model portrait.

Off-chain: original photo + signed image rights authorization.
On-chain: photo hash.
Precautions: if the model exercises their right to erasure (rare but possible), destroy the photo and the authorization. The hash becomes inoperative.

Special cases to know

eIDAS and GDPR

eIDAS (EU Regulation 910/2014, revised 2024) governs digital trust: electronic signatures, qualified timestamping, digital identity. GDPR governs personal data protection. Both apply in parallel.

A qualified eIDAS timestamp must be implemented in compliance with GDPR: minimization, legal basis, security, etc. The QTSP itself has GDPR obligations as processor or joint controller depending on architecture.

International transfers

If your timestamping service is hosted outside the EU (e.g., in the US), examine:

The legal basis for transfer (DPF, Standard Contractual Clauses).
Data actually transferred (is a hash alone a personal data transfer? subject to debate).
CNIL recommendations on post-Schrems II transfers.

European services or on-premise solutions minimize this risk.

Sensitive data (Article 9 GDPR)

Health data, political opinions, sexual orientation, etc.: processing strictly framed by Article 9 GDPR. Hash-based timestamping remains possible, but the legal basis and security measures must be reinforced (explicit consent, strong encryption, restricted access).

Records of processing activities (Article 30)

If you implement regular timestamping, integrate it into your GDPR records. Sample entry:

text

Purpose: Timestamping documents for prior-art and integrity proof
Legal basis: Legitimate interest (securing contractual evidence)
Data categories: SHA-256 hash of documents potentially containing personal data
Data subjects: Customers, employees, suppliers (depending on document)
Recipients: Timestamping service [name], public blockchain [name]
Retention period: On-chain hash (unlimited), off-chain data (per business policy)
Security measures: Hash-only on-chain, off-chain encryption, restricted access
Erasure procedure: Destruction of off-chain data on request

Mistakes to avoid

Inscribing a name, email or identifier on the blockchain → Personal data inscribed irreversibly. Major GDPR risk.

Storing a complete file (even encrypted) on public IPFS → Encryption is not anonymization. A compromised key makes all content readable.

Forgetting to mention timestamping in the privacy policy → People must be informed about data processing.

Believing the hash anonymizes → The hash pseudonymizes. It remains personal data if re-identification is possible.

Not planning for erasure → Without a documented procedure, you are non-compliant the moment the first erasure request arrives.

Confusing technical compliance with legal compliance → A technically flawless architecture does not exempt you from records, information notices, or consent when required.

GDPR compliance checklist for timestamping

Legal basis identified and documented (consent, legitimate interest, legal obligation)
On-chain architecture limited to hashes (never raw content)
Off-chain data stored in a GDPR-compliant environment (encryption, access logs)
Off-chain retention period defined and enforced
Erasure procedure documented (off-chain destruction → hash inoperative)
Mention in records of processing activities (art. 30)
People informed in the privacy policy
DPIA performed if high-risk processing (art. 35)
Processors (QTSP, timestamping provider) under art. 28-compliant contract
International transfers framed (Standard Contractual Clauses, DPF)

FAQ

Yes, provided you only inscribe hashes (fingerprints) and not raw personal data. The hash is considered pseudonymized data per CNIL doctrine (2018 blockchain report, updated 2024) and EDPB guidance.

You cannot erase a transaction on a public blockchain. But if you only inscribe a hash, effective erasure consists of destroying the off-chain data that links that hash to a person (correspondence key, source file).

According to CNIL and EDPB, a hash of personal data remains personal data if it allows indirect identification. Pseudonymization is not anonymization. Compliance relies on the security of the data enabling re-identification.

Yes, provided you only send the document's hash to the blockchain. The contract itself stays local or in a GDPR-compliant system. The timestamp proof reveals nothing about the content.

CNIL published a report in 2018 (updated 2024) recognizing blockchain as a legitimate tool, provided only minimized data (hashes, references) is inscribed. It recommends off-chain timestamping for raw personal data.

Not systematically. A DPIA is required if processing presents a high risk to rights and freedoms (Article 35 GDPR). Hash-only timestamping generally presents low risk and does not require a specific DPIA.

Destroy the off-chain data that allows reconstituting the hash ↔ person link (source file, correspondence base). The on-chain hash then becomes inoperative for identifying the person. Document the procedure in your records of processing.

No. eIDAS and GDPR are two complementary regulations. A qualified timestamp benefits from a legal presumption, but must be implemented in compliance with GDPR when personal data is involved.

Conclusion

GDPR and blockchain timestamping are not in opposition, they are complementary — provided you respect a simple design rule: on-chain only hashes, off-chain everything else, and a documented erasure procedure.

This architecture, recommended by CNIL, allows you to combine the benefits: solid prior-art proofs, verifiable integrity, and demonstrable GDPR compliance. All without giving up either blockchain robustness or your contacts' right to erasure.

Building this yourself takes time: hash-only architecture, records of processing, erasure procedure, art. 28-compliant processor contracts, international transfer framework, audit log. Doable, but a real project.

LegalStamp embeds this compliance by design: only the hash on-chain, off-chain data encrypted and EU-hosted, documented erasure procedure, pre-filled records of processing, art. 28-compliant subprocessing. You keep the legal benefit of blockchain without the GDPR risk.

Disclaimer (general information): this article is provided for educational purposes and does not constitute legal advice. GDPR compliance always depends on the precise context of processing and the analysis of a DPO or specialized lawyer. For high-risk processing, a DPIA and professional support remain essential.

GDPR and Timestamping: What Your Digital Evidence Must Comply With