Key Takeaways:
- Most of financial services' vendor-risk conversation this year has focused on AI vendors. The regulatory capital spent over the past eighteen months has gone somewhere broader: the core technology platform underneath AI, claims, and payments alike - cloud infrastructure, policy administration systems, core banking platforms, and the small number of hyperscale and specialist vendors that increasingly sit behind all of it at once.
- Australia's CPS 230 Operational Risk Management standard, in full effect since 1 July 2025, is built around "material service providers" and "critical operations," not AI specifically, and requires a tested - not merely documented - exit plan and board-level tolerance for disruption.
- The UK's operational resilience regime (PRA/FCA, in force since March 2022) and the EU's Digital Operational Resilience Act (DORA, applicable from January 2025) converge on the same structural question as CPS 230: not which vendors a firm contracts with, but which critical operations resolve to the same underlying infrastructure provider, and for how long a disruption there could be tolerated.
- An institution can have a clean AI vendor exit plan and still have no meaningful exit plan for the cloud region, core policy system and payments rail that AI vendor actually runs on - a gap a narrowly AI-focused vendor review will not surface.
- A three-question diagnostic - which critical operations share an underlying provider, is the exit plan for that dependency tested rather than merely documented, and has the board approved a tolerance for it specifically - does most of the work of finding that gap before a supervisor does.
Introduction
Most of the vendor-risk conversation in financial services this year has been about artificial intelligence: which AI vendors a bank or insurer uses, what happens if one of them fails, and how quickly a firm could exit the relationship. That conversation matters, but it is also, in a narrow sense, a distraction. The vendor concentration risk regulators have spent the most regulatory capital on over the past eighteen months is not AI-specific at all. It is the core technology platform underneath AI, underneath claims, underneath payments, underneath almost everything: the cloud infrastructure, the policy administration system, the core banking platform, and the small number of hyperscale and specialist vendors that increasingly sit behind all of it at once.
Australia's CPS 230: a standard built around the platform, not the model
In Australia, the clearest evidence of this is APRA's Prudential Standard CPS 230 Operational Risk Management, which came into full effect on 1 July 2025, superseding the older CPS 231 Outsourcing standard. CPS 230 does not single out AI. It is written around a broader and, for most institutions, more consequential category: "material service providers" and "critical operations" - the vendors and functions whose failure would materially disrupt a regulated entity's business, regardless of whether the technology involved happens to be labelled AI, cloud, or something else entirely. Regulated entities are required to maintain a register of material service providers, document business continuity and exit plans for each one, and be able to demonstrate - not merely assert - that they could continue critical operations through a prolonged disruption at a single provider.
That requirement lands with particular weight on cloud and core-platform concentration, because unlike a point-solution AI vendor, a core platform or hyperscale cloud provider is frequently load-bearing across an institution's entire operating model. An AI pilot that fails is contained; a core banking platform or primary cloud region that fails is not. Industry commentary following CPS 230's commencement has repeatedly noted that Australian banks and insurers were given a multi-year window - reporting through calendar 2025 and into 2026 - to renegotiate existing cloud and technology contracts specifically to meet the new exit-planning and audit-rights requirements, because many legacy contracts simply did not contain the termination assistance, data portability, and audit provisions CPS 230 now expects as standard.
A system-wide risk, not just a firm-level one
The regulatory attention has not stopped at APRA. The Council of Financial Regulators - which brings together APRA, ASIC, the Reserve Bank of Australia and Treasury - has flagged concentration in cloud and critical third-party technology services as a financial-system stability issue in its own right, separate from firm-level operational risk.
The concern at that level is structural: if a small number of hyperscale cloud providers sit underneath a large share of the regulated financial sector simultaneously, an outage, a commercial dispute, or a geopolitical disruption at one provider is no longer a single-firm operational incident. It becomes a sector-wide event.
The Reserve Bank has separately noted, in commentary on financial system stability, that the growing reliance on a concentrated set of "big tech" infrastructure providers - spanning cloud, data, and increasingly AI infrastructure layered on top of that cloud - is a trend supervisors are watching precisely because it compounds the single points of failure that operational risk frameworks were designed to catch.
Where AI vendor governance and core-platform risk collide
This is where the AI vendor conversation and the core-platform conversation collide, and where most institutions' current risk registers are incomplete. An institution can have a clean, CPS 230-compliant exit plan for its AI vendor - the model provider, the annotation service, the MLOps platform - and still have no meaningful exit plan for the cloud region that AI vendor, its core policy system, and its payments rail all happen to run on. The exit plan for the AI vendor is real but shallow if the underlying infrastructure dependency it inherits is unaddressed. A model can be swapped in an afternoon. A cloud region cannot.
Three tests that separate real risk management from a compliance exercise
Three things distinguish genuine core-platform concentration risk management from a compliance exercise built to pass an APRA review.
The first is whether the material service provider register actually traces dependency chains, not just direct contracts. CPS 230's intent is to capture concentration that is structural rather than contractual: a vendor register that lists "AI Vendor A", "Core Policy System B", and "Payments Processor C" as three independent line items, when all three in fact run on the same hyperscale cloud region, has not captured the real concentration. Mapping that dependency - which of an institution's critical operations ultimately resolve to the same underlying infrastructure provider, region, or data centre - is harder and less visible than listing direct vendor contracts, and it is exactly the layer that a narrowly AI-focused vendor review misses.
The second is whether the exit plan for a core platform is tested, not just documented. CPS 230 asks for demonstrable continuity capability, and law firm commentary on the standard since its commencement has repeatedly emphasised that this is the dividing line APRA is expected to probe hardest in supervisory reviews through 2026: a written exit plan that has never been exercised, costed, or timed is materially weaker evidence of operational resilience than one that has been tested against a realistic disruption scenario, even partially. For an AI vendor, a tabletop exercise is feasible within weeks. For a core banking platform or primary cloud provider, testing an exit plan properly can itself be a multi-quarter undertaking, which is precisely why so many institutions have not done it and precisely why a regulator asking the question first should be treated as a near-certainty rather than a remote risk.
The third is governance accountability at the board and executive level specifically for concentration risk, as distinct from individual vendor risk. CPS 230 pushes operational risk ownership upward, requiring boards to understand and approve the institution's tolerance for disruption to critical operations. A board that has approved an AI vendor risk appetite statement but has never been asked to approve a tolerance for core-platform or cloud-region concentration has a gap that a supervisory review is likely to surface, because the standard's logic treats concentration in critical infrastructure as a board-level risk question, not a technology-team checklist item.
Three jurisdictions, one structural insight
Australia is not an outlier here; it is simply further along in supervisory practice than some comparable markets. The United Kingdom's operational resilience regime, jointly overseen by the Prudential Regulation Authority and the Financial Conduct Authority, has required banks, insurers and financial market infrastructure firms since March 2022 to identify "important business services," set impact tolerances for disruption, and map the people, processes, technology, and third parties - including cloud and critical IT providers - that each important business service depends on.
The mapping exercise the UK regime demands is, in substance, the same dependency-chain exercise CPS 230 asks of Australian institutions: not "which vendors do we have contracts with," but "which of our most important services would stop functioning if a single underlying provider failed, and for how long could we tolerate that." The European Union's Digital Operational Resilience Act (DORA), which came into application in January 2025 across EU banks, insurers and other financial entities, goes a step further on concentration specifically: it introduces a direct oversight regime for "critical ICT third-party providers" - a category aimed squarely at the hyperscale cloud and infrastructure providers that sit underneath large numbers of regulated firms simultaneously - recognising that concentration risk at that layer is a supervisory concern in its own right, not simply an aggregation of individual firms' vendor risk.
Three regimes, three jurisdictions, and the same structural insight: operational resilience regulation has moved past treating vendor risk as a bilateral issue between one firm and one supplier, and toward treating infrastructure concentration as a systemic one. For an Australian insurer or bank with offshore operations or reinsurance relationships touching UK or EU entities, this is not a theoretical parallel - it means the core-platform concentration question is likely to arrive from more than one regulator, on more than one timeline, and the institutions that build a single dependency-mapping capability rather than three jurisdiction-specific compliance exercises will spend less to answer all three.
Why insurance carries a sharper version of this risk
Insurance carries a particular version of this exposure that is easy to underweight. A life or general insurer's core policy administration system, claims platform, and increasingly its underwriting and pricing models are more likely than a bank's core banking stack to have been migrated to cloud-native, vendor-hosted platforms in the past five to seven years, often from a smaller pool of specialist InsurTech infrastructure vendors than the hyperscalers serving banking. That can mean a sharper concentration profile: fewer alternative providers to fail over to, and, in some cases, specialist vendors whose own business continuity capability has not been tested at the scale a tier-one insurer's claims volume would require during a genuine regional outage.
An insurer's material service provider register that treats its policy administration vendor, its claims vendor, and its pricing-model vendor as three unrelated line items - when two or three of them are hosted by the same underlying cloud provider, or are themselves dependent on a shared specialist infrastructure layer - has the same blind spot described above, just concentrated in a sector with fewer substitute providers to fall back on.
A practical diagnostic: three questions in sequence
What does a credible response look like in practice, short of a multi-quarter infrastructure re-architecture? Three questions, asked in sequence, do most of the diagnostic work.
First: of our critical operations - not our AI pilots, our critical operations - which ones ultimately resolve to the same cloud region, data centre, or infrastructure provider, even where the contracts sit with different named vendors?
Second: for each of those shared dependencies, is there a documented and tested exit or continuity plan, or only a documented one?
Third: has the board been asked to approve a tolerance for disruption to that shared dependency specifically, separate from any AI-specific risk appetite statement already in place?
An institution that cannot answer the first question with confidence does not yet have a material service provider register in the sense CPS 230, the UK resilience regime, or DORA intend - it has a vendor contract list, which is a necessary but materially different thing.
What this means for leaders building the business case
None of this is reason to deprioritise AI vendor governance - the work already under way on AI vendor exit planning, documented elsewhere in this series, remains necessary. It is a reason to recognise that AI vendor governance is a subset of a larger problem, and that a core-platform concentration gap can sit underneath an otherwise well-run AI governance programme without being visible in the AI vendor register at all. The institutions best positioned heading into 2026 supervisory reviews are the ones treating the material service provider register as a dependency map first, and a vendor list second.
For an underwriting, claims, or technology leader building the business case for closing this gap, the practical next step is not a new AI policy. It is a cross-functional review - procurement, technology, risk, and the business lines that depend on the core platform - of which critical operations trace back to a shared infrastructure provider, and whether the exit plan for that shared dependency has been tested, costed, and signed off at board level. That review is less visible than an AI pilot and harder to resource than a model-vendor audit. It is also, on the evidence of where CPS 230 supervisory attention has gone since July 2025, the review most likely to be asked for next.
There is also a sequencing argument for doing this work now rather than waiting for a supervisory letter to prompt it. APRA's own public commentary through 2025 and into 2026 has repeatedly framed AI adoption and third-party technology concentration as connected risks, not parallel ones - the regulator's letters to regulated entities on AI use have explicitly referenced third-party supplier dependency as part of the same conversation. That framing suggests institutions that fold core-platform concentration mapping into their existing AI governance uplift - rather than treating it as a separate, later-stage piece of work - will find it easier to present a coherent operational risk narrative when a supervisory review does arrive, and will have already done a meaningful share of the underlying dependency-mapping work regardless of which risk category eventually triggers the review.
Conclusion
The cost of waiting is asymmetric in a specific way. An AI vendor exit plan that turns out to be incomplete is embarrassing and fixable within a quarter. A core-platform or cloud-region exit plan that turns out to be undocumented, untested, or simply absent - discovered because a supervisor asked for it, or worse, because a provider actually failed - is neither quickly embarrassing nor quickly fixable.
The gap between "we have a vendor register" and "we have a tested understanding of what happens to our critical operations if our primary infrastructure provider is unavailable for an extended period" is the gap most institutions have not yet closed, and it is the one CPS 230, the UK operational resilience regime, and DORA all converge on as the question that matters most.
Frequently Asked Questions
Is core-platform concentration risk different from AI vendor risk? Yes. AI vendor risk concerns a specific model, annotation or MLOps provider and is relatively quick to remediate - a model can be swapped in an afternoon. Core-platform concentration risk concerns the cloud region, core banking or policy administration system, and infrastructure layer that AI vendors, claims systems and payments rails often run on simultaneously, and a disruption there cannot be resolved as quickly.
What does CPS 230 actually require of Australian banks and insurers? CPS 230, in full effect since 1 July 2025, requires regulated entities to maintain a register of "material service providers" and "critical operations," document business continuity and exit plans for each, and be able to demonstrate - not merely assert - continuity through a prolonged disruption at a single provider, with board-level approval of the institution's tolerance for that disruption.
Do the UK and EU have equivalent requirements? Yes. The UK's operational resilience regime (PRA/FCA, in force since March 2022) requires firms to map the technology and third parties each "important business service" depends on and set impact tolerances for disruption. The EU's DORA (applicable from January 2025) goes further by introducing direct oversight of "critical ICT third-party providers" - the hyperscale cloud and infrastructure providers sitting underneath many regulated firms at once.
Why does insurance face a sharper version of this risk than banking? Insurers' policy administration, claims and pricing systems have more often migrated to cloud-native platforms from a smaller pool of specialist InsurTech infrastructure vendors than the hyperscalers serving banking, which can mean fewer alternative providers to fail over to and less-tested continuity capability at the scale a major outage would require.
What is the fastest way to find this gap before a supervisor does? Three questions in sequence: which critical operations resolve to the same underlying cloud region or infrastructure provider regardless of which vendor holds the contract; is the exit plan for each shared dependency tested rather than only documented; and has the board approved a tolerance for disruption to that shared dependency specifically, separate from any AI-specific risk appetite statement.
Reference List
Australian Prudential Regulation Authority (APRA) (2023) Prudential Standard CPS 230 Operational Risk Management. Sydney: APRA. Effective 1 July 2025.
Clayton Utz (2025) CPS 230: what financial institutions need to know. Sydney: Clayton Utz.
Allens (2025) CPS 230 Operational Risk Management: a practical guide. Sydney: Allens.
Corrs Chambers Westgarth (2025) Preparing for CPS 230. Sydney: Corrs Chambers Westgarth.
Piper Alderman (2025) CPS 230 and material service providers. Sydney: Piper Alderman.
MinterEllison (2025) CPS 230: the practical playbook. Sydney: MinterEllison. Available at: https://www.minterellison.com/articles/apra-ai-letter-third-party-suppliers (Accessed: 6 November 2026).
Council of Financial Regulators (CFR) (2026) Financial stability considerations: cloud and critical third-party technology concentration. Canberra: CFR.
Reserve Bank of Australia (RBA) (2026) Commentary on AI, big-tech infrastructure concentration and financial system stability, as reported by itnews.com.au.
Bank of England, Prudential Regulation Authority and Financial Conduct Authority (2021) Building operational resilience: impact tolerances for important business services. London: Bank of England/PRA/FCA. In force from March 2022.
European Union (2022) Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Brussels: European Parliament and Council of the European Union. Applicable from 17 January 2025.