Vendor risk: why 60% of post-incident reviews trace back to suppliers

The number that anchored our last three vendor risk engagements is from the Verizon Data Breach Investigations Report. Across the 2024 and 2025 editions, the share of confirmed data breaches involving a third-party element has crossed the 60% mark. Sometimes the third party is the initial access vector. Sometimes the third party's compromise leaks credentials that get used elsewhere. Sometimes the third party's failure cascades through a supply chain.

What the number tells us, indirectly, is that the perimeter most companies are defending is the wrong one. The company's own systems, the company's own employees, the company's own controls — these have improved markedly over the last decade. The third-party perimeter has not.

The vendor risk lifecycle most companies operate

We have run vendor risk assessments across financial services firms, manufacturers, healthcare providers, and SaaS companies. The pattern is consistent. The lifecycle that exists on paper has four stages: onboarding due diligence, ongoing monitoring, incident handling, and offboarding. The lifecycle that exists in practice has one and a half.

Onboarding due diligence is real. Most companies have a vendor onboarding questionnaire, a procurement workflow, and a sign-off process. New vendors get reviewed at the point of contract.

Ongoing monitoring is partial. Some vendors get reviewed annually. Most do not. The annual review, when it happens, is usually a refresh of the original questionnaire with the same vendor, with no test of whether the vendor's controls are actually operating.

Incident handling is reactive. When a vendor breach happens, the company learns about it through press reports or a vendor notification, and the response is improvised.

Offboarding is barely a process. Vendors are added; vendors are rarely formally removed. The access tokens, the API integrations, the data shares — these often persist long after the commercial relationship has ended.

The five-tier classification system

The first piece of vendor risk work that produces real value is a classification of every vendor by tier. The framework we use has five tiers.

Tier 1: critical. Vendors whose failure or compromise would materially affect the company's ability to operate. The core banking platform for an NBFC. The payment processor for an e-commerce firm. The cloud infrastructure provider. The major SaaS systems that hold customer data.

Tier 2: high. Vendors with access to customer data or financial systems but where a failure is recoverable within hours to a day. CRM, marketing automation, customer support tools.

Tier 3: medium. Vendors with access to internal systems or limited customer data, where a compromise is contained. Internal collaboration tools, analytics platforms, professional services with NDA.

Tier 4: low. Vendors with no access to systems or data, providing routine services. Cleaning, facility maintenance, basic office supplies.

Tier 5: ad-hoc. One-off engagements, consultants for specific projects, short-term contractors.

The classification drives the control depth. Tier 1 vendors get annual deep reviews, SOC 2 Type II reports, contractual breach notification clauses, and penetration testing rights. Tier 5 vendors get a standard NDA and a quick screen.

The mistake we see most often is treating every vendor identically. A 40-page questionnaire applied uniformly produces compliance fatigue. Vendors fill it in, but the responses are not read with attention proportionate to the actual exposure. A tiered framework concentrates the attention where the risk is.

What ongoing monitoring actually requires

Beyond the annual questionnaire refresh, real ongoing monitoring for Tier 1 and Tier 2 vendors includes:

SOC 2 Type II review. Not just confirming the report exists. Reading the exceptions, the scope, and the testing period. A SOC 2 with a six-month scope is not the same as one with a twelve-month scope. A SOC 2 with material exceptions in change management is not the same as a clean one.

Breach notification monitoring. Has the vendor disclosed any security incident in the last 12 months, either through formal channels or in press? Many vendors disclose incidents on their own status pages without notifying customers individually.

Financial health monitoring. For Tier 1 vendors, particularly mid-size SaaS providers, financial distress can be the leading signal of a control degradation. A vendor running out of cash cuts security staff first.

Subcontractor mapping. Tier 1 vendors usually have their own Tier 1 vendors. The data that flows to your CRM may flow further to the CRM's own data warehouse, customer support tooling, and engineering productivity tools. This sub-tier rarely appears in the original onboarding diligence.

