You're evaluating how to classify and protect medical information in your data processing register. This decision is critical. Grindr recently agreed to a £26 million ($35.2 million) settlement over allegations it shared HIV status and other medical details with third parties. Your classification choice determines which controls you implement, which vendors you can use, and whether you're exposed to significant regulatory penalties.
The Decision You're Facing
Your organization processes health-related information. You need to determine whether to:
- Treat it as special category data requiring Article 9 GDPR controls
- Apply standard personal data protections under Article 6
- Implement sector-specific health data requirements (HIPAA, state privacy laws)
This isn't a legal interpretation exercise. It's a control design decision that shapes your vendor risk program, incident response procedures, and data processing register entries.
Key Factors That Affect Your Choice
Nature of the information: Does your system store explicit medical diagnoses, treatment records, or test results? Or does it collect proxy indicators like fitness tracker data or symptom searches? GDPR Article 9 covers "data concerning health," which the Article 29 Working Party defines as information related to physical or mental health, including service provision. That's broader than formal medical records.
Your lawful basis: Special category data requires both a lawful basis under Article 6 and a specific Article 9 condition. If you're relying on explicit consent, you need separate, granular consent for health data processing. If you're using legitimate interests for standard data, that won't work for special categories.
Third-party exposure: Review your data processing agreements. When Grindr allegedly shared HIV status with advertising partners, the issue wasn't just the sharing itself but the lack of adequate safeguards in those relationships. Your vendor risk profile requirements change significantly between standard and special category data.
Jurisdictional overlap: U.S. organizations face a patchwork. HIPAA applies to covered entities and business associates. State laws like California's CMIA impose separate health data restrictions. If you operate globally, GDPR's special category rules may be your highest bar.
Path A: Treat It as Special Category Data
Choose this path when:
- The information explicitly reveals health conditions, diagnoses, or treatment
- You process genetic or biometric data for health purposes
- Your data subjects reasonably expect health-level protection
- You operate in multiple jurisdictions and need a defensible global standard
Implementation requirements:
Start with your Data Processing Register. Create separate entries for special category processing. Document your Article 9 condition (explicit consent, substantial public interest, health/social care provision, etc.). You can't default to legitimate interests here.
Rebuild your Vendor Risk Profile template. Add mandatory controls: encryption at rest and in transit, separate logical segmentation for health data, prohibition on secondary use without explicit consent, and breach notification within 24 hours. Your vendor assessment questionnaire should verify ISO 27701 or equivalent privacy controls.
Update your Policy Exception Registry process. Standard data might allow time-limited exceptions for operational needs. Special category data requires executive sign-off and a documented necessity test. Your exceptions should be rare and auditable.
Implement enhanced Individual Rights procedures. Health data subjects often exercise access, rectification, and erasure rights more frequently. Your response workflow needs legal review checkpoints that standard data requests don't require.
When this becomes mandatory:
You don't have discretion if the data explicitly reveals health status. The Grindr case allegedly involved HIV status shared with third parties. That's unambiguously Article 9 data. If you're processing similar information and treating it as standard personal data, you're creating regulatory exposure.
Path B: Apply Standard Personal Data Controls
Choose this path when:
- The information relates to wellness or lifestyle, not medical conditions
- You're processing aggregated health statistics without individual identifiers
- Your lawful basis and purpose don't require health-level sensitivity
Implementation requirements:
Your Data Processing Register should still document the data category precisely. "User preferences" is too vague. "Dietary preferences and exercise goals" gives auditors clarity without triggering special category treatment.
Standard vendor due diligence applies: SOC 2 Type II reports, annual security assessments, contractual data protection terms. You don't need the enhanced health data restrictions, but you still need processor agreements that limit purpose and require security measures.
Your Ongoing Vendor Monitoring program should track security incidents and control changes quarterly. That's less intensive than the monthly reviews appropriate for special category processors.
The risk you're accepting:
Regulators might disagree with your classification. If your "wellness app" data could reasonably infer health conditions, you're vulnerable to enforcement action. The UK's Information Commissioner's Office has taken an expansive view of health data in recent cases.
Path C: Implement Sector-Specific Health Requirements
Choose this path when:
- You're a HIPAA covered entity or business associate
- State health privacy laws apply to your operations
- You operate in specialized health sectors with regulatory oversight
Implementation requirements:
HIPAA requires a risk analysis under the Security Rule. Your control baseline includes access controls (164.312(a)(1)), audit controls (164.312(b)), integrity controls (164.312(c)(1)), and transmission security (164.312(e)(1)). These are more prescriptive than GDPR's risk-based approach.
Your business associate agreements must flow down HIPAA obligations. Unlike GDPR's processor agreements, these create direct regulatory liability for your vendors. Your Vendor Risk Profile should verify they maintain their own HIPAA compliance programs.
State laws add complexity. California's CMIA restricts health information disclosure beyond what HIPAA requires. Massachusetts has separate data security regulations. Your compliance matrix needs jurisdiction-specific rows.
When both GDPR and HIPAA apply:
Implement the higher standard for each control area. GDPR's Individual Rights are broader than HIPAA's access rights. HIPAA's Security Rule is more prescriptive than GDPR's security requirements. Your control framework should satisfy both.
Summary Matrix
| Factor | Special Category (GDPR Art. 9) | Standard Personal Data | HIPAA/Sector-Specific |
|---|---|---|---|
| Lawful basis | Art. 6 basis + Art. 9 condition | Art. 6 basis only | HIPAA permits or state law |
| Vendor requirements | Enhanced DPA, monthly monitoring, prohibition on secondary use | Standard DPA, quarterly reviews | Business associate agreement, direct liability |
| Breach notification | 72 hours to SA, immediate to subjects if high risk | 72 hours to SA, case-by-case subject notification | 60 days to HHS and subjects, media if 500+ affected |
| Individual rights | Enhanced transparency, explicit consent for new purposes | Standard access/erasure/portability | Access and amendment rights, accounting of disclosures |
| Documentation | Separate register entries, DPIA for most processing | Standard register entries, DPIA for high-risk only | Risk analysis, policies and procedures, training records |
The £26 million Grindr settlement wasn't about technical security failures. It allegedly involved sharing sensitive medical information with third parties who shouldn't have received it. Your classification decision determines whether your contracts, controls, and vendor oversight would prevent similar exposure. Choose the path that matches your data's actual sensitivity, not the label that's easiest to implement.
