Skip to main content
← Blog·8 min read·July 27, 2026

The seven incident response phases Security+ tests, in plain English

CompTIA Security+ lists incident response as a seven-step sequence in SY0-701 objective 4.8: Preparation, Detection, Analysis, Containment, Eradication, Recovery, Lessons learned. That seven-step list is CompTIA's, not NIST's. NIST SP 800-61 Revision 2 used four groupings, and it was superseded in April 2025 by Revision 3, which organizes incident response around the six CSF 2.0 Functions instead. For the exam, learn CompTIA's seven. The order is what most scenario questions hinge on.

N
IT Service Center Manager, former CTE teacher, founder of Revtek

Where the seven phases come from

The seven-phase list is CompTIA's own. It sits in SY0-701 objective 4.8 as the incident response process. It is worth being clear about the label, because a lot of study material calls these "the seven NIST phases" and NIST has never published a seven-phase incident response model. SP 800-61 Revision 2 used four groupings: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. Revision 3 arrived in April 2025 and dropped the phase list entirely, organizing incident response around the six CSF 2.0 Functions: Govern, Identify, Protect, Detect, Respond, and Recover. So Revision 2 is no longer current guidance, and the seven steps were never NIST's to begin with.

The steps are still worth learning, because CompTIA lists them and each one carries a different goal, a different decision, and a different correct next action. SANS publishes a similar model called PICERL: Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. SANS combines detection and analysis into a single Identification step. CompTIA splits them. Learn CompTIA's seven for the exam. The vocabulary carries over either way, since Revision 3 maps this work onto the CSF Functions and most of these steps land under Detect, Respond, and Recover. That is the language you will hear in a compliance or audit role later.

The phases are not always strictly linear in real life. Teams loop back to analysis when new evidence surfaces, bounce between containment and eradication, and sometimes restart detection on a related incident. On the exam, treat the order as canonical. In the seat, treat it as a strong default.

Phase 1: Preparation

Preparation happens before any incident. This is the phase most organizations underspend on, which is why it shows up on the exam. The work is unglamorous: write the incident response plan, build the team roster, document the playbooks, deploy the tooling, train the staff, run the tabletop exercises. None of it gets attention until the day it saves the organization.

Concrete preparation outputs include a documented IR plan, a named IR team with backups, per-incident-type playbooks (phishing, ransomware, lost device, insider), tested tooling like EDR with isolation and SIEM with correlation rules, and a quarterly tabletop cadence. The exam likes to test the difference between tabletop exercises (discussion only, quarterly, finds planning gaps) and simulations (sandboxed walk-through, annual, finds tool and coordination gaps). Both are required.

Phase 2: Detection

Detection is the trigger. Something fires. A SIEM correlation rule trips on a burst of failed logons. EDR flags a process executing from a temp directory. A user reports a strange email. An external party (a threat intel feed, a partner, sometimes the FBI) notifies you. The phase ends with an open ticket and an analyst assigned.

Detection alone does not confirm an incident. A SIEM alert is a hypothesis. The detection phase ends when the alert exists and someone owns it. The next phase decides whether it is real.

Phase 3: Analysis

Analysis is where the team confirms the incident is real, scopes the blast radius, and classifies severity. This is where most teams misstep. The pressure to do something pushes analysts toward containment before they understand the scope. Containing one host while ten others are still talking to the attacker buys nothing.

A clean analysis phase answers three questions before any containment action. What is happening (the technique and the target). How bad is it (how many hosts, which data, which accounts). How fast does it spread (active lateral movement, dormant foothold, automated ransomware). Once those three answers exist, the team can make a containment plan that actually works.

Phase 4: Containment

Containment stops the spread. The exam tests two flavors. Short-term containment is the minutes-scale move: isolate the host through EDR, disable the compromised account, block the malicious domain at the firewall. Long-term containment is the architectural move: route around the affected segment, deploy a workaround, harden the perimeter so the attacker cannot regain access while eradication runs.

Order matters. Contain before you eradicate. If you start deleting malware while the attacker still has an active session, you tip them off and they pivot or wipe logs. Containment buys the time eradication needs. The other order-of-operations rule the exam loves: do not power off compromised hosts. Memory holds running processes, network sessions, and unencrypted strings that vanish on power-off. Use EDR isolation instead.

Phase 5: Eradication

Eradication removes the threat. Kill the malicious processes. Delete the malware files. Disable or delete the compromised accounts. Rotate any credentials that were exposed. Patch the vulnerability the attacker used to get in. Rebuild affected hosts from a known-good baseline image when reimaging is the only way to be sure.

