NIST SP 800-61 Rev. 3 What is the difference between an event and an incident?
An event is any observable occurrence involving computing assets. An incident is an occurrence that meets the defined cybersecurity incident criteria.
Analyze potentially adverse events, apply documented criteria to known and assumed facts, account for false positives, and preserve the declaration or closure rationale.
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.
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.
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.
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.
Incident handling should activate response procedures, coordinate containment and recovery, communicate status, preserve evidence, and feed lessons learned back into the program.
Incident: declare an incident when analysis supports the incident definition, then apply organization-defined prioritization, response, communication, recovery, and improvement procedures.
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.
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.
Incident handling should activate response procedures, coordinate containment and recovery, communicate status, preserve evidence, and feed lessons learned back into the program.
Incident: declare an incident when analysis supports the incident definition, then apply organization-defined prioritization, response, communication, recovery, and improvement procedures.
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.
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.
Primary NIST source for the CSF Core, Organizational Profiles, Tiers, and implementation approach.
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.