Breach notification delay: the management risk that gets underestimated
Companies discover breaches months after the event. I look at why this is a leadership problem, not just a security team problem.
Research over the past several years consistently shows that the average time between a system intrusion and its detection runs to several months. In some high-profile cases, more than a year. The company continues operating, unaware that customer data or internal documents are already accessible to outsiders.
This is not purely a technical problem. It is a management one.
Why detection lags
Attackers who have gained access do not always act noisily. Professional intrusions are designed to stay inside as long as possible - extracting data gradually, mapping the infrastructure, waiting for the right moment.
Detection lags for several reasons. Event logs are either not collected in full, or nobody reviews them regularly. Anomalies exist but there is no process that surfaces them. Internal resources for monitoring are stretched, and external monitoring is not configured.
Sometimes a breach is discovered through third parties - a partner who finds their own data on a public resource, or a security researcher who reports it.
What this means for leadership
A detection delay is not just a technical failure. It means decisions were made without knowing the real state of affairs. Negotiations with counterparties, personnel decisions, financial operations - all of this may have happened while outsiders had access to the information involved.
It also means regulatory consequences. In many jurisdictions the law requires notifying regulators and affected parties within a defined window after the company becomes aware of an incident. But if the company became aware late, demonstrating that it acted promptly is significantly harder.
And the reputational risk is of a different order. There is a difference between saying "we detected the attack within 24 hours and here is what we did" and explaining why data was accessible to outsiders for several months.
What reduces this risk
First - visibility. Authentication logs, network flows, privileged account activity need to be collected and retained. Not for manual review, but to enable investigation and automated anomaly detection.
Second - a response process. If the first person to notice something suspicious does not know who to tell or what happens next, the chain breaks. The process needs to exist before the incident, not during it.
Third - periodically testing the hypothesis "we may already be compromised". This is not paranoia, it is a professional posture. Bringing in an external team occasionally to look for signs of compromise is standard practice for organisations handling sensitive data.
Three questions for leadership
- If someone gained unauthorised access to our systems three months ago - would we know about it today? How?
- Who in our organisation is first to learn about an incident, and what happens after that?
- When did anyone last check for signs that we are already compromised?
If the answers are vague, that is not a reason for alarm. It is a reason for a conversation with the responsible people about how detection actually works.