ISO 27001 Clause 10.2 Nonconformity and Corrective Action is a corrective control that defines how organisations react to security failures. It mandates a systematic process to identify the root cause of issues, implement fixes, and verify that those actions prevent the problem from recurring across the management system.
ISO 27001:2022 Attributes
| Attribute | Value |
|---|---|
| Control Type | Corrective |
| Information Security Properties | Confidentiality, Integrity, Availability |
| Cybersecurity Concepts | Identify, Respond, Recover |
| Operational Capabilities | Governance, Compliance, Risk Management |
Implementation Difficulty & Cost
| Metric | Rating | Details |
|---|---|---|
| Difficulty | 3/5 | Requires discipline and analytical thinking for root causes. |
| Implementation Cost | Low | Primary costs involve staff time and basic tracking software. |
| Primary Owner | ISMS Manager | Oversees the nonconformity log and tracking. |
| Accountability Cascade | Board > CISO | The board must ensure resources exist for fixes. |
ISO 27002 Control Guidance
In my experience, organisations often fail to distinguish between a simple incident and a formal nonconformity. You must implement a physical process to log every failure to meet an ISO 27001 requirement. This includes failed audits, security breaches, and missed policy targets. I look for a central register that records the date of detection and the nature of the gap.
Technical implementation requires the use of ticketing systems like Jira to track corrective actions. You should map every technical failure back to a specific control in your Statement of Applicability. I often find that IT teams fix the immediate symptom but ignore the underlying system configuration. You must ensure that technical fixes apply to all similar assets in your environment.
Behavioral guidance focuses on the culture of reporting without fear. You must train staff to identify when a process fails to meet security standards. I look for evidence that employees flag issues before they cause a major breach. Management must support this by providing the time needed to perform deep root cause analysis. A culture that hides failures will never satisfy a Lead Auditor.
The Auditor’s Eye: Expert Insight
I often find that companies perform “surface-level” root cause analysis. They simply state “human error” and move on. To me, human error is the start of the investigation, not the conclusion. Why did the person make a mistake? Was the training poor? Was the software interface confusing? I look for the “Five Whys” technique in your records. I also perform Log Reviews to see if the same issue appears multiple times. If I see a pattern of recurring failures, I will issue a Major Non-Conformity.
10 Steps to Implement Clause 10.2
Establish a Nonconformity Log
Create a central register to document every instance where your ISMS fails. This log should capture the source, the date, and the initial description. I recommend using SharePoint or Jira for this purpose. You must ensure that only authorised staff can close these entries.
Define Reporting Thresholds
Clarify what constitutes a nonconformity versus a minor observation. In my experience, setting clear triggers helps staff know when to escalate an issue. I look for these definitions in your ISMS Manual. Ensure your team understands the impact of ignoring small failures.
React to the Issue
Take immediate action to control and correct the problem. You must stop the bleeding before you start the surgery. Document your immediate response clearly in the log. I check for the timestamp between detection and the first corrective action.
Conduct Root Cause Analysis (RCA)
Use a structured method to find out why the failure happened. I prefer the “Ishikawa” diagram or the “Five Whys” approach. You must look beyond the obvious to find systemic weaknesses. I want to see this analysis attached to the record.
Search for Similar Failures
Determine if the same issue exists elsewhere in your organisation. If a server in London has a patch gap, check your servers in New York. You must prove that you looked for wider implications. I often find that isolated fixes lead to systemic vulnerabilities.
Evaluate the Need for Action
Decide if a permanent change is required to prevent recurrence. Not every minor gap needs a million-pound solution. However, you must document your decision-making process. I look for risk assessments that justify why you did or did not implement a fix.
Implement Corrective Actions
Carry out the necessary changes to your processes, technology, or people. Use tools like Microsoft Intune to push technical fixes automatically. Ensure you assign a clear owner and a deadline for each action. I look for evidence of completion in your project logs.
Review Effectiveness
Wait a suitable period after the fix and then verify that it worked. This is not the same as verifying completion. You must prove that the nonconformity has not returned. I often look for a follow-up internal audit report as evidence of this review.
Update the Risk Register
A nonconformity often changes your risk profile. You must update the relevant risks in your register based on the incident findings. I look for the link between your log and your risk management tool. This ensures your ISMS remains accurate.
Report to Management
Provide a summary of nonconformities to the board during management reviews. Leaders must understand where the system is failing. I check meeting minutes for evidence that management discussed these trends. This proves leadership commitment to continual improvement.
Requirements by Environment
- Office Environment: Log physical security breaches, such as tailgating or lost ID badges. Monitor failures in the clear desk policy and hardware disposal processes.
- Home/Remote: Identify failures in secure remote access or VPN connectivity. Document instances where personal devices were used for work without authorisation.
- Cloud Infrastructure: Track misconfigurations in AWS or Azure. Identify when IAM permissions were granted outside of the standard approval process.
The “Checkbox Compliance” Trap
| Requirement | SaaS Tool Trap | Auditor Reality |
|---|---|---|
| Root Cause Analysis | The tool provides a dropdown list of generic causes. | I want to see a unique, deep investigation into your specific failure. |
| Effectiveness Review | The system auto-closes tickets after 30 days. | I need to see a human signature or test results proving the fix worked. |
| Consequence Management | Ignoring the business impact of the failure. | I look for evidence that you evaluated the actual damage caused. |
10 Steps to Audit Clause 10.2 (Internal Audit Guide)
- Request the NC Log: Start by reviewing the central register of nonconformities.
- Verify Completeness: Compare incident logs against the NC log to see if items were missed.
- Sample Recent Entries: Pick three recent nonconformities for a detailed walkthrough.
- Check RCA Depth: Ask the owner to explain the logic behind their root cause finding.
- Verify Immediate Action: Ensure the organisation reacted quickly to contain the initial issue.
- Trace to the Risk Register: Confirm that the risk scores were adjusted following the failure.
- Review Evidence of Fixes: Check Intune logs or system settings to see if the fix exists.
- Check Effectiveness Evidence: Look for a re-test result or a follow-up audit note.
- Verify Timelines: Ensure that actions were completed by the agreed deadlines.
- Look for Patterns: Identify if the same root cause appears in multiple entries across departments.
10.2 Audit Evidence Checklist
| Evidence Item | Pass/Fail Criteria | Owner |
|---|---|---|
| Nonconformity Register | Must be up to date and contain all required fields. | ISMS Manager |
| Root Cause Analysis Report | Must show a structured investigation method (e.g., 5 Whys). | Process Owner |
| Effectiveness Verification | Documented proof that the issue has not recurred after 3-6 months. | Internal Auditor |
Required Policy Content: A Lead Auditor’s Checklist
- Definition Clause: You must define what constitutes a nonconformity in your specific business context.
- Reporting Procedure: Must detail the exact steps an employee takes to report a failure.
- RCA Methodology: You must mandate a specific analytical tool for investigations.
- Effectiveness Criteria: Must define how long you wait before a fix is considered “effective”.
- Enforcement Clause: Must define the specific disciplinary path for intentional non-compliance with security rules.
What to Teach Employees
- Identification Skills: Teach staff how to spot a deviation from the security policy.
- The Reporting Path: Ensure everyone knows how to use the Jira or SharePoint portal.
- No-Blame Culture: Explain that reporting a mistake is better for the company than hiding it.
Enforcement and Consequences
Failure to follow the corrective action process leads to Major Non-Conformities. I follow a path from verbal warning to formal findings if the NC log is ignored. Continued failure to address root causes will result in the suspension of your ISO 27001 certificate. Management must take disciplinary action against those who intentionally bypass security controls.
Common Implementation Challenges
| Challenge | Root Cause | Solution |
|---|---|---|
| Recurring Issues | Weak root cause analysis. | Train the team in the “Five Whys” technique. |
| Stale Actions | Lack of resource or priority. | Integrate security tasks into the main business project pipeline. |
| Lack of Evidence | Doing the work but not logging it. | Use automated triggers in your service desk to create audit trails. |
Sample Statement of Applicability (SoA) Entry
“Clause 10.2 is applicable. We maintain a robust process for managing nonconformities and implementing corrective actions. We utilise Jira to track root cause investigations and verify the effectiveness of all changes. This process is reviewed during our quarterly management review sessions to ensure system suitability.”
Changes from ISO 27001:2013
| ISO 27001:2013 | ISO 27001:2022 |
|---|---|
| Clause 10.1 focused on NC. | Clause 10.2 now focuses on NC (numbering change). |
| Required reacting to NC. | Stronger emphasis on changes to the ISMS after a failure. |
How to Measure Effectiveness (KPIs)
- Recurrence Rate: Percentage of nonconformities that have the same root cause as a previous entry. (Target: <5%).
- Average Time to Close: The number of days from detection to effectiveness verification. (Target: <90 days).
- Internal Audit Catch Rate: Percentage of nonconformities identified by internal audits versus external ones. (Target: >80%).
Related ISO 27001 Controls
- ISO 27001 Clause 9.2 Internal Audit: Internal audits are the primary source of formal nonconformities that feed into this process.
- ISO 27001 Annex A 5.24: Incident management provides the raw data for technical nonconformities.
- ISO 27001 Annex A 8.8: Unpatched vulnerabilities often represent a nonconformity with your technical security standards.
Clause 10.2 FAQ
What is the difference between a correction and a corrective action?
A correction fixes the immediate problem (e.g., closing an open port). A corrective action fixes the root cause (e.g., updating the firewall change procedure).
Do we need a separate log for incidents and nonconformities?
No, you can use one tool. However, you must be able to filter and identify which incidents reached the level of a formal nonconformity.
How long should we wait to review effectiveness?
In my experience, 3 to 6 months is standard. You need enough time to pass to ensure the “fix” has truly survived daily operations.
Can an auditor fail us for having too many nonconformities?
No. Having nonconformities shows the system is working. I only worry if you have the same nonconformities repeatedly.
Who should perform the root cause analysis?
The process owner who understands the failure should lead it, supported by the ISMS manager to ensure the methodology is correct.