Controllers: Log Article 6 and 9 Proof for GDPR PII Categories
Under the GDPR, personal data is any information relating to an identified or identifiable natural person, and the bar for “identifiable” is lower than most teams assume. A subset of that data, called special categories under Article 9, needs a separate legal justification on top of your normal Article 6 basis. If you can’t point to documentation showing both, you have a compliance gap, not a technicality.
TL;DR:
- Most datasets with plausible re-identification methods are considered personal data under GDPR, requiring proper legal justification for processing.
- Indirect identifiers like device IDs, location data, and quasi-identifiers are easily overlooked but can link back to individuals, increasing compliance risks.
- Processing sensitive categories such as health, genetic, biometric, or political data requires dual approval under Articles 6 and 9, with documented lawful bases and national law considerations.
- Profiling outputs that infer Article 9 traits are considered sensitive data, necessitating a DPIA and strict controls before deployment.
- Local, auditable analysis tools that keep data on the researcher’s machine simplify compliance, especially for special-category data, by avoiding cross-border transfers and providing transparent documentation.
Table of Contents
- What Counts as Personal Data Under GDPR PII Categories
- Personal Data Categories: Direct and Indirect Identifiers
- Special Category Data: The Article 9 List and Why It’s Different
- Combining Article 6 and Article 9: The Two-Step Lawful Basis Test
- When Analytics Turn Ordinary Data Into Special Category Data
- Anonymization vs Pseudonymization: Where GDPR Stops Applying
- A Compliance Checklist for Classifying and Protecting Personal Data
- How Local, Auditable Analysis Supports GDPR Obligations for Research Data
- Author Perspective: Classify First, Document Second, Automate Last
- A Privacy-First Path for Sensitive Research Data
- Sources
- FAQ
What Counts as Personal Data Under GDPR PII Categories
Article 4(1) of the GDPR defines personal data as “any information relating to an identified or identifiable natural person.” That single sentence carries more weight than its length suggests, because it makes almost every operational dataset a candidate for regulation. The GDPR text on EUR-Lex lists name, identification number, location data, and online identifiers as examples, but the definition doesn’t stop at obvious fields.
Regulators apply what’s often called a “reasonable means” test. If a person could plausibly be identified by combining a dataset with another source, even one you don’t currently hold, that dataset counts as personal data. This is why European Commission guidance on applying the GDPR stresses that identifiability includes indirect routes: a key linking pseudonyms to real identities, a device ID matched against a login table, or a rare combination of postal code, birth date, and gender.
The regulation is also format neutral. A few things follow directly from that:
- It applies to paper files just as much as databases and spreadsheets.
- Manual processing counts if the data is structured enough to search (a filing system, not a shoebox of receipts).
- Automated processing, including AI-driven analysis pipelines, is fully in scope regardless of where the model runs.
- Scope extends to organizations outside the EU when they offer goods or services to, or monitor the behavior of, people in the EU.
Treat any dataset with a plausible re-identification path as personal data first, and only reclassify it after a documented test says otherwise.
Personal Data Categories: Direct and Indirect Identifiers
Compliance teams typically sort identifiers into two buckets, and the split matters because indirect identifiers get missed far more often in audits.
Direct identifiers point at a specific person with no extra work required. Common examples include:
- Full legal name
- National ID or passport number
- Personal email address
- Home address and phone number
- Signature and photograph used for identification
Indirect identifiers don’t name someone outright, but they can be linked back to a person through other data. This category tends to catch teams off guard:
- IP addresses and cookie identifiers
- Device IDs and advertising IDs
- GPS coordinates and location trails
- Combinations of quasi-identifiers (job title plus department plus start date, for instance) that narrow a dataset down to one individual
Work context adds a wrinkle. A business email like j.rivera@company.com is still personal data because it identifies an individual, even though it’s tied to an employer. HR records, performance reviews, and internal directories fall the same way. What’s excluded is data about the company itself: a generic info@company.com inbox, a corporate registration number, or aggregate department budgets carry no link to an identifiable person and sit outside GDPR’s personal data categories entirely.
Special Category Data: The Article 9 List and Why It’s Different
Article 9 names a shorter, higher-risk list, and processing it is prohibited by default. The GDPR lists these types as special categories:
- Racial or ethnic origin
- Political opinions
- Religious or philosophical beliefs
- Trade union membership
- Genetic data
- Biometric data, when used for unique identification
- Health data
- Data concerning sex life or sexual orientation
These categories carry elevated risk because misuse can lead to discrimination, exclusion, or harm that ordinary identifiers rarely cause on their own. A leaked email address is a nuisance. A leaked HIV status or union membership record can cost someone a job or worse, which is the rationale behind the stricter Article 9 regime.
Genetic data fits this list because it reveals inherited traits about a person and, often, their biological relatives, making the harm both individual and familial. It typically shows up in research contexts through sequencing data, ancestry results, or clinical genotyping, and it’s treated with the same weight as health data even when it arrives as a raw file rather than a diagnosis.
Biometric data has a genuine nuance that trips up a lot of teams. A photo on an event registration form isn’t automatically special category data. It becomes special category only when it’s processed for the specific purpose of uniquely identifying someone, such as running it through facial recognition. The ICO’s guidance on special category data draws this line explicitly: the purpose of processing, not the data type itself, determines classification.
Criminal conviction and offense data sits outside Article 9 entirely. Article 10 governs it separately, and most member states layer their own national restrictions on top, often requiring specific legal authority before you can process it at all.
Combining Article 6 and Article 9: The Two-Step Lawful Basis Test
Every processing activity involving special category data needs two separate approvals, not one.
- Identify an Article 6 lawful basis first: consent, contract necessity, legal obligation, vital interests, public task, or legitimate interests.
- If the data falls under Article 9’s special categories, identify a matching exception under Article 9(2): explicit consent, obligations tied to employment or social security, vital interests where the person can’t consent, substantial public interest, or scientific and statistical research purposes.
- Check national law caveats, since member states can narrow or add conditions to several of these exceptions, particularly around health and research.
- Document both bases together in your lawful-basis log, not as separate, disconnected records.
European Commission guidance on legal grounds is direct about this structure. The most common audit failure isn’t a missing Article 6 basis. It’s a missing or unvalidated Article 9 justification sitting behind data that clearly needed one.
When Analytics Turn Ordinary Data Into Special Category Data
Profiling can manufacture special category data even when none of the inputs were sensitive. A model that predicts likely health conditions from purchase history, or infers political leaning from social media activity, produces an output that reveals a sensitive trait. The ICO treats that inferred output as special category data, regardless of how mundane the source data looked.
This shows up constantly in predictive health scoring, credit models that correlate with protected characteristics, and marketing segmentation that infers religion or sexual orientation from browsing behavior. The derived data inherits the legal sensitivity of what it reveals.
Pro Tip: Run a Data Protection Impact Assessment before deploying any model whose output could reveal a health condition, belief, or other Article 9 trait, even if the training data itself contains nothing sensitive. Pair it with strict purpose limitation and access controls that treat the output like source special-category data, not like a harmless score.
Anonymization vs Pseudonymization: Where GDPR Stops Applying
Anonymization removes GDPR obligations only when it’s irreversible. Pseudonymization, which replaces identifiers with a token that a key can reverse, keeps the data inside GDPR’s scope for as long as anyone can plausibly reconnect the token to the person.
That distinction gets misread constantly. European Commission guidance confirms that pseudonymized data remains personal data if the controller, or a linked party, retains the ability to re-identify it. Swapping a name for a participant number doesn’t exit the regulation; it just adds a layer that has to be protected as carefully as the original identifier.
Re-identification risk climbs fast in high-dimensional research datasets, where a handful of variables like age, postal code, and diagnosis date can uniquely fingerprint someone even without a name attached. Guard against it with:
- Documented key management showing who can access the re-identification key and under what conditions
- Reproducible audit trails that record exactly how anonymization or pseudonymization was applied
- Periodic re-identification testing on high-dimensional datasets, not a one-time check at project start
A workable rule of thumb from practitioners handling regulated data: if you can’t prove irreversibility with a documented, testable process, treat the dataset as pseudonymized and keep it inside your GDPR controls. A closer breakdown of the technical and legal differences between anonymization and pseudonymization walks through the specific tests regulators expect to see.
A Compliance Checklist for Classifying and Protecting Personal Data
Most audit findings trace back to a skipped step, not a misunderstanding of the law. Work through these in order:
- Classify every field: personal, special category, or out of scope, and record the reasoning.
- Identify your Article 6 lawful basis for each processing activity.
- Identify the matching Article 9 exception for any special category data, checking national-law limits.
- Run a DPIA when processing is large scale, involves special categories, or includes profiling.
- Set retention limits and access controls tied to the classification, not a blanket policy.
- Log everything: lawful-basis records, Article 9 justification, DPIA outcomes, and processing agreements with any third party touching the data.
| Artifact | What it proves | Who checks it |
|---|---|---|
| Lawful-basis log | Article 6 basis for each processing activity | Regulators, internal audit |
| Article 9 justification record | Valid exception for special category processing | Data protection authority |
| DPIA documentation | Risk assessment for high-risk or profiling activity | Data protection officer, auditors |
| Access control list | Who can view or re-identify sensitive data | Security and compliance teams |
| Processing agreements | Third-party obligations match your own | Legal, procurement |
Watch for these escalation triggers specifically: any profiling output that could reveal a sensitive trait, any cross-border transfer of special category data, and any anonymization claim that hasn’t been re-tested since the dataset last changed shape. Data anonymization techniques that pass a test on one export can fail on the next if new fields get added.
How Local, Auditable Analysis Supports GDPR Obligations for Research Data
Research teams working with health records, genetic data, or other special categories face a structural problem: most cloud analytics tools require uploading that data somewhere outside the researcher’s control, which is a hard blocker for IRB-governed or GDPR special-category datasets, underscoring the importance of platforms that prioritize privacy and content control.
Some analytics platforms run analysis locally on the researcher’s own machine, so special-category data never leaves the device in the first place. That sidesteps the cross-border transfer and cloud-processing questions entirely, rather than trying to answer them after the fact.
Two other design choices matter for documentation:
- Every analysis runs against a pre-approved analysis plan, giving reviewers a written record of methods and assumptions before any code executes, which doubles as evidence for a DPIA.
- Certain software features let a lab encode its field’s required statistical steps once, so every subsequent analysis follows the same documented methodology.
- Exports include annotated notebooks and permanent, searchable analysis pages, giving auditors a traceable record of exactly how a result was produced.
Author Perspective: Classify First, Document Second, Automate Last
Most privacy programs get the order backward. They write policy documents before they’ve run a single identifiability test on their actual data, which means the policy is guessing at a classification nobody has verified. Start with the test, not the paperwork.
Treat every profiling output as sensitive until proven otherwise, and DPIA it before deployment, not after a complaint. Reproducible, local-first tooling makes that discipline easier to sustain than manual spreadsheets ever will.
— Aymen
A Privacy-First Path for Sensitive Research Data
Research teams handling patient records, genetic data, or other special categories don’t need to choose between rigorous analysis and defensible compliance. Plotstudio runs statistical analysis, including survival models, mixed-effects regression, and Cox proportional hazards, entirely on the researcher’s own machine, so special-category data never touches a cloud server.
Every analysis is gated behind a plan the researcher reviews before code runs, which gives your DPIA documentation a built-in audit trail instead of a reconstructed one. Combined with annotated notebook exports and searchable analysis pages, that’s a workflow built for peer review and regulatory scrutiny at the same time. If your lab handles GDPR special-category data and needs a managed deployment, see how an enterprise plan handles regulated research data and start with a review of your current DPIA gaps.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
- Regulation (EU) 2016/679 (GDPR) — EUR-Lex
- European Commission — Application of the GDPR
- ICO — What is special category data?
FAQ
What are the categories of PII data under GDPR?
GDPR splits personal data into general categories (name, ID numbers, location data, online identifiers) and special categories under Article 9, which cover racial or ethnic origin, health data, genetic data, biometric data used for identification, religious beliefs, political opinions, trade union membership, and sex life or sexual orientation data.
What are the categories of personal data under GDPR?
Personal data under Article 4 includes any information relating to an identified or identifiable person, direct identifiers like name and passport number, and indirect identifiers like IP addresses, device IDs, and location trails that can be linked back to someone.
What are the 7 GDPR requirements?
The GDPR is built on seven core principles: lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality; and accountability, all of which controllers must apply to every processing activity.
What is GDPR and PII?
GDPR is the EU regulation governing how organizations collect, process, and protect personal data, and PII (personally identifiable information) is the common industry term for the same concept the regulation calls “personal data” under Article 4.
Is a business email address considered personal data under GDPR?
Yes. A business email tied to a specific individual, such as a first and last name at a company domain, still identifies that person and counts as personal data, even though it’s used in a work context.