How should teams distinguish a security event from an information security incident under ISO/IEC 27035?
Grounded in external ISO, NIST, EU, or framework sources where relevant. This is practical implementation guidance, supporting implementation planning and should be validated against jurisdiction-specific legal, contractual, and policy requirements before implementation.
Structured answer sets in this page tree.
Cited legal and guidance references.
This FAQ for Event vs Incident defines trigger and scope, accountable owner, evidence requirements, and review timing.
Use this comparison to decide when an observed security-relevant occurrence stays an event for triage and logging, and when it becomes an information security incident that requires response, escalation, and lessons learned.
An event is a detected or reported security-relevant occurrence that needs recording, triage, and assessment before the team knows whether incident criteria are met.
An incident is one or more related information security events that meet the organization's criteria for harm or compromise and require managed response.
| Dimension | Event | Incident | Operational implication |
|---|---|---|---|
| Scope and covered activity | A security-relevant occurrence, alert, report, control failure, or unusual condition that may indicate a breach or weakness but still needs assessment. | One or more related and identified events that meet incident criteria and can harm assets, operations, confidentiality, integrity, or availability. | Classify broadly at intake, then promote only events that meet the documented incident criteria. |
| Who must act | Monitoring, service desk, SOC, product, supplier, or control owners can record and enrich the event. | Incident manager, response team, communications, legal, privacy, service owner, and evidence custodian take accountable response roles. | Keep event intake lightweight, but pre-assign incident roles so escalation is fast. |
| Trigger or threshold | Triggered by detection, user report, supplier notice, system alert, vulnerability signal, failed control, or anomalous activity. | Triggered when assessment shows actual or likely impact, compromise, policy breach, or a defined severity threshold. | The threshold belongs in the severity matrix, not in ad hoc judgment during a crisis. |
| Core obligations | Event requires practical governance: scope, roles, risk or impact decisions, evidence, operating cadence, monitoring, review, and improvement. | Incident expects its own required or recommended outcomes, which may include legal duties, assurance criteria, control objectives, profiles, or risk methodology. | Translate both sides into a single task register only after labeling which requirement or guidance source each task satisfies. |
| Evidence and records | Event log, source alert, reporter details, timestamp, affected asset, initial classification, triage notes, and closure or escalation reason. | Incident record, severity decision, response timeline, containment and recovery actions, notifications, approvals, retained logs, and lessons-learned actions. | Evidence should show the decision path from detection to closure or incident response. |
| Timing and cadence | Handled through intake and triage clocks set by monitoring, service, and risk procedures. | Handled through incident-response SLAs, legal-notification review windows, customer commitments, and recovery objectives. | Separate triage timing from incident response timing so routine alerts do not hide urgent incidents. |
| Enforcement or assurance route | Reviewed through monitoring quality, internal audit, control testing, and trend analysis. | Reviewed through incident postmortems, management review, audit evidence, customer assurance, and regulator or contract reporting where applicable. | Both records may be audited, but incident records need stronger chain-of-custody and decision evidence. |
| Overlap and reuse | May become an incident after correlation or assessment, or may close as benign, duplicate, expected, or informational. | Always starts from event evidence, but requires a response record once criteria are met. | Maintain a clear status transition so evidence can be reused without rewriting history. |
| Practical decision rule | Use Event when the team is observing, logging, enriching, correlating, or assessing a possible security issue. | Use Incident when the team has confirmed incident criteria and must coordinate response, recovery, communications, and lessons learned. | The operating rule should be simple enough for first-line triage to apply consistently. |
A security-relevant occurrence, alert, report, control failure, or unusual condition that may indicate a breach or weakness but still needs assessment.
One or more related and identified events that meet incident criteria and can harm assets, operations, confidentiality, integrity, or availability.
Classify broadly at intake, then promote only events that meet the documented incident criteria.
Monitoring, service desk, SOC, product, supplier, or control owners can record and enrich the event.
Incident manager, response team, communications, legal, privacy, service owner, and evidence custodian take accountable response roles.
Keep event intake lightweight, but pre-assign incident roles so escalation is fast.
Triggered by detection, user report, supplier notice, system alert, vulnerability signal, failed control, or anomalous activity.
Triggered when assessment shows actual or likely impact, compromise, policy breach, or a defined severity threshold.
The threshold belongs in the severity matrix, not in ad hoc judgment during a crisis.
Event requires practical governance: scope, roles, risk or impact decisions, evidence, operating cadence, monitoring, review, and improvement.
Incident expects its own required or recommended outcomes, which may include legal duties, assurance criteria, control objectives, profiles, or risk methodology.
Translate both sides into a single task register only after labeling which requirement or guidance source each task satisfies.
Event log, source alert, reporter details, timestamp, affected asset, initial classification, triage notes, and closure or escalation reason.
Incident record, severity decision, response timeline, containment and recovery actions, notifications, approvals, retained logs, and lessons-learned actions.
Evidence should show the decision path from detection to closure or incident response.
Handled through intake and triage clocks set by monitoring, service, and risk procedures.
Handled through incident-response SLAs, legal-notification review windows, customer commitments, and recovery objectives.
Separate triage timing from incident response timing so routine alerts do not hide urgent incidents.
Reviewed through monitoring quality, internal audit, control testing, and trend analysis.
Reviewed through incident postmortems, management review, audit evidence, customer assurance, and regulator or contract reporting where applicable.
Both records may be audited, but incident records need stronger chain-of-custody and decision evidence.
May become an incident after correlation or assessment, or may close as benign, duplicate, expected, or informational.
Always starts from event evidence, but requires a response record once criteria are met.
Maintain a clear status transition so evidence can be reused without rewriting history.
Use Event when the team is observing, logging, enriching, correlating, or assessing a possible security issue.
Use Incident when the team has confirmed incident criteria and must coordinate response, recovery, communications, and lessons learned.
The operating rule should be simple enough for first-line triage to apply consistently.
Start with the operational decision: define what Event vs Incident means in your ISO/IEC 27035 scope, who owns it, and what record proves the decision is current.
For incident work, decide the timer and escalation path before an event occurs: classification, severity, legal-notification review, containment owner, communications owner, recovery owner, and evidence custodian. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.
Primary ISO listing for incident management principles and process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
The evidence should show the process operating. For this artifact, the strongest record usually includes incident policy, response plan, severity matrix, triage records, escalation logs, notifications, containment and recovery notes, lessons learned, and retained logs.
Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
Primary ISO listing for ICT incident response operations guidance.
This page moves ISO/IEC 27035 guidance into an auditable operating loop with owners, evidence requests, decision records, and scheduled review dates.
Convert Event vs Incident into accountable tasks, evidence requests, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.
For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.
Primary ISO listing for incident management principles and process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.
A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.
Primary ISO listing for incident management principles and process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
"preparing for, detecting, reporting, assessing, and responding to incidents"
"plan and prepare for incident response and to learn lessons"
"information security incident response in ICT security operations"