ISO 27001 Nonconformity and Corrective Action (Clauses 10.1 and 10.2)

Clauses 10.1 and 10.2 of ISO 27001 govern how your ISMS responds when something fails to meet a requirement. Every ISMS will generate nonconformities. The question is not whether they happen but whether your organization handles them in a structured, evidence-producing way that drives real improvement rather than just documentation theater.

The corrective action process, often referred to as CAPA (corrective and preventive action, inherited from quality management systems), is one of the most auditor-visible parts of your ISO 27001 programme. Certification auditors will sample open and closed nonconformities, verify that root causes were actually identified, and check that corrective actions were verified for effectiveness. Weakness here reliably produces findings.

What Clauses 10.1 and 10.2 actually say

Clause 10.1 (Continual Improvement) sets the expectation that the organization continually improves the suitability, adequacy, and effectiveness of the ISMS. In the 2022 revision this clause is short and points forward to the improvement activities described in the rest of Clause 10 and elsewhere.

Clause 10.2 (Nonconformity and Corrective Action) is the operational heart. When a nonconformity occurs, the organization must:

• React to the nonconformity and take action to control and correct it.
• Deal with the consequences.
• Evaluate the need for action to eliminate the causes of the nonconformity so it does not recur, by reviewing the nonconformity, determining its causes, and determining if similar nonconformities exist or could occur.
• Implement any action needed.
• Review the effectiveness of any corrective action taken.
• Make changes to the ISMS if necessary.

The organization must also retain documented information as evidence of the nature of the nonconformities, actions taken, and results.

This is a complete loop: detect, contain, analyze, fix, verify, evidence. Miss a step and the finding is effectively incomplete.

Where nonconformities come from

Nonconformities surface from many sources. A well-designed ISMS captures them from all of them:

• Internal audit findings. The most structured source. Internal auditors identify gaps against ISO 27001, your own policies, or contractual requirements.
• External audit findings. From certification bodies during Stage 1, Stage 2, or surveillance audits.
• Security incidents. An incident that reveals a control was not operating as documented is a nonconformity even after the incident is contained.
• Customer or regulator feedback. A customer reporting a policy violation or a regulator flagging noncompliance.
• Self-reported issues. Engineers, ops staff, or managers noticing that a process is not being followed and raising it.
• Management review discussions. Leadership identifying systemic issues during review.
• Risk assessment updates. Reassessing risk and finding existing controls are insufficient.

The more paths you have for nonconformities to surface, the healthier your ISMS. Organizations where all nonconformities come from external audits are not catching problems themselves.

The CAPA workflow step by step

1. Identification and recording

When a nonconformity is identified, record it immediately. Every nonconformity record should include:

• Unique identifier.
• Date identified and by whom.
• Source (internal audit, incident, etc.).
• Description referencing the specific requirement that was not met.
• Evidence of the nonconformity.
• Initial severity classification.

Entering nonconformities into a structured system, not an email thread, is essential for later auditor review.

2. Immediate correction and containment

Before root cause analysis, contain the problem. If an access review was missed, complete it. If a control stopped operating, restart it. If an incident is in progress, follow incident response to contain it. Correction addresses the immediate issue and limits the blast radius.

3. Root cause analysis

This is where weak programmes fail. Root cause analysis asks why the nonconformity happened, not just what happened. Techniques include 5 Whys, fishbone diagrams, and fault tree analysis. The depth should match the severity: a minor isolated issue may only need a brief analysis, while a systemic issue deserves deeper investigation.

Root cause analysis should end with a statement of underlying cause that could plausibly lead to a corrective action. "The access review was not completed because the owner was on vacation" is a symptom. "The access review process has no backup owner and no automated reminder, so it fails whenever the primary owner is unavailable" is a root cause.

4. Corrective action planning

Based on the root cause, plan corrective actions. A corrective action should be:

• Specific. Not "improve the process" but "assign a backup owner and enable automated reminders in the GRC platform."
• Owned. A named person is responsible.
• Time-bound. With a target completion date appropriate to severity.
• Evidence-producing. The action should generate artifacts that prove completion.

5. Implementation

Execute the corrective action. Retain evidence of implementation, such as updated policies, new automation, training records, or configuration changes.

6. Verification of effectiveness

ISO 27001 specifically requires review of effectiveness, not just evidence of implementation. This is the step most often missed. Verification asks whether the corrective action actually prevented recurrence. Depending on the nature of the action, verification might include:

• Re-auditing the affected area after a defined interval.
• Reviewing metrics for the affected control over time.
• Sampling additional records to confirm the fix is operating.

Only after verification is the nonconformity closed.

7. Systemic evaluation

Clause 10.2 also requires evaluating whether similar nonconformities exist elsewhere or could occur. A single missed access review in one system might point to a gap in every access review process across the organization. This step is what separates corrective action from reactive firefighting.

Distinguishing major and minor nonconformities

Classifications affect how urgently a nonconformity must be handled and, in the case of external audits, whether certification is at risk.

A major nonconformity is typically:

• Absence of a required element of the ISMS.
• Systemic failure of a process.
• Multiple minor nonconformities in the same area indicating a broader issue.
• A control that is fundamentally not operating.

A major nonconformity from a certification body must be resolved before a certificate is issued or will suspend an existing certificate if not addressed.

A minor nonconformity is typically:

• An isolated failure within an otherwise functioning process.
• A documentation gap that does not affect control operation.
• A process deviation that is not yet systemic.

Minor nonconformities usually have a fixed remediation window, often 90 days, before the certification body follows up.

How this fits into your ISMS

Nonconformity handling is where Clauses 9 and 10 meet. Internal audits and management reviews under Clause 9 surface nonconformities. Clause 10 processes them. Outputs from corrective action feed back into continual improvement as systemic learnings and often trigger updates to risk treatment or the Statement of Applicability.

During the certification process, auditors will review your nonconformity log both from internal audits and from operational sources. Closed nonconformities with weak root cause analysis or no effectiveness verification are a leading cause of findings during Stage 2.

Common pitfalls

• Correction without corrective action. Fixing the immediate issue without addressing the root cause guarantees recurrence.
• Root causes that are not really root causes. Stopping at "the person forgot" rather than investigating why the process allowed forgetting is a shallow analysis.
• No effectiveness verification. Closing a nonconformity the day the fix ships misses the point. Effectiveness must be reviewed after the action has had time to operate.
• Closing nonconformities too quickly to clear the backlog. Auditors notice, and reopening a closed nonconformity looks worse than leaving it open with a plan.
• Not looking for systemic occurrences. Clause 10.2 specifically requires checking whether similar issues exist elsewhere.
• Treating every issue as a minor. Downgrading severity to reduce pressure produces audit findings when the pattern becomes visible.
• Weak documentation trail. If the nonconformity, root cause, action, and verification cannot be reconstructed from your records, the corrective action is effectively incomplete.

How episki helps

episki provides a structured nonconformity workflow that captures findings from internal audits, incidents, and ad-hoc reports into a single register, enforces the full CAPA lifecycle including mandatory root cause analysis and effectiveness verification, links each nonconformity back to the controls and risks it affects, and produces the documented evidence ISO 27001 auditors expect. Patterns across nonconformities surface automatically so systemic issues are caught before they become external audit findings.

For the broader context of how nonconformity handling fits the ISMS cycle, return to the ISO 27001 framework overview.