Everything in GDPR flows from one definition: personal data. Get it right and the rest of the regulation has a clear target; get it wrong and you will either over-engineer your programme or, more often, leave real obligations unmet. A precise understanding of personal data is the bedrock of any GDPR compliance.
This guide explains exactly what personal data means under GDPR, with plenty of examples, the tricky edge cases, and a practical way to identify it across your systems.
The GDPR definition
Under GDPR, personal data is “any information relating to an identified or identifiable natural person”. That phrase is doing a lot of work. “Any information” is deliberately broad, “relating to” means the data only has to be about or linkable to a person, and “identifiable” includes people you could single out indirectly, not just those you can name.
The result is one of the widest definitions in privacy law. If a piece of information can be connected to a living individual, directly or indirectly, it is almost certainly personal data and within scope of the regulation.
“Identified or identifiable”
A person is identified when you can distinguish them from everyone else — by name, for example. A person is identifiable when you could single them out using information you have or could reasonably obtain, even without a name. An ID number, a combination of attributes, or an online identifier can all make someone identifiable.
The test considers the means reasonably likely to be used to identify someone, accounting for cost, time and available technology. As re-identification gets easier, more data becomes “identifiable” and therefore personal.
Free resource
The Ultimate Guide to GDPR
Scope your personal data correctly with a clear, practical classification guide.
Common examples of personal data
Obvious examples include name, home address, email address, phone number, identification numbers and date of birth. But GDPR reaches much further: location data, IP addresses, cookie identifiers, device IDs, account usernames, photographs and even an individual’s appearance or voice can all be personal data.
The breadth surprises many teams, particularly the inclusion of online and technical identifiers that a narrower “PII” mindset tends to overlook.
Online identifiers are personal data
GDPR explicitly names online identifiers — including IP addresses and cookie IDs — as personal data. This is one of the most important practical points for any website or app, because it brings analytics, advertising and tracking data squarely into scope.
If your systems log IPs or set identifying cookies, you are processing personal data, with all the consent, transparency and rights obligations that follow. Treating this data as anonymous “traffic” is a common and costly mistake.
Pseudonymised data is still personal data
Replacing identifiers with tokens — pseudonymisation — reduces risk but does not take data out of scope. Because a key still exists to re-link the data to individuals, pseudonymised data remains personal data under GDPR.
This catches teams who assume hashing or tokenising removes their obligations. Pseudonymisation is a valuable security measure that GDPR actively encourages, but it is a safeguard, not an exemption.
Anonymised data is not personal data
By contrast, truly anonymised data — where re-identification is no longer reasonably possible — falls outside GDPR entirely. Genuine anonymisation is a high bar: it must be irreversible, accounting for all the means someone could realistically use to re-identify individuals.
Aggregated statistics with no path back to individuals are a good example. If you can anonymise data you no longer need in identifiable form, you keep its analytical value while removing it from GDPR’s scope.
Inferred and derived data
Personal data is not limited to what people give you. Inferred and derived data — a credit score, a risk rating, a marketing segment, a predicted preference — relates to an identifiable person and is therefore personal data, even though the individual never directly provided it.
This matters for analytics and profiling: the conclusions you generate about people carry the same obligations as the raw data you started with.
What is not personal data
Some information falls outside the definition. Data about deceased persons is not personal data under GDPR (though national law may protect it). Genuinely anonymous data is out of scope. And information about organisations — a company’s registered address or turnover — is not personal data, unless it also identifies an individual.
The line can be subtle: a generic role address like info@company.com is not personal data, but a named employee’s work email is.
Special category data
A subset of personal data is treated as especially sensitive: special category data under Article 9. This includes data revealing racial or ethnic origin, political opinions, religious beliefs, trade-union membership, genetic and biometric data, health, and data about a person’s sex life or sexual orientation.
Processing special category data is prohibited unless a specific additional condition applies, so identifying it within your wider personal data is an important step.
Why the broad definition matters
Because the definition is so wide, scoping your data correctly is the foundation of GDPR compliance. Underestimate it — by treating IP addresses, pseudonymised records or inferred data as out of scope — and you will miss obligations, fail data subject requests, and create gaps that surface during audits or breaches.
Overestimating is far less risky than underestimating, so when in doubt, treat data as personal and protect it accordingly.
How to identify personal data in your systems
Build a data inventory that asks, for each system and dataset: could this information, alone or combined with other data we hold, identify or single out a living individual? Flag online identifiers, pseudonymised fields and inferred data as in scope by default, and tag any special category data separately.
This inventory underpins everything else — your records of processing, lawful basis assessments, retention schedules and responses to rights requests all depend on knowing exactly what personal data you hold and where.
A practical test you can apply
When you are unsure, use a simple rule: if the information could reasonably be linked back to a living person, treat it as personal data. This errs toward caution, which is exactly where you want to be — over-protecting a borderline dataset costs little, while under-protecting one is how compliance gaps and breaches happen.
Apply the test consistently across new features, vendors and datasets, and you will keep your scope accurate as your business evolves.
How ISpectra helps
Getting the definition of personal data right is the starting point for credible GDPR compliance. ISpectra Technologies helps organisations build data inventories and classification schemes around the GDPR definition — capturing online identifiers, pseudonymised and inferred data, and special categories — so nothing person-linkable slips through unprotected.
If your current map is built on a narrow “PII” view, a short review usually surfaces several categories you need to bring into scope.
Free consultation
Need help with GDPR?
Talk to our data-protection specialists — we’ll map your fastest path to compliance.
In one paragraph
Personal data under GDPR is any information relating to an identified or identifiable living person — a deliberately broad definition that includes names and contact details but also IP addresses, cookie IDs, location data, pseudonymised records and inferred data like scores and segments. Truly anonymous data and information about organisations or deceased people sit outside it, while a sensitive subset known as special category data carries extra protection. Because the definition is so wide, the safest approach is to treat anything reasonably linkable to a person as personal data and protect it accordingly.