Every credible incident response process follows the same backbone: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity. Skip a phase or run them out of order, and you extend dwell time, contaminate evidence, or both.
Each phase has a distinct job. Preparation builds the muscle before anything breaks: policies, tooling, and a trained team ready to move. Detection and Analysis confirms an incident is real and scopes what it touched. Containment stops the bleeding without torching the evidence you need later. Eradication and Recovery remove the attacker’s foothold and bring systems back online safely. Post-Incident Activity turns the mess into permanent improvements.
NIST SP 800-61 incident response guidance frames this lifecycle around Detect, Respond, and Recover, tying it directly into enterprise risk management rather than treating IR as a standalone fire drill. CISA’s federal playbooks echo the same structure with concrete checklists for declaration and evidence handling. Blueteam-academy teaches this lifecycle the same way SOC teams actually run it: as a sequence of decisions, not a slide deck.
Key Takeaways
Following the six-phase incident response lifecycle in order, and closing the loop with a real postmortem, is what separates organizations that contain incidents fast from those that relive the same breach twice.
| Point | Details |
|---|---|
| Follow the six phases in order | Preparation, Detection/Analysis, Containment, Eradication, Recovery, and Post-Incident Activity build on each other sequentially. |
| Preserve evidence before remediation | Capture memory images and logs before touching affected systems to protect chain of custody. |
| Contain without destroying forensics | Isolate hosts and disable accounts before deciding between snapshot and live-response evidence collection. |
| Verify eradication is complete | Rotate all touched credentials and confirm no secondary backdoors remain before declaring recovery. |
| Close the loop with postmortems | Feed IOCs and control failures into detection rules and training within the same week, not months later. |
What Blue Team Academy Teaches Learners About Incident Response
Blueteam-academy builds its incident response training around decision frameworks and lab-based playbooks, not slide theory, because analysts who’ve practiced the containment decision under simulated pressure make it faster when it’s real. The two mistakes we see most: losing evidence by remediating before capturing it, and running a postmortem with no assigned owners. Both are fixable with a checklist and a rehearsal.
Ready to build these skills hands-on? Explore Blue Team Academy’s course catalog for self-paced training built around real incident response decision points, or start with the path from IT to cybersecurity if you’re mapping your next career move.
Table of Contents
- How Incident Response Frameworks Map to the Steps
- Preparation: People, Policies, Tooling, and Playbooks
- Detection and Analysis: Validating Alerts and Scoping the Blast Radius
- Containment: Stopping Spread Without Destroying Evidence
- Eradication and Recovery: Removing the Threat and Restoring Trust
- Post-Incident Activity: Turning a Bad Week Into Permanent Improvements
- A Practical Playbook Checklist You Can Adapt Today
- Frequently Asked Questions
- Sources
How Incident Response Frameworks Map to the Steps
Three names come up constantly when people talk about incident response frameworks: NIST, SANS, and the CSF 2.0 Functions. They describe the same reality with different levels of granularity, and knowing how they line up matters more than picking a “winner.”
NIST SP 800-61 condenses the lifecycle into four phases: Preparation, Detection and Analysis, Containment/Eradication/Recovery (bundled as one), and Post-Incident Activity. The NIST incident response recommendations push teams to map this lifecycle to the CSF 2.0 Functions, which matters for governance because auditors and boards increasingly expect CSF alignment as the reporting language.
SANS splits the same work into six steps: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. It’s functionally identical to NIST’s model, just with Containment/Eradication/Recovery separated into three distinct decision points instead of one bundled phase.
CSF 2.0 organizes work around Govern, Identify, Protect, Detect, Respond, and Recover. It’s not really an IR-specific model. It’s a governance layer that IR plugs into.
Which model should you use?
- Choose the NIST four-phase model for concise executive reporting and audit mapping.
- Choose the SANS six-step model when you need granular runbook structure for analysts.
- Layer CSF 2.0 on top of either one when leadership wants IR tied to broader risk posture.
Preparation: People, Policies, Tooling, and Playbooks
Preparation is where most incidents are actually won or lost, long before an alert ever fires. A team that has rehearsed ransomware containment five times responds differently than one reading a runbook for the first time mid-breach.
Start with the CSIRT (Computer Security Incident Response Team). Define who has authority to declare an incident, who can isolate a production host without a change ticket, and who escalates to legal or executive leadership. Ambiguity here costs hours during a live incident.
- Write the IR policy with named ownership and management sign-off, not just an IT-team draft nobody above director level has read.
- Build playbooks per scenario (ransomware, business email compromise, insider data theft) that specify prerequisite logs, required tools, and expected outputs for each step.
- Design your telemetry strategy before you need it: EDR coverage, NetFlow, authentication logs, and cloud audit trails (CloudTrail, Azure Activity Log) all need retention windows long enough to reconstruct an attack timeline.
- Schedule exercises on a cadence, not as one-off events: tabletop exercises quarterly, purple team engagements twice a year, and at least one full-run rehearsal annually where the CSIRT actually executes containment steps against a test environment.
- Assemble a jump-bag: offline contact lists, out-of-band communication channels (a separate messaging app or phone tree), and printed copies of your first 30 minutes of playbook steps in case primary systems are compromised.
AWS’s incident response guidance makes a point that on-prem teams often miss: cloud responders need different playbooks entirely, because the log sources, query syntax, and even the identity model differ from traditional infrastructure. A playbook written for Windows Event Logs doesn’t help you when the incident lives in an S3 bucket policy.
Pro Tip: Test your out-of-band communication plan during a normal Tuesday, not during an actual incident. If your “offline” contact list lives in a shared drive that requires SSO, it isn’t actually offline.
Detection and Analysis: Validating Alerts and Scoping the Blast Radius
An alert is not an incident. Detection and Analysis is the phase where you decide whether something deserves a war room or a shrug.
Start with a validation pass. Check the alert against known false-positive patterns, confirm the initial indicator against a second data source (an EDR alert plus a matching auth log entry, for example), and rule out benign explanations like scheduled maintenance or a misconfigured scanner. A significant portion of SOC alert volume in a typical environment turns out to be noise once cross-validated, which is why triage discipline matters more than alert volume.
Once you’ve confirmed something real, triage it against four factors:
- Business impact: does this touch revenue systems, customer data, or life-safety functions?
- Data sensitivity: PII, PHI, payment data, or intellectual property in scope?
- Attacker persistence: scheduled tasks, registry run keys, or web shells suggesting the actor plans to stay?
- Lateral movement risk: is this contained to one host, or does it touch domain admin credentials?
Collect artifacts in order of volatility. Memory images first (they disappear on reboot), then disk images of affected hosts, then relevant logs and packet captures. CISA’s federal playbooks specify preserving evidence before remediation begins, which sounds obvious until you’re under pressure to “just fix it” three hours into an outage.
Build a timeline as you go. Map the indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs) you find against a reference like MITRE ATT&CK, since that mapping directly informs both your containment strategy and the detection rules you’ll write during the post-incident phase. Blueteam-academy’s Threat and Control Method walks through exactly this kind of mapping, connecting observed behavior to the specific controls that should have caught it.
Keep stakeholders updated on a need-to-know basis. Executives need impact and timeline; they don’t need every IOC you’ve found.
Containment: Stopping Spread Without Destroying Evidence
Containment decisions get made under time pressure, and the wrong call here can either let an attacker keep moving or wipe out the forensic trail you need for eradication and legal follow-up.
Short-term containment buys you time immediately:
- Isolate the host from the network while keeping it powered on if memory forensics haven’t been captured yet.
- Disable compromised accounts rather than resetting passwords first. A reset can tip off an attacker still active in the session.
- Apply network ACLs to block command-and-control traffic without taking down the whole segment.
Long-term containment addresses the structural gap that let the incident happen: network segmentation changes, temporary credential rotation across an entire domain, and monitored reconnections where isolated systems rejoin the network only under active watch.
The snapshot-versus-live-response decision matters here too. A disk snapshot preserves state cleanly but takes systems offline longer; live response keeps services running but risks evidence changing underfoot. Whichever you choose, document chain of custody: who touched the system, when, and what tool captured the artifact. That documentation is what makes evidence usable in a legal proceeding later.
This is also the point to loop in legal, HR, and PR with a coordination template that spells out who says what, to whom, and when. Waiting until eradication to bring in legal is the most common containment-phase mistake, especially with active exfiltration.
Eradication and Recovery: Removing the Threat and Restoring Trust
Eradication only works if you’ve fully mapped how the attacker got in and stayed in. Rebuilding a server without rotating every credential it touched just resets the clock on the same breach.
- Rotate all credentials the compromised system or account could have touched, not just the obviously affected one.
- Patch the exploited vulnerability and confirm the patch actually closes the gap the attacker used.
- Remove malware and persistence mechanisms completely: scheduled tasks, registry keys, web shells, rogue service accounts.
- Confirm no secondary backdoors remain. CISA’s playbooks specifically warn that attackers often plant multiple persistence mechanisms, so eradicating the one you found isn’t the same as eradicating all of them.
Recovery should be staged, not immediate. Restore systems to an isolated environment first, test functionality and integrity there, then gradually reintroduce them to production with enhanced monitoring active. Set clear acceptance criteria before you call recovery complete: integrity checks pass, monitoring shows no anomalous behavior over a defined window, and business functions confirm normal operation.
Bring in outside help when the incident exceeds internal capability, particularly with ransomware, suspected nation-state activity, or anything triggering mandatory law enforcement notification.
Post-Incident Activity: Turning a Bad Week Into Permanent Improvements
The postmortem is the phase everyone skips when they’re exhausted, and it’s exactly the phase that determines whether you see this incident again. Atlassian’s incident management research notes that post-incident review is commonly the weakest link in the entire lifecycle, largely because teams treat it as optional once systems are back online.
A useful postmortem structure covers:
- Timeline reconstruction: what happened, when, and who responded at each step.
- Root cause analysis: not just the exploited vulnerability, but the control failure that allowed it.
- Remediation actions with named owners and deadlines, not a generic “improve monitoring” bullet nobody is accountable for.
- Metrics that matter: mean time to detect, detection-to-containment time, and re-infection rate, tracked over time and presented to leadership in plain business terms.
Every finding needs a destination. IOCs go into detection rules. Process gaps go into playbook revisions. Skill gaps go into training assignments.
Pro Tip: Feed the IOCs and TTPs from your postmortem directly into your detection pipeline within the same week. Postmortems that sit in a shared drive don’t prevent the next incident; the same entry vector tends to reappear when the loop never closes.
Retention policies and regulatory triggers belong here too. Data breach notification laws vary by state and by sector, and the postmortem is where you confirm whether this incident crossed a reporting threshold.
A Practical Playbook Checklist You Can Adapt Today
A working runbook boils down to six decision points: declare, scope, contain, eradicate, recover, postmortem. Each needs a trigger, not a vague judgment call made under stress.
For a ransomware case, a SOC analyst’s first moves typically include: query EDR for the initial encryption process parent, isolate affected hosts from network shares, and check backup integrity before any recovery attempt begins. For credential compromise, the sequence is: force session termination, rotate the credential and any linked service accounts, and review authentication logs for the hours prior to detection.
- Automate detection-to-alert routing and initial triage scoring.
- Keep containment and eradication decisions manual until playbooks are proven reliable.
- Automate credential rotation only for accounts with pre-approved scope.
The gap between a team that has a playbook and a team that has run the playbook is the entire difference between a contained incident and a headline. Tabletop exercises exist to close that gap before it costs you.
Blueteam-academy’s hands-on labs walk through both scenarios end to end, giving learners the chance to practice these decision points before a real incident forces the issue.
Frequently Asked Questions
What are the six incident response steps?
Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity, following the sequence outlined in NIST’s incident response guidance.
What’s the difference between NIST and SANS incident response models?
NIST bundles Containment, Eradication, and Recovery into one phase across four total phases. SANS separates them into three distinct steps across a six-step model. Both describe the same underlying work.
What should a CSIRT do during the preparation phase?
Define roles, escalation authority, and delegated permissions; build scenario-specific playbooks; establish telemetry and logging strategy; and run tabletop exercises on a regular cadence.
How long should you keep forensic evidence after an incident?
Retention should match your regulatory and legal exposure. Data breach notification requirements vary by state and sector, so confirm retention windows with legal counsel during the post-incident phase.
Why do postmortems get skipped, and why does that matter?
Teams treat recovery as the finish line when exhausted, but Atlassian’s incident management research shows postmortem is the phase most likely to be skipped, and skipping it means the same control failure often causes the next incident.
What is one thing to build before you need it?
A jump-bag with offline contact lists and out-of-band communication tools, so your team can coordinate even if primary systems are compromised.
Sources
- NIST incident response recommendations and resources
- Cybersecurity Incident & Vulnerability Response Playbooks
- Atlassian postmortem guidance
