Four technology providers now sit inside the UK's critical third-party regime. Finance should pay attention
Published 14 August 2026
Four technology providers now sit inside the UK’s critical third-party regime: AWS EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited.
The Bank of England, Prudential Regulation Authority and Financial Conduct Authority began direct oversight on 13 July 2026. That is a significant change in the regulation of technology concentration across financial services. It is not, however, a transfer of responsibility from regulated firms to the regulators.
The FCA’s announcement is explicit. Firms remain responsible for due diligence, risk management and contingency planning around their third-party arrangements. Finance leaders should read the designation as confirmation that dependency on a small number of providers has become a system-level concern.
What the critical third-party regime changes
The regime gives UK financial regulators direct oversight of services provided by designated third parties where disruption could threaten confidence or stability in the financial system. The four initial designations cover businesses that underpin a large share of cloud, data and enterprise technology used by financial firms.
The regulators can require information, test resilience and set expectations for the providers’ services to the sector. That creates a clearer view of risks that no individual customer could assess alone.
It does not make a firm’s own dependency safe. A regulator can scrutinise a cloud provider while a bank, insurer or payments business still has a poorly mapped service, an unrealistic recovery plan or no workable route away from a failed component.
The FCA’s critical third-party guidance describes the regime as complementary to existing outsourcing and operational-resilience duties. That word matters. The new oversight adds a layer. It does not replace the control work inside each firm.
Finance needs a dependency map, not a vendor list
Most organisations can produce a list of major technology suppliers. Far fewer can show how a failure at one supplier reaches a critical business service.
A dependency map starts with the service that customers or the business must continue to receive. It then traces the systems, data flows, integrations, people and third parties required to deliver it.
The difference is important. Microsoft may appear once in the vendor register, but the practical dependency may run through identity management, email, collaboration, analytics, hosted applications and several suppliers whose own products sit on Azure. The direct contract tells only part of the story.
The same is true of AWS, Google Cloud and Oracle. A finance team may not contract with them directly while depending on software providers that do. Fourth-party exposure can be more consequential than the relationship visible in accounts payable.
Finance has a useful role because it sees the contracts, expenditure, renewal dates, insurance requirements and financial health of suppliers. Technology and operational-risk teams see the architecture. The dependency map needs both views.
Start with the ten services whose interruption would create the greatest customer, regulatory or liquidity impact. For each one, identify the underlying providers, including subcontractors where the information is available. Then record the contractual and technical constraints on recovery.
Impact tolerances need financial consequences
Operational-resilience programmes define how much disruption a critical service can tolerate. Those tolerances are often expressed in hours or transaction volumes. Finance should attach consequences to them.
What happens to cash, customer compensation, regulatory exposure and liquidity if the service is unavailable for two hours, one day or three days? Which payment flows stop? Which manual workarounds create new error or fraud risk? Which contractual service credits are immaterial compared with the loss suffered?
This turns an abstract technology scenario into a board decision. A two-hour tolerance is not credible because a policy says so. It is credible when the architecture, people and funding required to recover within two hours have been tested.
The finance model should include the recovery path, not only the outage. Backlogs can create larger operational and customer effects after the technology returns. A payments service that resumes after four hours may take two days to process queued work safely.
The same applies to finance operations. If the ERP, banking interface, expense system or identity provider is unavailable, which payments can still be made and which controls still operate? A manual workaround that removes segregation of duties is not a complete recovery plan.
Substitution is not the same as resilience
Multi-cloud and dual-provider strategies are often presented as the answer to concentration risk. Sometimes they are. Sometimes they create an expensive diagram that cannot support a real switch.
Substitution only works when data, applications, identity, security and operating procedures can move within the required time. A second contract with another provider does not establish that capability.
For each critical dependency, be precise about the recovery strategy. Is the service designed to fail over automatically? Can it be rebuilt elsewhere from tested backups? Is there a manual alternative? Or is the real strategy to wait for the provider to recover?
Waiting may be a rational decision for some services. It should be stated openly and matched to a tolerance the board accepts. False optionality is worse than an acknowledged concentration because it produces confidence without capability.
Finance should also challenge the cost assumptions. Active-active resilience, portable architecture and duplicate capacity are expensive. The business case should compare that cost with the impact of disruption and the probability that the alternative works when needed.
This is not a cyber checklist. The existing article on security risks from AI tools in finance covers access, generated code and supplier-security controls. Critical-third-party planning is about continuity of the service when a strategically important provider fails, is impaired or becomes unavailable.
Exit plans need to be executable before the crisis
Outsourcing contracts routinely contain exit provisions. That does not mean the organisation can exit.
An executable plan answers practical questions. How is the data returned, in what format and within what period? Which integrations need to be rebuilt? What knowledge sits with the supplier? Who owns the migration? What would it cost? How long would parallel running last? What happens if the exit is triggered by supplier distress rather than a planned procurement process?
Test the commercial constraints as well as the technical ones. Minimum terms, data-egress charges, software licences, audit rights and support obligations can change the feasibility of an exit. A plan that assumes supplier cooperation during a dispute or failure needs a second route.
The exit plan should also cover AI services and models built on the designated providers. A finance agent may use a model, retrieval layer, identity system and application hosted across several related services. Moving the visible application may not remove the underlying dependency.
This is why evaluating AI vendors as a CFO must include architecture and subcontractors, not only product functionality. The vendor’s dependency chain becomes part of yours.
What the board should receive
A board does not need a complete cloud-architecture diagram. It needs a concise view of material dependency and the decisions required.
For each critical service, show the principal provider and material fourth parties, the agreed impact tolerance, the tested recovery route, the most recent exercise result and the residual exposure. Highlight any service where the stated tolerance is shorter than the demonstrated recovery capability.
Add the financial consequence of the main disruption scenarios and the investment required to close the largest gaps. That allows the board to make a risk decision rather than receive a technology update.
The Audit or Risk Committee should also see changes over time. New integrations, acquisitions and AI deployments can increase concentration quietly. A dependency assessment completed once will be wrong as soon as the architecture changes.
Set triggers for reassessment: a material contract renewal, a new critical service, a significant provider incident, an acquisition, a change in subcontractors or a major model deployment.
The finance actions to take this quarter
First, reconcile the critical-service map with the supplier ledger and contract register. Find the providers and subcontractors that appear in one view but not the other.
Second, identify where AWS, Google Cloud, Microsoft or Oracle support those services, directly or indirectly. Do not assume a lack of direct contract means a lack of exposure.
Third, compare stated impact tolerances with tested recovery. Where the gap is material, quantify the business consequence and the cost of closing it.
Fourth, select one exit plan and test whether it can actually be executed. A tabletop review is a start. A technical recovery or migration exercise produces better evidence.
Finally, bring the result into the normal finance and risk cycle. Capital allocation, insurance, supplier negotiations and transformation plans should reflect the dependency rather than treating it as an IT matter.
The designation of four providers is a regulatory signal. Technology concentration now has direct system-level oversight because the consequences of failure extend beyond any one firm. The internal response should be equally clear: know what the business depends on, how long it can tolerate failure and what recovery is actually possible.
For the wider control context, read AI governance for finance functions and the connector problem in finance AI. If the dependency map exposes a broader finance-transformation problem, work with me to discuss the leadership required.
Maebh Collins is a Fellow Chartered Accountant (FCA, ICAEW) with Big 4 training and twenty years of operational experience as a founder and senior finance leader.