In this module
IR0.3 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.
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 authorises 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.
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.
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.
The myth. NIST guidance is for US federal systems. UK and EU organizations should use ISO 27035 or national equivalents instead.
The reality. NIST SP 800-61 and CSF 2.0 are used globally. Most UK enterprises, most EU enterprises, and most multinational organizations reference NIST guidance in their IR programs. 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; multinational organizations typically map their programs to both. The argument that "NIST is only for Americans" was never accurate and is less accurate every year. If your organization's IR plan still references Rev 2 or avoids NIST language entirely, update it at the next review cycle. It is a currency problem, not a geographic one.
Try it: rewrite one paragraph of a real IR report in framework language
Take a paragraph from a report you have written recently and produce the CSF 2.0 mapping
Setup. Pick any paragraph from an IR report, post-incident review, or tabletop write-up you have produced in the last six months. It can be a short paragraph — one or two sentences about a specific finding, action, or control failure. If you have not written a report recently, use a paragraph from a published incident write-up (Microsoft's incident response case studies or public CIRT reports are good sources).
Task. Rewrite the paragraph in two parts. First part: the operational narrative, written in plain language, four to six sentences, capturing what happened and what was done. Second part: a short mapping block naming the CSF 2.0 Functions and Subcategories the paragraph corresponds to. For a paragraph about session theft and revocation, the mapping might be "Detect: DE.CM monitoring identified the anomalous session. Respond: RS.AN investigation confirmed AiTM pattern; RS.MI mitigation revoked the session and rotated credentials. Protect: PR.AA-03 multi-factor authentication identified as insufficient for this attack class." Keep the mapping to three to five lines.
Expected result. A single paragraph that reads naturally to a CFO and a single mapping block that satisfies an auditor. Together they should fit on less than half a page. This is the pattern IR17 teaches at scale. Doing it once now on a real paragraph establishes the habit.
Debugging branch. If the mapping is hard because you cannot find a Subcategory that fits, the Subcategory naming is probably too granular for a first-pass report — use the Function level only (Detect, Respond, Protect) and add Subcategories in a subsequent review. If the operational paragraph is hard to write because you only wrote the report in framework language originally, that is the symptom of the opposite problem this course is trying to prevent — the framework-first report with no operational story. Rewrite the paragraph in plain English first; the framework mapping adds on top.
You should be able to do the following without looking back at the text.