Hyperledger Fabric GDPR erasure and private data purging

Can Hyperledger Fabric support GDPR erasure requests?

Partly. Hyperledger Fabric can support erasure of personal data held by peers, but it cannot decide whether an erasure request must be honored. Consider a controller running a consortium network in which member organizations hold customer records that must be erased on request under Article 17. Fabric's private data collections keep those records off the shared channel ledger, and the private data documentation describes purging them from peers where parties want to, or regulation requires them to. The platform does not determine whether a ground in Article 17(1) applies, whether an Article 17(3) exception keeps the data, or whether the processing had a lawful basis in the first place. Those decisions belong to the controller and its counsel.

Fabric helps most with the security measures in Article 32. Collection-level membership policies limit which organizations can read personal data, TLS protects traffic between nodes, and peer and orderer MSP keys can be held in an HSM through PKCS#11. The operations service provides health checks and logging that support the regular testing Article 32 describes. Before go-live, the controller should map each personal data attribute to a collection, name the member organizations in each collection policy, and confirm with the Fabric documentation which purge settings apply to the Fabric version in use. Test an erasure end to end on a non-production network and record the result as evidence.

The on-ledger hash left after a purge is the design point that needs legal review. The Fabric documentation describes it as immutable evidence, but whether a hash is itself personal data depends on the facts, so counsel should decide whether it can stay and for how long. Article 17(3) exceptions, such as a legal obligation to retain records or the establishment or defence of legal claims, may also require some data to be kept, and those choices must be documented per request. Chapter V adds a separate question: peers, operators or support staff located or accessing data from a third country can make the arrangement a transfer. Under Article 44 and Article 83, infringements of Articles 44 to 49 carry the highest fine tier, so counsel should review each location and access path before the network holds personal data.

The GDPR requires no audit, attestation or certificate, so no vendor or platform can supply one that makes the network compliant. Article 42 certification is voluntary, is issued for at most three years by accredited bodies or supervisory authorities, and does not reduce the controller's responsibility. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certificates; independent auditors and certification bodies do that work. Ask your counsel to sign off on the lawful basis, retention rules and transfer assessment in writing, and ask your assessor which evidence they expect to see from the Fabric network.

Mapping GDPR requirements to Fabric capabilities and configuration

This table maps each GDPR requirement in scope to what Hyperledger Fabric provides, what the network configuration must set, and who owns the remaining work. Read the Configuration column for settings that only take effect when the network is built as described, and the Client responsibility column for decisions and evidence that no platform feature can supply. The main takeaway is that Fabric supports purging personal data from peers and limits who holds it, but legal decisions, evidence and residual copies remain with the controller.

Requirement	Platform capability	Configuration	Client responsibility
Article 17(1) erasure grounds	Private data purge removes personal data from authorized peers and leaves the hash on the ledger as evidence.	Define private data collections with purge behavior in the collection definition. Confirm parameters in the Fabric private data docs.	Identify which of the six erasure grounds apply, trigger the purge and record each request.
Article 17(3) exceptions	Not a platform feature. Fabric cannot determine whether an exception applies to a request.	None at the platform level. Record the retention decision in the erasure procedure.	The controller and legal counsel decide whether an exception applies and document the basis.
Article 32 pseudonymisation and encryption	Private data collections restrict which organizations hold personal data, while the shared ledger holds only hashes.	Set collection membership policies. Protect MSP and TLS keys, using an HSM for MSP keys through PKCS#11 on custom images.	Map each data set to a collection, select HSM hardware and manage key custody and access.
Article 32 confidentiality and integrity	Mutual TLS secures the operations service, and Fabric CA issues, renews and revokes certificates and generates revocation lists.	Require client certificates on operations endpoints. Configure CA revocation and distribute certificate revocation lists to all members.	Operate the CA, distribute revocation lists on schedule and monitor revocation events.
Article 32 regular testing	Fabric provides health, log and metrics endpoints but does not test erasure or restoration on its own.	Build test cases that write a test record, purge it and confirm that only the hash remains on each peer.	Own the verification runs, their schedule, evidence retention and remediation of failures.
Residual copies (snapshots, backups, CouchDB)	Purged personal data may still exist in snapshots, backups and CouchDB state until those copies expire or are rebuilt.	Set backup retention and snapshot handling to match the erasure procedure. Confirm behavior with the Fabric docs for your version.	Define retention periods, restore procedures and how residual copies are documented and handled.
Article 44 transfers	Every peer holds the data for its collections, so peer, orderer and database placement decides where personal data is stored and processed.	Place peers, orderers, CouchDB and backups in approved locations. Restrict remote administrative access from third countries.	Confirm hosting locations, assess remote access and onward transfers and review cloud provider terms.

