Friday, October 16, 2026
IT BusinessDigest
Get the Daily Brief
Explainer

Incident response steps: what NIST's 2025 update changed, and how to use it

NIST's incident response guide went 13 years without an update. The new version treats response as part of everyday risk management, not a separate plan in a drawer.

Morgan Reid Security and infrastructure writer · · Updated · 3 min read
A team at a conference table listening to a colleague

For more than a decade, the standard US reference for handling security incidents was NIST Special Publication 800-61 Revision 2, published in 2012. In April 2025, NIST replaced it with Revision 3, titled "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile."

The title says what changed. Incident response is no longer a standalone process. It is organized around the six functions of NIST's Cybersecurity Framework 2.0, the same framework many companies already use for the rest of their security program.

The new model

According to a summary by law firm Covington, Rev. 3 describes incident response in three layers:

Layer CSF 2.0 functions What it means in practice
Preparation Govern, Identify, Protect Ongoing work: roles, asset inventory, protections, plans
Lessons learned Identify (improvement) Feeding what you learn back into everything else
Incident response Detect, Respond, Recover Finding, containing and recovering from an incident

The point of the change is that preparation never stops. An incident response plan written once and filed away is the failure mode NIST is trying to design out.

NIST also moved its lists of tools and resources out of the document and onto a separate incident response website, so they can be updated without a new revision.

The high-priority recommendations

Covington's summary picks out three of NIST's high-priority recommendations:

  1. Align business continuity plans with incident response plans, because a serious incident is also a business continuity event.
  2. Monitor continuously for unauthorized activity and changes in security posture, across networks, hardware, software, staff activity and external service providers.
  3. Use technology to filter large volumes of events down to a set that people can review.

Steps for a mid-size IT team

Translated into work for a team without a dedicated security operations center:

  1. Name the roles before you need them. Who leads an incident, who talks to leadership, who calls legal, the insurer and law enforcement. Write down a backup for each.
  2. Know what you have. An incident response plan depends on an asset inventory and knowing which systems are critical.
  3. Write short playbooks for your most likely incidents: ransomware, a compromised email account, a lost laptop, a breach at a key supplier.
  4. Connect it to continuity planning. Decide in advance which systems you restore first and how the business keeps running meanwhile.
  5. Keep logs where an attacker can't reach them, and make sure someone or something is watching them.
  6. Practice. Run a tabletop exercise at least once a year and after any major change.
  7. Review after every incident, including near misses, and update the plan, playbooks and protections.

What IT teams should do

  • Compare your current incident response plan against the six CSF 2.0 functions and note the gaps.
  • Write or update playbooks for ransomware and account compromise first.
  • Check that your business continuity plan and incident response plan agree on restore priorities.
  • Book a tabletop exercise for this quarter.

Sources