10.2 — Nonconformity and corrective action

Every finding from every other clause eventually lands here. This is where you prove that a problem, once found, actually gets fixed—not just documented.

Mandatory requirement · Documented information required: yes

In plain language

10.2 requires that whenever something nonconforming happens—a control fails, an audit finds a gap, an incident exposes a weakness—you react to contain it, figure out the actual root cause rather than just the symptom, fix that root cause, check that the fix worked, and change the ISMS itself if the problem reveals it needs to.

Why this requirement exists

Without this discipline, organizations tend to fix the immediate symptom and move on—patch the one server that got flagged, without asking why the patching process let it fall behind in the first place. This requirement forces the harder, more valuable question: not just "what broke," but "why did our system allow it to break, and will it happen again somewhere else?"

Scenario: an internal audit finds that one employee’s access was never revoked after they changed roles. The immediate fix—removing the stale access—takes five minutes. The root cause investigation finds that the offboarding checklist has no step for role changes, only full departures, meaning the same gap likely exists for other employees who changed roles. Fixing only the one account, without updating the checklist, means the same finding reappears at the next audit.

What the standard expects

When a nonconformity occurs, the standard expects the organization to react to it and, as applicable, take action to control and correct it, and deal with the consequences; evaluate the need for action to eliminate the causes of the nonconformity so it does not recur or occur elsewhere, by reviewing the nonconformity, determining its causes, and determining whether similar nonconformities exist or could occur; implement any action needed; review the effectiveness of any corrective action taken; and make changes to the ISMS if necessary. Corrective actions must be appropriate to the effects of the nonconformities encountered, and the organization must retain documented information as evidence of the nature of nonconformities, any actions taken, and the results of corrective actions.

In practice

• Keep a single nonconformity and corrective action register capturing every finding—from internal audits, monitoring, incidents, or management review—in one place.
• Push past the immediate fix to an actual root-cause question: ask "why" at least a few times before accepting an explanation.
• Explicitly check whether the same root cause could affect other systems, teams, or processes, not just the one where the problem surfaced.
• Close the loop by verifying the fix actually worked—re-test, re-audit, or re-measure rather than assuming.

Evidence the auditor will ask for

• A nonconformity and corrective action register showing the nature of each finding, root cause analysis, and action taken.
• Evidence the corrective action was verified as effective, not just marked closed.
• For recurring or systemic findings, evidence the ISMS itself was updated in response.

Common pitfalls

• Fixing the symptom (one broken control) without investigating whether the same gap exists elsewhere.
• Marking a corrective action closed without ever verifying it actually worked.
• The same finding recurring audit after audit because the root cause was never actually addressed.

Related requirements

• 10.1 Continual improvement—the proactive counterpart to this reactive discipline.
• 9.2 Internal audit—the most common source of nonconformities that feed into this clause.
• 9.3.2 Management review inputs—trends in nonconformities and corrective actions are a required review input.
• Parent clause: Clause 10 Improvement.

2013 → 2022 mapping