When the Breach Comes Through a Vendor, Who Owns It?

Summary

When the incident starts at a vendor, the vendor cleans up its own network. You keep the disclosure clock, the customer calls, and the audit file. Regulators have already settled this question, but not the way most vendor contracts assume. The work is to decide who owns detection, scope, remediation, and proof before a vendor ever calls you.

Introduction

Verizon’s 2026 Data Breach Investigations Report found that 48% of breaches involved a third party. That is roughly 60% higher than the year before. The breach moved onto somebody else’s network. Everything that happened after the breach stayed on your network.

Almost half of breaches now arrive through someone else

The numbers have crossed a line: vendor risk is now breach risk.

• Third-party involvement showed up in 48% of breaches in the 2026 DBIR, up about 60% from the prior dataset.
• IBM’s 2026 Cost of a Data Breach report puts the average cost of a supply chain compromise at $4.96M, a number that reaches the board.
• The same report clocks that attack path at 258 days to find and contain: 194 days to identify and 64 days to shut down. It is the slowest path on the chart.

Eight months of dwell time is not a detection problem on your side. It is a detection problem on somebody else’s side that becomes your incident on the day they finally notice.

“It was our vendor” is not a defense

This is where most programs find out what they actually signed up for.

The regulators already answered this

When the SEC wrote its disclosure rules, companies asked for an exemption for incidents that happen on a third party’s systems. The SEC declined and also declined to add a safe harbor. You run your own materiality call on a vendor incident, using whatever you know at the time. You are not expected to investigate past your normal contract channels, which is exactly the problem. You have to decide with partial facts while the vendor is still working.

In Europe, the language is blunter. DORA Article 28 says a financial entity that hands operations to a technology provider stays fully responsible for its obligations at all times. Under GDPR, choosing the processor was your decision, so you’re also responsible. Outsourcing the work never outsourced the answer.

Your customers see one company

A customer whose data leaked does not know your vendor’s name. They know yours. They didn’t sign anything with your analytics provider, billing platform, or support tool. One breach, one brand, one apology.

Where ownership actually breaks

Vendor incidents break down at the same four points, every time.

Detection

You usually hear late, and you rarely hear first. Plenty of teams learn from a journalist, a customer, or a status page. By then the clock has been running for weeks.

Scope

Almost nobody has a current list of what a given vendor can reach. The contract says one thing. The access token says another. The support portal engineering opened 2 years ago says something else.

Remediation

The fix lives on their side. The risk lives on yours. You can cut access and rotate keys, and you still cannot patch their code or verify their containment.

Proof

Your auditor wants evidence you never collected, about systems you never logged, on a timeline you did not control. That’s when the gap becomes a finding.

The questionnaire is the gap, not the control

Most programs still judge vendors on a form. SecurityScorecard’s 2026 supply chain research reports that around two-thirds of organizations rely on assessments taken at a single moment in time, while 86% of leaders say supply chain risk worries them. Treat those as directional, from one vendor’s study, but the direction matches what teams describe.

A signed questionnaire tells you what a vendor believed about itself when they filled it out. It cannot tell you which of their tokens still works in your tenant this morning.

Who owns what, written down before you need it

Every vendor breach breaks at the four handoffs above, so split them in advance and put the split in the contract.

• Detect. They find it and tell you inside a named window measured in hours. You monitor their access to your estate.
• Scope. They say what was taken and which tenants were touched. You keep an up-to-date map of your data and the systems they can reach.
• Fix. They own containment and root cause on their systems. You own cutting access, rotating keys, and closing the path.
• Prove. They owe you a written incident report. You own the regulatory filing, the customer notice, and the audit evidence.
• Shared. One named contact on each side, one agreed timeline, and a retest that shows the path is really closed.

The column teams skip is the one marked “you own.” It is also the only column a regulator, a customer, or an auditor will ever ask you about.

Four moves that close the gap before the breach

Map the vendor attack surface the way an attacker does

Procurement has a vendor list. An attacker has a different list: live integrations, OAuth grants, service accounts, shared identities, and admin portals. Continuous attack surface management should cover both, because the second list leads to your data.

Test the trust path, not the vendor’s certificate

The 2026 incidents followed a pattern. Attackers took developer tooling, package repositories, and analytics integrations, then rode the trust into customer environments. A compromised analytics provider exposed data on roughly 119,000 users of one video platform. The connection was the way in, not the vendor’s front door.

So test the connection. Red teaming against vendor-held access answers a question no questionnaire can: if this partner is owned tomorrow, how far does the attacker get, and how fast do we see it? Continuous penetration testing keeps that answer current as integrations change, which they do every sprint.

Write incident clauses that actually help you

Most vendor security addenda are written to assign blame later. Write yours to shorten the next 72 hours.

• Notification in hours, with a defined trigger, not “promptly.”
• A named security contact and an escalation path that is a person, not an inbox.
• Evidence rights: logs, scope statements, and a written incident report you can hand to a regulator.
• The right to retest after they tell you it is fixed.
• A duty to tell you when their own subprocessors change.

Keep the evidence trail live

Disclosure clocks start before a vendor finishes investigating. If your evidence only exists as screenshots gathered after the fact, you will file late or file thin. Collect it as you go, including access reviews, integration inventories, and retest results.

How Secure.com helps

Secure.com puts governed AI teammates on top of the stack you already own, so vendor-connected risk gets tested and documented on a normal week instead of a bad one. Your team sets the rules. The teammates do the work.

• The Red Teammate attacks approved scope and validates what is actually exploitable across vendor-held access, so you learn the blast radius before an attacker does.
• Findings move straight into governed defensive work, with human approval on anything consequential.
• Exposure across integrations, tokens, and portals is tracked as it changes, not once a year.
• We log every recommendation, approval, action, and retest, so you have the audit evidence you need when a vendor incident lands.
• Start with one teammate, keep your existing tools, and run it yourself or let Secure.com run it for you.

Frequently asked questions