Pseudonymized, Re-identified, and a Laptop Extract Request
Velora, a European e-commerce company, is deploying self-service BI for 1,200 users across 14 countries. The customer table holds name, email, full address, date of birth, and order history; access currently flows through a single "analytics" role that can read every column. A privacy impact assessment found that the "pseudonymized" churn dataset - customer ID replaced by a hash, but postcode, birth year, and order month retained - was re-identified for 18 of 20 test customers using public records. A contractor supporting the churn model has asked for a full CSV extract to a laptop because "the VPN is slow"; the model needs six months of order history. Marketing wants to join the dataset to a third-party enrichment vendor. The DPA requires GDPR compliance and breach notification within 72 hours.
1. Evaluate the pseudonymization claim and recommend a de-identification approach, including how you would test it and what threshold you would set.
Read the worked answer
Hashing the customer ID is pseudonymization, not anonymization. The dataset remains personal data under GDPR because re-identification is reasonably likely, and the 18-of-20 result demonstrates it empirically. The hash only removes the direct identifier; the quasi-identifier combination of postcode, birth year, and order month is close to unique in a sparse population - small postcodes with one birth cohort ordering in one month are effectively singletons.
Recommend generalization plus suppression: postcode to outward code or region (and to region only in low-density areas), date of birth to five-year band, order date to month or quarter, and no free-text fields. Then apply a k-anonymity threshold on the quasi-identifier set. For external sharing, k ≥ 11 is a defensible starting point; for internal modelling inside a controlled environment, k ≥ 5 with access controls and no export. Add l-diversity or t-closeness checks on sensitive attributes if any are retained, and suppress or aggregate records in small cells rather than perturbing them individually.
Test it adversarially: rerun the same public-records linkage attack against the generalized dataset and report the re-identification rate, not just the theory. Document residual risk and the DPO's acceptance.
For the churn model specifically, question whether the quasi-identifiers are needed at all. If the model only needs behavioural features, aggregate to customer-month with stable pseudonymous keys and drop demographics entirely - that removes the risk instead of tuning it.
2. How would you respond to the contractor's request for a full CSV extract to a laptop? Give the decision and the controls.
Read the worked answer
Decline the laptop CSV. The reason is not policy purism - it is that a file on an endpoint cannot be revoked, cannot be logged, and cannot be scoped after the fact. With a 72-hour breach notification obligation, an uncontrolled copy means you cannot determine who was affected or whether notification is required. "The VPN is slow" is a performance problem with cheaper solutions than an uncontrolled copy.
Offer alternatives in order of preference. First, bring the analysis to the data: a secure VDI or remote notebook session in the warehouse, with the model code committed to a repository and results exported rather than rows. Second, if the contractor needs local tooling, provide a minimized dataset: six months of order lines, pseudonymous stable customer keys, no name, no email, no exact date of birth, no full address, and aggregation to week where the model tolerates it. Third, if a file is genuinely unavoidable, an encrypted managed device, DPO approval, a defined retention period, an egress DLP rule, and a signed deletion attestation.
All routes need a data processing agreement with the contractor's employer, named individual access rather than shared credentials, MFA, time-boxed access that expires automatically, and query logging. Also fix the root cause: profile the VPN and the notebook environment, because slow access drives shadow exports across the whole analytics population, not just this contractor.
3. The single analytics role gives 1,200 users every column. Propose an access model and the metrics you would use to tell whether it is working.
Read the worked answer
Start from data classification, not from org chart. Tag columns as direct identifiers (name, email, address, date of birth), quasi-identifiers, and non-sensitive. Then combine a small number of role archetypes with attribute-based policy: four to six roles (regional analyst, finance analyst, marketing analyst, data scientist, admin) plus policy tags that mask or block identifier columns unless a role carries an unmasked grant. Row-level security by country handles the 14-country split; dynamic masking on email and phone covers most marketing needs without exposing raw values.
Add just-in-time elevation for the exceptions: a time-bound, approved grant with a reason code, logged and reviewed. Avoid proliferating bespoke roles per team - that is how a 1,200-user estate ends up with 300 roles nobody can audit. Policy-based masking keeps the role count manageable.
Marketing's enrichment join should go through a governed matching process with the vendor under a DPA, using hashed identifiers and returning only derived attributes, rather than exporting customer rows to a third party.
Metrics that show it works: percentage of access requests served by self-service (target above 80%), median time to access grant, number of standing unmasked grants trending down, quarterly recertification completion, and anomalous-access detections such as bulk exports. The bulk-export detector is what would have caught the contractor's CSV before it left the building - and it is a better investment than another policy document.