It is possible to have a technically correct incident response plan and still not be prepared to respond.
The problem appears when the document describes what should happen, but the people who must act do not know how to activate it under pressure.
An incident rarely arrives with all the information available. It begins as an incomplete signal: a suspicious email, unusual account activity, a device behaving differently, a missing file, or an alert that may or may not represent a real incident.
At that point, the value of the plan is not how many pages it contains. It is whether it helps the team answer concrete questions:
- who needs to know first?;
- where do we record what we know?;
- who is allowed to make decisions?;
- what evidence must we preserve?;
- when does severity change?;
- which operational scenario should we activate?;
- who authorizes communications?;
- what conditions allow closure?
If those answers are unclear, the plan exists as documentation but not necessarily as an operational capability.
Incidents begin with uncertainty
A mature response process does not assume that cause, scope, and impact will be known from the first minute.
That is why I find it more useful to design the process to manage uncertainty than to describe a perfect path.
At the beginning, the team should at least be able to record:
- what was observed;
- who reported it;
- when it occurred;
- which asset, account, or process may be involved;
- which actions have already been taken;
- what evidence exists;
- which questions remain open.
That initial record creates a common working point and reduces a frequent risk: each person responding from a different version of events.
A defined reporting channel and system of record change the response
When an event can arrive through any channel and be documented anywhere, reconstructing what happened later becomes difficult.
An operational model needs to define, at minimum:
one official reporting channel and one official system of record.
The reporting channel tells people where to activate the response. The system of record creates traceability: decisions, owners, evidence, severity changes, containment actions, and closure.
That is not bureaucracy for its own sake. It is operational memory during a situation where information changes quickly.
Playbooks help, but they do not replace judgment
I like playbooks because they reduce cognitive load.
For known scenarios—phishing, compromised accounts, malware, ransomware, information loss, unauthorized access, or recovery problems—they can remind a team what to inspect and what evidence to preserve.
But a playbook should not become a rigid script.
One incident may activate several scenarios at the same time. A phishing message may become a credential compromise; a compromised account may imply access to information; an outage may reveal a recovery problem.
The playbook helps structure the response. Technical judgment is still required to decide what applies, in what sequence, and with what priority.
Evidence must be designed before it is needed
During an incident it is easy to focus only on “fixing the problem.”
That can create another problem: afterward, nobody can explain precisely what happened, what decision was made, or why the incident was closed.
That is why I find it useful to define in advance which evidence belongs in the response lifecycle.
For example:
- initial record;
- timeline of actions and decisions;
- relevant technical evidence;
- impact assessment;
- closure report;
- lessons learned;
- pending corrective actions.
The timeline is especially valuable. It does not need to be sophisticated. It needs to reconstruct who did what, when, and with what information available at the time.
Closing an incident is not the same as alerts stopping
Closure should be an explicit decision.
Before closing, it is useful to ask:
- was the threat contained?;
- was the service or asset recovered where needed?;
- is the scope reasonably understood?;
- was the required evidence preserved?;
- are there privacy, legal, or contractual obligations still open?;
- were follow-up actions documented?;
- do those actions have owners and dates?
An incident can be technically controlled while still leaving work to do.
Closing well means separating what has ended from what still needs to be managed.
Communication is part of the response
During an incident, communicating quickly does not always mean communicating well.
Information may be incomplete, change rapidly, or involve personal data, third parties, customers, or contractual responsibilities.
That is why the model should define who may communicate, to whom, and under what conditions.
External communication should not depend on the individual initiative of whoever discovers the problem. It should be part of escalation and rely on confirmed facts as far as possible.
The plan must be tested
This is probably the clearest difference between having documentation and having capability.
A tabletop exercise can reveal issues that a document review will not:
- nobody remembers the reporting channel;
- severity is interpreted differently;
- two people believe they own the same decision;
- nobody knows where evidence should be recorded;
- the right playbook is not obvious;
- the privacy path is activated too late;
- closure has no clear owner.
Finding those failures during an exercise is good news. It means they can be corrected before the process is needed in a real situation.
Preparation means reducing unnecessary improvisation
No plan eliminates uncertainty during an incident.
Nor should it try to eliminate the judgment of the people responding.
What it can do is reduce improvisation where improvisation adds little value: channels, roles, records, evidence, escalation, communication, and closure.
For me, that leads to the most useful test of an incident response plan:
Can a team use it to make better decisions when information is incomplete and time matters?
If the answer is no, we still have a document to improve—not a finished response capability.
Related work
Designing an operational model for cybersecurity incident management