Security Event vs Incident vs Nonconformity in ISO 27001

A security event, an information security incident and a nonconformity are related concepts, but they answer different questions. Confusing them causes alert overload, incomplete investigations and corrective action that never reaches the underlying management-system weakness.

The simplest distinction is:

• an event is something observed that may be relevant to information security;
• an incident is an event or series of events assessed as requiring coordinated security response; and
• a nonconformity is a failure to meet an applicable requirement.

These are practical summaries, not reproduced ISO definitions. An organisation should define terms and criteria that fit its scope, risks, obligations and selected standards.

The relationship is not a straight line

Not every event becomes an incident. Not every incident proves a nonconformity. A nonconformity can exist without any incident.

For example:

• A monitoring tool reports an unsuccessful login burst. Analysis shows approved testing. It remains a reviewed event.
• A stolen laptop containing protected information meets the organisation’s incident criteria and activates response.
• The laptop was encrypted and handled as designed, so the incident may not reveal a management-system failure.
• A required quarterly access review was missed. That is a nonconformity even if no unauthorised access occurred.
• Investigation of an account compromise reveals that required access removal repeatedly failed. The same case is an incident and evidence of a nonconformity.

Treat classification as a set of recorded decisions, not an automatic label conversion.

What counts as a security event?

Security events come from people, technology, suppliers and business processes. Examples include:

• malware or authentication alerts;
• a user reporting suspicious email;
• unexpected data transfer;
• a missing device;
• a control failure or disabled log source;
• a supplier warning;
• an unusual privileged action;
• a vulnerability report; or
• unexpected service behaviour.

Events need an intake and assessment process. Otherwise, the organisation cannot show which signals were considered or why they were dismissed.

The initial record should capture source, time, affected service or information, description, immediate action and assigned owner. Automated events should be reconciled to the known monitored population so failed integrations do not create silent gaps.

When does an event become an incident?

Use defined assessment criteria rather than personal intuition. Consider:

• actual or potential effect on confidentiality, integrity and availability;
• sensitivity and quantity of affected information;
• affected business services and users;
• continuing attacker activity or exposure;
• legal, regulatory, contractual and customer obligations;
• operational disruption and recovery dependency;
• supplier or multi-entity impact;
• reliability of available evidence; and
• potential for escalation.

The assessor should record known facts, uncertainty, classification, severity, owner and decision time. A false positive can still require a defensible record when it crossed the investigation threshold.

ISO/IEC 27035-1 provides guidance for a structured information-security incident lifecycle. The organisation should adapt its workflow proportionately and retain its own decision rules.

What makes something a nonconformity?

A nonconformity exists when evidence shows that a requirement has not been fulfilled. The relevant requirement may come from the ISMS criteria being audited, an approved organisational rule, a contractual commitment or another defined source within the audit scope.

Examples include:

• a required approval was not obtained;
• an agreed control did not operate over the defined population;
• a mandatory record was absent;
• assigned incident reviews were not performed;
• corrective action was closed without evaluating effectiveness; or
• the organisation did not follow its approved risk method.

An undesirable outcome alone does not prove nonconformity. Strong controls reduce risk but do not eliminate uncertainty. The auditor needs objective evidence and a specific unmet requirement.

The major versus minor nonconformities guide explains classification and evidence without assuming that one isolated failure always receives the same grade.

Nonconformity is not the same as legal noncompliance

“Non-compliance” is often used broadly for failure to meet a law, regulation, contract or internal rule. In management-system auditing, nonconformity has a more precise relationship to the audit criteria.

A privacy incident may trigger a legal assessment but not automatically establish that a law was breached. An ISO audit finding may show failure against an internal procedure without establishing legal liability. Route legal conclusions to competent legal or regulatory owners and record the criteria separately.

Do not ask an incident responder or certification auditor to make conclusions outside their authority.

Use a three-decision workflow

One case record can support three explicit decisions.

Decision 1: Is the signal relevant and credible?

Validate source, scope and basic facts. Close noise with a reason, or escalate for further investigation.

Decision 2: Does it meet incident criteria?

Assess information-security impact, urgency, obligations and coordination needs. Declare the incident, priority and response owner where criteria are met.

Decision 3: Does evidence show an unmet requirement?

During or after response, compare what occurred with applicable criteria. If a requirement was not met, record the nonconformity and route it to correction and corrective-action governance.

These decisions can occur at different times. Avoid delaying urgent response while investigating a possible audit finding.

Examples across common scenarios

