Can a Hyperledger Besu ledger meet GDPR erasure requests?
A regulated operator running a shared Besu ledger faces a basic conflict: once a block is accepted, its contents cannot be edited, yet GDPR Article 17 still requires the controller to erase personal data without undue delay when a ground applies. The answer depends on one design rule: personal data must stay out of chain data in the first place. Besu is an execution client and permissioning layer, not an erasure tool. It can help you control who writes to the network and keep an auditable record of design decisions, but it does not make a ledger erasable. Treat erasure as a property of your architecture, decided before the first transaction is submitted.
Work through the requirement in parts. The platform supports the parts you control: deciding which fields go on chain, restricting which accounts and nodes can submit transactions through local permissioning (node and account permissioning files), limiting who can reach RPC endpoints through JSON-RPC authentication, and keeping configuration and access records in your own logging stack. It does not support erasing a value once it is in a block, and it cannot tell you which copies of a block exist across every operator's nodes. Article 17(2) and Article 19 also require notifying recipients and linked copies, which depends on your data flows and off-chain stores, not on the chain. Ask your legal team to confirm which Article 17(3) exceptions, if any, apply to records you must keep.
Where personal data does need to be shared between members, Paladin's off-chain private state is the mechanism to evaluate, since it keeps data outside the shared chain. Confirm with the Paladin project and your counsel how that state is stored, deleted and backed up, because the EDPB's 2025 coordinated enforcement action found deletion gaps, including in backups, a recurring problem. DeployOpen plans, implements and documents these designs and prepares systems and evidence for your compliance assessments. It does not issue audit reports, attestations or certifications, and certification under Article 42 is voluntary and does not reduce the controller's responsibility.
How GDPR Article 17 requirements map to Besu design choices
This table maps each Article 17 and 19 requirement, plus the Article 58(2)(g) order power, to the Besu design choice that addresses it and the gap the operator must close. Read the design column as where erasure can actually be executed, and the gap column as what Besu does not do. The main takeaway is that the ledger is immutable, so erasure depends on keeping personal data off it.
| Requirement | What it asks for | Besu design choice | Gap to close |
|---|---|---|---|
| Article 17(1) grounds | Erase without undue delay on six grounds, including withdrawn consent and a successful objection. | Keep identifiers and personal fields in off-chain stores that the operator can delete. | Besu has no feature to delete ledger entries. Confirm no personal data reaches the chain. |
| Article 17(2) public data | Where data was made public, take reasonable steps, including technical measures, to inform other controllers. | Publish only pseudonymous references on the network, so links and copies carry no personal data. | No Besu feature propagates erasure notices. Build a notification step into your process. |
| Article 17(3) exceptions | Retention may be allowed for legal obligations, public tasks, archiving, research or legal claims. | Keep a separate, access-controlled record for retained data, outside the ledger. | Exceptions are a legal assessment Besu cannot make. Document the basis for each dataset. |
| Article 19 recipient notice | Tell each recipient of the data about erasure, unless this is impossible or disproportionate. | Use local node permissioning to define which parties connect, and keep a recipient register alongside it. | Besu keeps no recipient register. Confirm how members are listed and contacted. |
| Article 58(2)(g) orders | Supervisory authorities can order erasure of personal data. | Keep erasure executable on off-chain stores, with logged and timed deletion evidence. | Ledger history stays immutable and an order cannot reach it. Agree this position with counsel. |
| Backups and node data | The EDPB's 2025 enforcement action found deletion of personal data in backups a recurring challenge. | Keep personal data out of node backups, and set retention for off-chain store backups. | Confirm backup purge steps for off-chain stores with your backup tooling. |
What remains immutable on the ledger and how to design around it
Once a block is committed on a Besu network, the network cannot rewrite it. Validators and RPC nodes each hold a copy of the chain, so any personal data written into a transaction, event log or contract storage may persist in every one of those copies, including copies held by other consortium members and by any archive or backup taken from them. Erasure therefore has to be solved before data reaches the chain, not after. The practical design question for the team is simple: which fields in each transaction and event could identify a natural person, and who can read them once they are committed.
Pseudonymisation and anonymisation are not the same. Pseudonymised data, where a stable identifier replaces a name but a key or lookup table still links it back to a person, remains personal data under the GDPR. Anonymised data must be impossible to re-identify by any means reasonably likely to be used, and that bar is hard to meet on a shared ledger where transaction patterns, timestamps and addresses can be correlated over time. The EDPB's 2025 coordinated enforcement action identified ineffective anonymisation used in place of deletion as one of its recurring challenges. A hash written on chain is therefore a pseudonym at best. Confirm the position with your data protection officer and, where needed, with counsel before relying on hashing as the erasure answer.
Design to limit what is written: keep identifiers, names, account details and free text in an off-chain store that your organization controls, and record on chain only a commitment or reference that the off-chain record can be deleted without touching the ledger. Review every smart contract event and every RPC-visible field in the design review, because a value emitted in a log is as permanent as one stored in state. Document the data flow and the justification for each on-chain field, and treat the choice of what not to write as a control that auditors and supervisory authorities can examine.
Paladin off-chain private state compared with on-chain data
The strongest position for erasure is to keep personal data out of the Besu network altogether. The ledger then carries only identifiers or commitments that cannot be traced back to a person without material held by the controller. Erasure is handled in the systems that already hold the record, such as the CRM, core banking system or identity store, and the on-chain reference is left untouched. The controller still has to show that the reference cannot identify anyone on its own, which is a question about the design of the identifier, not about the ledger.
- Where copies live: the personal record sits in your own systems, under the retention and access controls you already run.
- Who can delete them: your data owners and application teams, through the normal erasure workflow.
- What erasure requires: deleting or restricting the off-chain record and every backup and replica you control, plus evidence that the on-chain reference no longer links to a person.
- Pseudonymous references: confirm with your data protection officer whether salted or keyed identifiers still count as personal data under the GDPR in your case.
- Ledger contents: nothing that names a person, account or contact detail should be written to the shared chain.
Check that every integration writes only the agreed reference and that no log, trace or transaction payload carries the underlying data.
Paladin privacy domains let consortium members keep transaction data private between the participants who need it, after Tessera's removal from Besu. Private state is held off the shared chain by the participating nodes, so the public ledger records only what the design allows. This moves the erasure question from the shared ledger to each participant's node storage, and it adds a second question: which copies exist on which member's node, and who controls each one. Paladin's exact deletion behaviour, storage layout and any support for removing private state must be confirmed against its current documentation before you rely on it.
- Where copies live: on each participating member's node storage, and in any backup or replica that member keeps.
- Who can delete them: each member controls its own copy. Deleting one copy does not delete the copies held by other participants.
- What erasure requires: an agreed process across the domain, a record of which members hold the data, and a deletion procedure each member can run and evidence.
- Consortium terms: write the erasure responsibility into the governance agreement, including who answers a data subject request.
- Confirm with Paladin: whether private state can be overwritten or removed, and how that interacts with any chain history.
Ask for the current Paladin documentation and check it against your planned storage and backup design before you commit to this option.
Writing personal data to a Besu ledger is the option that conflicts most directly with erasure. Blocks and transactions are appended and replicated to every node in the network, so removing a value from the chain is not a normal operation. Copies also spread to node databases, archives, backups and any external system that ingested the chain data. Article 17(2) asks controllers who made data public to take reasonable steps, including technical measures, to tell others about erasure requests, and the EDPB's 2025 coordinated enforcement action listed ineffective anonymisation used instead of deletion as a recurring problem.
- Where copies live: on every validator and RPC node, in node databases and backups, and in any indexer or analytics copy built from the chain.
- Who can delete them: no single operator can remove a value from all copies, because each node holds its own replica.
- What erasure requires: a design that never needed the data on chain, which in practice means a different option.
- Anonymisation is not deletion: masking or hashing a value on chain does not by itself meet the erasure request if the value can still be linked to a person.
- Escalation: involve counsel before any on-chain personal data is written, because the choice affects every participant.
As a rule, do not place personal data on the shared ledger. Use this tab as the baseline that the other options are measured against.
Evidence to keep for erasure and records of processing
An erasure request is only as defensible as the records behind it. The cards below cover the documents and logs a controller should hold so it can show a data subject or supervisory authority what was stored, where, how it was removed, and why some copies remain. Each item feeds the next, from the data map to the request log.
Data map for the Besu network
A register of every personal data element, the system that holds it, the purpose, the lawful basis and the recipients. For a Besu network it should name each contract, event field, transaction input, RPC log, node and backup location that could carry personal data. Without this map, a controller cannot show that it searched every place the data could sit. Check that the map is reviewed whenever a smart contract or privacy domain changes.
On-chain versus off-chain classification
A written decision for each data element that states whether it is written to the shared ledger, held in an off-chain private store, or never stored. Record the reason, such as an immutable hash that cannot identify a person, or a value that must be deleted on request. Keep the classification tied to the data map so reviewers can trace a field from design to storage. Re-open the decision whenever a new field is proposed for a contract.
Deletion logs for off-chain stores
A dated record of each deletion from an off-chain database, object store, cache, search index or log pipeline, with the identifier of the request it served. Confirm that the log proves removal and does not repeat the personal data itself. The EDPB's 2025 coordinated action found that deletion was often replaced by anonymisation that did not hold up, so the log should show actual erasure, not a flag or soft delete.
Key destruction records
Where personal data is encrypted before it is stored off-chain, the key is what makes the data recoverable. Record when each key was created, which data it protects, when it was destroyed and who approved the destruction. Destroying the key can render encrypted copies unreadable, but the controller should confirm with its legal team and supervisory guidance whether that counts as erasure in its case. Besu's node key file is not encrypted by default, so store and destroy any key material deliberately.
Node and backup retention decisions
A decision record for how long each Besu node, archive copy and backup keeps chain data, with the reason for each period. Because the ledger is replicated across validators, a request cannot be honored for data already committed without a recorded exception or a privacy design that avoided writing the data in the first place. Note which backups are kept for recovery, how they are restored, and when they expire. Ask the backup team to confirm that expiry is enforced, not only planned.
Request handling log
A case record for each erasure request, showing receipt date, identity verification, the Article 17(1) ground relied on, any Article 17(3) exception applied, the systems searched, actions taken and the notice sent to recipients under Article 19. Responses to supervisory authorities depend on this trail, so keep it complete even when a request is refused. Set a reviewer to check that each refusal names its exception.
Designing the network so erasure is possible
This sequence sets the design rules that decide whether an Article 17 erasure request can be met on a Besu network. It ends with an erasure test that proves the personal data can be found, removed from controller-managed stores and shown to be absent from the ledger's usable state.
Classify data before the design starts
The controller's privacy lead and the network architect list every data element the business process touches, such as names, account identifiers, contact details, identity documents and transaction counterparties, and mark which ones identify a person. They also record the lawful basis, the purpose and the systems of record for each element. The step is done when each element has an owner, a purpose and a documented decision on whether it may be personal data at all. Without this list, later steps cannot be checked, because no one can say what must be erased.
Decide what may touch the ledger
Architects set a written rule that the shared ledger carries only the data needed for ordering, settlement and proof, such as hashes, opaque references and status values, and never raw personal identifiers. Anything that must be readable by a person is held off-chain. Because Besu blocks and transactions are replicated to every node and cannot be edited, this rule is the main control over what erasure can reach. The output is an approved data-on-chain specification signed by the data protection officer, with a review trigger for any new transaction type.
Place personal data in controller-managed stores
Personal data is stored in databases or document stores that the controller operates, with access logs and deletion routines that the controller can run. Where a privacy feature is needed for transaction data between members, the team evaluates Paladin's off-chain private state rather than relying on removed Besu features such as Tessera. The team confirms which store holds each record and that a deletion in that store removes the only readable copy. The check is a store-by-store map tied to the classification from the first step.
Set retention and backup rules
The team writes retention periods for each off-chain store and decides what happens to backups that hold deleted records. The EDPB's 2025 coordinated enforcement action identified deletion of personal data in backups as a recurring challenge, so the rule must say how backup copies are expired, excluded from restores or re-deleted after a restore. Because the Bonsai database auto-upgrades on first start and older versions cannot open it, node backups taken before upgrades also need this treatment. The output is a retention schedule and a backup procedure approved by the controller.
Configure permissioning and RPC authentication
Node permissioning limits which peers can connect, using the permissions configuration file that Besu reads for node and account rules. Account permissioning controls which accounts can submit transactions. RPC access is protected with credentials or JWTs validated against a public key, and the node is placed behind a TLS-terminating proxy, since Besu does not terminate HTTPS natively. Operators confirm that only named roles can query or write personal data references. The step is complete when a test account outside the approved list is refused and each RPC route is listed with its allowed callers.
Enable metrics and logs as erasure evidence
Operators turn on metrics with the --metrics-enabled option and route node and gateway logs into the monitoring stack they already run. The logs should record erasure job starts and finishes, store deletions, backup expirations and any RPC access to personal data references, without writing the personal data itself. The team confirms retention for these logs and that clocks are synchronized so entries can be ordered. The output is a sample evidence bundle for one erasure job that a reviewer can read without access to the ledger.
Test an erasure request end to end
A test subject's record is created, linked to ledger references and then erased through the documented process. The team confirms the record is gone from every off-chain store and backup in scope, that the on-chain material left behind contains no readable personal data, and that the erasure is logged. It also checks that the controller can explain why remaining immutable hashes do not identify anyone, which the anonymisation discussion in the EDPB's 2026 erasure report makes necessary. Any gap found is fixed and the test is repeated before go-live and after material changes.
Why Besu version choice affects erasure evidence
The Besu release you run decides which privacy mechanism you can rely on and what your backups contain, so both belong in the erasure evidence file. Besu 25.6.0 (June 4, 2025) removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. A team that built its off-chain handling around those APIs cannot assume they still exist on a current release. Before you pick a version, confirm in the release notes for that exact version which privacy mechanism your design uses, and record the answer alongside the design decision that depends on it. The Besu maintainers suggest plugins, community forks or Paladin's privacy domains for teams that still need the removed features, so the replacement must be named and checked, not inferred.
Upgrades carry a second erasure consequence. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older Besu versions cannot open an upgraded database, so rollback depends on a backup taken before the upgrade. That backup is a copy of node data that may still hold personal data or the material needed to reconstruct it. Treat pre-upgrade snapshots as personal data stores: give them the same retention limit, access control and deletion procedure as live stores, and check whether an erasure request reaches them. Ask your team to document where each pre-upgrade backup sits, how long it is kept and how it would be removed if a request requires it. Also record the Besu version running on each node, because the answer to what an erasure request touched depends on it.
Questions buyers ask about erasure on a Besu network
How much does a GDPR erasure design for a Besu network cost?
No price is published, and DeployOpen does not estimate prices. A quote follows from a written scope. The main cost drivers are how many systems hold personal data around the ledger (onboarding, KYC, support tickets, backups, analytics), how many organizations share the network, whether privacy is handled by Paladin's off-chain private state or a custom pattern, and how much of the existing data flow must be mapped first. Ask for the quote to split design review, any build work, testing of erasure and backup handling, and documentation as separate line items, so you can see what is one-time and what would recur if you later add a retainer for ongoing support.
How long does a design review of personal data on a Besu ledger take?
Duration depends on the inputs more than on the platform. A review moves faster when you already have a data inventory, a list of which processing activities touch the network, and clear owners for each system. It slows down when the team must first agree what counts as personal data on-chain, such as wallet addresses or transaction references that can be linked to a person. Ask for a timeline in the written scope and confirm which of your teams must be available for workshops, since the review depends on their answers about retention, backups and third-country access.
What must our team provide before a design review starts?
Expect to supply the material that describes your processing, because a design cannot be made without it. This usually includes:
- A record of processing activities covering the data that touches the network
- Diagrams of where node, RPC and application data is stored, including backups
- Your retention rules and the legal bases you rely on for each purpose
- The list of processors and sub-processors, with locations
- Access to the team that owns onboarding, customer records and incident handling
Confirm the exact list with DeployOpen during scoping so the review does not stall on missing documents.
Can our own engineers design and run GDPR erasure for a Besu network?
Yes, a capable internal team can do this, and many do. The work needs skills in blockchain data structures, privacy engineering, records management and legal interpretation, and the decisions must be documented for your DPO. Internal teams often struggle with the backup and off-chain storage questions, because these are easy to overlook. Compare your team's current skills against the design questions in the main section, then decide whether to build the gaps internally or buy a fixed-scope review that ends with written decisions you can test.
Can DeployOpen certify that our Besu network is GDPR compliant?
No. DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. The GDPR itself requires no audit or certificate. Certification under Article 42 is voluntary, is issued by accredited certification bodies or supervisory authorities for at most three years, and does not reduce your responsibility as controller. Your DPO and an independent assessor are the right parties to judge compliance, and DeployOpen can give them the design records and test evidence they need.
Do we need a legal opinion before we design erasure for our network?
Usually yes, at least for the points where the law is unclear to your organization. A technical design can show that erasure is possible, but it cannot decide whether a particular record may be kept under an Article 17(3) exception, whether a transfer to a third country is lawful, or how a request should be answered. Ask your counsel to confirm the lawful bases, the retention periods and the treatment of any data that remains on the ledger. DeployOpen can prepare the technical facts for that review, and the legal conclusions remain with your lawyers and DPO.
Does the proposed Omnibus change affect a design we build now?
Possibly, so plan for change control rather than assuming the text stays fixed. The GDPR text had not been amended as of October 2026, but the Omnibus IV and Digital Omnibus proposals are in the legislative process. Ask your counsel to review the current status before you sign off the design, and record which assumptions depend on the current text. Build the erasure controls so that retention periods and processing purposes are configuration decisions you can revise, not hard-coded rules spread across the network.
How DeployOpen scopes erasure design and evidence
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so the erasure design for a Besu network is worked out against your data flows and your environment. We set out what stays off the shared ledger, what cannot be changed once written, and what evidence your team and auditors will need.
How we scope
- We map which personal data each Besu node, RPC endpoint and application touches before any design work starts.
- The written scope states which data stays off-chain, which hashes or references go on-chain, and who owns each erasure step.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we build
- We design the off-chain store, its access controls and deletion routines in your infrastructure, and document how they link to on-chain records.
- We test erasure end to end, including copies in logs, backups, replicas and monitoring pipelines, on segregated test systems.
- We confirm with your team which Paladin privacy features and Besu versions your design depends on before build starts.
How we hand over
- You receive the design record, data flow diagrams, runbooks for handling an erasure request and the test results behind them.
- The handover lists what cannot be erased from the immutable chain and the controls you must document in its place.
- We train the operators who will process requests so the procedure works without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can re-test erasure paths when Besu releases change logging, storage or privacy behavior that affects your design.
- Questions about legal basis or enforcement exposure remain with your counsel and data protection officer, and we confirm the technical facts they need.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), Articles 17, 19 and 58, EUR-Lex ↗
- EDPB news: challenges hindering the full implementation of the right to erasure ↗
- EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V of the GDPR (version 2.0) ↗
- Besu docs: permissioning ↗
- Sunsetting Tessera and simplifying Hyperledger Besu ↗
- Besu releases on GitHub ↗
