WorkflowGLOBALNIST SP 800-61 Rev. 3

NIST SP 800-61 Rev. 3 Communications Escalation Workflow

Decide who must know, who may speak, what can be shared, and when each communication decision must be reassessed.

Keep coordination, formal notification, public communication, and information sharing as separate decision streams linked to one incident timeline.

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

After an incident is declared, open four separate communication decisions: incident coordination, formal notification, public communication, and . NIST says information sharing is usually voluntary, while notification may be required by law, regulation, policy, or contract. Escalation generally increases resources or changes time frames; elevation involves higher management. SP 800-61 Rev. 3 does not create a universal reporting deadline.

Section 1

Workflow steps for incident communication and escalation

Open a communication record linked to the incident timeline. Do not wait for every fact to be final: record what is known, what remains uncertain, and the event that will trigger reassessment. Recheck audiences and duties when the incident's scope, magnitude, affected parties, containment status, or recovery estimate changes.

  • 1 | Establish authority | Owner: incident lead | Record the communication lead, legal and privacy reviewers, management approver, spokesperson, provider contacts, authorized senders, and secure fallback channel.
  • 2 | Map affected parties | Owner: incident and asset owners | Record affected services, data, people, locations, customers, suppliers, regulators, law enforcement criteria, and each party's response role.
  • 3 | Separate the four streams | Owner: communication lead | For coordination, notification, public communication, and information sharing, record the purpose, recipients, authority, confidentiality limits, and whether the stream is required or voluntary.
  • 4 | Assess external duties | Owner: legal or privacy lead | For each possible notice, record the controlling law, regulation, policy, or contract; the facts known; the trigger decision; the deadline calculation if applicable; uncertainty; and the next reassessment event.
  • 5 | Decide each branch | Owner: designated decision owner | If communication is required or approved, proceed to drafting and delivery. If notice, public communication, or voluntary sharing is not required or approved, record the decision, authority, facts, rationale, approver, and event that will reopen it.
  • 6 | Approve and send | Owner: designated sender | Preserve the validated facts, message version, approvers, recipients, secure delivery channel, timestamp, delivery evidence, correction history, and promised follow-up.
  • 7 | Continue through recovery | Owner: incident and recovery leads | Update senior leadership for major incidents, coordinate with suppliers under applicable contracts, communicate restoration progress through approved channels, and route communication lessons to ID.IM.
Section 2

Decision points for incident communication and escalation

Apply the organization's risk factors to each decision. Rev. 3 lists examples such as asset criticality, functional and data impact, the stage of observed activity, threat-actor characterization, recoverability, time-criticality, and available resources. These factors inform response priority, escalation or elevation, and the decision to initiate recovery; they are not a universal severity scale.

  • Has risk increased enough to change response priority, add resources, shorten a time frame, change strategy, or involve higher management?
  • Is this coordination, formal notification, public communication, voluntary information sharing, or more than one separate stream?
  • Which current facts activate a legal, regulatory, policy, or contractual notification rule, and which facts remain unverified?
  • Would sharing reveal sensitive incident records, personal data, privileged material, exploited vulnerabilities, or attacker-useful detail?
  • Who has authority to approve the communication, who sends it, who must receive it, and when must the decision be reviewed again?
  • Does malicious insider activity require an approved internal notification to human resources?
  • Would sharing observed tactics, techniques, and procedures with a sector Information Sharing and Analysis Center help peers, and do the response plan and sharing agreement permit it?
Section 3

Evidence fields for incident communication and escalation

Keep one record per communication decision, including decisions not to notify or share. The record should let a later reviewer reconstruct the available facts, authority, approval, message, delivery, and reassessment without treating the workflow as a substitute for the controlling notice rule.

  • Decision ID, incident ID, communication stream, purpose, audience, sensitivity, and approved channel.
  • Controlling requirement or sharing authority, trigger facts, assumptions, unresolved facts, decision timestamp, owner, approver, and next review event.
  • Approved message version, factual-source references, recipients, sender, delivery timestamp, delivery proof, corrections, and follow-up commitments.
  • Supplier or information-sharing agreement, contractual restrictions, sanitization decision, permitted recipients, and disclosure limitations.
  • Links to incident status, magnitude assessment, containment decision, recovery progress, and the common incident timeline.
Primary sources

References and citations

doi.org
Referenced sections
  • CSF 2.0 supplies outcome language but leaves actions, responsible roles, and implementation details to the organization.
csrc.nist.gov
Referenced sections
  • RS.AN-06 calls for recording investigation actions while protecting record confidentiality, integrity, and access. RS.CO and RC.CO support secure communication consistent with response plans, laws, policies, agreements, and approved messaging.
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 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: 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.