Change advisory board
The CAB reviews requests for change that affect the operational environment. Its job is to make a decision with enough information to defend it, not to add a meeting between a decision and its implementation.
Purpose
Assess every request for change for technical, operational, security, compliance and quality impact before it is implemented.
Core members
Members are appointed by role; the individual changes without the seat changing.
| Role | Contribution | Decision rights |
|---|---|---|
| CAB chair (technical executive) | Runs the meeting, sets the agenda, breaks ties | Final decision on a tie |
| Technical lead | Technical feasibility and implementation planning | Final technical approval |
| Program manager | Operational impact and alignment with infrastructure | Vote on operational and infrastructure changes |
| Head of security | Security implications and control compliance | Vote on security-affecting changes |
| Compliance officer | Legal, regulatory and policy conformance | Vote where compliance is affected |
| Senior developer representative | Development impact | Advisory |
| DevOps lead | Delivery and operations impact | Advisory |
| QA manager | Testing and quality impact | Advisory |
| Network architect | Network architecture and performance impact | Advisory |
Advisory members
Invited per change, without a vote:
| Role | Contribution |
|---|---|
| Business owner | Customer-facing impact |
| Project manager | Effect on features and timelines |
| Systems administrator | System configuration impact |
| Database administrator | Data integrity and database risk |
| Application support | Operational impact on running services |
Decision model
A change is approved when the voting members reach consensus. Where consensus is not reached:
- The chair summarises the disagreement and its basis.
- The security or compliance member may hold the change if the concern is a control obligation. This is not veto by seniority; it is a legal constraint.
- The chair decides, and the decision and dissent are recorded.
Recording dissent matters: if the change fails, the record shows what was considered.
Meeting rhythm
| Meeting | Frequency | Content |
|---|---|---|
| Standard change review | Weekly | Open requests, impact assessments, decisions |
| Emergency CAB | On demand | Urgent changes with a compressed assessment |
| Post-change review | Monthly | Outcomes of implemented changes |
Agenda
- Review of previous actions.
- Open requests in order of risk.
- Impact assessment presentation by the requester.
- Questions and decision.
- Emergency changes since the last meeting, for retrospective review.
- Register status and ageing.
Change classes
| Class | Examples | Route |
|---|---|---|
| Standard | Pre-approved, low risk, repeatable — routine deployment through the pipeline | Automated approval; recorded |
| Normal | Planned change with assessment | CAB review |
| Emergency | Incident remediation, security response | Emergency CAB or delegated authority, reviewed afterwards |
The standard class exists so that routine work does not consume CAB time. If a standard change starts appearing in incidents, its classification is wrong.
Information the CAB needs
A request without this information is deferred, not guessed at:
- What changes, and why.
- Which systems and customers are affected.
- What happens during implementation — downtime, degraded performance, none.
- Rollback plan and its time to execute.
- Test evidence — what was verified, and where.
- Security and compliance impact.
- Communication already sent, or planned.
- Who will be on hand during and after.
Operating rules
- Decisions are made in the meeting. A request that is "still being reviewed" for three cycles is a decision to delay — record it as such.
- Emergency is not bypass. An emergency change is approved by a named delegate, implemented under the same rigour, and reviewed at the next CAB.
- Repeat changes get a standard. A change that recurs monthly should become a standard or an automation.
- The register is the record. Minutes that are not in the register are not evidence.
- Post-incident, not post-blame. The post-change review asks what the process missed, not who missed it.