Keep People and Documents Off the Chain: What the EDPB's July 2026 Guidelines Mean for an EU Issuer's Register

Executive Summary

The European Data Protection Board adopted the final version of its blockchain guidelines on 7 July 2026. The practical rule for an EU issuer is short: keep personal data off the ledger, and do not assume a hash or encryption fixes that. The Board says a salted or keyed hash is still personal data, and that clear text, encrypted and hashed personal data should all be stored off-chain.

That leaves a workable design. The ledger holds pseudonymous subject identifiers, balances and rule outcomes. The table that links a subject to a person stays in a system the issuer controls, where it can be corrected or erased. Two developments that might have loosened this have not: a September 2025 Court of Justice judgment helps recipients of pseudonymised data, not the party holding the key, and the Digital Omnibus proposal to rewrite the definition of personal data is still in negotiation.

Key Takeaways

• The EDPB adopted Guidelines 02/2025 on blockchain, version 2.0, on 7 July 2026. The first version dates from 8 April 2025.
• The final text says it is not advisable to record clear text, encrypted or hashed personal data on a chain.
• Wallet addresses and other on-chain metadata can be personal data when they enable identification of a natural person.
• In EDPS v SRB (C-413/23 P, 4 September 2025) the Court held that pseudonymised data is not automatically personal data for every recipient. The case went back to the General Court.
• The Digital Omnibus (COM(2025) 837) would add a relative test to Article 4(1) GDPR and delete Article 36 of the Data Act. On 1 August 2026 the Council had no mandate and Parliament had over 1,750 amendments.
• Retention duties pull the other way: MiCA and the Anti-Money Laundering Regulation require five-year records. Those records belong off-chain.

First, What Counts as Personal Data on a Chain

GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable natural person, including by reference to an identifier such as a name, an identification number or an online identifier. Recital 26 adds that identifiability depends on all the means reasonably likely to be used, by the controller or another person, judged by cost, time and available technology. Article 4(5) defines pseudonymisation as processing so that data cannot be attributed to a person without additional information kept separately under safeguards. The EDPB’s guidelines make three points for an issuer.

Addresses can be personal data. The Board says a public key used as an identifier is personal data if it can be used to identify an individual by means reasonably likely to be used, and gives a data breach as an example. In a footnote it adds that wallet addresses, event logs, receipts, state transitions and smart contract storage may all constitute personal data when they enable direct or indirect identification.

Replacing an identifier does not remove the problem. Where cryptographic tools hide identifiers, the data replacing them may still be personal data.

Hashing does not take you out of scope. The Board says a salted or keyed hash of personal data is still personal data, even though the original sits off-chain, and that unsalted or unkeyed hashes should in general not be considered sufficient on a public blockchain. In the data subject rights section it goes further: because rectification and erasure are hard to grant when clear text, encrypted or hashed data is on a chain, it is not advisable to register personal data in those forms there.

What Can Sit on the Ledger

The table below maps the guidelines onto the choices an issuer actually faces. The right-hand column is our reading of how each choice behaves under the Board’s text.

The Board leaves one door open: if the purpose justifies it and a data protection impact assessment concludes the risks are addressed, identifiable data may go on a public chain where it must stay public for the life of the chain. For an issuer’s holder register, we cannot see that purpose, and the guidelines favour permissioned chains.

What the SRB Judgment Changes, and What It Does Not

On 4 September 2025 the Court of Justice decided EDPS v SRB (C-413/23 P). The Single Resolution Board had pseudonymised shareholder and creditor comments before passing them to a consultancy, keeping the identifying key to itself. The Court’s holdings, in brief:

• Pseudonymisation reduces the risk of attributing data to a person; it does not by itself make data anonymous (paragraphs 72 to 73).
• For a recipient, pseudonymised data need not be personal data if the recipient cannot lift the measures and cannot attribute the data to a person, including by cross-checking with other factors (paragraphs 77 and 86).
• The party that holds the additional information is in a different position. For the Board in that case, the comments remained personal (paragraph 76).
• Where a third party may have means reasonably likely to re-identify, the person is identifiable for that transfer and for later processing by that party (paragraph 85).

