Security incident response: who makes the decisions
During an incident there is no time to build a command chain on the fly. I look at what needs to be defined in advance and why this is a management question, not a technical one.
When a security incident happens - and sooner or later it does - the first thirty minutes determine how well or badly things will go. In those thirty minutes you need to understand the scope, make initial decisions, and begin coordination. Doing that without preparation means spending time on organisational questions instead of dealing with the incident itself.
Most organisations think about incident response as a technical task: there is an IT team, an antivirus, a firewall. That is not the picture. Responding to a serious incident is a management task with technical execution.
What needs to be decided before the incident
First - who declares an incident an incident. This is not an obvious question. A security analyst sees an anomaly - is that an incident or a suspicion? Who decides to escalate rather than "wait and see"? Without an explicit answer organisations tend to underestimate the severity and respond with a delay.
Second - who makes decisions during the incident. The technical lead handles isolation and recovery. But the decision to shut down critical systems, whether to notify customers, how to engage with regulators - that is at the executive level. That person needs to be identified, reachable, and aware of their role.
Third - who notifies external parties, and when. Customers, partners, regulators. Notifying too early with an unclear picture creates panic. Notifying too late creates legal and reputational risk. This decision requires legal and communications involvement, not just IT.
The mistakes I see most often
First - the response plan exists only on paper. A document was written, filed, never read, never tested. During a real incident it is useless.
Second - technical specialists make decisions that belong at the management level. This happens not from a desire to overstep, but because management is unavailable or does not know they should be involved.
Third - internal communications are not structured. Who knows what and when - different teams get information at different times, through different channels, and it is sometimes contradictory. This adds chaos on top of the technical problem.
Minimum readiness
A few specific things that need to exist before an incident:
A contact list for different scenarios - who calls whom in the event of data compromise, system unavailability, suspected data leakage. The list must be current and accessible outside corporate systems.
A responsibility matrix: who makes technical decisions, who makes business decisions, who communicates with external parties.
At least one tabletop exercise per year - walking through a hypothetical scenario with the people who will actually respond. Not as a formality, but as a way to find gaps in the process before they appear in reality.
One question to check
Ask your team right now: "If at 10pm tonight we discover that someone has gained unauthorised access to our customer data - who makes the decision and what happens in the first hour?"
If the answer is confident and specific - you have a foundation. If not - that is a conversation worth having before you need it.