GDPR distinguishes between personal data and a small category of data so sensitive that it receives a separate, stricter regime: special category data under Article 9. The problem for SaaS founders is that many products touch special category data without realising it — and the compliance consequences of getting it wrong are severe.
What Counts as Special Category Data?
Article 9(1) GDPR lists eight categories of data for which processing is prohibited unless an explicit exemption applies:
| Category | SaaS Examples | Often Overlooked? |
|---|---|---|
| Health / medical data | Healthcare apps, fitness trackers, mental health tools, HR absence management, employee wellness surveys | ✅ Usually recognised |
| Biometric data (used to uniquely identify a person) | Face recognition login, fingerprint authentication, voice recognition, liveness detection | ⚠️ Often missed — only biometrics USED FOR identification qualify; photo alone ≠ biometric |
| Genetic data | Genealogy platforms, clinical research tools, rare disease apps | ✅ Usually recognised in scope |
| Racial or ethnic origin | DEI analytics tools, age/race-based audience targeting, image analysis tools that infer ethnicity | ⚠️ Often missed in DEI analytics products |
| Political opinions | Political polling tools, social listening platforms that categorise political sentiment, CRM platforms that track donation history | ⚠️ Often missed in B2B analytics tools |
| Religious or philosophical beliefs | Faith-based apps, tools collecting church attendance, philosophical belief surveys | ⚠️ Rare but easily overlooked |
| Trade union membership | HR platforms, workplace analytics tools, employment background check services | ⚠️ Often missed in HR SaaS |
| Sex life or sexual orientation | Dating apps, LGBTQ+ specific platforms, health apps that track sexual health | ✅ Usually recognised in scope |
| Criminal convictions and offences data (Art. 10) | Background check services, HR platforms, tenancy management | ⚠️ Art. 10 — separate provision, similar restrictions |
Critical edge case — inferred special category data: You may be processing special category data even if you didn't ask for it directly. A mental health app that analyses chat messages to detect depression is processing health data. An analytics tool that infers political opinions from browsing patterns is processing political opinion data. A DEI platform that asks about "gender identity" is likely processing data on sexual orientation. The category is defined by the nature of the data, not how it was collected.
Why Article 9 Matters More Than Article 6
For regular personal data, Article 6 provides six legal bases — including legitimate interests. For special category data, Article 9(1) imposes a blanket prohibition on processing unless one of ten explicit conditions in Art. 9(2) applies. You cannot rely on legitimate interests alone.
| Art. 9(2) Condition | When It Applies to SaaS | Practical Notes |
|---|---|---|
| (a) Explicit consent | Most consumer SaaS | Higher standard than regular consent — must be explicit (no pre-ticked boxes, no ambiguous wording), specific to the processing, and freely given (power imbalance problem for employees) |
| (b) Employment / social security obligations | HR SaaS used by employers under national law | Only covers processing required by labour law — not HR analytics generally |
| (c) Vital interests | Emergency healthcare, life-or-death situations | Very narrow — courts interpret strictly |
| (d) Legitimate activities of non-profits | Religious, political, trade union membership organisations | Only for members/associates; no disclosure without consent |
| (e) Manifestly public data | Research tools scraping publicly disclosed data | Very narrow — data must have been made public by the data subject deliberately |
| (f) Legal claims | Legal tech tools, court record systems | For establishment, exercise, or defence of legal claims |
| (g) Substantial public interest | Government-adjacent SaaS, public health research platforms | Must be specified in EU or member state law; not a general public good exception |
| (h) Health / social care (under professional secrecy) | Clinical software, healthcare provider tools | Requires a healthcare professional or someone under equivalent secrecy obligation |
| (i) Public health | Epidemiological tools, contact tracing | Must be covered by specific member state law; GDPR Art. 9(3) |
| (j) Archiving / research / statistics | Academic research tools, longitudinal data platforms | Subject to Art. 89 safeguards; pseudonymisation typically required |
What You Must Do Differently When Processing Special Category Data
1. Conduct a DPIA (GDPR Art. 35)
Processing special category data on a large scale is one of the EDPB's nine criteria that make a DPIA mandatory. For most SaaS products handling health, biometric, or other special category data, you need a DPIA before you start processing.
The DPIA must cover: purpose and description of processing, necessity and proportionality assessment, risk to data subjects (with residual risk after safeguards), and DPA consultation if risk remains high after safeguards.
2. Appoint a DPO (Possibly)
Art. 37(1)(c) requires a DPO when core activities involve "large-scale processing" of special category data. There's no numeric threshold for "large scale" — the EDPB uses factors like number of individuals, geographic scope, duration, and scope of processing. A regional mental health SaaS serving 10,000 users likely requires a DPO. A small internal employee wellness tool serving 50 staff probably doesn't — but document your reasoning.
3. Tighten Your Legal Basis Documentation
For each special category data processing activity, document in your RoPA:
- The specific Art. 9(2) condition relied upon
- The Art. 6(1) lawful basis (both are required — Art. 9(2) is an additional condition, not a standalone basis)
- For explicit consent: how you obtain, record, and enable withdrawal
4. Implement Enhanced Technical Safeguards
Art. 9 processing should receive additional security measures proportionate to the sensitivity:
- Encryption: health data should be encrypted not just at rest and in transit, but field-level encryption for the most sensitive records
- Access controls: least privilege strictly enforced — only clinical/relevant staff can see health records
- Pseudonymisation: separate identifiers from health data where architecturally possible
- Data minimisation: collect only the minimum special category data necessary for the specific purpose
- Audit logging: comprehensive audit trail of who accessed special category data and when
- Retention: shorter retention periods than for ordinary personal data; strict deletion schedules
5. Update Your Privacy Policy and Data Collection Notices
Art. 13/14 transparency obligations apply with extra urgency to special category data. Your privacy policy must explicitly identify the special category data you process and the specific Art. 9(2) condition relied upon. For explicit consent, the consent mechanism must clearly identify the special category nature of the data.
6. Special Category Data in Sub-Processors
When special category data flows to sub-processors (cloud infrastructure, analytics, AI models), those data processors face the same Art. 9 obligations. Your DPA must explicitly address special category data. Check that your cloud provider's terms of service and DPA specifically cover the special category data you're sending them.
Critically: OpenAI, Anthropic, and other AI model APIs are sub-processors if you send them special category data for processing. Their standard API terms may not provide adequate protection for health or biometric data. Review carefully before building features that pass special category data to AI APIs.
Five Common SaaS Traps with Special Category Data
- DEI analytics tools inferring race/ethnicity: If your platform infers demographic characteristics from names, photos, or language patterns, you may be processing racial/ethnic origin data even if you never ask for it directly.
- Mental health / wellbeing features in HR SaaS: "Mood tracking" features in workplace tools often process data revealing mental health — health data under Art. 9. The employment context makes valid consent near-impossible (power imbalance). You likely need Art. 9(2)(b) — statutory basis — which may not exist for your use case.
- AI models trained on customer data containing special categories: If customers upload documents, messages, or files that contain health data and you use that data to train/fine-tune AI models, you need an explicit Art. 9(2) basis for the training — often absent from standard terms.
- Biometric login features: Face ID or fingerprint authentication that you process server-side (not device-local) creates Art. 9 biometric data. Device-local biometric processing (Apple Face ID) is not your processing — the device processes it.
- User-generated content with health data: A community platform, forum, or ticketing tool where users freely share health information doesn't automatically get an Art. 9 exemption just because users volunteered it. Art. 9(2)(e) (manifestly made public) applies only when the data subject clearly intended to make the data public.
Build Your GDPR Compliance Stack for Special Category Data
- DPIA Template Generator — mandatory for large-scale special category processing
- Privacy Policy Generator — includes special category disclosure and Art. 9 basis
- GDPR RoPA Generator — document special category data activities with Art. 9(2) basis
- Information Security Policy Generator — enhanced safeguards for sensitive data
- Sub-Processor List Generator — track which processors receive special category data
- GDPR DPA Generator — Art. 28 DPA with special category data provisions
- GDPR Data Subject Rights Guide — special rights for sensitive data
- DPIA Guide for SaaS Founders
⚠️ This article is for informational purposes only and does not constitute legal advice. GDPR Article 9 interpretation, national law derogations, and enforcement vary significantly by member state. Consult qualified legal counsel before processing special category data, particularly in healthcare, HR, or AI contexts.