Artifact GuideGLOBALNIST SP 800-61 Rev. 3

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

Predefine who coordinates response, who approves notices, who speaks publicly, and what can be shared with partners.

Rev. 3 identifies four communication categories: coordination, notification, public communication, and usually voluntary incident information sharing. Applicable requirements, not Rev. 3, set mandatory triggers and deadlines.

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

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 separate decision tracks for incident coordination, formal notification, public communication, and incident information sharing. Define as increasing resources or time frames and elevation as involving higher management. NIST SP 800-61 Rev. 3 provides those categories and distinctions, but the organization must set its own thresholds, authority, channels, approval paths, and applicable legal or contractual notification rules.

Section 1

Separate the four communication tracks

Incident coordination keeps internal and external responders aligned on current and planned work. Incident notification formally informs affected customers, employees, partners, regulators, or others. Public communication addresses the public or media. Incident information sharing distributes observed threat information, usually voluntarily. Do not use one approval path or message for all four.

generally increases resources or changes time frames. Elevation usually brings a higher level of management into the response. Define both before an incident, including who can trigger them and which facts, risk factors, stalled actions, or resource constraints require reassessment. For example, responders may escalate by adding forensic or cloud-provider support while separately elevating a critical-service shutdown decision to senior leadership.

  • Classify each communication as coordination, notification, public communication, or information sharing before selecting its audience and approval path.
  • Distinguish of resources or urgency from elevation to higher management.
  • Run legal and contractual notification assessments in parallel with technical response and preserve the facts available at each decision time.
Section 2

Map audiences, authority, and external obligations

For each incident type and risk level, identify who needs information, why they need it, when the decision is revisited, what facts may be shared, and who approves the message. Include tested out-of-band channels for incidents that affect ordinary email, identity, messaging, or telephony.

Keep a jurisdiction, sector, customer-location, policy, and contract matrix beside the incident procedure. For each possible duty, record the covered entity or service, covered incident or data, trigger event, clock start, calculation rule, recipient, required content, update or final-report duty, and evidence of delivery. Rev. 3 says notification should comply with current requirements that apply to the organization, but it does not supply a universal reportability threshold or timer.

  • Identify affected services, data, people, locations, customers, suppliers, and government relationships.
  • Preassign message drafter, factual validator, legal reviewer, business approver, sender, and spokesperson.
  • Define supplier coordination and crisis-communication duties, including contacts, authority, approved channels, required updates, and restrictions on sharing.
Section 3

Communication decision record

The incident file should distinguish a technical status update from a notification required by an external rule. Preserve the facts, assumptions, source requirement, decision owner, approval, and timestamp at each decision point so the organization can later reconstruct why a notice was sent, updated, delayed under an applicable rule, or assessed as unnecessary.

Protect response communications because they may expose vulnerabilities, personal data, investigation strategy, or safeguards. Define access, retention, confidentiality, legal-review, and secure-channel rules before an incident. Whether a communication is legally privileged depends on the applicable law and facts; Rev. 3 does not decide that status.

  • Audience and purpose, trigger source, known facts, uncertainties, decision timestamp, owner, approver, and next update time.
  • Approved message, delivery channel, recipients, delivery evidence, corrections, and follow-up commitments.
  • Information-sharing agreement or contract basis, sanitization decision, confidentiality marking, and recipients.
  • Leadership and recovery-status updates for major incidents, including critical-supplier coordination.
Section 4

Common communication failures

A contact list is not a communications plan. Teams also need decision authority, fallback channels, message approval, confidentiality rules, jurisdiction-specific notice logic, and update cadence.

Begin the applicable notification assessment as facts develop; do not assume that technical certainty is always a prerequisite unless the controlling requirement says so. An internal severity label does not by itself establish legal reportability. Apply the relevant external trigger to the known facts and reassess when those facts change.

  • Do not turn NIST guidance into a false statutory deadline unless another instrument actually incorporates it.
  • Do not let providers contact customers, regulators, or media unless authority and conditions are explicit.
  • Do not use compromised systems or channels for sensitive incident coordination without an evaluated fallback.
  • Do not treat a decision not to notify or share as an absence of work; retain the controlling rule or agreement, facts, owner, approval, rationale, and reassessment trigger.
Primary sources

References and citations

doi.org
Referenced sections
  • Provides the governance and outcome structure in which Rev. 3 places incident communications.
doi.org
Referenced sections
  • RS.CO supports advance coordination, notifications, management approval, applicable external requirements, and secure information sharing; RC.CO supports recovery updates and critical-supplier crisis communication.
"Notify affected third parties of data breaches and other cybersecurity incidents in accordance with regulatory, legal, and contractual requirements"
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 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 Post-Incident Evidence Log Workflow
Preserve incident records and data, document recovery, produce the after-action report, and verify corrective actions under NIST SP 800-61 Rev. 3.
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.