We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

WorkflowGLOBALNIST SP 800-61 Rev. 3

NIST SP 800-61 Rev. 3 Post-Incident Evidence Log Workflow

Build the record during response, validate recovery against explicit criteria, and track each lesson until its change is verified.

Preserve investigation actions and incident data with integrity and , validate recovery, and verify corrective actions through ID.IM.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
3 sections3 primary sources
Overview

Open this log as soon as the incident investigation starts. Use it to preserve investigation actions, incident data and metadata, recovery evidence, the after-action report, and verified improvements. SP 800-61 Rev. 3 calls for integrity and for investigation records and collected incident data. It does not say every incident needs formal chain-of-custody handling; follow the organization's evidence-preservation and retention procedures and seek legal direction when prosecution, litigation, regulation, or contract makes handling requirements material.

Section 1

Workflow steps for lessons learned and evidence preservation

Keep the event timeline, evidence register, decision log, recovery record, and improvement tracker linked by incident ID, but do not collapse them into one free-text chronology. Each record needs an owner, timestamp, source, handling history, and enough context to reconstruct what happened and why.

  • 1 | Open and protect the record | Owner: incident lead | Record the incident ID, declaration time, initial scope, systems and data involved, authoritative time sources, repositories, access rules, preservation procedure, retention basis, and legal-hold status.
  • 2 | Record investigation actions | Owner: each investigator | Record the actor, timestamp, action, purpose, result, affected system, command or tool when relevant, and link to the decision or evidence item. Protect confidentiality and integrity and restrict access to authorized personnel.
  • 3 | Register incident data and metadata | Owner: collector or evidence custodian | Record the source, collector, acquisition time and method, original and working-copy locations, integrity value or other control, , access history, and custody transfer when formal custody is used.
  • 4 | Complete the incident and decision timeline | Owner: incident lead | Link triage, priority, escalation or elevation, analysis, containment, eradication, communications, recovery initiation, assumptions, rejected options, approvers, and changes in scope or magnitude.
  • 5 | Validate and close recovery | Owner: recovery and asset owners | Check restoration assets before use, remediate root causes before production use, verify restored-asset integrity and function, restore essential services in the approved order, monitor performance, document residual risk, and apply the criteria for declaring recovery complete.
  • 6 | Report and verify improvements | Owner: incident lead and risk owners | Produce an after-action report covering the incident, response, recovery, and lessons. For each accepted lesson, record priority, owner, due date, changed policy, control, procedure, playbook, or recovery arrangement, verification evidence, and retest trigger.
Recommended next step

Keep the investigation and recovery records linked

Assign evidence handling, preserve provenance, record recovery validation, and verify approved improvements.

Assessment workflow
Open Assessment Autopilot for NIST SP 800-61 Rev. 3

Create cited tasks, evidence requests, and review checkpoints for this NIST SP 800-61 Rev. 3 scope.

Explore next step
Talk to Sorena
Review this NIST SP 800-61 Rev. 3 scope with Sorena

Review decision authority, procedures, evidence gaps, and exercise results for this incident-response scope.

Explore next step
Section 2

Decision points for lessons learned and evidence preservation

Set handling and retention from the organization's procedure and the incident's facts. Rev. 3 treats collected incident data as evidence but says formal chain of custody might not be used for every incident. Consider possible prosecution, legal or regulatory duties, the sensitivity of the records, retention cost, and whether future access requires specific hardware or software.

  • Which investigation records, incident data, metadata, system snapshots, communications, and decision records must be preserved, and which source establishes retention or legal hold?
  • Does the case require a documented chain of custody, specialist forensic acquisition, or other handling beyond normal integrity and controls?
  • Has the team searched known targets and other potential targets for persistence and indicators of compromise, and what uncertainty remains about magnitude and root cause?
  • Were backups and other restoration assets checked before use, root causes remediated, restored assets verified before production use, and essential services restored in the approved order?
  • Who may declare recovery complete, what criteria apply, what residual risk was accepted, and is all incident documentation complete?
  • Which lesson warrants a change, who owns it, what evidence will show that the change works, and when will it be retested?
Section 3

Evidence fields for lessons learned and evidence preservation

Keep investigation records confidential, integrity-protected, attributable, and available only to authorized personnel. For collected incident data, record integrity and so a reviewer can identify its origin and handling. Use a custody history only when the organization's procedure or case requires it.

  • Incident ID, evidence-item ID, description, source asset or person, collector, acquisition timestamp, time zone, and authoritative time source.
  • Acquisition method and tool, original and working-copy location, integrity value or other control, , access history, and custody history when applicable.
  • Linked investigation action, decision, communication, containment, eradication, recovery step, and the fact or conclusion the item supports.
  • Confidentiality classification, authorized roles, preservation procedure, legal hold or retention rule, disposition date, and hardware or software needed for future access.
  • Recovery criterion, validation method, result, asset-owner confirmation, completion approver, residual risk, and monitoring period.
  • Lesson, source, priority, accepted action, accountable owner, due date, target outcome, verification evidence, status, and retest trigger.
Primary sources

References and citations

NIST CSF 2.0 (CSWP 29)
doi.org4 citations
Referenced sections
  • Official CSF 2.0 source for non-prescriptive outcomes and the ID.IM improvement Category.
  • ID.IM identifies improvements from evaluations, exercises, operational activities, and incident response plans, with lessons feeding improvements across all CSF Functions.
  • CSF 2.0 leaves implementation details to the organization; ID.IM provides the outcome structure for identifying and tracking improvements.
