Outsourcing Besu node operations under DORA

Outsourcing Besu node operations under DORA third-party rules: what must be settled first

Article 28 of DORA applies before the contract is signed, and the financial entity stays fully responsible for compliance throughout. Since 17 January 2025, an entity considering an outside firm for Besu validator or RPC node operations must assess whether the service supports a critical or important function, check supervisory conditions, identify ICT concentration and other risks, carry out due diligence on the provider, and record any conflicts of interest. Outsourcing the work does not transfer the obligation. Under Article 28(1), ICT third-party risk is managed as part of the entity's own ICT risk management framework, so the Besu network stays inside that framework even when a partner runs it. Some of this preparation can be supported by the platform and by a partner. The Besu documentation describes node permissioning and account permissioning files, JSON-RPC authentication options and key handling, which give the entity concrete facts to write into its assessment. A partner can document how those controls are configured in the entity's own infrastructure and assemble evidence for audit rights and the exit plan. The strategy on ICT third-party risk, the decision that a function is critical or important, the risk acceptance, the choice of provider and the notice to the authority for planned arrangements remain decisions the entity must make and own.

DeployOpen prepares systems, controls and evidence for these assessments. It does not issue audit reports, attestations or certifications, and DORA itself sets no certification scheme, so the entity should not treat any partner document as a regulatory approval. Before shortlisting a firm, confirm with counsel and the supervisor where needed which register fields, notice periods and contract terms apply in the entity's member state, and ask the partner to show, in writing, how each Article 28 item will be evidenced. The practical starting point is a written scope listing every node role, network segment and key the partner would touch, which the entity can then test against the register of information required by Article 28(3). Agree on that scope, the data locations required by Article 30(2) and the audit and exit terms before any node access is granted, because changing them after go-live is harder than settling them in the contract.

Which DORA Article 28 duties map to Besu platform capabilities and configuration

This table maps each Article 28 duty to the Besu feature, configuration or upgrade behavior that supports it. Rows marked with a dash show duties that the platform cannot decide, so the entity's own contracts, governance and records must carry them. Use it as a checklist before the outsourcing contract is signed.

Article 28 duty	Besu capability and configuration	Where the platform does not decide the outcome
28(1) and 28(2): ICT third-party risk within the ICT risk framework and a third-party strategy	Document each node role (validator, bootnode, RPC) and the outsourced operator's access to each one in the ICT risk register. Record which Besu version and client upgrade path the operator may apply.	Strategy, policy and risk appetite are organizational decisions. Besu cannot set them, and the entity stays fully responsible.
28(3): Register of information	Keep an inventory of every node, its host, the operator and the Besu version in use. Track the permissions files and JSON-RPC credential holders for each arrangement.	The register itself is maintained by the entity. Ask the operator for a current node and version inventory on a fixed schedule.
28(4): Pre-contract assessment and due diligence	Confirm which Besu functions support a critical or important function, such as validator participation or transaction submission, and scope the operator's access to match.	Whether a function is critical or important is a judgment the entity must make. Besu does not classify services.
28(5) and 28(6): Information security standards and audit rights	Enable node permissioning and account permissioning through local permissions configuration files. Use JSON-RPC authentication with credentials files or JWTs validated against a public key (RS256 to ES512), and place Besu behind an HTTPS terminator because Besu does not terminate HTTPS itself. Enable metrics with `--metrics-enabled` for audit evidence.	Auditor access, audit frequency and standards are contract terms. Confirm with the operator which third-party certifications it holds. Besu does not provide them.
28(7): Termination rights and exit conditions	Permissions files and JWT or credential material are the controls the entity can revoke on termination. Plan revocation as a runbook step, including removing node keys from peer allowlists.	Termination triggers and contract remedies are negotiated in the contract, not set by Besu.
28(8): Tested exit strategy and transition plan	Take a full node backup before any upgrade. Release 26.10.0 auto-upgrades the Bonsai database on first start, and older Besu versions cannot open an upgraded database, so rollback depends on that backup. Keep node private keys in an HSM through the `--security-module` option where available, since the local key file is not encrypted.	Whether the chain can be transferred to another operator, and how validator keys are moved, depends on the consensus setup and the HSM vendor. Test the transition on a segregated system.
Key handling supporting Article 28 security duties	Node private keys are stored unencrypted in the local key file by default. An HSM plugin can be connected with the `--security-module` option. Confirm supported HSM plugins and their versions with the vendor before use.	HSM procurement, key ceremony and custody rules are set by the entity and its HSM provider.

