When people talk about incident response, it is easy to imagine the most visible part: a critical alert, an isolated endpoint, a compromised account, an active investigation, or an urgent call.

But much of the quality of that response is decided before the incident happens.

It is decided when the organization defines who may act, how incidents are reported, where they are recorded, which scenarios require escalation, how evidence is preserved, and what needs to be tested before the process is relied on in a real situation.

That is why I do not see preparation as an administrative phase separate from response. I see it as part of the response capability itself.

Pressure reveals what was actually defined

Under normal conditions, many ambiguities seem tolerable.

During an incident, they stop being tolerable.

Apparently simple questions can consume valuable time:

  • is this an event or an incident?;
  • what severity does it have?;
  • who leads?;
  • who may isolate an endpoint or revoke a session?;
  • when should privacy or compliance become involved?;
  • who informs leadership?;
  • what may be communicated to a third party?;
  • where is evidence recorded?;
  • who decides that the incident can be closed?

Preparation exists so those decisions do not begin from zero.

Preparation does not mean predicting every possible incident

No organization can write a specific procedure for every possible situation.

The goal should be to build a structure that still works when the scenario does not perfectly match something anticipated.

That structure needs a few stable elements.

Roles and authority

It is not enough to say who participates. The organization needs to understand who decides what.

A response may involve security, technology, leadership, privacy, legal, communications, or suppliers. Coordination improves when authority and escalation paths are considered before they are needed.

Classification and escalation criteria

Severity should not depend only on the impression of the analyst receiving the alert.

Potential impact, scope, data involved, affected assets, propagation potential, compromised privileges, and disruption of critical processes can all change response priority.

A system of record

Response needs a shared source of truth.

Recording from the beginning helps preserve facts, decisions, owners, timing, and evidence while the investigation evolves.

Operational scenarios

Playbooks prepare questions and actions for frequent situations without pretending every incident will be identical.

Communications

Defining who may communicate helps prevent a technical incident from becoming an information problem involving contradictory or unauthorized statements.

Evidence also requires preparation

Evidence can be surprisingly easy to lose.

A message may be deleted. A session may be revoked before useful information is captured. A log may rotate. Someone may take an action and forget to document it.

That is why preservation should not depend only on remembering to “take screenshots.”

It helps to design which types of evidence may matter and how they fit into the timeline:

  • messages and headers;
  • authentication records;
  • security alerts;
  • endpoint events;
  • configuration changes;
  • containment evidence;
  • decisions and approvals;
  • communications performed.

Technical evidence and decision evidence complement each other. Both help explain what happened.

Exercises turn assumptions into learning

A plan may look consistent until the team tries to execute it.

A tabletop exercise can introduce information gradually and observe how the team responds.

For example, a scenario may begin as a suspicious email and evolve:

  1. the user reports the message;
  2. the user confirms clicking it;
  3. credential exposure becomes possible;
  4. unusual sign-in activity appears;
  5. the account is found to have access to sensitive information.

The value of the exercise is not in “beating” the scenario.

It is in observing:

  • how long the team takes to record the event;
  • whether severity changes appropriately;
  • whether the right playbook is activated;
  • whether evidence is preserved;
  • whether decisions have clear owners;
  • whether privacy or compliance becomes involved when appropriate;
  • whether closure produces concrete improvement actions.

A useful metric should change a decision

Measuring incidents only to fill a report provides limited value.

Metrics become more useful when they reveal where capability needs improvement.

Some questions I find valuable are:

  • how long does it take to record a relevant event?;
  • how long does containment take?;
  • which incident types repeat?;
  • which areas or assets appear most often?;
  • which corrective actions remain open?;
  • which controls failed or provided insufficient visibility?;
  • what changed after lessons learned?

The metric is not the outcome. It is a signal that helps decide where the process needs strengthening.

Recovery should also be part of the design

Response does not end with containing an attacker.

When a service, account, endpoint, or information asset needs to be recovered, the process must connect with continuity and recovery.

That means thinking before the incident about:

  • backups;
  • restore testing;
  • critical dependencies;
  • operational alternatives;
  • recovery priorities;
  • criteria for returning an asset to service.

An organization is not more resilient simply because it has backups. It is more resilient when it can recover what it needs under acceptable conditions and with enough confidence in the result.

Preparation reduces unnecessary improvisation; it does not eliminate judgment

Preparing the response does not mean automating every decision or turning people into procedure executors.

It means creating a framework that allows judgment to be used where it matters most.

When roles, channels, evidence, escalation, and scenarios are defined, the team can focus on the difficult part: understanding what is happening, assessing impact, and deciding how to reduce it.

That is why incident response starts before the incident.

It starts when we decide how we want to act before we know exactly what will happen.

Designing an operational model for cybersecurity incident management