What Is Personal Data Under the GDPR? Definition, Examples & Compliance Tips

Definition of Personal Data

Under the GDPR, personal data means any information relating to an identified or identifiable natural person. An identifiable natural person is someone who can be identified, directly or indirectly, by reference to identifiers like a name, an ID number, location data, an online identifier, or factors specific to their identity.

Information “relates to” a person when its content, purpose, or effect is about them—whether the data is factual or an opinion, raw or inferred. Personal data under the GDPR covers obvious identifiers and less obvious signals that can single someone out or be linked back to them over time.

The GDPR protects living individuals. Data about companies is not personal unless it identifies a person (for example, a sole trader’s email). Data that has been truly anonymised—so individuals are no longer identifiable by any means reasonably likely to be used—falls outside the GDPR.

Identifiability Criteria

Direct identification

Direct identification occurs when a person can be singled out without combining multiple sources—for example, a full legal name, a government ID number, a unique student or patient number, or a personal email like jane.doe@domain.com. These data points enable immediate recognition.

Indirect identification

Indirect identification happens when separate data elements, viewed together, make a person identifiable. A birthdate, ZIP code, and gender, a device fingerprint, or a unique username can enable indirect identification, especially when matched with other datasets.

Reasonable means and context

The identifiability test considers the means reasonably likely to be used by you or others. Availability of additional data, technical effort, costs, and the context (for example, a small workforce) matter. What is anonymous in one setting may enable identification in another.

Singling out and linkability

Even without a name, the ability to single out a person across records—via a stable cookie ID, advertising ID, or hashed email—can constitute personal data. Persistent tokens that allow records to be linked back to the same individual count toward identifiability.

Examples of Personal Data

Direct identifiers

• Full name, signature, photograph, voice recording
• Government IDs (passport, national ID, Social Security number)
• Personal contact details (home address, personal phone, personal email)

Likely-indirect identifiers

• Date of birth, place of birth, ZIP or post code, household composition
• Employment title at a small organization, unique job role, or rare skillset
• Vehicle registration and VIN when linked to an individual

Online identifiers and technical data

• IP addresses, cookie IDs, device IDs, advertising IDs, MAC addresses
• Precise geolocation, device telemetry, session IDs, referrers, and logs
• Usernames, account IDs, and persistent tokens enabling cross-session linkage

Financial, health, biometric, and derived data

• Bank account and card numbers, transaction histories, credit scores
• Medical records, health metrics, disability information
• Biometric identifiers (faceprints, fingerprints, voiceprints) used to identify a person
• Profiles and inferences (propensity scores, interests, churn risk) tied to an individual

Sensitive Personal Data

Sensitive personal data—also called “special category data”—includes data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data concerning a person’s sex life or sexual orientation. This data generally requires a stricter legal basis, such as explicit consent or a limited, specific exception.

Data about criminal convictions and offences is not a special category, but it is subject to separate safeguards and may only be processed under specific conditions. Handling sensitive personal data demands enhanced protection measures, rigorous access controls, and careful necessity assessments.

Anonymised and Pseudonymised Data

Anonymised data is processed so individuals are no longer identifiable by any party using means reasonably likely to be employed; the GDPR does not apply to such data. Pseudonymised data replaces direct identifiers with codes or tokens, but re-identification remains possible with additional information—so it is still personal data.

Effective anonymisation

To achieve anonymisation, remove or transform identifiers and quasi-identifiers, reduce precision (for example, coarse location or broad age bands), and prevent singling out in small groups. Validate that re-identification is not reasonably likely given available auxiliary data.

Pseudonymisation techniques

Use keyed hashing with salt, tokenisation, and encryption. Store the mapping (keys or lookup tables) separately with strict access controls. Rotate identifiers, limit retention, and segment environments. Pseudonymisation supports Data protection by design while preserving analytic utility.

Common pitfalls

Stable “anonymous” IDs, small-cell aggregates, or consistent device fingerprints can still enable linkability. Always test for re-identification risk and avoid reusing the same token across contexts without necessity and safeguards.

