UK regulatory context

Cloud exit in the UK operational-resilience regime

FCA mapping and scenario testing, and PRA stressed-exit expectations, reinforce the need to connect important services to evidence that can be challenged.

UK operational-resilience expectations use a different legal and supervisory structure from DORA, but they create a similar practical pressure: firms need to understand the technology supporting important services and test whether their plans work under disruption.

FCA: map and test important services

The FCA says firms in scope should identify important business services, set impact tolerances, perform mapping and testing, and identify vulnerabilities through testing. The business service and its tolerable disruption remain the governing context; an infrastructure inventory is only one input.

PRA: plan for stressed exits

The March 2026 update to PRA Supervisory Statement SS2/21, effective from 18 March 2027, says stressed-exit plans should be appropriately documented and tested as far as possible. It focuses on the outcome—continued provision of important business services—rather than prescribing one exit form, and points to portability tools as one possible enabler.

Where technical portability evidence fits

A workload map can help connect a service to its compute, data, network, identity and third-party dependencies. A target model can show where the destination deliberately differs from the source. Workload-level checks can then verify externally meaningful behaviour without requiring every provider component to be recreated verbatim.

This is one evidence stream. Impact tolerances, severe-but-plausible scenarios, people, communications, contracts, data recovery and operational acceptance require wider ownership and testing.

Design around the outcome.

The portable unit should be the workload capability and its observable behaviour, not an assumption that every source-cloud component must have a one-for-one destination equivalent.

Keep claims inspectable

For each run, retain the workload revision, scenario, target, package identity, checks, execution mode, date, result and known limitations. That makes the evidence useful to engineers, risk teams and reviewers without presenting it as a regulatory determination.