Cloud Concentration and Risk Appetite at a Payments Firm
A regulated payments processor handles 40 million transactions a day. Sixty percent of production workloads sit with a single cloud provider under a three-year contract with 18 months remaining. Last quarter a regional outage caused four hours of degraded service and a regulatory notification. The provider offers a new managed AI fraud-detection service at attractive pricing, and the product team wants to adopt it immediately. The board risk committee reviews IT risk as a standing line item but has never agreed an appetite statement for availability, concentration, or third-party risk. The regulator has asked for evidence that the board understands and controls concentration risk. The CTO argues that multi-cloud would double run costs; the CRO wants a moratorium on new services with the provider. You are asked to prepare the committee's decision.
1. How should the committee frame risk appetite for availability and concentration, and what decision should it take on the AI service?
Read the worked answer
The committee should convert vague concern into an appetite statement with measurable tolerances.
- Availability: define tiered services and maximum tolerable disruption; for example, core payments must not exceed a stated outage threshold, with a lower tolerance for the AI service.
- Concentration: set a limit on the share of tier-1 workloads with any single provider, plus a requirement for exit or portability plans and annual testing.
- Third party: require evidence of provider resilience, regulatory access, subcontractor visibility, and contractual termination rights.
On the AI service, a moratorium is a blunt instrument; unconditional adoption is worse. The committee should direct a conditional, stage-gated pilot: prove fraud-loss reduction against a baseline, assess model risk and explainability, data residency, lock-in and exit, and confirm the service stays within the concentration appetite. Approve limited spend and a review date; do not approve irreversible integration. If the provider fails the conditions, the decision is 'not yet'. This exploits the opportunity while controlling the risk, and gives the regulator evidence of active oversight.
2. What does good board-level IT risk reporting look like in this situation, and how does it differ from a risk register?
Read the worked answer
Board reporting should be an aggregation and decision tool, not a risk register printout.
A good pack would show:
- The top five IT risks in business language, with owner, current tolerance position, trend, and the decision required.
- Concentration and availability against appetite, including a plausible outage scenario and estimated customer and regulatory impact.
- Treatment status and assurance: what has been tested, by whom, and what failed.
- Forward-looking indicators: contract expiry, provider changes, regulatory findings, dependency on key vendors.
- Interconnections: how a cloud outage affects fraud, liquidity, and customer remediation.
A risk register is a management inventory of many risks and controls. The board needs the few risks that threaten strategic objectives, the aggregate exposure, and choices. It should also see dissent and uncertainty, not only green ratings. If the pack contains 60 risks and no tolerance breaches, monitoring is failing.
3. How do you exploit the AI opportunity while aligning with business strategy?
Read the worked answer
Exploiting the AI opportunity should be tied to strategy, not to vendor enthusiasm.
- Start with the strategic problem: fraud losses, false declines, customer friction, or analyst workload. Quantify the baseline.
- Test strategic fit: does the service improve a stated strategic outcome, or create a new dependency that conflicts with resilience?
- Run a bounded pilot with pre-agreed success measures and a kill criterion. Include model risk, fairness, explainability, and regulatory acceptability.
- Assess total economics, not the vendor's payback claim: integration, data preparation, monitoring, staff change, and exit.
- Sequence it behind data readiness and identity controls; if the data foundation is weak, fix that first or scope the pilot narrowly.
- Report benefits and risks to the board at stage gates, with a named business owner.
The board should approve a portfolio of options, not a single silver bullet. That is how opportunity exploitation stays aligned with strategy and within risk appetite.