The incident response lifecycle

Why this matters

Objective 3.2 asks you to outline the incident response process, and it is one of the most reliably examined topics on CS0-004. The phases have names, an order, and activities that belong to each — which is exactly the shape a multiple-choice question likes.

Learn it as a structure rather than a list. Its real function is to stop the two failures that ruin responses: doing things out of order, and skipping the phase that has no visible urgency. The rest of this domain is each phase in depth, so this lesson is the map.

The lesson

Preparation: the phase that decides the rest

The first phase, and the only one that happens before anything is wrong.

Preparation is everything that determines how the other phases go: the plan, the people, the authority to act, the tooling, the logging, the backups, the contacts, the practice. Lesson 29 covers it properly, because it deserves a lesson of its own and because it is the phase organisations skip.

The reason it decides the rest is blunt. You cannot investigate what you did not log. An intrusion three weeks old is invisible if your retention is seven days, and no amount of skill in the detection phase recovers it. You cannot contain quickly if nobody knows who may authorise disconnecting a production server. You cannot recover from backups nobody has restored. Every one of those is a preparation decision, made months earlier by someone not thinking about incidents.

It is also the phase you are in right now, most of the time. Response is rare; preparation is continuous. Treating preparation as the default state rather than a project is most of what separates a team that handles its first serious incident well from one that discovers its gaps during it.

Detection and analysis

The phase where you find out something happened and work out what.

Detection draws on everything in Domain 1: alerts from the SIEM, EDR detections, hunting, user reports, third-party notification. That last source is worth dwelling on — a substantial share of breaches are still reported to the victim by an outside party: law enforcement, a customer, a payment processor, a researcher, or the attacker's own extortion note. An organisation notified from outside had a detection gap, and that fact belongs in the post-incident review rather than being quietly absorbed.

Analysis is the work of turning an alert into a description. Its output answers:

• What happened? Which technique, which systems, which accounts.
• Is it actually an incident? An alert is not an incident until someone determines it is; lesson 30 covers that triage.
• How far does it go? Scope, in hosts, accounts, data.
• When did it start? Almost always earlier than the alert suggests.
• Is it still happening? Which decides how much time you have.

Two properties of this phase to hold on to. It is iterative — every answer produces new questions, and scope grows as you look. And it overlaps containment, because in a live intrusion you will be analysing and containing at once, which the tidy diagram does not show.

Containment, eradication and recovery

Grouped in the classic model, and genuinely three activities.

Containment stops the incident spreading while you still have work to do. Short-term containment is immediate and crude — isolate the host, disable the account, block the address. Long-term containment is the sustainable position you hold while eradicating: a segmented network, a temporary rule, a rebuilt host in a clean segment.

The tension this phase is famous for: containing early destroys evidence and warns the attacker; containing late lets damage spread. There is no general answer, and lesson 32 works through how to decide.

Eradication removes the attacker and what they left: malware, web shells, scheduled tasks, service accounts, added SSH keys, altered configurations, stolen credentials still valid. The recurring failure is partial eradication — cleaning the host you found while leaving the persistence mechanism that put it there, then watching the same compromise reappear a week later.

Recovery returns systems to service and verifies they are healthy: restore, rebuild, re-enable, monitor closely. Recovery has its own decision, covered in lesson 32 — rebuild or clean — and its own verification obligation, which is that "it is working again" is not the same as "the attacker is gone".

Enhanced monitoring of recovered systems is part of this phase, not an optional extra. The period just after recovery is precisely when an incomplete eradication shows itself.

Post-incident activity

The phase with no urgency at all, which is why it is skipped, and the only one that improves anything.

It covers the post-incident review, the root cause, the actions that come out of it, the tracking of those actions to completion, and the updates to detections, controls and the plan itself. Lesson 35 is entirely about it.

The argument for doing it, for the times you are arguing: an incident you did not learn from is an incident you have paid for and not bought anything with. The cost is already sunk — the hours, the downtime, the disclosure. The review is the only part that turns it into something.

Note also the loop: post-incident activity feeds preparation. The lifecycle is drawn as a cycle rather than a line because its output is a better version of phase one.

Declaring an incident, and un-declaring one

The transitions, which are the part a diagram never shows and a real response always needs.

Declaring an incident changes what is permitted. It usually activates an emergency change path, authority to disconnect systems, a communications protocol, and sometimes a retainer or an insurer's notification clock. Until it is declared, an analyst is investigating an alert with ordinary authority and ordinary change control.

What makes declaration work:

• A defined criterion written in advance, so it is not argued during the incident.
• A named person who can declare, reachable outside working hours.
• A bias toward declaring. Declaring and standing down costs a meeting. Not declaring and being wrong costs the response. Organisations that treat declaration as an admission of failure declare late every time.

Un-declaring — standing down, closing the incident — needs criteria too, and gets far less attention. Closing should require that eradication was verified, enhanced monitoring ran clean for an agreed period, affected credentials were rotated, notification obligations were met, and the post-incident review is scheduled rather than intended.

The failure mode here is closing an incident because the meetings became tiresome and the systems are back up. That is the state in which an incomplete eradication is rediscovered as a second incident — with the added difficulty that the evidence from the first has been overwritten, and the same organisation now has to explain why it said the matter was closed.

Which is the through-line of this domain, in the same shape this course has used throughout: a system that is clean and one that merely looks clean are indistinguishable from outside, and only a deliberate check tells them apart.

Topics this lesson owns

• [x] Preparation: the phase that decides the rest
• [x] Detection and analysis
• [x] Containment, eradication and recovery
• [x] Post-incident activity
• [x] Declaring an incident, and un-declaring one