Who Else Needs to Know Right Now
The technical team has it under control. Someone is in the logs, someone else is running queries, the channel is active, and the hypothesis about how the attacker got in is two hours from being confirmed. This is the point in an incident where most responders stop thinking about anyone outside the room.
The outside world does not stop.
Incident response has two tracks running simultaneously, and every experienced responder has a war story about organizations that handled the technical track well and got destroyed by the notification track. The attacker was evicted. The data was contained. And then the regulatory fine arrived, or the customer breach notice went out six weeks too late, or leadership found out about a significant incident from a news article rather than from the security team. The technical response was clean. Everything else was a disaster.
Who Actually Needs to Know, and Not at the End
The default assumption in most organizations is that the security team handles the incident and briefs relevant stakeholders when there is something meaningful to report. This assumption produces two-week information vacuums during which the security team is genuinely trying to be responsible by not speculating, while legal counsel has no idea a clock is ticking on regulatory notification, the communications team has no idea a breach disclosure might be coming, and the CFO is about to approve a press release that mentions the affected system without knowing why that would be a very bad idea.
The people who need to know during an incident are not all the same people who need to act on it. Legal counsel needs to know early, before you have answers, because privilege considerations and notification obligations start accruing the moment an incident is confirmed. They do not need a full technical briefing. They need: something happened, here is what we know, here is what we do not know yet, and here is the system category involved. That is usually enough to start assessing whether a notification obligation clock has started.
The CISO or whoever has authority to make decisions about business risk needs to be in the loop at a cadence that is more frequent than "when the team has findings." They are not going to go fix it themselves. They are going to be asked questions by people above them, and it is considerably better for everyone if those answers are coming from a briefed decision-maker rather than a technical lead who is simultaneously trying to run the investigation.
The Regulatory Clock Problem
Most industries have incident notification requirements. Healthcare, financial services, and any organization handling EU resident data are operating under frameworks that specify how quickly they must notify regulators after determining that a breach has occurred. The important word is "determining" because it is interpretable, and how you handle documentation and communication during the investigation affects what that determination moment actually is.
This is not legal advice. It is a practical observation that the security team's instinct to avoid communicating conclusions before they are certain is sometimes in direct tension with regulatory timelines that do not reward caution. The legal team needs to be in the room - or at minimum, in the channel - early enough to flag when timelines are starting to bind, because the technical team is not going to think to ask.
Most notification obligations are measured in days or hours from discovery, not from investigation completion. "We were still confirming scope" is not an argument that regulators find compelling when the notification arrived four weeks after the initial alert.
How to Brief Under Uncertainty
The hardest communication problem in an incident is that the people who need information are asking for certainty you do not have, and the natural human response is to delay communicating until you have something concrete to say. This is the wrong move in both directions: too slow for the stakeholders who need to take time-sensitive actions, and too pressuring for the technical team if every briefing generates demands for answers they are not ready to give.
The solution is structured uncertainty. Every leadership briefing during an active incident should include: what is confirmed, what is suspected but not confirmed, what specific questions the team is currently working to answer, and when the next update will be. That format gives stakeholders enough to make decisions from without asking the technical team to overclaim.
Brief on a schedule, not on demand. An update every two hours during an active investigation is far more sustainable than responding to a constant stream of individual messages asking if there is news yet. Set the cadence at the start and stick to it. People who know when the next update is coming stop generating noise in between.
The One Decision Nobody Wants to Make in Real Time
At some point in a significant incident, someone has to decide whether customers or affected individuals get notified, and when, and what the notification says. This decision almost never sits with the security team, which is appropriate. It does sit with people who need to have been briefed long enough in advance to make it thoughtfully rather than reactively.
The organizations that handle external notification well had the conversation early, before they were certain, about what the threshold for notification would be and who had authority to pull that trigger. The organizations that handle it badly are the ones where that conversation happens for the first time at 11 PM when legal just confirmed the scope and someone is asking whether the CEO needs to approve the customer email.
There is also a real risk in the other direction. Notifying customers prematurely, before you understand the actual scope of what was exposed, creates its own set of problems: inaccurate disclosures, follow-up corrections, regulatory questions about why the initial notice was wrong. The notification decision is genuinely hard. It requires current, accurate information from the technical team and clear authority from whoever owns the decision. Getting those two things in contact with each other, at the right moment, is exactly what the notification track is supposed to produce.
The Fix Is Structural, Not Heroic
None of this requires better communication skills or someone on the team who is particularly good at crisis messaging. It requires a pre-built structure: a notification matrix that identifies who gets called at which incident severity threshold, a pre-agreed briefing cadence, legal and communications already identified as part of the response function rather than a later escalation, and a named person whose job during an incident is to manage the notification track while the technical team works the other one.
That structure gets built during calm times. Incidents are when you find out whether it exists.
The technical track and the notification track are the same incident. Running them separately is how organizations end up with a clean technical response and a very expensive aftermath.