Special category data is the personal data the GDPR prohibits you from processing unless you can point to a specific Article 9 condition, and it is also the data whose exposure hurts people most. Health records, genetic results, biometric templates used for identification, union membership lists and data revealing ethnicity, religion, politics, sex life or sexual orientation all sit behind that prohibition. This guide is for security, privacy and data engineering teams who need to find this data, confirm the legal footing with their DPO, and then put controls around it that are visibly stronger than the baseline. It covers the EU GDPR and the UK GDPR with the Data Protection Act 2018, and it goes deeper than the GDPR Compliance Guide for Security Teams, which treats special category data only as one input to risk.
Key takeaways
- Two legal tests, not one. You need an Article 6 lawful basis and a separate Article 9(2) condition, and in the UK many conditions also need a Schedule 1 condition under the Data Protection Act 2018.
- Inference is enough. The CJEU held in Case C-184/20 that data liable to reveal sexual orientation indirectly is special category data, and the ICO treats inferred data as special category regardless of how confident the inference is.
- The scope is wider than the obvious systems. Pharmacy order data is health data even without a prescription (CJEU C-21/23), so marketing, analytics, logs and support tickets often hold special category data nobody tagged.
- Security has to be proportionate to the harm. Article 32 is risk based, and regulators expect stronger authentication, tighter access and better monitoring for this data, as the ICO's 2025 penalty against 23andMe shows.
- Machine access is the blind spot. Service accounts, ETL jobs, BI connectors and AI pipelines usually read special category stores with broader rights than any human, so they belong in the same access reviews.
What counts as special category data
Article 9(1) GDPR lists the categories exhaustively. Criminal offence data is not on the list: it is governed separately by Article 10, and the ICO notes that similar rules and safeguards still apply. Treat both as restricted data in your classification scheme, but keep the legal analysis separate.
| Category | Definition or trigger | Where it hides in practice |
|---|---|---|
| Racial or ethnic origin | Data revealing origin, including by inference from names or images (ICO example) | Diversity monitoring, HR systems, photo libraries, marketing segments |
| Political opinions | Data revealing political views; inferring them for ad targeting is special category processing (ICO example) | Ad tech audiences, survey tools, social listening |
| Religious or philosophical beliefs | Data revealing belief | Dietary requirements, leave requests, event registrations |
| Trade union membership | Membership itself | Payroll deductions, HR case files, email distribution lists |
| Genetic data | Inherited or acquired genetic characteristics, including DNA or RNA analysis (Art. 4(13), Recital 34) | Consumer genomics, research datasets, raw data downloads |
| Biometric data for unique identification | Data from specific technical processing, special category only when used or intended to identify someone uniquely (Art. 4(14)) | Door access fingerprints, face verification in onboarding, voice ID in contact centres |
| Health | Physical or mental health, including provision of care (Art. 4(15)) | Sickness absence, occupational health, wellbeing apps, pharmacy and e-commerce orders, accessibility requests |
| Sex life or sexual orientation | Data revealing either, directly or indirectly | Partner names in benefits or declarations, dating features, HR equality data |
Two rulings shape the boundary. In C-184/20 OT (Grand Chamber, 1 August 2022) the Court read "revealing" to cover information obtained through "an intellectual operation involving deduction or cross-referencing", so publishing a declarant's partner's name was special category processing. In C-21/23 Lindenapotheke (4 October 2024) it held that customer data entered to order pharmacy-only medicines online is health data even where no prescription is needed. The practical reading for discovery: a field does not have to be labelled "diagnosis" to be in scope. A photograph is not automatically biometric data, but the same image fed into a face matching service is.
Article 9 conditions and what each one asks of security
The legal choice belongs to the controller and its DPO. Security teams need to know which condition applies because it changes the evidence and safeguards you must be able to show. Article 9(4) also lets Member States add conditions for genetic, biometric and health data, so check national law for each country of processing.
| Article 9(2) | Condition | Typical use | Security and evidence implications |
|---|---|---|---|
| (a) | Explicit consent | Consumer health apps, genomics, optional diversity data | Consent records must be tamper evident and linked to purpose; withdrawal must propagate to every copy, including analytics and backups on their retention cycle |
| (b) | Employment, social security and social protection law | Sickness absence, occupational health, reasonable adjustments | UK: Schedule 1 condition 1 plus an appropriate policy document; strict role-based access in HR systems |
| (c) | Vital interests where the person cannot consent | Emergency medical information | Break-glass style access with logging and after-the-fact review |
| (d) | Not-for-profit bodies with political, religious, philosophical or union aims | Union and church membership systems | No disclosure outside the body without consent: watch exports and third-party mailing tools |
| (e) | Manifestly made public by the data subject | Narrow; rarely safe for scraping or enrichment | Document why the person deliberately made it public; scraped data rarely meets this |
| (f) | Legal claims and courts | Litigation holds, employment tribunals | Legal hold storage with restricted access and chain of custody |
| (g) | Substantial public interest under law | Fraud prevention, safeguarding, equality monitoring | UK: Schedule 1 Part 2 conditions, most needing an appropriate policy document |
| (h) | Health or social care, with professional secrecy (Art. 9(3)) | Clinical systems, care records | Access limited to those under a duty of confidentiality; strong audit of record access |
| (i) | Public health | Disease surveillance, medicines safety | Safeguards set by law, often including professional secrecy |
| (j) | Archiving, research and statistics under Article 89(1) | Clinical research, statistics | Pseudonymisation and minimisation as Article 89 safeguards; separate key holding |
In the UK, section 10 of the Data Protection Act 2018 requires a Schedule 1 condition wherever the Article 9 condition needs a basis in law. The ICO lists conditions 1 to 4 for employment, health or social care, public health and research, and conditions 6 to 28 for substantial public interest. Explicit consent must be confirmed in a clear statement, name the nature of the special category data and sit apart from any other consent you collect. See the UK GDPR and Data Protection Act 2018 Guide for the wider UK regime.
The appropriate policy document
Under Schedule 1 Part 4, the appropriate policy document (APD) explains the procedures for complying with the Article 5 principles and sets out retention and erasure policies with an indication of how long the data is likely to be kept. It must be retained for six months after the processing ends and made available to the regulator on request, free of charge. The ICO says an APD is needed for the employment condition and almost all substantial public interest conditions, but not for health or social care, public health or research. Security teams should own the sections on access control, encryption, logging and deletion so the document describes controls that actually exist.
Finding special category data you did not know you had
A record of processing that names the condition is mandatory under the ICO's guidance, but the record is only as good as discovery. Build the inventory from three directions.
- From purposes: interview HR, occupational health, customer support, marketing, product and data science about why they might process each category. Map answers to systems in the Data Mapping and ROPA Guide format.
- From content: run classifiers over databases, object storage, SaaS file stores and ticketing systems. Tune them for proxies as well as direct terms: medication names, clinic names, partner fields, prayer or dietary codes, union deduction codes and accessibility flags.
- From models and features: list every model, segment or score that predicts a characteristic linked to a special category (pregnancy, health risk, ethnicity, political affinity). Per the ICO, the output is special category data however uncertain the prediction.
Tag results with a dedicated label in your scheme rather than folding them into "confidential". The Data Classification Guide covers label design; the important point here is that the label must be machine readable so DLP, access policies and retention jobs can act on it. Remember derived copies: logs that capture request bodies, data warehouse staging tables, test environments seeded from production, exports in collaboration tools and AI prompt histories.
Security controls proportionate to the harm
Article 32 does not list special category data by name, but it requires measures appropriate to the risk to individuals, and the ICO tells controllers to consider additional security measures for this data. The controls below are the ones that distinguish a special category store from an ordinary personal data store.
| Control area | Baseline personal data | Special category uplift |
|---|---|---|
| Authentication | SSO with MFA for staff | Phishing-resistant MFA for staff; mandatory MFA or step-up for customer access to their own sensitive records and raw downloads |
| Authorisation | Role-based access | Purpose-based roles, field-level or row-level restriction, no broad "all records" roles; quarterly certification |
| Machine access | Service accounts inventoried | Dedicated non-human identities per pipeline, read scopes limited to needed columns, short-lived credentials from a vault |
| Encryption | Platform encryption at rest, TLS in transit | Customer-managed keys or application-level encryption for the most sensitive fields, with key access logged separately |
| Minimisation | Retention schedule | Pseudonymised analytics copies, tokenised identifiers, automated deletion tied to the APD retention statement |
| Monitoring | Security event logging | Record-level access logging, alerts on bulk reads and exports, anomaly detection on customer login patterns |
| Non-production | Masking encouraged | No production special category data in test or development without a documented exception |
- Pseudonymisation: separate direct identifiers from sensitive attributes and hold the re-identification key in a different trust domain. The Pseudonymisation Techniques Guide covers tokenisation, keyed hashing and key separation; pseudonymised data remains personal data.
- Customer-facing access: the ICO's 23andMe penalty notice summary points to missing mandatory MFA, weak password rules and no extra verification before raw genetic data could be accessed or downloaded. If customers can view or export their own sensitive records, require step-up authentication for that action.
- Linked records: features that let one account see data about others (family matching, shared care plans, team wellbeing dashboards) multiply the blast radius of one compromised account. Rate limit and log cross-record views.
Where identity fits
Most special category stores are read far more often by machines than by people. ETL jobs move sickness data into payroll, BI connectors pull HR equality data into dashboards, support tools sync health notes into tickets and AI assistants are given retrieval access to case files. Each of these runs as a service account, OAuth client or API key, usually with standing read access to whole tables. Give each pipeline its own identity, scope it to the columns it needs, keep credentials in a secrets manager, and include these identities in the same quarterly review as the humans. The Service Account Security Guide covers ownership and rotation, and the Access Reviews Guide covers the certification process.
Decision guidance
- Collect or infer? If the purpose can be met without the category, do not collect it and do not build features that infer it. Removing a model output is cheaper than defending it in a DPIA.
- Consent or another condition? Explicit consent suits optional consumer features. In employment it is rarely freely given, so condition (b) with Schedule 1 condition 1 and an APD is the usual UK route, decided with the DPO.
- Central store or embedded fields? A single segregated store with its own access policy is easier to protect and audit than sensitive fields spread across a CRM. Large organisations should segregate; small organisations with one HR platform can rely on that platform's role controls if they restrict and review them.
- Small versus large: a small employer handling sickness notes needs a clear APD, restricted HR access and MFA. An organisation processing special category data at scale as a core activity triggers a mandatory DPO under Article 37(1)(c) and a DPIA under Article 35(3)(b).
Implementation roadmap
- Weeks 1 to 4, discover: run the three-direction inventory, label stores and fields, and record the Article 6 basis and Article 9 condition (and Schedule 1 condition in the UK) for each processing activity.
- Weeks 3 to 6, assess: complete or refresh DPIAs where the ICO criteria apply (large scale, access decisions, genetic or biometric identification). Use the DPIA Guide: Running a Data Protection Impact Assessment.
- Weeks 5 to 10, restrict access: remove broad roles, create purpose roles, split service accounts per pipeline, and run the first certification. Pilot on one store, compare access logs before and after for a fortnight, and keep the previous role mappings exported so you can roll back a role that blocks a legitimate process.
- Weeks 8 to 14, protect data: enable record-level logging, apply field encryption or tokenisation to the most sensitive fields, enforce step-up for exports, and purge production copies from non-production.
- Weeks 12 to 16, document: write or update the APD with the real controls, add the categories to privacy information, and set the retention jobs that implement it.
- Ongoing: rerun discovery each quarter and whenever a new model, integration or SaaS tool touches labelled data.
Detection and measurement
Log every read, export and permission change on labelled stores, including reads by service accounts. Alert on bulk exports above a set threshold, first-time access by a new identity, access outside the role's purpose (for example, a finance user opening occupational health records) and spikes in failed customer logins against accounts with sensitive data. Feed these into the same pipeline that supports breach assessment, because a personal data breach involving special category data is more likely to meet the threshold for notifying individuals; see the Data Breach Notification Checklist.
- Coverage: percentage of known special category stores with a recorded Article 9 condition and owner.
- Access breadth: number of human and non-human identities with read access per store, tracked down over time.
- Review completion: percentage of access to labelled stores certified in the last quarter, including service accounts.
- Logging: percentage of labelled stores with record-level access logs in the SIEM.
- Non-production hygiene: count of non-production environments holding unmasked special category data (target zero).
- Customer protection: share of customer accounts with access to sensitive records protected by MFA.
Framework mapping
| Activity | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Legal basis and conditions | PT-2 Authority to Process PII; PT-7 Specific Categories of PII | GV.OC-03 | A.5.31, A.5.34 | 3.1 |
| Inventory and labelling | PT-7 | ID.AM-07 | A.5.12, A.5.13 | 3.2, 3.7 |
| Access restriction | AC-3, AC-6 | PR.AA-05 | A.8.3 | 3.3 |
| Encryption at rest | SC-28 | PR.DS-01 | A.8.24 | 3.11 |
| Access logging | AU-2 | DE.CM-03 | A.8.15 | 3.14 |
| Impact assessment | RA-8 | ID.RA-04 | A.5.34 | 3.1 |
| Retention and disposal | SI-12 | PR.DS-01 | A.8.10 | 3.4 |
Common failure patterns
- Treating labels as the scope: discovery looks for "health" fields and misses order histories, partner names and model outputs that the CJEU and ICO treat as special category data.
- Optional MFA on sensitive consumer accounts: the 23andMe credential stuffing breach combined reused passwords, optional MFA and a matching feature that exposed relatives' data, and the ICO fined the company GBP 2.31 million in June 2025.
- An APD that describes nothing real: a template policy promising encryption and deletion that the systems do not perform is worse than none when the regulator asks for it.
- Pipelines with god-mode access: one analytics service account reading every HR table, never reviewed and holding a static key.
- Production data in test: occupational health or patient records copied into a development database with weaker access and no logging.
- Consent from employees: relying on staff consent for health or biometric processing where it cannot be freely given, leaving no valid condition.
Practitioner checklist
- Agree a written definition of each Article 9 category, including proxies and inferences, with the DPO.
- Inventory special category data by purpose, content scan and model output, and label it in a machine-readable way.
- Record the Article 6 basis, Article 9 condition and any Schedule 1 condition per processing activity.
- Write or refresh the appropriate policy document and keep it for six months after processing ends.
- Run a DPIA for large-scale processing, access decisions and genetic or biometric identification.
- Restrict access by purpose, require phishing-resistant MFA for staff and step-up for sensitive exports.
- Give every pipeline its own scoped non-human identity and include it in quarterly reviews.
- Enable record-level access logging and alerts on bulk reads for every labelled store.
- Remove unmasked special category data from non-production environments.
Standards and references
- GDPR: Article 9, Processing of special categories of personal data
- UK legislation: Data Protection Act 2018, Schedule 1 Part 4, Appropriate policy document
- ICO: What is special category data?
- ICO: What are the rules on special category data?
- ICO: What are the conditions for processing?
- Court of Justice of the EU: Case C-184/20, OT v Vyriausioji tarnybinės etikos komisija
- Court of Justice of the EU: Case C-21/23, Lindenapotheke
- ICO: 23andMe fined for failing to protect UK users' genetic data
This guide summarises the special category data rules in the EU GDPR and the UK GDPR with the Data Protection Act 2018 and is not legal advice. Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · Biometric Data in the Workplace · Health Data Privacy Beyond HIPAA Guide (My Health My Data) · Data Loss Prevention (DLP) Guide