The UK’s First Critical Third Parties Are Named: What Reliant Firms Do Monday Morning

The UK has named its first critical third parties. If you run on any of the four, the temptation this Monday is to assume the regulator now carries the risk you have been carrying. It does not, and reading the announcement that way is the single most expensive mistake available to you this quarter.

On 10 July 2026 HM Treasury announced the first designations under the UK’s critical third parties regime, and oversight by the Bank of England, the PRA and the FCA went live on Monday 13 July. The designating instrument, the Critical Third Parties (Designation) Regulations 2026, names four entities: Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited. If your firm sits inside the UK regulatory perimeter, at least one of those names is almost certainly in your estate, probably underneath something that matters.

This is a field note written the morning after, for the people who now have to decide what actually changes. The short answer: designation changes who the regulator watches. It does not change who owns your resilience.

What the designation actually does

The mechanism is worth being precise about, because the precision is where the misreading happens. The regime rests on powers inserted into the Financial Services and Markets Act 2000, under which the Treasury may designate a provider whose failure or disruption could threaten the stability of, or confidence in, the UK financial system. The final rules and supervisory approach were published by the three regulators in November 2024 and took effect on 1 January 2025. What happened this month is the first use of the designation power itself.

Designation places obligations on the provider, not on you. The four named firms now have to identify and manage risks to their material services, test their own resilience, and keep open and timely communication with regulators and with the firms that rely on them, particularly during a major incident. That is a genuine and useful shift. For the first time a UK supervisor can look directly at the resilience of the cloud substrate beneath a large part of the financial system, rather than inferring it second-hand through hundreds of individual outsourcing files.

What it does not do is transfer anything off your balance sheet of accountability. The regulators said so plainly in the announcement: the regime complements, but does not replace, existing outsourcing and operational resilience rules, and reliant firms remain responsible for managing their own third-party arrangements, including due diligence, risk management and contingency planning. If AWS or Azure goes dark and your critical business service goes with it, the supervisor asking why still asks you first.

The comfortable misreading

Every regime that oversees a supplier produces the same optical illusion in the firms downstream of it. Because a regulator is now inspecting the provider, the provider feels safer, and “safer” quietly becomes “my problem, handled elsewhere.” I watched the identical reasoning appear when the EU began designating critical ICT third parties under DORA. I wrote about the two-sided nature of that designation in an earlier reading of what designation means for both the provider and the firm, and the UK version has the same trap set in the same place.

The illusion is dangerous because it points your attention in exactly the wrong direction. Oversight of the hyperscaler does very little for the risk that actually hurts you, which is not the provider failing in the abstract but your particular configuration failing: the single region you never designed out of, the identity provider with no tested fallback, the data you could not egress inside your recovery window even if you wanted to. None of that is inside the regulator’s view of the CTP. All of it is inside yours.

What to do before you do anything else

The sensible first move is not to relax. It is to re-map your own concentration and exit exposure against the four named entities, now that you know precisely which providers the system has decided are load-bearing. Concretely:

• Re-run the dependency map with the four names as the query. Not “do we use cloud” but “which of our important business services terminate, at any layer, on AWS, Google Cloud, Microsoft or Oracle, including through our own SaaS suppliers who run on them.” The indirect dependencies are the ones that were never on the register.
• Find the concentration you have been tolerating. Designation is the regulator’s statement that these providers are systemically concentrated. That is a hint about where your own single points of failure sit. If three of your critical services and your primary identity plane all rest on one designated provider, that is now a documented, publicly-acknowledged concentration, not a private assumption.
• Test the exit, not the exit plan. Most cloud exit strategies are documents, not capabilities. Ask the harder question: if this provider were unavailable for the length of your impact tolerance, what would you actually do, and have you ever proven it end to end rather than asserted it in a board paper.

The output of that work is a register that treats the designated providers as named, ranked dependencies rather than a general “cloud risk” line item. I have set out how to build one in a separate piece on the hyperscaler dependency register, because it is the artefact a supervisor will reach for first and the one most firms cannot produce cleanly.

The evidence a supervisor will actually ask for

When your supervisor next raises operational resilience, the question will not be “is your cloud provider designated.” They know that; they designated it. The question will be whether you can show that designation did not change your own posture: your mapping of important business services to these providers, your impact tolerances, your tested substitution or recovery arrangements, and evidence that your board understood the concentration rather than outsourced its comfort to a press release. The firms that treated 13 July as a prompt to re-examine their own exposure will have those answers. The firms that treated it as relief will have a gap they created themselves.

The wider technology implications of the CTP framework, from contract leverage to incident communications, are worth reading in full; I have covered the practical ones in a piece on the six technology implications for affected firms. But the single point to carry out of this Monday is simpler than any of them. The regulator now watches your provider. That is not the same as the regulator carrying your risk, and the day you confuse the two is the day you stop doing the work that was keeping you resilient in the first place.