We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

FAQGLOBALNIST SP 800-61 Rev. 3

NIST SP 800-61 Rev. 3 What is the difference between an event and an incident?

An is any observable occurrence involving computing assets. An incident is an occurrence that meets the defined criteria.

Analyze potentially adverse events, apply documented criteria to known and assumed facts, account for false positives, and preserve the declaration or closure rationale.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
3 sections3 primary sources
Overview

An is any observable occurrence involving computing assets, including platforms, networks, services, and cloud environments. An has a negative consequence, but it is not automatically a . Declare an incident when analysis shows the occurrence actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system, or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable-use policies. NIST SP 800-61 Rev. 3 is April 2025 guidance organized as a CSF 2.0 Community Profile; the organization's policy and applicable law supply the operational criteria and any separate legal classification.

Side-by-side comparison

Event vs Incident under NIST SP 800-61 Rev. 3

Compare how teams should triage cybersecurity events, decide when an becomes an incident, and maintain evidence for incident response under NIST SP 800-61 Rev. 3.

Review all sources
First framework
Event

is the triage starting point: record what was observed, affected assets, initial impact, and whether incident criteria are met.

Second framework
Incident

An incident meets the defined declaration criteria: assign response ownership, activate applicable procedures, preserve records and evidence, and manage response and recovery.

Scope and covered activity

Event

: record the observed cybersecurity activity, affected assets, source, time, and initial indicators before deciding whether incident criteria are met.

Incident

Incident: determine that the occurrence actually or imminently jeopardizes, without lawful authority, information or system integrity, confidentiality, or availability, or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable-use policies.

Operational implication

Keep the triage record linked to the incident record when an incident is declared, but preserve the reason for the declaration.

Who must act

Event

: assign the analyst, monitoring owner, or service owner responsible for triage and initial evidence capture.

Incident

Incident: assign the incident lead and the response roles needed for technical, communications, legal, business, and recovery decisions.

Operational implication

Move from monitoring ownership to incident-response ownership only when the documented incident criteria are met.

Trigger or threshold

Event

: the trigger is an observable signal, alert, report, log entry, or external notification that may indicate cybersecurity risk.

Incident

Incident: the trigger is the supported determination that the occurrence meets the organization's incident definition; impact, scope, urgency, and available resources then help prioritize handling.

Operational implication

Document the incident criteria so teams know why an stayed in monitoring or was declared an incident.

Core obligations

Event

triage should capture facts, preserve relevant logs, assess credibility, and decide whether an incident should be declared.

Incident

Incident handling should activate response procedures, coordinate containment and recovery, communicate status, preserve evidence, and feed lessons learned back into the program.

Operational implication

Use records to support incident response, but add response-specific owners, actions, and recovery evidence after declaration.

Evidence and records

Event

: keep alerts, logs, timestamps, affected assets, triage notes, false-positive decisions, and declaration rationale.

Incident

Incident: keep declaration criteria, severity, response timeline, containment and recovery actions, communications, evidence preservation, and lessons learned.

Operational implication

Maintain traceability from detection to incident declaration, response decisions, and recovery closure.

Timing and cadence

Event

: track detection time, triage time, incident-declaration decision time, and any monitoring cadence.

Incident

Incident: track declaration time, response milestones, communication checkpoints, recovery criteria, and post-incident review timing.

Operational implication

Separate triage clocks from incident response clocks so delayed declaration and delayed recovery are visible.

Review and assurance

Event

: review whether monitoring, analysis, criteria application, closure, and declaration worked as designed.

Incident

Incident: review declaration, prioritization, response governance, evidence preservation, communications, recovery, and improvement actions.

Operational implication

Review the linked and incident records to find missed signals, unsupported assumptions, delayed decisions, or procedure gaps.

Overlap and reuse

Event

: reuse triage evidence only where it accurately supports the incident declaration and response timeline.

Incident

