Skip to main content
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Third-Party Breaches Hit 61% of Organizations: What Failed and What You Can FixThird-Party Risk Management
3 min readFor Third-Party Risk Managers

Third-Party Breaches Hit 61% of Organizations: What Failed and What You Can Fix

What Happened

In 2023, 61% of organizations reported breaches involving third-party vendors. This isn't an isolated incident; it's a pattern showing systemic failures in assessing and monitoring vendor risk. Many programs focus too narrowly on cybersecurity, ignoring financial instability, operational dependencies, and compliance gaps that create vulnerabilities.

These breaches didn't occur because organizations skipped security questionnaires. They happened because cybersecurity scores can't predict every risk a vendor introduces.

Timeline

The escalation follows a predictable pattern:

Initial Assessment Phase: Vendors complete security questionnaires and achieve passing scores on standardized frameworks, receiving approval based mainly on technical controls.

Operational Integration: Vendors gain access to systems, data, and business processes. Dependencies deepen, making the relationship mission-critical.

Hidden Risk Accumulation: Financial pressures emerge. Vendors cut corners on maintenance. Compliance obligations in areas like privacy and financial controls receive less attention than the initial security assessment.

Breach Event: Compromise originates not from assessed security controls, but from unmeasured gaps like outdated software, privacy violations, or operational failures.

Discovery and Response: Your team learns about the breach through notification, not monitoring. You scramble to understand exposure across a vendor relationship you thought was secure.

Which Controls Failed or Were Missing

Failures map to several control domains:

Ongoing Vendor Monitoring: Most programs assess vendors at onboarding, then rely on annual reassessments. Continuous monitoring of financial health, operational changes, and compliance obligations is often lacking or siloed.

Multi-Domain Risk Assessment: Initial due diligence evaluates technical security controls but ignores:

  • Financial viability indicators predicting resource constraints
  • Privacy program maturity beyond basic certifications
  • Operational resilience and business continuity capabilities
  • Regulatory compliance status across jurisdictions

Control Objective Mapping Across Standards: Organizations map vendor controls to ISO 27001 or SOC 2 but don't cross-reference requirements from privacy frameworks, financial regulations, or operational resilience standards.

Vendor Risk Profile Updates: Risk profiles remain static after initial classification. Changes in the vendor's business model or regulatory obligations don't trigger reassessment.

Dependency Analysis: Teams can't answer basic questions during breaches: Which business processes depend on this vendor? What data do they access? Who else connects to them?

What the Relevant Standard Requires

ISO 27001:2022, Annex A Control 5.19 requires defining and agreeing on information security requirements with suppliers, monitoring service delivery, and managing changes. The risk assessment must consider more than technical controls.

NIST Cybersecurity Framework v2.0, Govern (GV) category emphasizes integrating cyber supply chain risk management with enterprise risk management. GV.SC-03 requires continuous assessment, not just point-in-time checks.

SOC 2, Common Criteria CC9.2 states that the service organization "evaluates and monitors the nature and extent of services provided by the vendor and the significance of those services." This includes operational dependency and business impact.

None of these standards limit third-party risk management to cybersecurity. They require risk-proportionate controls across all domains where vendor relationships create exposure.

Lessons and Action Items for Your Team

Expand your risk assessment taxonomy beyond cybersecurity. Add financial stability indicators, privacy program maturity, operational resilience capabilities, and regulatory compliance status to your Vendor Risk Profile template. Configure risk domains that match your actual exposure.

Implement ongoing monitoring across domains. Set triggers for reassessment: financial disclosures, regulatory actions, significant operational changes, or shifts in services. Don't wait for annual reviews.

Map vendor controls to every applicable framework. If a vendor handles EU personal data, map their controls to GDPR Article 32, not just ISO 27001. If they support financial reporting processes, validate controls against COSO Internal Control-Integrated Framework.

Quantify operational dependency. Document which business processes would fail if the vendor became unavailable. Classify vendors by impact to operations, not just data sensitivity.

Build cross-functional risk assessment teams. Include finance, legal, privacy, and business continuity in your third-party risk program. Each domain contributes risk signals cybersecurity assessments miss.

Test your vendor incident response. Run tabletop exercises simulating vendor breaches. Can you identify affected systems? Do you know which other vendors connect to the compromised one? Can you execute contractual remediation rights? Most organizations discover these gaps only during actual incidents.

The 61% breach rate isn't inevitable. It's the result of programs that assess one dimension of risk while vendors introduce exposure across many. Fix that gap, and you'll separate your program from those still learning these lessons the hard way.

Promotional banner highlighting failures found in PCI audits and how to spot the gaps

You Might Also Like