Incident response, phase by phase

The order is the lesson#

A server is behaving strangely and you are fairly sure it is compromised. Almost everybody's instinct is the same: get rid of the malware, right now.

That instinct is wrong, and understanding why is most of this topic. Wiping the machine immediately destroys the evidence of how the attacker got in, and it does nothing about the four other machines they reached an hour ago. You cured one symptom and lost the ability to find the disease.

So incident response is a sequence, and the sequence exists because each step protects the one after it.

Why sources count the phases differently#

This trips people up during revision, so it is worth settling early. You will see this life cycle described as four phases in one book and six or seven in another. Nobody is wrong. They are grouping the same activities differently.

NIST's widely cited version groups them into four: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Other treatments, including most Security+ study material, split those groups out into separate named steps because each one is a different decision.

One consequence is worth noting. In the four-phase grouping, containment, eradication and recovery sit together because they often overlap in practice. You may be recovering one system while still containing another. The order still holds within the group.

Preparation is the phase that decides the others#

Preparation is the only phase that happens when nothing is wrong, which is exactly why it gets deprioritised and exactly why it matters most. Everything you did not do here becomes a problem you solve under pressure at three in the morning.

Preparation covers:

• The plan and the playbooks. A playbook is a written procedure for a specific incident type, so nobody is inventing a ransomware response during a ransomware incident.
• The team and the contact list, including who has authority to disconnect a production system. That authority question stalls real incidents constantly.
• Communication plans, including how you will communicate if email is the thing that is compromised.
• Tooling and logging, already deployed and already retaining data. You cannot investigate a month-old intrusion with seven days of logs.
• Exercises. A tabletop exercise talks a scenario through in a room. A simulation actually runs it. Both exist to find the gaps while they are cheap.

Detection and analysis#

Detection is noticing. It comes from monitoring alerts, a user report, a vendor notification, or an anomaly somebody spotted in a log. Most real incidents are detected by something mundane.

Analysis is the harder half, and it answers three questions that shape everything after:

1. Is this actually an incident? Distinguishing a real event from a false positive is the first job, and getting it wrong in either direction is expensive.
2. What is the scope? Which systems, which accounts, which data. Scope is what makes containment effective, and underestimating it is the most common serious error in real response work.
3. How severe is it, and what does that trigger? Severity drives escalation, and it may trigger legal or regulatory notification with a deadline attached.

Two terms belong here. An event is any observable occurrence. An incident is an event that actually harms, or threatens to harm, confidentiality, integrity or availability. Every incident is an event. Almost no events are incidents.

Containment comes before eradication, always#

This is the single most testable sequencing point in the topic. Contain first. Stop the bleeding before you treat the wound.

Containment limits further damage while you still work out what you are dealing with. It typically means isolating affected systems from the network, disabling compromised accounts, blocking attacker infrastructure, or segmenting a portion of the network.

There is a real tension inside containment that exam scenarios like to build on:

• Pulling the power stops the damage fastest and destroys everything in memory, which is often where the useful evidence lives.
• Disconnecting from the network but leaving the machine running preserves volatile evidence while cutting the attacker off. This is usually the better answer.
• Watching and waiting gathers intelligence about the attacker but accepts ongoing harm, and normally needs an explicit decision from someone with authority to accept that.

Eradication then removes the cause: the malware, the attacker's persistence mechanisms, the created accounts, and critically the vulnerability that allowed entry. Removing malware while leaving the unpatched service open means you will meet the same attacker again shortly.

Recovery, and the phase everyone skips#

Recovery restores normal operation and then verifies it. Restoring from backup, rebuilding systems, returning them to the network, and monitoring the restored environment more closely than usual. That last part matters: elevated monitoring after recovery is how you find out that eradication missed something.

Two measures shape recovery decisions, and they are constantly confused:

• RTO, recovery time objective, is how long you can be down. It is about time.
• RPO, recovery point objective, is how much data you can afford to lose. It is about the point you recover back to, so it drives how often you back up.

Lessons learned is the phase that gets skipped, because by the time you reach it the crisis is over and everyone wants their normal job back. It should happen while memory is fresh, produce a written report, and generate actual changes to the plan rather than a list of regrets.

The useful framing is that lessons learned feeds directly back into preparation. That is what makes the life cycle a cycle rather than a line, and it is why a diagram of it is usually drawn as a loop.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written — several of these exist because somebody asked.