Incident can reuse evidence, but it still needs its own response decisions, owners, severity, recovery proof, and lessons-learned record.

Operational implication

Avoid treating the ticket as the whole incident file; declaration creates additional evidence needs.

Practical decision rule

Event

: keep the matter in event triage when evidence does not meet incident declaration criteria and monitoring remains sufficient.

Incident

Incident: declare an incident when analysis supports the incident definition, then apply organization-defined prioritization, response, communication, recovery, and improvement procedures.

Operational implication

Write the decision as triage-only, incident-declared, escalated for more analysis, or closed as false positive.

Practical decision rule

How should teams use the event vs incident distinction in practice?

  • Treat an as an observable occurrence. Analyze adverse events and declare an incident only when the occurrence meets the defined incident criteria.
  • Define declaration criteria, decision authority, analysis ownership, false-positive handling, and the record needed for declaration, continued monitoring, or closure.
  • Preserve relevant data whether or not an incident is declared. Formal notification, response, evidence handling, or retention may also follow another applicable policy, law, regulation, or contract.
Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

How should teams handle event vs. incident under NIST SP 800-61 Rev. 3 incident response?

Start with monitoring data, an alert, a user or third-party report, or another observation. An may be routine: NIST examples include a login attempt, installation of a software update, and an application's response to a transaction request. An has a negative consequence, but the cause may be a natural disaster, power failure, or cybersecurity attack. Rev. 3 focuses on adverse cybersecurity events.

Estimate the 's scope and impact, correlate information from relevant sources, add current threat and asset context, and apply the organization's defined incident criteria to known and assumed characteristics. Account for known false positives. The criteria should connect the NIST incident definition to the organization's systems, data, policies, risk, and any applicable legal definitions.

If the criteria are met, declare the incident and execute the incident response plan with relevant third parties as needed. Examples in Rev. 3 include a botnet making an internet-facing service unavailable, stolen administrative credentials putting hosted tenant data at risk, ransomware blocking systems while copying files, phishing-led account compromise and fraud, exploitation of a new appliance vulnerability, and compromised vendor software distributed to customers.

If evidence is incomplete, continue or escalate analysis under a named owner and state what fact is still needed. If the criteria are not met, document closure or continued monitoring, including any condition that would reopen triage. Do not use severity alone as the declaration threshold; severity and urgency are estimated after preliminary review verifies an incident.

A NIST incident declaration does not by itself decide whether a statutory data breach, reportable cyber incident, insurance , contractual incident, or public-notification threshold has occurred. Apply each external definition and trigger separately with the responsible legal, privacy, compliance, contractual, or regulatory owner.

  • Treat the as the starting point for triage, not the final classification.
  • Apply documented incident criteria derived from the incident definition, the organization's environment, and applicable policy or law.
  • Preserve the record when an incident is declared so the incident file shows why the decision was made.
  • Keep the handling path reviewable by documenting the facts, owner, and declaration rationale.
  • Use four explicit outcomes: continue routine monitoring, continue owned analysis, declare an incident, or close as a false positive or non-incident with a reason.
  • Reassess the decision when new evidence changes the affected assets, scope, impact, persistence, attacker activity, policy analysis, or external classification.
Question 2

What evidence should support event vs. incident under NIST SP 800-61 Rev. 3?

Keep enough evidence to show what was observed, what was decided, and why the team moved forward or stopped. That usually means the alert or log entry, the triage notes, the incident criteria that were applied, and the declaration rationale.

NIST SP 800-61 Rev. 3 says incident response policies should define events, cybersecurity incidents, investigations, and related terms. The record should also distinguish an incident declaration from later categorization, severity, priority, escalation, elevation, notification, and recovery decisions.

Record assumptions and known false positives as carefully as confirmed facts. If automation declares a confirmed incident, preserve the rule, tool result, relevant input, and routing outcome so a reviewer can understand why the plan started. If a human overrides or reverses a decision, retain both decisions and the new evidence.