Show 1 more
  • ID.IM provides the CSF outcomes for improvements found through evaluations, exercises, operations, and incident response.
NIST SP 800-61 Rev. 3 Incident Response
csrc.nist.gov4 citations
Referenced sections
  • Final April 2025 publication used for investigation records, evidence handling, magnitude validation, recovery verification, after-action reporting, and continuous improvement.
  • RS.AN-06 and RS.AN-07 require integrity and provenance for investigation records and incident data. RC.RP-03 through RC.RP-06 cover restoration-asset checks, restored-system validation, recovery completion criteria, completed documentation, and the after-action report.
  • RS.AN-07 qualifies formal chain-of-custody use and ties collection and retention to organizational procedures, policies, possible prosecution, cost, and future-access needs. RS.AN-08 covers magnitude validation. RC.RP defines checks and criteria for recovery.
Show 1 more
  • RS.AN-06 and RS.AN-07 support investigation-action and incident-data fields, confidentiality, integrity, provenance, authorized access, retention, and qualified custody handling. RC.RP supports recovery checks, completion, and after-action documentation.

Related guides

NIST SP 800-61 Rev. 3 CSF 2.0 Incident Profile Guide

Map NIST SP 800-61 Rev. 3 across CSF 2.0 preparation, Detect-Respond-Recover operations, and continuous improvement without treating the profile as a law or playbook.

NIST SP 800-61 Rev. 3 FAQ: practical implementation questions

Answers on incident declaration, severity, roles, communications, notification clocks, evidence, recovery, and continuous improvement under NIST SP 800-61 Rev. 3.

NIST SP 800-61 Rev. 3 Incident Communications and Escalation

Separate incident coordination, notification, public communication, information sharing, escalation, and elevation, with owners and decision records.

NIST SP 800-61 Rev. 3 Incident Response Playbook Template

Build a scenario-specific incident playbook with declaration criteria, authority, third-party coordination, response evidence, legal overlays, and recovery exit criteria.

NIST SP 800-61 Rev. 3 Incident Severity and Response Targets

Build organization-defined incident severity bands and response targets from NIST risk factors without claiming that NIST prescribes levels or deadlines.

NIST SP 800-61 Rev. 3 vs CISA playbooks: practical side-by-side comparison

Choose NIST SP 800-61 Rev. 3 for an organization-wide incident-response risk model and CISA's playbooks for detailed FCEB incident and vulnerability procedures.

Show all related guides (20)

NIST SP 800-61 Rev. 3 vs ISO 22301 business continuity: practical side-by-side comparison

Use NIST SP 800-61 Rev. 3 for cybersecurity incident response and ISO 22301:2019 with Amendment 1:2024 for the business continuity management system.

NIST SP 800-61 Rev. 3 vs ISO/IEC 27035: practical side-by-side comparison

Compare NIST SP 800-61 Rev. 3's CSF 2.0 outcome profile with the ISO/IEC 27035 incident-management process, planning, and ICT response guidance.

NIST SP 800-61 Rev. 3 vs NIS2 incident reporting: practical side-by-side comparison

Use NIST SP 800-61 Rev. 3 to run incident response and the applicable NIS2 national law to assess significant-incident reporting and legal deadlines.

NIST SP 800-61 Rev. 3: escalation decision workflow for incident communications

Run incident coordination, required notifications, public updates, and voluntary information sharing as separate, documented decision streams.

NIST SP 800-61 Rev. 3: What Changed from Rev. 2

See how NIST SP 800-61 Rev. 3 replaced Rev. 2's incident-handling guide with a CSF 2.0 Community Profile and what teams should update.

Using NIST SP 800-61 Rev. 3 for Incident Response

Use NIST SP 800-61 Rev. 3 to assign incident-response outcomes, owners, records, communications, and improvements while tracking binding duties separately.

Event vs. Incident in NIST SP 800-61 Rev. 3

An event is observable activity. Declare an incident when analysis shows the occurrence meets documented cybersecurity incident criteria.

How should teams handle communications under NIST SP 800-61 Rev. 3 incident response?

Plan incident coordination, formal notifications, public communication, and voluntary information sharing under NIST SP 800-61 Rev. 3.

How should teams handle lessons learned under NIST SP 800-61 Rev. 3 incident response?

Capture incident-response lessons as they emerge, prioritize them through CSF 2.0 Improvement, and verify changes to plans, controls, training, and recovery.

How should teams handle post-incident evidence under NIST SP 800-61 Rev. 3 incident response?

Preserve incident records, collected data, metadata, integrity, provenance, access controls, and retention decisions under NIST SP 800-61 Rev. 3.

How should teams handle reporting clocks under NIST SP 800-61 Rev. 3 incident response?

NIST SP 800-61 Rev. 3 sets no universal reporting deadline. Build a clock register from each applicable law, regulation, policy, and contract.

How should teams handle severity under NIST SP 800-61 Rev. 3 incident response?

NIST SP 800-61 Rev. 3 sets no universal severity scale. Use documented risk factors to estimate severity and urgency, prioritize response, and reassess.

What should recovery include in a NIST SP 800-61 Rev. 3 incident response process?

Select, authorize, prioritize, and verify recovery actions; check restoration assets and restored systems; confirm service restoration; and document recovery closure.

Which CSIRT roles should teams define under NIST SP 800-61 Rev. 3?

Define incident-response leadership, handlers, technical specialists, legal, communications, HR, facilities, asset owners, and providers under NIST SP 800-61 Rev. 3.