Brief overview: The GDPR requires data minimization, purpose limitation, transparency and data subject rights – blockchains rely on immutability, replication and openness. This is not necessarily a contradiction. With a clean architecture (off-chain-first, on-chain-minimum, commitments instead of plain text), precise role allocation (controller/processor/joint controllership), eIDAS-supported evidence and clear contractual and governance rules, the core obligations can be fulfilled. The article outlines practical patterns, typical errors and a checklist for projects that must be resilient in 2025.

Initial situation: reconciling GDPR obligations and technical features

The GDPR works with basic principles (Art. 5), legal bases (Art. 6, for special categories Art. 9), transparency and information obligations (Art. 13/14), technical and organizational measures (Art. 25, 32), as well as data subject rights (access, rectification, erasure, restriction, objection). Blockchains counter this with the properties of immutability, decentralized storage, verification by consensus and global replication. This results in classic areas of conflict:

• Data minimization versus complete, permanent storage.
• Deletion/rectification versus immutability.
• Accountability versus distributed governance and “no one is responsible”.
• International data flows (nodes worldwide) versus transfer regimes.

The solution rarely lies in “blockchain or GDPR”, but in the architecture: personal data does not belong on-chain as plain text, but in controlled off-chain storage; only minimally necessary anchors (hash/commitment, references, status markers) remain on-chain. This view has been supported and substantiated for years by European specialist bodies, including the CNIL with guidelines and practical recommendations for data protection-compliant blockchain use as well as studies by the European Parliament and the EU Blockchain Observatory. These emphasize: Permissioned architectures facilitate role and transfer control; in permissionless networks, compliance is more challenging but not impossible if personal content is replaced by suitable constructs (commitments, selective disclosure, cryptography). ( cnil.fr, European Parliament, EU Blockchain Observatory and Forum)

A further building block for legal connectivity is eIDAS 2: electronic ledgers are legally located as evidence infrastructure; qualified electronic ledgers enjoy a presumption of integrity and correct chronological order of their entries. This increases the evidential value of well-designed chains – but does not replace the GDPR obligations.(EUR-Lex, european-digital-identity-regulation.com, EY)

Architecture and technology patterns: off-chain first, commitments and selective disclosure

Off-chain first and on-chain minimum
Personal data is processed outside the blockchain in systems whose access, storage periods and deletions can be controlled (databases, object storage, WORM repos). Only verifying markers are stored on-chain: cryptographic hashes, Merkle root commitments, status IDs or token identifiers without any reference to a person. The hash serves as proof of immutability; the personal reference remains off-chain. CNIL explicitly recommends this separation – with the addition that permissioned networks facilitate governance. ( cnil.fr)

Pseudonymization instead of anonymization
Public keys, addresses, transaction IDs: In many constellations, these identifiers are personal data because they can be indirectly assigned to a natural person. This means: pseudonymization yes, true anonymization rarely. Architectures respond to this with changing keys, privacy enhancements (e.g. address rotation, payment codes), but above all by moving sensitive content off-chain. Studies and workshops (EU Parliament/EU Observatory) warn against false security: metadata alone is often sufficient for re-identification.(European Parliament, ResearchGate)

Commitments and proofs
Instead of publishing data itself, commitments are written: Hashes on structured data sets, Merkle trees, accumulated states. Subsequent disclosure is selectively possible (proof of inclusion, zero-knowledge proofs). The chain documents integrity and time; off-chain, the data is deleted, corrected or blocked in a controlled manner. This makes it possible to combine data minimization and interests in proof.

Selective disclosure and zero-knowledge
ZK proofs (e.g. zk-SNARKs) make it possible to prove properties of a date without disclosing the date: Age ≥ 18, address in country X, authorization Y. In practice, this is often combined with verifiable credentials: An issuer signs attributes; the holder only discloses the relevant attributes to a verifier, ideally with ZK random samples (range proofs, membership proofs). This allows identity and authorization checks to be carried out without central data storage.

Editing instead of “deletion on chain”
Where chains support editable structures (by governance decision, “redactable ledgers”/chameleon hashes), corrections are possible. Legal considerations must be taken into account: A technical overwrite is not mandatory; it is often sufficient that personal content was never on-chain or is effectively inaccessible due to cryptographic decoupling and deletion of off-chain data. The GDPR requires effectiveness, not necessarily bit deletion at every storage location.

Think about database and copyright
Many blockchain-supported registers contain protectable databases. Extractions, mirroring and miner/validator copies can affect rights. At the same time, copyright positions arise in smart contract code; the transfer of purpose (e.g. audit, fork, re-use) must be contractually regulated. These issues must be addressed in parallel with the GDPR.

eIDAS-supported proofs
Qualified time stamps and seals can be placed in front of the on-chain layer: Off-chain documents, logs and proof of status are signed/stamped in a qualified manner and the hashes are also written to a ledger. This creates a double cascade of evidence (trust service + ledger). eIDAS 2 gives qualified electronic ledgers a legal presumption of integrity/chronology.(EUR-Lex, european-digital-identity-regulation.com)

Data subject rights and “immutability”: practical solutions for access, rectification and erasure

