Skip to main content
153M IDs Stolen: What Your Vendor Contract MissedIncident Response and Skimming
5 min readFor Fintech Risk and Compliance Teams

153M IDs Stolen: What Your Vendor Contract Missed

You're getting questions from your leadership team. A vendor breach just exposed driver's licenses at a scale nobody anticipated. Your business relies on third-party identity verification. Your legal team is asking what controls you have in place. Your CISO wants to know if you're next.

These questions are coming from real security and compliance teams after IDScan allegedly exposed over 153 million driver's licenses in a breach now under FBI investigation. The stolen data appeared on a dark-web service called Nexus, and multiple lawsuits have been filed in Louisiana where IDScan is based.

Here's what practitioners are asking right now, and what you need to tell your team.

Was My Customers' Data in This Breach?

If you use IDScan's verification systems, you may not know yet. According to law firm Markovits, Stock & DeMarco, IDScan began notifying some business customers around September 1st, but the company hasn't published a public statement about the incident's scope.

Start here: Pull your vendor contracts and look for notification requirements. Most agreements specify a timeframe for breach notification, typically 24-72 hours after discovery. If you haven't received notice but you use IDScan's services, that's your first escalation point with your account manager.

Document everything. Your legal team will need a timeline showing when you first learned of the potential exposure, what you asked the vendor, and what they told you. If you're subject to state breach notification laws or GDPR, your clock may already be running whether the vendor has confirmed your data was involved or not.

What's My Legal Obligation If It's the Vendor's Breach?

You're still responsible. When you collect customer data and send it to a third party for processing, you remain the data controller under most privacy frameworks. The vendor is your processor.

Under GDPR Article 28, you're required to use processors that provide "sufficient guarantees" of security. If you can't demonstrate you conducted adequate due diligence before onboarding IDScan, regulators may find you failed that obligation.

For financial institutions, the FFIEC IT Examination Handbook states that you're responsible for the actions of your service providers. Your examiner will ask what controls you had in place to monitor the vendor's security posture, not just at contract signing but on an ongoing basis.

Check your vendor's SOC 2 Type II report date. If it's more than 12 months old, you don't have current assurance. If you never requested one, document that gap now and escalate it as a control deficiency.

Should I File SARs on Transactions Verified by IDScan?

Not automatically, but you need a risk-based review. A Suspicious Activity Report under the Bank Secrecy Act requires reasonable suspicion that a transaction involves funds from illegal activity or attempts to evade reporting requirements.

The breach itself doesn't make previously legitimate transactions suspicious. However, if you identify accounts where the compromised identity data could enable account takeover or synthetic identity fraud, those warrant closer monitoring.

Practical step: Pull a list of accounts verified through IDScan in the past 12 months. Layer on your existing fraud indicators, such as velocity checks, device fingerprinting, and transaction patterns. Flag accounts showing anomalies for enhanced monitoring. If you see actual suspicious activity tied to potentially compromised credentials, that's when you file.

What Should Our Vendor Security Questionnaire Include?

Your questionnaire probably asks if the vendor encrypts data at rest and in transit. That's basic. You need to know what happens to identity documents after verification completes.

Ask these specific questions:

Data retention: How long do you retain scanned identity documents? Where are they stored? Many verification workflows only need to extract and validate data points, not store the full document image. If your vendor is retaining 153 million scans, ask why.

Access logging: Do you maintain immutable audit logs of who accessed identity document repositories? Can you provide evidence of log review cadence?

Segmentation testing: How do you validate that your production identity document storage is segmented from internet-facing systems? When was your last penetration test of that segmentation?

Incident response: What's your RTO for notifying customers of a confirmed breach? Get a number in hours, not "we'll notify you promptly."

The IDScan incident reportedly involved a dark-web service advertising access to the database. That suggests either a compromise of production systems or an insider threat. Your questionnaire should explicitly address both scenarios.

What Contract Terms Do I Need with a New Vendor?

Beyond standard indemnification, add these provisions:

Breach notification SLA: Require notification within 24 hours of discovery, not confirmation. You need to know about the investigation, not just the conclusion.

Right to audit: Include language allowing you to conduct or commission security assessments of the vendor's systems that process your data. Specify that you can do this on-demand if you identify a material risk, not just annually.

Data deletion verification: Require cryptographic proof of deletion when you terminate the relationship. A confirmation email isn't enough.

Subprocessor disclosure: Require the vendor to disclose any fourth parties that will have access to your data. The IDScan breach affects companies that thought they were only sharing data with IDScan, not with whatever infrastructure provider may have been compromised.

Regulatory cooperation: Add explicit language requiring the vendor to cooperate with your regulatory examinations and provide documentation examiners request.

How Do I Explain to Leadership Why We Can't Stop Using Third-Party Verification?

You can't eliminate third-party risk, but you can show you're managing it systematically.

Frame it this way: Your business needs identity verification to comply with KYC requirements and prevent fraud. Building that capability in-house means you're now responsible for maintaining document authentication algorithms, fraud detection models, and compliance with accessibility standards across 50 states. That's a different risk profile, not a lower one.

What you can control is vendor selection criteria, ongoing monitoring, and incident response planning. Show leadership your vendor risk management framework: how you score vendors, what triggers a reassessment, and what your exit strategy looks like if a vendor fails to meet security standards.

The IDScan incident is now an FBI investigation. That's the severity benchmark. Ask your leadership team: if our current vendor had an FBI investigation launched tomorrow, how long would it take us to switch to an alternative? If the answer is "we don't know," that's the gap you need to close.

Next Steps

Pull your vendor contracts today. If you don't have breach notification SLAs and audit rights, those are your first contract amendments to negotiate.

Request current SOC 2 Type II reports from every vendor handling customer identity data. If they can't provide one, that's a material gap for your risk committee.

Document your vendor risk assessments. When your examiner asks what due diligence you performed before onboarding a vendor, "they had good references" won't satisfy the FFIEC standard.

The FBI's New Orleans office is investigating this incident. Watch for any public findings about how the breach occurred. Those details will tell you what controls to prioritize in your next vendor assessment.

You Might Also Like