Third-Party Assurance for the CTP Era: Getting Evidence From Providers Who Won’t Change Their Paper

The most expensive misreading of the critical third parties regime is that once your cloud provider is designated, the regulators are watching it so you no longer have to. That is exactly backwards.

On 13 July 2026 the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority began jointly overseeing the first designated critical third parties (CTPs) to the UK financial sector: Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd and Oracle Corporation UK Limited. HM Treasury made the designations under the powers in the Financial Services and Markets Act 2023; the underlying rules, set out in the November 2024 policy statements (PS16/24 from the Bank and PRA, PS24/16 from the FCA), had been in force since 1 January 2025 but only bit once a provider was named.

The regulators were explicit about what the regime does not do. It does not replace the existing outsourcing and operational resilience obligations of the firms that rely on these providers. If you run material workloads on one of the designated four, you still owe due diligence, third-party risk management and contingency planning on that relationship, in full, exactly as you did the week before designation. The oversight sits on top of your duties. It does not absorb them.

The evidence problem designation does not solve

Here is the practical bind. Your supervisor still expects you to hold assurance evidence on a provider you cannot negotiate with. The designated CTPs sell standardised services on standardised paper. You do not get a bespoke master services agreement, a custom audit clause or a negotiated exit schedule because a mid-sized UK firm asked politely. The contract is take-it-or-leave-it, and “leave it” is not a realistic option when your core banking or ledger runs there.

So the question is not how to renegotiate the contract. It is how to build an assurance file out of what the provider already publishes and already contractually commits to, and how to close the gap between that and what a supervisor will ask to see. That is an evidence-assembly problem, not a legal one, and it is the same discipline I described for CPS 230 third-party assurance — read the standard reporting the provider offers, map it to your obligation, and document the residual gap rather than pretending it is not there.

What the hyperscalers actually give you

More than firms assume, if you know where to look and how to read it. The four designated providers each publish a large body of assurance artefacts through their trust or compliance portals. The ones that matter for an outsourcing file are:

• SOC 1 and SOC 2 Type II reports. The Type II report is the one that matters, because it covers the operating effectiveness of controls over a period, not a point in time. These are the closest thing to independent audit evidence you will get, and they are usually available under NDA through the provider’s console rather than on the open web.
• ISO/IEC 27001 certificates and Statements of Applicability. Certification scope is the trap here: read the statement of applicability and the certificate scope to confirm the specific services and regions you use are actually covered, not a sibling service in a different data centre.
• Bridge letters covering the gap between the SOC report period end and today, so your file is not stale.
• Service level and resilience commitments in the published terms — availability targets, region and availability-zone architecture, and the shared-responsibility model that tells you which controls are theirs and which are yours.

The SOC 2 Type II report is the workhorse of the file. But it does not read itself. The section that earns its keep is the complementary user entity controls — the controls the provider assumes you are operating. Every one of those is an obligation the report quietly hands back to you, and a supervisor who knows the document will ask which of them you actually run. Reading the report is where the assurance work is, not obtaining it.

Where the standard paper falls short

Two areas are where the take-it-or-leave-it model bites hardest, and both need handling in your own controls rather than in the contract.

Audit and access rights. Outsourcing rules assume you, and your regulator, can audit a material provider. No hyperscaler will grant a right for every customer to walk its data centres. What they offer instead is pooled audit programmes, the SOC and ISO reports in place of on-site access, and — for regulated financial customers — regulator access provisions that lean on the CTP regime itself. Document that you have assessed those substitutes and concluded they are adequate for the criticality of the workload, or concluded they are not and compensated elsewhere. The decision is yours to record; it will not be made for you.

Exit and stressed exit. This is the weakest point in most files. The standard contract gives you data-retrieval mechanisms and a notice period; it does not give you a tested, costed plan to move a live workload off the platform under stress. The regulators care about exit precisely because designation does not make a provider unfailable — it makes a provider systemically important, which is a different and more worrying thing. Your exit evidence is something you build: a documented alternative (another region, another provider, or degraded on-premise operation), a rough migration cost and timeline, and an honest statement of what you would lose in a stressed exit. A plan that says “we would move to another cloud” without a tested path is not a plan; it is a hope written down.

Build the process, not a one-off pack

The firms that handle this well treat provider assurance as a standing process, not a document assembled the week before an audit. That process starts from a current picture of what you actually depend on — which services, which regions, which internal functions sit on top — which is why a hyperscaler dependency register is the foundation the assurance file is built on. Without it you cannot even scope which SOC report sections apply to you.

From there the cycle is unglamorous and repeatable: pull the current SOC and ISO evidence each period, refresh the bridge letter, re-read the complementary user entity controls against your own control set, revisit the exit assessment when the architecture changes, and log the whole thing so it can be produced on demand. It is the same operational discipline I set out for firms working out what to do the Monday after the designations, and it connects to the wider set of technology implications the CTP regime carries for reliant firms.

There is a related deadline worth holding in view: the new material third-party reporting rules are expected to require firms to maintain and submit registers of material third-party arrangements on an annual basis, with the first submissions understood to fall in 2027 — verify the exact date and scope against the final Bank and FCA rules before you plan the work. The register and the assurance file draw on the same underlying inventory, so building one badly makes the other harder.

Designation moved these four providers under the regulators’ gaze. It moved nothing off your plate. The provider will not change a word of its paper for you, and it does not have to — the work the regime leaves with you is reading what it already gives you well enough to defend the reliance you have chosen.