Skip to content
← BlogComplianceAnalysis5 min read

Breach notification windows keep shrinking — 2026 made that concrete

California's SB 446 replaced a vague 'unreasonable delay' standard with a hard 30-day clock in 2026. Why fixed deadlines are becoming the norm for incident response.

By Norbelys Chirinos, Co-founder

Founder-reviewed ·How we research and correct articles

Until January 1, 2026, California’s breach-notification law — long treated as the de facto US benchmark, since so many other states modeled their own statutes on it — required disclosure “in the most expedient time possible and without unreasonable delay.” That phrase did a lot of quiet work for fifteen-plus years: it gave companies room to investigate before notifying, and it gave regulators an argument, after the fact, that a given delay had or hadn’t been reasonable. SB 446 ended that ambiguity. As of this year, California requires notification to affected residents within a hard 30 calendar days of discovering a breach, with a separate 15-day clock for notifying the Attorney General once 500 or more residents are affected. “Reasonable” is no longer the standard. A number is.

Why a fixed number is a bigger change than it looks

An open-ended standard and a fixed deadline sound like they should produce similar outcomes for a company that’s actually moving with urgency — but they don’t behave the same way operationally. Under “without unreasonable delay,” an incident- response process that took six weeks because the investigation was genuinely complex had at least an argument. Under a 30-day hard deadline, that same six-week investigation is simply late, full stop, with narrow, specifically enumerated exceptions (accommodating a law-enforcement request, or determining the actual scope of the breach) rather than an open judgment call. That shift moves the real work earlier: you can’t out-argue a calendar the way you might have been able to out-argue “reasonable,” which means the investigation, legal review, and notice-drafting process all need to fit inside a fixed window from day one, not get compressed into whatever’s left of it once the ambiguous phase runs long.

California isn’t acting alone here, either — New York has adopted its own 30-day notification mandate, and the broader national pattern is now a large minority of states specifying a numeric deadline rather than an open standard, generally in the 30-to-60-day range. The direction is consistent even where the exact number differs: incident response is being timed against a clock a regulator can point to, not a standard a company gets to argue about later.

Scope is widening at the same time timing is tightening

The other half of the shift is less visible in headlines but matters just as much operationally: what counts as a reportable breach, and who has to be told, keeps expanding alongside the shorter clocks. More jurisdictions are treating a wider range of data elements as triggering notification, and the AG-notification threshold in California (500+ residents) means a breach that would once have been handled quietly, resident by resident, now also has a mandatory regulator-facing disclosure the moment it clears a fairly ordinary size. A shorter deadline and a broader trigger together mean more incidents cross the “you must formally notify, on a fixed clock” line than did a year ago — not because breaches themselves got more common, but because the reporting bar moved down and the clock moved up at the same time.

What this means for incident-response readiness, generically

None of this is specific to any one company’s stack — it’s a planning problem every organization holding personal data now faces, regardless of size or industry:

  1. The investigation phase can’t be open-ended anymore. If your internal process assumes “we’ll notify once we understand what happened,” that assumption needs a hard stop built in — 30 days total leaves a lot less room than it sounds like once legal review, drafting, and delivery are subtracted from it.
  2. Notification-ready templates need to exist before an incident, not during one. Drafting a compliant notice from scratch under a fixed deadline, while also still investigating, is how deadlines get missed. A reviewed template that only needs incident-specific facts filled in buys back days that matter.
  3. Know your actual thresholds in advance. The number of affected individuals that triggers AG or regulator notification differs by jurisdiction — knowing in advance which threshold applies to which state (or country) you operate in means you’re not researching that for the first time mid-incident.
  4. Multi-jurisdiction incidents need a single coordinated timeline, not the slowest one. If a breach affects residents across several states or countries with different fixed deadlines, the effective deadline for your whole response is the shortest one that applies to anyone affected — treating it as one clock, not several independent ones, is what actually keeps you compliant everywhere at once.

The direction is set

Whatever your jurisdiction’s current specific number is, the trend across every market watched in this shift points the same way: shorter fixed windows, wider triggering scope, less room for “we were still investigating” as an answer. Building an incident-response process that assumes the clock will keep getting tighter — rather than one calibrated to today’s deadline exactly — is the version that doesn’t need rebuilding the next time a legislature moves the number again.

What this means if a sending platform is part of your data footprint

A cold-outreach tool holding thousands of contact records, with mailbox credentials attached, is squarely in scope for the same 30-day math as any other system touching personal data — the notification clock doesn’t distinguish “core database” from “marketing tool.” Two things determine how that clock feels in the moment: how much you’re actually storing that could leak, and how fast you can produce a complete, accurate account of what happened.

Norbelys narrows the first exposure by design: mailbox credentials — SMTP passwords, OAuth refresh tokens — are encrypted at rest and never returned over the API once stored, so an incident touching the platform can’t turn into “here’s the plaintext credential list” the way it can with a tool that hands raw secrets back to whoever asks for them. And a suppression list that’s enforced on every send, plus a complete export bundle you can pull on demand, means the second half — accounting for who was contacted, what was suppressed, and what data exists on a given record — is answerable rather than reconstructed under deadline pressure. Neither replaces your own incident-response plan, but a platform that can’t hand back a credential it never returns, and can produce a complete record without a scramble, is one less unknown inside a fixed 30-day window — which is the standard worth holding Norbelys, or any vendor touching your contact data, to before an incident forces the question.