# Blockchain and GDPR: Immutability, Roles and Data Subject Rights

Canonical URL: https://xpertdpo.com/blockchain-and-gdpr-immutability-roles-data-subject-rights/

Content type: Article

Published: 2026-06-25T22:44:19+01:00

Updated: 2026-06-25T22:50:11+01:00

Author: Philipa Jane Farley, Head of Legal and Operations

Summary: Practical CPD guidance for DPOs on blockchain and GDPR risks, including immutability, on-chain and off-chain data, controller roles, erasure, access and governance evidence.

## Article

*This article accompanies Hour 5: Blockchain, Biometrics and Emerging Technology under GDPR in our full-day CPD programme on [XpertAcademy](https://xpertacademy.com/cpd-event-b-ai-technical/). Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: [CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training](https://xpertacademy.com/cpd-event-b-ai-technical/).*

 A consortium proposes a blockchain identity record for credential verification.

 The idea is attractive. Universities, training providers and employers could verify qualifications without waiting for manual checks. Individuals could present a credential. A verifier could confirm that the credential was issued by a trusted body and has not been revoked. The project team says the ledger will be tamper-resistant, decentralised and efficient.

 The DPO's first question should be quieter and more practical:

 What exactly is going on-chain?

 In blockchain projects, the privacy risk is often set by early architecture decisions. If personal data, stable identifiers, credential details, hashes, public keys or revocation events are placed into an immutable or widely replicated ledger, later GDPR compliance becomes much harder. The organisation may not be able to rely on ordinary deletion, correction or access workflows. It may also be unclear who is controller, joint controller or processor across the network.

 The goal is not to reject every distributed ledger proposal. The goal is to prevent a privacy problem being designed into the system before anyone has written the DPIA.

### The governance issue in plain language

 Blockchain and distributed ledger designs can create tension with GDPR because they are often built around persistence, replication, traceability and shared validation. Those design features may support integrity, auditability and trust. They can also make data minimisation, storage limitation, accuracy, erasure, access and accountability more difficult.

 For a DPO, the central questions are practical:

- Is any personal data processed on-chain?
- Could a ledger address, public key, hash, transaction record or credential status be linked to an identifiable person?
- What personal data sits off-chain and how is it connected to the ledger?
- Who decides the purposes and means of processing?
- Who can write, read, validate, operate nodes, govern rules or change the protocol?
- How will data subject rights be handled if records are immutable or replicated?
- Is blockchain necessary, or would a conventional database, signed credential or trusted registry meet the purpose with less risk?

 The DPC guidance on personal data is a useful reminder that personal data includes information about a living person who is identified or identifiable, and that pseudonymised information can still be personal data if identification is reasonably possible using additional information. In blockchain projects, that means the privacy team should be cautious about claims that a hash, key or wallet address is "not personal data" without a proper identifiability analysis.

### Worked scenario: credential verification consortium

 Assume a consortium of training providers and employers wants to issue and verify professional credentials. The proposed design has four actors:

- issuers, such as training providers, who create credentials;
- holders, who receive and present credentials;
- verifiers, such as employers or clients, who check credentials;
- a consortium operator, which maintains governance rules and technical infrastructure.

 The initial technical proposal says that the blockchain will record a credential identifier, issuer identifier, holder public key, issue date, revocation status and a hash of the credential content. The full credential document, including the person's name, course, date and result, will be stored off-chain in a credential wallet and issuer database.

 The project team says no personal data will be on-chain because names and documents are off-chain. The privacy team is not ready to accept that yet.

 The facts known at the start are:

- the system is designed to verify credentials about identifiable individuals;
- the holder's public key may be stable across credentials;
- the issuer and credential identifier may reveal education, employment or professional status;
- revocation status may reveal that a credential has been withdrawn or expired;
- off-chain systems contain direct personal data;
- verifiers may keep logs of checks;
- the consortium will set rules for participation and operation.

 The unknowns are material:

- whether the public key or credential identifier can be linked to the holder by issuers, verifiers or others;
- whether the ledger is public, permissioned, private or otherwise restricted;
- who operates nodes and where copies of the ledger are held;
- whether hashes could be used to confirm that a person holds a specific credential;
- whether revocation events expose sensitive or damaging information;
- how correction and erasure requests would be handled;
- who is responsible for responding to access requests;
- whether the system could work without putting holder-linked information on-chain.

 The decision question is therefore:

 Can the consortium meet the credential verification purpose while keeping personal data off-chain, minimising linkable on-chain records, defining roles clearly and preserving workable rights-handling controls?

### On-chain and off-chain data

 The most important architectural move is to separate what must be on-chain from what can be kept off-chain.

 In the credential scenario, full credential documents should not be placed on-chain. Names, dates of birth, course results, employment history, identity documents, addresses and special category data should not be made immutable and replicated across a ledger unless there is a very strong, evidenced reason. In most practical verification systems, that reason will be difficult to establish.

 The harder question is whether "only a hash" or "only a public key" is safe. A hash of personal data may still be personal data where it can be linked back, used to confirm the presence of a known record, or combined with other information to identify someone. A public key or address may become personal data where it is associated with a holder, especially if reused across contexts. Revocation events may reveal information even if the name is not visible.

 The DPO should ask the technical team to produce a data classification table:

 | Data element | Proposed location | Could it relate to an identifiable person? | Privacy position |
| --- | --- | --- | --- |
| Holder name | Off-chain credential wallet and issuer record | Yes | Keep off-chain; apply ordinary retention, access, correction and deletion controls. |
| Credential document | Off-chain | Yes | Keep off-chain; avoid ledger storage; secure holder-controlled presentation where possible. |
| Holder public key | On-chain or in verification flow | Possibly, depending on reuse and linkability | Avoid stable reuse where possible; assess identifiability and rotation options. |
| Credential hash | On-chain | Possibly, if used to test known credentials or link records | Treat cautiously; consider salted or alternative designs; document identifiability analysis. |
| Revocation status | On-chain | Possibly, especially if linked to a holder or credential type | Minimise detail; consider privacy-preserving revocation design. |
| Verification logs | Off-chain with verifier and operator | Yes or potentially yes | Define retention, access, purpose and rights handling. |

 This table does not answer every legal question. It gives the DPO and technical team a shared view of the problem.

### Roles cannot be left to the protocol

 Blockchain projects often blur responsibility. The technology may be distributed, but accountability still needs names.

 The consortium should decide who determines the purposes and essential means of processing. Issuers may be controllers for issuing credentials. Verifiers may be controllers for checking credentials in their recruitment, onboarding or compliance processes. The consortium operator may be a processor for some functions, a controller for others, or part of a joint controller arrangement if it helps determine essential purposes and means. Node operators may also need role analysis depending on what they do, what data they process and whether they exercise meaningful influence.

 Those roles should not be guessed after launch. They should be documented before personal data is processed.

 The privacy team should ask:

- who decides what data is written to the ledger;
- who decides who may join the network;
- who sets verification rules, retention rules and revocation rules;
- who can change the protocol or smart contract;
- who operates infrastructure and has access to logs;
- who receives and answers data subject requests;
- who handles complaints, incidents and regulator contact;
- what happens if a member leaves the consortium.

 EDPB controller and processor guidance is useful here because it focuses on who determines purposes and means in practice. Contract labels are not enough if the operational reality points elsewhere.

### Data subject rights

 The most difficult rights issues are usually access, rectification, erasure and objection.

 For access, the individual may want to know what credential-related personal data is processed, who has checked the credential and what on-chain records relate to them. If the system cannot map the person's identity to ledger records in a controlled way, it may struggle to respond. If it can map them, that mapping is itself a privacy risk that needs governance.

 For rectification, the organisation must avoid a design where incorrect credential information is permanently visible. If full credentials are off-chain, correction may be possible in the issuer database and wallet. If credential details are on-chain, correction becomes much harder and may rely on adding a new record that leaves the old incorrect one visible.

 For erasure, the usual warning applies: do not put personal data on-chain unless the organisation has a credible rights-handling position. Some designs claim that erasure can be achieved by deleting off-chain data, deleting keys, revoking access or rendering data practically inaccessible. Those controls may be relevant, but they are not a simple answer in every case. The decision depends on the data, the architecture, the identifiability position, the legal basis, the right invoked and the technical facts.

 For objection, the consortium needs to understand whether a holder can use an alternative verification route if they object to ledger-based processing, and whether the processing is necessary for a contract, legal obligation, public task or legitimate interests position.

 The rights design should therefore be built before launch:

 | Right or issue | Practical design question | Evidence needed |
| --- | --- | --- |
| Access | Can the controller identify all records relating to a holder without exposing other holders? | Rights workflow, search method, controller responsibility map and response template. |
| Rectification | Can incorrect credentials be corrected without leaving misleading records in use? | Correction workflow, revocation/reissue process and verifier update route. |
| Erasure | What data can be deleted, rendered inaccessible, de-linked or retained with lawful justification? | Erasure position paper, off-chain deletion evidence, key management design and legal review. |
| Objection | Can the individual use an alternative route or opt out where required? | Lawful basis analysis, alternative process and transparency wording. |
| Transparency | Can holders understand who processes what, where and why? | Layered privacy notice, issuer/verifier wording and consortium governance summary. |

### The practical alternative test

 A blockchain proposal should include an alternatives assessment. This is not hostility to the technology. It is necessity and proportionality work.

 For credential verification, the team should compare at least three options:

1. a conventional central registry with access controls and audit logs;
2. digitally signed credentials held by the individual, with verification against issuer keys and off-chain revocation;
3. a distributed ledger with minimised on-chain records and off-chain personal data.

 The DPIA should explain why the preferred option is necessary and proportionate. If the main benefit is tamper-evidence, a signed credential may be enough. If the main benefit is multi-party trust without a single operator, a permissioned consortium design may be worth exploring. If the main benefit is marketing language around blockchain, the privacy risk is unlikely to be justified.

 The DPO should be especially cautious where a public or permissionless blockchain is proposed for identifiable or linkable personal data. Public availability, replication and long-term persistence can make ordinary GDPR controls very difficult.

### Governance evidence

 The consortium should retain a governance pack before launch.

 At minimum, it should include:

- a DPIA or documented assessment;
- an architecture diagram showing on-chain and off-chain data;
- a data classification and identifiability analysis;
- a role mapping note for issuers, verifiers, operator, node operators and vendors;
- lawful basis and transparency analysis;
- rights-handling workflows for access, correction, erasure and objection;
- retention and deletion rules for off-chain records, logs, keys and backups;
- security and key management evidence;
- smart contract or protocol change-control process;
- incident and breach response route;
- member onboarding and offboarding rules;
- residual risk record and sign-off conditions.

 For the credential scenario, a sensible decision might approve a design where full credentials and direct identifiers are off-chain, holder keys are rotated or scoped where feasible, revocation data is minimised, verification logs are retained for a defined period, roles are contractually documented, and individuals have a non-ledger verification alternative where appropriate. It might reject any design that places names, credential content or permanent holder identifiers on a public ledger.

 That decision should be documented before any live credential is issued.

### What the DPO or privacy team should check

 Use a checklist that keeps the architecture honest:

- Is blockchain necessary for the purpose, or would a simpler architecture achieve the same result with less privacy risk?
- What personal data, identifiers, pseudonyms, hashes, keys, signatures, metadata and logs are processed?
- Which elements are on-chain, off-chain, in wallets, in verifier logs, in issuer databases and in operator systems?
- Could any on-chain element be linked to an identifiable person by the controller, another participant or a reasonably likely third party?
- Is the ledger public, private, permissioned or permissionless, and who can read, write, validate or copy records?
- Who determines purposes and essential means, and how are controller, joint controller and processor roles evidenced?
- What lawful basis and transparency position applies to issuance, verification, revocation, logging and consortium governance?
- How will access, rectification, erasure, restriction and objection be handled in practice?
- What data can be deleted, what can only be de-linked or made inaccessible, and what must be retained?
- What security controls apply to keys, wallets, nodes, smart contracts, APIs and off-chain databases?
- What happens when a member leaves, a credential is revoked, a key is compromised or a protocol changes?
- What residual risk is accepted, by whom and for how long?

 If the team cannot answer these questions, the project is not ready for privacy sign-off.

### Review triggers

 Blockchain projects should be reviewed when the design or governance changes.

 Reopen the assessment if the ledger type changes, new data elements are added, public access expands, a new participant class joins, credential types become more sensitive, revocation design changes, keys become reusable across contexts, off-chain storage changes, a vendor or node operator changes, verification logs are reused for analytics, smart contracts are upgraded, a new jurisdiction is added or data subject rights requests expose gaps in the workflow.

 The review should ask whether the original minimisation and rights-handling assumptions still hold. In blockchain projects, small technical changes can have long consequences.

### What this means for CPD

 For CPD purposes, the lesson is not that blockchain is always incompatible with GDPR. That would be too blunt. The practical lesson is that distributed ledger design choices must be tested before they become irreversible.

 A DPO or privacy lead should be able to separate the trust claim from the data protection evidence. What is immutable? What is replicated? What is linkable? Who is responsible? How are rights handled? What simpler alternatives were considered? What residual risk remains?

 Those questions make the difference between a blockchain project with privacy by design and a ledger that preserves a compliance problem beautifully.

 *This article is intended to support the learning covered in Hour 5 of our [XpertAcademy](https://xpertacademy.com/cpd-event-b-ai-technical/) CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: [CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training](https://xpertacademy.com/cpd-event-b-ai-technical/).*

### Sources

- European Data Protection Board, Guidelines 02/2025 on processing of personal data through blockchain technologies: [https://www.edpb.europa.eu/public-consultations/guidelines-022025-on-processing-of-personal-data-through-blockchain_en](https://www.edpb.europa.eu/public-consultations/guidelines-022025-on-processing-of-personal-data-through-blockchain_en)
- European Data Protection Board, Guidelines 02/2025 PDF: [https://www.edpb.europa.eu/system/files/2025-04/edpb_guidelines_202502_blockchain_en.pdf](https://www.edpb.europa.eu/system/files/2025-04/edpb_guidelines_202502_blockchain_en.pdf)
- Data Protection Commission, What are personal data and when are they processed?: [https://www.dataprotection.ie/en/dpc-guidance/what-is-personal-data](https://www.dataprotection.ie/en/dpc-guidance/what-is-personal-data)
- European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR: [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en)
- European Data Protection Board, Guidelines 01/2022 on data subject rights – Right of access: [https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202201_data_subject_rights_access_v2_en.pdf](https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202201_data_subject_rights_access_v2_en.pdf)
- EUR-Lex, Regulation (EU) 2016/679, including Articles 12 to 17 and Article 35: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

 Publication verification notes:

- EDPB Guidelines 02/2025 blockchain page re-checked on 2026-06-25. The page showed the public consultation as closed. Confirm whether a final post-consultation version has been adopted before publication.
- DPC personal data guidance re-checked on 2026-06-25. It is used here for the general point that identifiability and pseudonymisation require contextual assessment.
- EDPB controller/processor and access-right sources should be re-opened before publication if detailed legal wording is added.

## General Information Only

This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation.

If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/