A cheat sheet of the questions you should be asking as the Business / Management representative in a CAB review. Grouped by risk category. Use this to participate meaningfully without needing to understand the technical details.
💡
How to use this: You don't need to ask every question on every change. For a low-risk Standard change, a few are enough. For a high-risk or Emergency change, work through each category. Questions marked Blocker are ones where an unsatisfactory answer should stop the approval.
01Data & Client Risk
🔒
Data & Client Risk
Protecting client data and the organisation's obligations to the people it serves
Does this change involve any client data -- names, contact details, financial information, or anything related to a specific client?
If yes, extra scrutiny is required. A satisfactory answer is: "No client data is involved" or "Yes, and here is how we have ensured it is handled safely."
Blocker
If something goes wrong with this AI tool and client data is exposed -- who do we have to notify, and within what timeframe?
This tests whether the team has thought through the notification obligations. A satisfactory answer is: a specific answer referencing the contract, GDPR, or applicable regulation.
Blocker
Have the affected clients been made aware that AI is being used in their service delivery?
Not always required, but worth asking for client-facing changes. Some clients have contractual or regulatory requirements around AI disclosure.
Probe
02Operational Risk
⚙
Operational Risk
What happens to the business if this change doesn't go as planned
If this goes wrong after go-live, what is our rollback plan and how quickly can we restore normal service?
A satisfactory answer is: a specific plan with a timeframe. "We can reverse it within 2 hours by doing X" is good. "We'll figure it out" is not.
Blocker
Is a human reviewing the AI output before it has any real-world effect -- or is this fully automated?
Fully autonomous AI actions carry significantly higher risk. If the answer is fully automated: ask what monitoring is in place and what triggers a human review.
Blocker
Has this been tested? What did the test results show?
Going straight to production with no testing is a red flag regardless of how low-risk the change appears.
Probe
What is the worst-case scenario if this change behaves unexpectedly? How many clients are affected?
Helps size the real business impact. A change that could affect one internal user is very different from one that could affect fifty clients simultaneously.
Probe
03Vendor Risk
🏢
Vendor Risk
Who is providing the AI, and what are our obligations and dependencies
Has this vendor been formally assessed and approved? Is there a completed Vendor Assessment on file?
Every new AI tool must pass a vendor assessment before approval. A satisfactory answer is: "Yes, the assessment is attached to this change request."
Blocker
If this vendor shuts down or significantly changes their pricing or terms -- what is our contingency?
Dependency risk. A satisfactory answer is: "We have an abstraction layer that allows us to switch" or "This is a low-dependency use case we could replace in X days."
Probe
Is this vendor using our data to train their AI models? Have we opted out?
Many AI vendors default to using customer inputs for training. This is a significant data governance issue for client-facing workflows.
Probe
04Compliance & Liability
📄
Compliance & Liability
Our obligations to regulators, auditors, and clients
Does this change affect our SOC 2 compliance posture? Has the Risk representative confirmed this?
SOC 2 is a key trust signal for our clients. Changes that introduce gaps in our controls can affect our audit standing and client contracts.
Blocker
If the AI produces an incorrect output that a client acts on -- where does the liability sit? Have we reviewed our professional indemnity coverage for AI-related claims?
Particularly relevant for changes where AI output could influence a client business decision.
Probe
Is this documented? Will there be a clear record of what was approved, when, and by whom?
The signed change request is that record. This question is a reminder that your signature matters -- it is the organisation's evidence of due diligence.
Context
05Strategic Fit
🎯
Strategic Fit
Does this make business sense right now
What problem does this solve? What does success look like in 90 days?
Changes without a clear success definition are hard to evaluate and harder to justify if they go wrong.
Probe
Is the timing right? Are there any client events, audits, or business commitments in the next 30 days that make this a bad time to introduce risk?
You often have the best visibility on upcoming business events. This is your domain.
Probe
Does the team have the capacity to support this properly after go-live, or are we adding to an already stretched workload?
Resource risk is a business question, not a technical one. Under-resourced implementations often become incidents.
Context
06Reading the Answers
Answers that give confidence
Specific and direct -- no hedging
References a plan, document, or test result
Acknowledges risk honestly and explains the mitigation
Tells you what the worst case is and how long recovery takes
The submitter has clearly thought this through
Answers that should give you pause
"It should be fine" with no supporting rationale
Vague or evasive -- doesn't answer the question directly
Dismisses the risk without explaining why it doesn't apply
"We can deal with it if something goes wrong"
Can't say how many clients are affected or what the blast radius is
07How to Frame Your Decision
Approve
All your blocker questions have satisfactory answers. The business risk is understood and managed. The timing is right. You're comfortable that if something goes wrong, the organisation is protected. Sign and proceed.
Conditional
You're broadly comfortable but have one specific concern that needs to be addressed before or immediately after go-live. State the condition clearly -- e.g. "Approved on the condition that client notification is sent before the automation goes live."
Defer
The change isn't ready -- questions weren't answered satisfactorily, testing wasn't done, or the timing is wrong. Deferral is not a rejection. It means "come back when it's properly prepared." This is the right call more often than people think.
Reject
The change poses unacceptable business risk, conflicts with a client commitment, or fails a fundamental requirement that can't be fixed with more preparation. You do not need to justify this technically -- "this creates unacceptable liability exposure for the business" is a complete reason.
⚠
You are never the only vote. The CAB requires all four representatives to sign. If the other three are satisfied and you have a concern, raise it -- that is exactly what you are there for. A good CAB process welcomes challenge. If you feel pressured to approve something you're uncomfortable with, that is itself a governance concern worth raising.