Incident response: NIST has revised SP 800-61 to revision 3 and aligned it with CSF 2.0

What changed from revision 2

The old edition described response as a lifecycle with its own stages, sitting apart from the rest of risk management. Revision 3 places response across all six CSF 2.0 functions, on the argument that every one of them has a part to play, not only the part that runs during an incident. The practical consequence is that a response plan should not be a separate document that gets opened when something goes wrong; it should connect to the governance, prevention and detection work happening every day.

What to have ready before anything happens

• Named responsibilities: Who decides, how to reach them, and who must be told outside working hours.
• An out-of-band channel: Something that does not depend on the systems that might be affected — a plan stored only in corporate email is no plan if email is down.
• Agreed severity criteria: Settle in advance what has to be escalated where, so nobody is debating it in the minutes that should be spent acting.
• Logs you can investigate with: Retain access and system logs long enough, and confirm they can actually be retrieved when needed.

Rehearsal is the part most often skipped

A plan that has never been rehearsed tends to fail on small things nobody thought about: no one knows the password to the break-glass account, or the provider's contact number has changed. A tabletop exercise of an hour or two usually surfaces more of those gaps than another document review.

After it is over

What actually improves a plan is what happens once the incident closes. Write the timeline as it really ran, mark where detection or communication was slower than it should have been, and convert those into tasks with an owner and a date. A review that concludes everyone did their best rarely makes the next one go better.