Within hours of the Nexus breach disclosure, questions flooded my inbox from compliance teams at banks, fintechs, and payment processors. They realized their third-party risk assessments might have a significant oversight.
The FBI's New Orleans field office is investigating idscan.net, a Louisiana-based identity verification company. Their systems allegedly leaked over 153 million drivers licenses to a dark web marketplace, with data exfiltration occurring over a year. If your team uses identity verification vendors for KYC, account opening, or transaction monitoring, you're likely asking similar questions.
Is This a PCI DSS Issue or a Privacy Problem?
It's both, depending on what you're verifying and when.
If you're using identity verification during cardholder enrollment or as part of your Card-Not-Present fraud controls, the vendor is part of your payment flow. PCI DSS Requirement 12.8 requires maintaining a list of service providers, obtaining acknowledgment that they're responsible for cardholder data security, and conducting due diligence before engagement.
However, drivers licenses aren't cardholder data under PCI DSS. They're used to verify identity before someone becomes a cardholder or during high-risk transactions. This falls under your KYC and Customer Identification Program (CIP) obligations under the Bank Secrecy Act and your broader third-party risk management framework.
The FFIEC IT Examination Handbook guidance on third-party relationships applies here. You're expected to assess the provider's information security program, including handling, storing, and disposing of sensitive personal information. If your vendor retains scanned license images with timestamps for over a year without a verified retention policy, that's a control gap.
How Can We Verify What Our IDV Vendor Does With the Scans?
Request their SOC 2 Type II report and review Section 4 for complementary user entity controls. This section outlines what they expect you to do. If data retention and deletion aren't in their control environment, they're shifting that risk to you.
Ask for their data flow diagram. You need to know where images are stored, if they're encrypted at rest, how long they're retained, whether they're used for model training, and which subprocessors have access. If they can't provide this in a week, that's a red flag.
For vendors processing identity verification at scale, like idscan.net, inquire about segmentation. Are images from financial services clients stored separately from retail or hospitality clients? If a cannabis dispensary's verification data is in the same data store as your bank's KYC scans, you're inheriting risk from other clients' security postures.
The timestamps in the Nexus records suggest images were retained with metadata intact. Your contract should specify maximum retention periods and require cryptographic deletion of both images and associated metadata after verification. If your vendor's terms say "we retain data as long as necessary for business purposes," push back with a specific timeline tied to your regulatory obligations.
Do We Need to File a SAR if Our Customers' Licenses Were in This Breach?
Probably not based solely on the breach, but secondary fraud might trigger filing obligations.
A Suspicious Activity Report under FinCEN regulations is required when you detect transactions involving illegal activity, evasion of BSA requirements, no business purpose, or potential money laundering or terrorist financing. The breach of identity documents doesn't automatically meet those thresholds.
What does trigger SAR filing: if you see account opening attempts using credentials from the Nexus dataset. Stolen identity documents can lead to synthetic identity fraud and account takeover. If you notice multiple new account applications with identity documents matching breach indicators, that pattern of suspicious activity warrants a SAR.
Evaluate whether this changes your Customer Due Diligence. If a customer's drivers license was in the breach and they're flagged for Enhanced Due Diligence as a Politically Exposed Person or due to high-risk transaction patterns, the compromised identity documents elevate the risk of impersonation. This might require re-verification using alternative methods.
Our Vendor's SOC 2 Report Was Clean Six Months Ago. How Did This Happen?
SOC 2 Type II reports test controls over a specific period (usually 6-12 months) against criteria the vendor selected. They don't test for every possible risk and are backward-looking.
The Nexus service claims continuous exfiltration over a year, with the dataset growing by nearly 400,000 records in 24 hours. This suggests either: (1) the exfiltration started after the SOC 2 observation period, (2) the controls tested didn't cover data exfiltration detection, or (3) the compromise method bypassed tested controls.
Most SOC 2 reports for identity verification vendors focus on availability, processing integrity, and confidentiality. They test whether the vendor encrypts data in transit and at rest, maintains access controls, and monitors for unauthorized access. They typically don't test for low-and-slow data exfiltration where an insider or compromised credential pulls small batches of records over months.
Your vendor questionnaire should ask: Do you have Data Loss Prevention controls that monitor bulk exports of identity documents? Do you log and alert on unusual database queries? How quickly can you detect if an API key or service account is systematically downloading records? These controls would catch the attack pattern described in the Nexus case.
Should We Stop Using Third-Party IDV and Bring It In-House?
Not necessarily, but you need to recalibrate the risk transfer model.
Building in-house identity verification means you're responsible for maintaining device hardware or SDKs that capture document images, implementing liveness detection to prevent spoofing, training models to detect fraudulent documents, and staying current with security features on IDs from all 50 states plus territories. You're also inheriting full data retention and breach notification liability.
Third-party vendors exist because this is specialized work. The question isn't whether to use them, but how to structure the relationship to limit your exposure.
Consider vendors offering real-time verification with immediate cryptographic deletion. The vendor captures the image, extracts necessary data fields, verifies authenticity, returns a pass/fail decision and the extracted fields, and deletes the image within seconds. You never store the image; neither does the vendor beyond the verification transaction.
If your use case requires image retention, segregate that storage under your control. The vendor performs verification; you handle retention in your own encrypted data store with your key management. This eliminates the risk of your customers' images sitting in a vendor's database alongside data from other clients.
What Do We Tell Customers Who Ask if Their License Was Exposed?
Be direct about what you know and what you're doing.
Confirm that you use identity verification services for account opening and fraud prevention, that you're aware of reports regarding a potential breach at an identity verification provider, and that you're investigating whether any customer data was affected. You're reviewing vendor relationships and have implemented additional monitoring for account takeover and synthetic identity fraud attempts.
Don't tell customers their data was "probably not" in the breach unless you have confirmation. The Nexus dataset allegedly includes over 153 million US and Canadian licenses. If your vendor is idscan.net or you don't know which vendor's data is in Nexus, you can't rule out exposure.
If you determine customer data was exposed, your notification obligations depend on state breach notification laws (all 50 states have them with different triggers and timelines) and whether you're subject to the Gramm-Leach-Bliley Act's Safeguards Rule, which requires notification to customers when there's unauthorized access to sensitive customer information.
Practical guidance: drivers licenses are often used as authenticators for account recovery, credit applications, and high-value transactions. Customers whose licenses are in this dataset face elevated risks of synthetic identity fraud and impersonation. Recommend they place fraud alerts with credit bureaus, review account activity carefully, and consider requesting new license numbers from their state DMV if available.
Where to Go for More
Review the FFIEC's "Outsourcing Technology Services" booklet for third-party risk management expectations. The NIST Cybersecurity Framework's "Identify" function includes specific guidance on supply chain risk assessment (ID.SC) that applies to identity verification vendors.
For vendor contracts, the Shared Assessments Standardized Information Gathering (SIG) questionnaire includes detailed sections on data handling, retention, and incident response that you can adapt for identity verification providers. Your vendor should be able to answer every question in the SIG's Data Classification and Handling section without hedging.
If you're re-evaluating your vendor roster, prioritize providers who can demonstrate real-time verification with cryptographic deletion, publish transparent data flow diagrams, and maintain separate environments for regulated financial services clients. The vendor's marketing page showing logos of Fortune 500 clients isn't a security control. Their architecture diagram showing data segregation is.
