The UK Critical Third Party regime does not tell financial services firms to abandon hyperscale cloud or adopt multi-cloud by default. Nor does it create a new set of cloud-migration obligations for firms. What it does is make the systemic importance of shared technology providers impossible to ignore.
Concentration, recoverability, substitutability and exit should therefore be explicit design inputs before a business-critical workload moves. A migration can improve infrastructure and still weaken operational control. If the target architecture leaves an important service dependent on a provider, region or shared component that the firm cannot adequately map, test, recover from or exit, the migration has exchanged one form of risk for another.
Key takeaways
- The CTP regime does not require firms to abandon hyperscale cloud or adopt multi-cloud by default.
- Since 13 July 2026, the systemic services supplied to the UK financial sector by designated entities within AWS, Google Cloud, Microsoft and Oracle have been directly overseen by the Bank of England, PRA and FCA.
- Concentration risk exists across six layers, not simply the number of cloud providers. The layers are; provider, region and availability architecture, managed services, shared enterprise services, supply chain and skills and operating model.
- Five concentration-risk tests should be applied when assessing regulated cloud migrations. The tests are; dependency mapping, provider-failure testing, recovery before redundancy, substitutability and exit and explicit governance of concentration decisions.
- A separate joint regulatory reporting regime takes effect on 18 March 2027. Firms within scope will need to notify the FCA about new or significantly changed material third-party arrangements and maintain an annual register. Migration programmes with accurate supplier and dependency mapping will be better placed to support this work.
What changed on 13 July 2026?
The Financial Services and Markets Act 2023 amended the Financial Services and Markets Act 2000 to give the Bank of England, Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA) powers to oversee designated Critical Third Parties.
The regulatory framework took effect on 1 January 2025. Direct oversight began on 13 July 2026, when the first designation regulations came into force and the regulators started overseeing the systemic services supplied by four designated providers.
The four designated Critical Third Parties are:
- Amazon Web Services EMEA SARL
- Google Cloud EMEA Limited
- Microsoft Ireland Operations Limited
- Oracle Corporation UK Limited
Designation does not mean these providers have suddenly become unsafe choices. Nor does it mean that every service they offer is treated as systemic. As the FCA explains, regulatory oversight is targeted at the systemically important services they provide to the UK financial sector.
The regime also does not transfer accountability from regulated firms to their providers. Firms, their boards and senior management remain responsible for managing their own third-party arrangements and meeting the operational resilience and outsourcing requirements that apply to them. The CTP regime complements those existing responsibilities; it does not replace them.
For CIOs, CTOs and architecture leaders, the practical implication is clear. Regulators may now oversee a critical provider directly, but each firm must still understand and manage what happens to its own services when that provider, or another shared dependency beneath it, is disrupted. For firms subject to the operational resilience rules, that includes demonstrating how important business services will remain within their impact tolerances.
Cloud concentration risk is not simply a provider-count problem. The risk is often reduced to one question – are we too dependent on one hyperscaler?
That is too crude. The more useful question is; how much important service capability could fail at the same time because of one shared dependency?
The Bank of England’s July 2026 Financial Stability Report highlights the potential for correlated disruption through shared providers, common software components and critical infrastructure. The FCA’s March 2026 operational resilience review also reinforces the need for firms to understand third-party vulnerabilities and use severe but plausible disruption scenarios in their resilience testing.
Concentration can therefore exist across several layers:
| Concentration layer | What to examine |
|---|---|
| Cloud provider | How many business-critical services depend on the same provider? |
| Region and availability architecture | Could a regional, availability-zone or control-plane failure disrupt several workloads at the same time? |
| Managed services | Are critical applications tightly coupled to proprietary databases, identity, messaging or other managed services? |
| Shared enterprise services | Do supposedly independent environments still rely on the same identity, DNS, network, CI/CD, monitoring or security service? |
| Supply chain | Which subcontractors, software components and infrastructure services sit beneath the immediate provider relationship? |
| Skills and operating model | Can your teams operate, recover or rebuild the service outside the current platform? |
A nominally multi-cloud estate can still contain a common failure domain. Conversely, a single-cloud architecture can be designed with strong recovery, appropriate portability and tested fallback arrangements.
The objective is not cloud diversity for its own sake. Rather, it is controlled dependency.
These six layers show where concentration may exist. The five tests that follow, determine whether that concentration is understood, recoverable and governed.
What the CTP regime brings into sharper focus
Catapult CX’s approach to cloud migration starts from a broader principle – migration does not remove risk; it reallocates it.
The CTP designations bring one part of that trade into sharper focus – commercial and operational dependency. Before committing a regulated workload to a target architecture, apply five tests to determine whether any resulting concentration is understood, recoverable and governed.
1. Map the workload to the service it supports
Do not start with the cloud account or application inventory. Start with the service the workload enables.
For firms subject to the operational resilience rules, this means mapping the workload to the relevant important business service and its impact tolerance. Other organisations should apply the same principle to services whose disruption would create material customer, operational or regulatory consequences.
For each relevant workload, identify:
- The business service it supports
- The applicable impact tolerance
- Upstream and downstream applications
- Data flows
- Identity and access dependencies
- Network and connectivity dependencies
- Third-party and subcontracted services
- Monitoring, security and recovery tooling
- Manual workarounds and fallback processes
The FCA’s operational resilience observations reinforce why this matters. Without comprehensive mapping, firms cannot properly understand vulnerabilities, interconnections or the scenarios their resilience testing needs to cover.
The useful output is not another architecture diagram. It is a dependency map that shows what can fail together.
2. Test provider failure, not just application failure
Traditional migration testing often asks whether an application can withstand the failure of a component, instance or deployment.
For a service that matters to customers or the organisation, that is not enough. Testing should also cover severe but plausible scenarios involving the disruption of a provider or shared service.
The FCA’s March 2026 operational resilience review points to the 2025 outages affecting AWS, Microsoft Azure and Cloudflare as examples of scenarios firms should consider in their resilience testing.
Ask:
- What happens if the primary region becomes unavailable?
- What happens if a provider control plane or managed service is degraded?
- What happens if identity, DNS or network access is disrupted?
- Can the service remain within its impact tolerance, where one applies?
- Which recovery assumptions depend on the same supplier that has failed?
- What is the minimum viable service the organisation must continue to provide?
The objective is not to predict the precise cause of the next outage. It is to establish whether the architecture has credible recovery options when a shared dependency becomes unavailable.
3. Define recovery before you define redundancy
Redundancy is not the same as recoverability.
A second region, duplicate environment or alternative provider improves resilience only if the organisation can use it effectively under pressure. Data must be sufficiently current. Access must work. Capacity must be available. Runbooks must be executable. Teams must understand their roles. The recovery route must have been tested.
This is where migration architecture and operational resilience need to meet.
The target-state decision should record:
- Recovery time and recovery point objectives
- How those objectives relate to the relevant business-service impact tolerance
- Tested failover or restoration routes
- Minimum service levels during disruption
- Manual or stand-in arrangements where appropriate
- Accountability for invoking and operating recovery
A resilience design that exists only in a diagram is an assumption and nothing more.
4. Measure substitutability and exit before lock-in becomes expensive
Cloud migration creates value through managed services, automation and platform capabilities. Avoiding every provider-specific feature in the name of portability can remove much of that value.
The opposite extreme is equally weak – adopting proprietary services without understanding the cost, complexity and time required to reverse the dependency.
The FCA’s guidance for firms outsourcing to the cloud and other third-party IT services identifies concentration risk and effective exit planning as areas firms need to consider.
For each material dependency, ask:
- Can the data be exported in a complete and usable form?
- What would need to be rebuilt on another platform?
- Which skills, processes and tools are provider-specific?
- How long would substitution realistically take?
- What contractual, licensing or data-egress constraints apply?
- Can the service continue operating during an exit?
- Which dependencies cannot reasonably be substituted and therefore require stronger recovery controls?
The objective is not zero lock-in. It is known, priced and governed lock-in.
5. Make concentration an explicit architecture decision
Concentration risk becomes dangerous when it is created unintentionally.
A migration may consolidate workloads onto one provider because doing so simplifies operations, strengthens security consistency, improves engineering productivity or reduces cost. Those can all be rational decisions.
But the trade-off should be visible.
For every material concentration decision, record:
- The business benefit
- The dependency being accepted
- The services affected
- The relevant failure scenario
- The recovery or fallback control
- The exit or substitution position
- The accountable owner
- When the decision will be reviewed
This turns concentration from an architectural side effect into a governed risk decision.
Does the Critical Third Party regime mean you need multi-cloud?
The CTP regime does not impose a general requirement for regulated firms to adopt multi-cloud. It strengthens direct oversight of systemic third-party services while leaving firms responsible for managing their own resilience and third-party arrangements.
Multi-cloud can be valuable where it creates a genuinely independent failure domain for an important service. But it can also introduce duplicated tooling, more complex data consistency, fragmented security controls, additional skills requirements and a larger operational surface.
The appropriate decision is therefore workload-specific.
| Approach | Potential benefit | Main question |
|---|---|---|
| Single cloud, multi-region | Lower operating complexity with geographic redundancy | Are the regions, critical services and control planes sufficiently independent? |
| Multi-cloud | Potential diversification at provider level | Can the service genuinely fail over or be restored elsewhere within the required time? |
| Hybrid | Retains selected on-premises capability or creates a separate recovery path | Is the retained environment operationally viable, or is it expensive insurance that has never been tested? |
| Retain or modernise before migration | Avoids moving a workload before its dependencies are understood | What needs to change before migration becomes a better risk trade? |
The wrong target is – use more clouds. The right target is – reduce the chance that one failure can take too much important service capability with it and prove that recovery works.
Build concentration risk into the migration roadmap
Concentration risk should not sit in a separate compliance workstream that begins after the target architecture has already been selected. It needs to be addressed throughout the migration lifecycle.
Catapult CX’s migration approach is Assess. Map. Move. For regulated cloud migrations, that means building dependency, recovery and concentration decisions into every stage.
Assess
- Identify important business services and impact tolerances where the operational resilience rules apply
- Identify other business-critical services whose disruption would create material customer, operational or regulatory consequences
- Understand current third-party dependencies, concentration and common failure domains
- Decide which workloads should migrate, modernise, remain or retire
- Identify existing recovery, substitutability and exit weaknesses
Map
- Map source and target dependencies
- Identify new concentrations across providers, regions, managed services and shared enterprise services
- Define recovery, fallback and substitution controls
- Record accepted concentration decisions and accountable owners
- Design resilience testing before cutover
- Determine what supplier and dependency information must remain current after migration
Move
- Migrate in controlled waves
- Validate resilience as well as technical functionality
- Test recovery routes, fallback arrangements and operational ownership
- Confirm that teams can operate the target environment under disruption
- Keep dependency and supplier information current after go-live
- Feed lessons from incidents, tests and operational experience back into architecture decisions
This approach makes concentration part of the migration decision rather than a risk discovered after the move.
There is another reason to improve supplier and dependency information now. A separate joint regulatory reporting regime takes effect on 18 March 2027. Defined categories of in-scope firms will need to notify the FCA when entering into, or significantly changing, a material third-party arrangement and maintain an annual register of those arrangements.
A migration programme that already maintains accurate supplier, service and dependency mapping will be better placed to support those requirements. The reporting rules are separate from the CTP regime, but both reinforce the value of understanding which external providers support critical services and where material dependencies sit.
What CIOs and CTOs should do now
The July 2026 designations should not trigger a panic-driven re-platforming programme. They should prompt a more rigorous review of existing and planned dependencies.
If you are planning or already delivering a cloud migration, assess the target architecture against five questions:
- Dependency. Which important or business-critical services will become more dependent on a shared provider, platform or service?
- Blast radius. How much service capability could fail at the same time?
- Recovery. Can the organisation continue within the applicable impact tolerance or service requirement if that dependency becomes unavailable?
- Substitutability. What could realistically be moved, restored or replaced elsewhere and how long would that take?
- Control. Has the concentration decision been explicitly accepted, assigned to an accountable owner, tested and scheduled for review?
If those questions have clear, evidence-backed answers, the concentration may be entirely acceptable.
If they do not, the problem is not necessarily that the organisation has chosen the wrong cloud. It is that the migration is creating a risk position it cannot yet explain, control or defend.
Catapult CX’s Migration service helps organisations make these decisions before and during delivery; understanding the current estate, mapping dependencies, designing a fit-for-purpose target and moving systems, applications and data without treating go-live as the only measure of success.
A migration should leave the organisation with more control than it had before the move. The CTP designations make that standard harder to ignore.
Plan a migration that strengthens operational control
Understand the dependencies, concentration risks and recovery requirements within your current estate before committing to a target architecture. Catapult CX helps regulated organisations design and deliver cloud migrations that improve resilience as well as infrastructure.
Frequently Asked Questions
What is the UK Critical Third Party regime?
The UK Critical Third Party regime allows HM Treasury to designate third-party providers whose disruption could threaten the stability of, or confidence in, the UK financial system. The systemic services supplied by designated providers are then jointly overseen by the Bank of England, PRA and FCA.
The regime introduces direct regulatory oversight and resilience requirements for those systemic services. It complements firms’ existing operational resilience, outsourcing and third-party risk responsibilities; it does not replace them. The FCA provides an overview of the regime and its operation.
Which providers were designated as Critical Third Parties in July 2026?
The first four designated Critical Third Parties are:
- Amazon Web Services EMEA SARL
- Google Cloud EMEA Limited
- Microsoft Ireland Operations Limited
- Oracle Corporation UK Limited
Their designations took effect on 13 July 2026, when direct regulatory oversight of their systemic services began. The FCA maintains the current list of designated CTPs.
Are all services supplied by a designated CTP directly overseen?
No. Oversight is targeted at the systemically important services the designated CTP supplies to the UK financial sector. Designation does not bring every product, service or part of the provider’s wider business within the same regulatory oversight.
Does the CTP regime apply only to cloud providers?
No. The regime allows HM Treasury to designate technology, data, operational or other third-party service providers that meet the statutory criteria. The first four designations are global cloud services and technology providers, but future designations are not necessarily limited to cloud companies.
Does the regime change financial firms’ existing responsibilities?
No. Direct oversight of designated CTPs does not transfer accountability away from regulated firms. Firms, their boards and senior management remain responsible for operational resilience, outsourcing and the management of their own third-party arrangements.
They must still understand their dependencies, assess provider risk, maintain appropriate contingency arrangements and meet the regulatory requirements that apply to them.
Does CTP designation mean financial firms should leave those providers?
No. Designation is not a finding that a provider is unsafe or unsuitable. It reflects the potential systemic effect of disruption to the services on which multiple firms and markets rely.
Firms should continue to make risk-based decisions based on their own workloads, dependencies, recovery requirements and regulatory obligations.
Does the CTP regime require firms to adopt multi-cloud?
The regime does not impose a general multi-cloud requirement.
The appropriate architecture may be single-cloud and multi-region, multi-cloud, hybrid, or another model depending on the workload, failure domains and recovery requirements. The objective is not to use more providers; it is to understand concentration and demonstrate that critical services can be recovered.
What should change in a cloud migration strategy because of the CTP regime?
The regime does not prescribe a particular cloud architecture or create a new set of migration rules for firms. It does, however, bring provider concentration and shared technology dependencies into sharper focus.
For regulated workloads, migration assessments should make concentration, shared dependencies, recovery, substitutability and exit explicit before the target architecture is fixed. Those assumptions should then be tested during migration and reviewed after go-live.
The FCA’s operational resilience observations emphasise comprehensive dependency mapping, third-party vulnerability assessment and testing against severe but plausible scenarios.
Is the March 2027 third-party reporting regime part of the CTP regime?
No. It is a separate joint regulatory reporting regime.
From 18 March 2027, defined categories of in-scope firms will need to notify the FCA when entering into, or significantly changing, a material third-party arrangement. They will also need to maintain and submit an annual register of material third-party arrangements.
The reporting regime will give regulators more consistent information about firms’ third-party dependencies. That information may also help regulators identify future Critical Third Parties, but the two regimes impose different requirements on different organisations.