Containment without eradication means the attacker comes back tomorrow. The isolated host is still infected. The disabled account is still compromised in the identity provider. The blocked domain is one DNS change away from being live again. Eradication is the phase that actually closes the door, not the phase that just slams it shut.

Phase 6: Recovery

Recovery brings systems back online. Restore from clean backups (this is where immutable backup discipline pays off). Validate the restored systems are actually clean. Return them to production with enhanced monitoring for the first stretch in case anything was missed. The phase is declared closed when leadership signs off, not when the host boots.

Heightened monitoring during early recovery catches the most common failure mode: a foothold the team missed during eradication. EDR alerting on the recovered host should be tighter than normal for the first week or two. If anything fires, the team loops back to analysis with new evidence.

Phase 7: Lessons Learned

Lessons learned is the phase most teams skip, which is why it shows up on the exam. The post-incident review (PIR) belongs on a calendar before the incident bridge closes, not as a vague "we will get to it." Hold it while the details are still fresh, which in practice means days rather than weeks. The review answers what worked, what did not, what gets updated in the playbook, what tooling needs investment, what training the team needs.

The phase produces concrete artifacts: an updated IR plan, updated playbooks, new detection rules, new training topics, new tabletop scenarios. Without those artifacts, the same incident lands the same way next time. The PIR is what turns one bad day into a stronger program. It is the phase that makes the next response better.

A ransomware response timeline, phase by phase

The seven phases are easier to remember when you walk an incident through them start to finish. Here is what a clean response looks like for a ransomware hit at a mid-size healthcare organization. The organization below is made up, the sequence is not.

How Security+ tests this on the exam

Three question shapes are worth drilling for this objective. Phase identification questions hand you an action ("a SOC analyst isolated the host from the network through EDR") and ask which phase the team is in. Correct ordering questions ask which phase comes next. Distinction questions test pairs that learners commonly confuse, especially containment versus eradication and short-term versus long-term containment.

The reliable test-day move is to ask yourself two questions before you answer. Is the spread stopped yet? If no, the analyst is somewhere in detection, analysis, or containment. Is the threat removed yet? If no, the analyst is in containment, not eradication. Walk those two questions through any scenario stem and the phase usually pops out.

Drill the lesson and the matching practice set if you want this locked in. The full Security+ objective lives at SP-4.8 Incident response. The companion objective SP-4.9 Data sources to support an investigation covers the log types you pull during the analysis and eradication phases. A full-length sit on the Practice Exam mode is the fastest way to see how CompTIA actually phrases these.

Where to go next

If you are tracking toward Security+ specifically, the Security+ track page has the full objective map and what each domain covers. If you are already in the platform, head to the dashboard and review Domain 4 in the Mastery Index with its evidence-quality label.

Questions about your specific path? Email the team. We reply personally, usually within a day.

Sources

  1. CompTIA. CompTIA Security+ SY0-701 exam objectives. Objective 4.8 is where the seven-step incident response process is published. This is the source for the seven phases and their order, not NIST.
  2. NIST. SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management. Published April 2025, superseding Revision 2. Revision 3 drops the phase list and organizes incident response around the six CSF 2.0 Functions. Revision 2's four groupings are the closest NIST ever came to the list above, and that revision is no longer current.
  3. CISA. Cybersecurity Incident Response (Federal Government Incident Response Playbook). CISA's operational guidance for incident response across federal and critical infrastructure agencies, aligned with the NIST incident response publications.
  4. SANS. Incident Handler's Handbook (PICERL model). The SANS six-step model (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned), which folds detection and analysis into a single Identification step where CompTIA splits them.

About the authors

Nicholas Miller
Founder and Lead Author

IT Service Center Manager and former CTE / IT teacher. Owner of Revtek in Chicago's south suburbs. Writes everything that ships under his name and reviews every line of Revy-assisted drafting before publish.

LinkedIn ↗
R
Revy
Study buddy · AI co-author

Revy helps draft and structure these posts. Every piece is reviewed, edited, and fact-checked by Nick before publish. We disclose this here because it is the right thing to do. See the AI Policy for the full stance.

Who writes this, and who checks it

Nicholas Miller
IT Service Center Manager · former high school CTE and IT teacher · founder of Revtek IT Solutions

Nick writes and edits these posts. AI helps with research, outlines, and first drafts. Nick reviews the draft before it goes live, and he is the only reviewer, so this is one person checking his own work. That catches a lot and it misses some.

When a post turns out to be wrong, the fix and the date it happened go on the corrections log, in public, including the ones nobody outside noticed. We do not use confidential, recalled, or leaked exam content. These posts are written from CompTIA's published objectives and authoritative technical sources. The AI policy has the longer version.

LinkedIn ↗