Chapter 17 Exercises: Data Privacy, GDPR, and Cross-Border Data Compliance

Exercise 17.1 — Lawful Basis Identification

Learning objective: Apply the six Article 6 GDPR lawful bases to real financial services processing scenarios.

Instructions: For each processing scenario below, identify the most appropriate lawful basis and provide a brief justification (two to four sentences). Where more than one basis might technically apply, identify which is primary and explain why.

For reference, the six lawful bases are: (1) Consent; (2) Contract; (3) Legal obligation; (4) Vital interests; (5) Public task; (6) Legitimate interests.

Scenario A: Verdant Bank collects a new current account customer's name, address, date of birth, and National Insurance number during the onboarding process in order to verify the customer's identity as required under the UK Money Laundering Regulations 2017.

Scenario B: Verdant Bank sends monthly e-statements to customers summarising their account activity and balance, as provided for in the terms and conditions of the current account agreement.

Scenario C: Verdant Bank runs a transaction monitoring system that analyses customer payment behaviour in real time, flagging patterns consistent with potential fraud. The system creates risk scores for each customer that influence whether transactions are approved or declined.

Scenario D: Verdant Bank's marketing team uses its existing customers' product holdings data to identify customers who hold only a current account and sends them personalised messages about Verdant's savings products. The bank has assessed that this falls within customers' reasonable expectations given their existing relationship.

Scenario E: Verdant Bank shares transaction data with the CIFAS National Fraud Database where it has identified that an application was made using stolen identity documents. The data sharing occurs under the CIFAS Rules, which constitute an industry fraud prevention scheme.

Scenario F: Verdant Bank processes a customer's health information (disclosed voluntarily) to assess whether the customer should be categorised as a vulnerable customer under FCA Consumer Duty guidance, and uses this information to ensure that products offered and communications made are appropriate.

Discussion notes:

Consider the following when completing this exercise:

For Scenario A — Does mandatory AML CDD constitute a legal obligation? What law creates the obligation? Does it matter that the bank would have conducted identity verification anyway under its own policies?

For Scenario C — Could this be legitimate interests rather than contract? What does "necessary for contract performance" mean in the context of fraud prevention? Is fraud prevention truly necessary for the banking relationship?

For Scenario F — What additional requirements apply beyond the Article 6 basis? What is the significance of the customer's health data being special category data? What Article 9(2) condition might apply?

Exercise 17.2 — Data Subject Rights Conflict: Erasure vs. AML Retention

Learning objective: Navigate the conflict between the GDPR right to erasure and statutory data retention obligations.

Background:

Rafael Torres, now a RegTech consultant, is advising a mid-tier UK bank on its data subject rights response procedures. The bank has received the following written request from a former customer, received on 14 March 2026:

"I closed my current account with your bank on 20 February 2026. I am writing to request that you delete all personal data you hold about me. I understand I have a right to erasure under Article 17 of UK GDPR. Please confirm within 30 days that all my data has been erased."

The customer's account closure was processed on 20 February 2026. During the account relationship, the bank held: - Account agreement and personal details (name, DOB, address, NI number) - Transaction history (three years of transactions) - Two suspicious transaction reports filed with the National Crime Agency (neither has resulted in charges) - Marketing consent records (customer had opted in to email marketing) - Customer service call recordings (30 calls over three years) - Credit reference bureau reports obtained at account opening - Biometric identity verification data from onboarding

Questions:

(a) What is the deadline by which the bank must respond to this erasure request? Calculate the date.

(b) Draft a structured analysis of each data category listed above, identifying: - Whether the erasure right applies to that data category - The relevant legal basis for retention (where applicable), citing specific provisions - The recommended action for each category

(c) What should the bank's written response to the customer say? Draft a brief response (300–400 words) that: - Acknowledges the request - Explains what has been erased - Explains what is being retained and why, citing the specific legal authority - Does not reveal the existence of the SAR filings (citing the appropriate tipping-off prohibition) - Is written in plain English appropriate for a retail customer

(d) If the bank's AML SAR records were filed under the Proceeds of Crime Act 2002, what provision prevents the bank from disclosing to the customer that these records exist? What is the maximum sentence for a tipping-off offence?

Suggested framework for part (b):

Exercise 17.3 — DPIA Trigger Analysis

Learning objective: Apply the Article 35 DPIA criteria and ICO mandatory DPIA triggers to new processing activities.

Background:

Priya Nair is reviewing five proposed processing activities at Cornerstone Financial Group as part of a privacy compliance advisory engagement. For each activity, she must assess whether a DPIA is required before processing commences.

