Breach notification timelines: 24, 48, or 72 hours

Every data processing agreement has a clause that says the vendor will notify the customer of a personal data breach within some number of hours. The number is usually 24, 48, or 72. The legal team negotiates it, the number goes in, and it sits in the document for the life of the agreement.

Then a breach happens. And the question nobody spent much time on at signing becomes the most operationally loaded question of the incident: what counts as discovery, what counts as notification, what counts as "undue delay," and who was supposed to tell whom first.

A breach notification timeline is not just a number in a contract. It's a commitment about how fast the vendor's incident response process can execute under pressure, and how much time the customer has to meet their own regulatory obligations. The clause gets more thoughtful every year, and the gaps between clauses that look similar are usually where the real risk lives.

Why the timeline matters

Three distinct things make the breach notification timeline consequential.

Regulatory clocks

GDPR generally requires controllers to notify supervisory authorities of a personal data breach within 72 hours of becoming aware of it, where feasible. That clock starts when the controller becomes aware, which, for a SaaS customer, usually means when the vendor tells them. Every hour the vendor delays shortens the customer's window.

Other regimes have different clocks. HIPAA requires covered entities to notify affected individuals within 60 days. Various US state privacy laws specify ranges from 30 to 90 days. Financial services regulators increasingly impose shorter windows, some as short as 24 or 36 hours for critical incidents.

The common pattern: the customer's clock starts when they're notified, and the customer's downstream obligations (to regulators, affected individuals, enterprise buyers, insurance carriers) depend on having enough runway to meet them.

Customer trust and contract flow-down

Enterprise customers increasingly pass through their own breach notification requirements to their vendors. A SaaS product that serves financial services customers will often be required by those customers to notify within 24 or 48 hours, because the bank itself is on a 48-hour clock with its regulator and needs the vendor to clear first.

This creates a ratchet effect. A vendor's slowest breach notification timeline across their customer base tends to become their operational standard, because promising faster to some customers than they can actually deliver is untenable.

Operational readiness signal

A vendor that agrees to a 24-hour breach notification timeline is committing to an incident response capability that can triage, confirm, and escalate a security event within a single business day. That's a meaningful operational commitment. A vendor that insists on 72 hours may have a less mature response function, or may be preserving flexibility to investigate before disclosing.

Neither is inherently wrong, but the timeline is a signal worth reading.

What the numbers actually mean

24 hours

The aggressive end. Typically seen in financial services, healthcare, and contracts with very large enterprise customers.

What it requires operationally:

• 24/7 incident response coverage. A breach detected on Friday night has to be escalated externally by Saturday night.
• Fast-track communication protocols. Customer contacts maintained in a system the incident response team can reach without hunting.
• A willingness to notify before full investigation. A 24-hour clock doesn't allow for complete root cause analysis before initial notification.

What it tends to produce:

• Initial notifications that are light on detail ("we have identified a potential incident affecting your account; investigation is ongoing") with follow-up updates as the picture clarifies.
• Occasional false positives. Fast notification means sometimes notifying about events that turn out not to be breaches.

24 hours is a reasonable ask when the customer has its own tight regulatory clock. It's an expensive commitment for vendors to honor well.

48 hours

A middle ground that's become common in enterprise SaaS. Offers the vendor meaningful time to triage before disclosing, while still leaving the customer a workable window.

What it requires operationally:

• Business-hours incident response with on-call escalation for weekends.
• A triage process that can distinguish confirmed breaches from suspected incidents within a business day.
• Defined notification contents that don't require full forensic analysis.

48 hours is where a lot of negotiated clauses land. It's the smallest number most vendors will agree to without special effort, and it covers most enterprise customer needs.

72 hours

The market default, mirroring the GDPR supervisory authority timeline. Most template DPAs start here.

What it requires operationally:

• A functioning incident response process. Not necessarily 24/7, but reliable.
• Clear internal criteria for what counts as a reportable breach.

72 hours is adequate for customers whose own obligations allow for it. It starts to fail for customers with tighter downstream commitments. Negotiating down from 72 is one of the more common DPA redlines.

"Without undue delay"

Some clauses use this phrase instead of a specific number. It's GDPR's own language for the processor-to-controller notification (as distinct from the controller-to-regulator 72-hour clock, which is specified).

In practice, "without undue delay" defaults to whatever the customer can later argue was reasonable. Vendors prefer it because it preserves flexibility. Customers prefer specific numbers because they're enforceable. A well-negotiated clause usually replaces "without undue delay" with a specific maximum, with "without undue delay" retained as the standard within that cap.

