The CAB That Cannot Keep Up With Delivery
Northwind Payments runs its IT change process through a Change Advisory Board that meets every second Thursday. Last quarter the board reviewed 340 changes and rejected 11; average time from submission to decision is 16 days. Meanwhile three product teams have started deploying directly to production through a vendor SaaS platform with its own release pipeline, arguing the CAB is 'too slow to matter'. A regulatory review of payment-card handling starts in six weeks and will ask for evidence that all production changes are authorised and traceable. The CIO has asked you, the newly appointed service management lead, to 'get control back' without stopping delivery. The board's charter has not been revised since 2019, and the risk register holds 12 entries, all more than 18 months old.
1. The CIO wants the CAB to review every change until the audit is over. Evaluate this proposal and recommend what the governing body should actually decide.
Read the worked answer
What is really wrong. The problem is not insufficient approval; it is an approval model that applies one control level to everything. Reviewing 340 changes in 26 meetings a year means roughly 13 changes per meeting, 16 days of queue time, and a board that adds no assurance value because it cannot genuinely assess each item. Blanket re-review would deepen the queue, push more teams into shadow channels, and worsen the audit position.
What the governing body should decide (direction, not detail).
- Define a change authority model: which categories of change may be authorised by a named role or automated pipeline rule, and which genuinely need cross-functional review. Standard/pre-approved changes with defined preconditions are governed, not ungoverned.
- Set the constraints: every production change must be recorded against a defined change authority, with an evidence trail of who authorised it and on what basis. Make this a condition of using any pipeline, including vendor SaaS pipelines.
- Require the board to spend its time on high-risk and cross-service changes, not on volume.
Why this is defensible to the regulator. The audit question is 'are changes authorised and traceable', not 'were they all seen by a committee'. A delegated authority model with recorded decisions answers that question more credibly than a committee that minutes 13 changes a fortnight.
The trade-off to state explicitly. Delegation increases the consequence of a bad rule, so the authority thresholds must be reviewed after the audit, and the shadow deployments must be brought in by adopting them into the model, not by shutting them down.
2. How should risk management be used so that the six-week regulatory review is credible and the change pipeline improves afterwards?
Read the worked answer
Diagnose the current state. A register of 12 entries, all older than 18 months, is not a risk register; it is an archive. It tells you nothing about which changes are risky now, and it cannot support decisions.
Make risk usable in the time available.
- Re-assess only what matters: the changes and services in scope for card handling, plus anything touching the shadow SaaS pipeline. A focused, current assessment beats a comprehensive, stale one.
- Record owner, likelihood, impact, and treatment for each entry - with a named accountable person, not a team name. An unowned risk is an unmanaged risk.
- State risk appetite for change categories, agreed by the governing body. Without a stated appetite, every risk debate becomes a matter of opinion and escalates to the CIO.
- Define escalation triggers - for example, any change to a service in the card-handling scope with no tested rollback goes to the board.
Connect risk to compliance and assurance. The three GRC strands should converge: the same risk assessment should generate the evidence the audit needs (authorisation, traceability, tested recovery), rather than producing a separate paper trail for the auditors.
Judgement point. Do not attempt to populate a complete enterprise risk register in six weeks. Prioritise the risks that could invalidate the audit finding, and be transparent that the wider register will be rebuilt on a defined cycle afterwards.