What is a change advisory board (CAB)?

The change advisory board explained: what it reviews, who takes part, how it treats normal, standard and emergency changes, and how to keep it lightweight.

2 min read

Definition

A change advisory board, or change committee, is the group that reviews and authorizes changes to production systems. ITIL 4 calls the role change authority: whoever is entitled to approve a given type of change.

What it reviews

  • The purpose and business value of the change.
  • Its risk level and impact.
  • Test results and evidence.
  • The rollback plan.
  • The schedule and conflicts with other changes.
  • Who requested it and who built it.

Normal, standard and emergency changes

Change types and how they are treated
Type Treatment
Standard Low risk and pre-approved; follows a known procedure
Normal Assessed and authorized by the change authority
Emergency Implemented urgently; authorized quickly and reviewed afterwards

A lightweight committee

  • Authorize by role, not by meeting: one accountable approver per gate.
  • Send a complete change record before the decision, not a slide deck.
  • Pre-approve standard changes.
  • Record each decision with its minutes number.

One committee or two?

Some organizations authorize the installation in pre-production and in production separately, so the second decision sees the result of the first. It adds one step but catches problems before they reach users.

How DevGob helps

DevGob's committee authorizes by role at the Pre and Production gates, with a workspace-wide agenda and minutes for each session.

Read it in the documentation

Frequently asked questions

Does ITIL require a CAB?

ITIL requires a change authority, not a weekly meeting. The authority can be a person or a group, depending on the risk.

Does a CAB slow DevOps down?

A meeting-based CAB can. Approvals by role inside the workflow, with complete evidence, take minutes.

Who should sit on a change committee?

The people accountable for the affected services: operations, the product owner, security when relevant, and a chair who records the decision.

Keep reading

Release management with approvals and evidence Manage software releases from development to production: phases with owners, Pre and Production committees, milestones and install evidence. Two committees, not one: authorizing pre-production and production Why DevGob splits change authorization into a pre-production gate and a production gate, and what the second committee sees that the first one cannot. Software development governance Govern how software is built and released: decision rights by role, approvals, traceability from requirement to production and evidence for every change. What is software governance? Software governance explained: decision rights, policies, controls and evidence, how it differs from management, and how to keep it lightweight.

DevOps with governance, on one record

DevGob plans the work and governs every change on its way to production: backlog, sprints, committee authorizations, install evidence and an audit trail.

Request a workspace Documentation