Review criteria after missed detections, repeated false positives, changes to assets or services, new threat information, policy changes, exercises, or incidents. Rev. 3 does not set a review interval; the organization should define one and assign the policy owner.

  • Original alert, report, log, or observation with source and timestamp.
  • Affected assets, relevant context, corroborating data, and triage analysis.
  • Incident definition and criteria applied, decision, rationale, owner, and decision time.
  • Declaration or closure record, linked incident identifier when declared, and any monitoring or follow-up action.
  • Known and assumed facts, false-positive checks, unresolved questions, and the fact or threshold that would change the decision.
  • Separate records for incident type, severity and urgency, response priority, reporting analysis, and recovery initiation when those decisions are made.
Recommended next step

Document the incident declaration criteria

Assign triage authority and record the evidence, declaration or closure rationale, and reassessment trigger.

Assessment workflow
Open Assessment Autopilot for NIST SP 800-61 Rev. 3

Create cited tasks, evidence requests, and review checkpoints for this NIST SP 800-61 Rev. 3 scope.

Explore next step
Talk to Sorena
Review this NIST SP 800-61 Rev. 3 scope with Sorena

Review decision authority, procedures, evidence gaps, and exercise results for this incident-response scope.

Explore next step
Question 3

Questions and answers

What is the difference between an and an incident?

An is any observable occurrence involving computing assets. An incident is an occurrence that actually or imminently jeopardizes, without lawful authority, information or system integrity, confidentiality, or availability, or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable-use policies. An requires analysis; it is not automatically an incident.

When should a team declare that an is an incident?

Declare an incident when analysis shows the meets the organization's defined incident criteria. Apply those criteria to known and assumed facts and account for false positives. If evidence is incomplete, keep the under owned analysis; severity and priority are separate decisions made after the incident is validated.

Primary sources

References and citations

NIST SP 800-61 Rev. 3 Incident Response
csrc.nist.gov13 citations
Referenced sections
  • Official final publication page and document history for the April 2025 CSF 2.0 incident response Community Profile.
  • Supports the event, adverse event, and cybersecurity incident distinctions and the need to analyze adverse events before declaring an incident.
  • Supports policy-defined terms, incident criteria, declaration decisions, event analysis, and preservation of incident records and data.
Show 10 more
  • Supports the event definition, incident definition, adverse-event analysis, and incident declaration criteria used in this comparison.
  • Supports the distributed response roles, incident-lead option, analysis ownership, and coordination needed after declaration.
  • Supports the use of observable activity as the triage input and defined incident criteria as the declaration test.
  • Supports adverse-event analysis, incident declaration, execution of response procedures, and response and recovery records.
  • Supports preserving analysis findings, incident-response records, collected data, metadata, integrity, and provenance.
  • Supports tracking event analysis and incident status, action time frames, response milestones, and recovery closure.
  • Supports reviewing event analysis, declaration, response records, recovery documentation, and improvement actions.
  • Supports linking event analysis and collected data to incident declaration, response decisions, recovery, and lessons learned.
  • Supports declaration based on defined incident criteria, continued analysis where facts are incomplete, and documented incident handling after declaration.
  • Supports the event and incident definitions, adverse-event analysis, defined declaration criteria, and incident response after declaration.
"incident response recommendations and considerations"
More quoted passages
"Additional analysis is often needed to determine whether adverse cybersecurity events indicate that a cybersecurity incident has occurred"
"Definition of events, cybersecurity incidents, investigations, and related terms"
NIST SP 800-61 Rev. 3 DOI
doi.org3 citations
Referenced sections
  • DOI for the April 2025 incident response publication.
"incident detection, response, and recovery activities"
More quoted passages
"incident response recommendations and considerations"
NIST CSF 2.0 (CSWP 29)
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"

Related guides

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.

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.

Show all related guides (20)

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.

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.