Vendor Breach Detection Delays

A healthcare data analytics company discovered on a Tuesday evening that their primary data processing environment had been accessed by an unauthorised actor. The intrusion had begun six days earlier , a service account credential had been compromised through a phishing attack on a contractor, and the attacker had spent six days conducting reconnaissance, accessing analytics datasets, and exfiltrating a subset of patient-attributed records. The detection itself was reasonably prompt once the anomalous access pattern was identified through their EDR platform. The response timeline that followed, however, created a second problem for the vendor's customers: the vendor's security team spent three days investigating and scoping the breach before issuing any customer notification. They wanted to be certain of what had been accessed before communicating. This desire for accuracy before disclosure is operationally understandable. From the customer's perspective, three days of unnotified exposure meant three days of operating without activating their own breach response procedures, without notifying their own regulators within applicable timelines, and without engaging their own legal and communications teams. The customer's seventy-two-hour GDPR notification window had been running since Tuesday. They learned about it on Friday.

What are Vendor Breach Detection Delays, Really?

Vendor breach detection delays are the gap between when a security incident at a vendor environment begins, when the vendor detects it, and when the vendor's customers are notified. These are three distinct timeline events, each of which creates a different category of customer risk. The dwell time gap , between incident initiation and vendor detection , is the period during which the attacker operates in the vendor's environment without discovery. The investigation gap , between detection and customer notification , is the period during which the vendor knows about the breach and the customer does not. The response gap , between customer notification and customer response initiation , is the time required for the customer to activate their own incident response procedures after receiving the vendor notification.

The investigation-first notification pattern is the most consequential vendor behaviour creating customer risk. Vendors who discover a security incident typically want to confirm scope, understand impact, and prepare a comprehensive notification before informing customers. This approach protects the vendor from the reputational damage of a preliminary notification that turns out to be more severe than initially communicated, and from the legal exposure of notifying customers of a breach scope that later proves inaccurate. These are legitimate vendor concerns. They conflict directly with the customer's interest in early notification that preserves the maximum time for their own response and regulatory compliance.

The regulatory timeline conflict is the specific legal dimension. GDPR requires breach notification to supervisory authorities within seventy-two hours of the controller becoming aware. Financial services breach notification requirements under DORA require similar timelines. When the vendor , acting as data processor , detects a breach and spends seventy-two hours investigating before notifying the controller, the controller's notification window may have already elapsed by the time they receive the vendor notification. The controller is late not because of their own detection failure but because their vendor's investigation-first approach consumed the notification window.

• Dwell time before detection , attacker in vendor environment for days or weeks before discovery
• Investigation-first notification , vendor confirming scope before notifying customers, consuming notification windows
• Customer regulatory timeline consumed , GDPR or financial services notification periods running during vendor investigation
• No preliminary notification obligation , contracts not requiring notification upon detection, only upon scope confirmation
• Notification threshold ambiguity , when does the breach rise to the level requiring immediate customer notification

Why this matters

Vendor breach detection delays matter for TPRM because the customer's regulatory obligations, incident response timeline, and risk mitigation options are all directly affected by how quickly the vendor notifies them after a breach is detected. The customer who receives a breach notification three days after detection and learns that the vendor's investigation consumed that time has lost three days of their own response window , three days of customer notification preparation, regulatory filing preparation, and technical response that could have been initiated immediately upon learning of the breach.

The DORA and NIS2 dimension is the emerging regulatory pressure point. The EU's Digital Operational Resilience Act requires financial entities to notify their competent authority within four hours of classifying an ICT-related incident as major. NIS2 requires essential and important entities to submit early warnings to national authorities within twenty-four hours of becoming aware of a significant incident. These timelines create direct regulatory exposure for customers who receive vendor breach notifications after the applicable notification window has already elapsed due to vendor investigation delays.

Where most teams get this wrong

The most consistent failure is not specifying the notification trigger in contracts. Contracts that require notification 'promptly' or 'as soon as reasonably practicable' following a breach leave the notification trigger open to vendor interpretation , which typically means notification once investigation is sufficiently advanced, not notification upon detection.

• Notification trigger not specified , 'promptly' interpreted as after investigation rather than upon detection
• No preliminary notification requirement , initial notice upon detection not contractually required
• Investigation gap not addressed , contract silent on vendor behaviour during investigation period
• Regulatory timeline not incorporated , notification SLA not calibrated to customer's regulatory obligations
• Contractual SLA not tested , notification timeline never verified through tabletop or past incident review

