Five months to tell anyone

Clarity Telecom, a fiber internet and telecommunications provider based in Denver, discovered a cybersecurity incident in December 2025.

Their customers found out in May 2026.

Five months passed between discovery and notification. A lawsuit followed within days of the notices going out. The complaint alleged that Clarity had discovered the incident months earlier and failed to notify affected customers within a legally required timeframe.

The technical failure that caused the breach is almost beside the point now. What's driving the litigation is the response.

The question has changed.

Breach litigation used to focus primarily on how an attack happened and whether the organization had adequate technical controls in place. That question still gets asked.

But a second question has become just as consequential: why did it take so long to tell anyone?

California's updated notification law now requires disclosure within 30 calendar days of discovery. New York shortened its reporting window in 2025. Roughly 20 states now specify a numeric deadline. The legal environment around breach notification has tightened significantly, and organizations whose incident response plans were built around older "without unreasonable delay" standards are finding those plans don't hold up anymore.

Why notification gets delayed:

Almost never because the security team didn't know they needed to notify. Usually because the decision of when to notify, who to notify, and what to say sits in a gap between legal, communications, the security team, and executive leadership - and nobody has clear authority to move it forward.

Legal wants to understand the full scope before saying anything. Communications wants to control the narrative. Leadership wants to minimize regulatory exposure. Security wants to act immediately.

Everyone has legitimate concerns. Nobody owns the decision. The clock keeps running.

Analysis of post-incident reviews suggests that roughly 63% of breaches involve significant coordination or communication failures during the response - delayed stakeholder notification, conflicting decision authority, missed regulatory deadlines, and inadequate documentation. The coordination gap, not the technical failure, is what determines how bad the outcome gets.

This is what security program governance is actually for.

Not just the controls that prevent breaches, but the frameworks that determine what happens when a breach occurs. Who has authority to make notification decisions. What the documented escalation path looks like. How legal, communications, and security coordinate under time pressure. What the regulatory obligations are across every jurisdiction where customers live.

These aren't decisions you make well in the middle of an incident. You make them beforehand, when there's no pressure, and document them clearly enough that anyone can follow them at 2am on a Tuesday.

CISM focuses on exactly this layer of security management. The program governance that determines whether your organization responds well to incidents, not just whether you detect them.

Our next CISM Bootcamp runs November 3–6. Four days with Kelly Handerhan, and our materials are fully updated to match the November 3 exam changes.


Best,
The DestCert Team