GDPR right to erasure on a permissioned blockchain: the short answer
A regulated organization that wants a permissioned ledger and must honor erasure requests should start from one principle: the ledger is rarely the right place for personal data to live. Erasure is solved by design, not by trying to delete blocks. Personal data is kept off-chain in the systems that already hold it, and the ledger carries only pseudonymised references, hashes or identifiers that do not reveal a person on their own. Where a channel or network member needs some personal data shared among a subset of organizations, Fabric private data collections limit which peers hold the data, and the on-chain record keeps only a hash. Article 25 of the GDPR asks for measures such as pseudonymisation that are designed in before processing starts, so these choices belong in the architecture review, not in a later clean-up project.
Answer the design question before any node is provisioned. Ask which data elements would be written to the ledger, who would be able to read them, and what happens to the off-chain record when a request arrives. The GDPR text on EUR-Lex sets out the grounds and exceptions for erasure under Article 17, and the EDPB's 2025 coordinated enforcement action listed deletion of personal data in backups among the recurring problems regulators found. Treat any copy of personal data that reaches an append-only structure as a risk to be designed out, and confirm with your data protection officer how that risk is recorded.
The GDPR requires no audit, attestation or certificate, and an Article 42 certification is voluntary and does not reduce the controller's responsibility. DeployOpen prepares the controls, configurations and evidence that a controller can show a supervisory authority or an independent auditor, but it does not issue audit reports or certifications. The GDPR text has not been amended as of October 2026, although the Omnibus IV and Digital Omnibus proposals are still moving through the EU legislative process, so confirm the current position with counsel before you commit an architecture.
Which design pattern fits which data: private data, off-chain storage or pseudonymised references
Hyperledger Fabric private data collections let a defined set of channel members hold the actual personal data in a side database on their own peers, while the shared channel ledger records only a hash of that data. Non-member peers never receive the payload, so the personal data is not spread across every organization in the network. Erasure is still a design question: the private store on authorized peers can be purged or overwritten, but the hash on the channel ledger cannot be removed by any member because the ledger is append-only.
- Erasure path: the payload in the private store is deleted or purged on each authorized peer under a documented procedure, and the data owner's request is traced to every member that holds a copy.
- What remains on the ledger: the hash, the transaction metadata, the identity of the submitting member and the timestamp, all of which persist after erasure.
- Collection policy: the member set, endorsement rules and retention settings are defined per collection, so data minimization is set at design time, which is the main lever under Article 25.
- Backups and snapshots: copies of the private store in backups or peer snapshots fall within the erasure scope and need their own deletion or rotation rule.
- Residual risk to confirm with counsel: whether a hash of personal data, combined with other information, is still personal data in your context, and whether the ledger metadata itself identifies individuals.
Confirm with counsel and your Fabric operators whether the hash and metadata are personal data for your use case, and document how private store purges reach every peer and backup.
This pattern keeps personal data entirely outside the ledger in an erasable store that your organization controls, such as a relational database or document store inside your own infrastructure. The ledger holds only a pseudonymous reference, such as an opaque record identifier, and a value that lets the data be checked without revealing it. Erasure happens in the off-chain store, and the on-chain reference is then no longer linked to any individual. Whether this amounts to anonymization or pseudonymization depends on whether the controller can still re-identify the person, which is the point regulators test.
- Erasure path: the record is deleted or irreversibly anonymized in the off-chain store, and the key that links the reference to the person is destroyed as well.
- What remains on the ledger: an opaque identifier, a commitment or hash and the business event, with no names, contact details or identifiers that point back to a person.
- Key management: the mapping between reference and person sits in a separate system with its own access controls, ideally in an HSM-backed or vault-managed store, so destroying that mapping is a single controlled action.
- Linkability: events, amounts and timestamps on the ledger can still reveal a person when combined with other data, so minimize what is written on-chain.
- Residual risk to confirm with counsel: whether the reference is pseudonymised data rather than anonymised data, and whether copies held by ledger participants, logs or analytics exports are covered by the erasure.
Ask counsel to confirm the re-identification test for your references and to confirm that every copy of the mapping, including backups and logs, is inside the erasure process.
Besu private networks restrict who can connect and who can transact through local permissioning. Node permissioning limits connections to known participants, and account permissioning controls onboarding, can suspend accounts and can restrict actions. This reduces who can read or write personal data, but it does not change what the ledger stores. Anything written to chain state or transaction data is replicated to every node that joins the network, so the design question is what is placed on-chain in the first place, and erasure of on-chain data is generally not possible once it is committed.
- Erasure path: personal data should not be written to the chain at all. If it is, an erasure request cannot be executed by deleting it from the replicated chain, so the data must be kept off-chain.
- What remains on the ledger: all transactions and state changes that were committed, replicated to each node that has synced the chain, including sender addresses and contract data.
- Permissioning configuration: the node and account permissioning files define which parties are inside the network, which is the access control layer you document for auditors.
- Privacy features: the Tessera privacy feature and onchain permissioning were removed in Besu 25.6.0, so confirm which privacy mechanism you can run on your release line before designing around it.
- Residual risk to confirm with counsel: whether suspending an account or removing a node is sufficient for the data subject's rights when the committed data remains on every synced node.
Confirm your Besu release and permissioning files against the current documentation, and confirm with counsel that no personal data is written to chain state or transactions.
The patterns are not mutually exclusive. A common split places direct identifiers off-chain, uses references for records that must be verifiable, and reserves private data collections for business data that only a subset of members needs to see. Illustrative example: a consortium records a shipment event on the ledger, keeps the consignee's personal details in an erasable store, and stores only a reference that the consignee's record was verified. The choice depends on which members need the data, how long it must be kept and whether a regulator or counterparty needs to verify it later.
- Direct identifiers: keep off-chain in an erasable store by default.
- Verification needs: use hashes or commitments on-chain so that integrity can be proven without revealing the content.
- Shared business data: use Fabric private data collections when only certain members should hold it.
- Retention conflicts: where a law requires records to be kept, such as financial record retention rules, document how that retention interacts with erasure before the data is written.
- Documentation: record the data map, the pattern chosen for each data class and the review date, since the EDPB expects measures to be reviewed regularly.
Before committing, confirm with counsel how each data class is classified, which retention obligations apply and whether the chosen pattern is recorded in your data protection impact assessment.
Mapping GDPR Articles 17 and 25 to ledger functions and configuration
This table maps each GDPR provision in scope to what the ledger function must do and how a Fabric or Besu design can be configured to meet it. Read each row as a design question to answer before the network is built, since retrofitting erasure into a live ledger is harder. The main takeaway is that most erasure work sits outside the chain: in private data collections, off-chain stores, key management and retention workflows, with the ledger itself holding only what the design can justify.
| Requirement | What the function must do | How to configure it |
|---|---|---|
| Article 17(1) grounds | Identify when personal data must be erased without undue delay, such as withdrawn consent, unlawful processing or no longer needed data | Tag each personal data item with its purpose and lawful basis at write time, and run a retention workflow that triggers erasure requests against off-chain records and private collections |
| Article 17(2) notification | Where data was made public, take reasonable technical steps to tell other controllers about erasure of copies or links | Keep a registry of which channel members or external recipients received a copy, and publish erasure notices through the integration layer rather than on the ledger |
| Article 17(3) exceptions | Document when retention is lawfully required, for example for legal claims or a legal obligation | Record the exception basis in a governance register and apply a legal hold flag so the retention workflow skips the affected records |
| Article 25(1) pseudonymisation and minimisation | Apply pseudonymisation and data minimisation when designing the processing and while it runs | Write only pseudonymous identifiers to the ledger, keep the mapping in an off-chain store with separate access control, and store hashes or references instead of raw personal data |
| Article 25(2) default minimisation and accessibility | Process only the personal data each purpose needs, limit storage period and access to individuals | Use Fabric private data collections with restricted member peers, or Besu account and node permissioning, so personal data is not visible to all participants by default |
| Article 25(3) certification as an element | Consider an approved certification mechanism under Article 42 as one element of evidence, without it replacing compliance | Confirm with the certification body whether any scheme applies to your processing; the certificate does not reduce controller responsibility |
Which open-source platforms support erasure-friendly designs
No platform removes personal data from an append-only ledger on its own. Erasure-friendly designs depend on what each platform can keep off the shared ledger, how privacy is scoped between members, and how identities and keys are revoked. The cards below cover the two ledger platforms in scope and the off-chain store that usually holds the data that must be deleted.
Hyperledger Fabric private data
Fabric is licensed under Apache-2.0 and is available in the v3.1.5 line and the v2.5 long-term support line. Its private data collections let a subset of channel members hold personal data while the channel ledger carries only a hash of that data. Erasure then means deleting the private copy at the peers that hold it, which must be verified in each peer's storage. Confirm with the vendor how private data purge and hash retention behave in your chosen release, and whether a deleted value can still be recovered from peer backups.
Fabric CA identity revocation
Fabric CA registers identities or connects to LDAP as the user registry, issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists. For erasure, the practical question is whether a person's identity record and certificates can be revoked and removed without breaking the audit trail of prior transactions. Design the identity data so that names and contact details live in the directory, with only a pseudonymous identifier in the certificate subject. Confirm how the CA stores revoked identity records and how long they persist.
Besu private network permissioning
Besu is licensed under Apache-2.0 and supports private networks using QBFT or IBFT 2.0 proof-of-authority consensus. Its local permissioning configures node permissioning, which restricts connections to known participants, and account permissioning, which controls onboarding, suspends accounts and restricts actions. These controls limit who can write personal data to the chain, which supports data minimisation under Article 25. Check whether your release's account rules can freeze or restrict an account whose data a data subject has asked to erase, because the chain itself will still hold the transaction history.
Besu privacy needs a new design
Besu removed the Tessera privacy feature in 25.6.0 and the EEA and PRIV privacy RPC API groups in 25.7.0, and the maintainers have announced the sunsetting of Tessera privacy. Any design that relied on Tessera private transactions for erasure must be rebuilt, usually by keeping personal data off-chain and storing only references or hashes on the chain. Ask the vendor or your integration partner which privacy approach is supported for your release before committing a data model, and record the decision in your processing register.
Off-chain personal data store
Keeping personal data off-chain requires a separate database that you select and operate, and no supplied fact confirms how any particular database behaves for deletion. This store holds the records that Article 17 requires you to erase, with the ledger holding only a hash or pseudonymous reference. Define the deletion procedure, the backup retention and the propagation to any copies, since the EDPB's 2025 enforcement action flagged deletion in backups as a recurring failure. Confirm the store's erasure and backup capabilities with its vendor and test them against your own retention schedule.
How an erasure request flows through ledger, off-chain store and backups
This sequence shows how an Article 17 erasure request is handled when personal data sits off-chain and only references, hashes or pseudonymous keys sit on the ledger. It produces a documented record that each copy, reference and backup was either erased, rendered unusable or justified as an exception.
Verify and log the erasure request
The controller's privacy or data protection function receives the request, confirms the identity of the requester and checks which ground under Article 17(1) applies, or whether an Article 17(3) exception such as a legal obligation to retain records applies. The decision, the date of receipt and the requester's verified identity are recorded in the case file before any system is touched. Done means a signed case record exists and the scope of the request is agreed internally. Confirm with your legal team how retention duties in your sector, such as the SEC record-keeping rules for broker-dealers, interact with the request before you proceed.
Map personal data and ledger references
Engineers identify every place the subject's data lives: the off-chain database or document store, the identifiers or hashes written to the ledger, private data collections or channel stores, and any indexes, caches and analytics copies. The output is a data map that links each on-chain reference to its off-chain record and shows which party holds each copy. Done means the map is reviewed by the data protection lead and each item is tagged as erase, pseudonymise or justify. Whether a given ledger field holds personal data depends on your design, so confirm this for each contract or chaincode.
Delete or destroy keys in the off-chain store
The off-chain records are deleted from the primary store, or the encryption keys that make them readable are destroyed in a key management system or HSM, which renders the stored ciphertext unrecoverable. The operator records which keys were destroyed, under which request reference, and confirms that no key escrow copy remains outside the approved process. Done means a deletion job completes and a verification query returns no readable personal data for the subject. Confirm that your key destruction method is accepted by your supervisory authority guidance and that your platform supports it, since the mechanism depends on the storage product you chose.
Purge or revoke private ledger data
Where personal data was placed in a Fabric private data collection or a separate private store, the peers holding that collection remove or stop serving the private payload according to the collection design and the chaincode logic. On the public ledger, the on-chain record remains immutable, so the step confirms that only a hash, pseudonymous identifier or unlinkable value remains, and that the mapping to the individual is removed from the off-chain side. Done means a test read against each peer returns no personal payload and the ledger entry no longer links to an identifiable person. Confirm with the platform team exactly what a Fabric or Besu peer retains after a purge, and whether a purge is possible in your chosen design.
Handle backups and archived copies
The team identifies every backup, snapshot, archive and replica that holds the subject's data, including ledger backups taken for upgrades and MSP backups. The EDPB's 2025 coordinated enforcement findings flagged deletion of personal data in backups as a recurring challenge, so the plan states how each copy will be overwritten, expired or excluded from restore, and how restoration will not re-introduce erased data. Done means a backup register entry exists for each copy with a documented disposition and a restore check procedure. Confirm the backup retention settings and restore procedures with your operations team and vendor, because ledger backups taken before an upgrade may be needed for rollback.
Notify downstream controllers where data was public
Where the controller made the personal data public, or shared it with other controllers who hold copies or links, the team sends erasure notifications to those recipients as Article 17(2) requires, using reasonable technical and organisational steps. For consortium ledgers, this means informing each member organisation that processes the data in its own systems and asking it to confirm completion. Done means each notification and each confirmation is recorded against the case reference. Confirm with your legal function which recipients count as controllers in your network agreement and which notification channel your members have agreed.
Test and log the completed erasure
The team runs verification checks against the off-chain store, the ledger peers, indexes and backups, then compares the results with the data map from the earlier step. Each action, its timestamp, the operator, the system and the evidence are written to an audit log that is kept under the controller's retention policy. Done means the case is closed with a signed completion record and any exceptions are documented with their legal basis. Schedule a periodic review of the erasure process, because EDPB Guidelines 4/2019 expect controllers to review the effectiveness of their measures regularly, and confirm the log format with your auditors before the first live request.
Evidence auditors and supervisors ask for on erasure and data protection by design
This table lists the records a data protection authority, auditor or internal assessor will ask to see when a permissioned ledger holds personal data, and which platform component usually produces each one. Read each row as a question to answer before go-live, then as a record to keep current after every upgrade. The main takeaway is that the ledger itself rarely holds the full evidence, so the design decision records and off-chain deletion logs matter as much as the node configuration.
| Evidence item | What it shows | Producing component |
|---|---|---|
| Records of processing and data flow maps | Which personal data enters the ledger, which members see it, and where off-chain copies live | Controller documentation, chaincode and client application design, off-chain stores |
| Design decision records for on-chain versus off-chain data | Why each data element was placed on the ledger, hashed, pseudonymised or kept off-chain | Architecture review records and data protection impact assessment |
| Private data collection policies and membership lists | Which organizations can read private data and the endorsement and retention rules for each collection | Fabric channel and private data collection definitions, MSP membership records |
| Erasure request logs | Each request received, the Article 17 ground relied on, the action taken and the date of completion | Case management system and off-chain store deletion logs |
| Backup and deletion test results | Whether deleted personal data is removed from backups and restored copies, not only from live systems | Backup tooling, restore test records and ledger backup procedures |
| Besu permissioning configuration files | Node and account permissioning rules that restrict who connects and who may act on the network | Besu node permissions configuration file and account permissioning records |
| Fabric CA revocation records | Certificates revoked for departing members or compromised identities, with certificate revocation lists | Fabric CA revocation and certificate revocation list outputs |
| Change records for platform upgrades | Pre-upgrade backups, rolling upgrade steps and, for Besu, a backup taken before the database upgrade so rollback is possible | Change tickets, ledger and MSP backups, Besu database backup before upgrade |
| Periodic effectiveness reviews | Regular review that the chosen erasure and minimisation measures still work, as EDPB Guidelines 4/2019 expects | Governance review minutes and test evidence reviewed by the controller |
What tooling alone does not satisfy
A permissioned ledger gives you tamper-evident records, but it does not decide what the GDPR requires. The cards below cover the gaps that remain after the platform is configured, and each one names the decision or check that closes it.
Lawful basis and exceptions
A ledger cannot decide whether an erasure request must be granted. Article 17(1) lists the grounds that trigger erasure, and Article 17(3) lists exceptions such as compliance with a legal obligation or the defence of legal claims. Someone accountable must map each record type to a basis and a retention reason before data is written. Record that decision in the data inventory, not in the chaincode or contract logic.
Hashes and references on-chain
Storing a hash of a personal record or a pointer to an off-chain store can still count as personal data where the controller or another party can link it back to a person. Whether a given hash is personal data is a legal question, not a technical one. Ask counsel to review each on-chain field, and document the reasoning before the design is approved.
Backups and node replicas
Every peer or validator holds a full copy of the ledger, and backups hold copies of those copies. The EDPB's 2025 coordinated enforcement action listed deletion of personal data in backups among its recurring challenges. Define how erased data is removed from backups within your retention rules, and test that restoring a backup does not bring erased data back.
Members who joined earlier
In a consortium, a member that joined later receives or can rebuild earlier blocks, and each member is its own controller for the data it holds. Erasure requests may therefore reach several organizations. Agree in the network governance who receives requests, who acts on them, and how each member is told that an erasure has been requested.
Certification does not replace accountability
The GDPR requires no audit, attestation or certificate. An Article 42 certification is voluntary and does not reduce the controller's or processor's responsibility for compliance. Treat any certificate as one piece of evidence for Article 25 and keep your own record of design decisions, testing and regular reviews. Confirm with your data protection officer what evidence your supervisor will expect.
Pending Omnibus proposals
The GDPR text has not been amended as of October 2026, but the Omnibus IV and Digital Omnibus proposals are in the legislative process and could change some obligations. Assign someone to track both procedures in the Legislative Observatory and schedule a design review when a text is adopted. Keep the design flexible enough that a changed retention or erasure rule does not require a full rebuild.
Questions buyers ask before hiring help on GDPR and permissioned ledgers
Can personal data be deleted from a Hyperledger Fabric or Besu ledger?
Not from the blocks themselves in the way a database row can be deleted, so the design has to keep personal data out of the append-only ledger in the first place. Ledger entries are chained by hash, and removing a record from one node would break agreement with other members. The practical approach is to store only pseudonymised references or hashes on-chain and keep the identifying data in a store the controller can change or delete. Whether a given design meets Article 17 is a legal question, so confirm the approach with your data protection officer and counsel. DeployOpen can implement and document the technical pattern you choose, including where personal data sits and how it is removed from each store.
How do Fabric private data collections help with erasure?
Private data collections let a subset of channel members hold actual private data in their own side databases, while the channel ledger carries only a hash of that data visible to everyone. Erasure then becomes a question of deleting the private value from the authorized peers' side stores, while the on-ledger hash remains. Regulators have been clear that anonymisation or hashing used in place of real deletion does not by itself satisfy erasure, so the hash and any retained metadata need a legal assessment. Confirm with the Fabric documentation and your own testing how purging works for your Fabric version, and check how each member's backups handle the same record.
What drives the cost of a GDPR-compliant ledger design?
The main drivers are the number of members and peers that hold copies of data, the number of off-chain stores that must be changed, how backups are designed and purged, the amount of legal review needed, and the testing required to prove deletion works across all nodes. Each member may need its own review, so cost rises with the size of the consortium. Software licenses for Fabric and Besu are not the main cost; the work is design, integration, testing and documentation. Ask any provider for a quote that lists each item separately, states what is one-time and what recurs (such as backup purge runs and annual control reviews), and names who is responsible for legal sign-off.
How long does a GDPR erasure design for permissioned ledgers take?
The duration depends on scope: how many systems hold personal data, how many members must agree on the design, whether an off-chain store must be built or modified, and how much testing and legal review is needed. A single-organization pilot with one off-chain store is a very different job from a multi-member network with several backup regimes. Ask for a timeline in the written scope, with milestones for data mapping, design decisions, build, testing and sign-off. DeployOpen plans and delivers fixed-scope engagements, so the timeline is agreed in writing before work starts rather than estimated from general assumptions.
What does the client team need to provide before work starts?
Expect to supply a data map showing which personal data enters the ledger, which systems hold it, where copies exist (including backups and logs) and who can access each store. You will also need the legal basis for each processing purpose, the retention rules and any exceptions your organization relies on under Article 17(3), and the member agreements that set roles, responsibilities and who acts as controller for each dataset. On the technical side, provide the planned Fabric or Besu versions, the channel and member layout, and the current backup and key management practices. Gaps in these inputs are the most common cause of delayed scopes.
Can our own engineers handle GDPR erasure on a permissioned ledger?
Some teams can, especially where they already operate Fabric or Besu nodes and have strong data protection and legal support. The work spans ledger design, off-chain storage, backup purge procedures, access controls and evidence collection, so it is rarely a single engineering task. Check whether your team has experience with Fabric private data purging, Besu upgrade and rollback behavior, and documenting controls for regular review as described in EDPB Guidelines 4/2019. A partner can build the pattern alongside your team, so knowledge stays in-house after handover. Decide this based on skills and capacity, not on the assumption that the work is small.
Does DeployOpen certify GDPR compliance for our ledger?
No. DeployOpen does not issue audit reports, attestations or certifications. The GDPR does not require a certificate, and an approved Article 42 certification is voluntary and issued by accredited bodies or supervisory authorities, and it does not reduce the controller's responsibility. What DeployOpen does is design and implement the technical and organizational measures, prepare the systems and evidence, and document the controls so that your legal team and independent assessors can review them. Responsibility for compliance remains with your organization and its legal advisers.
What should we ask a partner about GDPR and ledger design?
Ask how they map personal data before choosing a design, and whether they recommend keeping personal data off-chain for each use case. Ask how they handle backups, logs and peer copies during erasure, and how they test deletion across every node. Ask which Fabric or Besu versions they plan around, how they handle upgrades that could change storage behavior, and how they record the review schedule. Request a written scope that lists deliverables, exclusions and what legal review is expected from you. A clear answer to each point shows whether the partner understands both the ledger and the regulation.
What to confirm with counsel and your ledger partner before go-live
Before go-live, settle with counsel which data on the ledger is personal under your jurisdiction. Treat pseudonymised references, such as a hashed national identifier, a wallet-style account key or a member's internal customer number, as personal data unless counsel documents a reasoned position otherwise. Article 25(1) expects pseudonymisation as a design measure, so the ledger team needs that answer before choosing between private data collections in Fabric, off-chain storage with hashes on the ledger, or Besu private transactions. Confirm too whether EU data residency applies to every node, peer, orderer, validator and backup, and whether any member or node operator outside the EEA would make Chapter V transfers relevant. Record the answers in the data map that your ledger partner builds from the design.
Ask counsel how fines under Article 83 map to specific design choices. The higher maximum tier of EUR 20 million or 4% of worldwide annual turnover covers infringements of the principles and data subject rights, while the lower tier of EUR 10 million or 2% covers infringements such as Articles 25 to 39. Ask which design decisions would be judged against each tier, and document how each erasure path was assessed. Agree also how regular reviews will run under EDPB Guidelines 4/2019: who owns the review, how often it runs, what evidence it produces, and which trigger events, such as a new member or a major upgrade, force an earlier review. The EDPB's 2025 enforcement action flagged deletion in backups as a recurring failure, so include backup retention in that review.
Two regulatory items should sit on your monitoring list. Regulation (EU) 2025/2518 sets additional procedural rules for cross-border GDPR enforcement and applies from 2 April 2027, so ask counsel how it could change complaint handling and investigation timelines for members. Track the Omnibus IV proposal (procedure 2025/0130(COD)), whose text was agreed in interinstitutional negotiations on 26 June 2026 and awaits Parliament's first-reading vote, and the Digital Omnibus proposal (procedure 2025/0360(COD)), which awaits committee decision. The GDPR text had not been amended as of October 2026, so design against the current text and assign one owner to review these procedures at each release cycle.
How DeployOpen scopes, builds and evidences a privacy-aware ledger
DeployOpen starts with a written scope that separates personal data from ledger data before any node is deployed. We then build, test, document and hand over Hyperledger Fabric or Besu networks inside your own infrastructure, with the erasure design, evidence and operating routines your data protection team needs to review.
How we scope
- Inventory which records would go on the ledger and which personal data fields they contain, with your data protection officer.
- Map each data category to a design choice: keep off-chain, hash on-chain, or use private data collections in Fabric.
- Agree the written scope, deliverables and timeline in advance, since most engagements are fixed-scope.
How we build
- Deploy Fabric or Besu nodes in your cloud accounts, data centers or air-gapped networks, with the chosen privacy pattern configured.
- Set up the off-chain store, deletion workflow and key handling so that erasure requests reach every copy the design controls.
- Test erasure, access restriction and backup handling, and document the results against the agreed design.
How we hand over
- Deliver architecture records, data flow maps, runbooks and the erasure procedure in a form your auditors and supervisory staff can read.
- Document backup scope, including how deletion is reflected in backups, and the steps for restoring data without reintroducing erased records.
- Set up a review schedule for the chosen measures, reflecting the regular effectiveness review that EDPB guidance expects.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan upgrades around the Fabric and Besu release lines, including backups taken before each change.
- Confirm with your legal counsel which erasure exceptions apply to your records and retention obligations before go-live.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), EUR-Lex ↗
- EDPB Guidelines 4/2019 on Article 25 data protection by design and by default (version 2.0) ↗
- EDPB news: challenges hindering the full implementation of the right to erasure ↗
- Hyperledger Fabric private data and privacy documentation: Fabric docs, what's new ↗
- Besu docs: permissioning ↗
- Sunsetting Tessera and simplifying Hyperledger Besu ↗
