Key insight

The worst time to decide what to do is in the middle of an emergency. Incident response is a calm, rehearsed lifecycle — prepare, detect, contain, eradicate, recover, learn — that replaces panic with practised steps. The order matters: you contain the spread before you investigate or clean up, the way a doctor stops the bleeding first. And the step people most want to skip — a blameless review that fixes the root cause — is the one that quietly makes you harder to attack next time.

Every other topic has been about preventing and spotting trouble. This one starts from a grown-up admission: sooner or later, despite your best efforts, something will go wrong. Incident response is what you do when that day arrives, and the single most important idea is that the worst possible time to figure out what to do is in the middle of the emergency, when everyone is frightened and clear thinking is hardest. A fire station does not work out where the hoses are while the building burns; they rehearse it in advance. Incident response is that same idea for a security emergency.

1 · A plan beats panic

With no plan, an incident is chaos: people improvising, stepping on each other, crucial jobs left undone while three people do the same one. With a plan, the same incident becomes a set of calm steps everyone already knows. You do not need a perfect plan — you need to have thought it through once, calmly, so that on the day, you are executing rather than inventing.

Without a plan an incident is chaos; with a plan it is a set of calm steps A red box labelled No plan, chaos sits beside a green box labelled A plan, calm steps. A caption states the worst time to decide what to do is mid-emergency. No plan: chaos A plan: calm steps The worst time to decide what to do is mid-emergency
Figure 1. Teams that prepare well look almost unhurried during a real incident — precisely because they are executing, not deciding.

2 · The lifecycle: six calm steps

Incident response follows a lifecycle, walked in the same order every time, because a reliable order is exactly what stops people flailing. Prepare: get the plan, people, and tools ready beforehand. Detect: notice an incident is underway (this leans entirely on logging and monitoring). Contain: stop the problem spreading, right now. Eradicate: remove the attacker and whatever they left behind, completely. Recover: carefully bring systems back to normal, clean and trusted again. Learn: honestly work out what happened and prevent a repeat. Doing them in this order — rather than jumping straight to cleanup — separates a handled incident from a made-worse one.

The six-step incident response lifecycle: prepare, detect, contain, eradicate, recover, learn Six boxes in a row connected by arrows: Prepare, Detect, Contain, Eradicate, Recover, and Learn. A caption states the same calm order, every single time. Prepare Detect Contain Eradicate Recover Learn The same calm order, every single time
Figure 2. The order is the point. Containing before cleaning up, and learning after recovering, is what keeps a small incident from becoming a large one.

3 · Prepare: before the fire

Preparation quietly decides whether all the others go well, and it happens on an ordinary calm day. It means writing down a plan: what counts as an incident, who to call, the first concrete steps. It means deciding roles in advance, so that when the moment comes, everyone already knows who is leading, who is investigating, who is talking to management, and who is handling customers — rather than six people doing the same job while a crucial one goes undone. And it means having the practical things ready: contact numbers even at 3 a.m., access to backups, and the tools responders need. Every decision you make calmly in advance is one fewer frightening decision to make badly in the heat of the moment.

4 · Contain: stop the bleeding first

Here is the stage people most often get wrong. When you discover a compromised system, every instinct screams to start cleaning it up, or to gather every detail first. But the very first priority is containment: stopping the problem from spreading, right now, before it reaches more systems. Think of a doctor with a badly bleeding patient — they stop the bleeding first, and diagnose second. Containment might mean disconnecting an infected machine from the network, disabling a compromised account, or isolating a whole segment, so the attacker or malware is walled off. It can feel drastic, but the spread is almost always the real catastrophe. Contain first, understand fully second, clean up third — in the wrong order, a small incident becomes a company-wide one.

An infected system is isolated fast, so the rest of the systems stay safe A red server box labelled Infected system is cut off by a green boundary, while separate teal boxes labelled The rest stays safe stand apart. A caption states isolate before you investigate because spread is the real enemy. Infected system cut it off, fast The rest stays safe and reachable Isolate before you investigate — spread is the real enemy
Figure 3. Containment can be disruptive, but the spread is almost always the true catastrophe. Stop it first, understand it second.

