Why permissioned ledgers for EU data sovereignty need a different build
Hyperledger Fabric or Besu can be hosted fully inside the EU, but sovereignty depends on where nodes run, who holds the keys, who can reach the systems remotely, and whether personal data ever touches the ledger, not on the platform alone. For a consortium or single operator that must keep a shared ledger in EU infrastructure and answer GDPR and NIS2 questions, the platform choice is the secondary decision. The primary decisions are scenario-specific: which members host which peers and orderers or validators, which cloud accounts, data centers or sovereign hosts carry them, whether any member's support staff or managed-service provider can view data from a third country, and whether a non-EU parent company or cloud provider could be compelled to hand over data it controls. Each of these answers changes the architecture more than the choice between Fabric and Besu does.
Start by mapping every location where ledger data, backups, logs, MSP keys and admin sessions exist, including the ones your consortium partners control. EDPB Guidelines 05/2021 treat remote access from a third country, even only viewing data on a screen for support, as a transfer, and treat storage in a cloud outside the EEA as one too. Confirm with your hosting and support providers which personnel can reach nodes, from which countries, and under which legal orders they can be compelled to act. Then decide where node private keys and MSP or Fabric CA signing material are generated and stored. Plan for an HSM or equivalent key custody inside the EU, and document who can trigger a key ceremony. Ask any provider you are considering to state, in writing, how it would respond to a third-country authority request, because the EDPB treats complying with such a request as a transfer in itself.
The hardest question is personal data. A ledger that replicates to every member cannot be edited to erase a record, so personal data should stay off-chain and only hashes or references should be written to the ledger. This is a data design decision that must be made before the first channel or contract is deployed, and it applies whatever platform you select. This page does not issue attestations or certifications: it describes how to build and evidence controls that an independent auditor or competent authority would assess. Confirm the exact NIS2 obligations that apply to your entity with your national authority and legal counsel, and treat the design notes here as a starting point for that conversation, not as a compliance determination.
Which EU rules shape the ledger design and what each one means for the build
This table maps each EU rule on data location, transfers and sovereignty to a concrete consequence for node placement, admin access and provider contracts. Read each row as a design constraint to settle before the network topology is fixed, and confirm legal interpretations with counsel.
| Rule | What it asks for | Build consequence |
|---|---|---|
| GDPR Article 44 and fine level | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. Infringements of Articles 44 to 49 can draw fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). | Treat every node, backup and log store as a potential transfer point. Record where each personal data field lives and who can reach it before approving a topology. |
| EDPB Guidelines 05/2021 on remote access and cloud storage | Remote access from a third country, even only displaying data on a screen for support, and storage in a cloud outside the EEA both count as transfers. | Restrict vendor support sessions, follow-the-sun administration and monitoring dashboards to EEA-based staff, or document the transfer and its safeguards. Confirm the position with counsel. |
| EDPB Guidelines 05/2021, Example 12 | Using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. | Assess the exposure of each operator, hosting provider and managed service before engaging them. Ask whether the provider's parent company can be compelled to produce data held in the EU. |
| Article 48 and CLOUD Act exposure | A third-country court order is enforceable in the EU only if based on an international agreement such as a mutual legal assistance treaty. The CLOUD Act at 18 U.S.C. 2713 reaches data in a provider's possession, custody or control wherever it is located. | Ask providers for their legal process policy and whether they can refuse non-treaty requests. Keep keys and node operations under EU-controlled management so a provider cannot hand over data it does not hold. |
| Schrems II and the Data Privacy Framework | The Court invalidated Privacy Shield in July 2020 but kept standard contractual clauses valid. Adequacy under Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. | Do not assume a US-headquartered operator is covered by an adequacy decision. Choose between EU-only operation and documented transfer tools, and set a review point for the appeal outcome. |
| EDPB Recommendations 01/2020 on supplementary measures | Where a provider needs data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. | Where personal data must be readable by a non-EU provider, expect the transfer to be hard to justify. Keep personal data off-chain in EU systems and place only pseudonymous references on the ledger. |
| Data Act Article 32 and switching rights | Providers must prevent third-country governmental access to non-personal data held in the EU where it conflicts with EU or national law. Customers may switch to another provider or on-premises infrastructure, with switching charges banned from 12 January 2027. | Write exit and portability terms into the operator contract, including export of ledger state, MSPs and configuration. Confirm the Data Act's application to each service with counsel. |
| NIS2 obligations for node operators | The supporting facts for this page do not set out NIS2 requirements for ledger node operators, so no obligations are stated here. | Confirm with counsel whether your entity or the network falls within NIS2 scope, and which incident reporting and supply chain duties apply to each node operator. |
Fabric or Besu for an EU-hosted network: which fits which governance model
Hyperledger Fabric and Besu both run on infrastructure you control, which keeps nodes and keys in EU locations. They differ in membership model, identity design and how privacy and erasure are handled, so the choice depends on who governs the network and how personal data will be kept off the shared ledger.
Fabric for consortium membership
Fabric is a permissioned framework under Apache 2.0 that is hosted within LF Decentralized Trust and listed there as Graduated. Membership is enforced through identities issued by Fabric CA, so every organization knows exactly who may join and transact. Check whether your consortium will run its own certificate authority in EU data centers and who holds the root keys.
Fabric line choice for production
The Fabric documentation names v2.5 as the long-term support release for production users, and the 3.x line receives patches in parallel. Choosing v2.5 LTS favors stability for regulated operations, while v3.x brings BFT ordering and Ed25519 signing. Confirm which line your governance board has approved and the upgrade path before the network goes live.
Raft or BFT ordering
Fabric recommends Raft ordering, which tolerates crash failures and keeps working while a majority of nodes are available. A five node Raft cluster tolerates the loss of two nodes. Fabric v3.0 added a BFT ordering service based on SmartBFT for cases where members do not fully trust each other, but it tolerates only failures below one third of ordering nodes. Decide which fault model your members will accept before placing orderers in different jurisdictions.
Besu for proof-of-authority networks
Besu is an Apache 2.0 Ethereum client that supports private networks using QBFT or IBFT 2.0 proof-of-authority consensus. It suits consortia that want an Ethereum toolchain and a validator set chosen by the members. It requires JDK 25 to build and run, and its releases are calendar versioned and ship roughly monthly, so the patching process must be planned around that cadence.
Besu local permissioning
Besu permissioning is configured locally on each node, through a permissions file for node connections and another for account onboarding and suspension. Each operator must keep these files in step across the network, which is an operational control to test rather than assume. Ask how changes are approved, logged and replicated, since misaligned files can admit or block participants unevenly.
Removed privacy features and erasure
Besu removed Tessera privacy in version 25.6.0 and onchain permissioning in the same release, and removed the EEA and PRIV privacy RPC API groups in 25.7.0. Designs that relied on those features for private personal data must be rebuilt, usually by keeping personal data off-chain and storing only hashes or references on the ledger. Fabric private data collections work differently, so the erasure design must be checked separately for each platform.
Deployment patterns for node placement and admin access
This pattern places all peer, orderer and CA nodes in one EU region of a cloud account the organization controls, with keys in a key service or HSM in the same region. It is the most common starting point because it is quick to provision and keeps data processing inside the EEA. Sovereignty depends on more than the region name, so the design must also limit who can reach the control plane.
- Node and key placement: Peers, orderers and Fabric CA or Besu nodes run in EU zones, and signing keys stay in an EU HSM or key service that the organization administers.
- Backups and logs: Ledger snapshots, MSP material and log streams are written to EU storage. Confirm that replication, support tooling and log shipping do not copy data to a non-EEA region.
- Administrative access: Restrict console, API and support sessions to named EU-based staff through a bastion or privileged access broker, and log every session.
- Provider access: Confirm in the contract whether provider support staff, subprocessors or follow-the-sun teams can view data or infrastructure from outside the EEA, and what logging applies.
- Data Act switch: Plan for exporting ledger data, MSPs, keys and configuration to on-premises hosts. Test a restore on target hardware before a switch notice is ever needed.
Ask the provider which region, which subprocessors and which support locations apply to your account, and get the answers in writing.
This pattern runs nodes in a data center or a cloud offering that the organization or a contracted EU operator controls more tightly than a general-purpose region. Nodes, keys and backups stay under EU jurisdiction, and administrators work from EU sites under documented procedures. The model suits organizations that want more control over the hardware and the operator chain, at the cost of more operations work. No provider should be assumed sovereign on the strength of marketing.
- Node and key placement: Nodes run on dedicated hosts or a private cluster in the EU facility, with HSMs owned or leased under a contract that names the operator and location.
- Backups and logs: Backups go to a second EU site, and logs go to an EU-hosted SIEM. Record which staff and jobs can read both.
- Administrative access: Use jump hosts in the EU, separate administrator accounts for each node, and a documented approval step for any remote session from a third country.
- Operator control: Confirm who holds root and hypervisor access, whether the operator can be compelled by a non-EU parent or authority, and how that exposure was assessed.
- Data Act switch: Because the hardware and software are already self-hosted, a switch is mainly a move of data, keys and configuration. Document the exit runbook and the target hosts.
Ask the operator for a written description of its ownership, staffing locations and the legal assessment it has carried out for third-country authority requests.
This pattern places nodes, HSMs, backups and log stores in the organization's own data centers or in a network with no route to external services. Software and container images enter through a controlled transfer process. It gives the strongest control over administrative access, but it moves patching, certificate renewal and monitoring work onto the internal team. The Fabric and Besu upgrade cadence still applies, so the transfer process must be repeatable.
- Node and key placement: Peers, orderers, CAs and HSMs sit on internal networks, with keys never leaving the HSM boundary.
- Backups and logs: Ledger backups, MSP archives and logs are stored on internal media with offline copies. Check how restores are tested without a live connection to the internet.
- Administrative access: Administrators sit on a dedicated management network, use hardware-backed MFA, and open sessions through a controlled jump path. Remote administration from outside the EEA is blocked at the network layer.
- Software intake: Binaries, images and CVE feeds arrive through a reviewed import process, with checksums and signatures verified. Besu 26.10.0 notes that the Bonsai database auto-upgrades on first start, so take a backup before each upgrade.
- Data Act switch: Air-gapped sites are already on-premises, so a switch to this model requires only the data, key and configuration migration and a tested restore.
Confirm with your internal security team which patch and vulnerability feeds can be imported, and how often, before committing to this pattern.
How an EU ledger rollout moves from data mapping to supervised operation
The sequence turns a permissioned ledger idea into a network where personal data placement, key custody, identity, erasure design and upgrade procedures are documented, tested and handed over as evidence before production use.
Map data and jurisdiction exposure
The client's privacy, legal and architecture owners list every data element proposed for the ledger and mark which are personal data. For each party and processor that could see, store or support those elements, the team records the country of processing, the entity that controls the infrastructure, and whether a third-country authority could compel access. Remote administration from outside the EEA is treated as a transfer, so support paths are mapped too. The output is a data inventory and jurisdiction register that the client signs off before any placement decision is made.
Design placement and key custody
Using the register, the team decides where each member's peer, orderer or validator nodes run, which cloud accounts or data centers host them, and where node and signing keys are generated and stored. The design states who holds administrative access, from which locations, and how hardware security module (HSM) use fits Fabric or Besu key handling. The client confirms that no node, backup or key material leaves approved EU locations. The output is a placement diagram, a key custody matrix and an access map reviewed by the client's security and legal teams.
Build identity and certificate authority
The team sets up the membership service provider structure and certificate authority, for Fabric using Fabric CA, or for Besu the node and account permissioning files that restrict connections and onboarding. Enrollment, renewal and revocation procedures are written and tested with sample identities, including the process for suspending a member. Administrator accounts receive multi-factor authentication where the platform supports it, and identity logs are routed to the client's monitoring. The output is a tested enrollment and revocation runbook and a record of every issued root and intermediate certificate.
Keep personal data off-chain
The team designs the data model so that personal data is held in an EU-hosted off-chain store that the client controls, while the ledger records only references, hashes or pseudonymous identifiers. Erasure requests are routed to the off-chain store, and the design documents how the on-chain pointer loses its meaning once the underlying record is deleted, and where Fabric private data collections are a candidate for member-restricted data. Legal review confirms the approach with the client's data protection officer. The output is a data flow diagram, an erasure procedure and a documented basis for the design decision.
Build and harden the nodes
Nodes are deployed in the agreed locations using the chosen Fabric or Besu release line, with the JDK and runtime requirements confirmed against release notes before build. Hardening covers network segmentation, restricted peer connections, encrypted transport, operations and metrics endpoints kept off public networks, and logging of authorized user activity. Monitoring dashboards and alerts are configured for node health and consensus status. The output is a build record, a hardening checklist signed off by the security team, and a working monitoring view for each node operator.
Rehearse upgrade and rollback
Before any production change, the team runs an upgrade in a staging network that mirrors production topology. The run takes a full backup of the ledger and identity material, upgrades orderer and peer binaries in a rolling sequence, and tests the rollback path. For Besu, the rehearsal confirms that the backup is restorable, since upgraded databases cannot be opened by older versions. Results are compared with the vendor upgrade documentation, and any gaps are recorded. The output is a rehearsed runbook, a timed rollback record and a go or no-go decision by the client.
Hand over evidence for supervised operation
The team assembles the evidence pack: the data inventory, jurisdiction register, placement and key custody records, identity runbooks, erasure procedure, hardening checklist, test results and the upgrade rehearsal log. Each artifact is cross-referenced to the controls the client must demonstrate. Operators are trained on the runbooks and named owners are confirmed for each node. Ongoing support is agreed separately in writing. The output is a handover package accepted by the client's compliance lead. DeployOpen prepares this evidence for independent assessors and does not issue audit reports or certifications.
What auditors and regulators will ask for and which component produces it
What transfer map and location records will auditors ask for?
Auditors will ask for a written map of every location where personal data or ledger data is stored, processed or accessed, including remote administration sessions from outside the EEA. The map should list each node, its hosting provider and data center location, backup targets, and every support or administration path, because the EDPB treats remote access from a third country, even only displaying data on a screen, as a transfer. The ledger itself does not produce this record. Your cloud or data center inventory, network diagrams and processor register do, and DeployOpen can assemble and maintain that evidence set during the engagement. Ask your auditor which format they expect, and confirm with your legal team how the map maps to your records of processing under GDPR Article 30.
Which access logs prove who used admin sessions on ledger nodes?
Auditors expect logs that show which named person opened an administrative session on each node, when, from where, and what they changed. Access to the host operating system, the peer or orderer container, and the JSON-RPC interface should each be captured. For Fabric, the operations service exposes node health and logging data, while host-level access should flow through your privileged access tool and central log store. For Besu, authenticated JSON-RPC access and node permissioning changes should be logged alongside host sessions. Confirm with your security team that logs are shipped off the node, retained for a period your policy sets, and protected from the same administrators whose actions they record.
How do Fabric CA and Besu permissioning records show key and certificate lifecycle?
Auditors will want evidence that every node and member identity was issued, renewed and revoked under documented control. Fabric CA produces this through its enrollment certificate records, renewal history and certificate revocation lists, and it can use LDAP as its user registry. Besu produces node permissioning and account permissioning configuration files, which should be version controlled and changed only through approved change requests. Keep the issuance log, the approval for each change, the revocation timestamps, and the HSM or key management records for node keys. Confirm with your certificate authority team whether your chosen Fabric CA setup and Besu configuration retain the history your auditor needs, because retention depends on how you back up the CA database and configuration repository.
What erasure request records prove deletion from off-chain stores?
Auditors will ask for a request log that shows each GDPR erasure request, its receipt date, the verification step, the systems searched, the deletion action taken, and the confirmation sent to the data subject. Because the ledger is append-only, personal data should sit off-chain, and the on-chain record should hold only hashes or references. The evidence therefore comes from the off-chain store's deletion logs, backup expiry rules, and the mapping between a reference on the ledger and the record it points to. Illustrative example: if a reference is deleted off-chain, the log should show the deletion event and the backup purge date. Confirm with your data protection officer how exceptions, such as legal holds, are recorded.
What upgrade and backup records will auditors expect for a ledger network?
Auditors will expect a change record for each upgrade and a verified backup taken before it. For Fabric, the upgrade guide sets out 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 backup manifest, the change ticket, the test results and the post-upgrade health check for each step. For Besu, the 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and older versions cannot open it, so a backup taken before the upgrade is the only rollback path. Confirm with your change board how you will record these steps and how long the backups are kept.
Does 16 CFR 314.4 penetration testing apply to a permissioned ledger?
The FTC Safeguards Rule applies to covered financial institutions, and only those organizations should treat its requirements as binding. If you are one, 16 CFR 314.4(d)(2) requires annual penetration testing and vulnerability assessments at least every six months, unless you run effective continuous monitoring. Applied by analogy to a permissioned ledger, the same cadence is a sensible benchmark for the node hosts, orderer and peer endpoints, CA service and JSON-RPC interfaces. Keep the test scope, the tester's report, the remediation tickets and the retest results. DeployOpen runs application, API and infrastructure security testing and prepares this evidence, but the test scope and cadence should be agreed with your compliance lead, and independent assessors decide whether the evidence meets your obligations.
Who prepares this evidence and who assesses it?
DeployOpen prepares the systems, controls and evidence that auditors and regulators review, under a fixed scope agreed in writing before work starts. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors, certification bodies or supervisory authorities make those assessments. In practice, DeployOpen configures logging, documents key lifecycle procedures, builds the transfer map and erasure workflow, and runs test evidence collection. Your organization still owns the processing decisions, the processor contracts and the final sign-off. Ask any implementation partner to show, in writing, which evidence they deliver, which records remain your responsibility, and who holds the retention copies.
How personal data stays off the ledger so erasure remains possible
The design starts from one rule: personal data lives in an EU-hosted off-chain system that can delete it, and the ledger holds only what is needed to prove a transaction happened. In practice, the application writes the customer record to a database inside the same EU infrastructure, applies retention and deletion controls there, and submits to the ledger a reference such as a record identifier plus a salted hash of the document. Shared ledger data then carries no name, address or account detail. Document the data minimization reasoning in the processing record: which fields go on-chain, why a hash is sufficient for integrity, who can resolve the reference, and how deletion in the off-chain store is carried out and verified.
Two platform features are candidates for this split, and both need confirmation in your own build before you rely on them. Hyperledger Fabric private data collections let a defined subset of members hold personal data in side databases on their peers while the channel records only a hash, which keeps the data away from non-authorized members. Besu permissioning, configured through node and account permissioning files, controls which participants can connect and transact, but it does not hide data from members who run a node. Confirm with your partner how a collection's membership and endorsement policy will be set, who can purge data from peer side stores, and how deletion is evidenced to a supervisor.
A hash is not automatically anonymous. If the input can be guessed or linked to a person through other data, or if the hash is shared with parties who hold other identifiers, regulators may treat it as personal data, so the on-chain reference may still fall under erasure and transfer rules. Do not promise erasure from the ledger itself. Ask your counsel to review the hash construction, the reference scheme and the set of parties who can resolve it, and record their conclusion in the data protection impact assessment.
What buyers ask about cost, time and effort for EU ledger projects
What drives the cost of an EU permissioned ledger project?
The main cost drivers are the number of nodes, the hardware security modules protecting node and signing keys, the certificate authority operations, the legal review of where data and keys sit, and the off-chain store that holds personal data. Each member that runs its own node adds hosting, patching and monitoring work. Fabric and Besu have no license fee, so the bill is mostly people, infrastructure and governance time. Ask any partner to split the quote into one-time build work (architecture, data mapping, legal analysis, deployment) and recurring work (node operations, upgrades, certificate renewal, monitoring, testing). Ask which items assume the members' own infrastructure and which assume yours.
Do Hyperledger Fabric and Besu have license fees?
No. Hyperledger Fabric is licensed under Apache-2.0, and Besu is licensed under Apache-2.0 as well, so the software itself carries no license fee. You pay for the infrastructure the nodes run on, the people who operate and upgrade them, the HSMs you choose to buy or rent, and any services you contract for. Commercial support or managed offerings from third parties are separate decisions with their own terms, so confirm licensing for any add-on component before it enters the architecture.
How long does an EU ledger rollout take?
The scope sets the timeline, and no standard duration applies to every network. The variables that move it most are the number of member organizations, whether each member must onboard its own nodes, how many ledger functions and data types are in scope, how much legal analysis the data transfer questions need, and how many integrations with ERP or identity systems must be built. Ask for a written plan with phases, owner responsibilities for each phase and the dependencies that could delay go-live, such as a member's legal approval or HSM procurement.
What does our team need to provide before a ledger project starts?
Before design starts, you need to provide a data map that lists which personal data would enter the ledger, which stays off-chain and where each store is hosted. You also need a named legal owner who can approve data transfer analysis and the GDPR position on erasure, and a list of network members with their roles, their legal entities and the locations where their nodes would run. Finally, name the business owner for governance decisions such as chaincode or contract changes and membership changes. Missing answers on these points usually cause the largest delays.
Can our internal team run a permissioned ledger without a partner?
It is possible, but the work is ongoing. An internal team needs skills in Fabric or Besu operations, certificate authority management, key handling, monitoring and upgrade planning. Upgrades carry specific risks: Fabric v3.0 removed Solo and Kafka ordering and the v1.x legacy chaincode lifecycle, and Besu's Bonsai database auto-upgrades on first start, so rollback requires a backup taken before the upgrade. Assess whether your team can cover node operations, incident response and testing across every member's environment. A partner can take on part of that work under a written scope, and a retainer can cover ongoing support, upgrades and testing.
What changes if a network member is located outside the EU?
A member outside the EU changes the data transfer analysis and the operating model. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. Remote access from a third country, even for support, counts as a transfer under EDPB Guidelines 05/2021. A node hosted outside the EEA may also expose data to third-country legal process, which requires a separate assessment. Ask your legal owner to document the transfer basis, the access model for support staff and the exposure to third-country authority requests before that member receives any node or key.
Which parts of the cost are one-time and which recur?
One-time costs usually include architecture, data mapping, legal analysis, identity and certificate design, HSM setup, initial deployment, integration builds and testing. Recurring costs include node hosting, HSM operation, certificate renewal and revocation, monitoring, security testing, patching, upgrades to new releases and governance work across members. Ask for the recurring items to be priced separately with the assumed frequency of upgrades and testing, so you can compare an offer with your own run budget. Also ask who pays for each member's infrastructure, because that cost sits outside a partner's quote.
What should a written quote for a ledger project include?
A useful quote lists the scope in writing: the number of nodes and their hosting locations, the ledger functions in scope, the integrations, the HSM and certificate authority design, the monitoring and upgrade policy, and the deliverables for compliance evidence. It should also state the assumptions about member participation, the items excluded from scope, such as legal opinions or audits, and the acceptance criteria for each phase. DeployOpen works from a written scope and does not publish a price list, so ask any provider to show how each assumption maps to a cost line.
How DeployOpen scopes and runs EU-sovereign ledger work
The sequence turns a sovereignty requirement into a written scope, a mapped data placement, a network built inside the client's EU infrastructure, and a handover of evidence the client's own assessors can review.
Agree a written fixed scope
DeployOpen and the client agree in writing which network, channels or contracts, member nodes, regions and personal data categories are in scope, along with deliverables and timelines. The client's counsel and data protection officer review the scope before work starts, since DeployOpen does not give legal opinions unless the client's counsel is involved. Done means a signed scope document that names the platform (Hyperledger Fabric or Besu), the release line and the infrastructure locations.
Map data, keys and access paths
The team inventories every place ledger data, node keys, certificate authority material, backups, logs and monitoring data will live, and every person or system that can reach them, including support staff in third countries. Each remote view, storage location and processor is checked against the transfer rules, so the client can see where a transfer would occur. Done means a placement register that the client's assessors can trace, with open questions assigned to named owners.
Decide what stays on-chain
Working with the client's data protection team, DeployOpen separates personal data from ledger entries, so that only hashes, references or pseudonymous identifiers reach the shared ledger, and the personal data sits in EU-hosted storage that can be erased. The design records where each erasure path applies and which data classes need a different method. Done means a data classification and a reviewed design note that the client's counsel has approved.
Build the network inside EU infrastructure
DeployOpen deploys ordering or validator nodes, peers, certificate authority services and any hardware security modules into the client's own EU cloud accounts, data centers or private networks. Identity enrollment, node permissioning and key generation take place in that environment, with keys kept under the client's control. Done means a working network in the agreed regions, with a record of each node's location, owner and key storage method.
Harden access, monitoring and backups
The team applies access controls for administrators, restricts remote administration to approved locations, enables authentication on JSON-RPC or operations endpoints where the platform supports it, and configures metrics, log collection and alerting in the client's environment. Backups of ledger data and identity material are taken before every upgrade, since some platform versions cannot reopen a database after an upgrade. Done means a hardening checklist signed off by the client's security lead and a tested restore from backup.
Test and document the controls
DeployOpen runs security testing against the network, its APIs and administrative paths, then records the findings, fixes and retests. Operating procedures for upgrades, key rotation, certificate revocation and erasure requests are written so the client's staff can run them without the delivery team. Done means a test report with closed findings and a procedures pack mapped to the client's own control framework.
Hand over evidence and runbooks
DeployOpen delivers the architecture, placement register, data classification, configuration records, test results, backup and restore evidence, and runbooks to the client. The client, its auditors or its supervisors decide what the evidence proves, since DeployOpen does not issue audit reports, attestations or certifications. Done means a handover meeting where the client's team confirms it can operate the network and locate each evidence item.
Retain ongoing upgrades and support
After handover, the client may place the network under a retainer covering upgrades, patch releases, continuous testing and support for changes in data flows or regulation. Upgrades follow a documented path with a backup first, rolling upgrades and a review of platform release notes. Done means a retainer scope in writing and a dated upgrade calendar agreed with the client's change board.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), EUR-Lex ↗
- EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V of the GDPR (version 2.0) ↗
- EDPB Recommendations 01/2020 on measures that supplement transfer tools (version 2.0) ↗
- Hyperledger Fabric documentation: Upgrading to the latest release ↗
- Besu docs: permissioning ↗
- Regulation (EU) 2022/2554 (DORA), EUR-Lex ↗