How private data collections keep personal data off the shared ledger

Personal data in a Fabric design belongs in a private data collection, not on the channel ledger. A private data collection is a definition that names the organizations allowed to hold the actual value. Only those peers receive the private data, through the gossip protocol and the transient store, while every peer on the channel stores a hash of it in the shared ledger. Before you design anything, confirm the exact collection definition fields and purge settings in the Fabric private data documentation, because the names, defaults and behavior of those settings determine what your erasure procedure can actually do.

The hash is the evidence component. It proves that a specific value existed and was agreed at a specific point in time, and it is what remains on the shared ledger after the private value is gone. The Fabric private data docs describe the purpose directly: parties may want, or be required by regulation, to purge private data from their peers, leaving the hash on the blockchain as immutable evidence. The ledger itself is append-only, so the hash cannot be rewritten. A purge removes the private value from the peers that hold it, but it does not and cannot change the hashed record. For the erasure design, that means the hash must not be a reversible or easily guessable representation of the personal data. Ask your legal and security teams whether a salted or otherwise protected hash meets their view of what counts as personal data, because the hash itself may still be treated as personal data in some cases.

The central design question is which organizations belong to each collection. Membership decides who can read the value, who must honor an erasure, and who must be able to prove that they did. Start by mapping every personal data element to the organizations with a documented need for it, then group those organizations into one collection per distinct need. Avoid collections that include organizations simply because they share a channel. Each added member is another peer that holds personal data, another set of backups and snapshots to account for, and another organization that must coordinate the purge. Record the lawful basis and retention reasoning for each collection so the membership can be defended later.

Peers outside a collection never hold the private value. This is the property that makes the design work, and it should be tested rather than assumed. After deployment, query each non-member peer for the private key and confirm that it returns nothing, while confirming that the hash is present on the channel ledger. Repeat this check after any collection definition change, because changing membership affects which peers should hold the value. Plan the test as part of change management so the result is recorded as evidence.

What evidence the platform produces and how to keep it

A Fabric network that holds personal data produces several kinds of records: governance records for private data collections, channel records, purge events and ledger hashes, operations telemetry and upgrade records. Each needs a defined retention period, a named approver and a clear line between what your team prepares and what an independent auditor or supervisory authority reviews.

Private data collection definitions and history

Collection definitions set which organizations hold personal data, the endorsement policy, and the purge settings such as blockToLive. Keep every version of the collection configuration in your change control system, with the reason for each change, and record the channel definition update that applied it. Before sign-off, confirm the approving data protection owner and the channel administrators who must co-sign each change. An auditor will review this history; DeployOpen prepares it but does not attest that it meets any regulator's expectations.

Channel configuration and capability records

Channel configuration blocks, their signed update transactions and the capability levels enabled on each channel show who changed the network's rules and when. Store the exported config blocks and the signature sets from each channel update in an access-controlled, versioned repository. Check that every member organization can reproduce the current configuration from the stored blocks. Confirm with your channel administrators which records must be retained beyond the network's operating life.

Purge events and ledger hashes

When a peer purges private data, the on-ledger hash remains as the immutable evidence that a transaction existed. Record each erasure request, the decision made, the affected collection and key, the purge timing and the peers where purge ran. Keep these records separate from the personal data itself, since the request log should not reproduce the data being erased. Confirm with your legal and privacy teams how long request records are kept, because the hashes persist on the ledger regardless.

Operations service logs and health data

The operations service exposes /healthz for health checks and /logspec for log level management on peers and orderers, secured with mutual TLS. Ship logs to a central store with retention that matches your incident and audit policy, and capture health check results over time. Record any change to log levels, since verbose logging can itself capture personal data. Confirm who in your operations team may change log levels and who reviews the captured output.

Prometheus metrics history

