Your compliance team needs actionable answers, not theoretical case studies. When IDScan confirmed on September 4, 2023, that unauthorized parties accessed data tied to over 153 million driver's licenses, privacy officers and governance teams faced urgent questions: What's our exposure? What do we tell customers? What should we have done six months ago?
Here are the questions we're hearing from practitioners dealing with third-party identity verification breaches, and the regulation-grounded answers that matter.
Does "may have accessed" mean we notify or not?
Yes, you notify. IDScan's language, "may have accessed or copied", reflects investigative uncertainty, not a reason to delay notification. Under GDPR Article 33, you have 72 hours from becoming aware of a breach to notify your Supervisory Authority. "Aware" means when you have reasonable certainty that personal data was compromised. If your vendor tells you unauthorized access occurred and personal data was stored in the affected system, that's your trigger.
The California Privacy Rights Act and state breach notification laws use similar thresholds. California Civil Code § 1798.82 requires notification when unencrypted personal information was "acquired" by an unauthorized person, or when encrypted information was acquired along with the encryption key. Your vendor's use of "may have" doesn't extend your timeline, it just means they're still scoping impact while the clock runs.
Notify your Supervisory Authority within 72 hours. Notify affected individuals "without undue delay" if the breach is likely to result in high risk to their rights. Driver's license numbers combined with full names and scans meet that threshold.
What's our liability when a processor we hired gets breached?
You remain the controller. Under GDPR Article 82, both controllers and processors can be held liable for damages, but the controller is responsible for choosing processors that provide "sufficient guarantees" of compliance (Article 28). If you didn't conduct due diligence on IDScan's security controls, didn't include Technical and Organisational Measures in your data processing agreement, or didn't audit their cloud security posture, you can't deflect liability by pointing at the vendor.
Your data processing agreement should specify the processor's breach notification obligations, ideally, notification to you within 24 hours of discovery, not three days later when they've finished their internal investigation. Review your agreement now. If it says the processor will notify you "promptly" or "as soon as practicable," replace it with a specific hour count.
How do we prove we did due diligence before signing with them?
Document your vendor assessment before the breach, not after. Your due diligence record should include:
- A completed vendor security questionnaire covering access controls, encryption at rest and in transit, logging and monitoring, and incident response procedures
- Evidence that you reviewed SOC 2 Type II or ISO/IEC 27001 certification, if available
- Your risk assessment noting the data categories involved (government ID numbers, biometric scans) and the justification for accepting residual risk
- Contractual terms requiring the processor to implement Article 32 security measures appropriate to the risk
If you're conducting this assessment now, post-breach, you're building a lessons-learned file, not a compliance defense. For your next vendor onboarding, require that the processor maintain a breach register and provide you with quarterly summaries, even if no incidents occurred. Silence isn't assurance.
The FBI is investigating, do we wait for them before notifying customers?
No. Law enforcement investigations don't pause your regulatory obligations. IDScan disclosed that it's cooperating with the FBI, but that cooperation doesn't extend your 72-hour Supervisory Authority notification window or excuse delays in individual notification.
You can request that your Supervisory Authority delay individual notification if early disclosure would impede a criminal investigation (GDPR Article 34(3)), but you must make that request explicitly and receive approval. Don't assume silence equals permission.
Coordinate with law enforcement, but notify your regulator on time. If the FBI asks you to hold individual notifications, document the request and seek a written extension from your Supervisory Authority.
What do we tell customers when we don't know the full scope yet?
Tell them what you know, when you know it. Your initial notification doesn't need to be complete, it needs to be timely and actionable. Include:
- The date you learned of the breach
- The categories of data involved (names, driver's license numbers, ID scans)
- The measures you're taking (engaging forensic specialists, securing systems, offering credit monitoring)
- The contact point for questions
- Your commitment to provide updates as the investigation progresses
IDScan's September 4 notice followed this structure. It didn't quantify the exact number of affected individuals or specify the attack vector, but it disclosed the data categories and the response steps. That's the baseline.
If you wait until you have every detail, you'll miss your notification deadline and multiply your regulatory exposure. Notify with what you have, then supplement.
Should we require MFA and encryption at rest in vendor contracts going forward?
Yes, and be specific. Don't write "appropriate security measures", that's unenforceable. Require:
- Multi-factor authentication for all administrative access to systems processing your data
- AES-256 encryption for data at rest
- TLS 1.3 for data in transit
- Role-based access controls with deprovisioning within 24 hours of employment termination
- Annual penetration testing by a qualified third party, with results shared within 30 days
These are Article 32 Technical and Organisational Measures, not aspirational goals. Write them into Section 7 of your data processing agreement and make them audit rights, not promises.
Where do we go from here?
Start with your vendor inventory. Identify every processor that stores government-issued ID numbers, biometric data, or financial account information. Request their most recent SOC 2 report or ISO/IEC 27001 certificate. If they can't produce one, escalate the risk.
Then audit your data processing agreements. If they predate 2020, they likely don't reflect current guidance from the European Data Protection Board on processor obligations. Update them.
The IDScan breach confirmed what your team already suspected: your vendor's cloud security is your compliance risk. Treat vendor assessments as regulatory controls, not procurement paperwork.