Information (Art. 15)
Information obligations primarily concern off-chain inventories and logs. Data catalogs that refer to the off-chain storage for each on-chain reference (data lineage) are recommended. On-chain hashes are explained in the response without disclosing sensitive content. For distributed networks, it must be defined which body provides information (lead controller/coordination body, contractually defined).

Correction (Art. 16)
If a data record stored off-chain is incorrect, it is corrected there; the new version is given a new hash. A correction marker can be entered on-chain (e.g. “superseded by state X”). Plain text that is actually stored on the chain must be avoided; otherwise the only option is a correction marker plus prevention of further use by governance rules.

Erasure (Art. 17)
Erasure means effectively removing or rendering unusable. In blockchain architectures, personal content is therefore not written to the chain in the first place. Deletion routines must be defined as mandatory for off-chain stocks; on-chain references become unusable if the off-chain data record no longer exists or the decryption key has been destroyed (crypto-shred). CNIL and other bodies emphasize that permissioned environments with clear deletion and access obligations facilitate practical implementation.(cnil.fr)

Restriction/objection (Art. 18/21)
Restriction can be mapped as a “freeze” in the off-chain system; on-chain, a flag or a status change can be set to prevent further processing. In the event of an objection, it must be checked whether the legal basis was legitimate interests or consent; in the case of legitimate interests, the assessment must be updated and, if necessary, adjusted in favor of the data subject.

Data portability (Art. 20)
Portability refers to the data provided by the data subject. Technically, exportable off-chain profiles (machine-readable formats, APIs) can be provided; on-chain markers regularly play no role here. It is important that portability is not confused with an obligation to disclose trade secrets or third-party rights.

Special categories (Art. 9)
Health data, political opinions, biometric/genetic data have the strictest requirements. Such content does not belong in publicly accessible registers. Where processing is necessary (e.g. proof of authorization in health scenarios), zero-knowledge/selective disclosure and strong off-chain controls are mandatory.

Governance, roles, transfers: defining responsibility, managing international risks

Role model
In permissioned networks, one or more responsible parties can regularly be identified (consortium, operator, use case owner). Depending on the constellation, joint controllership is obvious (Art. 26) because decisions on purposes and means are made jointly. Validators/members can be involved as processors if they act in accordance with instructions. In permissionless networks, the assignment of roles is more difficult; constructions that design the specific service offered (e.g. a wallet or registry application) as an independent responsibility, while the underlying protocol is treated as “infrastructure”, are practicable. CNIL points out that a clear definition of responsibility is essential – “no one is responsible” is not a GDPR model.(cnil.fr)

Legal bases and DPIA
For many registry applications, legitimate interests come into consideration (Art. 6 para. 1 lit. f), in the case of identity/certificate processes possibly legal obligations or contracts. In high-risk scenarios, a data protection impact assessment is appropriate: systematic evaluation of the risks (re-identifiability, crypto key loss, chain forks, international replication) and the planned remedies (off-chain controls, CC evidence, access controls, audit).

International data transfers
Public chains replicate data globally, which triggers the rules for third country transfers. CNIL therefore recommends permissioned networks in which the node location can be controlled and contractually secured via standard contractual clauses/BCR. In public networks, this can hardly be comprehensively ensured; therefore, the following applies all the more: no personal content on-chain, only non-personal commitments.(cnil.fr)

eIDAS bridge and evidence
eIDAS 2 strengthens the legal effect of electronic ledgers. An electronic ledger must not be rejected as evidence simply because of its form; qualified ledgers are presumed to have integrity and correct chronological order. For forensic/compliance evidence, it makes sense to combine trust services (qualified timestamp/seal) with the ledger in order to obtain double anchors (trust service + chain).(EUR-Lex, european-digital-identity-regulation.com)

Typical contract modules

• Roles and responsibilities (Art. 26-Agreement/joint controllership; GCU according to Art. 28).
• Data categories, on/off-chain delimitation, retention, deletion, key life cycle (creation, rotation, destruction).
• Security and audit clauses, eIDAS Trust Services, evidence management (time stamp/seal, hash register), fork/incident rules.
• Third country transfers and node locations (only permitted), standard contractual clauses/BCR, sub-processor chains.
• Rights to smart contract code/databases, transfer of purpose, fork reuse rules.

Checkpoints/checklist (compact)

1. On-chain only commitments/states – no clear data, no “special categories”.
2. Off-chain storage with deletion/correction routines, access, logging, retention.
3. ZK/Verifiable Credentials for selective disclosure; address rotation/key hygiene.
4. Responsible party/AVV/joint controller agreement; DPIA with risk mitigation.
5. International: Control nodes and transfers or keep personal data completely off-chain.
6. eIDAS Trust Services + ledger as verification cascade.
7. Documentation: data catalog, policy stack, incident and key management.

Conclusion

GDPR-compliant blockchains are not a contradiction, but a question of design, governance and evidence discipline. Those who keep personal content strictly off-chain, use only verifying markers on-chain, enable selective disclosure and clearly regulate responsibilities resolve the classic conflicts of data minimization, deletion and internationality. eIDAS 2 provides the bridge to court-proof evidence: a clean mix of qualified time stamps/seals and electronic ledgers creates evidence that is technically viable and legally connectable. The decisive factor remains the proof in detail – corpus, keys, protocols, policies and contracts – not keyword compatibility.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.