The IR lifecycle

Why it matters

Every organisation will have security incidents. What separates a bad day from a disaster is whether people know what to do: who leads, what to preserve, when to cut off a machine, who must be told, and how to stop it happening again. An incident response (IR) lifecycle gives that structure. It is also a staple of job interviews and of the CySA+ exam.

Event, alert, incident

• An event is anything observable: a login, a file write, a blocked connection.
• An alert is an event (or pattern) that a tool flagged for attention.
• An incident is a confirmed or likely violation of security policy: an attacker in an account, malware running, data exposed.

Most alerts are not incidents. Triage (the next lesson) decides which ones are.

The NIST lifecycle

The US National Institute of Standards and Technology publishes incident response guidance in Special Publication 800-61. The widely taught lifecycle from revision 2 has four phases:

1. Preparation: plans, contacts, tools, logging, training and practice before anything happens.
2. Detection and Analysis: noticing something is wrong, confirming it, working out scope and severity, and documenting.
3. Containment, Eradication and Recovery: stopping the spread, removing the attacker and their tools, and restoring normal operations safely.
4. Post-Incident Activity: lessons learned, improving controls and detections, and keeping evidence.

The phases loop: lessons learned feed back into preparation, and during an incident you often go back and forth between analysis and containment as you find more.

Revision 3 (2025) reorganises the guidance around the six functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), so incident response is treated as part of overall risk management rather than a separate process. The four-phase model is still the common vocabulary in SOCs and exams, and it maps neatly onto the CSF functions. Read the current publication at csrc.nist.gov. Checked on 2026-10-23.

Other models exist. The SANS model splits the same work into six steps (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned). The ideas are the same.

What each phase involves

Preparation

• A written IR plan with roles: incident lead, technical responders, communications, legal and management.
• An up-to-date contact list, including outside help (an IR retainer, your cloud provider, law enforcement contacts).
• Logging and a SIEM that cover your key systems (module 1), plus clock synchronisation.
• Tabletop exercises: walking through a scenario on paper to find gaps.

Detection and Analysis

• Confirm the alert is real, then scope it: which accounts, hosts and data are affected?
• Assign a severity based on impact (business functions, data sensitivity, number of systems).
• Start an incident log: every action, finding and decision with a UTC time and the person's name.

Containment, Eradication and Recovery

• Short-term containment stops the bleeding: isolate a host from the network, disable an account, block an IP or domain.
• Preserve evidence before you destroy it. Capture memory and logs before wiping or rebooting where the situation allows (lesson 2.3).
• Eradication removes the cause: malware, persistence mechanisms, backdoor accounts, the vulnerability that let them in.
• Recovery restores from known-good backups or rebuilds, resets credentials, and watches closely for the attacker returning.

Post-Incident Activity

• A blameless lessons-learned meeting within a couple of weeks: what happened, what went well, what to change.
• Concrete follow-ups with owners: new detections, patches, training, plan updates.
• Retain evidence and reports according to policy and legal advice.

Worked example: a phishing compromise

At 09:05 the SIEM alerts on a successful Microsoft 365 sign-in for j.ruiz from a country where the company has no staff, ten minutes after the user clicked a link in an email.

• Detection and Analysis. The analyst confirms the sign-in is not a VPN and the user did not travel. Mailbox audit logs show a new inbox rule forwarding all mail to an outside address. Severity: high (account takeover with data leaving). Scope check: two other users received the same email; one clicked.
• Containment. Revoke sessions and reset passwords for both users, require MFA re-registration, delete the forwarding rule, and block the sender and the phishing domain.
• Eradication. Purge the phishing email from all mailboxes, check for other inbox rules, OAuth app grants or MFA methods the attacker added.
• Recovery. Return the accounts to the users, monitor sign-ins for two weeks, and notify affected contacts if the forwarded mail contained their data (legal decides on notification duties).
• Post-incident. Lessons learned: the phishing email passed filters and users could not easily report it. Actions: add a report-phish button, alert on new external forwarding rules, and move these users to phishing-resistant MFA.

Common mistakes

• Wiping first, asking later. Rebuilding a machine before collecting evidence can destroy the only record of how the attacker got in.
• Tipping off the attacker. Visible half-measures (resetting one password while they hold others) can push them to act faster. Plan containment so it happens together.
• No incident log. Memory fails under stress; reports, insurance and legal questions need a timeline.
• Skipping lessons learned. Without it, the same incident happens again.

Quick recap

• Events are observations, alerts are flags, incidents are confirmed or likely policy violations.
• NIST SP 800-61 phases: Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity. Revision 3 aligns them with CSF 2.0.
• Scope, document, preserve evidence, contain together, remove the cause, recover carefully, and learn.