RC.RP-06 says the end of incident recovery is declared based on criteria, and incident related documentation is completed. An incident is not over because people are tired. It is over when written conditions are met, someone declares it, and the record is complete.
What good looks like
Your plan has end criteria, and the incident lead checks them and declares the end with a recorded time. Typical criteria: all affected services restored and verified, root cause fixed, heightened monitoring period finished with no recurrence, required notifications sent, evidence preserved, and open actions assigned. Within a set time, an after action report documents the incident, the response and recovery actions, and lessons learned. Lessons become owned tasks with due dates.
How to implement it
- Write end of recovery criteria into the incident plan and keep them short.
- Add a closing checklist to the incident ticket template: criteria met, notifications done, evidence stored, report scheduled.
- Have the incident lead declare the end in the ticket and tell stakeholders.
- Hold a blameless review within one or two weeks. Attendees are the people who did the work plus the business owner.
- Write the after action report. Include a timeline, what happened, how it was detected, what worked, what did not, and root cause.
- Turn each lesson into a tracked task with owner and date. Review progress monthly.
- Update the plan, playbooks and detection rules based on the findings.
- Store the report with access limited to those who need it, and keep it for your retention period.
Try it yourself
This demo walks through running an incident to closure and writing the postmortem, including turning findings into actions.
Click through it at your own pace, or open it full screen.
Evidence to collect
- The end of recovery criteria in the plan.
- Incident tickets with the declaration time and closing checklist.
- After action reports for incidents and exercises.
- The task list from lessons learned, with status.
- Updated plans showing changes made as a result.
CSF is not certifiable, but a customer can read an after action report and judge how seriously you take incidents.
Common gaps
- Incidents fade out without anyone declaring an end.
- The report is never written, or is written months later from memory.
- Lessons are listed but have no owner.
- Reviews turn into blame, so people stop sharing facts.
- The report sits in a folder and the plan is never updated.
- Notifications owed to customers or regulators are forgotten at closing.
Quick check
Who declares the end of recovery?
The incident lead, once the criteria are met, with the system owners agreeing. Record the time in the ticket.
What belongs in an after action report?
The incident itself, the response and recovery actions taken, root cause, what worked and what did not, and lessons learned as tracked tasks.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 implementation examples for RC.RP-06, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework
CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.
