What Clause 10.2 Requires
When a nonconformity occurs — any failure to meet a requirement, whether the standard's, your own policies and procedures, or an obligation you have committed to — Clause 10.2 requires a defined sequence. First, react: take action to control and correct the situation, and deal with whatever consequences it has already caused. Second, evaluate whether action is needed to eliminate the underlying cause, so the nonconformity neither recurs in the same place nor occurs somewhere else. That evaluation means reviewing the nonconformity, determining its root cause, and checking whether similar nonconformities already exist elsewhere in the ISMS or plausibly could.
Where cause-elimination is warranted, the organization must implement the actions, review whether they actually worked, and — if the nonconformity exposed a systemic gap — change the ISMS itself: the risk assessment, procedures, controls, or scope. The standard adds a proportionality rule: corrective actions must fit the effects of the nonconformities they answer, so a trivial slip does not demand a forensic investigation. Two sets of records are mandatory: documented evidence of each nonconformity's nature and the actions taken in response, and documented evidence of the results of every corrective action — including whether it proved effective.
Why This Clause Exists
To give the ISMS a self-repair loop: every failure is contained, traced to its cause, fixed at that cause, and verified — with records that prove the loop closes rather than just opens.
What This Really Means
Think of Clause 10.2 as bug tracking for your management system, with one discipline most bug trackers skip: it forces you to separate the hotfix from the root-cause fix. The standard's vocabulary makes the same cut. A correction fixes the instance — an access review finds an orphaned account, so you disable it today. A corrective action kills the cause — you discover that HR terminations processed outside the ticketing system never reach IT, so you integrate the HR system with identity management and that entire class of orphaned accounts disappears. Closing findings with corrections alone, while calling them corrective actions, is the single most common way organizations fail this clause.
The full loop has five moves. React: contain the situation, correct it, and handle consequences that have already landed — including notifying anyone who must be notified. Evaluate: decide whether the cause needs eliminating; the standard deliberately asks you to evaluate the need, because not every slip deserves a root-cause workup — proportionality is built in. Determining causes is where lightweight methods earn their keep: five-whys gets past the symptom in minutes, and a fishbone diagram helps when several factors interact. Then implement the actions, review their effectiveness once enough time has passed to know, and update the ISMS — risk register, procedures, SoA entries — wherever the nonconformity revealed that the system itself was wrong. The extent check matters throughout: if one business unit's process failed, the evaluation should ask whether the other four run the same process.
Nonconformities arrive from predictable directions: internal audits under Clause 9.2 (the highest-volume source in most ISMSs), certification and surveillance audits, security incidents that reveal a control absent or ineffective, monitoring results and compliance checks, and supplier failures. Certification-audit findings carry their own mechanics. A minor nonconformity is an isolated lapse — the requirement is implemented but slipped in one instance; the certification body typically accepts a root-cause analysis and corrective action plan, then verifies implementation at the next surveillance visit. A major is the absence or total breakdown of a required element, and it blocks the certificate: corrective action must be completed and evidenced before certification is granted or maintained. Response windows are set by your certification body — a plan within roughly 30 days and closure of majors within roughly 90 are common patterns — and missing them can mean repeating part of the audit.
What auditors treat as the heart of the clause is closure quality. They read the corrective action log for three things: root causes that go deeper than "human error", an honest extent check (where else could this happen?), and effectiveness evidence recorded after a meaningful interval rather than on the day the action was assigned. A log full of same-day closures with cause fields reading "carelessness" is the classic tell of an organization doing corrections and calling them corrective actions.
Why It Matters
Corrective action is where the ISMS proves it can repair itself. Organizations that fix instances but never causes meet the same failure repeatedly — the same misconfiguration class, the same offboarding gap, the same vendor slip — paying incident costs each time without ever buying prevention. The economics are lopsided: a cause-level fix is usually a process or automation change costing days, while the third recurrence of the same incident can cost a customer. A working 10.2 loop is also the best argument an organization has after something goes wrong, because it converts a failure into documented, verifiable change.
The certification stakes run in both directions. Your handling of the certification body's own findings is governed by this clause — and so is their patience. At Stage 1 a young ISMS is allowed a thin log, but auditors expect Clause 9.2 internal audit findings to already be flowing through the corrective action process; arriving at Stage 2 with zero recorded nonconformities reads not as excellence but as a detection failure.
What weak corrective action costs:
- •Certificate jeopardy – Major nonconformities not closed within the certification body's window block the initial certificate or can suspend an existing one; the CB sets the timeline, not you.
- •Findings that escalate – A minor that recurs at the next visit because its cause was never eliminated is routinely upgraded to a major, with the audit trail showing you knew.
- •Repeating incidents – Instance-level fixes guarantee the pattern returns — usually at a worse time, at larger scale, or in front of a customer.
- •Lost auditor confidence – An empty or cosmetic corrective action log signals that nobody is detecting problems, which widens sampling and sharpens scrutiny across the whole audit.
- •No post-incident defense – After a breach, customers and regulators ask what changed; without corrective action records there is no demonstrable diligence, only assurances.
Regional Compliance Context
India: for incident-driven nonconformities, CERT-In directions put a clock on the react step — covered incident types must be reported within six hours, so containment, consequence handling, and notification cannot wait for the root-cause meeting. The 180-day log retention requirement is an unexpected ally here: logs of forensic quality make root causes provable months after the event. Where personal data is involved, DPDP Act obligations make the corrective action record double as the demonstrable-diligence evidence regulators and enterprise customers ask for after a breach.
Regulated finance: supervisory frameworks — RBI master directions in India, and equivalent central-bank and PDPL-era expectations in the Gulf — generally require incidents and audit issues to be tracked to root cause and verified closure. A disciplined Clause 10.2 log maps almost one-to-one onto that supervisory expectation, so regulated entities should run a single corrective-action process rather than parallel ISO and regulatory issue registers.
Documented Information Required
Records of nonconformities and actions taken
MandatoryFor each nonconformity: what requirement was not met, where and how it was detected, the immediate correction, how consequences were handled, the root cause determined, and the corrective action decided — with owner and dates. Most organizations keep this as a corrective action log with one row or ticket per finding.
Records of corrective action results
MandatoryEvidence of what each corrective action achieved: implementation proof plus an explicit effectiveness verdict recorded after a defined interval — a recurrence check 60–90 days after the fix, for example — not at the moment the action was assigned.
Nonconformity and corrective action procedure
RecommendedNot explicitly required by the standard but expected in practice: definitions separating correction from corrective action, severity grading, the workflow from detection to verified closure, response timelines, and who has authority to close findings.
Root cause analysis worksheets or templates
RecommendedStandard five-whys or fishbone templates that make cause analysis consistent across owners and preserve the evidence of how each root cause was reached.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Implement Clause 10.2
Write a Short Nonconformity and Corrective Action Procedure
Two or three pages is enough: define nonconformity, correction, and corrective action in plain language; set severity grades with matching response expectations; map the workflow from detection through containment, root cause, action, effectiveness review, and closure; and name who may close findings — ideally not the person who owned the fix.
Create a Single Corrective Action Log
One register for all sources — a spreadsheet or a dedicated ticketing project. Minimum fields: ID, date raised, source, description of the nonconformity, immediate correction, root cause, corrective action, owner, target date, extent-check result, effectiveness review date and verdict, and status. One log, not five: scattered tracking is how findings get lost.
Define the Intake Sources and Triggers
Wire every detection channel into the log: internal audit findings transfer automatically, certification audit findings are entered the day the report arrives, incident post-mortems raise an entry whenever a control was absent or failed, and compliance checks and monitoring exceptions feed in monthly. If a channel can detect a failure, it needs a path into the corrective action process.
Train Owners on Proportionate Root-Cause Analysis
Five-whys and fishbone can each be taught in an hour — the techniques are simple; the discipline is refusing to stop at "human error". Pair the training with the proportionality rule: low-impact, first-occurrence slips may close with a documented correction and a one-line cause, while systemic, repeated, or high-impact nonconformities get the full workup including the where-else-could-this-happen extent check.
Run the React Step with Discipline
Containment and correction always come first: stop the bleeding, fix the instance, and deal with consequences already incurred — notifications, affected data subjects, customer commitments. Record what was done and when; the timeline matters later, both to auditors and, for incident-driven nonconformities, to regulators with fixed reporting clocks.
Verify Effectiveness Before Closing
Build a two-stage closure: implemented, then effective. After a defined interval — 30 to 90 days suits most actions — the closer checks whether the nonconformity has recurred, whether the new process or control is actually being used, and whether monitoring confirms the change. Only then does the finding close, with the verdict recorded as the mandatory results evidence. Update the risk register and ISMS documents wherever the fix changed them.
Rehearse the Certification-Audit Response
Use internal audit findings as the dress rehearsal: same form, same root-cause depth, same evidence standard the certification body will demand. Learn your CB's rules in advance — response window, required content (correction, root cause, extent evaluation, corrective action with owners and dates, closing evidence), and how closure is verified — so a Stage 2 minor triggers a routine process instead of a panic.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 10.2:
Documentation
- Corrective action log covering all sources, holding the mandatory record of each nonconformity's nature and the actions taken
- Records of corrective action results, including dated effectiveness verdicts issued after a closure interval
- Root cause analyses for a sample of findings, showing the method used (five-whys, fishbone) and an extent check
- Nonconformity and corrective action procedure with severity grading and closure authority
- Accepted responses and closure evidence for findings raised at previous certification and surveillance audits
Interviews
- ISMS manager on the workflow from detection to verified closure, and how proportionality decisions are made
- An action owner walking through one corrective action end to end — cause analysis, implementation, effectiveness check
- Internal auditor on how findings are graded and tracked, and what happens when corrective actions stall
Observations
- Live review of the corrective action log: aging of open items, quality of root-cause entries, and closure verdicts
- Tracing one nonconformity end to end through tickets, change records, and the ISMS documents it updated
- Cross-checking whether previously closed nonconformities have reappeared in later audits, incidents, or monitoring
Practitioner Insights
The most common Clause 10.2 failure I see is not missing records — it is corrections dressed up as corrective actions. The account was disabled, the patch applied, the document updated; root cause: "human error"; status: closed, same day. When five-whys stops at "the engineer forgot", you have found a scapegoat, not a cause — keep asking why the process let one person's memory be the control. Experienced auditors read your corrective action log for exactly this pattern, and a page of same-day closures invites a much deeper sample.
Treat internal audit findings as the dress rehearsal for certification findings — same form, same root-cause discipline, same effectiveness check. Teams that practice this respond to a Stage 2 minor in days, calmly; teams that do not are writing their first-ever corrective action plan the night before the certification body's deadline. And do not be afraid to raise nonconformities against yourselves: a log with real entries is evidence the system works, while an empty one is evidence nobody is looking — and auditors read it exactly that way.
Common Challenges & Solutions
Challenge
Every root cause comes back as "human error" or "carelessness", so every corrective action is retraining and reminders.
Solution
Ban the phrase as a terminal answer: the analysis must continue into why the process allowed one person's lapse to become a failure — missing automation, no checklist, unclear ownership, unrealistic workload. Adopt a no-blame framing so people surface process truths, and add cause categories (process gap, tooling gap, knowledge gap, resourcing) to force better classification. Retraining alone is a correction wearing a corrective action's clothes.
Challenge
Corrective actions are closed the day the fix ships, and no effectiveness review ever happens.
Solution
Split closure into two gates — implemented, then verified effective — and make the second a scheduled event 30 to 90 days out, owned by someone other than the implementer. The verification asks three questions: has it recurred, is the new process actually being used, does monitoring confirm the change? Record the verdict; that record is itself mandatory evidence under this clause.
Challenge
Audit findings get managed carefully, but incidents and monitoring exceptions never enter the corrective action process.
Solution
Give the log a single intake and wire every detection channel to it: the incident post-mortem template ends with "nonconformity raised: yes/no and why", compliance checks and monitoring reviews push exceptions monthly, and supplier failures from service reviews land the same way. Then check the source mix quarterly — a log fed only by audits means the other channels are leaking.
Challenge
The team over-reacts: every trivial slip gets a full root-cause workup, the process drowns in paperwork, and people stop reporting.
Solution
Use the proportionality rule the standard itself provides — actions must fit the effects. Grade findings at intake: low-impact, first-occurrence slips close with a documented correction and a one-line cause, while full analysis with extent checks is reserved for systemic, repeated, or high-impact nonconformities. A lightweight lane is what keeps the heavyweight lane credible and the reporting culture alive.
Challenge
A certification-audit nonconformity arrives, the response is written in panic, and the certification body rejects it as inadequate.
Solution
Learn your CB's requirements before Stage 2: the response window (often around 30 days for a plan, with majors commonly needing verified closure in about 90), and the expected content — containment and correction, root cause, extent evaluation, corrective action with owners and dates, and the evidence that will demonstrate closure. Draft against that structure, and rehearse quarterly on internal findings so the format is muscle memory when it counts.