Three cautions. The case concerned Regulation 2018/1725, the rules for EU institutions, though the Court worked from a recital that tracks GDPR recital 26. The Court set aside the General Court’s judgment and sent the case back, so the facts are not finally decided. And the EDPB’s final guidelines, adopted 10 months later, are what a supervisor will read; we found no reference to the SRB judgment in their text.

By our reading, the judgment does little for a ledger issuer. The issuer or its register-keeper holds the key table, so on the SRB logic the subject identifiers are personal data in its hands. Whether a reader of the ledger could re-identify a holder depends on what else they can see, and paragraph 85 treats the person as identifiable where re-identification cannot be ruled out. The design target stays the same.

The Digital Omnibus: Proposed, Not in Force

The Commission proposed the Digital Omnibus on 19 November 2025 as COM(2025) 837. Two parts touch this topic.

Article 4(1) GDPR. The proposal adds that information is not necessarily personal data for every entity merely because another entity can identify the person, that it is not personal for an entity that cannot identify the person with means reasonably likely to be used by it, and that it does not become personal merely because a later recipient could. In February 2026 the EDPB and the EDPS issued Joint Opinion 2/2026 strongly urging the co-legislators not to adopt the change to the definition, saying it goes beyond the case law and would significantly narrow the concept. The opinion also covers a proposed Article 41a, under which the Commission could adopt implementing acts on when pseudonymised data stops being personal data for certain entities.

Article 36 of the Data Act. The proposal deletes it. The Commission’s recital 16 says the article’s requirements for smart contracts executing data-sharing agreements, including a safe termination or interruption mechanism, are unclear and potentially incompatible with public blockchain architectures built on immutable ledgers. By our reading, the article targets data-sharing agreements, not token registers, so deleting it would not change the analysis here.

Status. The Parliament’s Legislative Train page, updated 1 August 2026, reports that the vote to approve the Council’s negotiating mandate, scheduled for 26 June, was cancelled because agreement on some open issues could not be found, and that work continues under the Irish Presidency. In Parliament the co-rapporteurs’ draft report of 22 June 2026 proposed no key amendments on the definition of personal data, and more than 1,750 amendments were tabled. We found no later official update. Plan on the GDPR as written.

Erasure: Design It In, Do Not Promise It Later

Article 17 GDPR gives a data subject the right to erasure without undue delay on defined grounds, for example where the data is no longer necessary for its purpose or has been unlawfully processed. Article 17(3)(b) excludes processing necessary to comply with a legal obligation. Article 25(2) says personal data must not be made accessible by default to an indefinite number of people.

The EDPB says the rights to erasure and to object must be met by design, that deleting data stored directly on a chain may be technically impracticable, and that technical impossibility cannot justify non-compliance. Its answer: personal data on the chain must be capable of being rendered anonymous. The on-chain data must not allow direct identification, and any off-chain data allowing indirect identification by means reasonably likely to be used must be erased. If a chain’s strong integrity is not needed, it recommends other tools.

Read together, the design pattern is:

1. Put nothing on the chain that identifies a person alone. No names, no ID numbers, no encrypted or hashed versions of them.
2. Key the ledger to a pseudonymous subject. Balances, lots and rule outcomes attach to the subject, not to a name.
3. Hold the link in one controlled place. The table that maps subject to person lives off-chain, under the issuer’s access controls, where it can be corrected, restricted or deleted.
4. Make deletion of that table do the work. Afterwards the ledger entry should not be linkable to the person. The EDPB notes the cost: the anonymised entry loses its original meaning but still supports the integrity of the rest of the chain.
5. Prevent re-linking. The guidelines say linking an existing transaction to future ones by the same person should be prevented, which argues against publishing address-to-person mappings.
6. Document retention periods. The life of the blockchain is not an appropriate default.

