How SOC 2 change management applies to Besu network upgrades
If you run Besu nodes in a regulated entity and your SOC 2 scope includes them, CC8.1 expects you to control every client and protocol change from authorization through implementation and evidence. Besu gives you useful building blocks for that control, but it does not run the process for you. Version pinning in your deployment tooling, so each node runs a named Besu release that was approved and tested, gives you a baseline configuration to compare against. Node and account permissioning files give you a reviewable record of who may connect and transact, and the metrics endpoint enabled with --metrics-enabled lets you show that nodes behaved as expected after a change. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older versions cannot open the upgraded database, so a verified backup taken before the change is a control you must design, not a feature you can assume.
The obligations that stay with you are the ones auditors sample most often: who authorized each change, what was tested and where, how emergency changes were approved after the fact, which patch changes were prioritized, and whether the configuration you documented matches what is running. Besu does not decide those things. Your change tickets, test records, approval evidence and post-change reviews are the evidence. Confirm with your auditor which change populations and sample sizes they will test, and confirm which Besu release lines and dates your scope covers before you commit to a calendar.
A SOC 2 is an attestation by an independent CPA firm under the AICPA attestation standards, and the report is the CPA's opinion, not ours. DeployOpen can help you design the change procedure, prepare test environments and assemble the evidence an auditor will request, and it can document how Besu upgrades flow through that procedure. It does not issue SOC 2 reports, attestations or certifications. The AICPA SOC 2 overview explains how the examination is scoped and who performs it, which is the right starting point before you decide what your change records need to prove.
Mapping CC8.1 points of focus to Besu capabilities and configuration
This table maps each CC8.1 change management point of focus to what Besu documents, the configuration an operator must set in its own environment, and what the team should confirm before an auditor samples the change. Read each row as a control question: the capability shows what the software offers, the configuration shows what you must set, and the confirmation column shows what evidence to gather. Baseline checks for the features Besu removed come first, because a network still relying on them cannot take a supported upgrade.
| CC8.1 focus | Besu capability (documented) | Configuration in your environment | What to confirm |
|---|---|---|---|
| Baseline checks: removed features | Besu 26.4.0 removed Clique, so pure Clique networks can no longer start or produce blocks. Besu 25.6.0 removed Tessera privacy and onchain permissioning, and 25.7.0 removed the EEA and PRIV RPC groups. | Record the consensus engine, privacy setup and permissioning mode of every node in the baseline. Block any upgrade step that depends on a removed feature until it is replaced. | Confirm no node, script or monitoring check still references Clique, Tessera, onchain permissioning or EEA/PRIV methods. Keep the baseline record with the change ticket. |
| Authorization and approval | Besu does not issue approvals. Its local permissioning uses node and account permissions files that restrict who can connect and transact. | Store permissions configuration under version control with a named approver for each change. Treat edits to node and account permissions as changes in their own right. | Confirm who may approve a permissions change, and that the approval is recorded before the file is deployed to each node. |
| Design and testing | Besu publishes release notes for each calendar release, and the 26.10.0 notes state the Bonsai database auto-upgrades on first start. | Run each candidate version on a test network with production-like genesis and validator count before it reaches a validator. Record the test plan and results. | Confirm the test covers block production, peer connection and RPC access. Confirm the test environment is separated from production. |
| Configuration baseline | Besu runs from command-line options and config files, and its JSON-RPC authentication and metrics settings are set explicitly by the operator. | Keep node configuration, including JSON-RPC authentication and the metrics option, in a versioned baseline. Compare live nodes against it after each change. | Confirm drift checks exist and that any node running a non-baseline setting is reported and approved. |
| Emergency changes | Besu's release notes call out changes that cannot be reversed simply, such as the Bonsai database upgrade, which older versions cannot open. | Define an emergency path that still requires a backup of node data before any upgrade. Record who may authorize it and how it is reviewed after the fact. | Confirm a backup exists and was verified before the emergency upgrade. Confirm the retrospective review is logged with the ticket. |
| Patch changes and rollback | Older Besu versions cannot open a database upgraded by a newer release, so rollback depends on a backup taken first. | Schedule patch releases through the same change process as feature releases. Take and label a node data backup immediately before each upgrade. | Confirm rollback was tested on a segregated copy, not only assumed. Confirm the backup is stored separately from the node. |
| System resilience | Besu's private network design and validator set determine whether the chain keeps producing blocks when one node is changed. | Upgrade validators one at a time, checking quorum and block production between steps. Plan the validator order in the change record. | Confirm the validator count still meets quorum during the rolling sequence. Confirm the rollback order is documented. |
| Confidentiality and privacy (2017 focus) | Besu's permissioning and transport settings can limit who reaches the node and its RPC interface. Besu does not terminate HTTPS natively. | Confirm TLS is provided by a proxy or gateway that is itself in the change scope. Protect the node private key file, or use a security module plugin with --security-module. | Confirm that changes to the proxy, TLS certificates and key storage pass through the same change process as Besu upgrades. |
Which change records auditors sample for Besu upgrades
A SOC 2 auditor testing CC8.1 will pull individual changes and ask for the full trail behind each one. The cards below describe the records that usually make up that trail for a Besu client upgrade, genesis transition or validator change, and how to keep them tied to one change ID across the observation window.
Change ticket with authorization
The change ticket is the anchor record. It should state the requested Besu version or configuration change, the reason, the risk rating, the named approver and the approval timestamp, recorded before implementation starts. Auditors check that approval came before the change was made, so compare the ticket timestamps against node logs or deployment history. Confirm that the approver is someone with authority over the affected network, not only the person who executed the change.
Pre-upgrade backup and restore test
Before a client upgrade, record a backup of the node data and the keys and configuration needed to restart the node. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older versions cannot open an upgraded database, so the backup is the only rollback path. Keep the backup identifier on the change ticket and attach evidence that a restore was tested on a segregated node.
Test evidence on segregated nodes
Record the test run that exercised the new Besu version before it reached production validators or RPC nodes. Keep the environment identifier, the version under test, the test scripts or scenarios, and the pass or fail output. Note any deviation and how it was resolved. Auditors often ask whether the tested build is the same build that went live, so store the version string or image digest in both places.
Release notes reviewed per version
For each version in the upgrade path, keep a short review note that lists the removed or changed features that affect this network. Besu has removed features across recent releases, including Clique consensus in 26.4.0 and the EEA and PRIV privacy RPC groups in 25.7.0, so a reviewer should confirm that no removed feature is still in use. Name the reviewer and link the note to the change ID.
Configuration and genesis diffs
Store the before and after diff of node configuration files, the permissions configuration and the genesis file for every change that touches them. Genesis transitions and validator set changes alter how the network behaves, so the diff should be reviewed and signed off before the change window opens. Keep the diff in version control with the change ID in the commit message, so the auditor can see exactly what changed and who reviewed it.
Post-change metrics and logs
Capture the monitoring output that shows the network returned to normal after the change: block production, peer counts, validator participation and error rates over a defined window. Export or snapshot the Prometheus or Grafana views and the node logs for that window, then reference them from the change ticket. This record shows that the change achieved its intended outcome and gives the auditor evidence for the operating effectiveness of the change control.
Why genesis transitions and validator changes need their own change path
Genesis changes, validator set changes and permissioning file changes alter network behavior for every operator at once, so they cannot follow the same path as a routine client upgrade on a single node. A change to the genesis configuration, the QBFT validator set or the permissioning files can change which nodes may connect, which accounts may transact and which blocks other members will accept. Under CC8.1, the change record for these events should show approval from each member organization that the change affects, not only from the team that edited the file. Before the change starts, document the rollback decision: who can call it, what evidence triggers it, and whether the previous state can be restored. Do not assume a rollback is possible for a database-altering release, because the Besu 26.10.0 release notes state that older versions cannot open an upgraded Bonsai database without a backup taken beforehand.
Record who approved each validator change, when the approval was given, and which proposal it covered. Auditors sampling changes will look for this trail, so the approver should be identified by name and role in your ticketing system, and the approval should reference the exact validator addresses and block at which the change takes effect. Permissioning files need the same discipline. Store the node permissions and account permissions configuration files in version control, require a second reviewer for each edit, and tie each deployed file to a commit so you can show what was live on a given date. Confirm with the Besu permissioning documentation how local files are read and reloaded on your release, because that determines what a reviewer must check.
The mechanics of validator changes, including voting, contract-based selection, transition blocks and timeouts, belong to the Hyperledger Besu QBFT validator management and private network design pages, so this section only sets the change control around them. Confirm the exact procedure, configuration keys and sequencing with the Besu documentation and against a test network before writing the change plan. Your change record should link to those validated steps, not restate them from memory.
Configuring the change process around a Besu upgrade
This sequence sets up a SOC 2 CC8.1 change process for Besu client, genesis and validator changes so that each upgrade leaves approvals, tests, backups and logs that an auditor can sample.
Define change categories for Besu changes
The change owner, usually the network operator's platform lead, sorts Besu work into categories such as client upgrade, genesis or fork transition, validator set change, and permissioning change. Each category states who authorizes it, which tests are required, whether a rollback path must be documented, and whether it can run as a standard or emergency change. Security and compliance sign off on the matrix before it is used. The output is an approved change category register that maps every Besu change type to an approval path, and it becomes the reference an auditor uses to test whether changes followed the right route.
Pin Besu version and JDK in configuration management
Record the exact Besu release and the JDK version in the configuration baseline, and keep both in version-controlled deployment code. Besu 26.6.0 release notes state that Besu requires JDK 25 to build and run, so the baseline must show that runtime alongside the client version. Releases ship roughly monthly, so the team should record which release is approved for each environment rather than tracking the latest tag. The output is a baseline record and a deployment diff that show the approved version, the JDK and the configuration file hashes for every node before and after the change.
Back up and verify before any Bonsai auto-upgrade
Before a client upgrade, the operator takes a backup of each node's data directory and verifies that it can be read. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older Besu versions cannot open an upgraded database, so this backup is the only rollback path. Confirm the backup method and retention with your own storage team and record the checksum or restore test result. The output is a backup record tied to the change ticket, including node identifiers, timestamps and the verification result.
Test the change on a segregated network
Apply the same client version, genesis file and validator configuration to a segregated test network that mirrors the production topology as closely as your environment allows. Run block production, transaction submission, peer connectivity and permissioning checks, and confirm that the upgraded test nodes can restart and reopen their databases. Any deviation from production, such as fewer validators or synthetic load, is written down so the reviewer can judge its effect. The output is a signed test report linked to the change request, with pass or fail results and open defects.
Set approval gates before implementation
Before production work starts, the change board checks the request against the category register: the test report, the backup record, the rollback steps, the implementation window and the named operators. Segregation of duties matters here, so the person who builds the change should not be the only approver. Approvers record their decision in the ticketing system, and any scope change restarts the gate. The output is an approval record with timestamps, approver identities and conditions, which is the evidence most often sampled for CC8.1.
Capture metrics and logs for each change window
During the window, the operators collect node logs, Prometheus metrics exposed by Besu when metrics are enabled, and block production and peer count figures for every node. Note the start and end time of each node restart, the sequence in which validators were changed, and any alerts raised. Confirm that log retention and clock synchronization apply to these records before the window opens. The output is a change window pack that links the logs and dashboards to the ticket, so an auditor can compare the planned and actual change.
Run and record the emergency change path
An emergency change, such as a security fix or a node that will not restart after an unplanned event, follows a shorter approval path defined in the category register. The approver is named in advance, the change is still recorded with reason, scope and rollback plan, and a retrospective test and review is completed after the event. The team should not treat emergency status as a way to skip backup verification where a Bonsai upgrade is involved. The output is an emergency change record and a post-implementation review that shows how the emergency was authorized and closed.
What Besu and the change process do not cover for SOC 2
Running Besu upgrades through a CC8.1 change process does not transfer the control to the platform. The gaps below sit with the operator, and each one needs a named owner, a written decision and evidence that auditors can sample.
Approval policy and change board
Besu ships releases and documentation, but it does not define who approves a client upgrade, genesis transition or validator change in your organization. Your change policy must set approver roles, emergency authority and the criteria a change board uses before a release reaches production. Check that the policy names who may approve a Besu change, how approvals are recorded in your ticketing system, and whether validator changes follow the same path as client upgrades.
The SOC 2 report and its scope
Besu does not issue, hold or interpret a SOC 2 report. A CPA firm examines your system, and management prepares the system description and written representations. Your team decides which Besu nodes, RPC endpoints and supporting tooling fall inside the system boundary, and whether the other TSC categories are in scope. Confirm the boundary with your auditor before you define which upgrade records they will sample.
Plugins and forks for removed features
Tessera privacy, onchain permissioning and the EEA and PRIV RPC groups were removed in Besu 25.6.0 and 25.7.0. If you still depend on them, the maintainers point to plugins or community forks, and those components fall outside the upstream release process. Your change control must cover each plugin or fork version, its build, its testing against each Besu release, and who reviews its security changes.
Patch review for releases and JDK
Besu releases roughly monthly on calendar versions, and Besu 26.6.0 requires JDK 25 to build and run. Upstream release notes do not decide whether your environment takes a given release or runtime change. You need a documented review step for each release and JDK update that assesses impact on your nodes, validators and monitoring, and records the decision to defer or accept. Ask your team to confirm how these reviews feed the standard change record.
Attestation standard changes
The AICPA Auditing Standards Board proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029. The proposal could change what an engagement requires from management and the service auditor, so your change evidence should not be designed around today's wording alone. Track the proposal through your auditor and review your change records when it is finalized.
Questions buyers ask about SOC 2 change management for Besu
Does a SOC 2 report cover Besu client upgrades and validator changes?
Yes, if the Besu network sits inside the system described in the SOC 2 and the change process is one of the controls the report tests. SOC 2 common criteria CC8.1 covers changes to infrastructure, data, software and procedures, from authorization through implementation. A Besu client upgrade, a genesis transition or a validator set change each passes through that lifecycle, so each needs a recorded authorization, a test result and an approval before it reaches production. The SOC 2 does not check Besu itself. It checks whether your change process is designed and, in a Type 2, operating as described. Confirm the system boundary with your auditor before the first upgrade is planned.
How do SOC 2 Type 1 and Type 2 differ for change controls?
A Type 1 report describes your system and states whether the change controls were suitably designed as of a single date. A Type 2 report covers a period and adds an opinion on whether those controls operated effectively throughout it. For Besu, a Type 1 asks whether your written change procedure for client upgrades, genesis changes and validator edits fits CC8.1. A Type 2 asks whether every upgrade in the window actually followed that procedure, with the approvals, test evidence and rollback plans present. Teams often find the Type 2 sample exposes gaps such as a hotfix applied to one validator without a ticket. Ask your auditor which period and sample size they expect.
What drives the effort and cost of a SOC 2 change management engagement?
Cost depends on the number of nodes and environments in scope, how many change types you run (client upgrades, genesis or consensus transitions, validator changes, emergency fixes), how much of the change record already exists, and how many systems share the change process. Costs fall into two groups. An assessor or auditor is paid to examine the report. DeployOpen or another implementation partner is paid to design the procedure, build templates, set up approval and evidence tooling, and test the rollback path. Setup work is largely one-time. Evidence collection, monthly upgrade reviews and retainers recur. Ask any quote to break out design, tooling, testing support, training and ongoing evidence work, and to name the systems and environments it covers.
How long does a SOC 2 change management readiness exercise take?
The duration depends on how far your current change process is from what CC8.1 requires and on how many Besu networks it must cover. The main drivers are the state of existing tickets and approvals, whether separate environments exist for testing upgrades, how many parties sign off on a change, and whether your network has already gone through a major Besu transition. Before you accept any timeline, ask the provider to list the stages, the dependencies on your staff and the evidence each stage produces. A fixed-scope engagement states its timeline in writing from the agreed scope, so compare quotes against the same list of networks and change types.
What must our team supply before a readiness exercise starts?
Your team needs to provide the material that shows how changes already happen, because the work is to formalize and test it. Typical inputs include the current change policy and any runbooks for Besu upgrades, an inventory of nodes and validators with their roles, the Besu versions in use, the release notes you rely on, and the access model for who can deploy to production. You should also name the approvers, the owners of each environment and the people who will sign records during the review period. Access to a test network that mirrors production, along with the backup and restore procedure, is needed to show that an upgrade can be verified and reversed.
Can our internal team run SOC 2 change management for Besu without a partner?
Yes, many operators run the process internally, provided they have people who understand both the Besu upgrade mechanics and the SOC 2 evidence requirements. The work splits into design, operation and examination. Design means writing the change procedure, classification rules and templates. Operation means raising, approving, testing and recording each change. Examination is the auditor's job. The skills gap usually appears in three places: deciding what counts as a significant change, testing a Besu client upgrade on a segregated copy, and keeping consistent records across validators run by several organizations. Confirm internal capacity against the release cadence. Besu publishes calendar releases, and each one may need its own change record.
What must an emergency change record for a Besu node contain?
An emergency change record must show what was changed, who authorized it, why it could not wait for the normal process, what testing happened, and how the change was reviewed afterward. For a Besu node, include the affected node or validator, the Besu version before and after, the configuration or key file touched, the reason for urgency, the approver who accepted the risk, and the timestamps of deployment and verification. Add the rollback decision. Note that Besu 26.10.0 auto-upgrades the Bonsai database on first start and older versions cannot open it, so a rollback needs a backup taken before the change. Close the record with a post-implementation review and any follow-up normal change.
Where the SOC 2 criteria and Besu release records come from
The change management controls you describe for CC8.1 should be written against the AICPA 2017 Trust Services Criteria with the revised points of focus published in 2022. That document is the reference your service auditor will use to read CC8.1, including its points of focus on emergency changes, baseline configuration and patch changes. Points of focus are characteristics that help you design and evaluate controls, not separate requirements, so your change procedure should show which ones you address and why others do not apply. Download the criteria from the AICPA 2017 Trust Services Criteria and keep the version you assessed against on file with your change records.
Confirm the current criteria text and any interpretive guidance with your CPA before you finalize the change policy, because the auditor's view of what counts as sufficient evidence for a Besu upgrade is what matters for the report. Ask them specifically how they expect you to evidence emergency changes and whether they want the release notes themselves retained as part of the change package or only referenced.
The Besu side of the record comes from the release notes for each version you deploy. Besu ships roughly monthly and uses calendar version numbers, and removals and behavior changes are documented in the besu-eth/besu releases page. Read the notes for every version between your current and target release, not only the newest one. Recent removals such as Clique consensus and the privacy and permissioning features mean a version jump can change what your network is allowed to do, and each change request should cite the specific notes it relied on, with the date you reviewed them.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the change records a SOC 2 change management process depends on. We scope the Besu upgrade work in writing before it starts, build the change path in your environment, and hand over the evidence your team and auditors will sample.
How we scope
- Written, fixed-scope agreement listing which Besu nodes, validators and upgrade types fall under the change process
- Inventory of current client versions, genesis settings and permissioning files taken as the baseline configuration
- Agreed list of change record fields, approval roles and emergency change conditions before the first upgrade
- Clear boundary between DeployOpen deliverables and controls your own change board and auditor own
How we build
- Change templates for client upgrades, genesis transitions and validator set changes, aligned to your change policy
- Test plans run on non-production networks, with rollback steps tied to a backup taken before each upgrade
- Configuration kept in version control so each change has a traceable diff, reviewer and approval record
- Monitoring and alert checks defined so post-change health can be shown in the change ticket
How we hand over
- Runbooks for standard, normal and emergency changes, with the approver and evidence expected at each step
- A sample set of completed change records, test results and rollback logs organized for auditor sampling
- Documentation of which controls DeployOpen prepared and which remain with your team to operate
- Handover session covering the records to retain and how to reconstruct a change during an assessment
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing
- Review of each new Besu release against your change process before it is scheduled for production
- Support for auditor walkthroughs, with DeployOpen preparing evidence while the independent auditor issues any opinion
- Quotes follow from the written scope, so ask which release reviews and evidence requests are included