What Article 28(4) due diligence requires before a Besu node contract

Before signing a contract for Besu node operations, the financial entity must assess whether the service supports a critical or important function under Article 28(4) of DORA. This classification drives everything that follows, including the depth of due diligence, the audit scope and the exit plan. A validator node that seals blocks for a settlement or tokenization network almost certainly supports a critical or important function, but the entity should document that reasoning rather than assume it. The same assessment must cover supervisory conditions, the entity's ICT concentration risk if one provider runs several nodes or several consortium members rely on the same firm, and any conflicts of interest between the provider and other participants on the network.

The Besu topology changes the answer. The number of validators sets how much of the network's ability to finalize blocks depends on a single operator, so the entity should ask the provider how many validators it runs, which other members' validators it operates, and what happens if it loses quorum. RPC exposure matters separately: an RPC node that the provider operates on the entity's behalf determines who can submit transactions and read state, so the entity should confirm which JSON-RPC methods are exposed, how authentication is enforced (for example through the --rpc-http-authentication-enabled option and credentials or JWT validation) and who can change those settings. On a shared consortium network, the provider may also hold permissioning rights that affect other members, which raises concentration and conflict questions.

For the assessment to be complete, the entity should request written answers on the provider's security certifications and controls, its incident history on the Besu network, its key custody model for validator and node keys, its staffing and geographic location for administration, its subcontractors, and its own dependence on third parties for hosting or cloud services. Ask for the provider's exit assistance and data return terms, and confirm whether the provider will accept the audit frequency and scope the entity needs under Article 28(5) and (6). Where the provider cannot answer a question, record that gap in the assessment, since the entity remains fully responsible for compliance.

Which contract terms Article 28 requires for node operations

Article 28 expects the contract with an outside operator to carry the controls that let the financial entity keep oversight and leave cleanly. The six terms below work together: they define who can inspect, when the contract can end, where data sits, what happens to data at the end, which security standard applies, and how exit is supported.

Audit and inspection rights

Article 28(5) and (6) allow contracts only with providers that meet appropriate information security standards, and they expect audit and inspection frequency and scope to be risk-based and fixed in advance. For a Besu operator, write down which nodes, RPC endpoints, key-handling records, change logs and backup evidence the entity may inspect, how often, and by whom. Check that the clause follows commonly accepted audit standards and that the operator can supply evidence on request without a new negotiation.

Termination rights

Article 28(7) requires the contract to be terminable in defined situations: significant breaches, circumstances that could change how the service performs, evidenced weaknesses in the provider's ICT risk management, and conditions that prevent effective supervision. For node operations, these triggers should be written as specific events, such as a missed key-custody control or a refusal to grant regulator access, so the entity can act without arguing over whether a breach occurred.

Service and data processing locations

Article 30(2) requires the contract to state where services are provided and where data is processed, and to require advance notice before those locations change. For Besu, confirm the countries and data centers that host validator nodes, RPC nodes, backups and logs, including any subcontracted cloud region. Ask the operator to name every location in the contract schedule and to notify the entity before a move, so the entity can reassess its risk.

Data return on insolvency or termination

Article 30(2) also requires the contract to cover how data is returned if the provider becomes insolvent or the contract ends. For a Besu network, define what the operator must hand back: node configuration, permissioning files, metrics and log archives, backup sets and any operator-held records of key handling. Confirm the format and timing with the operator, and test that the returned material can be read by a different team.

Information security standard compliance

Article 28(5) allows the entity to contract only with providers that comply with appropriate information security standards. The contract should name the standards and the evidence the operator will provide, such as independent assessments or certifications it already holds, and it should require notice when that evidence changes. Ask for the scope of each assessment, because a certificate covering the corporate office may not cover the hosts that run validator keys.

Exit strategy and transition support

Article 28(8) requires documented and tested exit strategies and transition plans for services that support critical or important functions. The contract should commit the operator to cooperate with a transition: handing over node operations, validator key custody and runbooks, and supporting a rehearsal on a non-production network. Agree the level of support, and who pays for it, before the contract is signed.

How to record the arrangement in the register of information

This sequence gives the financial entity a register entry for the Besu node operations arrangement that is complete at entity level, correctly consolidated where relevant, reportable on the yearly cycle, and producible on request. It also ensures the competent authority hears about the arrangement before it starts if the service supports a critical or important function.