Erasure is not absolute. Where a law requires retention, Article 17(3)(b) applies and the data stays, off-chain. MiCA Article 68(9) requires crypto-asset service providers to keep records of all services, orders and transactions for five years, up to seven if the authority asks; Article 76(15) sets five years for trading-platform order data. The Anti-Money Laundering Regulation, (EU) 2024/1624, applies from 10 July 2027 and requires five-year retention of customer due diligence documents after the business relationship ends, not redacted (Article 77). Under the DLT Pilot Regulation, a CSD running a DLT settlement system with an exemption from securities-account rules must still record the instruments on the ledger, match issue totals, and keep records that let it segregate each participant’s, issuer’s and client’s instruments (Article 5(2)). None of these provisions asks for names on the chain. They ask for records, which can sit in the issuer’s or operator’s systems.

Who Is the Controller

The GDPR defines the controller as the party that alone or jointly determines the purposes and means of the processing. The EDPB says roles on a blockchain need a factual assessment of the service provided, the governance mechanism, the technical and organisational features and the relationships between actors. It says that permissioned chains give a clearer allocation of responsibilities and that organisations should favour them.

For an issuer, three practical consequences follow, all by our reading.

• The issuer, or the register-keeper it appoints, is the likely controller for holder data. It decides why the data is collected and what the register is for. Write that into the offering documents and privacy notice before the first subscription, because the guidelines say information must reach data subjects before data is submitted to nodes.
• A platform or technology provider acting on the issuer’s instructions is a processor, and needs an Article 28 agreement. If the provider decides its own purposes, it risks being a controller or joint controller.
• Nodes are a separate question. The Board says nodes with limited decision power may not be controllers, while nodes on public permissionless chains can be controllers or joint controllers where they have decisive influence. Nodes outside the EU also raise the Chapter V transfer rules, which the guidelines flag.

Our Reading: Design for the Hard Case

By our reading, the final guidelines close the argument that a hash is a safe way to anchor investor data. The Board’s text on hashes is explicit, and paragraph 104 says to store personal data in those forms off-chain. Any design that depends on “it is only a hash” has to be defended against that sentence.

By our reading, the more useful change is in posture. An issuer should not ask whether the ledger is personal data and design for the answer it prefers. It should assume the pseudonymous ledger is personal data in its own hands, minimise it, run an impact assessment, and make erasure a property of the architecture. The SRB judgment or an Omnibus change might later narrow what counts as personal data for some readers of a chain. A design that does not rely on that survives either outcome.

These are our interpretations of public documents, not statements by the EDPB or the Court. This is not legal advice.

The Record View

In Stobox Intelligence a question like “what may this issuer hold on chain” becomes a set of records, each with a fact, a source, a date and an evidence tier: the EDPB’s position on hashes is one record, the SRB holding another, the Omnibus status a third, dated 1 August 2026 and marked proposed. Nothing is averaged. The same principle shapes what the platform puts on a ledger. Intelligence is designed around a record link in which the token carries a date, not the document or data payload, so a published record can be referenced without the content travelling with it.

Design Note: Stobox Orbit

Stobox Orbit, a permissioned tokenization protocol, is in development and running on testnet (Base Sepolia). It makes no claim of compliance with the GDPR or any other regulation. Its documents record this as a ruling dated 27 September 2026 (R41): no identifying data and no document content on chain, hashed or otherwise; pseudonymous holdings and amounts per subject are ledger state.

• Subjects, not names. Orbit is designed so that a person is represented by a subject identifier derived from a DID hash, never a name, and the wallet is bound to the subject by the wallet’s own signature.
• Raw values off-chain. Names, addresses, tax identifiers and subscription documents are designed to stay off-chain. Per-subject claims on chain carry a hash, an issuer, an expiry and a revocation status; under the EDPB’s reading of hashes, those entries belong first in an impact assessment.
• A pseudonymous register, not a private one. Holdings and amounts are visible per pseudonymous subject. Orbit does not hide transfers, and anyone who can link a wallet or subject to a person can read that person’s position. The design controls what the chain can reveal, not what its readers can see.
• Erasure. The documents we read do not describe an erasure procedure. The design choice is to keep everything an erasure request would touch off-chain.

What to Do on Monday

