In February 2024, the UK Information Commissioner's Office issued enforcement notices against Serco Leisure and seven associated trusts for using fingerprint scanning and facial recognition on more than 2,000 employees at 38 leisure facilities. Serco couldn't demonstrate a lawful basis to process biometric data at Article 9's elevated standard and was ordered to stop all fingerprint processing and delete the data collected.
Your team may be in a similar position right now. Most organizations that discover they're processing special category data are already doing it: through sick-leave records, DEI surveys, security access systems, or health-plan enrollment. The question is whether you can satisfy the two-layer legal test Article 9 imposes, and whether the safeguards in place will hold up when regulators look. GDPR fines for Article 9 violations reach up to €20 million or 4% of global annual turnover, the same upper tier as the most serious substantive infringements.
TL;DR
- GDPR Article 9 prohibits processing eight categories of sensitive personal data (racial origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data used for identification, health data, and sexual orientation data) unless one of ten specific conditions is met.
- Processing special category data requires satisfying two separate legal tests simultaneously: a lawful basis under Article 6 and a separate condition under Article 9(2). Legitimate interests is a valid Article 6 basis but does not replace the Article 9(2) condition; both are required.
- Explicit consent, the condition most organizations reach for first, sets a higher bar than standard GDPR consent and is frequently the wrong choice for employment contexts where employee consent is rarely free.
- Health data in employment, biometric data for access control, and DEI survey responses involving racial or ethnic origin are the three scenarios where Article 9 violations most often occur.
- A DPIA is mandatory whenever special category data is processed at large scale or combined with systematic monitoring.
The Eight Special Categories
GDPR Article 9(1) prohibits, as a default, the processing of personal data revealing:
- Racial or ethnic origin — includes country of origin where it implies ethnicity, and photographs used to extract race as an inference.
- Political opinions — beliefs, party membership, voting behavior.
- Religious or philosophical beliefs — church membership, dietary requirements that signal faith, absence records tied to religious observance.
- Trade union membership — payroll deductions to unions, strike participation records, collective bargaining contact databases.
- Genetic data — data derived from biological analysis uniquely identifying a person or their biological relatives.
- Biometric data processed for the purpose of uniquely identifying a natural person — fingerprints, facial geometry, voice prints used for authentication or access control. Not all biometric data triggers Article 9: a photograph taken for an ID badge doesn't automatically become special category data unless the image is processed through a recognition system.
- Health data — any information about a person's physical or mental health, past, present, or future. Sick-leave records, disability status, prescription data, and occupational health reports all qualify, even if a doctor isn't involved.
- Data concerning a natural person's sex life or sexual orientation — the category with the narrowest practical footprint in most organizations, but it surfaces in benefits enrollment (same-sex partner coverage), background checks, and certain HR records.
The Two-Layer Requirement
Article 9 imposes a rule that catches many compliance teams off guard: meeting it requires satisfying two separate legal requirements, not just one.
Layer 1: Article 6 lawful basis. You need one of the standard six lawful bases (consent, contract, legal obligation, vital interests, public task, or legitimate interests). This is the same requirement that applies to all GDPR processing.
Layer 2: Article 9(2) condition. In addition to the Article 6 basis, you must identify one of the ten specific conditions that lifts the Article 9(1) prohibition. The Article 9(2) condition is not an alternative to the Article 6 basis. Both are required simultaneously.
The practical consequence: legitimate interests under Article 6(1)(f) does not justify Article 9 processing on its own. An organization relying on legitimate interests as its Article 6 basis still needs to identify an applicable Article 9(2) condition, most commonly Article 9(2)(b) (employment law obligations) or Article 9(2)(g) (substantial public interest). Treating legitimate interests as if it does double duty is one of the most common Article 9 compliance gaps regulators find.
The Ten Conditions Under Article 9(2)
(a) Explicit consent
The person has given explicit consent to the specific processing for a specific purpose. "Explicit" is a higher standard than standard consent under Article 6(1)(a): it requires a clear, affirmative statement (not a checkbox bundled with terms), unambiguous about the specific categories being processed.
Explicit consent is generally not appropriate in employment contexts because employees cannot freely withhold consent from their employer without real or perceived consequence. The EDPB and most national DPAs have consistently held that employee consent is rarely "freely given" under GDPR. If your organization relies on explicit consent from employees for processing their biometric or health data, that basis will not survive regulatory scrutiny.
(b) Employment, social security, and social protection law
Processing is necessary for the performance of obligations or the exercise of specific rights in the field of employment, social security, or social protection law, insofar as authorized by union or member state law with appropriate safeguards.
This is the most practically important condition for employers. It covers: mandatory occupational health assessments, sick leave records maintained to administer statutory sick pay, disability accommodations required under employment law, and screening required by regulation (such as DBS checks in the UK). The catch: it must be authorized by applicable law, not merely convenient for the employer. Many employers misuse this condition for processing that serves administrative preference rather than a legal obligation.
(c) Vital interests
Processing is necessary to protect the vital interests of the data subject or another person where the data subject is physically or legally incapable of giving consent. This is narrowly scoped to genuine emergencies (unconscious patients, natural disasters) and does not cover routine processing of a vulnerable person's data.
(d) Legitimate activities of not-for-profit bodies
Processing by political, philosophical, religious, or trade-union-purpose organizations with appropriate safeguards, where the processing relates to members or former members and the data is not disclosed outside the organization without consent.
(e) Data manifestly made public by the data subject
If the person has put the data into the public domain themselves (a politician's public statement about their health, a public figure's published religious memoir), that specific data point can be processed. The "manifestly made public" standard is strict: something appearing in a data leak, court record, or third-party article does not qualify unless the subject themselves made it public.
(f) Legal claims and judicial proceedings
Processing necessary for the establishment, exercise, or defense of legal claims, or whenever courts are acting in their judicial capacity. This covers both active litigation and pre-litigation document retention for anticipated claims.
(g) Substantial public interest
Processing necessary for reasons of substantial public interest, on the basis of union or member state law, proportionate to the aim pursued and respectful of the essence of the right to data protection. Member states vary in implementation: the UK Schedule 1 of the Data Protection Act 2018 lists 23 categories of substantial public interest processing.
(h) Health and social care
Processing necessary for preventive or occupational medicine, medical diagnosis, health or social care, or management of health or social care systems, under EU or member state law, by a health professional or another person subject to a professional secrecy obligation.
This is the primary condition for clinical and public health processing. The Swedish DPA's EUR 12 million fine against a healthcare provider in 2024 for processing patient data without adequate consent mechanisms shows the enforcement exposure is real.
(i) Public health
Processing necessary for reasons of public health (disease monitoring, cross-border health threats, medicinal product safety) under EU or member state law with appropriate safeguards.
(j) Archiving, research, and statistics
Processing for archiving in the public interest, scientific or historical research, or statistical purposes, subject to the safeguards and conditions in Article 89(1). The EDPB's April 2026 draft Guidelines 1/2026 on scientific research clarify that reliance on this condition for health data in research also requires compliance with the European Health Data Space Regulation (EHDS) where applicable.
A note on criminal conviction and offenses data
Criminal convictions, offenses, and related security measures are not listed in Article 9 but are subject to similarly elevated restrictions under Article 10. Processing this data can only be carried out under the control of official authority or when authorized by member state law. Organizations running background checks that include criminal record information often need to comply with both Article 9 (if health-related criminal data is returned) and Article 10 for the criminal record itself. Treat Article 10 data with the same operational care as Article 9 data: it requires explicit national law authorization, and general legitimate interests is not a sufficient basis.
Article 9(2) Conditions at a Glance
| Condition | What it covers | Most common use cases | Key limitation |
|---|---|---|---|
| (a) Explicit consent | Freely given, specific, unambiguous consent | Public-facing health apps, research with volunteers | Rarely valid for employees |
| (b) Employment law | Processing required by employment or social security law | Sick leave records, occupational health, DBS checks | Must be required by law, not just convenient |
| (c) Vital interests | Emergency protection of life | Medical emergencies, disaster response | Only when consent is impossible |
| (d) Not-for-profit bodies | Member-related processing by political/religious/union orgs | Church membership records, union contact databases | Cannot disclose outside org without consent |
| (e) Publicly disclosed | Data the subject made publicly available themselves | Politician's public health statements | Third-party disclosure doesn't count |
| (f) Legal claims | Establishment, exercise, or defense of legal claims | Litigation hold, workplace investigation records | Must be necessary, not precautionary |
| (g) Substantial public interest | Broad category defined by member state law | DEI monitoring (where authorized), fraud prevention | Requires a specific legal basis in national law |
| (h) Health and social care | Clinical care and health system management | Patient records, occupational medicine, social care | Must involve a professional with a secrecy obligation |
| (i) Public health | Disease control, medicinal safety monitoring | Epidemiological surveillance, pharmacovigilance | Requires a specific legal basis |
| (j) Research and archiving | Scientific, historical, statistical purposes | Academic research, public interest archiving | Article 89 safeguards apply |
Scenarios Where Article 9 Most Often Goes Wrong
Biometric access control and attendance monitoring
Fingerprint scanners and facial recognition for physical access control or time-and-attendance monitoring are Article 9 special category processing because they use biometric data to uniquely identify individuals. This is the scenario most organizations get wrong.
The typical compliance failure: the organization treats the biometric system as a purely technical matter (procured by IT, not flagged to the privacy team), relies on implicit or bundled employee consent that wouldn't survive the "freely given" test, and has no DPIA. The Dutch DPA's €725,000 fine against a company for fingerprint attendance monitoring (where employees had no real choice about participation) illustrates this failure pattern precisely.
The correct path: unless a member state law specifically authorizes biometric workplace processing (some do, with conditions), explicit consent is rarely viable. The more defensible routes are Article 9(2)(b) where a legal obligation requires identity verification, or Article 9(2)(g) where substantial public interest is established by applicable law. Both are narrower than most IT procurement teams assume. If the same access-control function can be achieved with an ID card or fob, regulators will ask why biometrics were necessary. The Serco enforcement notices are explicit on this point.
Before deploying any biometric system in a workplace context, a data protection impact assessment is mandatory under Article 35. Systematic and large-scale processing of biometric data is one of the EDPB's nine processing types that always requires one.
Health data in employment
Every employer processes health data to some extent: absence management, sick pay calculation, occupational health referrals, disability accommodation requests, health insurance enrollment. The practical issue is that the employer-employee relationship that makes consent unreliable also limits Article 9(2)(b) to processing actually required by employment or social security law, not just HR practices the employer finds convenient.
Three failure patterns appear repeatedly in enforcement actions:
Overreach in occupational health records. Employers often collect more medical detail than is necessary for the accommodation or absence management purpose. An occupational health report summarizing fitness for work (with no underlying diagnosis) serves the Article 9(2)(b) purpose; retaining the employee's full medical history from their GP does not.
Bundled health consent in benefits enrollment. Italian Garante's EUR 1.5 million fine against a health app for bundling consent to process health data with consent to receive marketing demonstrates how the explicit consent standard works: each purpose needs separate, specific agreement. HR systems that collect health information during benefits sign-up and apply a single consent tick-box are structurally non-compliant.
Post-employment retention. Health data collected for a specific employment purpose (sick leave, occupational health) must be deleted or anonymized when it no longer serves that purpose. Organizations that retain it in HR systems as a general employee record after the purpose expires breach both Article 9 and the storage limitation principle.
DEI surveys and racial or ethnic origin data
Diversity, equity, and inclusion surveys often collect data on racial or ethnic origin, disability status, and religious beliefs: multiple Article 9 categories in a single form. Making such surveys "voluntary" doesn't automatically make participation freely consensual under GDPR, particularly when employees perceive implicit pressure to complete them.
The most defensible basis for DEI surveys is typically Article 9(2)(g) (substantial public interest) combined with an applicable member state derogation, and many EU countries have enacted employment equality monitoring exceptions. Where a legal basis exists, Article 89's safeguards (pseudonymization, aggregation before reporting, access restrictions) apply. Where one doesn't, explicit consent under Article 9(2)(a) is the fallback, but the freely-given requirement means individual respondents must be able to decline without consequence.
A practical safeguard: design DEI surveys to aggregate at reporting, not at collection. If individual responses can never be disaggregated to an identifiable person, GDPR may not apply to the aggregated output at all.
Trade union membership in payroll
Payroll systems that process union deductions necessarily record trade union membership, a special category regardless of whether that's the intended purpose. Article 9(2)(b) covers this where the deduction is required or permitted by applicable employment or collective agreement law. The gap most often seen: payroll vendors who add this data to broader HR analytics or employee profiling without the employer flagging that the union membership field is special category data under Article 9.
DPIA Triggers for Special Category Processing
A data protection impact assessment is mandatory under Article 35 whenever special category data is processed and one or more of the following conditions apply:
- Systematic and large-scale processing of Article 9 data (the EDPB's nine high-risk processing types include this explicitly)
- Systematic monitoring of publicly accessible areas combined with special category data
- New biometric systems for authentication or access control in any context involving employees or the public
- Combined datasets that create a risk of re-identification when Article 9 data is merged with other personal data
- Cross-border transfer of special category data to third countries without an adequacy decision
The "large scale" threshold has no numerical definition in the GDPR, but the EDPB factors include: the number of individuals affected (as a proportion of the relevant population, not an absolute count), the geographic scope, the duration and persistence of the processing, and the extent of the processing.
Even when a DPIA isn't strictly mandatory, processing special category data without one is a judgment call that regulators regularly second-guess. The cost of a DPIA is low relative to the cost of an enforcement investigation.
Technical and Organizational Safeguards Required
Article 9 doesn't prescribe specific technical controls, but it requires processing to be "necessary" and "appropriate safeguards" to be in place. Enforcement decisions and EDPB guidance make clear what "appropriate" means in practice.
Data minimization is non-negotiable. Collect the minimum Article 9 data required for the specific purpose. If occupational health advice can be expressed as "fit to work with adjustments" rather than as a clinical diagnosis, collect the former. If DEI monitoring can be done with aggregated categories rather than individual responses, do that.
Pseudonymization before aggregation. For analytics, research, and monitoring use cases, pseudonymize Article 9 data at collection and remove the pseudonym key before analysis wherever possible. The EDPB's April 2026 research guidelines specifically endorse pseudonymization as the baseline safeguard for health data in research.
Access controls proportional to sensitivity. Special category data should be accessible only to personnel with a specific need and a specific authority. A general "HR role" access permission for a system containing health data and biometric data doesn't meet the proportionality standard. The access scope should map to the processing purpose, not the job title.
Retention schedules enforced, not just defined. Retention limits for Article 9 data must be operationally enforced. A retention policy that says "delete after employment ends" and a system that retains health data in HR records for years afterward is a compliance failure, not a policy success.
Encryption and transfer controls for biometric and health data. Biometric templates and health records should be encrypted at rest and in transit, with access logs retained. Where Article 9 data is shared with processors, the data processing agreements must explicitly address the special category nature of the data and require equivalent safeguards downstream.
If your organization needs a structured way to document Article 9 conditions, run DPIAs, and track processor safeguards across your full processing inventory, Secure Privacy's Privacy & AI Governance Platform covers each of these steps in a single workflow.
How Secure Privacy Supports Article 9 Compliance
Managing Article 9 data compliantly across an organization's processing activities is an operational challenge as much as a legal one. The same data types (health records, biometric identifiers, DEI survey responses) appear in HR systems, CRMs, health platforms, vendor stacks, and internal tools, often without the privacy team knowing they're there.
Secure Privacy's Privacy & AI Governance Platform provides the infrastructure for systematic Article 9 management:
Data Map and Records of Processing Activities (RoPA): Inventorying where Article 9 data exists across your systems is the prerequisite for everything else. The platform's Data Map function documents processing activities by purpose, legal basis, and data category, flagging Article 9 categories distinctly and surfacing where Article 9 data is being processed without a documented condition.
Assessments, DPIAs, and Risk Management: For the mandatory DPIA step, the platform provides structured assessment workflows tied to GDPR Article 35 requirements. Assessment outputs document the Article 9 conditions identified, the safeguards applied, and the residual risk determination, producing the kind of documented record that regulators look for when an enforcement investigation starts.
DSAR Handling: Article 9 data is frequently in scope for data subject access requests, and the right to erasure under Article 17 applies to it too. The platform's DSAR module automates the identification and export of special category data responsive to a request and tracks the deadline from receipt to response.
Vendor Management: Third-party processors that handle your Article 9 data need contractual safeguards that go beyond a standard DPA. The specific categories of data, the specific Article 9 conditions, and the specific technical safeguards must be documented in the agreement. The Vendor Management module maintains processor records, tracks DPA status, and flags processors receiving Article 9 data.
Frequently Asked Questions
Does GDPR's Article 9 apply to health data collected from our own employees, not just patients?
Yes. "Health data" under GDPR includes any information about a person's physical or mental health: absence records, fitness-for-work reports, disability accommodations, and health insurance enrollment all qualify, regardless of whether a medical professional is involved. The employment context doesn't remove the special category status; it affects which Article 9(2) condition applies (most commonly Article 9(2)(b) for data required by employment law).
Is a photograph of an employee Article 9 biometric data?
Not automatically. A photograph is biometric data under Article 9 only when it is "processed through specific technical means allowing the unique identification or authentication of a natural person." A headshot in an employee directory is not Article 9 processing. The same photograph run through facial recognition software to verify identity at building access is Article 9 processing.
Can we rely on legitimate interests to process special category data?
Legitimate interests (Article 6(1)(f)) is a valid Article 6 lawful basis that can sit alongside an Article 9(2) condition. But legitimate interests does not itself lift the Article 9 prohibition; it doesn't appear in Article 9(2)'s list of conditions. You still need to identify one of the ten Article 9(2) conditions separately. Some organizations mistakenly treat legitimate interests as if it substitutes for an Article 9 condition; it doesn't.
What happens if we're already processing Article 9 data without a proper basis?
Stop processing until a lawful basis and Article 9(2) condition have been identified and documented, or delete the data if no basis can be established. Continuing to process while conducting the analysis doesn't fix the compliance gap; it extends it. If the processing can't be made lawful, delete the data and assess whether affected individuals need to be notified. Regulators treat continued processing after discovering a gap more seriously than the original non-compliance.
How does Article 9 interact with the requirement to respond to a Subject Access Request?
Article 9 data is in scope for DSARs. When a data subject requests access to their personal data, special category data is included in what must be disclosed. The fact that it's sensitive doesn't create an exemption; it creates an obligation to handle the DSAR response with enhanced security (encrypted delivery, redaction where third parties are identifiable from the health record).
Does conducting a DEI survey require a DPIA?
A DPIA is mandatory if the survey systematically processes Article 9 data at large scale. For a global employer surveying tens of thousands of employees on race, religion, and disability, a DPIA is required before the survey launches. For a small team running a one-time voluntary survey with no data linked to individual identifiers, the DPIA obligation may not be triggered, but the Article 9 basis question still needs to be answered before data is collected.
What records do we need to maintain for Article 9 processing?
Your Records of Processing Activities (RoPA) under Article 30 must identify each processing activity involving Article 9 data, the specific Article 9(2) condition relied upon, the Article 6 lawful basis, the safeguards in place, and any transfers of that data to third parties. Where a DPIA was required, the DPIA documentation must be retained and updated when the processing changes materially. Supervisory authorities have the right to request these records; failure to produce them is itself an infraction independent of the underlying processing.