Processing of Personal Data

Processing covers any operation on personal data—collection, recording, structuring, storage, adaptation, retrieval, consultation, use, disclosure or sharing, alignment, combination, restriction, erasure, or destruction. Almost any interaction with personal data qualifies as processing.

Lawful bases

You must have one lawful basis: consent, contract, legal obligation, vital interests, public task, or legitimate interests (subject to a balancing test). Choose a single, appropriate basis per purpose and document your reasoning.

Core principles

• Purpose limitation: state clear, specific purposes and avoid incompatible reuse.
• Data minimisation: collect the minimum necessary and keep precision no higher than needed.
• Accuracy: keep data up to date and correct inaccuracies promptly.
• Storage limitation: set retention periods and delete or anonymise when no longer needed.
• Integrity and confidentiality: protect against unauthorized or unlawful processing and loss.
• Accountability and transparency: be able to demonstrate compliance and inform individuals how you use their data.

Data subject rights

• Access, rectification, and erasure
• Restriction and objection (including to direct marketing)
• Data portability
• Rights related to automated decision-making, including profiling, where applicable

Sharing, vendors, and international transfers

Define roles (controller, joint controller, processor). Put processor contracts in place with clear instructions and security duties. For cross-border transfers, use appropriate transfer tools and assess local laws to ensure essentially equivalent protection.

Data protection by design and default

Embed privacy into architecture: prefer edge processing, short retention, granular access, encryption, and pseudonymisation. Run DPIAs for high-risk processing, and make privacy-preserving choices the default settings.

Compliance Tips for GDPR

• Map your data: maintain a record of processing activities, data flows, purposes, recipients, and retention.
• Define purposes up front and align each purpose to a lawful basis; obtain Informed consent where consent is the basis.
• Practice Data minimisation: limit collection, precision, access, and retention; review fields before adding them.
• Implement security controls: encryption in transit and at rest, access control, monitoring, and regular testing; plan for incident response and timely breach notification.
• Operationalise rights: offer self-service portals or efficient manual processes to handle access, deletion, portability, and objections.
• Manage vendors and transfers: use processor agreements, vet safeguards, and conduct transfer impact assessments where needed.
• Adopt Data protection by design: pseudonymise by default, segregate identifiers, and apply privacy-preserving analytics where feasible.
• Governance and training: appoint a DPO when required, train staff, audit regularly, and document decisions (for example, DPIAs and legitimate interests assessments).

Summary

Personal data under the GDPR spans any information that identifies or can identify a person through direct identification or indirect identification. Effective compliance rests on clear purposes, lawful bases, Purpose limitation, Data minimisation, strong security, and Data protection by design across the lifecycle.

FAQs

What qualifies as personal data under the GDPR?

Any information relating to an identified or identifiable natural person qualifies. This includes direct identifiers (like a name or ID number), indirect identifiers combined to single someone out, online identifiers, and even inferences about a person. Data that has been truly anonymised so individuals are not identifiable by reasonable means falls outside scope.

How is sensitive personal data different from regular personal data?

Sensitive personal data (special category data) covers areas like health, biometrics used for identification, genetics, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, and sex life or sexual orientation. It requires stricter conditions—often explicit consent or a specific exception—and stronger safeguards. Criminal conviction data is regulated separately.

What are best practices for GDPR compliance?

Define purposes early, pick a lawful basis per purpose, and obtain Informed consent when relying on consent. Apply Purpose limitation and Data minimisation, secure data with encryption and access controls, maintain records of processing, enable rights requests, assess high-risk activities with DPIAs, manage vendors and transfers carefully, and embed Data protection by design.

How does pseudonymisation affect GDPR obligations?

Pseudonymisation reduces risk and supports Data protection by design, but the data remains personal because re-identification is possible with additional information. All GDPR obligations still apply—lawful basis, principles, rights, and security—though controls may be proportionate, and some requirements (like access control and retention) become easier to meet in a risk-based way.