The Sandbox Copy, the Hash, and the Erasure Request
A retail insurer's marketing analytics team copied the production customer table into an unsanctioned cloud sandbox to debug a churn model. The table holds name, email, mobile number, full postal address, date of birth, policy number and a SHA-256 hash of the national ID. The sandbox has no column encryption, 14 engineers hold read access, there is no expiry policy, and the copy is refreshed weekly by a script the team wrote.
The churn model treats the literal placeholder [email protected], present on 8 percent of rows, as a normal feature value, and that placeholder is concentrated in one acquisition channel. A customer has now submitted an erasure request that has been fulfilled in the CRM. The Data Protection Officer has asked for a remediation plan and is specifically concerned that 'we hashed the ID, so it is anonymised' is being offered as the justification.
1. Assess the anonymisation argument and set a remediation order, justifying the sequence.
Read the worked answer
The hash is pseudonymisation, not anonymisation, on at least three grounds. The input space of a national ID is small and highly structured, so a determined party can hash candidate values and match them; a hash is not a one-way secret against an enumerable domain. It is deterministic and unsalted, so it is a stable join key that links this dataset to any other dataset holding the same hash. And it sits in a row alongside name, address, date of birth and policy number, which are themselves direct and quasi-identifiers, so the row is identifying irrespective of the hash. Under GDPR-style regimes this remains personal data.
Remediation order should follow risk and reversibility, not tidiness. First, contain: revoke the 14 broad grants, disable the weekly refresh script, and either delete the sandbox copy or replace it immediately with a masked extract, capturing evidence of what was done. Second, remove the incentive to recreate it: stand up a sanctioned sandbox with approved masking and a documented request process, because a control that exists only on paper while a five-minute workaround remains will fail again. Third, remediate the platform: classification tags on sensitive columns, masking or tokenisation with a vault for direct identifiers, column-level access, row filters by region, and a TTL that actually expires data. Fourth, govern: an approval workflow for extracts, DLP alerting on bulk copies, and training for the team.
Note that deletion from an unmanaged environment is hard to prove; the evidence trail matters as much as the act.
2. How should the erasure request be handled across environments and derivatives, and what must change so it does not recur?
Read the worked answer
Deleting from the CRM fulfils the request only for the system of record. The individual's data almost certainly also exists in the warehouse, in the weekly sandbox refresh, in extracts on laptops, in model training sets, and possibly inside stored model artefacts and cached dashboards.
The mechanism is lineage. Map the path from CRM to warehouse tables, to derived views and feature tables, to extracts and to model training inputs, then act on each node: delete or irreversibly anonymise at every node where the individual is still identifiable, and record what was done and when as evidence. For backups, do not promise something impossible: state a documented policy, such as rolling expiry with suppression on restore, and follow it.
Models need a judgement call. If the record influenced a trained model, retraining may be required, or you must be able to argue the individual's data is no longer embodied in the model in an identifiable form. Record the decision and its basis rather than leaving it implicit.
Root cause fix: maintain a persistent suppression list that is applied at ingestion, so a future weekly refresh or backfill cannot resurrect the record. Replace the team's script with a pipeline that consumes the suppression list by design, and add a reconciliation check that counts suppressed identifiers appearing in any downstream table. Without that, the erasure is a one-off cleanup and the next refresh undoes it.
3. What is the data quality issue with [email protected], and how should it be handled without distorting the model?
Read the worked answer
It is a sentinel value masquerading as real data: a placeholder standing in for 'missing' (or possibly for 'customer refused to give an address') that has been stored as a valid string. At 8 percent of rows it is far above any plausible genuine rate, and because it concentrates in one acquisition channel the model can learn a spurious association between the placeholder and churn that is really an artefact of how that channel captures data.
Diagnose before fixing: profile the placeholder by source system, acquisition channel and load date to establish whether it means one thing or several. If sources differ, treat them differently.
Fix at ingestion: map known placeholders to NULL, retain the raw value in a lineage column, add an explicit validity rule and a monitored quality metric (percent of sentinel values by source, tracked over time). Then handle missingness deliberately: either impute, or add an explicit missing-indicator feature. The indicator is only legitimate if missingness carries real signal, such as customers who declined to provide an address; if it merely reflects a broken capture form, the indicator encodes a process defect and should not be a model feature at all.
Do not silently drop the 8 percent. If the placeholder correlates with the label, dropping biases the training set and the churn rate the model reports. Finally, push a validation rule to the point of capture so the placeholder stops being created, and add a pipeline expectation test so the rate is visible when it changes.