Vendor Concentration in a Payments Migration
A mid-sized insurer is migrating its claims-payment platform to a single cloud provider over 18 months. The provider will host policyholder bank details and claims adjudication logic. The vendor's standard contract caps liability at 12 months of fees (about $400,000) and offers a 99.9% uptime service credit. The insurer's own operational risk appetite statement says no single third party may support a process whose outage would exceed $2 million in customer harm. The procurement lead argues the cap is market-standard and the service credit addresses availability. The board's risk committee has asked for an assessment before the contract is signed. The insurer has no tested exit plan and the incumbent platform is being decommissioned in 20 months.
1. How should the risk manager test whether this arrangement fits the stated risk appetite, and what does the mismatch imply?
Read the worked answer
The appetite statement is a threshold test, so the risk manager should measure the arrangement against it rather than reason qualitatively.
Estimate the harm of a plausible outage: claims not paid, statutory deadlines missed, customer detriment, and regulatory notification costs. If a 24-hour outage during month-end run produces more than $2 million of customer harm, the arrangement breaches the appetite regardless of the liability cap. The cap is a contractual recovery limit, not a measure of harm; conflating them is the procurement lead's error. A $400,000 cap against a multi-million-dollar harm scenario means the insurer retains most of the loss.
The service credit is also not a control: it compensates for downtime but does not prevent it, and 99.9% permits roughly 8.8 hours of unplanned downtime a year, which may exceed the process's tolerance during peak periods.
The implication is that the risk must be treated, not merely accepted. Options include renegotiating the cap for data-breach and availability events, purchasing cyber or technology E&O cover for the residual, adding redundancy or a secondary provider for critical functions, or escalating to the risk committee as an out-of-appetite decision requiring explicit acceptance with conditions. The assessment should be documented as a formal third-party risk rating so the committee sees the gap plainly.
2. What exit and concentration risks does the 20-month decommissioning deadline create, and how should they be managed?
Read the worked answer
The decommissioning deadline removes the fallback, which converts a vendor risk into a single-point-of-failure risk.
The risk manager should first test reversibility: can the insurer extract its data and adjudication logic in a usable format, and how long would re-hosting take? Without a tested exit plan, the insurer's negotiating position and resilience both weaken. The contract should include data-portability obligations, a defined transition-assistance period, escrow of critical code or configuration, and termination assistance at agreed rates.
Second, address concentration directly. If one provider supports a process the insurer cannot run elsewhere, the firm has outsourced availability without outsourcing accountability. Mitigations include a documented and rehearsed exit plan before go-live, a secondary environment for the most critical functions, or a phased migration that keeps the incumbent platform live until the new one is proven.
Third, sequence the deadlines. The 18-month migration and 20-month decommissioning leave almost no contingency. The risk manager should require a go/no-go gate with a defined fallback date and confirm the incumbent contract can be extended if the gate is missed.
Finally, report the residual position to the risk committee: the arrangement is acceptable only with a tested exit plan and a documented decision on the liability gap.