Article 9: Processing of special categories of personal data

GDPR Article 9 means you must treat “special categories” of personal data as prohibited by default and only process it when you can document a valid exception, then implement tighter controls across collection, access, sharing, and retention. Operationally, you need a clear inventory of where this data exists, a decision record for the Article 9 condition you rely on, and ongoing evidence that controls run. ¹

Key takeaways:

• Special category data is “no” by default; “yes” requires a documented exception and governance. ¹
• Your fastest path to defensibility is an Article 9 register tied to systems, use cases, owners, and approvals. ²
• Audits focus on operational proof: intake gates, access controls, sharing rules, and records that show decisions and execution. ²

Article 9 is one of the highest-friction GDPR requirements in day-to-day operations because “special categories of personal data” show up in more places than teams expect: HR files, benefits workflows, workplace accommodations, customer support notes, identity verification, background checks, and even analytics events (for example, “health condition” in a free-text field). The rule forces a default prohibition posture, so a CCO or GRC lead needs two things: (1) certainty about where special category data enters and moves through the organization, and (2) a repeatable method to approve, restrict, and evidence any processing that must continue.

This page is written for operators who need to implement controls quickly without getting stuck in legal abstractions. You will build an Article 9 “role-and-scope” register (controller vs. processor, data categories, systems, third parties), define a requirement-specific operating procedure (intake triggers, approvals, control requirements), and retain evidence packets that map each use case to a documented condition and the controls that enforce it. ²

Regulatory text

GDPR Article 9(1) excerpt: Processing personal data that reveals racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, and processing of genetic data, biometric data for uniquely identifying a person, health data, or data about sex life or sexual orientation “shall be prohibited.” ¹

Operator meaning (requirement-level):

• Treat special category data as prohibited by default in your data governance and system design. ¹
• If the business claims it “needs” this data, force a formal decision: where it appears, why it is necessary, who owns it, what systems process it, which third parties touch it, and what controls apply. ²
• Prove the decision was executed through technical and procedural controls plus retained evidence (not just a policy statement). ²

Practical note: Article 9(1) provides the prohibition baseline. The operational pattern you need is “deny unless explicitly approved,” with auditable approvals and guardrails.

Plain-English interpretation

Article 9 requires you to run special category data through a higher bar than normal personal data. In practice, that means:

• Stop accidental collection. Remove fields, block free-text capture, and prevent special-category tags from entering systems without intent.
• Contain what you must keep. If a workflow genuinely requires special category data, restrict access to a small set of roles, separate storage where feasible, and tighten sharing rules with third parties.
• Document and prove. Regulators and auditors don’t accept “we don’t process that” without evidence, and they don’t accept “we have a policy” without operational controls and records. ²

Who it applies to (entity and operational context)

Entities: Any organization subject to GDPR that acts as a controller or processor and handles EU personal data. ²

Operational contexts where Article 9 commonly triggers:

• HR and benefits: medical notes, disability accommodations, union membership indicators, leave documentation.
• Identity and access: biometric authentication, identity verification datasets, facial recognition.
• Customer support and case management: sensitive facts in tickets, attachments, chat transcripts.
• Healthcare-adjacent services: wellness programs, insurance-related workflows, occupational health.
• Security and fraud: watchlists and investigations that may imply political opinions or religious beliefs via contextual notes.
• Third parties: background check providers, benefits administrators, occupational health vendors, KYC/IDV providers, support platforms. ²

Role sensitivity (controller vs. processor):

• As a controller, you own the decision to process and the business purpose.
• As a processor, you must follow controller instructions and still need internal controls to prevent unauthorized or out-of-scope processing.
  Either way, you need clarity and evidence on scope. ²

What you actually need to do (step-by-step)

Step 1: Build an Article 9 data map (scope register)

Create a register that is specific to Article 9, not a generic RoPA substitute. Minimum columns:

• Processing role (controller/processor)
• Special category type (race/ethnicity, political opinions, religion/philosophy, union membership, genetic, biometric for unique ID, health, sex life/sexual orientation) ¹
• Use case / business process
• System(s) of record + data stores + logs
• Data entry points (forms, imports, APIs, free text, attachments)
• Internal owner (business) + control owner (security/IT)
• Third parties involved + contract pointer
• Retention location and deletion method
• Approval status + review date

Execution tip: Start with systems most likely to contain attachments and free text (support desk, HR case tools, CRM notes). Those are the fastest sources of accidental special-category collection.

Step 2: Implement an intake gate for new or changed processing

Establish a requirement-specific operating procedure with explicit trigger events:

• New product feature that captures user attributes
• New HR or benefits workflow
• New biometric/authentication method
• New third party onboarding touching identity, HR, or support
• New analytics event or data warehouse ingestion

Gate questions (make them mandatory in your change process):

1. Does this collect or infer any Article 9 category? ¹
2. Where is it stored and who can access it?
3. Which third parties receive it?
4. What controls prevent accidental entry and limit access?
5. What is the approval record and owner sign-off?

Step 3: Reduce collection by design (default deny)

Controls that operationalize “prohibited”:

• Remove optional demographic fields unless explicitly approved.
• Block or warn on free-text entry for sensitive terms in high-risk systems (support, HR case tools). Treat this as risk reduction, not perfect detection.
• Configure attachment handling: limit file types, restrict sharing links, apply stricter permissions.
• For biometrics: confirm the data is actually used “for uniquely identifying” a person, because that is expressly in scope. ¹

Step 4: Contain and control access

Implement and evidence:

• Role-based access control for any system storing special category data, with least privilege.
• Additional approval for access grants (ticket-based approval with named approver).
• Segregation: separate storage or dedicated workspace where feasible.
• Logging: access logs for high-risk repositories, plus periodic reviews tied to the register.

