Permissioned blockchain RFP questions to ask before you choose a partner
If your organization or consortium is choosing a partner to run Hyperledger Fabric or Besu nodes in your own infrastructure, the fastest way to separate credible proposals from sales material is a structured set of permissioned blockchain RFP questions sent in writing before any meeting. Ask every shortlisted partner the same questions, in the same order, and require written answers that name the components, versions and responsibilities involved. The questions below are vendor-neutral: they apply whether the platform is Fabric, Besu, or both, and whether the partner is an integrator, a managed service provider or your own platform team.
Run the evaluation in two stages. First, collect written responses covering node count per member, certificate authority design, key storage, chaincode or contract upgrade governance, cross-member monitoring and the release policy for long-term support lines. Second, hold a scored workshop where the partner walks through a reference architecture for your network, including who hosts each node and where keys live. Attendees should include a security lead, a platform or infrastructure owner, a compliance representative and at least one person who will sign off on the governance agreement between members. Ask the partner to confirm which Fabric or Besu release lines they support in production and how they adopt new patch releases. For Fabric, the LF Decentralized Trust Fabric project page is a useful reference when checking vendor claims about the platform's status.
Score written answers against the questions you can verify, not against confidence in the presenter. Ask for a sample Fabric CA or Besu permissioning configuration with secrets removed, a documented upgrade runbook that includes a backup step before any ledger-format change, and an example of the evidence the partner would hand a supervisor or internal auditor after a change. Confirm the partner's assumptions about which parts are one-time (design, onboarding, first deployment) and which recur (patching, certificate renewal, monitoring, governance changes), and ask for each in the written quote. Note any answer that depends on a product feature you have not personally verified in the vendor documentation, and make the partner confirm it before award.
Which questions to ask about nodes, identity, keys and upgrades
How many ordering nodes should each member run in a Fabric network?
The count depends on the ordering design, not on a fixed number per member, so ask the partner to justify it against your fault tolerance target. Fabric's documentation recommends the Raft ordering service, which is crash fault tolerant and keeps working while a majority of nodes are available. A five node Raft cluster tolerates the loss of two nodes. Ask whether the partner plans ordering nodes separately from peers, which members host them, and how a node outage in one organization affects the others. If the design uses the BFT ordering service added in Fabric v3.0 (based on SmartBFT), ask how the partner sizes the cluster against the one-third failure threshold, since it tolerates failures of up to, but not including, one third of ordering nodes. Confirm that the design is written down per member before any build starts.
How are Fabric CA or Besu permissioning configured across members?
A good answer names the identity source and the permissioning files, then explains who controls each one. For Fabric, ask how Fabric CA registers identities or connects to LDAP as the user registry, how enrollment certificates are issued, renewed and revoked, and how certificate revocation lists are published to every member. For Besu, ask how node permissioning (restricting connections to known participants) and account permissioning (onboarding rules, suspending accounts, restricting actions) are set in each node's permissions configuration file, and whether the same lists are kept in sync across members. Ask who can approve a new member, how a compromised identity is revoked within your change process, and where the authoritative copy of each permissions file is stored. Confirm that Besu's onchain permissioning is not part of the design, since the Besu maintainers have announced its sunsetting.
How are node and signing keys protected, and is an HSM required?
The partner should describe where every private key lives, who can use it, and how it is backed up. Ask whether keys are generated and held in a hardware security module (HSM) for each member, and whether the Fabric configuration uses the HSM integration described in the Fabric documentation. Ask how MSP signing keys are chosen, since Fabric v3.0 added Ed25519 alongside ECDSA. For Besu, ask how node keys are generated, stored and rotated, and how a lost or exposed key is replaced without rebuilding the network. Ask for the list of people with access to key material and the logging of their use. HSM costs are usually a one-time purchase plus recurring support and hosting, so request those lines separately in the quote.
How are chaincode or smart contract upgrades governed across members?
A good answer describes a written approval path, not only a technical deployment step. Ask who proposes an upgrade, which members must approve it, how the new version is tested against a copy of the ledger, and how the change is recorded for auditors. In Fabric, ask how chaincode definitions are approved by the organizations on each channel under the v2.x lifecycle, which the Fabric upgrade docs require before moving to v3.0. In Besu, ask how contract changes are versioned and what happens if a member refuses an upgrade. Ask how the partner separates chaincode changes from network software upgrades, and whether emergency changes follow the same approvals. Confirm that the governance rules are agreed in writing with all members before go-live.
How does monitoring work across members without exposing their data?
The partner should explain which metrics each member exposes, who collects them, and who gets alerted when a node falls behind. Ask whether Fabric's operations service and Besu's metrics endpoints are enabled on every node, how they feed a monitoring stack that each member controls, and how cross-member alerts reach the right operator. Ask how logs of authorized user activity are kept, since the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to log that activity, and ask how long logs are retained and where. Ask who is on call for each node and what the escalation path is when a member's node is down. Request a sample dashboard and alert list before signing.
How does the partner adopt LTS releases and upgrade without losing data?
Ask which release line the network will run and why. The Fabric documentation states that v2.5 remains the long-term support release for production users, while the 3.x line receives patch releases in parallel; ask the partner to confirm the current LTS line at the time of the quote. Ask for the upgrade sequence: the Fabric upgrade guide describes four steps, which are backing up the ledger and MSPs, upgrading orderer binaries in a rolling fashion, upgrading peer binaries in a rolling fashion, then updating application channel capability levels. Ask how Kafka ordering and v1.x lifecycle are retired before a v3.0 move. For Besu, which uses roughly monthly calendar releases, ask how the partner tests each release, and note that the Bonsai database auto-upgrades on first start and older versions cannot open it, so a backup before upgrade is the only rollback path. Also ask how Fabric Gateway client applications are upgraded separately from the network.
What does the partner's engagement cover, and what can our team run alone?
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can provide ongoing support and upgrades as a retainer. Ask the partner to split the scope into design, node build, identity and key setup, monitoring, upgrade runbooks, and training, and to state which parts stay with your staff after handover. Ask what evidence is delivered for your assessors, noting that DeployOpen prepares controls and evidence but does not issue audit reports or certifications. Ask which parts of the quote are one-time and which recur, such as retainers, HSM support and monitoring. DeployOpen does not publish a price list, so the quote follows from the written scope.
Which Besu limits and removed features should the design avoid?
A good partner will tell you which features Besu no longer supports before you design around them. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. Besu 26.4.0 removed Clique consensus, so pure Clique networks can no longer start or produce blocks. The LF Decentralized Trust blog also announced the sunsetting of proof of work consensus and fast sync. Besu requires JDK 25 to build and run, according to the 26.6.0 release notes. Ask the partner to confirm the consensus choice (for example, QBFT or IBFT 2.0 for private networks), the JDK version in your build pipeline, and how privacy between members will be handled without the removed features. Confirm each point against the current Besu release notes before you commit to a design.
How to test a partner's LTS and version policy
Ask the partner which release line it will run and why. Fabric documentation names v2.5 as the long-term support release for production users, while v3.x carries newer capabilities such as the SmartBFT ordering service and Ed25519 signing for MSP identities. The Fabric releases page shows v3.1.5 and v2.5.16 both published on June 18, 2026, so both lines receive patch releases in parallel. A good answer states the line for each network, the criteria for moving a network to 3.x, and who signs off that move. Ask whether the partner tracks security patches on both lines, how long it will keep a line in its supported set, and what happens to a network when its line reaches end of support. Confirm these commitments in the statement of work, because the public release cadence does not tell you what the partner will do for your network.
Besu follows a different rhythm. It uses calendar version numbers and ships roughly monthly, and the maintainers have removed features that many older networks depended on: Tessera privacy and onchain permissioning in 25.6.0, the EEA and PRIV privacy RPC API groups in 25.7.0, and Clique consensus in 26.4.0. Ask the partner for its written test plan for each removal, including a check that your genesis and node configuration still start, that privacy and permissioning workflows still behave as before, and that no application calls a removed RPC group. Also ask how the partner handles the Bonsai database, which upgrades on first start, and whether every upgrade starts with a verified backup, since the 26.10.0 release notes state that older versions cannot open an upgraded database. Set the monthly cadence against your change window, and agree in advance on which releases you will skip.
For end of support, ask for a written policy covering notice periods, the minimum time between a release reaching end of support and your forced upgrade, and whether the partner will extend support for a line during a regulatory review. Ask which Besu release and JDK version the partner targets, since the 26.6.0 release notes state that Besu requires JDK 25 to build and run, and whether a Fabric upgrade from v2.5 to v3.x needs the prerequisite migrations first. Request a dry run of the upgrade runbook in a non-production network, and keep the results as evidence of your change management process.
Fabric and Besu questions differ in what to verify
Fabric networks are organized around membership. Every member runs peers and, in most designs, shares an ordering service, and identity is issued by a membership service provider (MSP) that usually sits behind Fabric CA. Ask the partner to show how enrollment, revocation and the ordering layer are set up in a network like yours, not in a demo.
- Fabric CA and MSPs: Ask how Fabric CA is deployed, whether it uses LDAP as its user registry, how certificate renewal and revocation are run, and how certificate revocation lists are published to every member. A good answer names the CA root and intermediate hierarchy, who holds the admin credentials, and how a departing member's identities are revoked on all peers.
- Raft or BFT ordering: Ask which ordering service the design uses and why. Raft is crash fault tolerant and keeps working while a majority of nodes are available, so a five node cluster tolerates the loss of two nodes. The SmartBFT option added in v3.0 tolerates failures of up to, but not including, one third of ordering nodes. A good answer ties the choice to the trust model between members.
- Chaincode lifecycle and upgrade path: Ask how chaincode definitions are approved by members, who can commit them, and whether every channel is on the v2.x lifecycle. Fabric v3.0 removed the v1.x legacy lifecycle and Kafka ordering, so a good answer includes the migration plan for any network that still uses them.
- Gateway client compatibility: Ask whether client applications can move to a new release separately from the network. The Fabric Gateway client API is compatible with both v2.5 and v3.0, which affects how application teams schedule their work.
Confirm current CA, MSP and ordering behavior against the Fabric documentation for the exact version the partner proposes.
Besu networks are controlled through node permissioning, account permissioning and access to the JSON-RPC API. Because the maintainers have removed several features in recent releases, the questions here focus on what is still supported and how each control is administered on every node.
- JSON-RPC authentication: Ask how access to the JSON-RPC endpoints is authenticated, which API groups are exposed, and who may reach them from which networks. A good answer describes authentication configuration, network segmentation and what happens to nodes that are reachable from outside the member's perimeter.
- Node and account permissioning: Ask whether permissioning is managed locally with a permissions configuration file on each node, and how changes are approved and distributed. A good answer explains which connections are restricted to known participants, how accounts are onboarded or suspended, and who signs off on each change. Ask for confirmation that the design does not rely on onchain permissioning, which the maintainers have sunsetted.
- JDK requirements: Ask which JDK the partner plans to use. Besu 26.6.0 requires JDK 25 to build and run, so a good answer covers how the runtime is patched, how custom images are built and how the JDK version is tested against the chosen Besu release.
- Bonsai database rollback: Ask how the team will roll back a failed upgrade. The Besu 26.10.0 release notes say the Bonsai database auto-upgrades on first start and older versions cannot open it, so a good answer makes a verified backup a required step before every upgrade.
Confirm consensus support, permissioning options and JDK requirements in the Besu documentation for the release the partner intends to run.
Answers that should worry a buyer
Vendors and partners often answer permissioned ledger questions with confident numbers and generic assurances. The six answers below are the ones that tend to produce failed upgrades, unrecoverable identities and disputes between members, so each one is worth probing before you sign.
A node count without a fault tolerance argument
A partner who names a number of nodes per member without explaining what failure that number survives has not designed the network. Ordering fault tolerance depends on the consensus choice. Fabric's documentation recommends Raft, which keeps working while a majority of nodes are available, so a five node cluster tolerates the loss of two nodes. Fabric v3.0 added a BFT ordering service that tolerates failures of up to, but not including, one third of ordering nodes. Ask which consensus they chose, which failures they tested, and who runs each node.
No plan for Fabric CA or HSM-backed keys
Identity and key custody decide who can join the network, who can transact and whether a compromised key can be revoked. A partner should explain how Fabric CA registers identities, connects to a user registry such as LDAP, issues enrollment certificates and handles renewal and revocation. They should also say where node and signing keys live and whether a hardware security module protects them. If the answer is that keys sit on disk with the node, the trust model of the consortium is weaker than it appears.
Upgrades without backups or a rollback plan
Upgrades are where most production ledgers break. Fabric's upgrade guide starts with backing up the ledger and MSPs, then upgrades orderers and peers in a rolling fashion. Besu's 26.10.0 release notes state that its Bonsai database upgrades on first start and that older versions cannot open it, so rollback depends on a backup taken before the upgrade. Ask for the backup procedure, how restores are tested, and who approves the change across all members.
No ownership of chaincode or contract change approval
In a multi-party network, a chaincode or smart contract change alters rules that every member relies on, so it needs a governance path as well as a technical one. A partner should describe who proposes, reviews and approves a change, how channel definitions and endorsement policies are updated, and how members are notified before activation. Fabric's lifecycle requires every channel to move to the v2.x lifecycle before upgrading to v3, so approvals must be planned against that sequence. Ask who holds the approval record.
Monitoring limited to one member's view
A node operator that monitors only its own peers can see its own failures but not a stalled ordering service or a member falling behind. Fabric exposes operations endpoints for each component, and Besu exposes metrics that can be scraped by a monitoring stack. A partner should explain how member nodes feed a shared view of block height, ordering health, certificate expiry and alert ownership, and which party responds at night. Ask who can see the dashboards and who is contractually responsible for each alert.
Treating unsupported Besu features as available
Besu has removed several features that older guides still describe. Its maintainers announced the sunsetting of Tessera privacy, onchain permissioning, proof of work and fast sync, and Besu 25.6.0 removed Tessera privacy and onchain permissioning. Besu 26.4.0 removed Clique consensus, so pure Clique networks can no longer start or produce blocks. A partner who proposes any of these without a plan for migration is designing on a foundation that will not be supported. Ask for the Besu version they target and the feature list checked against its release notes.
How to score partner responses
This table compares the main areas of a permissioned blockchain partner response, with the weight each area deserves, the evidence to require and the answer that should end a bid. Weights depend on your risk profile, so set them before reading responses, and score against written evidence and workshop demonstrations rather than presentation claims.
| Area | Suggested weight | Evidence required | Disqualifying answer |
|---|---|---|---|
| Node count and fault tolerance per member | High | Written topology for each member, ordering or validator count, and the failure cases it tolerates, such as the Raft majority rule or the BFT one-third limit | Topology that cannot survive loss of a single member or ordering node without manual rebuild |
| Fabric CA or Besu permissioning design | High | Documented CA hierarchy, enrollment and revocation procedure, and node and account permissioning files demonstrated in a workshop | No plan for certificate revocation or onboarding rules, or permissioning left to default settings |
| Key protection and HSM use | High | Key lifecycle document, HSM integration approach for signing keys, and a demonstration of key rotation and access logging | Private keys stored as plain files on shared hosts with no rotation or access record |
| Chaincode or contract upgrade governance | High | Written approval workflow across members, version control records, and a test upgrade on a non-production channel | Upgrades applied by one party without agreed member sign-off or test evidence |
| Cross-member monitoring and alerting | Medium | Sample dashboards, alert ownership by member, and how operations service metrics reach each operator | Monitoring visible only to the partner, with no shared alert path for members |
| LTS adoption and upgrade policy | Medium | Stated version policy (for example, Fabric v2.5 LTS or a current Besu release), backup-before-upgrade steps and a rollback plan | Plan to track the newest release on every change with no backup or rollback step |
| Backup and recovery of ledger data | Medium | Backup scope covering ledger and MSPs, restore test results and recovery time targets agreed in writing | Backups never restored in testing or covering only one member's copy |
| Compliance evidence for assessors | Medium | Mapping of controls to the buyer's obligations, log retention settings and sample evidence packs | Claims of compliance without evidence, or any statement that the partner issues audit reports |
How to run the technical workshop with a candidate partner
This sequence turns a vendor pitch into evidence: you see the partner's proposed architecture, watch them perform the operations you will depend on, and read the runbook they would hand over. Each step ends with a result you can compare across candidates.
Share the reference architecture and ordering design
Send the candidate your intended member list, the number of peer and ordering nodes you expect per member, the consensus choice (Raft for Fabric, or QBFT or IBFT 2.0 for Besu), and which members host which nodes. Ask the partner to return a diagram and a written justification for node count per member, ordering fault tolerance, and where each HSM and certificate authority sits. The step is complete when you can state, in one sentence, how many node or ordering failures the design survives and who operates each node. Confirm these choices against your own governance and data residency rules before the session.
Walk through a rolling upgrade on a test network
Ask the partner to run a rolling Fabric upgrade, or a Besu version change, on a test network that mirrors your production topology. For Fabric, the expected sequence is a ledger and MSP backup, orderer binaries upgraded in a rolling fashion, peer binaries upgraded in a rolling fashion, then channel capability levels updated. For Besu, ask how the Bonsai database auto-upgrade is handled and how a pre-upgrade backup enables rollback. Note any step that requires a network-wide pause. The step is complete when you have a timed, logged run with a documented rollback point. Confirm which Fabric line (v2.5 LTS or v3.x) and which Besu release your organization has approved.
Demonstrate key and certificate revocation
Ask the partner to revoke a test member identity in Fabric CA, or remove a node or account from Besu local permissioning, and show the effect on the running network. For Fabric, look for certificate renewal and revocation handled through Fabric CA and an updated certificate revocation list distributed to every member. For Besu, look for edits to the node and account permissions files and confirmation that a rejected peer cannot reconnect. Ask where the private keys sit, whether an HSM is used, and who holds the administrative credentials. The step is complete when the revoked identity is shown to fail, and the partner can point to the log entry that records it.
Show monitoring across all members
Ask the partner to show a dashboard or log view that covers every member's nodes, not only their own. For Fabric, ask how the operations service exposes health and metrics for peers and orderers, and how an alert on one member reaches the others. For Besu, ask which metrics are collected and how the feed from each node is aggregated. Ask who is paged, who can silence alerts, and how access to the monitoring system is itself controlled. The step is complete when you have seen a simulated node outage appear on the shared view with the expected alert and owner.
Review the written runbook
Request the runbook the partner would deliver for your environment, and read the sections on backup and restore, key rotation, chaincode or contract upgrade approval, incident response, and the LTS adoption policy. Check that each procedure names an owner, a trigger, and the evidence it produces, and that the runbook covers every member, not only the partner's own nodes. Ask how the runbook is kept current when Fabric or Besu releases new versions. The step is complete when you have a list of gaps to close in the statement of work and a confirmed date for the revised runbook, agreed in writing.
What a quote should contain for a permissioned network
A quote for a permissioned network should follow from a written scope, and the buyer should be able to see each component priced or estimated on its own line. Ask for separate lines for node hosting per member (ordering nodes, peers or Besu validators, and the environments they run in), for HSM or key custody (the hardware or cloud key service, the number of HSM partitions, and who holds the administrator roles), for Fabric CA or Besu permissioning setup (certificate authority design, enrollment and revocation procedures, or the node and account permissioning files), for upgrade and monitoring work (the Fabric or Besu release line being supported, rolling upgrade rehearsals, and the metrics and alerting you will see across members), and for governance support (the runbooks, change records and member onboarding work). Each line should name the party doing the work, whether that is DeployOpen, your staff or a member's operator.
Separate what is paid once from what recurs. Design, identity and certificate setup, initial node builds, HSM integration, the first monitoring configuration and the first upgrade rehearsal are typically one-time work. Certificate renewal, node hosting, monitoring operations, patch and release adoption, backup verification and member onboarding recur, and they grow with the number of members and nodes. Ask the partner to state which items are fixed-scope and which are retainer-based, and what changes the price if a member joins late or a second release line must be supported. Also confirm that the quote does not include license fees for Fabric or Besu, since both are Apache-2.0 licensed, so the cost sits in people, infrastructure and governance. Cost of smart contract development or audits, if in scope, should appear as its own section rather than hidden in platform work.
What buyers ask before hiring outside help on permissioned ledgers
What drives the cost of a permissioned blockchain implementation?
The cost follows the number of members, nodes and the governance work between them, because Hyperledger Fabric and Besu are open source and carry no license fee. The main cost components are node hosting and infrastructure per member, hardware security modules where keys must be held in hardware, certificate authority setup, custom chaincode or smart contract development and any security review of it, monitoring, and the coordination effort of agreeing membership, policies and upgrade rules across parties. Ask any quote to separate one-time build work from recurring operations, upgrades and support, and to show who pays for each node.
How long does a scoped permissioned ledger rollout take?
Duration depends on how many members must agree before the first node starts, how much smart contract logic is new, and how mature the infrastructure and identity services already are. Member onboarding and governance agreements often take longer than the technical build, so they should be scoped separately. No general duration applies, so ask for a timeline tied to a written scope with named milestones, including identity enrollment, a test network, security testing and a production cutover. Fixed-scope engagements agree deliverables and timing in writing before work starts.
What does the work need from our own staff?
Your staff need to make decisions that only your organization can make, and to supply access to the systems the network must integrate with. The usual inputs are:
- A named business owner for membership, data sharing rules and dispute handling
- Platform and infrastructure staff who will host the nodes and approve cloud or data center accounts
- Security and key management owners who will approve HSM use, certificate policy and access control
- Application owners for the ERP or other systems that will submit transactions to the ledger
Agree these roles in the statement of work so the implementation does not stall on decisions that were not assigned.
Can our team run the network without an outside partner?
Yes, if you have the skills and staffing to operate it, and a partner can help you reach that point. Running a node means handling identity enrollment and revocation, key protection, monitoring, backups and version upgrades, and the upgrade path itself is a multi-step process that includes a ledger backup, rolling binary upgrades and channel capability updates. Fabric 3.x and the 2.5 LTS line receive patch releases in parallel, and Besu ships roughly monthly with calendar versioning, so someone must own that release calendar. Evaluate your team against those tasks before deciding who runs each node.
What happens after a permissioned ledger goes live?
After go-live the network needs ongoing operations that go beyond the initial build. Typical recurring work includes monitoring each member's nodes and ordering service, rotating and renewing certificates, applying patch releases, planning larger upgrades, and reviewing access and permissioning changes when members join or leave. Ask whether post-launch support is covered by a retainer, what response coverage it includes, and how upgrades across members will be coordinated, because a change on one node can affect the rest of the network.
How do Fabric or Besu upgrades affect a live network?
Upgrades change the operating plan, so they should be scoped and budgeted as recurring work. For Fabric, the upgrade guide describes four steps: back up the ledger and MSPs, upgrade orderers and then peers in a rolling fashion, and update application channel capability levels. Fabric v3.0 also removed Solo and Kafka consensus and the v1.x legacy chaincode lifecycle, so networks on those must migrate first. 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 each partner how they test these steps before they touch production.
Which compliance evidence will the implementation need to produce?
The evidence depends on your regulator and sector, so confirm the requirements before the scope is fixed. In US financial services, for example, the FTC Safeguards Rule at 16 CFR 314.4 requires encryption of customer information, multi-factor authentication, change management and logging of authorized user activity, and the rule's testing provisions call for penetration tests and vulnerability assessments at least every six months unless continuous monitoring is in place. Ledger records may also fall under retention rules such as SEC Rule 17a-4(b) for broker-dealers. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the findings.
What should a partner's scope document include?
A useful scope names the members and the nodes each one hosts, the ordering or validator design, the certificate authority and key storage approach, the smart contract lifecycle and who approves changes, the monitoring setup, the upgrade policy and the handover of operational runbooks. It should also state which items are one-time, which recur, what the buyer must provide, and how acceptance is tested. Ask for the scope to be written before work starts, since fixed-scope terms depend on it.
How DeployOpen scopes and supports a permissioned ledger evaluation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a permissioned ledger, that means the Fabric or Besu nodes, the certificate authority or validator setup, the monitoring stack and the runbooks run in the cloud accounts, data centers or air-gapped networks the members have chosen. Nothing in the engagement model requires a consortium member to hand its keys or node operations to a third party. Before any evaluation starts, ask a candidate partner to show where each member's nodes, Fabric CA or Besu permissioning files, and key material would physically sit, and who holds administrative access to each.
Most DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work begins, so an RFP response can be compared on the same list of items: the number of nodes per member, the identity design, the upgrade plan for the chosen Fabric or Besu release line, and the monitoring and backup scope. Work that continues after go-live, such as applying patch releases, planning migrations between release lines, rotating certificates and reviewing permissioning changes, is typically covered by a retainer for upgrades and support. Ask for the written scope and the retainer terms separately, and confirm which member-side tasks, such as approving admission of a new organization to the network, stay with the consortium's governance process.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration baselines, access records, backup and restore results, and change records for upgrades. It does not issue audit reports, attestations or certifications. Those come from independent auditors, supervisors or certification bodies, and the requirements behind them should be confirmed with each member's own compliance and legal teams. Ask any candidate partner to state, in writing, which evidence items they will produce, in what format, and who signs off on each one.
