Erasure Request, Legal Hold, and an Unsanctioned Ad Feed
A European specialty retailer keeps a 4.2 million row customer_profile table in its EU warehouse and replicates it nightly to a US analytics environment for churn scoring. The 2021 consent notice covered 'marketing analytics'; the churn scores now flow to a third-party ad platform keyed on hashed email addresses. A customer has submitted an erasure request. Legal has separately placed a hold on 18,000 records tied to an open fraud investigation, and the warehouse's immutable backups rotate on a 35-day cycle. The processor agreement with the ad platform was never signed, and no data protection impact assessment exists for the scoring model. The data protection officer wants a decision from the governance council this week. Also pending: a data scientist's request to join the profile table with five years of transaction history to build a propensity model for the same marketing team.
1. The council must answer the erasure request while a legal hold and a 35-day immutable backup cycle are in play. What is the defensible sequence of actions, and what must be documented?
Read the worked answer
Verify identity first, then scope the request using lineage rather than assuming the warehouse copy is the only copy. The subject's data will exist in the CRM, the EU warehouse, the US replica, in derived churn scores, and in the ad platform's audience segments.
The legal hold is a recognised exception to erasure, but only to the extent the fraud investigation genuinely needs those records. Apply minimisation: freeze the 18,000 held rows, restrict access to the investigation team, and erase everything else about the requester. The hold is not a licence to retain the whole profile row.
Live systems, replicas and the US analytics copy must be erased; derived artefacts (score, segment membership) must also go, or the hashed identifier must be suppressed at the platform.
Backups: immediate purging of immutable archives is not required where it is technically impossible, but guaranteed suppression is. Maintain a deletion registry keyed on the subject, apply it automatically on every restore, and block restored records from re-entering analytics.
Document the decision, the legal basis for partial retention, and the restore safeguard in the record of processing activities, and reply within the statutory one-month window.
2. What is the correct ruling on sending churn scores and hashed emails to the ad platform?
Read the worked answer
Suspend the feed. Hashing an email is pseudonymisation, not anonymisation: the platform can still single out and re-identify an individual, so the data remains personal data and the transfer needs a lawful basis in its own right.
Three defects compound. First, purpose limitation: the 2021 notice covered marketing analytics, not advertising activation against an external audience. Using the output for ad targeting is a new purpose requiring a fresh basis, typically consent with a clear opt-out. Second, there is no processor agreement, so the roles, instructions, sub-processors and international transfer mechanism are undefined. Third, there is no impact assessment for a large-scale profiling activity.
If the US environment involves California residents, pushing identifiers to an ad platform may also count as a 'sale' or 'share' under CCPA/CPRA, triggering opt-out and global privacy signal obligations.
Remediation path: sign a data processing agreement, complete an impact assessment, update the notice and collect a valid basis, document the transfer mechanism, then resume. Until then the scores stay internal.
3. Before approving the propensity-model join, what is the minimum set of governance artefacts and controls the council should require?
Read the worked answer
A purpose statement and recorded lawful basis for the new model, entered in the record of processing activities. 'Marketing' is too broad; the entry should name the model, its inputs and its intended use.
A fresh impact assessment, because joining five years of transaction history to profile data is large-scale profiling even if the outputs only rank customers for offers.
A data contract and lineage record for the join, covering both sources, the join key quality, and the refresh cadence, so downstream copies can be found when a subject exercises a right.
Consent verification: the join must exclude customers who opted out of profiling or who are subject to an erasure request, and that exclusion must be re-applied on every refresh, not once at build time.
Access controls on the feature table, retention for the derived features and model, and documentation of features, provenance and bias testing.
Finally, an approval record with an owner, an expiry date and a scheduled review. The failure mode here is a silent, permanently renewed permission.