You've signed the BAA. You've reviewed the SOC 2 report. You've checked the box that says "third-party risk assessed." Then someone posts your users' National Insurance numbers on a forum for $600.
These questions arose after news broke that a seller claimed to have obtained 877,000 driver records from Love Electric, a UK-based EV salary sacrifice scheme provider. The breach sample contained National Insurance numbers, driving license numbers, and employment data. Worse, the seller offered the full dataset for $600 in cryptocurrency, allowing multiple buyers to obtain the same records.
The questions below reflect what compliance teams actually asked when they saw the news. Your vendor questionnaire probably won't catch what this breach exposed.
Do SOC 2 Reports Show If My Vendor Can Protect Identity Data?
Not directly. A SOC 2 Type II report confirms that controls were tested over a period, but it doesn't tell you whether those controls are sufficient for the specific data your vendor holds.
Consider what Love Electric processed: National Insurance numbers, driving license numbers, dates of birth, employer information, and addresses. That's high-value identity data. If your vendor holds similar datasets, verify specific controls beyond the report's scope.
Start with ISO/IEC 27001 Annex A.5.19 (Information security in supplier relationships) and A.5.20 (Addressing information security within supplier agreements). These require you to define security requirements based on the type and sensitivity of information the supplier will access or process.
For identity data specifically, ask: Does the vendor maintain an asset inventory that classifies this information? What cryptographic controls protect it at rest? Who can query the production database, and how is that access logged? A clean SOC 2 opinion doesn't answer these questions unless you've seen the detailed control descriptions and test results.
How Do I Verify a Vendor's Security Claims Without a Certification?
Conduct your own assessment and document it as evidence that you met your own control obligations.
ISO/IEC 27001 clause 8.1 (Operational planning and control) requires you to establish criteria for processes and implement control of processes in accordance with the criteria. For suppliers, that means defining what "secure enough" looks like before you sign the contract.
Build a risk-based vendor assessment that focuses on the controls that matter for your use case. If the vendor processes personal data, verify that they've implemented data minimization, access controls, and logging. If they hold credentials, verify that they use FIPS-Validated Cryptography for encryption at rest.
Request evidence: configuration screenshots, access control matrices, recent vulnerability scan results, incident response runbooks. If the vendor can't or won't provide evidence, that's a finding in your risk treatment plan. You either accept the residual risk, implement compensating controls, or choose a different vendor.
Document everything. Your auditor will ask how you verified third-party security. "They said they were secure" isn't evidence. A completed assessment questionnaire with supporting artifacts is.
What Should I Include in a Vendor Contract About Security?
Include specific, testable obligations tied to the data they'll handle.
Start with the right to audit. ISO/IEC 27001 A.5.20 requires you to agree with suppliers on the right to monitor, review, and audit security practices. Your contract should allow you (or a qualified third party) to conduct security assessments at defined intervals or after a suspected incident.
Define incident notification timelines. SOC 2 Common Criteria CC7.4 addresses how the entity responds to system failures, but your contract should specify what constitutes a notifiable incident and how quickly the vendor must inform you. The Love Electric case shows why this matters: if a vendor suffers a breach, you need to know immediately so you can assess the impact on your own users and meet your own notification obligations under ISO/IEC 27001 A.5.27 (Learning from information security incidents).
Include data handling requirements: where data can be stored geographically, how long it can be retained, what happens to it upon contract termination, and whether the vendor can use it for purposes other than delivering the contracted service.
Specify logging and evidence retention. If you're subject to SOC 2 or ISO/IEC 27001, you'll need evidence that the vendor maintained controls throughout the audit period. Require the vendor to retain access logs, change logs, and security event logs for at least the duration of your audit cycle.
How Do I Know If a Vendor Breach Affects My Compliance Status?
It depends on what data was exposed, whether you had appropriate controls in place to manage the vendor risk, and how you respond.
If the vendor held personal data you're responsible for under GDPR or similar regulations, you likely have a notification obligation. Check your data processing agreement: you should have already mapped what data the vendor processes and under what legal basis.
From a framework perspective, ISO/IEC 27001 clause 10.1 (Nonconformity and corrective action) requires you to react to nonconformity, evaluate the need for action, and implement any action needed. A vendor breach that exposes data you're responsible for is a nonconformity in your supplier management process.
For SOC 2, look at your system description. If you've identified the vendor as a subservice organization and relied on their controls (Complementary Subservice Organization Controls), a breach at the vendor affects your control environment. You'll need to work with your auditor to determine whether the breach represents a control deficiency and what remediation is required.
Document your response: when you learned of the breach, what data was affected, how you assessed impact, what notifications you made, and what changes you're implementing to prevent recurrence. That documentation becomes evidence that you followed your incident response process.
Should I Require Vendors to Carry Cyber Insurance?
Insurance doesn't prevent breaches, but it can reduce your financial exposure if a vendor breach leads to regulatory fines or notification costs that flow back to you.
More useful: require the vendor to demonstrate that they have an incident response plan that's been tested in the last 12 months. ISO/IEC 27001 A.5.26 (Response to information security incidents) requires you to plan your response to incidents. Your vendor should be able to show you their plan and evidence of tabletop exercises or simulations.
Ask what their plan covers: How quickly can they determine the scope of a breach? How do they preserve forensic evidence? What's their process for notifying affected customers? Who's on their incident response team, and do they have external support lined up?
The Love Electric case shows why this matters. The sample data was published on August 26, but the created_at timestamps in the sample dated to August 14, 2022. If that's accurate, the data had been sitting in the database for years before it was exposed. A vendor with a mature incident response capability should be able to tell you not just that they were breached, but what data was accessed, when, and by what method.
What Do I Do If I Find Out My Vendor Was Breached Six Months Ago?
Activate your own incident response plan immediately, even if the vendor says the issue is resolved.
First, determine scope. What data did the vendor hold? Was it encrypted? Who had access? Is there evidence the data was exfiltrated, or just accessed? The answers drive your notification obligations and remediation steps.
Second, assess your own controls. Why didn't you detect the vendor breach earlier? ISO/IEC 27001 A.5.20 requires you to monitor supplier security practices. If you're learning about a breach from a news report or a forum post rather than from the vendor, that's a control gap in your supplier management process.
Third, document everything as a nonconformity. You'll need to show your auditor that you identified the issue, assessed its impact, took corrective action, and implemented preventive measures. That might include terminating the vendor relationship, implementing additional monitoring, or changing your vendor assessment process.
Finally, evaluate whether you need to notify regulators or affected individuals. The fact that the breach happened at a vendor doesn't eliminate your notification obligations if you're the data controller.
Where Do I Go From Here?
Build a supplier security assessment process that's tied to data classification, not vendor size or contract value. The vendor processing your most sensitive data might be a small firm without a SOC 2 report. That doesn't mean you can skip the assessment.
Start with ISO/IEC 27036 (Information security for supplier relationships). It provides a structured approach to identifying information security risks in supplier relationships and defining requirements based on the type and sensitivity of information involved.
For vendors that process personal data or hold credentials, require evidence of specific controls: encryption at rest using FIPS-Validated Cryptography, role-based access control with documented authorization matrices, logging of privileged access, and annual penetration testing.
Review your data processing agreements. Make sure they define incident notification timelines, audit rights, data retention limits, and termination procedures. If your current agreements don't cover these points, that's your starting point for remediation.
And test your own incident response plan with a vendor breach scenario. Can your team determine scope, assess regulatory obligations, and execute notifications within the required timelines? The Love Electric breach shows that vendor incidents can expose identity data that can't be rotated or replaced. Your response needs to be faster than the time it takes for that data to show up in a phishing campaign.
