Your CAB Isn't the Problem. Its Design Is.

Reconciling DORA’s change-approval research with SOC 2 CC8.1, SOX ITGC and NIST CM-3.

There are two rooms in most regulated software companies, and they are telling you opposite things.

In one room, the platform team has read the DORA research and can quote it at you. Google’s DevOps Research and Assessment program has been unambiguous for years: “No evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates.” Worse, DORA finds these processes “tend to slow down the delivery process leading to the release of larger batches less frequently, with an accompanying higher impact on the production system.” The recommendation is blunt — replace external approval with peer review, captured in the development platform. DORA, Streamlining Change Approval

In the other room, someone is preparing for a SOC 2 Type 2 and holding a copy of CC8.1, which requires the organization to “authorize, design, develop or acquire, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures.” If the company sells to the federal government, they are also holding NIST SP 800-53 CM-3, which does not merely permit a change board — it names one, requiring organizations to coordinate configuration change oversight through “Configuration Control Boards or Change Advisory Boards” convened at defined frequencies. NIST SP 800-53 Rev. 5, CM-3

So one room has data saying the CAB doesn’t work, and the other has a federal control catalog specifying it by name.

Most writing on this picks a side. The DevOps side calls it change management theater. The compliance side calls the DevOps side reckless. Both are describing something real, and both are wrong about the fix, because they are arguing about the wrong noun.

What the frameworks actually ask for

Read CC8.1 as a list of verbs rather than a ceremony and it stops looking like a calendar invite:

• Authorize — someone with the standing to say yes said yes, and there is a record
• Test — the change was exercised somewhere that wasn’t production
• Approve — approval is distinct from authorship
• Document — the artifact survives the deploy
• Implement — you can tell who shipped what, when, and from which commit

Not one of those verbs says “convene.” They say record. The control is evidentiary, not procedural. ISMS.online, SOC 2 CC8.1 Explained

NIST CM-3 is more prescriptive because federal systems are, but look at what its enhancements actually specify: automated documentation and notification of changes, testing and validation of changes, automated change implementation, and — CM-3(4) — security and privacy representatives participating in the change control process. That last one is the interesting one. The federal catalog’s concern is not that a group of people sat in a room. It is that someone with a security mandate had a say before the change landed.

SOX ITGC arrives at the same place from the financial-reporting direction. Auditors testing program-change controls look for six things: change authorization with formal approval workflows, segregation of duties, documented testing and validation, complete documentation from request to deployment, controlled emergency-change procedures, and lifecycle tracking. Again: none of that is a meeting. All of it is a trail. SafePaaS, Change Management Controls in SOX ITGC Audits

ISO 27001:2022 consolidates its change-related requirements into a single Annex A 8.32, and the language is similarly outcome-shaped.

DORA’s own recommendation — “use peer review to meet the goal of segregation of duties, with reviews, comments, and approvals captured in the team’s development platform as part of the development process” — is not in conflict with any of that. A pull request with a required reviewer, a passing pipeline, a linked ticket and an immutable log satisfies every verb in CC8.1. It does so better than a Thursday meeting, because it produces system-generated evidence covering the entire observation period rather than a screenshot of a spreadsheet somebody assembled the week before fieldwork.

That distinction is not academic. It is where audits now fail. Auditors have moved decisively toward requiring system-generated evidence across the full observation window, and a well-instrumented pipeline produces that by default while a meeting produces it only if someone remembers to write it down.

So why is your CAB slow?

Because it is doing a job nobody assigned it.

When I took over the change advisory board at a behavioral-health EHR company — a HIPAA business associate, in the years leading up to its HITRUST certification — the board was not slow because the people in it were careless. It was slow because of three specific design decisions nobody had ever revisited.

The first was that every change went through the same gate regardless of risk. A copy change on a settings screen and a schema migration against a table holding protected health information received the same slot on the same agenda. The agenda was long, so both received roughly the same fifteen minutes, which was far too much for one and nowhere near enough for the other.

The second was that there was no standard-change catalog. Work that the organization had performed successfully dozens of times — certificate rotation, a documented runbook, an autoscaling adjustment inside agreed bounds — re-litigated itself every week, from scratch, in front of people who had approved the identical change a fortnight earlier.

The third was the one people find hardest to say out loud: for a meaningful share of the agenda, the board did not have the context to evaluate what it was approving. Approval was really attendance. That is not a criticism of the approvers. It is a straightforward consequence of routing everything to one group of generalists.

