Chapter 27: Exercises — Cloud Compliance: Regulatory Requirements for Cloud Adoption

Exercise 1: Workload Classification

Objective: Apply the criticality and data sensitivity framework to classify cloud workloads and identify the governance requirements that follow from each classification.

Scenario: Verdant Bank UK is conducting its annual cloud asset inventory. The following five cloud workloads have been identified in the inventory but have not yet been formally classified.

Task A: For each workload, assign a WorkloadCriticality rating (Critical / High / Medium / Low) and a DataSensitivity rating (Public / Internal / Confidential — Personal Data / Critical — Regulated/Financial). Justify your ratings with reference to the regulatory frameworks discussed in this chapter.

Task B: For each workload rated Critical or High, identify the specific governance requirements that apply: (a) does it require prior FCA notification before any migration? (b) does it require a DORA Article 30-compliant contract? (c) does it require a tested exit strategy? (d) does it require a formal data residency assessment?

Task C: Workload 2 (AML Alert Management Platform) is a SaaS product from a RegTech vendor, which is itself hosted on AWS. Explain the layered outsourcing structure this creates and identify what additional due diligence steps are required compared to a workload that Verdant self-hosts on AWS IaaS.

Suggested approach: Use the CloudWorkload and WorkloadCriticality / DataSensitivity enumerations from the chapter's Python implementation as a reference framework. Your written classification should map to the values in those enumerations.

Exercise 2: DORA Article 30 Contract Gap Analysis

Objective: Identify compliance gaps in a cloud contract clause against the DORA Article 30 standard.

Scenario: Verdant Bank UK's legal team has provided the following extract from its contract with a cloud-hosted compliance monitoring vendor. The contract was executed in 2022 and has not been updated since DORA came into force in January 2025.

Extract from Compliance Monitoring Vendor Agreement (executed 2022):

Section 8 — Data and Security

8.1 The Vendor shall implement industry-standard security controls to protect Customer Data stored on the Vendor's platform.

8.2 Customer Data shall be stored in data centers located in the European Economic Area. The Vendor reserves the right to change data center locations upon ninety (90) days' notice to the Customer.

8.3 The Customer may, upon reasonable written notice, request a summary of the Vendor's security certifications. The Vendor shall provide such summary within thirty (30) business days.

Section 12 — Termination

12.1 Either party may terminate this Agreement upon ninety (90) days' written notice.

12.2 Upon termination, the Customer shall have sixty (60) days to export its data using the Vendor's standard data export function. After sixty (60) days, the Vendor shall have no obligation to retain or provide access to Customer Data.

Section 14 — Sub-contractors

14.1 The Vendor may engage sub-contractors in the performance of services under this Agreement without the prior consent of the Customer.

Task A: Review this contract extract against the DORA Article 30 minimum requirements listed in the chapter. For each Article 30 requirement, state whether the contract extract is Compliant, Partially Compliant, or Non-Compliant, and explain your reasoning. Use the following Article 30 requirements as your framework:

• Right to access, inspect, and audit (Article 30(2)(d))
• Data location specification and portability (Article 30(2)(b))
• Sub-outsourcing notification and approval (Article 30(2)(f))
• Exit assistance and transition support (Article 30(2)(g))
• Termination rights including regulatory compliance termination (Article 30(3))
• Incident notification obligations (Article 30(2)(h))

Task B: Draft replacement or supplementary contractual language for each provision you identified as Non-Compliant. Your language should be consistent with DORA Article 30 requirements. Where a provision is absent from the extract (not merely inadequate), draft a new clause.

Task C: Section 12.2 provides sixty days for data export after termination using the Vendor's "standard data export function." Explain why this provision may be inadequate for exit planning purposes, with reference to the specific exit strategy requirements discussed in this chapter.

Exercise 3: Data Residency Configuration Design

Objective: Design a data residency-compliant cloud configuration for a UK bank's AML system migration to AWS.

Scenario: You are the cloud compliance lead at a UK retail bank. The bank is migrating its AML transaction monitoring system to AWS. The system processes approximately 2.4 million transactions per day, identifies suspicious patterns, and generates AML alerts for human review. The data it processes includes: transaction records (amount, sender account, receiver account, timestamp, reference); customer profile data (name, date of birth, address, nationality — personal data under UK GDPR); and AML case records (alert records, analyst notes, SAR preparation files).

The bank's data residency requirements are: all personal data must remain within the UK or EEA; UK GDPR applies; AML records must be retained for five years under POCA 2002 (UK); the bank's operational resilience framework requires a backup region with an RPO of thirty minutes and the backup must also comply with UK GDPR.

Task A: Select the appropriate AWS primary region for this deployment and justify your choice with reference to the data residency requirements. Identify an appropriate backup/DR region and explain why it satisfies both UK GDPR and operational resilience requirements.

Task B: Identify at least four specific AWS services or configurations that could create inadvertent cross-border data transfers — i.e., routes by which data might leave your designated regions without explicit intent. For each, describe how the configuration should be set to ensure data residency compliance.

Task C: Design the data residency assessment structure for this workload using the DataResidencyAssessment dataclass from the chapter's Python implementation. Populate realistic values for all fields, including at least two hypothetical issues that you identify and would need to remediate.