Confirm the arrangement is a register entry
Before the register is updated, the risk owner confirms that the outside firm's node operation, support or hosting work counts as an ICT service under the entity's contractual arrangements, including any sub-contracted support. Legal and the ICT third-party risk function record this in the decision file. The output is a written scoping note stating the service, the contracting entity and the contract reference, so the register entry has a clear source.
Record the arrangement at entity level
The third-party risk function adds the arrangement to the entity's register of information on all contractual arrangements for ICT services, as Article 28(3) requires. Entries should capture the provider, the service description, the locations where services are provided and data is processed, and whether the service supports a critical or important function. The output is a register line that matches the signed contract and the scoping note.
Extend the entry to sub-consolidated and consolidated levels
Where the entity sits within a group, or the group applies DORA on a sub-consolidated or consolidated basis, the group function determines whether the arrangement must also appear in those registers. Article 28(3) requires registers at these levels where relevant. The output is a documented decision on each level, with the reason, held by the group risk function so that the entity and group figures stay consistent.
Confirm the yearly reporting path with the competent authority
Compliance confirms with the national competent authority how the yearly reporting obligation for new arrangements will be met. The ESAs' Q&A 2025_7309, published 14 August 2025, states that the yearly submission of registers of information to the ESAs generally satisfies the Article 28(3) yearly reporting obligation, without a separate communication. Because national practice can differ, the output is a written confirmation from the authority or a documented note of its published guidance.
Give timely notice for critical or important functions
If the Besu node arrangement supports a critical or important function, the entity notifies its competent authority of the planned arrangement in good time before contracting. Article 28(3) requires this notice, and the pre-contract assessment under Article 28(4) should be complete first. The output is a dated notice on file, with the supporting risk assessment attached and the authority's response, if any, recorded.
Hold the register ready for production on request
The entity keeps the register in a form it can provide to the competent authority on request, as Article 28(3) requires. Named owners, a current version history and a link from each entry to its contract, risk assessment and exit plan make this practical. The output is a tested extract of the register for this arrangement, produced by someone other than its maintainer, showing that the entry can be retrieved and explained without delay.
Update the entry when the arrangement changes
The register is kept current after go-live. Changes to the provider's locations, sub-contractors, service scope, or the critical or important function classification trigger an update and, where planned arrangements are involved, a fresh notice to the authority. The output is a change log against the register line, approved by the third-party risk function, so that the yearly submission reflects the arrangement as it stands.

What evidence an examiner will ask for on outsourced Besu operations

An examiner reviewing an outsourced Besu network will trace one question through several records: who provides the service, why that provider was chosen, what the contract allows, and how the entity would leave. Each card below is one piece of that trail, with notes on how Besu configuration and logs feed it and how to keep it current as the client moves through the monthly release cadence.

ICT third-party strategy and policy

This is the board-approved statement of how the entity uses ICT third parties, including its policy on services that support critical or important functions. For a Besu network, the policy should name which node roles (validators, RPC, bootnodes) may be run by an outside firm and which must stay in-house. Review it at each planned Besu upgrade, since a change in client version or role can move a service into or out of scope. Confirm with your compliance lead how often the policy is reviewed and who signs off.

Risk assessment and due diligence file

Before contracting, the entity must assess whether the Besu service supports a critical or important function, the concentration risk, and the provider's security posture, and must check for conflicts of interest. The file should record which validators and keys the provider can touch, the Besu version in use, and the provider's own evidence of secure operations. Refresh the assessment when the client moves from one release to another, for example from 26.7.0 to 26.8.0, because the risk profile of a database format change differs from a routine patch.

Register of information entries

The register lists every contractual arrangement for ICT services, including the provider, the services, and where data is processed and stored. For Besu, record the node locations, the regions holding any copies of node data, and the systems that hold validator or node key material. Article 30 also expects contracts to state data location and data return on termination. Update the register whenever a release changes hosting, a new monitoring tool receives Besu logs, or a provider adds a subcontractor.

Signed contract with audit and exit clauses

The contract must allow termination for significant breaches or regulatory conditions, and must set the audit scope and frequency. Ask that audit rights cover node configuration, permissioning files, key handling records and upgrade change logs, not only the provider's general policies. Confirm that the contract requires the provider to support migration of node data and keys to a successor, and that it addresses data return on termination. The clauses should be reviewed by counsel against the entity's own regulator's expectations.