What good looks like

Mature vendor breach notification frameworks require preliminary notification upon detection , a brief initial notice confirming that a security event has been identified and that investigation is underway , followed by supplemental notification as investigation findings become available. This two-stage approach satisfies the customer's need for early notification while accommodating the vendor's need for investigation time.

• Preliminary notification upon detection , contractual requirement for initial notice within hours of detection, regardless of investigation status
• Supplemental notification cadence , defined schedule for investigation updates
• Customer regulatory timeline incorporated , notification SLA calibrated to the most stringent applicable regulatory requirement
• Detection-to-notification SLA defined and tested , specific timeline in contract, validated through past incidents or tabletop
• Joint incident response procedure , pre-defined coordination between vendor and customer response teams

Tooling

TPRM Contract Management , notification clause design

Contract management platforms and TPRM tools that support notification clause tracking enable monitoring of whether vendor contracts include preliminary notification requirements and whether those requirements have been exercised in past incidents. For TPRM practitioners, reviewing whether contracts distinguish between preliminary detection notification and confirmed breach notification provides the clause specificity that standard promptly language does not.

Continuous Security Monitoring , BitSight, SecurityScorecard

Continuous external security rating monitoring can provide early signals of vendor security incidents , publicly observable indicators such as increased vulnerability exposure, anomalous network behaviour signals, and breach intelligence feeds , that may surface before vendor notification. For TPRM practitioners, monitoring continuous security ratings for vendors alongside reliance on contractual notification provides a parallel detection channel.

Governance challenges

The governance challenge with vendor breach detection delays is the investigation-notification tension. Vendors face genuine pressure to investigate before notifying , premature notification of an unscoped breach can trigger customer panic, regulatory escalation, and reputational damage disproportionate to the confirmed impact. The governance resolution is designing the notification obligation around stages rather than a single event: preliminary notification upon detection, confirmed scope notification once investigation reaches defined milestones, and ongoing updates thereafter.

• Require preliminary notification upon detection , specific SLA in hours, not days
• Calibrate notification SLA to customer's regulatory requirements , GDPR, DORA, financial services timelines
• Define notification stages , detection notice, preliminary scope, confirmed scope
• Test notification SLA , ask vendors for notification timelines from past incidents
• Include preliminary notification in DPA , data protection agreement, not just security addendum

If you are a small team

Review your top five vendor contracts and identify the specific notification trigger language. Is notification required upon detection, upon scope confirmation, or simply 'promptly'? For any contract using promptly or similar language, negotiate a specific preliminary notification SLA , even a simple clause requiring initial notice within twenty-four hours of detecting a security event, with scope to be confirmed in a subsequent communication, addresses the investigation-first problem that vague language creates.

• Review notification trigger language in top five vendor contracts
• Identify contracts requiring notification upon scope confirmation rather than detection
• Negotiate preliminary notification SLA , initial notice within 24 hours of detection
• Calibrate final notification SLA to most stringent applicable regulatory requirement

What to require

Ask directly:

"In your last security incident affecting customer data, what was the timeline from initial detection to customer notification , and does your current notification procedure require preliminary customer notification upon detection or only after investigation confirms scope?"

Expect as evidence

• Detection-to-notification timeline from past incidents
• Notification procedure distinguishing preliminary and confirmed notification
• Commitment to preliminary notification within defined hours of detection
• Investigation-to-customer timeline from most recent incident

A vendor who confirms a breach notification process should be asked specifically what triggers the notification , detection or confirmed scope. The answer determines whether the customer's regulatory window is preserved.

How to evidence it

• Notification trigger clause review records
• Preliminary notification SLA documentation
• Regulatory timeline calibration records
• Detection-to-notification SLA testing

Key Takeaway

The breach was detected Tuesday. The customer was notified Friday. The seventy-two-hour GDPR window ran from Tuesday. By Friday it was already elapsed. The vendor notified correctly under their interpretation of their obligation. The customer's regulatory clock did not wait for the investigation. Detection and notification are two events separated by a gap that the contract must specifically address. Require preliminary notification upon detection. Define the SLA in hours. Calibrate it to the most stringent regulatory deadline. Test it before the incident that requires it.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations