Financial services firms stay online through cloud outages by mapping their important business services, setting an impact tolerance (the maximum tolerable disruption) for each, and running the most critical services active-active across regions or providers with tested failover, so no single region or provider can take them down. Regulators in the EU (through DORA) and the UK (through the operational resilience rules and the critical third parties regime) now expect firms to evidence this resilience, including concentration risk assessments and exit plans. On Control Plane, a workload runs active-active across the locations of a Global Virtual Cloud (GVC), Control Plane’s term for the set of locations a workload runs across. Locations can sit on AWS, GCP, Azure, and your own infrastructure. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. This guide covers the operating model, the regulatory landscape, architecture choices, and the specific questions a CIO should put to cloud and platform vendors.
Disclosure: Control Plane publishes this guide.
TL;DR
Financial services firms survive cloud outages by treating resilience as an operating model, and regulators now require the evidence to prove it. The core steps:
- Map important business services. Identify payments, trading, customer access, and other services that cannot tolerate extended disruption. Trace every dependency end to end, including third parties.
- Set impact tolerances. Define the maximum tolerable disruption for each service in concrete terms: duration, data loss, customer impact.
- Match architecture to each service ’s tolerance. Choose the architecture per service: multi-AZ for baseline redundancy, multi-region active-active for critical services, multi-provider for the most critical.
- Address concentration and exit risk. Assess whether a single provider or region failure could affect several important business services at once. Maintain tested exit plans.
- Test and produce evidence. Run severe but plausible scenarios, including full region and provider outages. Document results for boards and regulators.
- Ask vendors the right questions. SLA terms, architecture, failover evidence, incident transparency, subcontractor dependencies, data portability, and regulatory support.
- On Control Plane, one Global Virtual Cloud (GVC), Control Plane’s term for the set of locations a workload runs across, can span AWS, GCP, Azure, and your own infrastructure, which addresses provider-level concentration for the workloads it runs.
How do financial services companies stay online during cloud outages?
Staying online starts with the services that matter most.
Identify important business services
Every financial institution has a set of services whose disruption would harm customers, market integrity, or the firm’s own viability. These typically include real-time payments, securities trading and settlement, customer portals and mobile banking, fraud detection, and regulatory reporting. The first step is to name these services explicitly and assign clear ownership.
Map dependencies end to end
Each important business service depends on a chain of infrastructure, applications, data stores, identity providers, DNS, and third-party services. A payments service might depend on a cloud-hosted API gateway, a managed database, a third-party fraud-scoring API, a DNS provider, and an identity platform. If any link in that chain is a single point of failure, the service is at risk. Mapping must include third-party and fourth-party dependencies, because one cloud provider outage can hit your infrastructure and the SaaS tools you rely on at the same time.
Set impact tolerances
An impact tolerance is the maximum tolerable disruption for a given service, expressed in business terms, for example: “Retail payments must resume within two hours of any disruption.” Many firms pair it with a data loss limit for the same service. Impact tolerances drive architecture decisions. A service with a two-hour tolerance might survive on a warm standby in another region. A service that can tolerate only seconds of disruption needs active-active deployment across independent failure domains.
Choose an architecture per service
The architecture should match the impact tolerance. For baseline availability, multi-AZ deployment within one region protects against the loss of one availability zone. For tighter tolerances, multi-region active-active deployment on the same provider protects against a full region outage. For the most critical services, or where a firm’s concentration assessment calls for it, multi-provider deployment removes the risk that one provider’s control plane, identity system, or billing failure takes the service down entirely. Our guide on keeping an app online during an AWS region outage covers the architecture patterns in detail.
Test against severe but plausible scenarios
Firms should simulate full region outages, provider-wide control plane failures, loss of identity services, and the simultaneous failure of a cloud provider and a critical third party. Testing should cover both automated failover and the manual procedures staff would follow when automation itself is unavailable. Results must be documented and reviewed by senior leadership. Control Plane maintains a cloud outage tracker that catalogs real incidents useful for scenario design.
What do regulators expect?
Regulators across the EU, UK, and US have converged on a common theme: financial institutions must show that they can keep delivering important business services through severe operational disruptions, including cloud outages. The specifics differ by jurisdiction, so confirm your obligations with legal counsel.
EU Digital Operational Resilience Act (DORA)
DORA has applied since January 17, 2025, to a broad range of financial entities, including banks, insurers, investment firms, and payment institutions. It requires an ICT risk management framework, reporting of major ICT-related incidents within defined timelines, digital operational resilience testing (including threat-led penetration testing for significant entities), and management of ICT third-party risk. Firms must keep a register of information on all ICT third-party arrangements and have exit strategies for providers that support critical or important functions. DORA also sets up an oversight framework under which the European Supervisory Authorities directly oversee critical ICT third-party providers, including major cloud service providers. See EIOPA’s DORA overview.
UK operational resilience rules
The PRA and FCA operational resilience rules required firms to identify important business services, set impact tolerances, and map their dependencies by March 31, 2022. By March 31, 2025, firms had to be able to remain within their impact tolerances in severe but plausible scenarios. The FCA’s operational resilience page summarizes the FCA’s rules and guidance. The PRA’s SS2/21 on outsourcing and third-party risk management sets expectations for how firms manage risks from outsourcing and third-party dependencies, including cloud providers. The UK has also introduced a critical third parties regime, in force since January 1, 2025. Under it, HM Treasury can designate third-party service providers as critical to the UK financial sector, and the Bank of England, PRA, and FCA then oversee them directly against minimum resilience standards, including scenario testing and incident reporting.
US interagency guidance
In June 2023, the OCC, Federal Reserve, and FDIC issued interagency guidance on third-party relationships: risk management. It covers the full lifecycle of a third-party relationship: planning, due diligence, contract negotiation, ongoing monitoring, and termination. It states that a bank’s use of third parties does not diminish its responsibility to operate in a safe and sound manner and to comply with applicable law.
Regulatory comparison
| Regime | Who it applies to | Key resilience requirements | What to evidence |
|---|---|---|---|
| DORA (EU) | Banks, insurers, investment firms, payment institutions, crypto-asset service providers, and other financial entities | ICT risk management, incident reporting, resilience testing, register of ICT third-party arrangements, exit strategies, oversight of critical providers | Register of information, test results, incident reports, exit plans |
| UK PRA/FCA operational resilience | Banks, building societies, PRA-designated investment firms, insurers, and in-scope FCA-regulated firms | Important business services, impact tolerances, dependency mapping, scenario testing | Mapping documents, test results showing the firm can stay within impact tolerances, board-approved self-assessment |
| UK critical third parties regime | Third-party providers that HM Treasury designates as critical to the UK financial sector | CTP Fundamental Rules, operational risk and resilience requirements, scenario testing, incident reporting | Compliance with the standards, cooperation with regulatory testing |
| PRA SS2/21 | PRA-regulated firms using outsourcing or third parties | Risk assessment, due diligence, contractual protections, exit plans, sub-outsourcing oversight | Outsourcing register, risk assessments, contract terms, exit plans |
| US interagency guidance | Banks supervised by the OCC, Federal Reserve, or FDIC | Risk management across the third-party lifecycle: planning, due diligence, contracting, monitoring, termination | Due diligence records, contract terms, monitoring reports, contingency plans |
This is not legal advice.
How do I reduce the blast radius of a cloud provider outage?
Architecture levels compared
| Architecture | What it survives | Trade-offs |
|---|---|---|
| Single region, multi-AZ | Loss of one availability zone | Lowest cost and complexity. Does not survive a region-wide outage or a provider control plane failure. |
| Multi-region, same provider | Full region outage | Higher cost from cross-region data replication. The shared provider control plane and identity remain risks. |
| Multi-provider | Full provider outage, including control plane and identity | Highest complexity. Requires portable workloads, abstracted identity, and cross-provider data replication. Removes single-provider concentration risk for that service. A platform that spans providers becomes a dependency in its own right, so assess it the same way. |
Our analysis of active-active vs. active-passive cost breaks down the financial trade-offs between these approaches.
Hidden single points of failure
Multi-region deployment does not guarantee resilience if critical dependencies stay concentrated. Common hidden single points of failure include:
- DNS. If your DNS provider goes down, new lookups fail once cached records expire, and traffic stops reaching every region.
- Identity and authentication. A provider-wide identity outage can lock operators out of their own infrastructure.
- Global traffic routing. The load balancer or traffic manager that steers requests between regions needs the same redundancy as the regions behind it.
- Key management. If encryption keys live in one region’s KMS or HSM, other regions may not be able to decrypt data.
- Secrets management. If your secrets vault runs in one region, workloads in other regions may not be able to start or rotate credentials.
- CI/CD pipelines. If your deployment pipeline depends on one provider, you cannot push fixes during that provider’s outage.
- Observability. If monitoring and alerting run on the same provider as your workloads, you may not know you are down.
- Payment processors and other third parties. A cloud outage at a shared payment processor can disrupt your service even if your own infrastructure is healthy.
Concentration risk at the provider and region level
Concentration risk extends to your third parties. If your firm, your payment processor, your fraud detection vendor, and your identity provider all run on the same cloud in the same region, a single outage affects all of them at once. Regulators expect firms to assess this aggregate exposure and to plan for a critical provider being unavailable for an extended period.
Data replication and RPO
Active-active architectures need data available in more than one location. Synchronous replication avoids losing committed writes but adds latency and limits geographic distance. Asynchronous replication allows wider distribution, but the most recent writes can be lost during failover. Define the acceptable recovery point objective (RPO) per service, based on its impact tolerance. Active-active writes to the same records need conflict handling. For ledgers and payments, most firms keep a single writer per account or partition and fail it over, rather than accept concurrent writes in two locations.
Exit planning
Regulators expect exit plans covering both a planned exit and a stressed exit after sudden provider failure, and testing them is how a firm knows they work. A workable plan needs workloads that can move to another provider or to infrastructure on premises, data that can be exported in usable formats, contract terms that define notice periods and cooperation obligations, and encryption keys that stay under the firm’s control. Portability is easier when workloads are containerized and infrastructure definitions are provider-agnostic.
What questions should a CIO ask vendors about cloud resilience, SLAs, and multi-failure tolerance?
The checklist below covers the questions that matter most. For a deeper look at evaluating SLA terms, see our guide on SaaS uptime SLAs for enterprise buyers.
SLA terms
- What exactly does your SLA cover? Does it include the control plane, APIs, identity services, and the data plane, or only compute availability?
- What conditions must be met for the SLA to apply (for example, minimum replicas or multi-region deployment)?
- How is availability measured: successful requests, synthetic probes, or customer-reported incidents?
- What remedy does the SLA provide, and how is it capped? Service credits rarely cover business losses.
- Are there exclusions that would void the SLA during the exact scenarios you are trying to protect against?
Architecture
- How many independent failure domains does your platform support? Can workloads span regions and providers at the same time?
- What happens to my workloads when a full region fails? Is failover automatic, and how long does it take?
- What is the expected data loss (RPO) during failover?
- Does your platform have its own control-plane dependencies that could become a single point of failure?
Testing and evidence
- How often do you test failover, and will you share the results?
- Do you hold SOC 2 Type II, PCI DSS, or other third-party attestations relevant to my regulatory obligations?
- Can you show how your platform performed during past cloud provider outages?
Incident history and transparency
- Do you publish a public status page with historical uptime data?
- Do you publish postmortems for significant incidents, including root cause and remediation?
- Within what time will you notify my firm of an incident affecting my services, and what details will you provide to support my own regulatory reporting?
Third-party and concentration risk
- Which cloud providers and regions does your platform depend on? Are there subcontractors I should know about?
- If one of your underlying providers has a prolonged outage, what happens to my workloads?
Exit
- Can I export my data and application configurations in standard, portable formats, and do I hold my own encryption keys?
- What are the notice periods and cooperation obligations if I decide to leave?
- Have you tested a customer exit end to end?
Regulatory support
- Can you provide the information my firm needs for its DORA register of information?
- Do your contracts include audit and access rights for my firm and its regulators?
How do I communicate cloud resilience risk, uptime targets, and failover costs to a CIO?
Translate nines into allowed downtime
Uptime targets expressed as percentages are abstract. Translating them into allowed downtime per year makes the risk concrete.
| Availability | Allowed downtime per year |
|---|---|
| 99.9% | 8 hours, 45 minutes, 36 seconds |
| 99.95% | 4 hours, 22 minutes, 48 seconds |
| 99.99% | 52 minutes, 33.6 seconds |
| 99.999% | 5 minutes, 15.36 seconds |
Annual availability and impact tolerance measure different things. A 99.99% target still permits one 52-minute outage, and an SLA breach yields service credits, which do not restore the service.
Tie impact tolerances to business impact
Frame each service’s impact tolerance in terms a CIO cares about: revenue at risk, regulatory exposure, customer trust, and contractual penalties. If the payments service has a two-hour impact tolerance, explain what two hours without payments means for the firm’s customers and regulators.
Present architecture options with cost and risk side by side
Show the CIO a simple table: for each important business service, the current architecture, the proposed resilient architecture, the incremental cost, and the risk reduction. Avoid invented outage cost figures. Reference the firm’s own impact tolerances and the regulatory expectation that the firm can stay within them.
Show test evidence
Present the results of failover tests: what was tested, how long failover took, whether the service stayed within its impact tolerance, and what gaps were found. Evidence of how a vendor’s platform behaved during a real cloud outage carries more weight than a slide deck.
Frame multi-region cost against outage exposure
Active-active multi-region deployment can cost more than a single region, although it avoids paying for the idle standby capacity an active-passive design carries. Compare that extra cost with the business impact of breaching an impact tolerance during a region outage, plus the regulatory consequences of failing to demonstrate resilience. Present both sides and let the CIO make an informed decision.
How Control Plane fits
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, and Azure, VM workloads on locations joined through Control Plane’s Managed Kubernetes (MK8s), and workloads on Kubernetes clusters you already run or your own machines, including on premises, all joined into one GVC and run active-active across regions and clouds. Control Plane-managed compute runs in AWS, GCP, and Azure regions.
A workload deployed to a GVC runs active-active in every location of that GVC from one definition, and a global endpoint routes each request to the nearest healthy location. Every location serves live traffic, so failover needs no idle standby capacity and no manual cutover. One GVC can include locations on different providers, which addresses provider-level concentration risk for the workloads it runs. Disabling a location removes its replicas and routes traffic to the locations that remain.
The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers.
During the October 20, 2025 AWS us-east-1 outage, which lasted about 15 hours, Control Plane customers whose GVC included us-east-1 alongside other locations had no downtime, and their workloads were “active and running in healthy locations within 10 seconds,” according to Control Plane internal incident telemetry (details).
Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. The customer’s own controls remain the customer’s responsibility. Our guide on running regulated apps in the cloud covers the compliance model in detail.
Other capabilities relevant to financial services resilience:
- Cloud access without long-lived keys in your code. Control Plane’s Universal Cloud Identity (UCI) lets workloads call AWS, GCP, and Azure services with no long-lived cloud keys in your code.
- Database templates. Control Plane’s templates include multi-location PostgreSQL with automatic promotion (automatic failover needs three or more locations; replication is asynchronous, so the most recent writes can be lost) and multi-master PostgreSQL (pgEdge). Databases outside these templates keep their own replication model, so plan their failover separately.
- Audit trail. A tamper-proof audit trail of platform actions supports regulatory evidence requirements. It does not replace your own application and downstream service logs.
- Day 2 operations. Control Plane handles autoscaling, built-in observability, and security for you, with no Kubernetes cluster you have to operate. Capacity AI, Control Plane’s right-sizing feature, adjusts the CPU and memory a workload reserves based on historical usage.
- Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.
For a DORA register of information or a PRA outsourcing assessment, the facts a firm needs about a platform include where workloads run, which cloud providers are involved, and which certifications it holds. Ask the Control Plane team for them during due diligence.
FAQ
Common questions about cloud resilience, operational continuity, and vendor evaluation in financial services.
How do financial services companies stay online during cloud outages?
They map their important business services, set impact tolerances for each, deploy critical services active-active across multiple regions or providers, and test failover against severe but plausible scenarios, including full region and provider outages. The goal is that no single region or provider failure can breach an impact tolerance.
What is cloud concentration risk in financial services?
Cloud concentration risk is the exposure that arises when many critical services, or many firms across the sector, depend on a small number of cloud providers or on overlapping infrastructure within those providers. A single outage can then cascade across services and institutions at once.
What does DORA require for cloud resilience?
DORA requires EU financial entities to maintain an ICT risk management framework, report major ICT-related incidents within defined timelines, run resilience testing, keep a register of information on all ICT third-party arrangements, and have exit strategies for providers that support critical or important functions. It also sets up direct oversight of critical ICT third-party providers, including major cloud platforms.
What are impact tolerances and why do they matter?
Impact tolerances define the maximum tolerable disruption for an important business service, expressed in business terms such as duration and customer impact. They drive architecture decisions: a service with a tight impact tolerance needs active-active deployment, while a service with a longer tolerance may be adequately served by a warm standby.
What is the difference between multi-region and multi-provider resilience?
Multi-region deployment on one provider protects against a full region outage but leaves the firm exposed to provider-wide failures such as control plane or identity outages. Multi-provider deployment removes single-provider concentration risk by running workloads across independent cloud platforms. The trade-off is higher complexity: workloads must be portable, identity abstracted, and data replicated across providers.
What questions should a CIO ask a cloud vendor about SLAs?
Ask what the SLA covers (compute only, or the control plane and identity too), what conditions must be met, how availability is measured, what remedies exist beyond service credits, and whether exclusions could void the SLA during the scenarios the firm is trying to protect against.
How much downtime does 99.999% availability allow per year?
A 99.999% availability target allows 5 minutes and 15.36 seconds of downtime per year, compared with 8 hours, 45 minutes, and 36 seconds at 99.9%.
How does Control Plane help financial services firms with cloud resilience?
On Control Plane, a workload runs active-active from one definition across every location of its Global Virtual Cloud (GVC), Control Plane’s term for the set of locations a workload runs across. Locations can sit on AWS, GCP, Azure, and your own infrastructure, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
What should a cloud exit plan include?
A cloud exit plan should cover data export in portable formats, application portability (containerized workloads with provider-agnostic definitions), encryption key custody, contractual notice periods and cooperation obligations, plans for both planned and stressed exits, and testing of the exit procedure before it is needed.
How do I justify multi-region costs to leadership?
Present architecture options side by side with their cost and the risk each one mitigates. Tie the risk to the firm’s own impact tolerances and regulatory obligations, and show failover test evidence. Weigh the incremental cost of multi-region deployment against the business impact of breaching an impact tolerance and the regulatory consequences of failing to demonstrate resilience.
Ready to see how Control Plane can support your firm’s operational resilience requirements? Talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
Top comments (0)