The /metrics endpoint feeds Prometheus, and its history shows peer and orderer availability, block commit activity and resource trends around erasure runs and upgrades. Set a retention period in your Prometheus or long-term storage configuration and export dashboards and alert rules under version control. Verify that metrics carry no personal data labels. Confirm with your operations lead which periods of metric history must be preserved for each network.

Upgrade records from the four-step process

Fabric's upgrade guide describes four steps: back up the ledger and MSPs, upgrade orderer binaries in a rolling fashion, upgrade peer binaries in a rolling fashion, then update application channel capability levels. Keep the pre-upgrade backup manifest, the binary versions per node, the timing of each rolling step and the capability change approval. Record which 2.5 LTS or 3.x patch release each node runs. Confirm the change approver for each step before the upgrade window opens, since a capability change alters network behavior.

What remains in snapshots, backups and CouchDB after a purge

Ledger snapshots are point-in-time copies a peer can use to join a channel without replaying every block from the beginning. A purge that runs on live peers afterward does not automatically rewrite a snapshot that was created earlier, so the private data it captured may still be present in that file. The controller needs to decide how long snapshots are kept, who may create them and whether a snapshot taken before an erasure can still be used to bring up a peer.

The points to settle with your team include:

Snapshot inventory: Record which snapshots exist, the channel and block height each covers and the peers that generated them.
Erasure cut-off: Decide whether snapshots older than an erasure event are deleted, regenerated or quarantined.
Join behavior: Confirm in the Fabric private data documentation how purged private data is handled when a peer joins from a snapshot.
Restore testing: Test a join from a snapshot taken before a purge in a non-production network and check whether the erased collection data reappears.
Access control: Restrict who can read snapshot storage, since a file copy can be read outside the peer.

Confirm all snapshot join behavior against the current Fabric release you run before you rely on it.

Configuration sequence for an erasure-ready network

This sequence sets the order in which a Hyperledger Fabric network holding personal data is designed and built, so that personal data sits in purgeable private data collections and only evidence reaches the shared ledger. Each step closes with a check that the team can verify before the next step begins.

Map personal data and the organizations that need it
Start with an inventory of the personal data categories the network will handle, the processing purpose for each category, and the member organizations that need access to it. The privacy lead and the data owners review the inventory, and the network architect confirms which organizations form each sharing group. The output is a table listing each category, its documented lawful basis and its recipients. Done when every category has a named owner and a recipient list that the consortium has approved in writing.
Define collections and their purge behavior
The network architect creates one private data collection for each group of organizations that must see the same personal data, keeping each group as narrow as the mapping allows. Each definition lists its member organizations, its endorsement policy and its purge setting, so the configured period sits next to the business reason for it. Confirm the purge parameter and its unit in the private data documentation for the release you run. Purge is time-based, so an individual erasure request may also need chaincode that deletes the record, which the runbook step covers. Done when every category maps to exactly one collection and a purge test on the non-production network removes the data from a member peer.
Keep only hashes on the channel
The chaincode developers design transactions so that the channel ledger holds only a hash of each personal data record, computed as part of the private data transaction, and never the record itself. The hash gives the consortium evidence that a record existed and changed, without exposing its content after purge. The security team reviews chaincode and sample transactions to confirm that no personal fields reach the world state, block payloads or application logs. Done when a ledger query and a block inspection on a test network show hashes and no personal values.
Choose and document the ordering service
Select Raft as the default ordering service for production, and record the node count, the placement of nodes across failure domains and the number of nodes the cluster can lose. Fabric documentation recommends Raft, a crash fault tolerant service that keeps working while a majority of nodes are available, and a five node cluster tolerates the loss of two nodes. If your organization considers Byzantine fault tolerance, the v3.x line includes a BFT ordering service based on SmartBFT that tolerates failures of up to, but not including, one third of ordering nodes. Confirm its operational maturity with the vendor before you choose it. Done when a signed decision record names the service, the version line and the node placement.
Protect MSP keys in an HSM
Place peer and orderer MSP keys in a hardware security module through PKCS#11, and keep TLS keys file-based, as Fabric requires. The prebuilt Docker images are not built with PKCS#11, so the platform team builds custom images that include the HSM client library and tests them against the HSM before deployment. Record key ownership, the HSM partition layout and the rotation procedure. Done when each peer and orderer signs a test transaction with a key held in the HSM and the TLS keys are confirmed to be file-based.
Secure the operations service with mutual TLS
Enable the operations service on each peer and orderer, and require client certificates for every caller so that only identities your monitoring stack is allowed to use can reach the endpoints. The endpoints include /healthz, /logspec, /version and the Prometheus /metrics endpoint or StatsD push. The platform team issues monitoring client certificates from the organization's CA and documents how they are renewed and revoked. Done when a request without a valid client certificate is refused on every node and the monitoring system still collects metrics.
Define the backup and snapshot retention rule
Write one rule for how long ledger backups, MSP backups and ledger snapshots are kept, and state which of them may hold personal data from collections that have not yet been purged. Backups are a common place where purged data survives, so the rule must say whether a restore may reintroduce personal data and how the team handles that case. Include the CouchDB state database in the scope, and confirm with legal counsel how long copies may remain. Done when privacy and operations owners approve the rule and every backup job references it.
Write and test the erasure runbook
Write a runbook that takes an erasure request from intake through identification of the affected collections, chaincode deletion where needed, purge verification on each member peer, backup handling and the evidence record kept on the channel. Assign an owner to each step and set the consortium approval point. Run the runbook on a non-production network with seeded test records before go-live, and record what an independent auditor would be shown. Done when the test produces a complete evidence pack and the team has closed every gap the test exposed.

