When IDScan allegedly suffered a breach exposing over 153 million driver's licenses, lawsuits arrived before the company issued a single public statement. That's not unusual anymore. What makes this incident instructive isn't the scale, though 153 million records is staggering, but the pattern: a specialized third-party service, scattered vendor notifications around September 1st, FBI involvement from the New Orleans office, and immediate class-action filings in Louisiana where the company is based.
The mistakes that led here aren't exotic. They're structural, contractual, and organizational. And they're happening right now in your vendor stack.
Why These Mistakes Keep Happening
Third-party identity verification creates a paradox. You outsource the function to reduce liability and improve user experience, but you've actually just moved your risk into someone else's infrastructure while keeping 100% of the regulatory and reputational exposure. The business using IDScan's scanning hardware at the rental counter doesn't get to tell regulators "we didn't store it, they did." The General Data Protection Regulation (GDPR) doesn't care. The SEC Cybersecurity Disclosure rules don't care. Your customers definitely don't care.
The mistakes below aren't technical failures. They're governance gaps that happen when procurement, legal, and security don't converge on the same vendor risk question: what happens to our liability when this vendor gets breached?
Mistake 1: Treating Vendor Security as a Procurement Checkbox
Your procurement team sends a vendor security questionnaire. The vendor returns it with satisfactory answers. You sign the contract. Six months later, you learn from Brian Krebs that the vendor's database is being sold on the dark web.
Why it happens: Procurement evaluates vendors on price, features, and contract terms. Security questionnaires become compliance theater. Nobody verifies the answers, tests the controls, or revisits the assessment after the initial deal closes. The vendor's SOC 2 report is three years old. Their penetration test was done before they added the cloud storage bucket that just leaked.
The consequence: When the breach happens, your legal team discovers that the contract's indemnification clause is worthless because it caps liability at the annual contract value, which for a scanning service might be $50,000, while your notification costs alone will exceed $2 million. You can't even determine which of your customers are affected because the vendor won't share forensic findings during the FBI investigation.
The fix: Implement continuous vendor risk monitoring that includes:
- Annual control validation, not just questionnaire refresh
- Breach notification SLAs in the contract (24-hour preliminary notice, 72-hour detailed forensics)
- Liability caps that reflect actual exposure (if the vendor processes 1 million customer records, the cap should cover notification, credit monitoring, and regulatory penalties for 1 million records)
- Contractual right to audit, with results shared with your team within 15 days
- Termination rights triggered by control failures, not just breaches
Mistake 2: Assuming Data Minimization Happened
You contracted with IDScan to verify age at point of sale. You assumed they'd check the birthdate and discard the scan. Instead, they stored full driver's license images, including photos, addresses, license numbers, and whatever other documents customers scanned.
Why it happens: Your contract says "identity verification services." It doesn't specify data retention limits, image storage prohibitions, or deletion schedules. The vendor's business model depends on building a database they can monetize. You never asked what data they keep or why.
The consequence: You're now liable under state breach notification laws for data you didn't know existed. Your privacy impact assessment, which you didn't update after signing the vendor contract, doesn't mention driver's license scans. Your Data Protection Officer learns about the data inventory from a plaintiff's attorney.
The fix: Before signing any contract that touches Personally Identifiable Information:
- Map the data flow: what gets collected, where it goes, how long it's kept, who has access
- Require written data processing agreements that specify retention limits (e.g., "verification data deleted within 24 hours of transaction")
- Prohibit secondary use (vendor can't use your customer data for their own analytics or model training)
- Demand regular data inventory reports (quarterly spreadsheet showing record counts by data type)
- Insert contractual language requiring ISO/IEC 27701 privacy controls or equivalent
Mistake 3: Failing to Test Your Breach Response with Vendor Scenarios
Your Incident Response Plan has a section on vendor breaches. It says "contact vendor, assess impact, notify affected parties." When the IDScan breach hits, you discover the vendor isn't responding to emails, your contract doesn't require them to share forensic reports, and you have no idea which of your 47 retail locations were using their scanners versus the old manual process.
Why it happens: Tabletop exercises always use the same scenario: ransomware on your own systems. You've never simulated a third-party breach where you have no forensic access, no control over the timeline, and incomplete records of what data the vendor held.
The consequence: You're 72 hours into the incident before you even know which business units were affected. Your notification deadline, required under most state laws within 60-90 days of discovery, is ticking, but you're still trying to get the vendor to confirm what "discovery" means. Did they discover it on September 1st when they started notifications, or earlier? You don't know, and they won't say during the FBI investigation.
The fix: Run vendor breach scenarios quarterly:
- Simulate notification from a critical vendor (payment processor, ID verification, cloud storage)
- Test your ability to identify affected customers without vendor cooperation
- Validate your contract's breach notification clause by actually executing it in simulation
- Confirm you have offline copies of vendor relationship documentation in case their systems are down
- Practice the legal hold process for vendor-related communications
Mistake 4: Ignoring the Vendor's Vendor
IDScan's scanning hardware sits at your rental counter. But where does the image data go? To IDScan's cloud storage provider, their analytics subprocessor, and their fraud detection partner. You contracted with one vendor. You got a supply chain.
Why it happens: Your contract allows the vendor to use subprocessors "as needed for service delivery." You never asked for the subprocessor list. You never required notification when they add new ones. You never audited their vendor management program.
The consequence: The breach didn't happen at IDScan's primary infrastructure. It happened at a cloud storage bucket managed by a subprocessor you've never heard of, in a region you didn't authorize, under access controls you never reviewed. Your contract with IDScan says nothing about subprocessor security standards.
The fix:
- Require a complete subprocessor list before contract signature
- Mandate 30-day advance notice for new subprocessors, with right to object
- Flow down your security requirements to all subprocessors (if you require encryption at rest, the subprocessor must provide it)
- Audit subprocessor controls annually or require the vendor to share their subprocessor audit results
- For critical vendors, those handling Personally Identifiable Information or Protected Health Information, prohibit offshore subprocessors unless you explicitly approve the jurisdiction
Mistake 5: Separating Vendor Risk from Enterprise Risk Reporting
Your vendor risk team knows about the IDScan relationship. Your enterprise risk committee doesn't. When the breach happens, the board learns about it from a Reuters article, not from your quarterly risk report.
Why it happens: Vendor risk lives in procurement or IT. Enterprise risk reporting goes to the board. The two processes don't connect. Your Key Risk Indicators track "number of vendors assessed" but not "aggregate Personally Identifiable Information exposure across third parties" or "percentage of critical vendors with breach notification SLAs."
The consequence: The board reasonably asks why this wasn't escalated as a top-tier risk. Your organization processes 50 million customer transactions annually. A single vendor held three years of identity scans. That's a material concentration risk that never appeared in any board deck.
The fix: Connect vendor risk to enterprise risk reporting:
- Track third-party data exposure as a board-level metric (total records held by vendors, by sensitivity tier)
- Report vendor concentration risk (percentage of customer data held by top 5 vendors)
- Include vendor breach scenarios in your enterprise risk register
- Escalate new vendor relationships that create material exposure, defined as: vendor would process >10% of annual customer records, or any Protected Health Information/financial data
- Require CISO sign-off on contracts that create new data processing relationships
Prevention Checklist
Before signing your next vendor contract that touches customer data:
- Data processing agreement specifies retention limits and deletion schedules
- Contract includes breach notification SLA (24-hour preliminary, 72-hour detailed)
- Liability cap reflects actual exposure, not just contract value
- You have contractual audit rights with 15-day report delivery
- Vendor must provide complete subprocessor list and 30-day notice for changes
- Contract prohibits secondary use of your customer data
- You've mapped the complete data flow (collection, storage, access, deletion)
- Your Incident Response Plan includes a vendor breach scenario
- Your tabletop schedule includes quarterly vendor breach simulations
- Your enterprise risk reporting tracks third-party data exposure
- Your board receives vendor concentration risk metrics
- Termination rights trigger on control failures, not just breaches
The IDScan lawsuits were filed in Louisiana before the company made any public statement. That timeline tells you everything: your customers' attorneys will move faster than your vendor's communications team. Your preparation needs to move faster than both.
