Distinguish an information security event from an incident under ISO/IEC 27035 and record the assessment without discarding useful event evidence.
ISO/IEC 27035 is voluntary guidance, not a law or standalone certification scheme. Apply separate legal, contractual, regulatory, privacy, and evidence requirements where relevant.
Structured answer sets in this page tree.
Cited legal and guidance references.
An indicates a possible security breach or control failure. An is one or more related and identified events that can harm the organization's assets or compromise its operations. Under ISO/IEC 27035-1:2023, the team should record the occurrence, apply prepared criteria, preserve the reasoning, and reopen the decision when later facts change the test.
This comparison helps decide when an observed security-relevant occurrence stays an event for triage and logging, and when it becomes an 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, security operations center, product, supplier, or control owners can record and enrich the event. | , 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 one or more related and identified events can harm organizational assets or compromise operations under the prepared criteria. | The organization should document the incident test and supporting classification criteria before a crisis; a policy breach or alert is not automatically an incident. |
| Core obligations | Record enough information to validate the event: source, time, affected asset or service, observable facts, initial impact, and the triage decision. | Once classified as an incident, activate the applicable response authority, coordination, communications, evidence handling, recovery, and lessons-learned procedures. | Keep one traceable record as the event is validated, closed, or promoted to an incident; do not discard the evidence and reasoning behind the classification decision. |
| 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 service-level targets, 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 can be reviewed. Apply formal evidence-preservation or chain-of-custody controls when investigation, disciplinary action, litigation, law enforcement, or another evidential purpose makes them necessary, not automatically to every event or incident. |
| Overlap and reuse | May become an incident after correlation or assessment, may move to vulnerability or service management, or may close as a false alarm, duplicate, expected, or informational event. | 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 prepared criteria show that related and identified events can harm assets or compromise operations and the team must coordinate response. | 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, security operations center, product, supplier, or control owners can record and enrich the event.
, 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 one or more related and identified events can harm organizational assets or compromise operations under the prepared criteria.
The organization should document the incident test and supporting classification criteria before a crisis; a policy breach or alert is not automatically an incident.
Record enough information to validate the event: source, time, affected asset or service, observable facts, initial impact, and the triage decision.
Once classified as an incident, activate the applicable response authority, coordination, communications, evidence handling, recovery, and lessons-learned procedures.
Keep one traceable record as the event is validated, closed, or promoted to an incident; do not discard the evidence and reasoning behind the classification decision.
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 service-level targets, 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 can be reviewed. Apply formal evidence-preservation or chain-of-custody controls when investigation, disciplinary action, litigation, law enforcement, or another evidential purpose makes them necessary, not automatically to every event or incident.
May become an incident after correlation or assessment, may move to vulnerability or service management, or may close as a false alarm, duplicate, expected, or informational event.
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 prepared criteria show that related and identified events can harm assets or compromise operations and the team must coordinate response.
The operating rule should be simple enough for first-line triage to apply consistently.
Detection creates an report, not an automatic incident declaration. The evaluates the report against criteria prepared in advance, including the event type, affected assets or services, actual or projected adverse consequences, and the organization's classification scale.
Classify the record as an when one or more related and identified events can harm the organization's assets or compromise its operations. Representative examples include ransomware that makes a service unavailable, accidental disclosure of protected information, unauthorized modification of data, theft of a device containing organizational information, or fire that damages an information system. These examples are informative, not automatic classifications; the specific facts and prepared criteria control. If the incident test is not met, retain the assessment and route a false alarm, vulnerability, routine service issue, or other event through the appropriate process.
Primary ISO listing for incident management principles and process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
Keep the original event report, source alert or observation, timestamps, affected assets or services, validation steps, correlated events, available impact evidence, criteria applied, assessor, decision time, status, rationale, and next action. Log later changes instead of rewriting the first assessment.
A false alarm means the reported event was found not to be real or to have any impact. A real event that does not meet incident criteria can still require vulnerability handling, service management, monitoring, or another follow-up process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
Primary ISO listing for ICT incident response operations guidance.
Connect event assessment to prepared criteria, named decision owners, retained evidence, and reassessment triggers.
Convert Event vs Incident into accountable tasks, evidence requests, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
The evaluates the event report and declares the incident using criteria defined during planning. Security and non-security personnel should supply the asset, service, business, privacy, safety, supplier, and legal facts needed for the decision.
The policy should permit a possible or provisional incident status when facts are incomplete. If the criteria are met, establish the required incident response teams and start the response process without waiting for certainty about every detail.
Primary ISO listing for incident management principles and process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
Reopen the decision when new related events, affected assets, business impact, threat intelligence, supplier facts, or evidence changes the original test. An event closed as benign or routine can later become part of an incident after correlation.
During response, continue reassessing the incident's type, scope, priority, and severity. Keep each status change, timestamp, reason, and decision maker in the incident register.
Primary ISO listing for incident management principles and process.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
ISO/IEC 27035-1:2023 provides the definitions and the generic process for organizations of any type, size, or nature, including external incident-management providers. ISO/IEC 27035-2:2023 covers the policy, plan, classification scale, forms, roles, exercises, and lessons learned. ISO/IEC 27035-3:2020 gives ICT operational guidance for detection, notification, triage, analysis, response, and reporting.
The series is voluntary guidance, not a law or a standalone certification. It does not set a universal number of affected users, duration, financial loss, severity label, or notification deadline that turns every event into an incident. An adopted policy or contract can make the organization's procedure mandatory internally, while applicable law or regulation can define a different reportable-incident test. Apply and record each test separately.
ISO identifies Part 1:2023 as the generic foundation for incident-management principles, definitions, and process.
ISO identifies Part 2:2023 as planning and preparation guidance, including classification and record design.
ISO identifies Part 3:2020 as ICT incident-response operations guidance.
"preparing for, detecting, reporting, assessing, and responding to incidents"