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

An event is any observable occurrence involving computing assets. Declare a cybersecurity incident when analysis shows that the occurrence meets the organization's incident criteria, based on Rev. 3's definition: it actually or imminently jeopardizes, without lawful authority, information or system confidentiality, integrity, or availability, or constitutes a violation or imminent threat of violation of law or applicable security and acceptable-use rules.

Apply documented incident criteria to known and assumed facts and account for known false positives. Severity helps prioritize a validated incident; it should not replace the declaration test. Keep the original event, analysis, decision time, owner, rationale, and any monitoring or response action together.

Recovery includes selecting, authorizing, prioritizing, and securely performing restoration actions. Check backups and other restoration assets before use; check restored assets for compromise; remediate root causes before production use; verify that restoration is correct; restore essential services in the right order; monitor performance; and have system owners confirm normal operations.

Recovery may begin during or after response. Declare its end only against documented criteria, complete the incident documentation and after-action report, and continue approved internal, external, supplier, and public status communication.

Preserve both investigation records and the incident data and metadata collected. Record what happened, which assets were involved, what responders did, the supporting evidence, communications, recovery actions, and resulting improvements. Protect confidentiality and integrity, preserve provenance, and limit access to authorized personnel.

Rev. 3 says formal evidence gathering and chain-of-custody handling might not be performed for every incident, but collected incident data is still evidence. Use the organization's evidence-preservation procedures and retention policies, considering possible prosecution and the cost of retaining the data and the hardware and software needed to access it later.

Plan four distinct communication paths: operational coordination, formal incident notification, public communication, and usually voluntary incident information sharing. For each, define the owner, audience, approval, secure channel, timing, disclosure limit, backup contact, and evidence record.

Procedures should state what must be reported, to whom, and at what times. Notifications must follow current applicable requirements; public messages should use approved media procedures; and information sharing should follow response plans, contracts, and information-sharing agreements.

Rev. 3 does not prescribe universal severity levels, scores, or response service-level agreements (SLAs). After validating an incident, estimate severity and response urgency using documented factors that fit the organization. NIST examples include asset criticality, functional impact, data impact, observed-activity stage, threat actor characterization, and recoverability.

Prioritize the response using scope, likely impact, time-critical nature, and resource availability. Track severity separately from incident category, escalation, elevation, recovery status, and external reporting classification, and reassess when the facts change.

Rev. 3 creates no universal reporting deadline. Identify every applicable law, regulation, policy, and contract, then record its covered actor and incident type, trigger, calculation method, deadline, recipient, content, submission route, update requirements, owner, and approval.

Track each duty beside the technical timeline without treating alert receipt, detection, triage, incident declaration, scope confirmation, and rule-specific awareness as the same timestamp. Preserve the applicability decision, uncertainties, submission, acknowledgment, correction, and final report.

Treat the Computer Security Incident Response Team (CSIRT) as a coordinated set of roles that may include leadership, incident handlers, technology professionals, legal, public affairs, human resources, facilities, asset owners, and third parties. The staffing model can combine employees, contractors, providers, partners, and specialists available when needed.

For each role, document scope, decision and action authority, primary and backup contacts, availability, handoffs, evidence ownership, and escalation paths. Put provider responsibilities, information flows, authority, and restrictions in contracts rather than assuming the provider owns the entire response.

Capture lessons from evaluations, exercises, response, and recovery, and communicate useful lessons as soon as they are identified. Route them through CSF 2.0 Improvement (ID.IM) to analyze and prioritize the issue and select a change to the incident program or another cybersecurity risk-management activity.

Keep the observation, supporting facts, root or contributing cause, priority, approved action, owner, resources, dependencies, due date, implementation evidence, and effectiveness result together. A closing meeting or assigned task is not evidence that the improvement works.

NIST published the final Rev. 3 in April 2025, and it supersedes Rev. 2 from August 2012. The publication says nongovernmental organizations may use it voluntarily. It does not create a certification, a universal compliance date, or a transition deadline for replacing every Rev. 2 procedure.

Federal authority needs a separate check. NIST developed Rev. 3 under its Federal Information Security Modernization Act (FISMA) responsibilities, and the publication does not alter standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce or the authority of the Office of Management and Budget (OMB) and other federal officials. For any organization, a law, regulation, policy, contract, procurement term, or other incorporation can make particular outcomes or practices mandatory.