Instructions: For each activity below, determine: (i) Whether a DPIA is required (yes/no/likely required) (ii) The specific legal basis for the DPIA requirement (Article 35 provision and/or ICO mandatory trigger) (iii) If no DPIA is required, whether one is nonetheless advisable as a matter of good practice

Activity 1: Cornerstone is implementing a behavioural analytics platform that analyses customers' app usage patterns, browsing history within the app, and time-of-day transaction patterns to create individual "financial wellness scores." These scores will be used by customer-facing staff to initiate proactive outreach about product offerings. No automated decision-making based solely on the score will occur — human review always intervenes.

Activity 2: Cornerstone's HR department wants to introduce a new employee absence monitoring system that tracks the number and frequency of sick days, cross-references these against teams and managers, and produces alerts when individual absence rates exceed thresholds. The system will flag HR business partners when patterns suggest performance management conversations may be needed.

Activity 3: Cornerstone is migrating its existing customer data from an on-premises data centre to a cloud provider (hosted in Ireland) for operational resilience purposes. The data will be processed in the same way as currently; only the infrastructure changes. No new uses of the data are being introduced.

Activity 4: Cornerstone's credit risk team wants to retrain its mortgage affordability model using a dataset that combines existing customer transaction data with externally purchased credit bureau data, postcode-level deprivation indices, and social media data (specifically, publicly available LinkedIn employment and education data). The updated model will make automated recommendations on mortgage offers, including acceptance, rejection, and rate bands.

Activity 5: Cornerstone is implementing a digital onboarding process for business customers that includes: company officer biometric verification (facial recognition against passport images); enhanced due diligence data collection for high-risk jurisdictions; and automated PEP (Politically Exposed Person) screening against Refinitiv World-Check. An automated "risk rating" is assigned, with high-risk customers referred to a human reviewer. Approximately 5,000 new business customers will be processed annually.

Discussion points to address:

• For Activity 1: Does the absence of fully automated decision-making eliminate the DPIA requirement? What is the ICO's position on profiling with human review?
• For Activity 3: Under what circumstances does a cloud migration require a DPIA? Is there a change in risk profile?
• For Activity 4: What is the significance of including social media data? Is LinkedIn data truly "public" in a GDPR sense when repurposed for credit scoring?
• For Activity 5: Which specific categories within the activity trigger DPIA requirements? Does the scale (5,000 per year) matter?

Exercise 17.4 — Coding Exercise: DataSubjectRequestTracker

Learning objective: Implement a complete data subject rights management system in Python with GDPR-compliant deadline tracking.

Background:

Verdant Bank's compliance team currently manages data subject rights requests in a spreadsheet. Maya Osei has asked you to build a DataSubjectRequestTracker that automates tracking, deadline calculation, escalation flagging, and reporting.

Task A: Core Implementation

Extend the DataSubjectRequestTracker class from the chapter (or build your own implementation) to support:

class DataSubjectRequestTracker:
    """
    Manages GDPR data subject rights requests across the organisation.

    GDPR requirements:
    - Art. 12(3): Response within 1 month; extendable to 3 months for
      complex/numerous requests (data subject notified within first month)
    - Art. 12(4): Requests manifestly unfounded or excessive may be refused
      or charged; controller must demonstrate this
    - Art. 12(5): First copy of data free; reasonable fee for further copies
    """

    def receive_request(self, request_type, subject_id, received_date=None):
        """Register and return a new DataSubjectRequest."""
        ...

    def assign_request(self, request_id, assignee):
        """Assign a request to a named individual for handling."""
        ...

    def extend_request(self, request_id, reason):
        """Apply Art. 12(3) extension; notify data subject."""
        ...

    def complete_request(self, request_id, notes=None):
        """Mark a request as completed."""
        ...

    def refuse_request(self, request_id, reason, partial=False):
        """Refuse or partially refuse a request with documented reason."""
        ...

    def get_overdue_requests(self):
        """Return all requests past their effective deadline."""
        ...

    def get_requests_due_within(self, days):
        """Return open requests with deadlines within N days."""
        ...

    def compliance_report(self):
        """Generate a compliance status report."""
        ...

    def monthly_volume_report(self, year, month):
        """
        Report request volumes and completion rates for a given month.
        Returns: dict with total, by_type, completed, on_time, overdue.
        """
        ...

    def export_to_csv(self, filepath):
        """Export all requests to CSV for audit purposes."""
        ...

Task B: Test Your Implementation

Write a test script that:

1. Creates a tracker for "Verdant Bank Ltd"
2. Adds at least 10 requests of different types (access, erasure, portability, objection), with received dates spread over the past 6 weeks
3. Assigns requests to team members
4. Extends two requests with documented reasons
5. Completes four requests
6. Refuses one request with a documented reason (e.g., AML exemption)
7. Calls get_overdue_requests() and prints results
8. Calls get_requests_due_within(7) and prints results
9. Prints the full compliance report
10. Exports to CSV

