Chapter 27: Key Takeaways — Cloud Compliance: Regulatory Requirements for Cloud Adoption

1. DORA Chapter IV establishes the most comprehensive cloud governance framework in effect. The EU's Digital Operational Resilience Act, effective January 2025, creates binding obligations for all EU-regulated financial entities around ICT third-party risk management. Chapter IV covers due diligence before engaging cloud providers, mandatory contractual provisions, the ICT third-party register, concentration risk management, and the Critical ICT Third-Party Provider (CTPP) designation framework through which the ESAs can subject hyperscale cloud providers — AWS, Azure, GCP — to direct regulatory oversight. DORA is not a principles-based framework: it specifies what contracts must contain and what governance processes must be in place.

2. DORA Article 30 defines the minimum contractual content for every cloud agreement. Contracts with cloud providers must include: a clear description of services and measurable SLAs; specification of data locations; provisions on availability, authenticity, integrity, and confidentiality of data; the firm's right to audit (including through reliance on pooled third-party audit reports); sub-outsourcing notification and approval provisions; exit assistance and transition support obligations; incident notification timelines; and termination rights allowing the firm to exit for regulatory compliance reasons. Cloud providers publish compliance addenda addressing these requirements, but firms must formally execute the relevant addendum — referencing it in principle is not sufficient.

3. The EBA Outsourcing Guidelines (2019) established the EU baseline that DORA supersedes for in-scope firms. Before DORA, the EBA Guidelines on Outsourcing were the primary framework for cloud governance across EBA-supervised institutions. They introduced the outsourcing register — a comprehensive record of all outsourcing arrangements — and established the requirement to identify critical or important functions, conduct due diligence, and include specific contractual protections. DORA replaces and significantly strengthens these requirements for financial entities in scope. The EBA guidelines remain relevant for institutions not yet covered by DORA's full scope.

4. The shared responsibility model is the single most important technical concept for compliance professionals. Every cloud service model — IaaS, PaaS, or SaaS — comes with a specific allocation of security responsibilities between the provider and the firm. Under IaaS, the firm retains responsibility for the operating system, applications, and data. Under SaaS, the provider manages nearly everything and the firm is responsible for configuration and data governance. Compliance professionals must understand where the firm's responsibilities begin and ensure that both sides of the shared responsibility boundary are covered. A common compliance failure is assuming that "the cloud is secure" without specifying which layer of security the cloud provider actually manages.

5. Data residency compliance requires auditing all data flows, not just the primary data location. Setting the primary AWS region to eu-west-2 or the Azure region to uksouth does not ensure UK data residency compliance. Operational data — CloudWatch logs, monitoring metrics, diagnostic data, backup replications — may flow to regions outside the required residency zone without explicit configuration to prevent it. GDPR and UK GDPR require that personal data not be transferred outside the EEA or UK without appropriate legal mechanisms (adequacy, SCCs, or contractual addenda). A complete data residency assessment maps all data flows, including operational and logging data, not merely the primary application data store.

6. Exit strategy planning is a regulatory requirement, not a commercial nicety — and it must be tested. Both DORA and the UK's SS2/21 require that firms have a documented and tested exit strategy for every critical cloud arrangement. The exit strategy must specify how data will be extracted (format, tooling, timeline), what alternative providers or architectures are available, and what transition service arrangements are in place. Regulatory expectation has moved beyond documentation: supervisors expect evidence that the exit process has been exercised — that data extraction has been run, the timeline validated, and the RTO confirmed achievable. Architectural choices that create deep vendor lock-in (use of highly proprietary cloud-native services) create exit strategy compliance risk.

7. Concentration risk is a systemic concern that regulators are beginning to address directly. The majority of financial institutions rely on one of three cloud providers for critical workloads. Regulators — the FCA, PRA, and ESAs under DORA — regard this concentration as a systemic risk: a disruption at a single provider could simultaneously impair dozens of regulated firms. DORA requires firms to assess and manage concentration risk at the firm level. At the system level, the CTPP designation framework allows regulators to impose direct requirements on cloud providers. Firms are expected to have documented concentration risk assessments that explain their provider choices, not merely default configurations that have accumulated without governance.

8. The FCA's Critical Third Parties (CTP) regime mirrors DORA's approach and subjects cloud providers to direct UK oversight. The FCA and PRA's PS23/5 CTP regime, operational since 2024, allows the regulators to designate third parties — including cloud providers — as critical to UK financial stability and subject them to direct regulatory oversight, testing requirements, and supervisory expectations. This closes the gap identified in earlier outsourcing frameworks where the cloud provider itself, despite being central to the resilience of dozens of regulated firms, faced no direct regulatory accountability. Firms should expect that designated CTPs will be subject to increasing regulatory scrutiny, which may affect service terms and compliance posture.

9. IaaS and SaaS cloud workloads require different governance approaches but the same regulatory baseline. The governance intensity for a SaaS compliance tool — a sanctions screening platform or AML monitoring system purchased from a vendor — is the same as for a self-hosted application running on IaaS. The contractual requirements of DORA Article 30, the due diligence obligations, the exit strategy requirements, and the data residency obligations all apply. The difference is that SaaS governance is more complex: the firm must assess not only the SaaS vendor's security posture but also the cloud infrastructure on which the vendor's application runs. Many RegTech vendors are themselves SaaS applications running on AWS or Azure, creating a layered outsourcing chain that compliance professionals must map and govern.

10. A cloud compliance program is an operational function, not a one-time project. Building the cloud asset inventory, classifying workloads, conducting due diligence, and reviewing contracts are the initial steps. The ongoing program includes annual due diligence refreshes, annual review of cloud provider audit reports, tracking of SLA performance, processing of sub-outsourcing notifications, monitoring of data residency compliance, and updating exit strategies when workload architecture changes. Cloud compliance must be embedded in the firm's technology change management process: any new cloud workload or any significant change to an existing one should trigger the governance cycle — risk assessment, due diligence check, contract review, regulatory notification where required.