In this section
How You Describe the Work
You have probably seen a four-phase incident response lifecycle diagram — preparation, detection and analysis, containment and eradication, post-incident. You have referenced it in an IR plan, a tabletop, or a compliance document. What you may not have tracked is that the document behind that diagram was withdrawn by NIST in April 2025. This subsection tells you what replaced it, in plain terms, and focuses on the part that matters to you — the vocabulary you use when writing reports and talking to the people who read them.
Scenario
Your incident report lands on the CISO's desk. It says: "We completed the containment phase and moved to eradication." The CISO forwards it to the cyber insurer. The insurer's assessor flags the language — NIST withdrew the four-phase lifecycle in April 2025. The report uses Revision 2 vocabulary that no longer reflects the current framework. The assessor doesn't question your investigation. They question your currency. The work was right. The vocabulary was wrong. The current vocabulary matters because the people who evaluate your reports expect it.
Estimated time: 35 minutes.
Figure IR0.3 — The six CSF 2.0 Functions as applied to incident response by NIST SP 800-61 Rev 3. The three highlighted Functions are where the working responder's time goes during an active incident. This course teaches Detect (validation and scoping), Respond (primary scope), and Recover (from the responder's angle).
What changed, in one paragraph
Short version first. The rest of the sub only exists because you will occasionally need to justify current framework language to someone who learned on the old one.
NIST Special Publication 800-61 is the reference document most organizations, auditors, and regulators use as the shared language for incident response. In April 2025, NIST withdrew Revision 2 — the 2012 document that defined the four-phase lifecycle most people trained on — and replaced it with Revision 3. The new document does not present incident response as a linear sequence of phases. It presents incident response as activity that happens across the six Functions of the Cybersecurity Framework 2.0 — Govern, Identify, Protect, Detect, Respond, Recover — with three of those Functions (Detect, Respond, Recover) running concurrently during an active incident. The reason for the change is that real investigations cycle. You detect something, you respond partially, you find more scope, you respond again, you begin recovering some assets while still investigating others. The linear lifecycle pretended these were sequential phases. Rev 3 drops the pretence.
The six Functions, in the language you will actually use
You do not have to memorize these. You do have to recognize them when an auditor, regulator, or executive uses them, and you should use them in written reports. One line each.
Govern. The program-level activities that determine how cybersecurity work is resourced, authorized, and measured. In IR: who is the incident commander, who authorizes isolation actions, who decides on external notifications, what does the retainer cover, what are the reporting obligations to the board.
Identify. Knowing what you have to defend. Asset inventory, data classification, third-party relationships. In IR: the reason you can scope an incident is because someone did Identify well enough for you to know what assets exist and which matter.
Protect. The controls that prevent or limit incidents. Access control, hardening, MFA, segmentation, user awareness. In IR: these are the controls the investigation will identify as breached, bypassed, or missing.
Detect. Identifying and validating security events. Continuous monitoring, alerting, triage. In IR: the entry point to your work — the alert, the anomaly, the external notification. The part of Detect this course teaches is the validation and scoping that converts an alert into a declared incident.
Respond. Investigation, analysis, containment, eradication, coordination, reporting during an incident. In IR: this is where the majority of the course sits. IR2–IR17 are all Respond activities.
Recover. Restoration and improvement after containment. Rebuild, validate that restored systems are clean, feed findings back into the program. In IR: the responder's role is usually limited to validating that recovered systems are actually clean (no surviving attacker persistence) and producing the findings that drive program-level improvements. The operational work of rebuilding systems is an operations role, not a responder role.
The vocabulary is the six Functions. The work is what the rest of the course teaches. The two connect at the point where you write the report, brief the CISO, or answer a regulator's question — which is also the point where the difference between Revision 2 and Revision 3 language becomes visible to the reader.
Figure IR0.3b — The six CSF 2.0 Functions as applied to this course. Detect, Respond, and Recover (orange borders) are where the working responder's time goes. Respond (IR2–IR17) is the course core. Govern, Identify, and Protect are referenced where they intersect with investigation work.
Where this course sits in the framework
Look at Figure IR0.3. The orange-bordered Functions are where responder time goes. Those are what the course primarily teaches.
Detect is taught partially. This course does not teach detection engineering — writing the analytics rules that fire the alert in the first place. That is a separate discipline (and one of the highest-leverage adjacent skills for an IR practitioner, which IR0.4 will discuss). What this course teaches within Detect is the validation layer: converting an alert into a confirmed incident with a defined scope. IR2 covers the evidence acquisition that underpins valid scoping. Phase 2 and Phase 3 cover the endpoint-side and cloud-side validation work.
Respond is the core of the course. Every module from IR2 through IR17 is Respond activity. Investigation is the bulk of it (IR3–IR12). Scenario-specific response comes next (IR13–IR16). Reporting closes the loop (IR17). Containment is woven throughout rather than taught as a separate module, because containment decisions are inseparable from the investigation findings that justify them.
Recover is partially covered. IR17 teaches the reporting that drives recovery decisions. IR18 covers the readiness program that plans recovery in advance. What this course does not teach is the operational rebuild work — server reimaging, backup restoration, identity rebuild — because that is an IT operations responsibility informed by responder findings, not a responder skill.
Govern, Identify, Protect are referenced where they intersect with responder work. IR18 (readiness) is largely Govern. The evidence preservation framework in IR2 is Govern. The regulatory notification requirements in IR17 are Govern. The discussion of assets and crown jewels across the scenario modules is Identify. The analysis of which controls failed in the forensic modules is Protect. You are not here to build the program — you are here to run the investigation — but the investigation has to produce findings that feed back into those three Functions, and the vocabulary is what connects them.
Using the vocabulary in practice
This is the part that matters. The rest of the subsection is background.
When you write an incident report, the framework vocabulary is what makes the report legible to the people who will read it.
Compare two sentences. First sentence: "Claire's account was compromised because MFA was bypassed. We revoked her session and forced a password reset." Second sentence: "The incident demonstrated a failure of PR.AA-03 (multi-factor authentication). Respond.MI (mitigation) activities at 14:58 included session revocation and credential rotation. Recovery validation is tracked under RC.RP-01."
The first sentence is correct English. The second sentence uses CSF 2.0 Subcategory references. The second version is what audit firms, cyber insurers, and regulators are increasingly expecting to see. It is not a requirement yet — Rev 3 is a guidance document, not a law — but the direction of travel is clear. Major UK and EU regulators reference NIST documents in their supervisory guidance. Cyber insurance questionnaires are being rewritten against CSF 2.0 Subcategories. NIS2 audit frameworks use CSF 2.0 as a reference structure.
You do not have to write every report in Subcategory-reference form. You do have to be able to translate between the operational language you use internally ("we revoked the session") and the framework language external readers expect ("Respond.MI activities completed at..."). Reports that mix the two — one short paragraph of operational detail followed by the Subcategory mapping for audit — are the current best practice for 2026 reporting.
The rule for your writing is: use Rev 3 vocabulary for anything an external reader will see. Use operational language for anything internal. When in doubt, write the operational version first and add the framework mapping in a second pass — the operational version is the one that captures what actually happened, and the framework mapping is what makes it auditable.
Where the old vocabulary still shows up
You will hear PICERL and Revision 2 terms in the field for a while. Here is how to handle each one without getting into a framework argument with a colleague.
"PICERL" or "SANS PICERL." This is a six-phase variant from SANS — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. It is not NIST-endorsed and never was; it was a SANS teaching model derived from the 2012 lifecycle. Do not use it in reports that will be read by auditors or regulators. In verbal conversation, translate silently — "Identification" is Detect with early Respond, "Containment" is Respond mitigation, "Lessons Learned" is Improvements feeding back into Identify.
"Preparation." A Revision 2 phase. Under Rev 3, preparation is distributed across Govern (program level), Identify (asset and risk level), and Protect (controls level). The work still happens; the vocabulary distributes it differently.
"Post-incident activity." A Revision 2 phase. Under Rev 3, post-incident work sits in Respond's final reporting (RS.CO), in Improvements (ID.IM) feeding back into Identify, and in specific Recover activities.
"The four-phase lifecycle." If your organization's IR plan still uses this structure, the plan is not wrong, it is dated. A full rewrite is not urgent. A one-page mapping addendum that translates the plan's sections onto the six Functions satisfies an audit finding without requiring a rewrite cycle. That addendum work sits in IR18 (building IR readiness) — not something you produce in the middle of an incident.
Decision Point
The situation. It is 18:40. Claire's incident is contained — sessions revoked, endpoint isolated, inbox rule removed, OAuth app purged, affected supplier notified. You have forty minutes before the CISO's scheduled external brief to the CFO and Head of Audit. You need to produce a one-page summary. Your internal investigation notes are written in operational language ("we found the inbox rule at 14:46, confirmed AiTM from the RawTokenNumber field, the endpoint beacon was reflective in explorer.exe"). The audience for the brief is non-technical and will read the document against the organization's CSF 2.0-aligned IR plan.
The choice. You can (a) translate the entire document into CSF 2.0 Subcategory-reference form, which is what the IR plan uses, (b) keep the operational language for clarity and add a short CSF 2.0 mapping paragraph at the end, (c) write two separate documents, one operational for the CISO and one framework-aligned for the CFO and Head of Audit, or (d) use operational language throughout and not reference the framework at all, on the grounds that the incident is already contained and the framework mapping is readiness work.
The correct call. (b). Operational language is what captures what actually happened, in words the CFO can parse without a glossary. The CSF 2.0 mapping at the end makes the document auditable against the organization's own plan — which is what the Head of Audit will be reading for. Option (a) buries the story under vocabulary the CFO does not need. Option (c) doubles the work and doubles the chance of one version contradicting the other. Option (d) produces a document the Head of Audit cannot reconcile against the plan and forces them to ask for a follow-up mapping — additional work for you, and a signal that your team does not track the framework language the organization adopted.
The operational lesson. The framework vocabulary is a layer you add on top of clear operational writing, not a replacement for it. Reports that lead with Subcategory references and bury the actual findings are unreadable to the people who fund your program. Reports that ignore the framework force every audit-adjacent reader to do the mapping themselves. The combination — operational narrative, framework mapping at the end — is the current standard for 2026 IR reporting and is the pattern IR17 teaches in detail.
"NIST is a US federal agency, so its framework doesn't apply to us." NIST SP 800-61 and CSF 2.0 are used globally. Major UK and EU regulators — FCA, ICO, BaFin, AMF — reference NIST documents in their supervisory guidance. Most cyber insurance underwriters use NIST frameworks regardless of where the insured organization sits. ISO 27035:2023 and NIST SP 800-61 Rev 3 describe broadly compatible activities using different vocabulary. The argument that "NIST is only for Americans" was never accurate and is less accurate every year. It's a currency problem, not a geographic one.
Investigation Principle
The vocabulary is not the work — but the vocabulary is how the work is evaluated. Use NIST SP 800-61 Rev 3 (CSF 2.0 Functions) for anything an external reader will see. Use operational language for anything internal. The combination — operational narrative first, framework mapping at the end — is the current standard for 2026 IR reporting.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.