Permissioning files and access logs

Besu's local permissioning uses a node permissions file and an account permissions file on each node, so the examiner can see which peers and accounts were allowed at a given date. Keep these files under version control and record every change with an approver, because permissioning is the control that limits who the provider's operators can reach on the network. Pair them with JSON-RPC authentication records and access logs from the node and the reverse proxy. Check that logs survive each upgrade, since a new Besu release may change log formats.

Tested exit and transition plan records

Article 28(8) requires a documented exit strategy and transition plan for services supporting critical or important functions, and the plan must be tested. For a Besu network this means a rehearsed move of validator and node roles to another operator or to in-house staff, with proof that the new team can open the database and sign blocks. Note that a newer Besu version can write a database that older versions cannot open, so the rehearsal must include a backup taken before any upgrade. Record the test date, scope, findings and the Besu version used.

What a tested Besu exit plan must cover, by situation

A planned termination gives the financial entity time to prepare, so the exit plan should assume the provider is still cooperating. The main risk is that the entity has no independent copy of what it needs to run the nodes itself, or that the provider's last version of the node database cannot be read by the software the entity plans to use. The plan should name the owner of each artifact before notice is served.

Node key custody: Confirm where each node key sits. The Besu documentation states that the local node private key file is not encrypted, so a key file copied during handover is a full secret. If an HSM or security module plugin, such as the Besu HSM plugin used with the --security-module option, holds the keys, confirm how the entity regains operational control of that module.
Database version: Bonsai auto-upgrades on first start and older Besu versions cannot open an upgraded database. Agree which Besu version the provider runs at exit and do not allow an upgrade during the handover window without a backup.
Permissioning files: Obtain the node and account permissions configuration files and the current allowlist state, and confirm the entity can update them without the provider.
Documented runbooks: Require the provider to hand over build, configuration and monitoring documentation, plus the Prometheus and log pipeline settings.

A test should start a replacement node from the handed-over keys, configuration and a backup, confirm it syncs and matches the expected state, and record the outcome.

How Besu version changes affect third-party control

Change control over the provider's Besu client versions is the part of outsourcing most often left vague, and it is where the entity can lose the ability to supervise its own ledger. Besu has removed features that some permissioned networks relied 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. Besu 26.4.0 means a pure Clique network can no longer start or produce blocks, so a version bump can stop validation outright rather than degrade it. The entity should ask the provider to list every removed or deprecated feature in use on its nodes and to confirm which releases affect them before any upgrade is scheduled.

Besu now uses calendar version numbers and ships roughly monthly. The release list in the project's GitHub releases page shows 26.7.0, 26.8.0, 26.9.0 and 26.10.0 in quick succession during 2026, and the 26.6.0 release notes state that Besu requires JDK 25 to build and run. A runtime change such as a new JDK requirement touches the host image, not only the client, so the entity needs to know whether the provider patches hosts and JVMs on its own schedule. The 26.10.0 release notes also say the Bonsai database upgrades automatically on first start and older versions cannot open it, so an upgrade is effectively one-way unless a backup was taken beforehand. Confirm who takes that backup, where it is stored, and how a restore is proven.

The contract must state who approves each upgrade, who tests it, and who bears the consequence if it fails. A workable split gives the entity approval authority over any release that changes consensus behavior, genesis, permissioning or the database format, and requires the provider to test the release on a segregated copy of the network first, with written results delivered before the change window. The entity should also set a rule for release currency, such as the maximum number of releases a node may lag, and agree who may stop a rollout. Those terms are commercial and operational choices. DORA sets no specific upgrade timetable, so the entity should derive these rules from its own change management and risk appetite and then confirm them with its supervisor where needed.

What the platform and DeployOpen do not settle for Article 28

Is our Besu node service a critical or important function under DORA?

That is a decision the financial entity makes, not the Besu software or DeployOpen. Article 28(4) requires the entity to assess, before contracting, whether the ICT service supports a critical or important function. Consider what the node serves: whether validators or RPC endpoints carry settlement or tokenization flows, how long an outage could be tolerated, and what the entity's own business continuity analysis says. Record the reasoning in the assessment file, because that classification drives the register, notice, exit and audit obligations that follow. Ask any outside firm to support the analysis with information about the service, but keep the conclusion with your risk function.

When must we notify the competent authority about a Besu node arrangement?