Scenario	Event decision	Incident decision	Nonconformity decision
Blocked malicious attachment	Relevant event	May remain below incident threshold after assessment	None unless evidence shows a required control or process failed
Lost encrypted laptop	Relevant event	May require incident treatment because of uncertainty and obligations	Not automatic; test whether required handling was followed
Missed access review	Control event or assurance observation	No incident unless unauthorised activity or material exposure is identified	Likely if an applicable review requirement was not met
Compromised shared account	Relevant event	Likely incident requiring coordinated response	Possible if shared access violated an applicable rule or selected control design
Failed exercise escalation	Exercise observation	Simulated, not necessarily a real incident	Possible if the response arrangement failed defined criteria

The table supports analysis; it does not replace facts, scope or professional judgement.

Keep records connected but controlled

An event record may become an incident case and generate a nonconformity. Use linked identifiers so evidence remains traceable without copying sensitive material.

Event record

Retain source, time, observation, validation, classification and closure or escalation reason.

Incident record

Retain impact assessment, timeline, decisions, actions, evidence locations, communications, recovery validation and lessons.

Nonconformity record

Retain the unmet requirement, objective evidence, correction, cause analysis, corrective action, owner, timing and effectiveness evaluation.

Restrict forensic, personal, legal and vulnerability information according to need. An evidence index can point to authoritative sources without turning every audit record into a sensitive data repository.

The evidence-register guide provides a structured way to maintain traceability.

Assign ownership to the decision

Different people may own different parts:

• monitoring or service teams own intake;
• a competent security role assesses and declares incidents;
• the response lead coordinates containment and recovery;
• legal, privacy or regulatory owners assess obligations;
• the process or control owner addresses the failed requirement;
• an authorised manager accepts residual risk; and
• an auditor reports findings independently.

Small organisations may combine roles, but they should preserve authority and objectivity. An operator should not quietly downgrade an event to avoid performance consequences, and an auditor should not take ownership of the corrective action they will later evaluate.

From incident lesson to corrective action

An incident review can identify immediate technical causes and wider management-system contributors. Ask:

• What allowed the event to occur?
• Why was it not prevented or detected earlier?
• Did people follow the defined process?
• Was the process suitable and resourced?
• Did the same weakness affect other systems?
• Which requirement, risk or control needs change?
• How will recurrence reduction be evaluated?

Correction addresses the observed problem, such as disabling an exposed account. Corrective action addresses the cause of the nonconformity, such as repairing the identity offboarding workflow and verifying it across the employee population.

The incident-management evidence guide explains how to preserve the timeline and keep improvement visible after operational closure.

Audit questions and sampling

An auditor may ask:

• How are events reported and reconciled?
• What criteria trigger incident declaration?
• Who can change classification or severity?
• How are possible legal issues routed?
• When does incident review consider nonconformity?
• Are corrective actions traced to causes and effectiveness?
• Can the complete population of events, incidents and findings be identified?

Sample across detection sources and classifications. Include a dismissed alert, a security incident with no finding, a nonconformity with no incident and a case that produced both.

Use the ISO 27001 clause explainer to understand connected requirements, while evaluating the organisation’s actual criteria and evidence.

Pass

Definitions, thresholds and owners were clear. Sampled cases showed consistent assessment, authorised response and evidence-based findings. Corrective actions were evaluated for effectiveness.

Partial

Incidents were handled competently, but event dismissal reasons were inconsistent and control failures did not always reach the corrective-action process.

Fail

Only confirmed breaches were recorded, alert closures were untraceable and repeated requirement failures were treated as isolated technical tickets.

Common mistakes

Avoid:

• declaring every alert an incident;
• recording only events with confirmed impact;
• assuming every incident proves control failure;
• treating an absence of incidents as proof of effectiveness;
• writing findings without an unmet requirement;
• making legal conclusions without authority;
• closing incidents before improvement receives an owner; or
• allowing the same team to implement and independently approve its own corrective action.

The practical conclusion

Events tell you what was observed. Incident classification tells you what needs coordinated security response. Nonconformity analysis tells you whether an applicable requirement was not met. Keeping these decisions separate produces clearer escalation, stronger evidence and more meaningful improvement.

Design one connected workflow, record the reason for each classification and route causes to the right owners. That lets the organisation respond quickly without turning every alert into a finding—or letting a real management-system weakness disappear inside a closed ticket.

The subject perspective was informed by Advisera’s comparison of security events, incidents and non-compliance, with incident lifecycle context checked against ISO/IEC 27035 guidance.