What the platform does not cover for erasure

Fabric private data collections can remove personal data from peers, but they do not decide whether an erasure request is lawful, how long data must be kept, or where copies live outside the network. Each card below is a decision or control that stays with the controller and its members, not a product defect.

Lawful basis and Article 17(3) exceptions

Article 17(1) lists the grounds that can require erasure, but Article 17(3) sets exceptions, such as compliance with a legal obligation, public health, archiving and research, and the establishment, exercise or defence of legal claims. Whether a request must be honored, refused or partly honored depends on the lawful basis recorded for each data category. Fabric will purge data from peers only after your process has made that decision. Document the basis and the exception reasoning for each collection before go-live.

Retention schedules for private data

Purging removes private data from peers, but it does not tell you when data should be purged. A retention schedule sets the period for each collection, and the private data collection configuration (including block-to-live settings where used) must match it. Confirm with your records owner which periods apply, and check that the schedule covers data held by every member organization in the collection, not only the peer you operate.

Whether a hash is personal data

The on-chain hash is kept as immutable evidence after purging. Whether that hash is itself personal data depends on how it was derived, whether it can be linked back to a person by someone who holds other information, and the context in which it is held. Fabric does not make this determination. Confirm the position with your Data Protection Officer or counsel before you design the hash inputs, and record the conclusion.

Off-network copies made by members

Members often export records to spreadsheets, reports, email or BI tools, and those copies sit outside the ledger and outside any purge. A purge on every peer will not reach them. Your erasure procedure needs an inventory of member exports, a rule for who may create them, and a step that tells each member to delete its copies. Ask each member to confirm in writing that its local copies were addressed.

Applications and chaincode that cache data

Client applications, API gateways and chaincode can store private data in their own caches, search indexes or logs. Fabric's purge applies to the peer state database, so these caches stay populated until something removes them. Map every application that reads a private collection, check its cache lifetime and logging settings, and include those components in the erasure runbook and its test cases.

Backups and snapshots beyond platform control

Ledger backups, MSP backups, CouchDB backups and ledger snapshots made before a purge can still contain the data that was purged. Whether these copies must be altered, restricted or deleted is a retention and restoration decision for your organization. Define how long backups persist, who may restore them, and what happens to purged records if a restore occurs. Test that a restore does not silently bring purged personal data back into live peers.

No Fabric-issued certification

Hyperledger Fabric and its maintainers do not issue a GDPR certificate or attestation for a network or a configuration. The GDPR does not require one either, and Article 42 certification is voluntary and issued by accredited bodies. Readiness evidence, such as configuration records, purge test results and runbooks, must be prepared by your team. Ask any partner to show how that evidence will be produced and reviewed by an independent party you choose.

Where GDPR transfer rules still apply to a Fabric network