Where breach notification timelines break down

Even with a clear number, several recurring issues come up when the clause is actually exercised.

When does the clock start?

"Within 72 hours of becoming aware of a personal data breach" is the standard phrasing. But what counts as "becoming aware"?

• Does the clock start when the vendor's automated monitoring fires an alert?
• When a security engineer confirms the alert is real?
• When the incident is classified as a breach (as opposed to a security event)?
• When leadership is briefed?

Different vendors will interpret this differently. Sharper clauses define "awareness" explicitly, typically tying it to a specific internal determination rather than the initial alert. The definition matters because in a fast-moving incident, hours of ambiguity are real hours.

What counts as a "breach"?

GDPR defines a personal data breach broadly, any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. The contract usually mirrors this definition, but the edges vary.

• Is a failed phishing attempt on a vendor employee a breach? Probably not.
• Is a successful phishing attempt that led to unauthorized access to a support tool that contained customer data? Almost certainly yes.
• Is a sub-processor incident that may have affected the customer's data? Depends on the clause.
• Is a ransomware event where the attacker encrypted but didn't exfiltrate data? Usually yes, under most privacy regimes.

The definition of "breach" in the DPA should match the definition the vendor's incident response team uses internally. Mismatches are where disputes arise.

What has to be in the notification?

GDPR specifies required contents for supervisory authority notifications: nature of the breach, categories and approximate numbers of data subjects affected, likely consequences, measures taken. Contracts usually require similar contents for processor-to-controller notifications.

Where clauses vary:

• Some require a preliminary notification within the timeline and a detailed notification within a longer window.
• Some require the vendor to provide "all information reasonably necessary for Customer to meet its own notification obligations."
• Some list specific fields the notification must contain.

The "all information reasonably necessary" phrasing is the most customer-favorable. It puts the burden on the vendor to understand the customer's downstream obligations, not just to fill in a checklist.

Who is notified?

The notification has to reach a human who can act on it. Clauses that say "notice to Customer at the address set forth in the Agreement" can fail if the address is generic. Better clauses specify a designated security contact, require maintenance of up-to-date contact information, and allow multiple communication channels (email, phone, in-product notification).

Weekends and holidays

A 72-hour clock that starts at 6pm on a Friday runs out at 6pm on Monday. That's fine if the vendor's incident response runs through the weekend. It's a problem if "business hours" is implicit in the clause. Most modern clauses make the hours calendar hours, not business hours, but it's worth checking.

Negotiation asks worth making

A handful of improvements that vendors will often accept:

• Specific timeline in calendar hours (not business hours), 24, 48, or 72 depending on the customer's downstream needs.
• Defined "awareness" trigger, typically a specific internal determination, not just the initial alert.
• Preliminary and detailed notification structure, preliminary within the tight window, detailed within a longer one, which gives the vendor triage room without sacrificing customer runway.
• "Reasonably necessary information" language, requires the vendor to support the customer's downstream notification obligations, not just to hit a checklist.
• Named security contact, both sides designate an on-call contact, with commitments to keep the contact current.
• Sub-processor breach pass-through, when a sub-processor has a breach affecting customer data, the vendor notifies within the same timeline.
• Incident response cooperation, commitment to support the customer's investigation, including providing logs, access records, and forensic artifacts.

What incident response teams actually want

Beyond the contract language, teams that work well with vendors during breaches usually rely on a few operational habits:

1. Pre-incident contact exchange. The first time a customer and vendor exchange security contacts shouldn't be during a live incident. Enterprise programs often include a tabletop exercise or at least a contact test during onboarding.
2. A shared understanding of what triggers notification. A one-page joint document that says "these are the events that will trigger notification, these are the expected contents, these are the escalation paths" reduces ambiguity when the real event happens.
3. Clarity about public disclosure coordination. Who issues a public statement, and when, is a recurring source of conflict during breaches. Addressing it in advance avoids surprises.
4. Logs on hand. A customer that wants its own forensic view needs access to logs. Commitments to log retention and access during incidents belong in the DPA alongside the notification timeline.

The bottom line

The breach notification timeline in a vendor contract is one of the smallest-looking clauses and one of the most consequential when something goes wrong. The number, 24, 48, or 72, matters, but the surrounding mechanics matter more: what triggers the clock, what the notification has to contain, who receives it, and how the vendor operationally executes when the phone rings on a Saturday night.

Teams that treat the timeline as an operational commitment and not just a contract term tend to end up with clauses that work when exercised. Teams that treat it as boilerplate find out the gaps in the clause the hard way.