Breach Notification Timing: What SaaS Companies Need to Know

You discover a security incident on a Friday afternoon. Customer data may be exposed. The clock is now ticking — but toward what deadline?

The answer depends on where your affected users are located and what you've agreed to in your customer contracts. This guide covers the key deadlines you need to know.

1.      Why Timing Matters

Breach notification timing matters for three reasons:

·         Regulators take delays seriously. A late notification can turn a minor breach into a major enforcement action.

·         Contracts are often stricter than the law. Your customer agreements may require notification faster than any regulation. Miss that deadline and you've handed them grounds for termination.

·         The clock starts earlier than you think. Most frameworks start the timer when you become "aware" of a breach — not when you've finished investigating.

2.      US Requirements: The State Patchwork

There's no federal breach notification law for most industries. Instead, each state has its own rules.

The strictest deadlines:

  • Florida, Colorado, Washington: 30 days

  • Ohio, Vermont, Oregon: 45 days

  • California, New York, most others: "Without unreasonable delay" (interpreted as 30-45 days)

Attorney General notification is required in many states when breaches exceed a threshold — typically 250-500 affected residents.

Practical approach: If you have users across multiple states, treat 30 days as your deadline.

3.      GDPR: The 72-Hour Rule

GDPR has the tightest regulatory deadline most SaaS companies will face.

·         Notification to supervisory authority: 72 hours. You must notify the relevant data protection authority within 72 hours of becoming "aware" of a breach. That's calendar hours — weekends count.

·         Notification to individuals: "Without undue delay". If the breach poses high risk to individuals, you must notify them directly, typically within days of notifying the regulator.

What triggers the clock: You're "aware" when you have reasonable certainty that personal data was compromised. You don't need to know the full scope. The moment you know something bad happened, the 72 hours starts.

The UK has the same 72-hour requirement under UK GDPR.

4.      Contractual Deadlines: Often the Real Constraint

Your customer contracts may be stricter than any regulation.

Deadline:

  • 24 hours - Aggressive - common in enterprise/financial services

  • 48 hours - Tight but achievable

  • 72 hours - GDPR-aligned

  • 5 business days – More realistic

The problem with 24 hours: You often can't confirm a breach occurred, let alone determine scope, within 24 hours. Yet many enterprise contracts include this deadline.

How to negotiate: Push for tiered notification (preliminary notice within 24 hours, details within 72), or a trigger based on "confirmation" rather than "discovery."

5.      When Does the Clock Start?

Different frameworks use different triggers:

  • Discovery: The moment you learn an incident occurred (earliest)

  • Awareness: When you have reasonable certainty it qualifies as a breach

  • Determination: When you've confirmed scope (latest, least common)

GDPR uses "awareness." Most US states use "discovery" or similar.

The key point: You can't wait until your investigation is complete. You're expected to notify based on what you know, then supplement as you learn more.

6.      Who Gets Notified

A single breach can trigger multiple notifications:

·         Regulators — Data protection authorities (GDPR), state attorneys general (US)

·         Affected individuals — The people whose data was compromised

·         Customers — Your B2B customers, per your contract terms

Each has different deadlines and content requirements. Customer notification doesn't satisfy your regulatory obligations.

7.      Exceptions

Not every incident requires notification:

·         Low-risk breaches (GDPR): If the breach is unlikely to result in risk to individuals, you may not need to notify — but you must document your reasoning.

·         Encrypted data: Many frameworks have safe harbors if the data was encrypted and the key wasn't compromised.

·         Limited data types: Some US state laws only cover specific categories (SSNs, financial accounts, health data). A breach of email addresses alone may not trigger notification.

8.      Common Mistakes

Waiting for the investigation to finish. The clock starts at awareness, not when you have complete answers.

Forgetting contractual deadlines. You're focused on GDPR's 72 hours while your customer contract required 24.

Not knowing which regulator to notify. Under GDPR, you notify your "lead supervisory authority." Figure this out before you need it.

Over-notifying. Not every security incident is a notifiable breach. Unnecessary notification creates attention and exposure for no reason.

9.      What to Do Now

  • Know your deadlines. Map your regulatory obligations by user location. Review customer contracts for notification requirements.

  • Build templates in advance. Don't draft notifications from scratch during an incident.

  • Establish escalation paths. The person who detects an incident at 3am needs to know exactly who to call.

  • Run a tabletop exercise. Practice your response process before you need it.

10. Conclusion

Breach notification timing is about preparation. Know your deadlines, build processes that can meet them, and have your templates ready before the clock starts running.

Need help with breach response planning? Reach out for a consultation.

Next
Next

GDPR for US SaaS: A No-Nonsense Guide