ISO Digital Solutions Get the ISMS Framework

SGRII Insights  ·  ISO 27001:2022  ·  2026

‘Employee Clicked the Phishing Link’ Is Not a Root Cause. It Is a Description of What Happened. ISO 27001 Clause 10.2 Requires You to Explain Why the System Allowed It.

Root cause analysis in information security follows the same principle as every other management system: the root cause is always a system deficiency. The system either failed to prevent the error or failed to detect the condition that enabled it. If the analysis stops at the person, the analysis has not started.

The Root Cause Categories for Information Security Nonconformities

ISO 27001 Clause 10.2 requires the same corrective action methodology as any Annex SL standard: react to the nonconformity, evaluate the need for action to eliminate causes, implement action, review effectiveness, and update risks and opportunities if necessary. The methodology is identical. The cause categories are different.

In information security, nonconformities typically trace to six system cause categories: Control design failure (the control was designed inadequately for the threat it addresses), Control implementation gap (the control was designed correctly but not fully implemented), Competence deficiency (the person operating the control lacked the required skill), Technology failure (a technical control malfunctioned or was misconfigured), Process gap (no process existed to address the situation), and Third-party failure (a supplier or external provider failed to meet contractual security requirements).

Each category maps to a specific ISO 27001 clause or Annex A control — and therefore to a specific corrective action pathway. A control design failure (Category 1) traces to Clause 6.1 risk treatment and requires SoA review. A competence deficiency (Category 3) traces to Clause 7.2 and requires competence framework update. A third-party failure (Category 6) traces to A.5.19–5.22 supplier controls. The root cause category determines the corrective action pathway. ‘Retrain the employee’ is not a pathway. It is a reflex.

The Phishing Example: What System Deficiency Analysis Actually Looks Like

Incident: employee clicked a phishing link. Malicious payload delivered. Credentials compromised. Lateral movement detected and contained by SOC after four hours.

Root cause analysis stopped at ‘human error’: employee clicked the link. Corrective action: retrain the employee. Close the NC.

Root cause analysis continued to system deficiency: Why did the phishing email reach the employee’s inbox? Email filtering controls (A.8.23 web filtering, email gateway) failed to classify the message as malicious. Why did clicking the link deliver a payload? Endpoint detection controls (A.8.7 protection against malware) did not block the payload execution. Why were credentials compromised? The compromised account was not protected by MFA (A.8.5 secure authentication). Why did lateral movement succeed for four hours? Monitoring controls (A.8.16) did not detect the anomalous authentication pattern within the defined response window.

The system deficiency analysis identifies four control gaps across four Annex A controls. The corrective actions are specific: enhance email filtering rules, deploy endpoint detection response capability, implement MFA on all accounts with privileged or administrative access, and reduce the monitoring detection-to-alert window. Each action addresses a system cause. ‘Retrain the employee’ appears nowhere — because the employee’s click was the trigger, not the cause. The system should have prevented the consequence of the click at four separate points. It failed at all four.

The Three Registers: NC & CA, Continual Improvement, and Incident Log

The correct Clause 10 architecture for an ISMS requires three distinct registers, each serving a different function:

NC & CA Register (Clause 10.2) — Reactive responses to nonconformities. Triggered by audit findings, procedural failures, control breakdowns. Root cause analysis identifies system deficiency. Corrective action addresses the system cause. Effectiveness verification is evidence-based.

Continual Improvement Register (Clause 10.1) — Proactive system enhancements. Triggered by management review outputs, performance evaluation trends, context changes, and strategic direction updates. Not triggered by incidents or failures. This is the forward gear of the ISMS.

Incident Log (Annex A.5.24–5.28) — Operational security event and incident records. Classification, response, containment, evidence collection, post-incident review. Outputs feed into both the Risk Register (new risk identification) and the Continual Improvement Register (system enhancement recommendations). The incident log is an operational record. It is not a Clause 10 instrument.

All three exist. None substitutes for the others. An ISMS with only an incident log under Clause 10 has neither a corrective action mechanism nor a continual improvement mechanism. It has an event response system. That is necessary. It is not sufficient.

The SGRII Position

The SGRII position on Clause 10.2 is identical across all twelve ISO standards: the root cause is always a system deficiency. ‘Human error’ is never an acceptable root cause. The corrective action must address the system cause, not the human action. Effectiveness verification must be evidence-based, not date-based.

For ISO 27001 specifically, the SGRII ISMS Framework enforces this through: a root cause category taxonomy (six categories mapped to specific clauses and Annex A controls), mandatory clause reference in every root cause analysis, and a corrective action pathway that traces from root cause category to the specific system component that requires modification. The NC & CA Register, Continual Improvement Register, and Incident Log exist as three separate instruments — because the standard requires three separate functions.