The 'Anonymised' Ride Dataset: When Removing Names Is Not De-identification
Northwind Analytics (320 staff, Berlin and Lisbon) plans to release a dataset of 1.8 million ride-hailing trips to a university research partner, described internally as 'fully anonymised'. The extract keeps pickup and drop-off coordinates rounded to 50 metres, timestamps to the minute, fare, vehicle class, and a persistent rider identifier that is stable across all trips. Legal reviewed the release and concluded that because names, emails and phone numbers were removed, the data falls outside data-protection scope and no further analysis is needed. Two weeks before release, a master's student shows that linking four consecutive trips to public social-media posts re-identifies 12 of 5,000 sampled riders, including a journalist who took trips to a clinic. The head of data insists the coordinate rounding makes re-identification 'theoretical and not our problem'. Separately, the security team notes the same dataset sits in an analytics bucket readable by 40 engineers, half of them contractors. The DPO asks for a written recommendation before the release date, which cannot move because the partnership contract is signed.
1. Evaluate whether the dataset can be treated as anonymous. Show the reasoning a reviewer should follow, and state what obligation follows from your conclusion.
Read the worked answer
The conclusion that the data is anonymous is unsupported, and the reasoning behind it tests the wrong property. Anonymity is not a property of which fields were deleted; it is a property of the data in its context of release, assessed against re-identification by singling out, linking and inference using means reasonably likely to be used. Removing direct identifiers while retaining a persistent rider key and high-resolution spatio-temporal attributes produces pseudonymised data at best: the key allows records to be linked to each other, and trip geometry plus minute-level timing is highly distinctive for repeat users.
The student's attack is not exotic - public social media plus four trips is a low-effort linkage, and the journalist's clinic trips show the harm is not hypothetical embarrassment but potentially sensitive-attribute inference. 'Theoretical' is the wrong threshold; the threshold is reasonably likely.
Obligations that follow:
- Treat the dataset as personal data. That means a documented lawful basis, transparency to riders, purpose limitation for the research use, and a data protection impact assessment before release.
- Apply data minimisation rather than field deletion: drop the persistent rider key, generalise time to hour or day bands, coarsen or perturb coordinates, and aggregate where the research question permits.
- Do not rely on a one-off test. Set a measurable re-identification criterion (for example a minimum group size per quasi-identifier combination), test against it, and record the residual risk and who accepted it.
- Prefer a controlled research environment over an open transfer, with contractual use restrictions and no re-publication rights.
Accountability sits with Northwind, not the researcher.
2. The bucket exposure and the re-identification finding are both described as 'privacy problems'. Distinguish them, and explain why treating them as one issue leads to the wrong controls and the wrong owner.
Read the worked answer
They are different harms arising from different causes, and conflating them produces a single inadequate response.
The bucket is a confidentiality failure. Authorised processing has been undermined by poor access control: 40 readers, many contractors, no evident need-to-know. The cause is entitlement and identity management, so the controls are access rights, privileged access, authentication, encryption and logging - a security-owned problem with an engineering fix and a short timescale.
The re-identification finding is a privacy-design failure. The processing itself is lawful in intent but disproportionate in method: the data is more identifying than the research purpose requires. The cause is a design decision about what to collect and release, so the controls are data minimisation, de-identification technique, purpose specification and impact assessment - a DPO and product-owned problem, fixed before release, not after.
Why the distinction matters:
- Fixing the bucket leaves the release just as re-identifying; the student's attack needs no bucket access at all, only the published file.
- Fixing the dataset leaves 40 unnecessary readers with standing access to sensitive data.
- The risks compound: a bucket compromise converts a privacy risk into a reportable personal-data breach, so the two must be assessed together even though they are remediated separately.
Practical test for the candidate: ask what would have to change for each risk to disappear. If the answer is 'an access decision', it is a security control; if it is 'a data design decision', it is a privacy control.
3. Recommend a decision and the minimum set of safeguards you would require before the release proceeds. Justify what you would and would not accept.
Read the worked answer
Decision: do not release the current extract. Release a re-engineered extract into a controlled environment, with a documented residual-risk acceptance signed by a named accountable owner. This is proportionate: the research value is real, the contract is signed, and a defensible path exists that does not depend on the student being wrong.
Minimum safeguards, in order of importance:
- Remove the persistent rider identifier and replace it with a per-extract random key that cannot be joined to operational systems. Without this, every other measure is weaker.
- Reduce attribute precision to the minimum the research question needs: day-level or hour-band timestamps, and coarser geography with sensitive locations (clinics, places of worship, shelters) generalised or suppressed.
- Set and test a stated re-identification criterion before release, document the test method and result, and repeat it if the extract changes. Residual risk must be stated in the DPIA, not assumed away.
- Controlled access - a secure research environment or a transfer with contractual no-re-identification, no-linkage and no-publication terms, plus an audit right.
- Reduce bucket entitlements to a named, reviewed list before any extract is generated, with contractor access time-bound and logged.
What I would not accept: an assurance that rounding 'makes it theoretical'; a blanket legal sign-off based on field removal; or a release approved without a named risk owner. I would also refuse to treat the researcher's contract as transferring accountability - Northwind remains the controller and must be able to show why the residual risk was acceptable.