Article 28(3) requires timely notice to the competent authority of a planned contractual arrangement on an ICT service supporting a critical or important function. The Regulation does not give a fixed number of days in the supplied text, so confirm the notice window and format with your supervisor before signing. Separately, the ESAs stated in final Q&A 2025_7309 that the yearly submission of registers of information generally satisfies the yearly reporting obligation for new arrangements, without a separate communication. Build the notice step into your contracting timeline so it does not become the critical path.

What will the competent authority accept as evidence of compliance?

DORA sets no certification scheme, and supervisors assess compliance using their supervisory powers under Article 50. No standard product or firm can give you a DORA certificate. The evidence supervisors typically ask for is the documented assessment, the register entry, the contract terms, the exit plan and test records, and the monitoring of the provider's performance. The only authority-issued attestation the Regulation provides for concerns a threat-led penetration test under Article 26(7). Confirm the expected evidence set with your national competent authority, since practice differs by member state and entity type.

How do we negotiate audit and inspection rights with a Besu operations provider?

Article 28(6) requires a risk-based audit and inspection frequency and scope, fixed in advance, that follows commonly accepted audit standards. Negotiate the right to inspect the systems, runbooks, change records, access logs and key handling that touch your nodes, and the right for your auditors and supervisors to do the same. Agree how access to shared facilities is handled and how sub-contractors are covered. DeployOpen works from a written scope, so the audit clause, evidence list and reporting cadence should be agreed in the contract before any node is touched. Have legal counsel check that the clause matches your supervisory obligations.

How do we verify that a provider meets appropriate information security standards?

Article 28(5) allows contracts only with providers that comply with appropriate information security standards. Ask the provider which standards its management system is built on, which independent assessments it has undergone, and for the scope and date of each report. Confirm which of those documents are issued by an independent auditor or certification body. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so you should not accept a self-declared document as proof. Check each claim against the scope you contract for.

Does the Besu software itself meet DORA third-party requirements?

No. Besu is an open-source Ethereum execution client, and DORA duties sit with the financial entity, which remains fully responsible for compliance at all times under Article 28(1). Besu can support controls such as local node and account permissioning, JSON-RPC authentication and Prometheus metrics, but those are configuration choices you own and must evidence. Registers, contract terms, exit strategies, due diligence and audit arrangements are organizational documents. Treat the software as one input to your ICT risk framework, and map each Besu feature to the control it supports rather than to a compliance claim.

Can we build the Article 28 file ourselves instead of hiring a partner?

Yes, many entities maintain the assessment, register and exit plan in-house, and an outside firm can only support that work. Decide which parts you keep: the critical-function decision, the risk acceptance and the supervisor relationship are normally yours. Work that can be shared includes technical documentation of node topology, configuration evidence, backup and restore procedures, and exit test preparation. Cost depends on how much of the operating model changes, how many nodes and organizations are involved, and how much evidence must be produced. Ask any provider for a written scope that lists which Article 28 artifacts it delivers and which remain with you.

What should a tested exit plan for Besu node operations contain?

Article 28(8) requires documented, tested exit strategies and transition plans for services supporting critical or important functions, and Article 28(7) requires termination rights for specified circumstances. A practical plan names the data and configuration to return, including node keys held outside the platform, genesis and permissioning files, and the backups needed for restoration. It also identifies a replacement operator or in-house team, the time needed to bring nodes under new control, and the test that proves the handover works. Write the plan before go-live, and test it on a segregated environment so the result is evidence rather than an assumption.

Sequence for preparing a Besu node outsourcing file

This sequence gives a financial entity an ordered file covering the DORA Article 28 checks, contract terms, access and key controls, register entry, exit testing and audit planning that must exist before an outside firm touches its Besu nodes. Each step closes with a record the entity can show a supervisor.

