FAQGLOBALNIST SP 800-61 Rev. 3

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

Document the internal and external roles needed for an incident, the authority each role can exercise, its backup, its handoffs, and the evidence it owns.

Rev. 3 does not require one team name or staffing model. Roles vary by organization and incident, and may be filled by employees, contractors, providers, partners, or other available specialists.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Questions
2

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

Define the Computer Security Incident Response Team () as a coordinated set of roles, not necessarily one permanent department. NIST SP 800-61 Rev. 3, published in April 2025 as a CSF 2.0 Community Profile, identifies leadership, , technology professionals, legal, public affairs and media relations, human resources, physical security and facilities management, asset owners, and third parties as possible participants. Select the roles needed for the organization and each incident, then document authority, availability, handoffs, and provider boundaries. Rev. 3 is guidance, not a universal staffing mandate; applicable law, policy, regulation, and contract terms may assign additional roles or decision rights.

Search this module

Find a question or answer quickly

2 of 2 questions
Question 1

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

Start with incident leadership and handling. Leadership oversees the capability, funds it, and may approve high-impact actions such as shutting down or rebuilding a critical service. verify incidents, collect and analyze data and evidence, prioritize work, limit damage, find root causes, and help restore operations.

Add the specialists and owners the incident requires. Technology professionals investigate and restore their systems; legal advises on applicable law, privacy, contracts, and legal consequences; public affairs manages approved media communication; human resources supports personnel matters; facilities teams support physical incidents and access; and asset owners set business and recovery priorities and confirm status.

Choose a staffing model that fits the organization. may be on staff, under contract, or available from a parent organization, specialist provider, business partner, or law-enforcement agency. An organization may combine these approaches. If several internal teams cover different regions or technology segments, coordinate them as one entity so procedures, training, and incident information remain consistent.

When a provider performs part of detection, response, or recovery, document the in the contract. Include information flows, coordination, authority to act, restrictions on sharing or operational decisions, access protections, and the responsibilities that remain with the organization. For example, state whether a cloud provider or internet service provider may automatically isolate a service, whether an MSSP may share sanitized indicators with other customers, and who preserves provider-side logs.

Provider access creates its own risk. NIST notes that service providers may have privileged system access and sensitive data, so plans and contracts should address provider compromise, malicious insiders, confidentiality, and loss of access when the relationship ends. A provider's capability to correlate activity across customers can improve detection, but it does not replace organization-side ownership.

  • Leadership oversees incident response, allocates funding, and may approve high-impact response actions.
  • verify incidents, collect and analyze data and evidence, prioritize response activities, and limit damage.
  • Technology professionals, legal, public affairs and media relations, human resources, and physical security and facilities management support response and recovery as needed.
  • Asset owners help set response and recovery priorities for affected assets and receive status updates.
  • Third parties, such as MSSPs, cloud service providers, ISPs, business partners, specialist responders, and law enforcement agencies, may support incident response when needed; their authority and availability should not be assumed.
  • Assign a lead for each incident or define an equivalent coordination role, then name the backups who cover absence, time-zone gaps, and provider unavailability.
  • Write action-level authority for high-risk decisions such as confiscating or disconnecting assets, shutting down or rebuilding services, delaying containment for observation, contacting authorities, approving public statements, and declaring recovery complete.
Citations
NIST CSF 2.0 (CSWP 29)

Primary NIST source for the CSF Core, Organizational Profiles, Tiers, and implementation approach.

Question 2

What evidence should support CSIRT roles under NIST SP 800-61 Rev. 3?

Document the role roster, primary and backup contacts, decision and action authority, escalation and elevation paths, availability, geographic and system scope, evidence ownership, provider responsibilities, and handoffs. Map each role to the incident types and operating periods it covers instead of assuming one roster fits every incident.

Test the roster through contact checks, exercises, and incidents. Record whether people could be reached, obtained the access and information they needed, understood who could approve each action, and completed provider handoffs. Correct gaps, assign an owner and due date, and retain the test or incident record that shows the change was verified.

Review assignments after personnel, organizational, technology, facility, supplier, legal, policy, or contract changes and after an exercise or incident exposes a gap. Rev. 3 does not set a universal review interval, so the organization should define one that fits its risk and operating model.

  • Write the role, authority, and backup for each incident response function.
  • Document which actions leadership can approve and which actions can take directly.
  • Record the external parties that may be involved, such as providers, business partners, or law enforcement.
  • Capture the status-update and escalation path for asset owners and senior leadership.
  • Test contact paths, decision rights, provider handoffs, and after-hours coverage in exercises; review assignments after incidents and relevant organizational or service changes.
  • Retain the approved responsibility matrix or plan version, contact-test results, exercise findings, provider clauses, access approvals, and evidence of completed corrective actions.
  • Record exceptions explicitly, including an unavailable specialist, a provider action the contract prohibits, a legal restriction on sharing, or an emergency delegation of authority.
Citations
NIST CSF 2.0 (CSWP 29)

Primary NIST source for the CSF Core, Organizational Profiles, Tiers, and implementation approach.

Primary sources

References and citations

doi.org
Referenced sections
  • Primary NIST source for the CSF Core, Organizational Profiles, Tiers, and implementation approach.
"does not prescribe how outcomes should be achieved"
doi.org
Referenced sections
  • DOI for the April 2025 incident response publication.
"Many individuals, teams, and third parties hold a wide variety of roles and responsibilities"
csrc.nist.gov
Referenced sections
  • Supports documented roles, responsibilities, authority, provider coordination, contact paths, and exercises.
"incident response recommendations and considerations"
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: 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.