1. Draw the data map. List every field your token and register would hold on chain and off-chain. Mark each one that identifies a person alone, or can with other data you or a reader of the chain hold. Anything on the first list goes off-chain.
2. Remove hashes of personal data from the design. If a spec says “store a hash of the passport or the investor file”, rewrite it. Keep such data off-chain, or hold only a reference that identifies no person.
3. Name the controller and the processors in writing. Decide who runs the key table, who the platform provider is, and what the Article 28 agreement says. Put the same names in your privacy notice before the first subscription.
4. Run a data protection impact assessment on the register. The EDPB’s list of questions is a ready template: whether the chain will contain personal data, why a blockchain is necessary, what type of chain, and what measures apply. Record the answers.
5. Write the erasure path and test it. State what deleting the key table does to each ledger entry, and which retention duties (MiCA, AML) keep which off-chain records for how long.

FAQ

Can I put a hash of investor data on a blockchain? The EDPB says a salted or keyed hash of personal data is still personal data, and that unsalted or unkeyed hashes are generally not enough on a public chain. Its final guidelines also say it is not advisable to record clear text, encrypted or hashed personal data on a chain and recommend keeping such data off-chain.

Is a wallet address personal data? It can be. The EDPB says public keys used as identifiers qualify as personal data where they can identify a natural person by means reasonably likely to be used, for example after a data breach. An address linked to a person in the issuer’s own systems should be treated as personal data by that issuer.

Does the SRB judgment mean pseudonymised data is not personal data? Not in general. On 4 September 2025 the Court of Justice held that pseudonymised data need not be personal data for a recipient who cannot re-identify the person. The party holding the key can still be dealing with personal data, and the case was sent back to the General Court.

How do I honour an erasure request when the ledger is append-only? Design so that the chain holds nothing that identifies a person on its own, and so that deleting the off-chain key table leaves the ledger entry unlinkable. The EDPB says erasure must be met by design, that the chain data must be rendered anonymous, and that technical impossibility is not a defence.

Related Reading in This Series

• MiCA or MiFID: Your Token’s Rights Decide
• The EU’s DLT Pilot Cap and the Ministers’ Meeting on 9 October
• Central Bank Money for Tokenized Securities Is Live: Pontes

For the wider picture, see the EU guide, the Germany guide, the tokenization overview, the Stobox Tokenization Framework and the glossary. Next in the series: stablecoin or central bank money as the settlement asset.

To see how a regulatory question looks as a record, look at Stobox Intelligence; Stobox Orbit’s documentation will follow when it is public.

Sources

Accessed 1 October 2026.

1. Regulation (EU) 2016/679 (GDPR), Articles 4(1), 4(5), 5, 17, 25 and recital 26: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679
2. EDPB, Guidelines 02/2025 on processing of personal data through blockchain technologies, version 2.0, adopted 7 July 2026: https://www.edpb.europa.eu/system/files/2026-07/edpb_guidelines_202502_blockchain_v2_en.pdf
3. EDPB, guidelines page: https://www.edpb.europa.eu/documents/guideline/guidelines-on-processing-of-personal-data-through-blockchain-technologies_en
4. Court of Justice, judgment of 4 September 2025, EDPS v SRB, C-413/23 P: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62023CJ0413
5. Commission proposal COM(2025) 837 final (Digital Omnibus), 19 November 2025: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025PC0837
6. EDPB-EDPS Joint Opinion 2/2026 on the Digital Omnibus, adopted 10 February 2026: https://www.edpb.europa.eu/system/files/2026-02/edpb_edps_jointopinion_202602_digitalomnibus_en.pdf
7. European Parliament, Legislative Train Schedule, The Digital Omnibus Regulation Proposal (2025/0360(COD)), updated 1 August 2026: https://www.europarl.europa.eu/legislative-train/theme-a-new-plan-for-europe-s-sustainable-prosperity-and-competitiveness/file-digital-package
8. Regulation (EU) 2023/1114 (MiCA), Articles 68(9) and 76(15): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1114
9. Regulation (EU) 2024/1624 (AMLR), Articles 77 and 90: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1624
10. Regulation (EU) 2022/858 (DLT Pilot Regulation), Article 5(2) and recital 57, as published in 2022: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R0858

This article is general information based on public documents. It is not legal advice. Consult qualified counsel before making decisions about a specific issuance.