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 provenance, validate recovery, and verify corrective actions through ID.IM.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
3

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
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.
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

doi.org
Referenced sections
  • ID.IM provides the CSF outcomes for improvements found through evaluations, exercises, operations, and incident response.
csrc.nist.gov
Referenced sections
  • 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

Explore more topics

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.
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.
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.
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.