Task C: AML Complication

Modify your implementation to add a flag aml_tipping_off_risk: bool on DataSubjectRequest. When this flag is True: - The access response must not reference AML SAR-related data - The response notes must include the specific DPA 2018 Schedule 2 paragraph 14 exemption text - An audit log entry must be automatically generated

Write a function handle_aml_dsar(tracker, subject_id) that creates a request with this flag set, applies the appropriate exemption, generates the compliance note, and returns the audit log.

Task D: Reporting Extension

Add a generate_icо_register_export() method that produces a dictionary containing all information required under GDPR Article 33(5) — the internal breach register — formatted as if each DSAR refusal were a potential compliance risk event requiring documentation. (This is a realistic use case: regulators may ask to see refusal records as evidence of proportionate rights restriction.)

Submission checklist: - [ ] Core tracker class implemented with all methods - [ ] Test script creates 10+ requests and exercises all tracker methods - [ ] AML flag and handle_aml_dsar() function implemented - [ ] CSV export works and produces readable output - [ ] Code follows PEP 8; classes and methods have docstrings - [ ] No real personal data is hardcoded (use pseudonymised identifiers)

Exercise 17.5 — Cross-Border Transfer Scenario Analysis

Learning objective: Apply the cross-border transfer framework to a realistic multi-layered scenario.

Background:

Rafael Torres is advising Verdant Bank on its cloud infrastructure strategy. Verdant has selected a US-based cloud provider ("CloudCore Inc.") to host its core banking platform. CloudCore operates data centres globally, including one in Frankfurt, Germany (EU) and one in Northern Virginia, US. Verdant's customer base is entirely UK-based; Verdant is a UK legal entity regulated by the FCA and PRA.

