Learn
Incident Response
Incident response is a discipline, not improvisation
Every organization with anything worth protecting eventually has an incident. What separates a controlled response from a chaotic one isn't luck or individual heroics. It's whether there's a structured process everyone already knows, practiced before it's needed, rather than invented in the middle of a crisis.
That process has been formalized by more than one authoritative body, and they don't all describe it the same way. This page covers five: NIST's Cybersecurity Framework and its incident-response-specific companion publication, SANS's widely used practitioner framework, DoD's formal reporting requirements, and ISO/IEC 27001, the internationally recognized standard. Knowing all five, and how they relate, matters more than memorizing any single one, because different organizations lean on different combinations of them depending on context, including which country or countries they operate in.
NIST CSF 2.0: the organization-wide risk framework
The NIST Cybersecurity Framework is the broadest of the frameworks covered here, and it isn't specific to incident response at all. It's a voluntary, outcome-based structure any organization can use to assess where its cybersecurity program stands, decide where it needs to go, and talk about risk in a common language that works across a security team and executive leadership alike. First published in 2014, it's become one of the most referenced cybersecurity frameworks in the world, well beyond the critical-infrastructure sector it was originally built for.
Version 2.0, released in February 2024, is the framework's first major revision, and the headline change is a new sixth function. The original five, Identify, Protect, Detect, Respond, and Recover, are joined by Govern: cybersecurity risk management strategy, policy, and leadership accountability, sitting at the center and informing how the other five actually get carried out. Adding Govern wasn't cosmetic. It reflects a real shift in how the field thinks about cybersecurity, from something IT handles in isolation to something that has to be a governed, board-visible part of how an organization manages risk generally, not a side function. If you're hearing CSF 2.0 referenced constantly at industry conferences right now, that's why: Govern is the piece that finally gives security leadership a formal seat in how the framework works, and organizations are still actively working out what that looks like in practice.
NIST SP 800-61: applying CSF 2.0 specifically to incident response
If you've encountered NIST incident response guidance before CSF 2.0 existed, you likely learned a four-phase model: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. That model, Special Publication 800-61 Revision 2, was formally withdrawn by NIST in April 2025. The current guidance, Revision 3, is where the CSF's broader structure actually gets applied to the specific job of handling incidents.
Revision 3 builds directly on CSF 2.0's six functions. Govern, Identify, and Protect are framed explicitly as preparation: broader cybersecurity risk management activities that support incident response but aren't part of responding to an incident itself. The actual response sits in Detect, Respond, and Recover. Threaded through all of it is a continuous Improvement activity, not a single lessons-learned meeting held after the fact, but an ongoing feedback loop where whatever you learn from handling one incident immediately informs how you prepare for the next.
The practical shift: incident response stops being a discrete, bounded event you handle and close out, and becomes an integrated part of how the organization manages risk on an ongoing basis, governed the same way CSF 2.0 governs everything else. That reflects reality better than the old model did. Incidents today are more frequent, and many take far longer to fully resolve than a tidy few-day cycle.
SANS: the tactical, step-by-step process
Where NIST's current guidance operates at the level of organizational risk management, SANS's incident handling process, sometimes referred to by the shorthand PICERL, is the practitioner-level version: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. This is the process most individual analysts actually think in terms of while an incident is live, and it maps naturally onto NIST's higher-level structure. Identification is where Detect happens in practice. Containment, Eradication, and Recovery are what Respond and Recover actually look like hands-on-keyboard. Lessons Learned is the same continuous-improvement idea NIST now builds directly into its model, just named as its own explicit step.
Where this differs meaningfully from a purely intellectual framework is in the specifics: how you actually decide whether to isolate a host now or keep watching to gather more evidence first, how you distinguish real eradication from a fix that only looks complete, how you know recovery is actually safe rather than premature. Those judgment calls are what the hands-on-keyboard work in this program is built to develop, not something a framework document by itself can teach.
DoDI 8530.03: the reporting and governance layer
DoD Instruction 8530.03, Cyber Incident Response, operates at a different level entirely from NIST and SANS. It isn't a technical how-to-investigate guide. It's a formal governance and reporting instrument: how incidents get categorized, who must be notified, within what timeframe, and through what channel, particularly for incidents involving personal information or classified systems.
If you end up in a government or defense-adjacent SOC, this kind of formal reporting structure is directly relevant and often legally binding. But the underlying principle generalizes well beyond that context: every mature organization has some version of a formal escalation and reporting requirement, defining who needs to know what, how fast, and through what channel. Knowing that this layer exists, and that it operates independently from the technical work of actually handling the incident, is the transferable lesson even outside a DoD environment specifically.
ISO/IEC 27001: the international standard
Everything covered so far is U.S.-specific, whether government guidance, a U.S.-based training organization's process, or DoD's own reporting requirements. ISO/IEC 27001 is the internationally recognized standard for information security management, and its 2022 revision addresses incident response through five Annex A controls, structured as one continuous loop:
- 5.24, Planning and preparation. A documented incident management process, with roles and responsibilities defined before an incident happens, not improvised during one.
- 5.25, Assessment and decision. Formally evaluating a reported event against defined criteria to decide whether it's actually an incident and how severe it is.
- 5.26, Response. The active work of responding to a confirmed incident, this platform's scenarios exercise this control directly.
- 5.27, Learning from incidents. Feeding what was learned back into the process, closing the loop the same way NIST's continuous Improvement function does.
- 5.28, Collection of evidence. Handling evidence, logs, artifacts, anything gathered during an investigation, in a way that holds up to later scrutiny. This is worth taking seriously even outside a legal context: sloppy evidence handling during an investigation is exactly how real analysts lose track of what they actually found.
If you work at, or end up at, an organization pursuing ISO 27001 certification, especially one operating internationally, this is very likely the framework structuring their formal process, running alongside whatever region-specific requirements also apply.
Bringing it together
In practice, none of these five frameworks stand alone. A real response draws on all of them at once: SANS-style tactical steps for the actual hands-on-keyboard work, CSF 2.0's governed, risk-based posture as the organizational backdrop, SP 800-61's specific application of that posture to handling an incident, ISO 27001's same plan-assess-respond-learn loop if the organization is internationally certified, and a formal reporting structure, whether DoDI 8530.03 or an organization's own equivalent, running in parallel to make sure the right people are informed on the right timeline.
That's the process you'll be practicing in this program, not as five separate boxes to check, but as one integrated way of working: identify what happened, contain and remediate it, learn from it, handle the evidence properly, and know what needs to be reported and to whom, all at the same time rather than in isolation.
Where this goes next
The frameworks above describe the process. The next step is doing it: an Elastic Security walkthrough covering the actual mechanics of investigating an incident hands-on, from first alert to final write-up, using the same telemetry and interface every scenario in this platform gives you.
Where to go from here