Underneath all three is the same mistake. The CAB had been designed as a filter, when the frameworks only ever asked it to be a record. A filter has to inspect everything. A record only has to capture what happened, with proof that the right people were involved.

Once you stop treating the board as the control and start treating it as one route into the control, the redesign is fairly mechanical. Ours cut change-approval time by roughly 30%. Over the same period we had no major incidents and no unanticipated downtime.

The redesign

1. Classify changes, and mean it.

ITIL has had standard, normal and emergency change types for decades and most organizations implement one of them. A standard change is pre-authorized: the change model itself was reviewed and approved once, and every subsequent execution inherits that approval. These do not need a board. They need a catalog entry, a template and a log line.

This is not a compliance shortcut. Pre-authorization is authorization. CC8.1 does not require the authorizer to be surprised.

2. Move normal changes into the development platform.

Required reviewers on the pull request. Branch protection preventing self-merge. A linked ticket carrying business justification. A pipeline that will not deploy without passing tests. A deployment log tying the release to a commit hash and an identity. That is authorization, segregation of duties, testing, documentation and implementation — five of CC8.1’s verbs — produced automatically, with timestamps auditors can sample.

3. Reserve the board for what a board is good at.

Genuinely high-risk, high-blast-radius, cross-team changes. The ones where the value is not approval but coordination — where three teams need to agree the order of operations. Meet about those. Do not meet about the other ninety percent.

4. Fix the emergency path before you need it.

A break-glass procedure with retroactive documentation and a mandatory post-implementation review is an explicitly acceptable control. An emergency path so onerous that engineers route around it is a finding waiting to happen, and it is the single most common way a change program fails an audit.

5. Put security in the loop, not in the room.

CM-3(4) wants security representation in the change process. A required security review on changes touching authentication, encryption, network boundaries or data classification does that continuously. A security person attending a weekly meeting where they lack context on most items does not.

6. Solve population completeness before your auditor raises it.

This is the failure mode nobody prepares for. Auditors sample from a population of changes — but first they have to be satisfied the population is complete. If changes can reach production through paths your change record doesn’t capture, sampling is meaningless and the control fails regardless of how well the sampled changes were handled. Reconcile your deployment logs against your change records and be able to show the two agree. If they don’t, that gap is your real audit risk, not the length of your meeting.

The part both rooms get wrong

DORA is right that formal external review doesn’t reduce change failure rate. The compliance team is right that you cannot ship to production without an audit trail. These are compatible claims, and the fight between them persists mostly because each side is arguing against the other’s worst implementation. Forrester, Ringing Down The Curtain On Change Management Theater

There is one more DORA finding that deserves more attention than it gets, because it reframes the whole problem: “Simply doing a better job of communicating the existing process and helping teams navigate it efficiently has a positive impact on software delivery performance.”

Not replacing the process. Not deleting the board. Making the existing thing legible and navigable.

That is a much less exciting conclusion than “kill the CAB,” which is probably why it travels less well. It is also the one that survives contact with an auditor.

What I’d tell you if you asked me directly

The thing that convinced me was not the delivery metric. It was watching what happened to the evidence. Before the redesign, preparing a change-management evidence package meant a person spending days reconstructing a quarter from meeting minutes, tickets and memory. Afterwards the same request was a query. The approvals were in the platform, the tests were in the pipeline, the deploys were in the log, and the three reconciled because they were generated by the same act of shipping rather than assembled afterwards to describe it.

That is the real argument for moving the control into the development platform, and it is not a DevOps argument. It is an audit argument. Reconstructed evidence is weaker evidence. An auditor who can sample a system-generated population across the full observation window is being handed a stronger control than one who is handed a tidy spreadsheet, no matter how tidy.

So if your board feels slow, resist both of the available reflexes. Do not defend it on the grounds that compliance requires it, because compliance requires a record and you may be producing the record somewhere else already. And do not delete it, because the ten percent of changes that genuinely need coordination will find you eventually and you will want somewhere to put them. Classify the population, move the routine work to where the evidence writes itself, and give the board back the only job it was ever good at.

Sources

• DORA (Google Cloud), Streamlining Change Approval
• NIST SP 800-53 Rev. 5, CM-3 Configuration Change Control
• NIST SP 800-53 Configuration Management control family
• A Practical Guide to SOC 2 Change Management Controls (CC8.1)
• ISMS.online, SOC 2 CC8.1 Explained
• SafePaaS, Key Change Management Controls Auditors Look For in SOX ITGC Audits
• Pathlock, ITGC and SOX: The Basics and 6 Critical Best Practices
• Forrester, Ringing Down The Curtain On Change Management Theater