Classify the function the nodes support
Start by deciding whether the Besu validators or RPC nodes support a critical or important function under DORA Article 28(4). The entity's risk, compliance and business owners should document which payment, settlement or tokenization processes depend on the nodes, what happens if they stop, and which ledger data is affected. This classification drives how deep every later step must go. Done means a signed classification memo that names the function, the owner and the reasons for the conclusion.
Run the pre-contract risk assessment
Before contracting, assess the proposed provider against the Article 28(4) items: supervisory conditions, all relevant risks including ICT concentration risk, due diligence on the firm's security and operating record, and conflicts of interest. Ask the provider how it will handle Besu-specific risks such as client upgrades, key custody and access to validator keys. Done means a written assessment approved by the accountable manager, with any open risks assigned to an owner.
Set the contract terms
Negotiate the contract so it states where the nodes and data are located, gives advance notice of location or subcontractor changes, and returns data on insolvency or termination under Article 30(2). Add audit and inspection rights at a pre-determined frequency and scope, termination rights for the grounds in Article 28(7), and an obligation to support the exit plan under Article 28(8). Done means legal and procurement sign off on a contract that contains each term, mapped to the assessment.
Configure permissioning and JSON-RPC access
Before the provider receives any access, configure Besu node permissioning and account permissioning so only known participants connect and only approved accounts can act. Set JSON-RPC authentication with a credentials file or externally issued JWTs, and place HTTPS termination in front of the node, since Besu does not terminate HTTPS natively. Agree on who holds the key material and whether a security module plugin such as the Besu HSM plugin will protect validator or node keys. Done means a documented access matrix and configuration files reviewed by the entity's security team.
Record the register of information entry
Add the arrangement to the entity's register of information covering all contractual arrangements for ICT services under Article 28(3). Record the provider, the service, the function it supports, the locations, the subcontractors and the contract dates. Confirm with the competent authority how the entry will be submitted, since the ESAs' Q&A 2025_7309 says yearly submission generally covers the yearly reporting obligation. Done means a register entry that matches the signed contract and classification memo, and a note of the submission route.
Test the exit plan on a segregated copy
Article 28(8) requires a documented and tested exit strategy and transition plan. Restore a copy of the node data to a segregated environment, run the transition to another operator or to in-house staff, and confirm that the nodes can rejoin and produce blocks. Record each step, the test results and any gaps. Done means a test report signed by the service owner, with gaps logged as remediation items before go-live.
Schedule audits and inspections
Set the audit programme under Article 28(6): a risk-based frequency, a defined scope covering access logs, key handling, change records and backup testing, and the audit standard the entity will use. Agree on how findings are tracked to closure and how the entity will exercise its rights if the provider's ICT risk management is found weak. Done means an approved audit calendar, named auditors and a findings process that the board or risk committee has reviewed.

Questions buyers ask before outsourcing Besu operations under DORA

What drives the cost and effort of preparing the Article 28 file?

The effort follows how many arrangements the file covers, how critical the Besu function is, and how much evidence already exists. Article 28(4) requires you to assess whether the service supports a critical or important function, the supervisory conditions, all relevant risks including ICT concentration risk, the provider's due diligence and conflicts of interest before you contract. A single validator network with one outside operator is a narrower task than a multi-party consortium with several RPC providers and shared keys. Cost components are your internal time for risk, legal and business owners, any outside advisory work, and the provider's time to supply architecture and control evidence. Ask any outside firm for a quote built from a written list of the nodes, providers, data flows and contracts in scope. DeployOpen does not publish prices, and a quote follows from that written scope.

How long does the DORA third-party work take for a Besu network?

No researched fact gives a duration for this work, so treat any timeline as something to agree in writing, not something to assume. Duration depends on the number of Besu nodes and operators in scope, whether the function is classed as critical or important, how many contractual arrangements must be entered in the register, how quickly your legal team can negotiate the Article 30 terms, and how complete your existing exit and audit documentation is. Work is usually easier to schedule when the architecture, key custody model and exit plan are drafted before the provider is selected. Ask for a schedule that shows each dependency, including the time your own governance committees need to approve the policy and the risk assessment.

What must the financial entity provide before an outside firm runs Besu nodes?

The entity must supply the facts that the risk assessment and contract depend on. Expect to provide:

An architecture description covering validator and RPC node roles, network topology, the consensus configuration, and where each node is hosted.
Key custody records, stating who controls the node and validator keys, whether an HSM or security module is used, and how signing keys are separated from the node.
Register of information data for each arrangement, including the provider's identity, the services, the locations where services are provided and data is processed, and the functions supported.
Access rules, permissioning settings, incident contacts, and your current exit and audit requirements.

Identify gaps early, because missing key custody or hosting location details often delay both the risk assessment and the contract.

Can our team prepare the Article 28 file ourselves, and what does outside help add?

