The recent IDScan breach has left many legal and compliance teams wondering, "What if this happened to us?" IDScan, an identity verification company, is under scrutiny after hackers allegedly exposed over 153 million driver's licenses. The FBI's New Orleans office is investigating, and class-action lawsuits are underway. If you're using third-party identity verification services, your team is likely asking similar questions.
Are We Liable if Our processor Gets Breached?
Yes, you're still responsible for your customers' data. Article 28 of the GDPR makes it clear that when you engage a processor to handle personal data, you must ensure they implement adequate technical and organizational measures. IDScan's notification to business customers doesn't absolve those businesses of their own obligations under Article 33.
Your processor agreement should specify the security measures your processor implements, the types of processing they'll perform, and your audit rights. If you can't show you conducted due diligence before engaging the processor and monitored their security posture, your supervisory authority will see the breach as your failure to comply with Article 32.
What Security Measures Should We Expect from Our processor?
Article 32 requires assessing security measures based on the risk to data subjects. For vendors handling government-issued IDs, expect:
- Encryption for all identity document scans
- Network segmentation to prevent lateral movement
- Multi-factor authentication for administrative access
- Regular penetration testing with shared results
- Incident response procedures with clear notification timelines
- Logging and monitoring to detect unauthorized access
The scale of data matters. A processor processing 153 million records presents a higher risk than one handling thousands. Your Article 28 processor agreement should reflect that with stringent security requirements and frequent audits.
Is "Without Undue Delay" Notification from Our processor Enough?
No. Article 33 requires notifying your supervisory authority within 72 hours of a breach. "Without undue delay" from your processor isn't sufficient. Your processor agreement should specify a 24-hour notification window and require the processor to provide:
- The nature of the breach and data categories affected
- The approximate number of data subjects concerned
- Contact details of their data protection officer
- Likely consequences of the breach
- Measures taken or proposed to address the breach
You need this information to complete your own Article 33 notification. Vague contractual language leaves you exposed when the 72-hour clock starts.
Do We Have to Notify Every Customer if Their ID Was Scanned?
It depends on the risk. Article 34 requires notifying affected data subjects if a breach likely results in high risk to their rights. Driver's licenses contain enough information for identity theft, which is high risk.
Exceptions include if the data was encrypted with inaccessible keys, if you've taken measures to eliminate the high risk, or if notification involves disproportionate effort (requiring a public communication instead). Don't rely on the disproportionate effort exception for 153 million records. Plan for individual notification.
Your notification must be clear, describe the breach, provide your DPO's contact details, describe likely consequences, and explain mitigation measures. Prepare this template now.
Does GDPR Apply to Our U.S. Company Using This processor?
If you're offering goods or services to EU residents or monitoring their behavior, Article 3(2) applies regardless of your location. Even if you're U.S.-based with no EU customers, you're subject to state breach notification laws, potential FTC enforcement, and state attorneys general interest in large-scale breaches. The IDScan lawsuits in Louisiana are just the beginning.
What Should We Do Now if We Use a Similar processor?
First, review your Article 28 processor agreement to ensure it requires the security measures mentioned. If not, start renegotiating today.
Second, request a SOC 2 Type II report or ISO 27001 certificate from your processor. These aren't sufficient alone but show baseline security practices. If unavailable, that's a red flag.
Third, document your processor due diligence in your Article 30 processing records. When did you last review their security practices? What audit rights have you exercised? What security incidents have they reported? Ensure your records are adequate.
Fourth, map your data flows. Where does identity document data go after verification? How long is it retained? Who has access? If you're storing the scan yourself, you're creating additional risk.
Finally, test your personal data breach response plan with a scenario like this: processor compromise, millions of records, 72-hour notification deadline. Can your team execute the plan under pressure?
Where to Go for More
Consult your supervisory authority's guidance on processor oversight. Review the European Data Protection Board's Guidelines 07/2020 on processor concepts. Check your industry association's processor management frameworks. And talk to your insurance broker about reviewing your cyber liability coverage limits.