5 · Eradicate and recover: cleanly

Once contained, two stages restore things properly. Eradication means completely removing the attacker and everything they left behind — the malware, any hidden way back in, any accounts they added. This must be thorough, because a half-removed attacker is barely better than none; miss the secret door they installed, and they walk back in a week later. Recovery means carefully bringing systems back to normal, ideally restored from clean backups made before the compromise, and watched closely afterward. Notice how earlier topics come together: trustworthy backups make recovery possible, and good logging tells you when the compromise began, so you know which backup is actually clean. The goal is not just working systems, but systems you can genuinely trust again.

6 · Learn: the step people skip

The final stage is the one exhausted teams most want to skip, and it is quietly the most valuable: learning. After the emergency, the team honestly works through what happened — how the attacker got in, why it took the time it did to notice, what went well and what did not. The crucial rule is that this review must be blameless. The goal is never to find someone to punish, because the moment people fear blame, they hide details, and the truth you need disappears. The goal is to find what in the system let this happen, and fix that root cause, so the same weakness cannot be used twice. An organization that truly learns from each incident gets steadily harder to attack; one that just cleans up and moves on is quietly guaranteeing the next incident looks like the last.

7 · What it means for AI agents

AI agents compress incident response the way they compress everything else. A human attacker might spend hours moving through a network, giving responders time to notice and contain. A misused or hijacked agent can take hundreds of harmful actions in seconds, so by the time a person notices, enormous damage may already be done. This makes two things essential in advance: fast detection specifically around agents, and — the agent-specific twist on containment — a reliable way to stop an agent instantly, an off switch that revokes its access and halts it in its tracks, decided and built before any incident. Everything else in the lifecycle applies unchanged. Agents simply shrink the time you have, which makes rehearsing the plan beforehand more important, not less.

8 · A simple test you can run this week

A rehearsal in miniature

1. Imagine one important system was breached today — who makes the first call, and do they know it?
2. Could you isolate one system fast, if you had to, and does someone know how?
3. Could you stop an AI agent instantly?
4. Any “we would figure it out then” is your gap.

The lesson: rehearse calm today, so tomorrow you are executing practised steps rather than inventing them in a panic.

9 · Glossary — every term, spelled out

Incident response
The calm, rehearsed set of steps for handling a security emergency when prevention has failed.
Lifecycle
The ordered stages of a response: prepare, detect, contain, eradicate, recover, learn.
Containment
Stopping an incident from spreading — isolating a machine, account, or segment — done before investigation or cleanup.
Eradication
Completely removing the attacker and everything they left behind, so they cannot simply return.
Recovery
Carefully restoring systems to trusted normal operation, ideally from clean pre-compromise backups.
Blameless review
An honest post-incident analysis that seeks the systemic cause rather than someone to punish, so people share the full truth.
Kill switch
A reliable, pre-built way to instantly stop an AI agent and revoke its access — the agent-specific form of containment.
Key takeaways

The worst time to decide what to do is mid-emergency — a rehearsed plan beats panic.
The lifecycle runs in order: prepare, detect, contain, eradicate, recover, learn.
Contain the spread before you investigate or clean up — the spread is the real catastrophe.
Learn blamelessly to fix the root cause, and for agents, build an instant off switch before you ever need it.

References

  1. NIST Special Publication 800-61, Revision 2, Computer Security Incident Handling Guide, National Institute of Standards and Technology. csrc.nist.gov
  2. SANS Institute, Incident Handler's Handbook — the preparation, identification, containment, eradication, recovery, and lessons-learned model. sans.org
  3. This guide’s Logging, Monitoring & Detection, Explained From Zero — the detection that triggers a response.
  4. This guide’s Backups & Recovery, Explained From Zero — the clean copies that make recovery possible.