The Definitive Governance Requirement.
Clause 10.2 mandates that when a nonconformity occurs, you must react to it, evaluate the need for action to eliminate the cause, and implement any action needed. This is the “self-healing” mechanism of the ISMS. It differentiates a mature governance structure from a chaotic firefighting operation.
The Mandate
Failures will happen. The standard does not punish you for failing; it punishes you for failing to learn.
When a nonconformity occurs (e.g., a policy breach, a failed audit control, or a security incident), you are legally required to execute a three-stage protocol:
- Correction (The Band-Aid): React immediately to control and correct the issue and deal with the consequences.
- Root Cause Analysis (The Surgery): Evaluate the need for action to eliminate the cause of the nonconformity, so that it does not recur or occur elsewhere.
- Corrective Action (The Cure): Implement the action needed to fix the system, not just the symptom.
The Verdict: If you simply “fix” a server outage without investigating why it went down, you have performed a Correction, but you have failed the Corrective Action requirement. You are non-compliant.
The Implementation Strategy
You must formalize your failure response. Ad-hoc fixing is not governance.
- The Containment: Stop the bleeding. Isolate the infected machine. Revoke the access. This is your immediate priority.
- The “5 Whys” Analysis: To find the Root Cause, ask “Why” five times.
- Problem: Laptop infected.
- Why? Antivirus was off.
- Why? User disabled it.
- Why? User had Admin rights.
- Why? Policy allows local Admin rights. -> This is the Root Cause.
- The Systemic Fix: Update the policy to remove Admin rights. This prevents the infection from happening to any laptop, not just the one that broke.
- Verification: Review the effectiveness of the corrective action. Did the fix actually stop the recurrence?
The Auditor’s Trap
[The Auditor’s View] The most common Major Non-Conformance here is “Blaming the Human.” I see hundreds of Corrective Action Reports that list the Root Cause as “Human Error” and the Remediation as “Retrain the Employee.”
This is lazy and unacceptable. Human error is a symptom of a system design failure. Why did the system allow the human to make the error? If you stop at “Human Error,” you have not found the root cause.
Required Evidence
An auditor looks for the forensic trail of your problem-solving.
- Non-Conformance Log: A register of all identified issues (from audits, incidents, or daily ops).
- Corrective Action Reports (CARs): Specific forms detailing the Root Cause Analysis (e.g., Fishbone diagrams or 5 Whys).
- Evidence of Implementation: Screenshots or logs proving the systemic fix was deployed.
- Effectiveness Reviews: A sign-off dated after the fix, confirming the issue has not returned.
Strategic Acceleration
Managing Corrective Actions via email chains is a liability. Things get lost, and “Overdue” actions pile up.
The Hightable™ Non-Conformance & Corrective Action Log forces you to complete the Root Cause Analysis before you can close a ticket. It ensures you never fall into the “Human Error” trap.
The Next Move: Deploy the Corrective Action Log