Distinguish an 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.
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.
Side-by-side comparison
Event vs Incident under ISO/IEC 27035
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.
Second framework
Incident
An incident is one or more related information security events that meet the organization's criteria for harm or compromise and require managed response.
A security-relevant occurrence, alert, report, control failure, or unusual condition that may indicate a breach or weakness but still needs assessment.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
The organization should document the incident test and supporting classification criteria before a crisis; a policy breach or alert is not automatically an incident.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Once classified as an incident, activate the applicable response authority, coordination, communications, evidence handling, recovery, and lessons-learned procedures.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
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.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
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.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Use Incident when the prepared criteria show that related and identified events can harm assets or compromise operations and the team must coordinate response.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Scope and covered activity
Event
A security-relevant occurrence, alert, report, control failure, or unusual condition that may indicate a breach or weakness but still needs assessment.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Operational implication
The organization should document the incident test and supporting classification criteria before a crisis; a policy breach or alert is not automatically an incident.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Incident
Once classified as an incident, activate the applicable response authority, coordination, communications, evidence handling, recovery, and lessons-learned procedures.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Operational implication
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.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Operational implication
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.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Overlap and reuse
Event
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.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Incident
Use Incident when the prepared criteria show that related and identified events can harm assets or compromise operations and the team must coordinate response.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Practical decision rule
How should teams decide between Event and Incident for compliance planning?
Treat it as an Event while the team is only observing, recording, enriching, correlating, or assessing a possible issue and incident criteria have not been met.
Treat it as an Incident once one or more related and identified information security events can harm the organization's assets or compromise its operations under the prepared decision criteria.
Move the record from Event to Incident when the incident criteria in your policy are met, and keep the response, recovery, communication, and lessons-learned records together.
Primary ISO listing for incident management principles and process.
preparing for, detecting, reporting, assessing, and responding to incidents
Search this module
Find a question or answer quickly
5 of 5 questions
Question 1
When does an event become an information security incident?
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.
Record source, timestamps, affected asset or service, observations, validation steps, decision, rationale, assessor, and next review trigger.
Use provisional incident status when material facts are missing and delay would create response or evidence risk.
Reopen the assessment when scope, impact, related events, threat intelligence, or reporting obligations change.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
plan and prepare for incident response and to learn lessons
Question 2
What evidence should support the event-or-incident decision?
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.
Record which prepared decision criterion was met or not met.
Keep related event identifiers so later correlation can reopen the decision.
Preserve potential digital evidence securely when an investigation, prosecution, or disciplinary action may require it.
Who should decide whether an event is an incident?
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.
Name a primary and backup .
Allow quality review without making it a mandatory delay for every declaration.
Escalate unclear or high-impact cases through the authority defined in the plan.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
plan and prepare for incident response and to learn lessons
Question 4
When should the classification be reopened?
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.
Use a next-review trigger when evidence is incomplete.
Do not delete the original event trail when promoting the record to an incident.
Use recurring misclassification or false alarms to improve decision criteria, monitoring, and training.
Primary ISO listing for planning, preparing, and lessons-learned guidance.
plan and prepare for incident response and to learn lessons
Question 5
Which ISO edition and external rules apply to the decision?
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.
Record the edition and local policy version used for the decision.
Do not wait for confirmed harm where the ISO definition and prepared criteria support a provisional incident response based on the event's capacity to cause harm.
Reassess legal, contractual, privacy, safety, and regulator-notification thresholds even when the internal incident status does not change.