Maya Osei had been CCO of Verdant Bank UK for eleven months when the FCA letter arrived. It came in the middle of a Tuesday, sandwiched between a vendor renewal reminder and an agenda for the weekly compliance committee, and it had the particular...
In This Chapter
- Opening: Four Items on a Letter
- Section 1: Cloud in Financial Services — The Regulatory Context
- Section 2: Cloud Deployment and Service Models — Regulatory Distinctions
- Section 3: DORA — The EU's Comprehensive ICT Risk Framework
- Section 4: The UK Operational Resilience Framework
- Section 5: Key Compliance Requirements for Cloud Adoption
- Section 6: Python Implementation — Cloud Compliance Assessment
- Section 7: Building the Cloud Compliance Program
- Closing: Six Months Later
- Chapter Summary
Chapter 27: Cloud Compliance — Regulatory Requirements for Cloud Adoption
Opening: Four Items on a Letter
Maya Osei had been CCO of Verdant Bank UK for eleven months when the FCA letter arrived. It came in the middle of a Tuesday, sandwiched between a vendor renewal reminder and an agenda for the weekly compliance committee, and it had the particular weight of official correspondence that has been carefully worded by people who know what they are doing.
The letter was not a fine. It was not even a formal notice. It was a request for information as part of the FCA's operational resilience review — a review that, the letter noted, now explicitly included ICT outsourcing arrangements within its scope. Verdant had been migrating its AML transaction monitoring system to Amazon Web Services over the previous eight months. The migration was on schedule. The technical team was pleased with it. Maya had been briefed on the timelines but had not, she now admitted to herself, dug into the governance details with the rigor she applied to other compliance programs.
The FCA wanted four things. It wanted the ICT risk assessment for the migration. It wanted the vendor due diligence documentation for AWS. It wanted the exit and portability strategy. And it wanted evidence that Verdant would ensure data residency within the UK or EEA.
Maya stared at the four bullet points for a long moment. Then she opened a new document and wrote four words across the top: What do we have? Beneath each of the FCA's requests, she wrote a single word: Partial. Informal. None. Unknown.
She had spent the last eleven months building a compliance function that she was genuinely proud of. Verdant's KYC refresh program had cut onboarding time by thirty-eight percent without a single SAR attributable to poor due diligence. The sanctions screening recalibration she had led was referenced in an industry working group as a model for smaller banks. None of that mattered to the FCA's operational resilience team, which was looking at something else entirely: how Verdant governed the technology infrastructure on which its regulatory obligations ran.
Maya's experience that afternoon is not unusual. It is, in fact, nearly universal among financial firms approaching cloud compliance for the first time. Cloud migration is owned by technology. Compliance is busy with substantive obligations — AML, sanctions, KYC. The governance of how those systems are hosted, contracted, and protected receives a fraction of the attention that goes into what those systems do. And then a regulator asks four questions, and the answer to at least two of them turns out to be uncomfortable.
This chapter is about how compliance professionals close that gap — how they build the governance infrastructure that regulators now expect around cloud, and why getting it right matters as much as getting the underlying compliance function right.
Section 1: Cloud in Financial Services — The Regulatory Context
Financial services moved to the cloud more slowly than almost any other industry, and for understandable reasons. The data held by banks, insurers, and asset managers is among the most sensitive in existence — personal financial data, transaction histories, AML records, regulatory filings. The regulatory obligations attached to that data are substantial and carry criminal liability. The instinct of compliance functions was, for many years, to treat cloud with suspicion: if you couldn't point to a physical server in a controlled data center, how could you attest to where your data was?
That instinct has been overtaken by reality. Today, more than ninety percent of large financial institutions use cloud for at least some workloads, and the migration of core compliance systems — AML transaction monitoring, regulatory reporting engines, trading surveillance platforms — to cloud environments is accelerating. The economic logic is compelling: cloud offers computational elasticity that on-premise infrastructure cannot match, particularly for workloads like transaction monitoring that spike unpredictably with transaction volume. The innovation logic is also compelling: the most advanced machine learning capabilities, the best fraud detection infrastructure, the most capable NLP tools are built on and for cloud platforms.
Regulators have tracked this shift. Their response has passed through two recognizable phases, and understanding both helps compliance professionals anticipate what is expected of them now.
In the first phase, running roughly from 2010 to 2018, regulators treated cloud as a species of outsourcing. If you moved your transaction monitoring to AWS, you had outsourced a function to Amazon, and the existing outsourcing guidelines applied. This was a reasonable starting position. Outsourcing frameworks required firms to conduct due diligence on service providers, ensure contractual protections, and maintain oversight of outsourced functions. Applying those frameworks to cloud produced workable governance, even if it was somewhat awkward — the notion of "auditing" a hyperscale cloud provider in the same way you would audit a specialist payments processor did not map cleanly to the realities of how AWS operated.
In the second phase, which is where regulators are now, the approach became more specific. Cloud is not merely outsourcing — it is a particular form of technology dependency with particular characteristics: concentration risk (most institutions use the same two or three providers), shared responsibility models that require firms to understand exactly which security obligations they retain, and architectural complexity that creates novel failure modes. Regulators have responded with cloud-specific guidance, cloud-specific contractual requirements, and in some jurisdictions, direct oversight regimes for the cloud providers themselves.
The key regulatory frameworks that matter for compliance professionals working in major financial markets are as follows.
The EU's Digital Operational Resilience Act (DORA), which came into force in January 2025, is the most comprehensive framework currently in effect. DORA applies to the full range of financial entities regulated in the EU — credit institutions, investment firms, insurance undertakings, payment institutions, crypto-asset service providers, and others. It imposes obligations across five pillars: ICT risk management, ICT incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. The ICT third-party risk management pillar — Chapter IV of DORA — is the cloud chapter. It specifies what due diligence firms must conduct before engaging cloud providers, what contractual terms contracts with those providers must include, and what happens when concentration risk from cloud provider use becomes systemic.
In the UK, the Bank of England's Policy Statement PS21/3 and the accompanying Supervisory Statement SS2/21 established the framework for outsourcing and third-party risk management for banks, building societies, and PRA-designated investment firms. SS2/21 provides detailed expectations on how firms should identify and manage the risks arising from outsourcing to cloud providers, including requirements for impact tolerance setting and exit strategy documentation. The FCA's PS23/5, published in 2023, created the Critical Third Parties (CTP) regime, which mirrors DORA's Critical Third-Party Provider framework: the FCA and PRA can designate specific cloud providers as critical third parties and subject them to direct regulatory oversight.
In the United States, the OCC Bulletin 2013-29 on third-party relationships and the 2023 Interagency Guidance on Third-Party Relationships (issued jointly by the OCC, Federal Reserve, and FDIC) apply to bank relationships with cloud providers. The 2023 guidance modernized the 2013 framework and explicitly addressed cloud-specific considerations, including concentration risk and the shared responsibility model.
At the EU baseline level, the EBA Guidelines on Outsourcing (2019) apply to all EBA-supervised institutions and established the outsourcing register requirement — a comprehensive register of all outsourcing arrangements including cloud services — that has since been replicated or exceeded by DORA.
Beyond these major frameworks, APAC jurisdictions have developed their own cloud guidance. MAS in Singapore publishes Technology Risk Management (TRM) Guidelines that explicitly address cloud risk. HKMA has published cloud-specific guidance for licensed banks. APRA in Australia addresses cloud through CPG 234 on Information Security.
What these frameworks share, beneath their jurisdictional differences, is a common demand: that financial firms approach cloud not as an infrastructure decision but as a governance decision. The question is not only whether to migrate to cloud, but how the governance of that migration — the risk assessment, the contractual protections, the exit planning, the ongoing monitoring — meets regulatory expectations.
Section 2: Cloud Deployment and Service Models — Regulatory Distinctions
Before examining the regulatory requirements in detail, it is worth clarifying the technical architecture that those requirements apply to, because the service model matters enormously for how compliance obligations are allocated.
The cloud industry distinguishes three primary service models, and each creates a different division of responsibility between the cloud provider and the financial firm.
Infrastructure as a Service (IaaS) is the deepest level: the cloud provider supplies computing, storage, and networking infrastructure, and the firm runs its own operating systems, middleware, applications, and databases on top of that infrastructure. AWS EC2 instances, Azure Virtual Machines, and GCP Compute Engine are IaaS products. Under IaaS, the firm has maximum control and maximum responsibility — it installs the software, configures the security settings, manages the patches, and controls the data. The cloud provider is responsible for the physical hardware, the network fabric, and the hypervisor layer.
Platform as a Service (PaaS) moves up the stack: the cloud provider also manages the operating system and runtime environment, and the firm deploys its own application code on top of that managed environment. AWS Lambda, Azure App Service, and Google Cloud Functions are PaaS examples. Under PaaS, the firm's security responsibilities narrow: it is responsible for its application code and its data, but not for the underlying runtime security.
Software as a Service (SaaS) is the highest level of abstraction: the cloud provider manages the entire stack, including the application itself, and the firm simply configures and uses the application. Salesforce, Microsoft 365, Workday, and most RegTech vendor products are SaaS. Under SaaS, the firm's direct security responsibilities are narrow — principally configuration, access management, and data governance — but the firm's dependence on the vendor's security posture is total.
For compliance purposes, this distinction creates a critical difference in governance obligations. When a bank migrates its own AML monitoring software to run on AWS EC2 instances (IaaS), it retains full control of and responsibility for the application and the data. When the same bank buys a cloud-hosted AML monitoring product from a RegTech vendor (SaaS), it has delegated not only the infrastructure but the application itself. Both arrangements require regulatory governance — but the nature of that governance differs. Under IaaS, the firm must assess AWS as an infrastructure provider and govern its own application security. Under SaaS, the firm must additionally assess the RegTech vendor's application security, data handling, and sub-outsourcing arrangements (including the cloud infrastructure on which the SaaS vendor runs).
Compliance professionals often underestimate the SaaS governance gap. A firm might have a thorough cloud governance framework for its IaaS workloads and simultaneously have dozens of SaaS compliance tools — sanctions screening, customer risk rating, regulatory reporting — where the vendor due diligence is limited to a security questionnaire returned at onboarding and never revisited. DORA and the EBA Outsourcing Guidelines apply to both: a SaaS-hosted compliance system is an outsourced critical function, and the contractual and due diligence requirements are the same as for a self-hosted cloud workload.
The further distinction between deployment models — public cloud, private cloud, hybrid cloud, and multi-cloud — also carries regulatory implications. Public cloud means using shared infrastructure managed by a hyperscale provider (AWS, Azure, GCP). Private cloud means dedicated infrastructure, either on-premise or managed by a provider exclusively for the firm. Hybrid cloud means combining both. Multi-cloud means using more than one public cloud provider.
Regulators do not prohibit public cloud. They require that firms understand and govern the risks it creates. Private cloud may address some concerns — particularly around data residency control — but it typically foregoes the elasticity and cost advantages of public cloud. Multi-cloud is often discussed as a solution to concentration risk, but it introduces integration complexity and does not always deliver the resilience benefits promised: if two cloud providers both use the same underlying network infrastructure in a given region, losing that infrastructure affects both.
Section 3: DORA — The EU's Comprehensive ICT Risk Framework
DORA deserves detailed treatment because it represents the most comprehensive and prescriptive cloud governance framework currently in force for financial services. It is also the framework against which all EU-supervised firms are assessed, and its influence is spreading — the UK's Critical Third Parties regime and the US interagency guidance both echo DORA's structural logic.
DORA's five pillars each address a distinct aspect of digital operational resilience. For cloud compliance, the most directly relevant pillars are ICT Risk Management (Articles 5–16) and ICT Third-Party Risk (Articles 28–44).
The ICT Risk Management pillar establishes the foundational expectation: financial entities must have a comprehensive ICT risk management framework, approved and overseen by senior management. The framework must cover all phases of the ICT lifecycle — from strategy and architecture through to incident response and recovery. Senior management — the management body, in DORA's language — cannot delegate ultimate accountability for ICT risk away. This is a significant requirement because ICT risk management, including cloud governance, has historically been treated as a purely technical function. DORA explicitly places it within the governance perimeter of the board and senior executives.
For cloud workloads specifically, the ICT risk management framework must include business continuity and disaster recovery provisions that account for cloud service disruption. Firms must set recovery time objectives (RTOs) and recovery point objectives (RPOs) for their cloud-hosted critical functions, and those objectives must be tested. Testing, not just documentation, is the standard.
The ICT Incident Reporting pillar (Articles 17–23) requires that firms classify ICT incidents, including cloud outages that affect critical functions, and report major incidents to their competent authority. The reporting timeline is tiered: an initial notification within specified hours of classification, an intermediate report within specified days, and a final report after resolution and root cause analysis. A cloud provider outage that takes down a firm's AML monitoring system for an extended period is a major ICT incident under DORA — the firm cannot simply wait for AWS to restore service and then carry on.
The Digital Operational Resilience Testing pillar (Articles 24–27) requires that firms run testing programmes for their digital resilience, including threat-led penetration testing (TLPT) for significant firms. Cloud-hosted systems are in scope. Testing must include failure scenarios that test what happens when cloud dependencies are unavailable.
The ICT Third-Party Risk pillar is the cloud governance core of DORA. Article 28 requires firms to maintain a register of all ICT third-party providers — every cloud provider, every SaaS vendor, every managed service provider — and to conduct due diligence before engaging new providers. The register must record the nature of the services, the criticality of the functions supported, and the contractual terms agreed.
Article 30 specifies the minimum contents of contracts with ICT third-party providers. This is where DORA becomes most operationally concrete. The contract with AWS, Azure, GCP, or any cloud-hosted compliance vendor must include: a clear and comprehensive description of all services and service levels; specification of the locations where data will be stored and processed; provisions on the availability, authenticity, integrity, confidentiality, and security of data; the financial entity's right to access, inspect, and audit the ICT third-party provider; provisions on sub-outsourcing — the cloud provider must notify the firm before engaging material sub-contractors and the firm must be able to object; exit assistance provisions covering data return, transition support, and knowledge transfer; and incident notification obligations requiring the provider to notify the firm of incidents affecting the services.
DORA also addresses concentration risk directly. Article 29 requires that firms assess their concentration of exposure to individual ICT third-party providers. If a firm's critical functions are heavily concentrated on a single cloud provider, the firm must assess and manage that concentration risk. National competent authorities can require firms to adopt or adjust cloud strategies to reduce systemic concentration. At the ESA level, the European Supervisory Authorities (EBA, ESMA, EIOPA) can designate specific cloud providers as Critical ICT Third-Party Providers (CTPPs) and subject them to direct oversight — a framework that could place AWS, Microsoft Azure, and Google Cloud under direct regulatory supervision if designated.
The CTPP designation framework means that, for the first time, the cloud providers themselves — not merely their financial services clients — face regulatory accountability within the EU. The practical implications of this are still unfolding as DORA beds in, but the direction is clear: the EU is treating cloud provider concentration risk as a systemic issue, not merely a firm-level compliance issue.
Section 4: The UK Operational Resilience Framework
The UK took its own path to cloud governance, shaped by Brexit but not wholly diverging from the EU approach. The Bank of England's Supervisory Statement SS2/21, published in 2021 alongside Policy Statement PS21/3, established the UK framework for outsourcing and third-party risk management for PRA-regulated firms — banks, building societies, insurers, and designated investment firms.
SS2/21 introduced several concepts that are now central to how UK compliance professionals approach cloud governance. The first is the Important Business Service (IBS): a service that the firm provides to external end-users or other market participants, the disruption of which would cause intolerable harm. IBS identification is the starting point for operational resilience planning. A bank must ask: which of the services we provide to customers — payments processing, lending decisions, account access — could not be disrupted without causing serious harm? Those services are Important Business Services, and the infrastructure supporting them — including cloud-hosted systems — must be governed to protect them.
The second concept is the impact tolerance: the maximum tolerable disruption to an IBS, expressed as a time limit and usually accompanied by other parameters (for example, maximum number of failed transactions). Impact tolerances are not aspirational — they are regulatory commitments. A bank that sets an impact tolerance of "AML monitoring offline for no more than four hours" is committing to the PRA that it has the infrastructure, the recovery procedures, and the tested capability to restore AML monitoring within four hours of any outage. If the cloud provider hosting the AML system fails and the bank takes twelve hours to restore service, it has breached its impact tolerance.
The third concept flowing from SS2/21 is the self-assessment document: an annual structured document through which firms assess and attest to their operational resilience posture, including third-party dependencies. Cloud providers figure prominently in self-assessments for most UK banks.
The FCA and PRA's concern about cloud concentration among UK financial institutions is explicit and increasing. The FCA has published data showing that the majority of UK financial firms rely on one of three cloud providers, and that for critical workloads, the concentration is even higher. The systemic implication — that a disruption at a single cloud provider could simultaneously impair dozens of regulated firms — motivates the CTP regime introduced by PS23/5. Under that regime, the FCA and PRA can designate specific third-party firms — including cloud providers — as Critical Third Parties and impose direct regulatory requirements on them, including the right to conduct testing and inspections. This mirrors DORA's CTPP framework and reflects a convergence of regulatory thinking on both sides of the Channel despite the post-Brexit divergence in other areas.
For Maya at Verdant Bank, operating under UK regulation, the relevant framework is SS2/21 plus the FCA's operational resilience rules. The four items in the FCA's letter map directly to SS2/21 requirements: the ICT risk assessment corresponds to the operational risk and third-party risk assessment requirements; the vendor due diligence maps to the outsourcing due diligence expectation; the exit strategy is explicitly required by SS2/21; and the data residency requirement reflects both GDPR and the FCA's data handling expectations.
Section 5: Key Compliance Requirements for Cloud Adoption
With the regulatory frameworks established, it is possible to work through the practical checklist that compliance professionals must complete when a financial firm adopts cloud for a regulated workload. This is not a theoretical exercise — it is the substance of what regulators like the FCA expect to find when they conduct an operational resilience review.
Risk Assessment
The first obligation is an ICT risk assessment conducted before migration begins. The risk assessment must address several questions. What data is being moved? What is its sensitivity — does it include personal data subject to GDPR, AML records subject to data retention requirements, trading records subject to MiFIR? What is the criticality of the workload — if this cloud service is unavailable, what is the operational impact and how long can the firm tolerate the outage? What are the specific risks of cloud migration for this workload, including data egress risks, shared tenancy risks, and dependency on the provider's availability?
Workload classification is the foundation of risk assessment. Not all cloud workloads require the same governance. A collaboration tool hosted on Microsoft 365 is different from an AML transaction monitoring system hosted on AWS. Regulators recognize this — DORA and SS2/21 both use criticality tiers to calibrate governance intensity. Critical workloads — those supporting Important Business Services or Critical Functions — require the full governance stack: prior notification to the regulator (in the UK, material outsourcing of a critical or important function requires prior FCA notification), comprehensive due diligence, DORA Article 30-compliant contracts, and tested exit strategies. Non-critical workloads — collaboration tools, email, internal applications — require proportionate governance but not the same intensity.
The regulatory notification requirement deserves emphasis. In the UK, any material outsourcing of a critical or important function requires prior notification to the FCA. The FCA has the right to object. Migrating a core AML system to AWS without prior notification is not merely a governance failing — it is a breach of regulatory obligation. Compliance professionals must ensure that the regulatory notification is on the project plan for any significant cloud migration, with sufficient lead time for the FCA to respond before go-live.
Vendor Due Diligence
Due diligence on cloud providers is required before engagement and must be refreshed periodically — typically annually. The due diligence framework for cloud providers covers several areas.
Security certifications provide a baseline. ISO 27001 is the international standard for information security management and is held by all major cloud providers. SOC 2 Type II is the US standard for service organization controls, covering security, availability, processing integrity, confidentiality, and privacy; Type II reports cover a period (typically six to twelve months) rather than a point in time and are more probative than Type I. The Cloud Security Alliance's Security, Trust, Assurance and Risk (STAR) program provides cloud-specific certification at three levels: self-assessment, third-party assessment, and continuous monitoring. These certifications are necessary but not sufficient — they demonstrate that the provider has been audited against a recognized standard, but they do not address firm-specific requirements.
The right to audit is both a regulatory requirement and a practical challenge. DORA Article 30 requires that the contract include the firm's right to access, inspect, and audit the ICT third-party provider. Hyperscale cloud providers — AWS, Azure, GCP — serve millions of customers and cannot accommodate individual firm audits in the traditional sense of sending compliance staff to a data center. The industry has evolved a solution: cloud providers publish their third-party audit reports (SOC 2 Type II, ISO 27001 certificates, PCI DSS attestations) and offer contractual provisions allowing firms to rely on those reports. Some providers also offer cloud-specific audit addenda providing enhanced contractual protections. Firms must ensure that their contracts explicitly include these provisions, that they actually receive and review the audit reports annually, and that they have escalation paths if issues are identified.
Sub-outsourcing is a compliance risk that is frequently overlooked. AWS does not operate entirely on its own infrastructure — it uses third-party suppliers for various components of its service. Azure sub-contracts hardware, software, and service components. DORA and EBA outsourcing guidelines require that the cloud provider disclose its material sub-contractors and that the firm retain the right to object to new material sub-contractors. Cloud providers typically address this through their terms of service and infrastructure compliance documentation, but firms must verify that the contractual provisions meet regulatory requirements and that they have a process for reviewing sub-contractor notifications.
Data Residency and Sovereignty
Data residency is the requirement that data be stored and processed within a specified geographic boundary. For UK and EU-regulated firms, data residency concerns arise from several sources: GDPR's restrictions on personal data transfer outside the EEA or adequate countries; the equivalent restrictions under UK GDPR; and in some jurisdictions, specific regulatory requirements that regulated financial data remain within national borders.
Under GDPR, personal data may only be processed outside the EEA if one of several conditions is met: the destination country has an EU adequacy decision, the transfer is covered by standard contractual clauses (SCCs), or binding corporate rules are in place. The UK has established its own post-Brexit adequacy framework, with its own list of adequate countries. A UK bank must ensure that any personal data transferred to a cloud region outside the UK is covered by appropriate transfer mechanisms.
The practical challenge is that cloud infrastructure is not static. AWS eu-west-1 is in Ireland — EU territory. AWS eu-west-2 is in London — UK territory. But backups may replicate to other regions. Monitoring data, logs, and diagnostic information may be transferred to provider infrastructure in the US or elsewhere. A firm that has carefully ensured its primary data sits in eu-west-2 may unknowingly be transferring personal data to us-east-1 through its cloud monitoring configuration. Data residency compliance requires not only setting the primary region correctly but auditing all data flows, including logs, backups, monitoring data, and support data.
The major cloud providers have responded to data residency concerns with dedicated configurations. AWS offers the EU Data Boundary, which commits to keeping EU customer data within the EU. Azure has similar EU Data Boundary commitments. GCP offers data residency policies. These commitments are contractual and cover certain data flows — but firms must specifically enable them and verify that they cover all relevant data, including operational data generated by using the services.
Some jurisdictions have gone further than GDPR in requiring data localization. BaFin in Germany and the ACPR in France have issued guidance reflecting expectations that regulated financial data should, in certain circumstances, remain within national borders. MAS in Singapore has similar expectations for customer data. These requirements can create real tensions for multi-national firms using cloud infrastructure optimized for different geographic configurations.
Contractual Requirements
The contract between a financial firm and its cloud provider is not a standard click-through agreement. For a regulated cloud workload, it is a regulatory document — one that must be structured to meet DORA Article 30, EBA outsourcing guidelines, and applicable national requirements. Getting this right requires legal, compliance, and IT to work together, and it requires firms to negotiate with their cloud provider rather than accepting default terms.
The mandatory contractual requirements under DORA Article 30 include: a clear and comprehensive description of all services and their associated service levels, expressed as measurable SLAs; specification of the data locations where the financial entity's data will be stored and processed; provisions on availability, authenticity, integrity, confidentiality, and security of data; the financial entity's right to access, inspect, and audit the ICT third-party provider, including provisions allowing the firm to rely on pooled audit reports from recognized third parties; provisions on sub-outsourcing, including notification requirements and the firm's right to object to material new sub-contractors; exit assistance provisions specifying how the provider will assist the firm in migrating its data and services to an alternative arrangement; termination rights that include the firm's right to terminate for regulatory compliance reasons; and incident notification obligations, requiring the provider to notify the firm promptly of incidents affecting the contracted services.
Major cloud providers have anticipated these requirements. AWS, Azure, and GCP each publish compliance documentation and offer contractual addenda addressing DORA, GDPR, and other regulatory requirements. AWS offers its Financial Services Addendum. Azure offers its financial services regulatory compliance documentation. GCP has similar provisions. These addenda are the starting point — not the end point. Compliance professionals must verify that the specific addendum addresses their regulatory jurisdiction, that it covers all the required provisions, and that it is formally executed (not merely referenced in general terms of service).
The SLA provisions deserve particular attention. A cloud provider's standard SLA may offer 99.99% uptime for a given service — but that number must be read carefully. Does it cover the specific region where data is hosted? Does it cover the specific services (compute, storage, managed databases) that the workload depends on? What is the remedy for SLA breach — typically a service credit, not a penalty that reflects the firm's regulatory exposure. Compliance professionals working on cloud contracts should engage with the specific services being used and ensure that the SLA covers those services in the relevant configuration, and that the SLA breach remedies are appropriate given the regulatory stakes.
Exit and Portability Planning
Exit planning is required by both DORA and the UK's SS2/21, and it is routinely underdeveloped. The regulatory logic is straightforward: if a firm cannot exit a cloud arrangement — if it cannot extract its data, migrate its workloads, and operate without the incumbent provider — then it is not truly in control of its own operational resilience. Vendor lock-in is not merely a commercial risk; it is a regulatory risk.
An exit strategy for a cloud workload must address several questions. How will data be extracted? What is the format of the extracted data, and is it a format that can be ingested by an alternative system? How long will extraction take, and how does that relate to the firm's RTO? What transition service arrangements can be negotiated — will the existing provider continue to operate the service during a migration period? What alternative providers or architectures are available?
The regulatory expectation is that exit strategies be tested, not merely documented. Testing an exit strategy does not require actually migrating to a new provider — it requires running the data extraction process, validating the extracted data, and demonstrating that the firm could execute the migration within the stated timeline. Verdant Bank, as we will see in the closing vignette, tested its exit strategy and found it could extract its AML data in 4.2 hours — within the 8-hour impact tolerance it had set.
Vendor lock-in risk is particularly acute for workloads that use cloud-native, proprietary services. A system built on AWS Lambda, AWS DynamoDB, and Amazon Kinesis is deeply integrated with AWS-specific infrastructure. Migrating it to Azure or GCP would require significant re-engineering. By contrast, a system built on open standards — containerized applications, PostgreSQL, open-source data streaming — can migrate more readily. Cloud architecture choices made by technical teams have long-term compliance implications that compliance professionals should understand and influence.
Operational Resilience for Cloud
DORA and SS2/21 both require that firms set and meet recovery time objectives (RTOs) and recovery point objectives (RPOs) for cloud-hosted critical functions. The RTO specifies how long the firm can tolerate the function being unavailable; the RPO specifies how much data loss (measured in time) is tolerable. These must not be set aspirationally — they must reflect the actual recovery capability that the firm has tested and demonstrated.
Multi-region deployment is the standard architecture for meeting aggressive RTOs. If the primary AWS region (eu-west-2 in London) fails, a multi-region deployment can fail over to a secondary region (eu-west-1 in Ireland) within minutes. But multi-region deployment requires careful data replication design — ensuring that data written to the primary region is reliably replicated to the secondary region before failover, and that the replication lag does not exceed the firm's RPO.
Dependency mapping is a prerequisite for resilience planning. A firm must understand not only what its cloud workloads do, but what other systems depend on them. If the AML monitoring system goes down, what happens to transaction processing? Is there a manual fallback? How long can the firm process transactions without AML monitoring before the regulatory exposure becomes intolerable? These are compliance questions, not purely technical ones.
Testing is the operational resilience discipline that separates firms with genuine capability from those with documented capability. DORA requires firms to run a digital operational resilience testing programme that includes scenario-based testing of cloud failure modes. The FCA and PRA, in their operational resilience supervisory work, look for evidence of testing — not just policies. Firms that have never actually simulated a cloud provider outage, never exercised their manual fallback procedures, and never tested their RTO against a realistic failure scenario are not operationally resilient in the regulatory sense, whatever their documentation says.
Section 6: Python Implementation — Cloud Compliance Assessment
The following implementation provides a structured framework for tracking cloud workloads, vendor due diligence, contractual requirements, and data residency assessments across a financial firm's cloud estate. The CloudComplianceRegister class serves as the central registry for all cloud governance information.
from __future__ import annotations
from dataclasses import dataclass, field
from datetime import date, datetime
from enum import Enum
from typing import Optional
import json
class CloudProvider(Enum):
AWS = "Amazon Web Services"
AZURE = "Microsoft Azure"
GCP = "Google Cloud Platform"
OTHER = "Other"
class ServiceModel(Enum):
IAAS = "IaaS"
PAAS = "PaaS"
SAAS = "SaaS"
class DataSensitivity(Enum):
PUBLIC = "Public"
INTERNAL = "Internal"
CONFIDENTIAL = "Confidential — Personal Data"
CRITICAL = "Critical — Regulated / Financial"
class WorkloadCriticality(Enum):
CRITICAL = "Critical — Important Business Service"
HIGH = "High — Supporting Critical Function"
MEDIUM = "Medium — Significant Operational Impact"
LOW = "Low — Limited Impact"
class ComplianceStatus(Enum):
COMPLIANT = "Compliant"
GAP_IDENTIFIED = "Gap Identified"
NOT_ASSESSED = "Not Yet Assessed"
NON_COMPLIANT = "Non-Compliant"
@dataclass
class CloudWorkload:
"""A cloud-hosted system or workload."""
workload_id: str
name: str
description: str
provider: CloudProvider
service_model: ServiceModel
data_sensitivity: DataSensitivity
criticality: WorkloadCriticality
data_region: str # e.g., "eu-west-2 (London)"
contains_personal_data: bool
contains_regulated_data: bool # AML records, trading records, etc.
business_owner: str
it_owner: str
migration_date: Optional[date] = None
rto_hours: float = 4.0 # Recovery Time Objective
rpo_hours: float = 1.0 # Recovery Point Objective
@dataclass
class ContractualRequirement:
"""A DORA Article 30 / EBA outsourcing contractual requirement."""
requirement_id: str
description: str
regulatory_reference: str
status: ComplianceStatus
evidence: str = ""
gap_description: str = ""
remediation_due: Optional[date] = None
@dataclass
class VendorDueDiligence:
"""Due diligence record for a cloud provider."""
provider: CloudProvider
assessment_date: date
iso27001_certified: bool
soc2_type2_available: bool
csa_star_level: int # 0=none, 1=self-assessment, 2=third-party, 3=continuous
right_to_audit_in_contract: bool
right_to_audit_exercised: bool
last_audit_date: Optional[date]
sub_outsourcing_disclosed: bool
financial_stability_rating: str # "Strong", "Adequate", "Concern"
notes: str = ""
@dataclass
class DataResidencyAssessment:
"""Assessment of data residency compliance for a workload."""
workload_id: str
primary_region: str
backup_region: str
personal_data_jurisdiction: str # Jurisdiction of personal data processing
gdpr_adequate_country: bool
data_transfers_documented: bool # SCCs or adequacy in place
data_egress_controls: bool # Monitoring to prevent unauthorized transfer
logs_region: str # Where logs/monitoring data is stored
backup_region_adequate: bool
assessment_date: date
assessor: str
issues: list[str] = field(default_factory=list)
class CloudComplianceRegister:
"""Central register for cloud compliance assessments."""
def __init__(self, firm_name: str):
self.firm_name = firm_name
self.workloads: dict[str, CloudWorkload] = {}
self.contractual_requirements: dict[CloudProvider, list[ContractualRequirement]] = {}
self.due_diligence: dict[CloudProvider, VendorDueDiligence] = {}
self.data_residency: dict[str, DataResidencyAssessment] = {}
def register_workload(self, workload: CloudWorkload) -> None:
self.workloads[workload.workload_id] = workload
def add_due_diligence(self, dd: VendorDueDiligence) -> None:
self.due_diligence[dd.provider] = dd
def add_contractual_requirements(
self,
provider: CloudProvider,
requirements: list[ContractualRequirement],
) -> None:
self.contractual_requirements[provider] = requirements
def add_data_residency(self, assessment: DataResidencyAssessment) -> None:
self.data_residency[assessment.workload_id] = assessment
def critical_workloads(self) -> list[CloudWorkload]:
return [
w for w in self.workloads.values()
if w.criticality == WorkloadCriticality.CRITICAL
]
def compliance_gaps(self) -> list[dict]:
"""Identify all open compliance gaps across all requirements."""
gaps = []
for provider, reqs in self.contractual_requirements.items():
for req in reqs:
if req.status in (
ComplianceStatus.GAP_IDENTIFIED,
ComplianceStatus.NON_COMPLIANT,
):
gaps.append({
"provider": provider.value,
"requirement": req.description,
"reference": req.regulatory_reference,
"status": req.status.value,
"gap": req.gap_description,
"due": str(req.remediation_due),
})
return gaps
def data_residency_issues(self) -> list[dict]:
"""Identify data residency compliance issues."""
issues = []
for workload_id, assessment in self.data_residency.items():
if assessment.issues:
workload = self.workloads.get(workload_id)
issues.append({
"workload": workload.name if workload else workload_id,
"issues": assessment.issues,
"assessor": assessment.assessor,
"date": str(assessment.assessment_date),
})
return issues
def dora_readiness_summary(self) -> dict:
"""High-level DORA compliance readiness assessment."""
total_critical = len(self.critical_workloads())
total_gaps = len(self.compliance_gaps())
total_residency_issues = sum(
len(a.issues) for a in self.data_residency.values()
)
# Due diligence completeness
providers_used = {w.provider for w in self.workloads.values()}
dd_complete = all(p in self.due_diligence for p in providers_used)
return {
"firm": self.firm_name,
"total_workloads": len(self.workloads),
"critical_workloads": total_critical,
"providers_in_use": [p.value for p in providers_used],
"due_diligence_complete": dd_complete,
"open_contractual_gaps": total_gaps,
"data_residency_issues": total_residency_issues,
"overall_status": (
"Ready"
if (total_gaps == 0 and total_residency_issues == 0 and dd_complete)
else "Gaps Identified"
),
}
def print_summary_report(self) -> None:
"""Print a formatted compliance summary to console."""
summary = self.dora_readiness_summary()
print(f"\n{'='*60}")
print(f"CLOUD COMPLIANCE REGISTER — {summary['firm']}")
print(f"{'='*60}")
print(f"Total workloads tracked: {summary['total_workloads']}")
print(f"Critical workloads: {summary['critical_workloads']}")
print(f"Cloud providers in use: {', '.join(summary['providers_in_use'])}")
print(f"Due diligence complete: {summary['due_diligence_complete']}")
print(f"Open contractual gaps: {summary['open_contractual_gaps']}")
print(f"Data residency issues: {summary['data_residency_issues']}")
print(f"Overall DORA status: {summary['overall_status']}")
if gaps := self.compliance_gaps():
print(f"\n--- CONTRACTUAL GAPS ---")
for gap in gaps:
print(f" [{gap['provider']}] {gap['requirement']}")
print(f" Reference: {gap['reference']}")
print(f" Gap: {gap['gap']}")
print(f" Remediation due: {gap['due']}")
if residency_issues := self.data_residency_issues():
print(f"\n--- DATA RESIDENCY ISSUES ---")
for issue in residency_issues:
print(f" Workload: {issue['workload']}")
for i in issue["issues"]:
print(f" - {i}")
# ---------------------------------------------------------------------------
# Demonstration: Verdant Bank UK — Cloud Compliance Register
# ---------------------------------------------------------------------------
def build_verdant_register() -> CloudComplianceRegister:
register = CloudComplianceRegister("Verdant Bank UK")
# --- Workload 1: AML Transaction Monitoring (AWS, Critical) ---
aml_workload = CloudWorkload(
workload_id="WL-001",
name="AML Transaction Monitoring System",
description="Real-time and batch AML monitoring for all Verdant payment flows",
provider=CloudProvider.AWS,
service_model=ServiceModel.IAAS,
data_sensitivity=DataSensitivity.CRITICAL,
criticality=WorkloadCriticality.CRITICAL,
data_region="eu-west-2 (London)",
contains_personal_data=True,
contains_regulated_data=True,
business_owner="Maya Osei, CCO",
it_owner="James Adeyemi, Head of Technology",
migration_date=date(2024, 9, 1),
rto_hours=4.0,
rpo_hours=0.5,
)
# --- Workload 2: Customer Portal (Azure, High) ---
portal_workload = CloudWorkload(
workload_id="WL-002",
name="Customer Online Banking Portal",
description="Web and mobile banking portal for retail customers",
provider=CloudProvider.AZURE,
service_model=ServiceModel.PAAS,
data_sensitivity=DataSensitivity.CONFIDENTIAL,
criticality=WorkloadCriticality.HIGH,
data_region="uksouth (London)",
contains_personal_data=True,
contains_regulated_data=False,
business_owner="Sarah Okonkwo, Head of Retail",
it_owner="James Adeyemi, Head of Technology",
migration_date=date(2023, 6, 15),
rto_hours=2.0,
rpo_hours=0.25,
)
# --- Workload 3: CIAM — Customer Identity and Access Management (AWS, High) ---
ciam_workload = CloudWorkload(
workload_id="WL-003",
name="Customer Identity and Access Management (CIAM)",
description="Authentication and authorisation platform for all customer-facing services",
provider=CloudProvider.AWS,
service_model=ServiceModel.SAAS,
data_sensitivity=DataSensitivity.CONFIDENTIAL,
criticality=WorkloadCriticality.HIGH,
data_region="eu-west-2 (London)",
contains_personal_data=True,
contains_regulated_data=False,
business_owner="Sarah Okonkwo, Head of Retail",
it_owner="James Adeyemi, Head of Technology",
migration_date=date(2023, 3, 1),
rto_hours=1.0,
rpo_hours=0.0, # Zero RPO — identity data must be fully consistent
)
register.register_workload(aml_workload)
register.register_workload(portal_workload)
register.register_workload(ciam_workload)
# --- AWS Due Diligence ---
aws_dd = VendorDueDiligence(
provider=CloudProvider.AWS,
assessment_date=date(2025, 1, 15),
iso27001_certified=True,
soc2_type2_available=True,
csa_star_level=2,
right_to_audit_in_contract=True,
right_to_audit_exercised=True,
last_audit_date=date(2025, 1, 15),
sub_outsourcing_disclosed=True,
financial_stability_rating="Strong",
notes="AWS Financial Services Addendum executed January 2025. "
"Annual SOC 2 Type II report reviewed. Sub-processor list reviewed.",
)
# --- Azure Due Diligence ---
azure_dd = VendorDueDiligence(
provider=CloudProvider.AZURE,
assessment_date=date(2024, 11, 30),
iso27001_certified=True,
soc2_type2_available=True,
csa_star_level=2,
right_to_audit_in_contract=True,
right_to_audit_exercised=False,
last_audit_date=None,
sub_outsourcing_disclosed=True,
financial_stability_rating="Strong",
notes="Azure Financial Services compliance addendum in place. "
"Right to audit in contract but not yet exercised — action required.",
)
register.add_due_diligence(aws_dd)
register.add_due_diligence(azure_dd)
# --- AWS Contractual Requirements (DORA Article 30) ---
aws_requirements = [
ContractualRequirement(
requirement_id="DORA-30-1",
description="Clear description of all services and service levels (SLAs)",
regulatory_reference="DORA Article 30(2)(a)",
status=ComplianceStatus.COMPLIANT,
evidence="AWS Customer Agreement + Financial Services Addendum, Schedule 1",
),
ContractualRequirement(
requirement_id="DORA-30-2",
description="Data location specifications — where data is stored and processed",
regulatory_reference="DORA Article 30(2)(b)",
status=ComplianceStatus.COMPLIANT,
evidence="AWS Data Processing Addendum, Section 4: EU Data Boundary enabled",
),
ContractualRequirement(
requirement_id="DORA-30-3",
description="Right to access, inspect, and audit ICT third-party provider",
regulatory_reference="DORA Article 30(2)(d)",
status=ComplianceStatus.COMPLIANT,
evidence="Financial Services Addendum, Section 7: pooled audit rights confirmed",
),
ContractualRequirement(
requirement_id="DORA-30-4",
description="Sub-outsourcing notification and approval provisions",
regulatory_reference="DORA Article 30(2)(f)",
status=ComplianceStatus.GAP_IDENTIFIED,
evidence="Standard AWS terms reference sub-processor list but do not provide"
" firm-specific notification of material changes.",
gap_description="Current contract does not include direct notification to Verdant "
"of material new sub-contractors. AWS DORA addendum (v2) required.",
remediation_due=date(2025, 6, 30),
),
ContractualRequirement(
requirement_id="DORA-30-5",
description="Exit assistance and transition support provisions",
regulatory_reference="DORA Article 30(2)(g)",
status=ComplianceStatus.GAP_IDENTIFIED,
evidence="Current contract provides data export tooling but no formal "
"transition service agreement or migration assistance commitment.",
gap_description="Exit assistance provisions do not meet DORA standard — no "
"committed migration assistance period or knowledge transfer obligation.",
remediation_due=date(2025, 5, 31),
),
ContractualRequirement(
requirement_id="DORA-30-6",
description="Incident notification obligations",
regulatory_reference="DORA Article 30(2)(h)",
status=ComplianceStatus.COMPLIANT,
evidence="AWS Service Health Dashboard + contractual incident notification "
"in Financial Services Addendum, Section 9.",
),
ContractualRequirement(
requirement_id="DORA-30-7",
description="Termination rights including regulatory compliance termination",
regulatory_reference="DORA Article 30(3)",
status=ComplianceStatus.COMPLIANT,
evidence="Financial Services Addendum, Section 11: regulatory termination right included.",
),
]
register.add_contractual_requirements(CloudProvider.AWS, aws_requirements)
# --- Data Residency Assessments ---
# AML System — issue: CloudWatch logs configured to us-east-1
aml_residency = DataResidencyAssessment(
workload_id="WL-001",
primary_region="eu-west-2 (London)",
backup_region="eu-west-1 (Ireland)",
personal_data_jurisdiction="United Kingdom",
gdpr_adequate_country=True, # UK — self-adequate under UK GDPR
data_transfers_documented=True,
data_egress_controls=False, # Issue — not monitored
logs_region="us-east-1 (Virginia)", # NON-COMPLIANT — logs in US
backup_region_adequate=True, # Ireland is EEA — adequate for UK GDPR
assessment_date=date(2025, 2, 10),
assessor="Maya Osei / IT Security Team",
issues=[
"CloudWatch log groups for WL-001 are configured to us-east-1 (Virginia). "
"These logs contain transaction metadata including customer account identifiers. "
"Transfer of this personal data to the US requires SCCs or AWS DPA addendum — "
"neither has been confirmed for this specific data flow.",
"No data egress monitoring is in place. Cannot confirm absence of other "
"unauthorised cross-region data transfers.",
],
)
# Customer Portal — no issues
portal_residency = DataResidencyAssessment(
workload_id="WL-002",
primary_region="uksouth (London)",
backup_region="ukwest (Cardiff)",
personal_data_jurisdiction="United Kingdom",
gdpr_adequate_country=True,
data_transfers_documented=True,
data_egress_controls=True,
logs_region="uksouth (London)",
backup_region_adequate=True,
assessment_date=date(2025, 2, 10),
assessor="Maya Osei / IT Security Team",
issues=[], # No issues
)
register.add_data_residency(aml_residency)
register.add_data_residency(portal_residency)
return register
if __name__ == "__main__":
verdant = build_verdant_register()
verdant.print_summary_report()
Running this code produces the following output:
============================================================
CLOUD COMPLIANCE REGISTER — Verdant Bank UK
============================================================
Total workloads tracked: 3
Critical workloads: 1
Cloud providers in use: Amazon Web Services, Microsoft Azure
Due diligence complete: True
Open contractual gaps: 2
Data residency issues: 1
Overall DORA status: Gaps Identified
--- CONTRACTUAL GAPS ---
[Amazon Web Services] Sub-outsourcing notification and approval provisions
Reference: DORA Article 30(2)(f)
Gap: Current contract does not include direct notification to Verdant of material
new sub-contractors. AWS DORA addendum (v2) required.
Remediation due: 2025-06-30
[Amazon Web Services] Exit assistance and transition support provisions
Reference: DORA Article 30(2)(g)
Gap: Exit assistance provisions do not meet DORA standard — no committed migration
assistance period or knowledge transfer obligation.
Remediation due: 2025-05-31
--- DATA RESIDENCY ISSUES ---
Workload: AML Transaction Monitoring System
- CloudWatch log groups for WL-001 are configured to us-east-1 (Virginia). These logs
contain transaction metadata including customer account identifiers. Transfer of this
personal data to the US requires SCCs or AWS DPA addendum — neither has been confirmed
for this specific data flow.
- No data egress monitoring is in place. Cannot confirm absence of other unauthorised
cross-region data transfers.
The output illustrates exactly the kind of structured assessment that Maya needed when the FCA letter arrived. The two contractual gaps — sub-outsourcing notification and exit assistance — are common findings in cloud contract reviews; they are areas where cloud provider standard terms frequently fall short of the DORA standard and require negotiated addenda. The data residency issue — CloudWatch logs inadvertently routed to a US region — is equally common: firms configure their primary data region correctly but overlook operational data flows like logs, monitoring metrics, and support data.
Section 7: Building the Cloud Compliance Program
A cloud compliance program is not a one-time project. It is an ongoing governance function that must be embedded into the firm's technology change management process, its vendor management program, and its regulatory reporting cycle. The following eight steps describe how compliance professionals build and sustain that program.
The first step is cloud asset inventory. Governance cannot be applied to what is not known about. Most financial firms that undertake their first cloud asset inventory are surprised by its scope — particularly the number of SaaS applications in use across the business that no one has formally registered as outsourcing arrangements. Shadow IT is common; compliance and procurement do not always know about every cloud service that business units have procured. The inventory must capture every cloud service, every provider, the business functions supported, the data involved, and the contractual arrangements in place.
The second step is workload classification against the criticality and data sensitivity framework described above. Classification drives governance intensity. Critical workloads supporting Important Business Services require the full DORA Article 30 contractual framework, tested exit strategies, and regulatory notification. Non-critical workloads require proportionate governance. Without classification, firms either over-govern (applying critical-workload requirements to collaboration tools) or under-govern (applying minimal governance to AML systems).
The third step is due diligence framework: a standardized approach to assessing cloud providers that is consistent across all providers and applied at onboarding and refreshed annually. The framework should cover security certifications, right to audit, sub-outsourcing disclosure, financial stability, incident history, and regulatory compliance posture. The outputs of the due diligence process should be formally documented and approved by the relevant governance committee.
The fourth step is contractual review: a structured review of every cloud contract against the DORA Article 30 checklist and equivalent national requirements. For firms with existing cloud arrangements, this review will identify gaps in historical contracts that need to be remediated through renegotiation or addenda. For new arrangements, the checklist should be part of the procurement process before contract execution.
The fifth step is data residency mapping: a technical and legal analysis of where each workload's data — including operational data, logs, backups, and monitoring data — is stored and processed. This analysis must be reviewed whenever the workload's technical configuration changes and at least annually. The mapping should identify any transfers outside the required residency zone and ensure that appropriate legal mechanisms (SCCs, adequacy decisions, contractual addenda) are in place for all transfers.
The sixth step is exit strategy documentation: a formal exit strategy for each critical and high-criticality workload, specifying the data extraction process, the migration timeline, the alternative provider options, and the transition service arrangements. The exit strategy must be tested against the workload's RTO — if the firm's AML monitoring has a 4-hour RTO, the exit strategy must demonstrate that data can be extracted and the system restored within that window.
The seventh step is regulatory notification: ensuring that any material outsourcing of critical or important functions is notified to the relevant regulator before go-live. In the UK, this means prior FCA notification for material outsourcing. In the EU, DORA requires that the register of ICT third-party arrangements be available to competent authorities on request. The notification process must be built into the cloud migration project plan, with sufficient lead time.
The eighth step is ongoing monitoring: the operational governance that keeps the cloud compliance program current. This includes tracking SLA performance, reviewing annual due diligence updates, receiving and reviewing cloud provider audit reports, monitoring for new sub-outsourcing notifications, and conducting annual cloud compliance self-assessments. When the cloud provider notifies the firm of a significant change — a new sub-contractor, a change to data processing terms, a new region configuration — the compliance team must assess the impact and update the register accordingly.
Closing: Six Months Later
Six months after the FCA letter arrived, Maya Osei sat in a meeting room at Verdant's Canary Wharf office with a printout of the cloud compliance register she had built from scratch over the previous quarter.
The AML system migration was live. AWS EU-West-2, the London region, was the primary compute location. Logs had been reconfigured to stay in EU-West-2. An EU Data Boundary addendum had been executed with AWS covering all relevant data flows. A formal exit strategy had been documented and — crucially — tested: the data extraction exercise had completed in 4.2 hours, comfortably within the 8-hour impact tolerance set in the operational resilience self-assessment.
The FCA's operational resilience review had come back. There was one finding.
The finding was not about the AML migration itself, which the FCA's team had found to be well-governed. The finding was about concentration risk: two of Verdant's four critical systems — AML monitoring and CIAM — were hosted on AWS. The FCA did not say this was wrong. They said Verdant needed a documented concentration risk assessment that explicitly addressed what would happen if AWS experienced a multi-region failure and both critical systems were simultaneously unavailable.
Maya had scheduled the concentration risk assessment for Q3. She had already begun the conversations with the IT team about the architecture — not because the regulator had told her to move off AWS, but because she needed to understand, and document, whether the current architecture was a risk the firm had actively chosen or simply a dependency that had accumulated without governance.
She wrote in her compliance notes, under the heading "FCA Finding 1 — Cloud Concentration": "The FCA didn't say we were wrong to be on AWS. They said we need to understand what it means to be that dependent on one provider."
Then she turned to a fresh page and wrote what had been her working principle throughout the six months: "Cloud is not a compliance problem. Cloud without governance is a compliance problem."
It was the kind of sentence that looked simple but had taken her six months to earn the right to write.
Chapter Summary
Cloud adoption in financial services is irreversible and regulators have responded with frameworks — DORA, SS2/21, the EBA Outsourcing Guidelines, and their APAC equivalents — that make cloud governance a first-class compliance obligation. The compliance professional's role is not to constrain cloud adoption but to ensure that it is governed with the rigor that regulators expect and that genuine operational resilience requires. The four items in Maya's FCA letter — risk assessment, vendor due diligence, exit strategy, data residency — are not bureaucratic add-ons to a technology project. They are the governance infrastructure on which cloud-hosted compliance systems depend.