Step 5: Manage third parties explicitly

For each third party in the Article 9 register:

• Confirm role allocation (processor vs. controller relationship for that processing).
• Ensure contractual and operational alignment to your approved scope and restrictions (data sharing limitations, retention expectations, incident handling).
• Require the third party to identify where special category data is stored and who can access it, then reconcile against your register.

Daydream fit (earned mention): Many teams lose time reconciling “what we think we send” versus “what third parties actually process.” Daydream can centralize the Article 9 register and attach evidence packets (approvals, data maps, third-party confirmations) to each use case so reviews stop relying on inbox archaeology.

Step 6: Retention and deletion you can prove

For each system in scope:

• Define retention logic for the special category element (not just the overall record).
• Implement deletion workflows (manual or automated) and record the outcome.
• Treat backups and exports as in-scope locations; document how deletion requests and retention policies apply there in practice.

Step 7: Evidence cadence (operationalize “show me”)

Pick a recurring cadence that matches your change velocity, then capture evidence packets:

• Updated Article 9 scope register export
• Sample of approved intake decisions and the matching change tickets
• Access review outputs for scoped systems
• Third-party due diligence evidence for scoped processors
• Exceptions log and remediation status

Required evidence and artifacts to retain

Keep artifacts organized by use case and system:

• Article 9 role-and-scope register (current + prior versions)
• Data flow diagram or data map excerpt for each in-scope workflow
• Approval records for each Article 9 in-scope processing activity (decision record with owner)
• System configuration screenshots/exports (permissions, field settings, sharing controls)
• Access request tickets and approvals
• Audit logs or reports showing access and administrative changes
• Third-party records: data processing scope confirmations and contract pointers
• Exceptions register: what deviated, who approved, compensating controls, closure evidence ²

Common exam/audit questions and hangups

Expect reviewers to ask:

• “List all systems where you process Article 9 data and show owners.”
• “Show how you prevent accidental capture in support tickets/CRM notes/attachments.”
• “Who has access today, and how do you review access?”
• “Which third parties receive it, and how do you control onward sharing?”
• “Show evidence of an approval workflow for a new data element or feature.”
  Hangup: teams answer with policy excerpts instead of system-level proof. Auditors will push for tickets, logs, and configuration evidence. ²

Frequent implementation mistakes (and how to avoid them)

1. Relying on a generic data classification policy. Fix: create an Article 9-specific register tied to real systems and owners.
2. Ignoring unstructured data. Fix: treat free text and attachments as primary risk; implement containment and access controls there first.
3. Assuming “we don’t ask for it” equals “we don’t have it.” Fix: perform targeted searches and sampling in HR and support systems; document results and remediation actions.
4. Third-party blind spots. Fix: reconcile data sharing paths and require explicit third-party confirmation of processing scope and storage locations.
5. No evidence trail. Fix: build evidence packets into the operating procedure so each approval automatically produces audit-ready artifacts. ²

Enforcement context and risk implications

No enforcement case sources were provided in the material for this page, so this guidance stays grounded in the Article 9 prohibition language and standard audit expectations under GDPR. The practical risk is consistent: special category data increases regulatory exposure because unauthorized or uncontrolled processing contradicts the “prohibited” baseline. ¹

Practical 30/60/90-day execution plan

Numeric timelines are avoided here; use phases to match your delivery capacity.

Immediate phase (stabilize and stop new risk)

• Appoint an Article 9 control owner and require intake gating for new processing.
• Stand up the Article 9 role-and-scope register with your known high-risk systems (HR, support, identity).
• Implement quick containment: restrict access groups; lock down attachments and sharing where possible.

Near-term phase (make it repeatable)

• Expand discovery to additional systems (CRM, analytics pipelines, data warehouse).
• Operationalize the procedure: add mandatory questions to change tickets and third-party onboarding.
• Establish evidence packets and store them centrally by use case.

Ongoing phase (prove operation)

• Run recurring access reviews for in-scope systems and retain outputs.
• Reconcile third-party processing annually or on material change.
• Track exceptions and remediation to closure with owner accountability. ²

Frequently Asked Questions

Does Article 9 mean we can never process health or biometric data?

Article 9(1) sets a prohibition baseline for special categories of personal data. If your organization processes any of these categories, treat it as an exception-driven workflow that requires explicit approval, tight access controls, and auditable evidence. ¹

What counts as “biometric data” under this requirement?

Article 9(1) calls out biometric data “for the purpose of uniquely identifying a natural person.” Treat authentication methods like facial recognition or fingerprint-based identification as in scope and route them through your Article 9 intake gate. ¹

Our support team sometimes receives medical documents in attachments. What should we do first?

Start by restricting access to the ticket queue and attachments, then add operational controls that discourage or block sensitive uploads where feasible. Document the workflow in your Article 9 register and retain evidence of the configuration and access reviews. ²

How do we operationalize Article 9 for third parties?

Identify every third party that receives or can access special category data, confirm the processing role and scope, and tie the relationship to your Article 9 register. Keep contractual pointers and the third party’s scope confirmation in your evidence packet. ²

What evidence is most persuasive in an audit?

Auditors typically want to see that you know where the data is, who can access it, and how changes are approved. Change tickets, access approval records, system permission exports, and register history usually carry more weight than narrative policy statements. ²

Can we store special category data in our data warehouse for analytics?

Treat the data warehouse as a high-risk multiplier because it broadens access and reuse. If you keep special category data there, document the specific use case, restrict access sharply, and ensure retention and deletion controls apply to downstream tables and extracts. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 9

2. Regulation (EU) 2016/679