Yes, a financial entity can prepare the file in-house, because DORA places full responsibility for compliance on the entity and does not require an external preparer. The file needs input from risk, legal, procurement, information security and the Besu platform team. Outside help adds value where your team lacks recent Besu operating experience, needs a structured technical description of the nodes, or wants a second review of the exit plan and audit scope. An outside firm can document the architecture, prepare the technical evidence and test exit steps, but your board and management remain accountable for the decisions. Clarify in the engagement letter which documents the firm drafts and which ones your staff must approve.

Can DeployOpen certify that our Besu outsourcing complies with DORA?

No. DeployOpen does not issue audit reports, attestations or certifications. DORA sets no certification scheme, and competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for concerns whether a threat-led penetration test met the requirements under Article 26(7). DeployOpen can prepare systems, controls and evidence for your supervisory review and for independent assessors, but the conclusion on compliance is made by your regulator and your own governance. Ask any provider to state in writing what evidence it prepares and what it does not attest.

How often must the Article 28 file be refreshed for monthly Besu releases?

DORA does not set a release-based refresh schedule, so the refresh trigger should be written into your ICT third-party policy. Besu uses calendar version numbers and ships roughly monthly, with recent releases including 26.7.0, 26.8.0, 26.9.0 and 26.10.0 on the GitHub releases page. Most releases do not change the arrangement, but changes to client version, consensus, database format or the provider's operating procedures may require a review of the risk assessment, contract terms and register entry. Article 28(3) requires an annual submission of the register, and the ESAs' Q&A 2025_7309 states that this yearly submission generally satisfies the yearly reporting obligation. Set a review cadence, define which upgrades trigger a change assessment, and confirm both points with your supervisor and provider.

Which contract terms and exit steps does the Besu outsourcing file need?

Article 28(7) requires contracts to be terminable for significant breaches, changes that could alter performance, evidenced weaknesses in the provider's ICT risk management, and conditions that prevent effective supervision. Article 28(8) requires a documented and tested exit strategy and transition plan for services supporting critical or important functions. Article 30(2) requires the contract to state where services are provided and data is processed, to give advance notice of changes, and to cover data return on insolvency or termination. For a Besu network, the exit plan should cover validator key transfer or revocation, node handover, ledger data retention, and how the network continues if a validator is removed. Test these steps on a segregated environment and record the results.

What audit rights should we secure for an outsourced Besu node operator?

Article 28(6) requires audits and inspections whose frequency and scope are risk-based and predetermined, and that follow commonly accepted audit standards. Before signing, agree who may audit, what access they receive to logs, configuration, key custody records and the provider's operating procedures, and how findings are remediated. The contract should also cover supervisory access, because Article 28(3) requires the register to be provided on request and your regulator may ask to inspect the arrangement. Confirm the audit scope with your internal audit and information security functions, and state how the provider's own third-party audit evidence will be shared.

How DeployOpen prepares Besu node operations evidence for DORA reviews

DeployOpen plans, implements, hardens, documents and supports self-hosted Besu nodes inside your own infrastructure, and prepares the systems, controls and evidence that your DORA review will examine. DeployOpen does not issue audit reports, attestations or certifications. Those come from your competent authority's supervisory process and from the independent auditors you appoint. What DeployOpen delivers is the material those parties will ask to see: the node build and configuration records, the key handling and access setup, the change and upgrade records for Besu releases, the backup and restore test results, and the written exit and transition documentation. Each item should map to a decision you have already made under your own third-party policy.

Engagements are fixed-scope. Before work starts, the written scope sets out which nodes, environments, deliverables and timelines are covered, and who is responsible for each evidence item, including what remains with your team. A quote follows from that written scope, so ask for the scope first and check that it names the Besu version you will run, the key storage approach, the logging and monitoring targets and the test evidence you expect to hold at the end. Where you need continuing help, such as applying Besu releases on your change calendar, refreshing evidence after each upgrade, or running periodic restore tests, ongoing support is available as a retainer with its own written terms.

Before you rely on any evidence pack, confirm the points that depend on your regulator and your auditors rather than on DeployOpen. Ask your competent authority how it expects the Article 28 register entry, the Article 28(4) pre-contract assessment and the Article 28(8) exit plan to be presented, and whether any notice is required before the arrangement covers a critical or important function. Ask your internal audit or external auditors which evidence they will sample, how often they expect audit rights to be exercised, and whether they accept documentation produced by a service provider. Confirm these answers in writing before you finalise the scope, because they determine what the evidence must contain.