What counts as personal data under GDPR

Article 4(1) of the GDPR defines personal data as any information relating to an identified or identifiable natural person. The key word is identifiable: the data does not have to name anyone, it only has to make one person distinguishable from another, directly or indirectly, by reference to an identifier such as a name, an identification number, location data, an online identifier, or one or more factors specific to that person's physical, physiological, genetic, mental, economic, cultural or social identity.

Recital 26 adds the test that matters in practice: you must take account of all the means reasonably likely to be used to identify the person, by you or by anyone else, considering cost, time and available technology. That turns identifiability into a moving target — a dataset that was effectively anonymous in 2010 may not be today, because the auxiliary data available for cross-referencing has grown.

Russian law arrives at a similar place from a different angle. Article 3 of Federal Law 152-FZ defines personal data as any information relating directly or indirectly to an identified or identifiable individual, and the 2021 amendments added a separate regime for data the subject has allowed to be published. The practical effect is the same: you cannot argue that a record is not personal data merely because the name column is empty.

Direct identifiers point at one person on their own: a full name in a small population, a passport or national ID number, a personal tax number, a bank account, an email address at a personal domain, a mobile phone number. These are the fields everyone remembers to remove, and they are also the ones a pattern-based tool finds most reliably, because many of them carry checksums.

Indirect identifiers are the ones that cause incidents. A job title plus a city. A date of birth. A device model and operating system version. The timestamp of a purchase. Each is useless alone and devastating in combination — and log files, support tickets and analytics exports are made almost entirely of indirect identifiers.

A useful habit is to ask, for each field you are about to keep: how many people in the relevant population share this exact value? If the answer is one, you are looking at an identifier no matter what the column is called.

The Court of Justice of the European Union settled the IP question in Breyer (C-582/14, October 2016): a dynamic IP address held by a website operator is personal data for that operator if it has legal means allowing it to identify the visitor with the help of additional information held by the internet access provider. Static addresses were already treated as personal data. In other words, the address in your access log is not a neutral number.

Recital 30 of the GDPR names online identifiers explicitly: IP addresses, cookie identifiers and radio frequency identification tags, which may leave traces that, combined with unique identifiers and other information received by the servers, can be used to create profiles and identify people. Advertising IDs, push tokens, installation UUIDs and device fingerprints all fall in the same bucket.

This is why a redaction tool that only looks for emails and phone numbers leaves most of the risk in place. A support ticket with the customer's name removed but the session cookie, the IPv6 address and the device UUID intact is still a document about one identifiable person.

Latanya Sweeney's 2000 study of US census data is still the clearest demonstration: the combination of five-digit ZIP code, gender and full date of birth uniquely identified roughly 87 percent of the US population. None of those three fields looks like personal data in a database schema. Together they are a name.

The same effect broke the Netflix Prize dataset. In 2008 Narayanan and Shmatikov showed that a handful of film ratings with approximate dates, cross-referenced against public IMDb profiles, was enough to re-identify individual subscribers in a set that had been published as anonymous. Later work repeated the trick with taxi trip data, mobility traces and browsing histories.

For everyday work the lesson is modest but firm: when you decide what to leave in a document, count identifiers together rather than one at a time. Two coarse fields — a city and a month of birth — are usually fine; the same two at full precision usually are not.

Article 9 of the GDPR singles out data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic and biometric data processed to identify a person, health data, and data concerning sex life or sexual orientation. Processing these is prohibited unless one of the narrow exceptions applies, and Article 10 adds criminal convictions and offences as a separate restricted class.

Russian law uses the term “special categories” in Article 10 of 152-FZ and covers a similar list, with biometric data regulated separately in Article 11. In both systems the practical consequence is that these fields rarely belong in a shared log at all, even pseudonymised — a ticket that says the customer called about a diagnosis is health data even if the name is gone.

Article 4(5) defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected. Crucially, pseudonymised data is still personal data and still fully inside the GDPR. Replacing anna@example.com with [EMAIL_1] and keeping a mapping table is pseudonymisation, not anonymisation.

Recital 26 says that the regulation does not apply to anonymous information, but the bar is high: identification must be impossible for anyone, using any means reasonably likely to be used, permanently. The Article 29 Working Party's Opinion 05/2014 on anonymisation techniques goes through the families — randomisation, generalisation, k-anonymity, l-diversity, differential privacy — and shows how each fails against singling out, linkability or inference if applied carelessly.

For a person cleaning a document before sending it, the honest framing is this: you are reducing exposure, not creating anonymous data. Keep the mapping table out of the same email as the redacted text, delete it when the case is closed, and do not tell anyone the file is anonymous when it is merely pseudonymised.