Small teams need change oversight but rarely a formal change advisory board. A standing weekly review of risky changes, plus required peer approval on every production change, delivers the same control with far less overhead. Add a larger board only when many teams change shared systems.
What the control wants
NIST SP 800-53 CM-3 asks for coordination and oversight through a defined change control body that meets on a schedule or under defined conditions. Its supplemental guidance says configuration control boards or change advisory boards typically handle approvals. The control defines a function, not a headcount.
Three scaled versions
Under ten people. Peer review on every pull request is the approval. Once a week, two senior people scan the list of production changes and infrastructure edits from the week. Minutes are a short note in a shared channel.
Ten to fifty people. Add a risk class system. Routine changes flow through automated checks. Higher-risk changes, such as database migrations, identity settings or network rules, go to a rotating reviewer group that meets twice a week or answers asynchronously within a day.
Larger. A formal board makes sense when many teams change shared systems and conflicts need resolving. Even then, keep standard changes out of it.
Make approvals meaningful
Two-party approval for sensitive components is described in CM-5(4). Use it for a short list: production database access, identity provider configuration, payment settings, and the deployment pipeline itself.
Combine that with restricted production privileges, which CM-5(5) says to limit and periodically review. If only the pipeline can deploy, then pull request review is a true gate.
What the meeting should do
A change review that works looks at the list of high-risk changes, checks that impact was assessed, spots conflicts such as two changes to the same system in one window, and picks windows for risky work. It does not re-review code.
Keep it to thirty minutes. If it takes longer, the risk classes are probably too broad.
Evidence you need
- A written statement of how oversight works.
- Records of the review: date, attendees, changes discussed.
- Links from approved changes to their approvals.
See what a change management policy should include for the surrounding policy.
When a CAB hurts
A board that gates every deploy slows delivery and teaches people to batch changes, which makes each change riskier. If you notice batching, loosen the gate on low-risk work and tighten automation instead.
Safeguard's policies and gates can block merges that fail defined checks, which helps make the pull request approval a real control. This is one part of the process, not a replacement for human review.
Quick check
Is a CAB required for SOC 2 or ISO 27001?
I could not confirm a requirement for a board by that name in the sources I used. Both expect a controlled change process, so ask your auditor what evidence they want.
Who should sit on the review group?
Someone who knows production, someone who knows security, and a rotating engineer from the team making changes.
Sources
- CM-3 Configuration Change Control, NIST SP 800-53 Rev. 5
- CM-5 Access Restrictions for Change, NIST SP 800-53 Rev. 5
Last reviewed: 19 October 2026.
