Cloud Oversight Goes Live: What Banks Must Change Now
The UK has moved from designing its critical third parties framework to supervising four major cloud and technology providers. For banks, the shift creates better system-level oversight but no transfer of accountability. The immediate task is to connect vendor assurance, service mapping, testing, incident response and exit planning into one decision-ready control model.
The designation is a market event, not a procurement footnote
On 13 July 2026, the Bank of England, Prudential Regulation Authority and Financial Conduct Authority began overseeing the first providers designated under the UK critical third parties framework. The official announcement names Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd and Oracle Corporation UK Limited. It describes a joint, proportionate regime focused on the resilience of critical services supplied to the UK financial sector.
That is a material change in the control environment. Regulators can now examine system-level dependencies at providers whose disruption could affect many firms simultaneously. Yet designation is neither a regulatory endorsement of a provider nor a substitute for a bank's own controls. The same announcement is explicit that regulated firms remain responsible for due diligence, risk management and contingency planning.
The practical conclusion is simple: banks should treat direct oversight as a new source of sector assurance and coordination, not as permission to reduce internal challenge. A cloud contract can be well governed in isolation while the business service it supports remains fragile because of identity, network, data, software or fourth-party dependencies. Resilience has to be assessed end to end.
What the UK critical third parties regime actually changes
The Bank of England's framework page explains the division of responsibilities. HM Treasury designates providers, while the Bank, PRA and FCA set rules, gather information and oversee the systemic services supplied by those providers. Critical third parties must identify and manage risks to those services and communicate openly and promptly with regulators and client firms, especially during major incidents.
For banks, this can improve the quality of discussions about common controls, testing and incidents. It may also expose where individual institutions have described the same shared service inconsistently. A provider's resilience evidence will increasingly sit beside, rather than outside, supervisory views of the financial system. Banks therefore need a reliable way to reconcile provider terminology with their own important business services, impact tolerances and customer outcomes.
Oversight complements accountability
A designated provider will face direct regulatory expectations, but its customers still decide which workloads to place on the service, how to configure them, what data to hold, which regions to use and how recovery works. Those design choices determine whether a provider incident becomes a manageable degradation or a breach of impact tolerance. The bank owns those choices and the evidence supporting them.
Build one dependency model from customer service to provider component
Most institutions already maintain vendor inventories, cloud configuration records and operational resilience maps. The weakness is often the join between them. A useful dependency model starts with the customer or market outcome, identifies the important business service, traces the supporting process and application, and then reaches the contracted cloud service, region, control plane, data store and critical sub-supplier.
The model should record failure mode as well as ownership. Loss of a cloud region, identity service, network route, encryption key service or management console creates different recovery options. A generic label such as 'hosted on cloud' is too coarse for scenario design. Equally, a list of thousands of technical resources is too detailed for executive decisions. The bank needs a service-level view that can drill down to the components that change recovery time or customer harm.
A sensible minimum data set includes service owner, accountable executive, provider entity, contracted service, deployment region, data criticality, recovery objective, impact tolerance, concentration indicator, tested workaround, exit pattern and evidence date. This creates a common spine for risk, architecture, procurement, compliance and crisis teams.
Replace generic cloud risk scores with failure-mode decisions
Supplier questionnaires remain useful, but they cannot answer the central resilience question: can this particular service remain within tolerance when a plausible dependency fails? Banks should score scenarios rather than providers alone. The same cloud platform may support a non-critical analytics workload and a time-sensitive payments service; the risk response should not be identical.
For each important business service, management should test at least four cases: loss of one availability zone, loss of a region, loss of a shared control-plane function and loss of the bank's ability to access or administer its own environment. A fifth case should cover corrupted or unavailable data, because infrastructure recovery without trustworthy data is not service recovery.
Each scenario needs a pre-agreed decision point. When does the bank fail over, degrade functionality, move to manual processing, pause new activity or communicate to customers? The answer should specify authority, evidence and time, not merely state that a crisis team will decide. This is where an operational resilience framework becomes an operating model.
Use provider assurance without creating an evidence gap
Direct oversight should increase the supply of credible system-level information, but banks will still need evidence that applies to their own configurations and services. Provider reports may demonstrate the design of common controls; they do not prove that a customer's identity policies, backups, network segmentation or recovery automation are effective.
The assurance pack should therefore have three layers. The first is provider-level evidence, including independent reports and relevant regulatory communications. The second is bank configuration evidence, showing how required controls are implemented. The third is service-outcome evidence from exercises, recovery tests and live incidents. A control is only decision-useful when management can connect all three.
Banks should also establish a disciplined intake process for new provider information. Every material assurance update needs an owner, relevance assessment, control impact decision and closure record. Simply storing a new report in a vendor repository creates the appearance of oversight without demonstrating that anyone considered its implications.
Align incident reporting with the new visibility regulators expect
The FCA's March 2026 statement on incident and third-party reporting says that more than 40% of cyber incidents reported to it in 2025 involved a third party. It also confirms a streamlined cross-regulator reporting approach and says the new rules take effect on 18 March 2027. The data is intended to help authorities see through supply chains and identify services exposed to common providers.
Banks should use the intervening period to align operational telemetry with regulatory reporting fields. Incident teams need to identify the affected provider, service, region, business outcome and customer impact quickly. If those elements are reconstructed manually after an event, reporting will be slow and inconsistent precisely when supervisors and customers need clarity.
A strong incident record distinguishes provider cause from bank consequence. It captures when the dependency failed, when the bank detected it, which service tolerance was threatened, what actions were taken and when normal service was restored. This chronology supports notification, lessons learned and vendor challenge without relying on premature root-cause conclusions.
Testing must cross organisational boundaries
The PRA's 2026/27 Business Plan says SIMEX26 will focus on an extended outage at a major third-party technology provider. That is a useful signal: sector exercises are moving toward the shared dependencies that can transmit disruption across institutions.
A bank should prepare at three levels. Internally, it should test technical recovery and business workarounds. Bilaterally, it should exercise notification, escalation and evidence exchange with the provider. At sector level, it should be ready to operate when competitors, payment systems, data vendors and communications channels are also under stress. Plans that assume unlimited provider attention or unaffected counterparties will not survive a systemic event.
Exercises should measure outcomes: time to detect, time to classify, time to invoke the workaround, proportion of priority transactions completed, customer communications latency and unresolved data reconciliation. These measures are more valuable than a pass-or-fail label because they reveal the bottleneck management can fund and fix.
Concentration risk is more than a provider count
Using two cloud providers does not automatically create resilience. Both environments may depend on the same identity platform, network carrier, software pipeline, skills pool or managed-service integrator. Multi-cloud can also increase operational complexity and make recovery less reliable if the secondary environment is rarely used.
Boards should ask where concentration becomes consequential. Relevant measures include the share of important services using a provider, the number of services dependent on one region or control plane, the volume of priority transactions exposed, the time required to restore elsewhere and the availability of people who can operate the alternative. These metrics translate architecture into business exposure.
The appropriate response may be diversification, but it may also be stronger isolation, a tested offline capability, better data portability or deliberate acceptance of a dependency with additional recovery investment. The objective is not a low concentration score. It is a credible ability to deliver priority outcomes through disruption.
Make exit readiness an engineering capability
Traditional exit plans often list notice periods, data-return clauses and transition responsibilities. Those are necessary but insufficient. A credible exit capability needs a target architecture, portable data, rebuildable infrastructure, replacement skills, a sequencing plan and a realistic estimate of service degradation during migration.
Banks should distinguish urgent exit from strategic migration. An urgent exit may prioritise protecting data and sustaining a narrow set of services; a planned migration can optimise cost and design. Testing should prove the critical steps in both paths. Evidence might include restoration to an independent environment, successful export of data and keys, reconstitution of access controls and validation of reconciled records.
A 90-day management agenda
In the first 30 days, identify services that use the four designated providers and reconcile vendor, architecture and important-business-service inventories. Assign an executive owner to every material dependency and document the failure modes that could breach impact tolerance.
By day 60, select the highest-exposure services and test one severe but plausible scenario for each. Close basic evidence gaps, define incident data fields, and agree escalation thresholds with providers and internal teams. Report exceptions as business decisions with cost, customer and recovery implications.
By day 90, present a portfolio view to the board risk committee: concentration by outcome, untested recovery paths, overdue assurance actions, exit feasibility and funded remediation. The report should show trend and decision dates. It should not collapse materially different services into a single vendor rating.
What good looks like
A mature bank will be able to name the customer outcomes exposed to each critical provider, show how those outcomes stay within tolerance, and produce current evidence without assembling it from disconnected teams. Its contracts, architecture, testing and incident response will use the same service taxonomy. Its board will see a small set of decision-relevant measures, while engineers can trace each measure to a component and control.
The UK regime creates a stronger foundation for collective resilience. Its value to an individual bank, however, will depend on how well that bank converts new oversight into better service-level decisions. The strongest response is neither complacency nor indiscriminate duplication. It is disciplined, testable control of dependency.
Frequently asked questions
Does designation mean the four providers are approved for bank use?
No. Designation brings specified providers under direct resilience oversight; it is not authorisation or a guarantee. Banks remain accountable for selecting, configuring and monitoring their third-party arrangements.
Do banks still need their own due diligence and testing?
Yes. Provider-level assurance cannot demonstrate that a bank's specific workload, configuration, data and recovery design will meet its impact tolerance. Service-level testing remains essential.
What should a board see about cloud concentration?
The board should see exposure by important business service, credible recovery time, untested dependencies, common control-plane risks, workaround capacity and remediation decisions, rather than provider spend alone.
How should the UK regime interact with DORA programmes?
Banks operating across the UK and EU should maintain a shared evidence core and map jurisdiction-specific obligations around it. The UK-EU oversight memorandum supports coordination between authorities, but firms still need to evidence compliance in each perimeter.
What is the most useful first action?
Reconcile the important-business-service map with the provider and architecture inventories. That exposes missing ownership, hidden fourth parties and recovery assumptions before the bank invests in additional controls.
References
• Bank of England: UK regulators begin overseeing the first critical third parties
• Bank of England: Critical Third Parties framework, rules and oversight
• Financial Conduct Authority: Incident and third-party reporting rules
• Prudential Regulation Authority: Business Plan 2026/27
• Bank of England: UK-EU memorandum on critical third-party oversight