Access review. For vendors with system access via API tokens, federated identity, or service accounts, the access scope should be reviewed at least quarterly. Vendors often retain access beyond what they currently need, simply because nobody reviewed.

The incident playbook

When a vendor breach occurs, the first 72 hours are when most of the damage is determined. The playbook we recommend covers four parallel tracks.

Containment. Revoke the vendor's access tokens immediately. Rotate any credentials the vendor had access to. If the breach involves a SaaS platform, force-rotate user sessions and require MFA re-enrolment.

Assessment. What data did the vendor have access to? What data did the breach affect? Is your data in the affected set? This requires a current, accurate vendor data inventory — which most companies do not have. The first 24 hours after a vendor breach are often spent reconstructing the inventory.

Disclosure. What are your obligations to notify? In India, the DPDP Act 2023 obligations are now in force, with breach notification timelines defined. Sectoral regulations — RBI for financial services, SEBI for intermediaries — have their own timelines, often shorter. The disclosure decision is fact-specific and has to involve legal counsel from hour one.

Vendor management. Engage with the vendor's incident response team. Demand specific information — affected records, root cause, remediation timeline. Document every communication. The post-incident review will rely on these records.

Offboarding is a control

When a vendor relationship ends, the offboarding has to be formal. The access tokens are revoked, the data shares are terminated, the company's data held by the vendor is either returned or certifiably destroyed, and the vendor's user accounts in your federated identity system are removed.

In about a third of the engagements we run, we find active credentials for vendors whose contracts have been terminated more than a year ago. Sometimes the access was through an API token that nobody documented as expiring. Sometimes through a shared account that no individual owned. Sometimes through a SaaS-to-SaaS integration that nobody remembered.

The fix is a quarterly access review against an active-vendor list, with anything not on the list flagged for immediate revocation.

Why ESG and labour issues are part of vendor risk now

The conventional vendor risk framework focuses on cyber, business continuity, and financial health. Two more risk categories are now consistently in scope.

ESG exposure. A supplier with poor environmental practices, exposed in a media report, becomes a brand risk for the customer. A supplier in a region with sanctions exposure becomes a compliance risk.

Labour practices. A supplier with documented child labour, forced labour, or unsafe working conditions becomes a brand risk, particularly for consumer-facing brands and for companies subject to supply chain disclosure requirements in their export markets.

Neither of these fits the IT security questionnaire. Both have to be in the broader vendor questionnaire for Tier 1 and Tier 2 suppliers.

The DPDP Act overlay

India's Digital Personal Data Protection Act 2023 has reframed vendor risk in a specific way. Any vendor that processes personal data on behalf of a Data Fiduciary becomes a Data Processor with defined obligations. The Data Fiduciary's contractual obligation is to ensure that the Data Processor maintains appropriate security and complies with breach notification.

This means vendor contracts for any system that handles customer personal data now require specific DPDP clauses — purpose limitation, retention limits, security obligations, breach notification timeline, data return or destruction on termination, sub-processor disclosure.

The audit committee question is no longer whether vendors have signed an NDA. It is whether vendors handling personal data have signed a DPDP-compliant data processing addendum, and whether the company has a current inventory of which vendors process which categories of personal data.

The deliverables from a vendor risk engagement

Three documents, refreshed annually.

First, the vendor inventory — every active vendor, tier, data access, system access, contract expiry, last review date.

Second, the tiered review schedule — what depth of review each tier gets and when.

Third, the incident playbook — specific to the company's regulatory environment and vendor mix.

If the audit committee gets these three documents on a regular cycle, the vendor risk function is operating. If the audit committee gets a single-page summary that says 'vendor risk is covered', it is not.

Vendor risk is the part of the security perimeter that the company does not directly control. The DBIR number — 60% plus — tells us that this perimeter is now the larger source of incidents, not the smaller one. Most companies' control investments have not yet adjusted to that fact. The next 24 months will be when the catch-up either happens or does not.