The UK Just Put Cloud Providers Under Financial Regulatory Oversight. Your Operational Risk Model Is Now Out of Date.

July 13, 2026 · 7 min read · Inglorious Editorial

The UK just handed the Financial Conduct Authority and the Bank of England direct oversight powers over Amazon Web Services, Google Cloud, Microsoft Azure, and Oracle Cloud. These are now designated Critical Third Parties under the Financial Services and Markets Act 2023. That means regulators can walk into those providers, inspect their systems, and impose requirements on how they serve financial services firms.

This is not a future concern. The designation is live. The supervisory framework is being built around it right now. And if your business touches the UK financial system, which means you hold a UK licence, process UK payments, or serve UK customers through a regulated entity, your relationship with cloud infrastructure just became a compliance variable, not just an IT decision.

Most operators have not updated their operational risk frameworks to reflect this. Most will not until something goes wrong.

What the Designation Actually Does

Under the Critical Third Parties regime, regulators are not just watching the cloud providers from a distance. They have powers to set resilience standards, demand audit access, and require providers to demonstrate that their services can withstand stress without taking down dependent financial services firms.

The practical effect is layered. AWS, Azure, Google Cloud, and Oracle will face mandatory resilience testing. They will need to maintain detailed registers of the financial services firms they serve. They will be required to notify regulators of material incidents, outages, and configuration changes that could affect service continuity.

For you, as the downstream operator, this creates something new. Your cloud provider is now a regulated entity in its own right when it comes to financial services. That changes what due diligence you are expected to perform on them, what you need to document in your own risk assessments, and what regulators will expect to see in your Business Continuity Plans and Operational Resilience frameworks.

If your current documentation describes your cloud provider as a vendor and nothing more, it is already wrong.

Why High-Risk Operators Are More Exposed Than They Think

Regulated retail banks have compliance teams that will update their third-party risk frameworks before the ink dries on a policy change. You probably do not have that resource sitting ready.

High-risk operators, whether iGaming platforms, crypto exchanges, payment processors, or forex firms, have historically treated cloud infrastructure as an operational matter. Uptime, latency, cost. The compliance angle, where it existed at all, was usually confined to data residency rules under GDPR and whatever your licence jurisdiction required on paper.

That model is now insufficient for anyone operating under a UK regulatory framework. The FCA has been explicit that operational resilience requirements apply to the full service chain, not just the licensed entity itself. If a critical part of your service depends on a cloud provider and that provider goes down, the regulators want to know that you planned for it, tested your response, and can evidence both.

More acutely, if a cloud provider receives a regulatory directive that affects how it configures services for financial firms, you may find your environment subject to changes you did not initiate and cannot easily reverse. That is not a hypothetical. It is now a structural feature of operating in this space.

What Your Operational Resilience Documentation Needs to Reflect

The FCA and PRA have been building out their operational resilience expectations since 2022, and the Important Business Services mapping requirement is already in force. The Critical Third Parties regime layers on top of that.

At minimum, your documentation now needs to do the following:

Explicitly identify which of the four designated providers you use and for what functions.
Map those dependencies against your Important Business Services, the processes whose failure would cause intolerable harm to customers or the market.
Set and test impact tolerances, the maximum time each Important Business Service can be disrupted before the harm becomes unacceptable.
Include scenarios where your cloud provider is the point of failure, not just your own systems.
Document your exit strategy. If you needed to migrate away from AWS in 90 days, what would that actually require?

If you cannot answer that last question without guessing, you have a material gap. Regulators are not interested in the fact that migration is hard. They are interested in whether you took it seriously before something forced your hand.

The Multi-Cloud Question Nobody Wants to Pay For

For the past several years, multi-cloud architecture has been positioned as best practice by everyone selling cloud services and ignored by most operators who were focused on margin. The cost and complexity of running across two providers simultaneously is real, and for smaller operations, it has rarely been justifiable.

The Critical Third Parties regime changes the calculus, not by making multi-cloud mandatory, but by making single-cloud dependency a documented risk that you now have to own explicitly. If your Important Business Services depend entirely on one designated provider and you cannot demonstrate credible alternatives, that is a finding waiting to happen in your next regulatory review.

The realistic middle ground for most operators is not full multi-cloud. It is documented and tested failover capability, whether that means a secondary provider for specific functions, colocation for critical data, or contractual arrangements that give you meaningful exit rights. What it cannot mean, going forward, is no plan at all.

This is also a negotiating moment. The major cloud providers are now motivated to demonstrate their compliance with the Critical Third Parties framework to their financial services clients. They want to retain this business. That means you have more grounds than you did a year ago to push for resilience SLAs, incident notification timelines, and audit cooperation that your contracts may not currently include.

The Licensing Angle You Are Probably Missing

This change is UK-specific in its origin, but its reach is broader than the FCA's direct jurisdiction. MGA-licensed operators serving UK customers, Gibraltar-licensed payment processors with UK banking relationships, and crypto firms using UK-regulated custodians all sit within the operational influence of this regime, even if they are not directly regulated by the FCA.

Beyond that, the EU is watching. DORA, the Digital Operational Resilience Act, came into full effect in January 2025 and imposes its own Critical ICT Third-Party Provider framework on firms operating across EEA markets. The logic is nearly identical to what the UK has now implemented. Regulators on both sides of the Channel have decided that cloud concentration risk in financial services is a systemic problem, and they are both moving to address it through the same mechanism: direct oversight of the providers themselves.

If you operate across UK and EU jurisdictions, you are now managing two overlapping regulatory frameworks that both touch your cloud infrastructure. They are not identical. The requirements, timelines, and audit mechanisms differ in ways that matter. Running one compliance approach for both will create gaps in at least one of them.

Update your third-party risk register this quarter. Get your cloud contracts in front of someone who understands both DORA and the FCA's Critical Third Parties framework before your next regulatory review. And if your Business Continuity Plan still treats your cloud provider as a background assumption rather than a named, assessed dependency, fix that before a regulator asks you to explain it under pressure.