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
Oct 15, 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 a managed security service provider (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 managed security service providers (MSSPs), cloud service providers, internet 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.
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.
Primary sources

References and citations

csrc.nist.gov3 citations
Referenced sections
  • Official final publication page and document history for the April 2025 CSF 2.0 incident response Community Profile.
  • Supports the listed internal and external roles, their responsibilities, flexible staffing models, and contractual provider boundaries.
  • Supports documented roles, responsibilities, authority, provider coordination, contact paths, and exercises.
"incident response recommendations and considerations"
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"
Show all related guides (20)

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.

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.