The Conventional Wisdom
Your vendor risk management program likely relies on annual assessments. You send questionnaires, review SOC 2 reports, score vendors on a risk matrix, and maintain a register of approved suppliers. When procurement wants to onboard new software, you run it through your third-party risk assessment process, check the boxes, and move on.
This approach seems comprehensive. It's what frameworks like ISO/IEC 27001 Annex A.15 and the NIST Cybersecurity Framework (CSF) 2.0 require. Your auditors expect documented vendor assessments. You're doing what compliance demands.
Why This Approach Is Incomplete
KDDI's breach exposed over 12.2 million email addresses and 7.6 million passwords due to a vulnerability in third-party software. Despite having regulatory obligations and mature security programs, a flaw in external software compromised an email platform serving five internet service providers.
Annual assessments miss a critical point: the software you evaluated six months ago isn't the same software running today. Vendors release patches, deprecate APIs, and introduce new features with new vulnerabilities. The SOC 2 Type II report you reviewed covers controls from a period that ended before the current quarter started.
You're managing vendor risk as if it's static, treating third-party software like a one-time procurement decision. But every line of code your vendors ship is a moving target. The questionnaire you completed in Q1 tells you nothing about the zero-day disclosed in Q3.
The Evidence
KDDI first disclosed unauthorized access in June, then confirmed the full scope after a forensic investigation. The breach didn't occur because KDDI failed to assess the vendor initially. It happened because a vulnerability emerged in software already deployed.
This isn't an isolated case. Consider these points:
Your vendor's development velocity outpaces your assessment cycle. Enterprise software vendors ship updates weekly or monthly. Your annual assessment captures a snapshot of controls that were current when the auditor visited. By the time you receive the report, the vendor has pushed dozens of releases.
You don't control what gets patched or when. KDDI patched the flaw immediately after detecting the intrusion. That's incident response, not risk management. Your assessment process doesn't tell you whether your vendor has unpatched vulnerabilities right now, today, in the version you're running.
Questionnaires measure intent, not outcomes. When you ask, "Do you have a vulnerability management program?", you get, "Yes, we scan quarterly and remediate critical findings within 30 days." What you don't get is whether they actually remediated CVE-2024-XXXXX in the build your team deployed last month.
The conventional approach treats vendor risk as a binary gate at procurement time. You assess, approve, and onboard. Then you wait twelve months to reassess. Meanwhile, your vendor's software evolves, their threat landscape shifts, and vulnerabilities are discovered and exploited.
What to Do Instead
You need continuous visibility into vendor security posture, not periodic attestation.
Shift from assessment to monitoring. Replace annual questionnaires with ongoing signals. Track your vendors' public vulnerability disclosures. Monitor security advisories for the specific products you've deployed. Set up automated alerts when CVEs are published for your third-party software stack. This isn't about trusting vendors less; it's about acknowledging that security posture changes between assessment cycles.
Require notification obligations in contracts. Your vendor agreements should mandate that suppliers inform you within 24 hours of discovering a vulnerability affecting your deployment. Not "a breach of your data," but "a vulnerability in the version you're running." KDDI detected an intrusion and patched immediately. You want to patch before the intrusion happens.
Map vendor software to your critical assets. KDDI's breach affected an email platform serving five ISPs. They noted their own consumer services ran on separate infrastructure and weren't affected. That's architectural isolation working as designed. You should know which vendor components touch your most sensitive data and which operate in isolated segments. When a vendor vulnerability emerges, you need to answer "What's our exposure?" in minutes, not days.
Implement compensating controls for high-risk integrations. If third-party software processes customer credentials or PII, assume it will eventually have a vulnerability. Design your architecture accordingly. Can you implement additional authentication layers? Can you encrypt data before it reaches the vendor component? Can you segment the vendor's access so a compromise doesn't cascade?
Test your vendor incident response coordination. KDDI coordinated with affected ISPs to complete mandatory password resets. That coordination doesn't happen smoothly under pressure unless you've practiced it. Run tabletop exercises that assume a vendor compromise. Who contacts whom? How do you communicate with affected customers? What's your decision tree for taking vendor software offline?
When the Conventional Wisdom Is Right
Assessments still matter at the procurement gate. You shouldn't onboard vendors who lack basic security controls. SOC 2 Type II reports remain valuable for understanding a vendor's control environment. Questionnaires help you understand vendor capabilities and commitments.
The conventional approach works when you're evaluating whether to establish a vendor relationship. It fails when you're managing ongoing risk in software you've already deployed.
If you operate in a low-risk environment where third-party software doesn't touch sensitive data or critical systems, annual assessments might suffice. If your vendor relationships are simple and your attack surface is small, the overhead of continuous monitoring might outweigh the benefit.
But if you're running infrastructure at scale, processing customer data through third-party platforms, or if a vendor compromise could trigger regulatory notification requirements, then treating vendor risk management as an annual compliance exercise is insufficient.
KDDI reported to Japan's communications ministry after completing their forensic investigation. Your regulatory obligations don't wait for your next assessment cycle. Neither do the vulnerabilities in your vendors' code.
