Half of breaches now involve a third party. Every clock starts too late

The number that changed

Verizon published the 2026 Data Breach Investigations Report on 19 May 2026. Third parties were involved in 48% of all breaches, up 60% on the previous year, when the figure was 30%.

Half. Third-party risk stopped being a category of breach and became a property of most of them.

Every clock starts at awareness

This is the structural point, and it is worth stating precisely because it is where the contractual thinking falls apart.

What the notification deadlines actually measure

Regime	Deadline	Clock starts at
NIS2 Article 23, early warning	24 hours	Becoming aware that a significant incident has occurred
NIS2 Article 23, incident notification	72 hours	The same awareness
NIS2 Article 23, final report	1 month	The same awareness
GDPR Article 33	72 hours	Becoming aware of the personal data breach
DORA, initial report	4 hours	Classifying an ICT incident as major
Typical vendor contract clause	24 to 72 hours	The vendor determining that an incident occurred

Three separate regimes, three different durations, one identical trigger. Not one of them starts at the moment of compromise, because no regulator can require an organisation to report something it does not know about.

Every one of those clocks is keyed to somebody noticing. That is not a drafting flaw: a regulator cannot require you to report what you do not know. But it means the number your contract specifies is the last leg of the exposure, not the whole of it.

Where the time actually goes in a vendor compromise

Day 0
The vendor is compromised
No clock is running. Nobody knows.
Days to months
The access is used
Against the vendor, and against the vendor customers. Still no clock.
Day D
The vendor becomes aware
Every legal and contractual deadline begins here, and not before.
D + 24 to 72 hours
You are notified
The only segment your contract governs.
After that
You begin your own investigation
Your own regulatory clocks start at your awareness, which is now.

Only the final segment is governed by your contract. Everything before it is determined by the vendor's own detection capability, which is the variable nobody assesses.

Where a supplier notification loses its usefulness

Supplier detects and confirms35%

Supplier assesses scope and legal position30%

Supplier notifies customers20%

Your window to respond15%

Illustrative shape rather than measured data, and the claim is the ordering. Almost all of the delay accumulates before you are told, in stages you cannot influence, which is why the remaining response window is the smallest bar on the chart.

What this means for assessment

Third-party assessment overwhelmingly measures the wrong property. A questionnaire asks whether the vendor has an incident response policy, whether it holds a certification, whether the contract contains a notification clause. All three can be true of a vendor that takes a month to spot an intrusion.

What the questionnaire establishes

A notification clause exists and specifies a duration.
The vendor holds a certification.
The vendor has a documented incident response process.
The vendor answered 140 questions.

What determines your actual exposure

How long the vendor has historically taken to detect its own incidents.
What the vendor is monitoring, and whether it covers the systems holding your data.
Whether the vendor would recognise misuse of the access it holds into your environment.
What you can see yourself, independent of being told.

None of the right-hand column appears on a standard questionnaire, and the first item is answerable: ask for the detection-to-disclosure interval on their last two incidents. A vendor that cannot answer has told you something. A vendor that will not answer has told you more.

Detect the consequences yourself

Since the notification will be late by construction, the only control that shortens the exposure is one you operate.

The connective tissue here is the same as the MCP connector problem: a vendor integration is a standing grant of authority into your environment. If it is exercised by someone who should not have it, that is visible on your side: new OAuth grants, API calls outside the vendor's normal pattern, access from unfamiliar infrastructure, vendor credentials surfacing in stealer logs.

The asymmetry nobody prices

Two clocks run from the same moment and only one of them is yours.

Your regulatory obligation begins when you become aware, and awareness is a low bar: a supplier email counts. But the supplier's obligation to tell you is governed by a contract, and the contract almost always states a period in days rather than hours. So the timetable that decides whether you can meet your duty is set by a document your procurement team signed, often years ago, usually without a security review.

That is worth stating plainly because it inverts where the effort should go. Most organisations respond to this class of incident by improving their own detection and their own runbook, both of which operate after notification. The control that actually changes the outcome operates before it, and it is a clause.

The clause worth having is not "notify without undue delay". It is a stated number of hours, a named contact who is not a generic mailbox, an obligation to notify on suspicion rather than on confirmation, and a right to your own data during the incident rather than after it.

What to check this week

Take this with you

Third-party exposure, measured rather than asserted

Ask your top-tier vendors one question: on your last two incidents, how long between compromise and detection? That single answer predicts your exposure better than the whole questionnaire.
Inventory standing vendor access into your environment: OAuth grants, API keys, VPN accounts, support tunnels. That list is what a vendor compromise actually hands over.
Alert on vendor integration behaviour, not just vendor announcements: new grants, unusual API volume, access from new infrastructure.
Tier vendors by blast radius and pre-decide the disconnect. Deciding whether to sever a critical integration during an incident costs the hours you do not have.
Map which of your own clocks a vendor incident starts (NIS2 24 hours, GDPR 72 hours, DORA 4 hours for major ICT incidents) and confirm the vendor notice reaches whoever starts them, rather than a procurement mailbox.
Rehearse the case where the vendor never notifies and you find out yourself, because at 48% third-party involvement that is now an ordinary scenario.

The regulatory scope checker works out which of NIS2, DORA and the UK regime apply to you, and the supply chain assurance service covers the assessment redesign.

Key facts

The Verizon 2026 Data Breach Investigations Report, published 19 May 2026, found third parties involved in 48% of all breaches, a 60% increase on the previous year's 30%.
NIS2 Article 23 requires an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month, each measured from becoming aware that a significant incident has occurred.
GDPR Article 33 requires notification within 72 hours of becoming aware of a personal data breach.
DORA requires an initial report of a major ICT incident within 4 hours of classifying it as major.
No notification deadline in any of these regimes starts at the moment of compromise; each starts at awareness, so none bounds the interval between a vendor being compromised and the vendor noticing.
A contractual notification clause therefore governs only the final segment of the exposure window, not its duration.