Throughout my 20+ year cybersecurity career, across DoD, U.S. federal civilian, and commercial environments, I have been involved in many incidents and associated response activities.
The pattern is remarkably consistent regardless of the organization’s size, sector, or security budget. Someone spins up a war room, someone else spins up a chat channel, a Google Doc appears with a running timeline, an executive asks for a status update that takes forty minutes and a game of telephone to assemble, and somewhere in the middle of all of it someone awkwardly asks whether anyone has started the clock on notification obligations.
That said, look at what we have actually built as an industry over the last three decades. We went from basic IT service management, to SIEM for detection, to EDR and XDR for containment, to SOAR for automating the tedious parts, to the current wave of AI SOC tooling for triage. Every one of those advances made the technical work better and almost none of them improved the enterprise work, meaning the decisions, the ownership, the obligations, and the documentation that determine what an incident actually costs an organization in the end.
Using Resilient Cyber’s partner, BreachRx as an example in this article, I want to dig into that gap, why it has become more expensive in an era of collapsing exploitation timelines, and what it looks like to treat incident response as a discipline with a real command center rather than an ad hoc scramble across disconnected tools.
Let’s take a look at how we got here, and where we still need to go.
The Clock We Never Reset
By now, it is clear that the timelines attackers operate on have detached from the timelines defenders operate on, and the evidence on this has gotten hard to dispute.
Mandiant’s M-Trends 2026, built on over 500,000 hours of frontline incident investigations conducted globally in 2025, found that the median time between initial access and hand-off to a second threat group fell from more than eight hours in 2022 to 22 seconds in 2025. Exploits remained the most common initial infection vector for the sixth consecutive year, at 32%. Google Threat Intelligence Group’s mean time-to-exploit, which measured 63 days back in 2018, is now estimated at negative 7 days, meaning exploitation is routinely happening before a patch exists at all.
I wrote about this trajectory earlier this year in an article titled, “The Zero Day Clock Is Ticking”, where the numbers tell the same story from the vulnerability side. In 2018, the median time from a vulnerability being disclosed to the first observed exploit was 771 days.
By 2021 that window had compressed to 84 days. By 2023 it was 6 days, and by 2024 it was 4 hours. This is in addition to the recent 2026 Data Breach Investigations Report (DBIR) highlighting how vulnerability exploitation is now the leading attack vector for organizations, overtaking other vectors such as compromised credentials or social engineering, which historically was in the lead.
Now, for those of us who have spent years telling executives that our detection and response capabilities are maturing, the other half of that same report is uncomfortable reading. Global median dwell time went the wrong direction, up to 14 days in 2025 from 11 days in 2024, and cases where the organization learned about the intrusion from an external party had a median dwell time of 25 days, up from 11. Attackers compressed their timelines by orders of magnitude while we got slower.
Detection has absorbed the overwhelming majority of security investment and innovation for twenty-five years, something strongly documented in work, such as Sounil Yu’s Cyber Defense Matrix and it shows, with 52% of organizations first detecting malicious activity internally in 2025, up from 43% in 2024.
The response side of the house, meaning everything that happens after someone says, “yes, this is real,” is largely still run the way it was run in 2012 with a bridge line, a shared document, and a lot of institutional memory.
Everyone in the Room, and No One in Command
Incident response sits at the intersection of nearly every business unit, and that is what makes it structurally different from the rest of security operations, involving a diverse group of both technical and non-technical stakeholders.
Within hours of an incident being declared, you have security running technical containment, IT managing systems and access, legal evaluating contractual and disclosure exposure, privacy assessing what data categories and jurisdictions are implicated, communications drafting internal and external statements, HR involved if there is an insider dimension, executives asking for accurate status, and the board asking whether this is material. That is before you get to the external parties, meaning outside counsel, forensic firms, the cyber insurer, managed service providers, regulators, customers under contractual notice obligations, involved business partners, and eventually the press.
Most of those people are not technical, and most of them are being asked to make consequential decisions from a summary that someone typed into a chat window twenty minutes ago, which then got passed along in a lossy game of telephone.
The technical execution in these situations is usually fine, since practitioners are good at containment work and generally know what to do. What breaks is enterprise coordination, and it breaks in a very specific way. Actions live in email threads, Slack or Teams channels, and a spreadsheet someone is heroically maintaining, ownership is tracked manually, and status is fragmented across half a dozen tools that were never built to talk to each other. There is activity everywhere and no authoritative, consolidated view of the incident.
In other areas of cybersecurity, we have pushed to quit tolerating this disjointed scenario and now have vendors and enterprises alike building unified cohesive platforms and sources of truth, but unfortunately not so much when it comes to incidents.
External parties make this harder rather than easier. Your forensics firm needs artifacts, your insurer needs a claim narrative, outside counsel needs a privileged workspace, and your regulator eventually needs a defensible chronology. In most organizations all four are served by someone manually exporting slices of the same spreadsheet or Google doc into email attachments, at 2 a.m., during the worst week of their professional life.
Regulatory Clocks Don’t Wait
If the coordination problem stayed internal, it would be an efficiency issue. It does not stay internal, because the reporting obligations have gotten both faster and more numerous, and they run on clocks that start whether or not your team has its act together.
Consider what a large multinational is actually holding at once. India’s CERT-In directions require reporting in-scope cyber incidents “within 6 hours of noticing such incidents.” Under DORA’s regulatory technical standards, EU financial entities must submit an initial notification of a major ICT-related incident within 4 hours of classifying it as major, and no later than 24 hours from becoming aware of it. NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month.
GDPR requires notification to the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it.” NYDFS requires notice within 72 hours of determining that a cybersecurity incident occurred, plus a 24-hour notice for extortion payments and a written justification within 30 days. The SEC’s Form 8-K is generally due four business days after a registrant determines an incident is material, and underneath all of that, the U.S. has breach notification laws in all 50 states plus the District of Columbia, Guam, Puerto Rico, and the Virgin Islands.
CIRCIA’s 72-hour incident and 24-hour ransom payment requirements are still dormant, since CISA has stated that covered entities are not required to report until the effective date of a final rule that has slipped repeatedly and is now projected for September 2026, but that is a reprieve, not a reduction, and the requirements are still likely to materialize.
Safe to say, the reporting timelines are complex and hard to juggle while also working through incident response.
None of these clocks are triggered by the incident. They are triggered by awareness, determination, or classification, which are all judgment calls made by humans under pressure, and every one of those judgment calls is later reviewable. Missing a deadline is one failure mode, however it is more common to not be able to demonstrate when the clock started or why you concluded what you concluded.
You can see the resulting confusion in the U.S. public company data. I’m subscribed to Andrew Hoog’s 8K and incident tracker, and the reporting truly is all over the place in terms of level of detail within what gets filed.
Privilege Is a Design Decision
There is a category of incident response failure that practitioners rarely think about until it is too late and the implications are real.
Every message in that incident chat channel, every comment in the running timeline doc, every speculative theory someone typed at hour three when the picture was still wrong, is potentially discoverable. Security teams communicate the way engineers communicate, which is candidly and with a lot of thinking out loud. That is the behavior you want during an investigation and exactly the behavior that reads badly when a plaintiff’s attorney reads it back to you two years later, stripped of context.
Attorney-client privilege over incident work is not automatic and it is not preserved by copying a lawyer on a thread. It depends on how the work was structured, who directed it, where it lived, and whether the organization can show a segmented, deliberate approach to sensitive communications. Doing that inside general-purpose collaboration tools designed for open information flow is difficult, and most organizations discover how difficult only in retrospect.
Additionally, and this one is almost too obvious to state, if your incident coordination lives entirely inside the productivity suite the attacker has been sitting in for two weeks, you have a shared workspace with an audience. Out-of-band access sounds paranoid right up until the moment it is the only thing that works, but even then it can get problematic with personal devices and communications intermingled with corporate ones.
This is also where the tabletop conversation gets interesting. We talk constantly about the need for exercises, and the advice is sound. However, running a tabletop in a slide deck and a conference room trains your people on a process they will not actually execute, in a system they will not actually use, against obligations they will not have time to look up. Practice that does not live in the same environment as execution is a rehearsal for a different play.
The Record Is What You Get Judged On
The personal liability narrative in our industry has run hot for a few years now, but the recent evidence is mixed. The SEC’s enforcement action against SolarWinds and its CISO was largely gutted at the motion to dismiss stage in 2024, and in November 2025 the Commission filed to dismiss the remainder with prejudice. That is a meaningful data point, and anyone telling you regulators are indiscriminately hunting CISOs should be viewed with caution.
That said, the underlying dynamic has not gone anywhere. Regulators, lawyers, insurers, and boards do not evaluate an incident purely on the technical outcome, they evaluate the process, meaning whether escalation was timely, whether executives were informed and when, whether disclosure decisions were documented with the reasoning behind them, whether obligations were tracked across jurisdictions and met, and whether leadership can demonstrate good-faith governance rather than simply claim it.
Every one of those questions is answered from the record. If the record is a reconstructed narrative cobbled together weeks later from chat exports, calendar invites, and people’s recollections, you are not defending your decisions, you are defending your memory of them, which is a much weaker and less than ideal position.
This is where I think the emerging Cybersecurity Incident Response Management (CIRM) category, which BreachRx has been a pioneer of, is pointed at a real gap in the industry.
The key thesis is that the enterprise layer of incident response deserves a purpose-built system of record in the same way detection, containment, GRC and even ticketing eventually got theirs, with clear ownership across stakeholders such as security, legal, privacy, IT, communications, and leadership, tailored playbooks and obligation tracking that surface which of those 6-hour, 24-hour, 72-hour, and four-business-day clocks apply to this incident in these jurisdictions, protected and segmented communications, evidence captured continuously as the response executes rather than reconstructed after the fact, and tabletops run inside the same environment the team will use when it counts and it’s no longer a hypothetical incident, but a real one.
Joe Sullivan, former CSO at Uber, Facebook, and Cloudflare, and an advisor to BreachRx, made the case for this strongly in their materials I read, and there are few people have who have lived through incidents at the level of scrutiny he has:
“Until I saw BreachRx, I had not seen any product that truly would have made a difference for me at Uber. Their platform could have completely changed the outcome by ensuring seamless communication, cross-organizational collaboration, and better decision-making that is documented and aligned with the law.”
Their platform embeds agentic AI into the response lifecycle through bounded, role-specific agents rather than a general-purpose chatbot bolted onto the side, with a coordinator agent orchestrating specialists for incident command, response execution, exercises, and regulatory analysis, and human approval checkpoints where they matter. It was interesting to see this multi-agent architecture applied to this use case.
Resilient Cyber subscribers know I am optimistically skeptical of agentic AI claims, but incident response is among one of the more defensible applications I have seen so far, largely because it is a workflow and context problem involving procedures, stakeholders, deadlines, approvals, and documentation. That is the kind of bounded, high-toil, high-consequence coordination work where agents earn their keep and where a chat interface alone does not.
BreachRx has also done something I have not seen elsewhere in this category, and frankly was something I was surprised to see, which is backing the product with a warranty offering up to $3 million per claim in liability protection, with no retention requirement, covering defense costs, fines, penalties, and negligence-related claims for executives and response team members personally named in regulatory or government actions. These are the sort of guarantees I recently heard longtime industry leader Jeremiah Grossman make a call for in an interview:
Very few security companies ever stand behind the effectiveness of their products with this sort of rigor honestly.
The argument is that D&O coverage frequently carries exclusions, carve-outs, or allocation disputes that leave security leaders exposed precisely when they need assurance. Whether a warranty is the deciding factor for a buyer is an open question, but putting financial skin in the game behind a defensibility claim is a stronger commitment than most vendors are willing to make, that’s for sure.
Closing Thoughts
We have spent a decade telling organizations that incidents are inevitable and that resilience matters more than prevention. I believe that, and the data keeps supporting it, especially now with AI-driven vulnerability discovery and autonomous exploitation arriving. What we have not done is give the people who actually run those incidents anything resembling the tooling maturity we handed the detection side of the house.
Attackers now move from initial access to hand-off in 22 seconds and exploit vulnerabilities before patches exist, while the enterprise response to those attacks is coordinated in a spreadsheet, a chat channel, and whatever document someone thought to create in the first ten minutes, against a stack of regulatory clocks that start ticking on judgment calls made by exhausted people at 3 a.m.
That is a very disorganized approach with very high stakes and very good odds of being reviewed later by someone who may not be sympathetic to the circumstances and stressors involved.
Whether you solve that with BreachRx, with something else, or with a painfully disciplined internal build, it’s worth asking your team some simple but not easy questions. For example, if an incident were declared this afternoon, where would the authoritative record live, and would we want a regulator to read it?
If you want to see what the platform side of this looks like in practice, BreachRx runs a walkthrough worth an hour of your time.
The line about missing a deadline being less common than being unable to prove when the clock started is on point. Regulators don't just want the right answer, they want to see the reasoning trail that got you there, and Slack was never built to be that trail.