Your Cloud Provider Just Got a Regulator — But You're Still on the Hook

Your Cloud Provider Just Got a Regulator — But You're Still on the Hook

The UK's Critical Third Party regime now directly supervises the big cloud providers. Here's why that doesn't reduce your firm's own resilience obligations — and a practical checklist for staying compliant.

Tony Brown
By Tony Brown ·

On 13 July 2026, something quietly shifted in the plumbing of UK financial services. Four companies — Amazon Web Services, Microsoft, Google Cloud and Oracle — came under the direct supervision of the Bank of England, the PRA and the FCA. They didn't ask for it. They can't opt out of it. For the first time, the firms that run the servers behind much of the UK economy answer to a financial regulator.

If you run a small business in Nottingham that uses Microsoft 365 or hosts your systems on AWS, your instinct might be relief. Someone official is finally watching the giants. Surely that means less to worry about at your end?

Rows of servers in a modern data centre, representing large cloud infrastructure providers

It does not. And the gap between what people assume this regime does and what it actually does is exactly where firms will get caught out.

What actually changed

The Critical Third Party (CTP) regime came out of a simple, uncomfortable observation. So many banks, insurers and payment firms now depend on the same handful of cloud and technology providers that a serious outage at one of them could ripple across the whole financial system. When a single hyperscaler stumbles, it's no longer one firm's problem — it's everyone's.

Regulators had a tool for supervising individual banks. They had nothing for supervising the shared infrastructure underneath them. The CTP regime fills that hole. HM Treasury designates a provider as 'critical', and once designated, that provider must meet resilience and reporting standards set by the regulators. They face scrutiny of their operational resilience, their incident response, their concentration of customers, and their ability to keep services running through disruption.

Crucially, this is supervision of the provider, not a guarantee to the customer. AWS being watched by the Bank of England does not mean the Bank of England is now responsible for your firm's data, your recovery plan, or your ability to keep trading when a service goes down.

The trap: assuming risk has moved

Here is the counterintuitive part, and it's the whole reason this post exists.

Nothing about the CTP regime reduces the obligations that already sit on regulated firms. The FCA's operational resilience rules, the PRA's outsourcing expectations under SS2/21, the requirements to identify important business services and set impact tolerances — all of it remains fully in force. The CTP regime sits alongside those rules. It doesn't replace a single one.

Think of it this way. Your car has a seatbelt and the road has a speed limit enforced by cameras. The speed cameras don't mean you can take the seatbelt off. Both exist because they protect against different failures. Regulating the cloud provider protects the system from a big shared shock. Your own resilience planning protects your customers from your failure to cope when something goes wrong upstream.

And things do go wrong. When a major cloud region has an outage — and they do, more often than the marketing suggests — the regulator supervising that provider doesn't restore your service, notify your clients, or explain to the FCA why your important business service breached its impact tolerance. That's still your job. Or your MSP's job, on your behalf.

Which brings us to the second trap.

MSPs can't offload it either

If you're a managed service provider, or you rely on one, don't read the CTP regime as a licence to point upstream. "The cloud provider is regulated now" is not an answer you can give a client when their systems are down and their customers are locked out.

The firm you support still owns its regulatory obligations. You still own the contractual and practical commitments you made to that firm. When a hyperscaler has a bad day, the client turns to their IT partner, not to Redmond or Seattle. A serious MSP treats the CTP regime as a reason to sharpen its resilience planning, not relax it — because the whole point of the regime is that regulators now consider cloud concentration a real systemic risk. If they think it's serious enough to regulate, you should think it's serious enough to plan around.

This is going to grow

One more thing to bank on: the list of four providers is a starting point, not a finishing line. The regime is built to expand. As dependence on other technology and data providers deepens, expect more designations over time — and expect the standards to tighten as regulators learn what good resilience looks like in practice.

So treating this as a one-off event to file away is a mistake. The direction of travel is clear. Concentration risk in technology supply chains is now a permanent regulatory concern, and the smart move is to build habits that will still make sense in three years, not to react to one headline.

A practical resilience checklist

Here's what firms and their IT partners should actually do, whether or not you fall directly under FCA or PRA rules. Even unregulated SMEs benefit from every one of these.

1. Know what you depend on. Map your critical services back to the specific providers, regions and products underneath them. Most firms are surprised how much runs through one vendor. You can't manage a dependency you haven't written down.

2. Identify your important business services. What must keep working for your customers to be served and your obligations to be met? Payroll, client access, payment processing, order fulfilment. Be specific.

3. Set impact tolerances. For each important service, decide how much disruption you can absorb before real harm is done — measured in hours, transactions or customers affected. This turns a vague worry into a testable target.

4. Stress-test the outage. Actually rehearse what happens if your main cloud region goes dark for four hours. Who does what? How do customers hear about it? Where does the work go in the meantime? A plan you've never tested is a guess.

5. Check your exit and portability. How hard would it be to move a workload if you had to? You don't need a live second provider for everything, but you should understand what you'd do if you were forced to switch — and what data you could get out.

6. Read the contract, not the reassurance. What does your provider actually commit to on uptime, support and incident notification? What are the remedies? The CTP regime doesn't change a word of your commercial agreement.

7. Sort out communications in advance. Half of the damage in an outage is silence. Have templates and a decision-maker ready so customers hear from you quickly and honestly.

8. Review it on a schedule. As the regime expands and your systems change, an annual look isn't a bureaucratic box — it's how you catch the dependency you added six months ago and forgot to plan for.

The bottom line

The CTP regime is genuinely good news for the stability of the UK's digital economy. It closes a real gap. But it closes it at the top of the stack, not at your desk. The regulator now watches the giants; it does not stand behind your recovery plan or answer to your customers.

If your response to the news is to do less, you've read it backwards. The right response is to treat cloud concentration as the recognised risk it now officially is — and to make sure that when something upstream breaks, your firm bends without breaking.

If you're not sure how your business would cope with a cloud outage tomorrow, that's the conversation to have with your IT partner this week. We're happy to be that partner.

Request a no obligation callback