Can someone be recognised? How data providers can assess identification risk

Before you share data about individuals, work out who will receive it and what they could match it against. Always pick your privacy tools after that, not before.

“Record-level” data means data that is one row per person or household, as opposed to a table of totals. It’s the riskiest kind to share, because each row describes someone real, and just blocking out the name isn’t enough.

If a row says “born 1971, postcode district SW9, works as a lighthouse keeper”, there is most likely only one person it can be, and they are easily singled out even without their name.

So, start with two questions. Who is receiving this data, and what job do they need it for?

List the fields in the extract, and ask what the recipient could combine them with to recognise someone. The answers tell you which protections you need, and let you test whether the data still does the job after de-identification.

The UK regulator, the ICO, describes identifiability as a sliding scale, not a yes-or-no. Where a dataset sits on it depends on what other information is out there and what methods someone is reasonably likely to use. The ICO’s guidance is being reviewed after the Data (Use and Access) Act, so whenever you make a release decision, record which version of the guidance you relied on.

First, clarify who receives the extract

Who receives the data changes how much risk you take on when you release it.

If you publish it for anyone to download, you lose control over who has it and what they can do with it. If you give it to a defined group, the ICO counts two extra things in your risk check: the access rules you put around it, and what information that group already has. It also wants you to think about people who shouldn’t have access at all, such as a hacker or an employee who goes rogue.

So ask the recipient directly. Which datasets do you already hold, and which could you reasonably get? Include data held elsewhere in their organisation, not just by the team asking.

One legal wrinkle. The ICO’s test of “is this identifiable in another’s hands?” only applies when the recipient is a separate controller, meaning an organisation that decides for itself how to use the data. If the recipient is a joint controller (deciding jointly with you) or a processor (only acting on your instructions), data that counts as personal for you counts as personal for them too.

Decide early, at the very start of your processing, how the data will be shared. NIST, the US standards body, describes three routes in its guidance:

• Publish a de-identified file, or a synthetic one.
• Offer a query interface, where people send questions and get answers back with privacy controls applied, but never see the rows.
• Let people work on the data inside a protected environment they can’t take it out of.

Pick the route that suits what the recipient needs before you promise anyone a downloadable file.

Look beyond names

Direct identifiers, like names and account numbers, deserve attention first. But everything left in the row can still be pieced together to form a picture and single someone out. The ICO separates three ways this can go wrong:

1. Singling out: picking out the rows that belong to one person, without even knowing their name.
2. Linkability: joining records about the same person, either within one dataset or across different systems.
3. Inference: using those links to learn something new about someone, such as their health or politics.

As mentioned in our last article, the 2006 Netflix Prize shows how real this is. No names were needed to identify users and to glean their apparent political leanings.

For your own extract, go through each worrying field and write down a specific route someone could use: which outside source, and which details overlap. “Possible linkage” is too vague, because the reviewer wouldn’t know what to test. Something like “job title plus postcode district could be matched against the client’s customer database” gives them a job to do.

Follow one record through the release

The easiest way to spot risks is to pick one row and imagine what the recipient could do with it.

Continuing the same example, say a consumer panel company (one that surveys the same households regularly about what they buy) wants to share survey records with a client’s analytics team. Here’s what it looks at:

• Spending trends by broad region show what the client needs.
• A customer database with postcodes and purchase histories shows what the client already has.
• A local area with only a few households is a weak spot.

The proposed extract has names and panel IDs removed. What’s left is year of birth, postcode district, job title, weekly spending, and a free-text comments box where people describe their purchases.

Now trace the risk by looking at combinations, not just single fields:

1. A rare job title plus a postcode district could narrow things down to one household.
2. The client could then match that household’s weekly spending against purchase records in its own database.
3. A comment like “bought a pram for our twins” could confirm that household.

Each of these steps can be tested. The panel company can count how many rows share the same job title and postcode district. It can also ask the client whether the matching information really exists in its systems.

Change the fields the analysis doesn’t need

The client only asked for spending by broad region, so much of the row-level detail can go. Keep in mind what the data will be used for – this dictates how much needs to be de-identified, and what level of context needs to be preserved.

Always check you haven’t broken the data. Run the analysis on the changed extract and compare the values with the original, kept under tight control. If a comparison stops being reliable, say so in the release record, and name the use that’s affected.

Test an identification attempt – try to break it yourself

The ICO’s “motivated intruder” test asks you to imagine a reasonably competent person who wants to identify someone, using the resources and investigation methods reasonably open to them. You can run this test in-house, and you should, or bring in an outside organisation. An outsider might know of data sources or weak spots you have missed.

Be careful with software that promises to do this for you. NIST lists re-identification studies (deliberately trying to identify people in the data) as one way to measure risk, alongside de-identification standards with measurable performance levels. It also warns that tools which only mask personal information may not actually de-identify it.

Name an owner for the decision, and what would trigger a review

Risk always remains, so one named person has to own it. Link the release record to the exact extract that was tested, and to the assumptions made about the recipient. That way, someone reviewing it later can see what would make the decision out of date. Be diligent about the records you keep.

The ICO says you should be able to justify the decision and keep it under review as technology and your processing change.

Two obvious triggers:

• The client gets hold of a new dataset that could be matched against the records.
• The client asks to pass the records on to someone else.

Jargon cheat sheet