These questions came up in our team channel after the ClarityCheck incident hit the news. A digital investigation service left 9,042,977 facial images, 450.2 gigabytes worth, in an unprotected database. Adults, teenagers, children. No password, no encryption. A researcher found it, reported it, and the company locked it down. No evidence anyone malicious got in, but the "what if" kept us up at night.
Your team's probably asking the same things ours did. Here's what we worked through.
Do Facial Images Count as Biometric Data Under GDPR?
Yes, but context matters.
Article 4(14) defines biometric data as personal data resulting from specific technical processing relating to physical, physiological, or behavioral characteristics that allow unique identification. A casual profile photo in your CRM? Probably not biometric data. That same photo run through facial recognition software to verify identity? Now it's biometric.
ClarityCheck was using reverse image search for identity verification. That processing crosses the line into Article 9 special category data territory. You're looking at the same heightened protection requirements as health records or genetic data.
If you're storing images and you're not sure whether your processing makes them biometric, ask: could this image be used to uniquely identify someone through technical means? If the answer's yes or maybe, treat it as special category data. The compliance burden's worth the certainty.
What's the Legal Basis for Processing Facial Images?
You've got limited options under Article 9(2), and none are easy.
Informed Consent works if you can prove it's freely given, specific, informed, and unambiguous. For a commercial service like identity verification, you'll need to demonstrate users genuinely had a choice and understood what they were consenting to. Document the consent mechanism, the exact wording, and how users can withdraw it.
Legitimate interests won't save you here. Article 9 doesn't include it as a lawful basis for special category data, even though it's available under Article 6. You can't balance your way into processing biometric data.
Some organizations try to argue substantial public interest under Article 9(2)(g), but you'll need a basis in EU or Member State law. "We think this makes the internet safer" doesn't cut it. You need statutory authorization.
The ClarityCheck database included children's images. If you're processing special category data about minors, your legal basis needs to account for their vulnerability. Consent from a 14-year-old for facial recognition processing? That's not going to meet the "freely given" test in most contexts.
What's the Timeline for Notifying a Breach?
You've got 72 hours from when you become aware of the breach to notify your Supervisory Authority under Article 33. "Aware" means when you have reasonable certainty a breach occurred, not when you've completed your full investigation.
The clock starts when you know. Not when legal approves the notification. Not when you finish your impact assessment. When you know.
Your notification needs to describe the nature of the breach, the categories and approximate number of data subjects affected, the categories and approximate number of records, and your contact details. In the ClarityCheck scenario, that's over 9 million images. If you can't provide exact numbers within 72 hours, give your best estimate and explain you'll update it.
Article 34 requires you to notify affected individuals without undue delay if the breach is likely to result in a high risk to their rights and freedoms. Exposed biometric data that could enable impersonation or identity theft? That's high risk. You're notifying individuals.
The only exception: if you've applied Technical and Organisational Measures that render the data unintelligible to unauthorized parties. Encryption would qualify. The ClarityCheck database had none.
How Do We Secure Biometric Databases?
Start with encryption at rest. Every biometric record should be encrypted using a key management system that separates encryption keys from the data. If someone gets database access, they get ciphertext.
Authentication and access controls come next. No database containing special category data should be accessible without authentication. Implement role-based access controls that limit who can query biometric records, and log every access attempt. Break-Glass Access procedures should exist for emergencies, but they should trigger immediate alerts.
Network segmentation matters. Your biometric database shouldn't sit on the same network segment as your general application infrastructure. Use firewalls and network policies to restrict which systems can even attempt connections.
Apply Column-Level Security if your database supports it. Even authenticated users shouldn't see biometric fields unless their role specifically requires it. A customer service rep looking up an account doesn't need to see facial images.
Regular access reviews catch credential creep. Every quarter, audit who has access to biometric data and why. Former employees, contractors who finished projects, developers who've moved teams, their access should be gone.
What If We Can't Prove Whether Anyone Accessed the Exposed Data?
You tell the Supervisory Authority exactly that.
The ClarityCheck researcher found no evidence of malicious access. That's not the same as proving no one accessed it. Your Article 33 notification should state what you know: the database was exposed, for how long, what monitoring or logging exists, and what that monitoring shows.
If you have no access logs because logging wasn't enabled, say so. The absence of evidence isn't evidence of absence, and trying to spin it that way will backfire when the Supervisory Authority asks for your log retention policies.
Document your investigation process. What systems did you check? What logs did you review? What forensic analysis did you conduct? If you brought in external incident response, include their findings.
The Supervisory Authority will want to know what measures you're implementing to prevent recurrence. "We turned on password protection" isn't a plan. They want to see systematic changes: encryption requirements, access control policies, security testing schedules, vendor assessment processes.
Does Public Availability of Data Affect Compliance?
Not the way they think it does.
Article 9 doesn't include a "but we found it on the internet" exception. If you're processing biometric data through facial recognition, you need a lawful basis under Article 9(2) regardless of where you sourced the images.
The European Data Protection Board has been clear: publicly available personal data is still personal data. Processing it still requires a legal basis. Scraping profile pictures from social media and running them through facial recognition software doesn't become compliant just because the pictures were public.
Your vendor's OSINT methodology doesn't transfer compliance responsibility away from you. If you're the controller determining purposes and means, you're accountable. If they're the controller and you're using their service, Article 28 processor requirements apply, and you need a data processing agreement that addresses special category data.
The fact that images might be findable through Google doesn't mean aggregating 9 million of them into a searchable facial recognition database is proportionate or necessary. Your Data Protection Impact Assessment needs to address that distinction.
Where Do I Go From Here?
If you're handling biometric data, commission a Data Protection Impact Assessment under Article 35 before you start processing. ISO/IEC 29134 provides the methodology framework. The assessment should identify risks specific to biometric processing: impersonation, surveillance, function creep, discrimination.
Review your Technical and Organisational Measures against the GDPR Article 32 security requirements. Encryption, access controls, logging, monitoring, these aren't optional for special category data.
Check your vendor contracts. If third parties process biometric data on your behalf, your Article 28 data processing agreement must explicitly address special category data, security requirements, breach notification timelines, and deletion obligations.
Document your legal basis. If you're relying on consent, you need proof of how you obtained it. If you're relying on a public interest basis, you need the statutory authorization. If you can't point to a clear Article 9(2) basis, stop processing until you can.
The ClarityCheck incident didn't result in confirmed exploitation. You might not be that fortunate. Build your controls assuming someone's already looking for the gap.
