When identity verification vendors handle millions of documents, you'd expect them to secure those systems like a vault. Yet, lawsuits are filed, the FBI is investigating, and 153 million driver's licenses were allegedly exposed through IDScan's systems. This breach, allegedly linked to the dark-web service Nexus, reveals a dangerous gap between what your compliance team assumes about vendors and what's actually happening.
The myths below aren't just misunderstandings. They're risks. Let's dismantle them.
Myth 1: "Our vendor contract covers data security"
Reality: Your Data Processing Agreement (Supervisory Authority) doesn't prevent breaches. It allocates liability after the fact.
Signing a Supervisory Authority with an identity verification provider documents the Technical and Organisational Measures they claim to implement. It doesn't validate their effectiveness. Article 28 of the GDPR requires you to use processors that provide "sufficient guarantees" of security, but it doesn't define what counts as sufficient for high-risk processing like biometric scans or government ID verification.
The IDScan incident demonstrates this gap. Multiple law firms are investigating whether IDScan failed to protect client data. If you're a car rental company, retailer, or financial institution that used IDScan's systems, your contract might say the vendor is responsible. Your customers' class-action attorneys won't care. Under Article 82 GDPR and similar provisions in the California Privacy Rights Act, data subjects can pursue either the controller or the processor. You'll spend months in litigation proving you exercised proper oversight.
What to verify instead: Request SOC 2 Type II reports annually. Require evidence of encryption at rest and in transit, not just policy statements. For high-risk processing, conduct on-site audits or third-party penetration tests. Document every verification step in your processing records under Article 30.
Myth 2: "If the vendor doesn't notify us, there's no breach"
Reality: You're still responsible for 72-hour notification even if your processor stays silent.
IDScan allegedly began notifying some business customers around September 1st, according to law firms investigating the incident. That's the same date Brian Krebs first reported the breach publicly. If you're relying on your vendor to tell you when something goes wrong, you're already behind the notification clock.
Article 33 GDPR requires notification to your Supervisory Authority within 72 hours of becoming aware of a breach. "Becoming aware" doesn't mean "when the vendor finally emails you." It means when you have reasonable grounds to know a breach occurred. If your customers start calling about fraudulent activity, if security researchers publish findings, or if law enforcement contacts you, that clock starts ticking.
Notification to data subjects under Article 34 has no 72-hour window. It's required "without undue delay" when the breach poses high risk. Driver's licenses qualify. They enable identity theft, financial fraud, and unauthorized access to age-restricted services. Delay that notification, and you're compounding the violation.
Build this into your vendor agreements: Require notification within 24 hours of the vendor's discovery. Specify that "discovery" includes when the vendor's security team detects anomalous activity, not just when they've completed a full investigation. Maintain your own Breach Register with vendor incidents tracked separately.
Myth 3: "We're not liable because we don't store the documents"
Reality: Processing includes collection and transmission. Storage isn't the only liability trigger.
Many businesses assume that because they don't retain ID scans, they're not responsible for what happens to that data. IDScan's systems scan, authenticate, and extract information from government-issued documents. If you're the business presenting that ID to IDScan's scanner, you're the data controller who determined the purposes and means of processing. IDScan is your processor.
Under Article 4(2) GDPR, processing means "any operation performed on personal data," including collection, recording, and transmission. The moment that ID touches the scanner, you're processing special category data (biometric data if facial recognition is involved) and potentially creating a Restricted Transfer if IDScan's infrastructure crosses borders.
This matters because Article 5(1)(f) requires you to ensure security "appropriate to the risk." You can't outsource that obligation. If IDScan's systems were compromised and you didn't conduct due diligence on their security posture, you've violated the accountability principle under Article 5(2).
Document your lawful basis before you start scanning IDs. If you're relying on Legitimate Interests under Article 6(1)(f), complete a legitimate interests assessment that weighs the necessity of third-party verification against the risks of centralized storage. If you're relying on Legal Obligation (for age verification in cannabis sales, for example), document the specific statute. Don't assume "we need to verify age" is sufficient.
Myth 4: "Our vendor has insurance, so we're protected"
Reality: Cyber insurance covers the vendor's losses, not your regulatory penalties or reputational damage.
IDScan's insurance policy, if it exists, will pay for IDScan's legal defense and potential settlements. It won't pay your costs when you're defending a separate class action, responding to a Supervisory Authority investigation, or rebuilding customer trust after your name appears in breach headlines.
The lawsuits filed in Louisiana name IDScan, not the businesses that used its services. But that's just the first wave. Class-action attorneys routinely add defendants as discovery reveals which controllers had oversight responsibilities. If you're Hertz (named in the lawsuits as an IDScan client), you're now explaining to your customers why their driver's licenses are allegedly circulating on the dark web.
Your own cyber insurance might cover breach response costs, but read the exclusions. Many policies exclude losses from vendor breaches if you can't demonstrate adequate vendor management. "Adequate" means documented risk assessments, contractual security requirements, and periodic compliance verification.
Maintain separate insurance coverage for third-party vendor incidents. Require vendors to name you as an additional insured on their policies. Most importantly, don't treat insurance as a substitute for security. It's a financial backstop, not a compliance strategy.
Myth 5: "We'll deal with vendor security when we renew the contract"
Reality: Annual contract reviews are too slow for a threat environment that moves in days.
The FBI is investigating the IDScan incident. The dark-web service Nexus is no longer online, but the database remains accessible to whoever downloaded it before the takedown. If you're waiting until your next vendor review cycle to assess IDScan's security, you're managing last year's risk.
Implement continuous vendor monitoring. Set up automated alerts for your critical processors: security incidents, regulatory actions, leadership changes, financial distress signals. Services exist that monitor dark-web marketplaces for your vendors' names. They're not perfect, but they're faster than waiting for a vendor to self-report.
Require quarterly security attestations, not annual audits. Include specific metrics: mean time to patch critical vulnerabilities, percentage of systems with multi-factor authentication, frequency of penetration testing. If those metrics degrade quarter over quarter, escalate to your vendor risk committee.
For high-risk processors like identity verification services, build termination rights that don't require cause. You need the ability to switch vendors quickly if their security posture deteriorates. That means maintaining data portability requirements in your contracts and testing your migration plan before you need it.
What to Do Instead
Stop treating vendor security as a contract negotiation problem. Treat it as an operational control that requires ongoing validation.
Build a vendor risk framework that categorizes processors by the sensitivity of data they handle. Identity verification vendors process government IDs, biometric data, and in some cases medical information. That's high-risk processing under Article 35 GDPR. Conduct a Data Protection Impact Assessment before you onboard any vendor in this category.
Require vendors to complete your security questionnaire annually and after any material change to their infrastructure. Define "material change" explicitly: new data centers, cloud migrations, acquisitions, changes in key personnel.
Maintain an approved vendor list with expiration dates. Don't let vendor relationships persist indefinitely without re-evaluation. When contracts auto-renew, security assumptions get stale.
Most importantly, document everything. Your Supervisory Authority will ask what due diligence you performed. "We trusted the vendor" isn't an answer. "Here's our vendor risk assessment, our quarterly security reviews, and our incident response plan for vendor breaches" is.
The IDScan incident isn't over. More lawsuits will follow. Regulators will investigate. And every business that scanned an ID through those systems will need to explain what they did to protect that data. Make sure your explanation includes evidence, not assumptions.
