A Change Advisory Board (CAB) is the group that reviews your proposed changes to IT systems and decides whether each one is safe to release. It weighs risk, impact, timing and rollback readiness, then approves, defers or rejects.
Formally the board advises and the designated change authority authorises. In most organisations those are the same people, so "CAB approval" is the ordinary shorthand, and this page uses it that way.
CAB roles and responsibilities
Keep a CAB cross-functional: no single person sees every consequence of a change. If you are small, run it with three or four people wearing several of these hats at once. The responsibilities matter more than the headcount.
| Role | Responsibility |
|---|---|
| Change manager (chair) | Owns the process, sets the agenda and records the decision. Does not authorise changes alone. |
| Service or application owner | Confirms the business can absorb the change now, and knows what the system is for and who breaks if it stops. |
| Infrastructure or platform engineer | Assesses technical blast radius and dependencies, and checks the rollback plan is real. |
| Security representative | Determines whether the change alters the attack surface, access model or data flows. |
| Operations or service desk | Flags clashes with other work, freeze periods and support capacity around the release. |
| Business stakeholder | Signs off on changes touching customer-facing services, contractual commitments or regulated processes. |
Which changes need CAB approval
Not every change should reach the board. ITIL separates three types, and getting that split right is what keeps your CAB from becoming a bottleneck.
On vocabulary: the standing CAB and the ECAB below are ITIL v3 terms most organisations still use. ITIL 4 calls the practice change enablement and assigns a change authority per change type, warning that one central board for everything creates delay. The three types carry over unchanged.
| Change type | Route |
|---|---|
| Standard | Pre-approved and low risk, following a documented procedure. No CAB review: the approval was granted once, to the procedure. |
| Normal | Full review before deployment by the assigned change authority, in most organisations the CAB. The default for anything that changes architecture, access or data. |
| Emergency | Handled by a reduced emergency CAB (ECAB, in ITIL v3 terms). Authorisation should still be sought before implementation wherever possible, with the documentation completed retrospectively. |
How a CAB evidences ISO 27001 and SOC 2
ISO 27001:2022 requires change control under Annex A 8.32: changes to information processing facilities and systems must be subject to change management procedures. The standard does not mandate a board; it mandates that your changes are assessed, authorised and documented. A CAB is the usual way to show that.
SOC 2 covers the same ground in common criterion CC8.1, which expects the entity to authorise, design, develop or acquire, configure, document, test, approve and implement changes to infrastructure, data, software and procedures to meet its objectives. Auditors sample change records and trace them end to end.
What auditors ask to see
In practice the request is narrow and specific. For a sample of changes, expect to produce the change record with its requester and approver, the risk and impact assessment, test evidence, a rollback plan, and a traceable line from the ticket to the deployment that actually happened.
For emergency changes, show the retrospective approval too. An emergency route with no paper trail behind it is a finding.
Common mistakes
The failure is rarely the absence of a CAB. It is a CAB that rubber-stamps. If nothing is ever rejected or deferred, your board is recording decisions rather than making them, and an auditor will notice.
Close behind is having no standard-change catalogue. Routine work queues behind the board, teams route around it through the emergency path, and "emergency" becomes the most common change type on your register.
Third is approving in chat. A decision nobody can retrieve six months later did not happen, as far as an audit is concerned.