Keeping personal data out of the shared ledger does not take a Fabric network out of GDPR Chapter V. Transfer rules follow each copy of the data and each person who can reach it. For a network that uses private data collections, the copies to check include the authorized peers' private state, their CouchDB state databases, orderer and CA hosting, ledger snapshots, backups, and logs from the operations service. EDPB Guidelines 05/2021 (version 2.0) treat remote access from a third country as a transfer, even when the person only views data on a screen for support or administration. They also treat storage in a cloud outside the EEA as a transfer. Article 44 extends the same conditions to onward transfers, so a partner that passes data to its own subprocessor abroad creates a second question to answer.

Before choosing a hosting or operations provider, assess the legal exposure that comes with its home jurisdiction. The US CLOUD Act provision at 18 U.S.C. 2713 requires providers of electronic communication and remote computing services to preserve or disclose data in their possession, custody or control, wherever that data is located. This matters when a provider headquartered in the United States holds peer, backup or support access to EU data. Article 48 limits when a third-country court or administrative order can be recognized in the EU: only where it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. The Guidelines' Example 12 notes that engaging an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be. Map which entities in the provider chain could receive such a request, and record that assessment before signing.

EDPB Recommendations 01/2020 (version 2.0) set the limit of what technical measures can achieve. Where a cloud provider needs access to data in the clear, and the destination's public authorities have powers beyond what is necessary and proportionate, the EDPB states that it cannot envision an effective technical supplementary measure. Fabric private data helps on the ledger side, because payloads stay on authorized peers and only a hash is shared with the channel. That design limits who holds the data but does not by itself settle where the peers are hosted or who can administer them. Ask counsel and the provider which keys, operators and administrative sessions could expose plaintext outside the EEA, including HSM-backed MSP keys and CouchDB access during maintenance.

Transfer tools also change over time, so the current position needs checking at the time of the decision. Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P, so a DPF listing should not be the only basis for a transfer. Keep standard contractual clauses under Commission Implementing Decision (EU) 2021/914 as a documented fallback, noting that the CJEU in Case C-311/18 held the clauses valid while invalidating the Privacy Shield decision. As of October 2026, the GDPR text has not been amended. The Omnibus IV text, procedure 2025/0130(COD), was agreed in negotiations on 26 June 2026 and awaits Parliament's first-reading vote, and the Digital Omnibus, procedure 2025/0360(COD), awaits a committee decision. Plan against the current text and have qualified legal counsel review the transfer analysis for your specific providers and data flows before you rely on it.

Questions buyers ask before hiring help with Fabric erasure

What drives the cost of a Fabric erasure project?

Cost follows the size of the network and the design work it needs. The main drivers are the number of private data collections, the number of organizations and peers that hold each collection, the backup design for ledgers and MSPs, any HSM integration, and the scope of testing, especially purge verification on every affected peer.

HSM work can add cost because Fabric keeps peer and orderer MSP keys in an HSM through PKCS#11, TLS keys stay file-based, and the prebuilt Docker images are not built with PKCS#11, so custom images are required.

One-time costs usually cover the data map, collection design, configuration, the purge test and documentation. Recurring costs cover patching, upgrades and any support retainer you choose.

Most engagements are fixed-scope, so the written scope sets the price. Ask each quote to itemize these components and name who performs each one. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a Hyperledger Fabric erasure engagement take?

Duration depends on the scope agreed in writing before work starts. Four variables set most of it: the depth of your data map, meaning how many systems, fields and copies of personal data feed the network, the number of private data collections to design and test, the number of test cycles needed for purge verification, and the time needed for legal decisions.

Legal review of erasure grounds and exceptions under Article 17 of the GDPR adds time when positions are still open. Changes to the data map midway through the work tend to add cycles.

Ask for a timeline tied to milestones and test cycles, and ask what happens to the schedule if the data map changes. DeployOpen does not give a duration until the scope is written, so treat any early estimate as a question to confirm with the delivery lead.

What does our team need to provide before work starts?

Erasure work needs decisions from people outside the engineering team as well as access inside it. Before work starts, confirm the following.

Legal and DPO input: the erasure grounds you accept, the exceptions you rely on under Article 17(3), and who signs off on retention decisions.
Data owners: a named owner for each collection and each category of personal data.
Network access: reachability to peers, orderers, Fabric CA hosts and the operations service, through your approved paths.
Change windows: dates for peer restarts, channel updates and upgrades, since erasure testing touches all of them.
Inventory: current backups, snapshots, MSP copies and CouchDB instances, plus your test environment.

