ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The security event vs incident question decides the moment your incident response plan starts running, who gets paged, and which records you must keep from that point on. Draw the line too low and the team spends its nights on noise. Draw it too high and a real compromise sits in an alert queue while the attacker keeps working.
NIST SP 800-61 Rev. 3 gives you three defined terms and one rule for crossing from one to the next: declare an incident when adverse events meet your defined incident criteria. This post sets out the security event vs incident distinction in Rev. 3’s own terms, explains where “breach” fits (it is a legal word, not a technical one), and shows how to write declaration criteria an analyst can apply at 2 a.m. without calling a meeting.
An event is anything observable. An adverse event is an event that could hurt you. An incident is an occurrence that actually or imminently jeopardizes confidentiality, integrity or availability, or that violates law or policy, and in practice it becomes one when someone with authority declares it against written criteria. Every incident starts as an event. Far from every event becomes an incident.
The working form of the security event vs incident answer is a funnel. Monitoring produces events, analysis separates adverse events from benign ones, and declaration criteria decide which adverse events become incidents. Rev. 3 says the volume of potentially adverse events is generally quite high, which is why it expects technical tools to filter event data down to a set a human can review.
NIST SP 800-61 Rev. 3, finalized on 3 April 2025, is a CSF 2.0 Community Profile rather than a step-by-step handling guide, but its glossary still pins down the vocabulary for the security event vs incident question. If you are new to the revision, our NIST 800-61 Rev 3 guide covers what changed from the 2012 edition.
Rev. 3 defines an event as any observable occurrence involving computing assets, including physical and virtual platforms, networks, services and cloud environments. A user signing in is an event. So is a firewall dropping a packet, a configuration change, or a scheduled backup job finishing. An event carries no judgment about harm.
An adverse cybersecurity event is an event with a potentially negative impact on cybersecurity. A run of failed sign-ins against an administrator account, malware quarantined on an endpoint, and an unexpected outbound connection to an unfamiliar host all qualify. The word that matters is “potentially”: Rev. 3 notes that anomalies may have benign or malicious foundations, and analysis is what tells them apart.
Rev. 3 takes its incident definition from FISMA 2014: “an occurrence that 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.”
Two parts of that definition catch teams out. “Imminently” means you do not have to wait for damage before declaring. And the policy-violation limb means an incident can exist with no outside attacker at all, for example an employee deliberately copying restricted data to a personal cloud account.
Breach is not a step on the security event vs incident ladder, and it is not a term you can define once and reuse. It is a legal term, and each law, regulation or contract that uses it defines it in its own way, with its own scope of data, its own harm test and its own notification trigger. The same facts can amount to a breach under one regime and not under another, and some reporting obligations are triggered by incident thresholds rather than by any breach definition.
So keep the word out of tickets, chat channels and status updates. The technical team declares and manages incidents. Legal counsel decides whether a given incident meets the breach definition of each regime that applies to you. Rev. 3 draws the same separation: RS.CO-02 asks organizations to perform notifications in compliance with the laws and regulations for their sectors, locations and customer locations, and notes that incident notification is an evolving topic with new laws arriving frequently.
One wrinkle: Rev. 3 itself lists “data breach” as an example incident type in RS.MA-03. If you keep that as a category label, state in your policy that the category is technical and does not answer the legal question. Notification clocks also start from different triggers in different regimes, so record the time of discovery and the time of declaration separately. Our breach notification guide covers the notification side.
| Term | Meaning | Who decides | What it triggers | Hypothetical example |
|---|---|---|---|---|
| Event | Any observable occurrence involving computing assets (Rev. 3 glossary) | No decision needed | Logging and retention under your logging policy | An administrator signs in from the usual office network |
| Adverse cybersecurity event | An event with a potentially negative impact on cybersecurity (Rev. 3 glossary) | Monitoring tools and analysts | Analysis, correlation and enrichment (DE.AE) | A burst of failed sign-ins on that account, then a success |
| Cybersecurity incident | Actual or imminent jeopardy to confidentiality, integrity or availability, or a violation of law or policy (FISMA 2014) | The role your policy authorizes to declare | The incident response plan, an incident record, a severity rating | The successful sign-in came from an unknown device and created a mail forwarding rule |
| Breach | Defined separately by each applicable law, regulation or contract | Legal counsel | A notification assessment under each regime | Counsel assesses whether data in that mailbox meets any breach definition that applies |
Read the security event vs incident table left to right as a funnel, and top to bottom as a hand-off: each row narrows the set and moves the decision to a more senior or more specialized owner.
Rev. 3 Subcategory DE.AE-08 states that incidents are declared when adverse events meet the defined incident criteria. Its recommendation, DE.AE-08.R1, says to apply incident criteria to the known and assumed characteristics of analyzed activity, and to consider known false positives, when deciding whether to declare.
Three words in that recommendation do the work. “Defined” means the criteria are written down before the incident, not improvised during it. “Assumed” means you may declare on a reasonable belief without proof. “False positives” means you keep a list of known benign patterns so the same harmless alert does not reopen the security event vs incident debate every week.
Criteria that hold up under pressure have four parts:
Rev. 3 Section 2.3 says the incident response policy should define events, cybersecurity incidents, investigations and related terms, and set out roles, responsibilities and authorities. That makes the policy the right home for the definitions and the declaration authority, with the detailed criteria in a supporting procedure. Our incident response policy post walks through all the Section 2.3 elements.
Section 2.3 lists investigations alongside events and incidents as terms to define. A practical use, and this is our recommendation rather than NIST’s, is a short-lived investigation state: an adverse event that needs more work gets an owner and a deadline, and must end in either a declaration or a documented closure. It stops ambiguous alerts from sitting open indefinitely and gives every security event vs incident call an end date.
The security event vs incident decision answers one question: is this an incident? Severity answers two others: how bad, and how urgent? Rev. 3 RS.MA-02.R1 keeps them in sequence: perform a preliminary review to verify that an incident has occurred, then estimate its severity and the urgency of the response.
Record the security event vs incident outcome before any severity discussion starts, so the two are never argued at the same time. Keeping the steps separate removes the main reason analysts hesitate to declare, which is the fear of setting off a full crisis response for something small. A low-severity incident should run a light process. Our incident severity levels post shows how to build that rating from Rev. 3’s six risk evaluation factors.
These cases are hypothetical and show how a reasonable set of criteria would settle each security event vs incident call.
Watch for these four errors in the security event vs incident call. Each is avoidable with written criteria and a named decision-maker.
No. Rev. 3 RS.MA-01.R1 says detection technologies should automatically report incidents they have confirmed. Human judgment is still needed for the grey zone your automatic triggers do not cover.
Yes. The FISMA definition Rev. 3 uses includes violations of law, security policies, security procedures and acceptable use policies, so a deliberate insider policy breach can be an incident.
No. Breach is a legal term defined differently by each law, regulation or contract. Counsel decides whether a declared incident meets any of those definitions.
No. Rev. 3 leaves that to you. Section 2.3 asks the policy to set roles, responsibilities and authorities, so name the declaring roles there and keep the security event vs incident criteria in a procedure they own.
Our Incident Response Toolkit provides 93 editable templates aligned to NIST SP 800-61 Rev. 3 — including the Incident Declaration Criteria, the Incident Severity and Prioritisation Matrix and the Incident Response Policy — for $99.
October 22, 2026
October 22, 2026
October 22, 2026
October 22, 2026
October 22, 2026