The proposed infrastructure design involves: - Customer-facing application layer: hosted in CloudCore's Frankfurt region (EU) - Core banking database: hosted in CloudCore's Northern Virginia region (US) - Disaster recovery: backup database in CloudCore's Northern Virginia region (US) - Fraud analytics processing: CloudCore's AI/ML service (logistically operated from CloudCore's US headquarters, though computation occurs in Frankfurt) - Regulatory reporting module: hosted in the UK via CloudCore's London region

Questions:

(a) Classify each of the five infrastructure components above according to whether it involves a UK-to-EU transfer, UK-to-US transfer, or UK-only processing. Explain your reasoning for any ambiguous cases.

(b) For each component that involves a UK-to-US transfer: (i) What transfer mechanisms are available under UK data protection law (UK GDPR)? (ii) What is the recommended mechanism given the current legal landscape (as of 2025)? (iii) What additional assessment must accompany any SCC/IDTA-based transfer following the reasoning in Schrems II?

(c) The EU-US Data Privacy Framework (DPF) was adopted for EU-to-US transfers. Does it help with UK-to-US transfers? If not, what is the UK equivalent or alternative?

(d) Verdant's data processing agreement with CloudCore characterises CloudCore as a "processor." Is this characterisation correct for all five infrastructure components? For the fraud analytics processing component, could CloudCore be characterised differently? What factors would determine this?

(e) CloudCore's terms of service contain a clause stating: "CloudCore may access customer data where required by applicable law, including in response to lawful government requests." Rafael advises Maya that this clause requires a Transfer Impact Assessment before signing. Draft a one-page TIA framework for the CloudCore Northern Virginia data transfers covering: (i) the assessment of US surveillance law; (ii) the contractual, technical, and organisational safeguards in place; (iii) the conclusion as to whether residual risk is acceptable.

(f) Maya asks: "What if we just put all the data in Frankfurt?" Analyse the privacy advantages and limitations of this approach. Does keeping EU-resident data within the EU/EEA eliminate all cross-border transfer concerns for Verdant as a UK entity?

Exercise 17.6 — Research Exercise: EU-US Data Privacy Framework

Learning objective: Evaluate the current legal status and practical durability of the EU-US DPF.

Background:

The EU-US Data Privacy Framework (DPF) was adopted by the European Commission on 10 July 2023. It followed the invalidation of its predecessor, the EU-US Privacy Shield, by the CJEU in the Schrems II judgment of July 2020. Privacy advocates, led by Max Schrems and the organisation noyb.eu, announced immediate intent to challenge the DPF in the courts.

Instructions:

Research the following questions and prepare a structured memo (approximately 600–800 words) suitable for presentation to a compliance committee. Your memo should address:

(a) Current Status: As of your research date, what is the legal status of the EU-US Data Privacy Framework? Is it in force? Is it subject to pending legal challenge? Has the CJEU issued any preliminary rulings or opinions?

(b) Key Safeguards: What were the specific mechanisms introduced by Executive Order 14086 that the European Commission found sufficient to address the Schrems II concerns? In particular, describe: - The necessity and proportionality requirements for US signals intelligence - The Data Protection Review Court (DPRC) and its powers - Why these mechanisms were considered more robust than those in Privacy Shield

(c) Critique: What are the principal legal arguments advanced by critics of the DPF, including noyb.eu? Specifically: - Does the DPRC satisfy the CJEU's requirement for "judicial redress" by an independent body? - Does US FISA Section 702 still permit bulk access to transferred data? - Is Executive Order 14086 sufficiently durable, given that executive orders can be revoked by subsequent administrations?

(d) Practical Implications for Financial Services Firms: If the DPF is challenged successfully in the CJEU (as Safe Harbor and Privacy Shield were): - What would be the immediate practical consequence for EU-US data transfers? - What contingency arrangements should financial institutions have in place now? - Given that two prior frameworks have been invalidated, what does this pattern suggest about the structural durability of EU-US adequacy frameworks?

(e) Recommendation: Based on your research, should a financial institution currently relying on the DPF for EU-US data transfers also maintain parallel SCC/TIA arrangements as a hedge? Justify your recommendation.

Research resources to consult:

• European Commission adequacy decisions page (ec.europa.eu)
• noyb.eu announcements and legal submissions (noyb.eu)
• EDPB opinion on the EU-US DPF
• CJEU case tracker for any pending proceedings
• FT, Reuters, and specialist privacy law blogs (IAPP, Bird & Bird Data Protection, Linklaters Data Protected)

Note: This is a live legal area. The status of the DPF may have changed since the publication of this textbook. The exercise is designed to develop the skill of monitoring an evolving regulatory environment — a core competency for RegTech practitioners. Your memo should clearly state the date of your research and caveat any conclusions accordingly.

Guidance Notes for Instructors

Exercise 17.1 (Lawful Basis): A and B are relatively straightforward (legal obligation and contract respectively). C is a legitimate discussion point — many firms use contract as the basis for fraud prevention, arguing it is necessary for the banking relationship, while others use legitimate interests. D and E are legitimate interests cases requiring the three-part test. F is the most complex: health data is special category data requiring both an Article 6 basis (legal obligation, given FCA Consumer Duty requirements) and an Article 9(2) condition (likely Article 9(2)(g) — substantial public interest as specified by national law, or Article 9(2)(h) for health/social care purposes). Encourage students to articulate the three-part test for legitimate interests where applicable.

Exercise 17.2 (Erasure vs. AML): Key points: (1) the MLR 2017 five-year retention obligation covers CDD and transaction records, not marketing data or call recordings beyond what is required; (2) call recordings have a separate FCA retention obligation under COBS 11.8 (five years for relevant telephone conversations); (3) credit reference bureau reports need careful analysis — the bank may not be legally required to retain them but may have a legitimate interest in doing so for dispute resolution; (4) the draft response requires sensitivity around the SAR existence — this is a genuine practical skill.

Exercise 17.3 (DPIA Triggers): Activity 1 — DPIA likely required despite human review; ICO mandatory DPIA list includes profiling and automated scoring even with human oversight. Activity 2 — DPIA required for employee monitoring (systematic processing). Activity 3 — likely no new DPIA required if genuinely like-for-like migration; a data transfer mechanism review is needed. Activity 4 — definite DPIA required; social media data repurposing raises additional purpose limitation questions. Activity 5 — multiple triggers: biometric data, automated PEP screening, special category data at scale.

Exercise 17.4 (Coding): Assess on: completeness of the implementation; quality of the AML flag handling; accuracy of deadline calculations; robustness of the CSV export; code quality. The AML complication in Task C directly mirrors the D.K. scenario in the case study.

Exercise 17.5 (Cross-Border Transfers): The Frankfurt vs. Virginia distinction is central. Key insight: data in Frankfurt is "safe" from UK GDPR cross-border transfer obligations, but the CloudCore access clause means that US parent company access to Frankfurt-hosted data could itself constitute a UK-to-US transfer (the question of "remote access" as a transfer). The EDPB guidance on "what constitutes a transfer" is relevant here.

Exercise 17.6 (Research): This is deliberately open-ended as the DPF's legal status is genuinely in flux. The key pedagogical goal is developing the skill of monitoring a live regulatory situation and translating uncertainty into actionable compliance recommendations.