Write these inputs into the scope so the quote and timeline reflect them.

Can our own Fabric team handle GDPR erasure without outside help?

Yes, if your team already operates Fabric peers, orderers and CAs and has legal support to define erasure decisions. Those two conditions cover the design and the operations side. Your lawyers and DPO still decide the lawful basis and the exceptions.

The hard check is the purge test. Your team should be able to show that personal data is gone from every peer that held the collection, that the hash remains on the channel as evidence, and that the result repeats after restarts, restores and upgrades.

If the team cannot run that test end to end, or has not yet worked through backups and CouchDB copies, a partner can take on the design and test work while your staff keep ownership of operations and decisions.

Does DeployOpen certify that our Fabric network is GDPR compliant?

No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence for compliance assessments, and independent auditors and certification bodies make their own determinations.

The GDPR itself requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance.

Supervisory authorities enforce the GDPR. Your DPO and legal team decide how the regulation applies to your network, and an auditor decides whether your evidence supports your assessment. Ask any partner to show the evidence it will produce and who will review it.

How do we prove a purge worked on every peer?

Run a purge test on every peer that holds the collection, before and after the purge. Confirm that private data no longer returns from queries on each peer, that the hash remains on the channel as evidence, and that the result holds after restarts and upgrades.

Include the state database, including CouchDB where you use it, and any peer rebuilt from a snapshot. A peer that was offline during the purge can reintroduce data when it catches up, so check peers that were down during the test window.

Record test inputs, outputs, timestamps and approvals in your evidence file. Fabric's private data documentation explains that the hash stays on the blockchain as immutable evidence, so have your legal and security reviewers confirm that the hash alone does not reveal personal data.

Does a purge also remove personal data from snapshots, backups and CouchDB?

Not automatically. A purge changes what live peers hold, but copies made earlier can still contain personal data. These include ledger backups, MSP backups taken during upgrades, ledger snapshots used to join peers, and CouchDB data that sits outside the peer's own purge path.

Map every copy in your data inventory and decide how each one is restricted, expired, rebuilt or deleted. Record the decision and the owner.

Test a restore from backup to see whether purged personal data reappears. A restore can bring back data that was purged from live peers if backup design is not aligned with erasure. Confirm how snapshots and purged data interact in the documentation for your Fabric version before you set the retention rules.

How DeployOpen scopes and delivers erasure-ready Fabric configuration

DeployOpen starts by mapping which personal data reaches the shared ledger and which can sit in private data collections that can be purged from peers. We then configure collections, hash evidence, purge behavior and retention around your data flows, and document what remains in snapshots, backups and CouchDB so the design can be reviewed before go-live.

How we scope

Inventory every personal data element that a chaincode would write to the channel ledger or a private data collection.
Agree in writing which collections, endorsement policies and purge settings the engagement will configure.
Confirm which GDPR Article 17 grounds and Article 17(3) exceptions your legal team has mapped to each data category.
Engagements are fixed-scope, and ongoing support for purge testing and upgrades can be added as a retainer.

How we build

Configure private data collections, collection-level policies and purge settings in a non-production Fabric network first.
Design hash-only evidence on the shared ledger so no personal data is written to channel state.
Test purge runs on peers, then check that snapshots, backups and CouchDB copies are handled as documented in your design.
Align the build with the Fabric upgrade steps so later binary or capability changes do not undo erasure settings.

How we hand over

Deliver a written configuration record covering collections, purge parameters, hash fields and endpoints involved.
Provide a remnant register listing where personal data may still exist after a purge, including snapshots, backups and CouchDB.
Document the erasure runbook, including who approves a request, how a purge is executed and how the result is recorded.
Prepare evidence for your own assessors, noting that DeployOpen prepares systems and records but does not issue audit reports or certifications.

How we support

Review collection changes, new chaincode releases and onboarding of new member organizations against the agreed design.
Repeat purge tests after Fabric upgrades on the 2.5 LTS or 3.x lines before those changes reach production.
Keep the remnant register and runbook current as backup, snapshot and storage practices change.
Support can be scoped as a retainer covering review cycles, testing and documentation updates.

Hyperledger Fabric and GDPR erasure with private data purging