Task D: The bank's CTO proposes using Amazon Rekognition (an AWS AI service for image analysis) to accelerate the KYC document review workflow. Amazon Rekognition processes images by sending them to AWS's AI inference infrastructure. Evaluate the data residency implications of adding Rekognition to this architecture. What questions would you need to answer before approving the use of this service?

Exercise 4: Code Exercise — Concentration Risk Report

Objective: Extend the CloudComplianceRegister class to generate a concentration risk report showing provider concentration across the cloud estate.

Background: The CloudComplianceRegister class developed in this chapter tracks workloads, due diligence, contractual requirements, and data residency assessments. It does not currently include concentration risk analysis — a significant gap given the regulatory importance of concentration risk under DORA Article 29.

Task: Add a concentration_risk_report() method to the CloudComplianceRegister class. The method should:

1. Calculate the number and percentage of total workloads hosted on each cloud provider.
2. Calculate the number and percentage of critical workloads hosted on each cloud provider.
3. Identify any provider where either (a) more than fifty percent of all workloads, or (b) more than sixty percent of critical workloads, are concentrated — and flag these as requiring a formal concentration risk assessment.
4. Calculate a simple Concentration Risk Score for each provider: the weighted sum of (workload count / total workloads × 0.4) + (critical workload count / total critical workloads × 0.6), expressed as a percentage. A score above sixty percent should be flagged as High concentration.
5. Return a dictionary containing the per-provider breakdown and any concentration flags.

Starter code:

def concentration_risk_report(self) -> dict:
    """
    Generate a concentration risk report showing cloud provider
    concentration across the total workload estate and critical workloads.

    Returns a dict with per-provider metrics and concentration flags.
    """
    # Your implementation here
    pass

Expected output structure (for the Verdant Bank demonstration from this chapter, where 2 of 3 workloads and 1 of 1 critical workload are on AWS):

{
    "firm": "Verdant Bank UK",
    "total_workloads": 3,
    "total_critical_workloads": 1,
    "provider_breakdown": {
        "Amazon Web Services": {
            "total_workloads": 2,
            "total_workload_pct": 66.7,
            "critical_workloads": 1,
            "critical_workload_pct": 100.0,
            "concentration_risk_score": 86.7,
            "concentration_flag": "HIGH — formal concentration risk assessment required",
        },
        "Microsoft Azure": {
            "total_workloads": 1,
            "total_workload_pct": 33.3,
            "critical_workloads": 0,
            "critical_workload_pct": 0.0,
            "concentration_risk_score": 13.3,
            "concentration_flag": None,
        },
    },
    "summary": "1 provider(s) flagged for formal concentration risk assessment.",
}

Extension challenge: Modify the method to also identify cascade risk — cases where multiple critical workloads share the same provider AND one of those workloads is a dependency of another (e.g., CIAM is a dependency of AML monitoring). This would require adding a dependencies: list[str] field to the CloudWorkload dataclass and adding logic to traverse the dependency graph.

Exercise 5: Exit Strategy Design for a Critical SaaS Compliance System

Objective: Draft a structured exit strategy for a critical SaaS compliance system, applying the regulatory requirements for exit planning discussed in this chapter.

Scenario: Verdant Bank UK uses a cloud-hosted SaaS sanctions screening platform from a vendor called ClearSanctions Ltd. ClearSanctions operates on AWS eu-west-1 (Ireland). The platform:

• Screens approximately 180,000 transactions and customer events per day in real time
• Holds twenty-four months of screening history (results, match rationales, analyst override records)
• Is integrated with five of Verdant's internal systems via API
• Has been in production for three years
• Is covered by a three-year vendor contract expiring in eighteen months

Verdant's operational resilience framework classifies sanctions screening as supporting an Important Business Service (IBS). The impact tolerance is: "Sanctions screening unavailable for no more than two hours before unacceptable customer harm (inability to process cross-border payments)."

Task A: Draft the exit strategy for the ClearSanctions arrangement. Your exit strategy should be structured as a series of bullet-pointed components covering: (1) trigger events — what circumstances would activate the exit strategy; (2) data extraction — how Verdant would extract its screening history data from ClearSanctions, in what format, using what tooling, and in what estimated timeframe; (3) alternative providers — identification of at least two alternative sanctions screening providers and a summary assessment of their capability; (4) transition service agreement requirements — what Verdant needs from ClearSanctions during a transition period (parallel running, knowledge transfer, API support); (5) integration remediation — how the five internal API integrations would be redirected to a new provider; and (6) RTO validation — how the exit strategy meets or is limited by Verdant's two-hour impact tolerance.

Task B: The exit strategy must be tested. Describe a testing exercise that Verdant could conduct without actually migrating to a new provider. What would be tested, how would success be measured, and what documentation would be produced?

Task C: Verdant's CTO notes that ClearSanctions uses a proprietary screening algorithm and a proprietary data format for storing match rationales. The data export function outputs screening history in a JSON format, but the match rationale fields use internal codes (e.g., "MR-47-FNAME-FUZZY") that are meaningful only in the context of ClearSanctions' platform. Assess the vendor lock-in risk this creates for exit planning. What contractual provisions should Verdant seek to negotiate before the contract renewal in eighteen months to mitigate this risk?