ISO 27001 corrective action under Clause 10.2 requires you to correct the immediate instance, determine and eliminate the root cause, implement proportional corrective actions, verify their effectiveness, and keep records that prove closure. A compliant entry names an owner, sets a target date, documents the root-cause method used, attaches evidence of what was actually done, and shows a follow-up check confirming the problem did not return.
TL;DR:
- Most nonconformities require root cause analysis with documented evidence, not just quick fixes, to demonstrate true organizational learning.
- Corrective actions must be assigned to a specific owner, with a clear target date, and verified through at least one full operating cycle.
- Evidence must include actual logs, configuration exports, or signed documentation, not just descriptions of what was done.
- Major nonconformities require faster response, often within 30 days, and may trigger follow-up audits instead of remote reviews.
- Use the Five Whys for simple failures and fishbone diagrams for complex, multi-factor incidents to produce testable, specific cause statements.
Table of Contents
- What Does ISO 27001 Clause 10.2 Actually Require?
- Which Root Cause Analysis Method Should You Use?
- What Documentation Do Auditors Actually Want?
- What Fields Belong in a Corrective Action Plan Template?
- How Long Do You Have to Submit and Close Corrective Actions?
- Why Do Corrective Actions Get Rejected?
- Why Clause 10.2 Is Bigger Than Passing Your Next Audit
- Plan Corrective-Action Workload With ISMS Calculator
- Where to Verify the Requirements Yourself
- Sources
- FAQ
What Does ISO 27001 Clause 10.2 Actually Require?
Clause 10.2 is short, but auditors treat it as one of the most scrutinized parts of the standard because it’s where you prove the ISMS actually learns from its mistakes. The clause requires organizations to react to nonconformities, evaluate their causes, implement corrective actions, review effectiveness, and retain documented evidence of both the nonconformity and what was done about it.
Here’s the workflow that turns those five requirements into something you can actually execute and defend during an audit.
- Contain the problem. Fix what’s broken right now, separately from fixing why it broke.
- Investigate the root cause. Find out what actually let the failure happen, not just what happened.
- Plan and assign the corrective action. Write down who owns it, what they’re doing, and by when.
- Implement. Do the work and capture proof as you go, not after the fact.
- Verify effectiveness. Check that the fix held, ideally after a full operating cycle has passed.
- Close the record. Document the outcome and archive the evidence trail.
Containment is the correction: patching the vulnerability, revoking the compromised credential, restoring the missing log source. Record it as its own line item, timestamped, separate from the corrective action. Auditors regularly see teams conflate the two, and a nonconformity that only shows containment steps reads as unresolved, no matter how fast the response was.
Root-cause investigation comes next, and this is where most teams either earn or lose their audit credibility. A compliant corrective-action workflow separates the correction from the corrective action precisely because the standard wants evidence that you understood why the failure happened before you decided how to prevent it. Skip this step or rush it, and your corrective action becomes a guess dressed up as a plan.
Planning and assigning the corrective action means writing something specific enough that a stranger could execute it. “Improve access review process” is not a plan. “Add quarterly access recertification to the HR offboarding checklist, owned by the IT security lead, effective March 1” is a plan. Every entry needs a named owner, a target date, and a description precise enough to verify later.
Implementation should generate its own paper trail as it happens: change tickets, configuration exports, signed-off procedure updates, training attendance logs. Don’t wait until the corrective action is “done” to start gathering proof. Screenshot the before-and-after. Export the ticket history. Save the meeting notes where the new procedure got approved.
Verification is the step teams skip most often, and it’s the one that gets audit responses rejected. A one-time check that the fix “seems to be working” isn’t verification. You need at least one full cycle of the affected process running under the new controls, with someone other than the person who implemented the fix confirming the outcome. If the corrective action changed an operational process, run it through your organization’s change management process and capture the first full cycle’s monitoring output as your effectiveness evidence.
Before you close anything, ask the question Clause 10.2 explicitly builds in: could this same root cause exist somewhere else in the organization? A recurring finding is itself evidence that a prior corrective action failed, so checking similar systems, teams, or processes for the same weakness isn’t optional diligence. It’s part of the requirement.
Pro Tip: Build a simple “could this exist elsewhere?” checklist into your corrective action template, even just three lines asking which other systems, teams, or vendors share the affected process. Auditors notice when that question is answered proactively instead of raised for the first time during the follow-up review.
How much rigor a given nonconformity needs is a judgment call, and that’s fine within limits. A single misconfigured firewall rule caught in a routine review probably doesn’t need a cross-functional investigation. A missed patch that led to unauthorized access, or a control failure that repeats across multiple audit cycles, needs to be escalated, documented in more depth, and possibly tied into your broader risk register rather than treated as an isolated fix.
Which Root Cause Analysis Method Should You Use?
Two tools cover the vast majority of ISO 27001 corrective action cases: the Five Whys and the fishbone (cause-and-effect) diagram. Picking between them comes down to how tangled the failure is.
Five Whys works well for a single, linear failure chain: a control didn’t fire, a person didn’t follow a step, a setting was wrong. You ask “why” repeatedly, usually five times, until you hit something structural rather than incidental. If the answer to “why did the laptop leave the building unencrypted” eventually resolves to “the onboarding checklist never included an encryption verification step,” you’ve found something fixable. If it stops at “the employee forgot,” you haven’t gone deep enough yet, because “human error” alone almost never satisfies an auditor.
Fishbone diagrams earn their place when the failure has multiple contributing factors that interact: people, process, technology, and environment all playing a part. A data exposure incident that involved a misconfigured cloud bucket, a missing peer review step, and unclear ownership of the deployment pipeline is a fishbone problem, not a Five Whys problem. Mapping it linearly would flatten causes that actually reinforced each other.
Whichever method you use, document the reasoning trail, not just the conclusion:
- The specific questions asked and answers given at each step of the Five Whys, or each branch of the fishbone.
- Supporting evidence referenced during the analysis: logs, interview notes, ticket timestamps, configuration history.
- The names and roles of who participated in the analysis session.
- The date the RCA was conducted, ideally close to when the nonconformity was raised.
The output of a good RCA is a cause statement specific enough to generate a testable action. “The onboarding checklist lacked an encryption verification step, added March 2023 when device provisioning moved to a third-party vendor” gives you something to fix. “IT process wasn’t followed” gives you nothing an auditor can verify was actually addressed.
Once you have that precise cause, write the corrective action with acceptance criteria attached: what specifically will exist once this is done, and how will you know it worked. A vague commitment to “review the process” is not.
Finally, run the same “elsewhere” check from the RCA stage itself, not just at closure. If the onboarding checklist gap existed for laptops, check whether the same vendor transition affected mobile device provisioning or contractor equipment issuance too.
What Documentation Do Auditors Actually Want?
Auditors want evidence you can point to, not narrative you have to be trusted on. That distinction drives almost every rejected corrective action submission.
Clause 10.2 requires organizations to retain documented evidence of the nature of the nonconformity and any subsequent action taken, which in practice means your record needs these fields populated, not just described in a summary paragraph:
- Nonconformity description: what happened, when, and how it was discovered.
- Containment action: the immediate fix, timestamped.
- Root cause statement: the specific, evidenced conclusion from your RCA.
- Corrective action: the precise change made, with owner and completion date.
- Effectiveness verification: what was checked, when, by whom, and what the result was.
- Related references: linked change tickets, incident numbers, or risk register entries.
Practitioners report that the most common rejection reasons for corrective action submissions are shallow root-cause analysis, missing evidence attachments, and no effectiveness verification — and the fix for two of those three is simply attaching proof instead of describing it.
That’s the practical rule worth internalizing: a good submission attaches the evidence itself rather than asserting that something happened. A screenshot of the updated configuration beats a sentence saying the configuration was updated. An exported log showing zero failed access attempts over 30 days beats a claim that “monitoring confirmed the fix worked.” Signed-off training attendance sheets beat a note that “staff were retrained.”
For timing, reference related tickets directly in the corrective action record rather than paraphrasing them. If the fix required a change request, link the change ticket number. If it originated from an incident, link the incident report. Auditors reviewing a corrective action package move faster, and trust it more, when they can trace the whole chain without asking follow-up questions.
What Fields Belong in a Corrective Action Plan Template?
A corrective action plan, or CAP, is the document that ties the entire Clause 10.2 workflow together into something suitable. Government remediation guidance on structuring these plans recommends including specific required actions, verification methods, deadlines or milestones, a communication plan, and stated consequences if actions aren’t taken. That structure translates directly into ISO 27001 corrective action templates:
- Finding reference: the audit finding number or internal nonconformity ID.
- Description: a factual account of what was found, without editorializing.
- Root cause: the specific, evidenced conclusion, not a category label.
- Corrective action: exact steps being taken, written so a third party could verify completion.
- Owner: one named individual, not a team or department.
- Target date: a real date, not “next quarter.”
- Verification method: how effectiveness will be confirmed, and by whom.
- Evidence attached: links or references to the actual proof documents.
- Status and closure date: updated as the item moves through the workflow.
This structure adapts easily whether you’re running it in a dedicated GRC platform, a Jira ticket type, or a shared spreadsheet. The fields don’t change. What changes is how you enforce completeness: a spreadsheet needs someone manually checking that no row skips the evidence column, while a ticketing system can make certain fields mandatory before a ticket transitions to “closed.”
The table below shows what auditors are actually checking for in each field, which matters more than just filling in the blank.
| CAP Field | Acceptance Criteria |
|---|---|
| Root cause | Specific and evidenced, not a generic category like “human error” |
| Corrective action | Concrete enough that a third party could verify completion |
| Owner | One named person, not a team or department |
| Target date | A specific calendar date |
| Verification method | Defined before implementation, not improvised at closure |
| Evidence attached | Actual documents or exports, not a description of them |
Pro Tip: Keep a “rejected first time” log of your own, informal but internal. When an auditor pushes back on a submission, note exactly what they flagged. After two or three audit cycles, that log becomes the best training material your team will ever have for writing acceptable CAPs on the first try.
How Long Do You Have to Submit and Close Corrective Actions?
Timelines depend on whether the nonconformity is minor or major, and whether you’re in initial certification or a surveillance cycle. Certification bodies vary slightly on exact windows, so confirm specifics with yours, but the general pattern holds across most accredited auditors:
- Minor nonconformities typically require a corrective action plan submitted within 30 to 90 days, with the certification body reviewing the plan itself before requiring proof of implementation.
- Major nonconformities usually demand a faster response, often within 30 days, and frequently require a follow-up audit rather than a desk review to confirm the fix actually took hold.
- Initial certification audits tend to have less flexibility than surveillance audits, since an outstanding major finding can block certification entirely until resolved.
- Surveillance audits may allow a nonconformity to carry forward with a documented plan, provided the timeline for resolution is realistic and tracked.
A desk review checks whether the submitted evidence and reasoning are internally consistent and complete. A follow-up audit gets triggered when the finding involved a systemic control failure, when evidence quality was too thin to verify remotely, or when a prior corrective action for the same issue already failed once.
Organize your submission package so a reviewer can move through it without hunting: lead with the finding reference and root cause statement, follow with the corrective action and evidence attachments in the order they occurred, and close with the verification result. Reviewers who can trace the story in five minutes are far more likely to accept it on the first pass.
Why Do Corrective Actions Get Rejected?
Three mistakes account for most rejected submissions, and all three are fixable before you ever hit submit.
- “Human error” as a root cause. It describes a symptom, not a cause. Push further: why did the process allow that error to have consequences, and what control should have caught it?
- Descriptive evidence instead of attached proof. A sentence claiming something was fixed carries no weight next to an actual log export, screenshot, or signed document.
- No planned effectiveness check. Closing a corrective action the same day it’s implemented, with no follow-up window, tells an auditor you never actually confirmed the fix worked.
Pro Tip: Write your effectiveness verification method into the CAP before you implement the fix, not after. Deciding upfront what “success” looks like keeps the eventual check honest instead of retrofitted to whatever outcome you got.
Why Clause 10.2 Is Bigger Than Passing Your Next Audit
Treating Clause 10.2 as a compliance checkbox misses the point. The organizations that get real value from corrective actions are the ones that use transparent ownership and short deadlines to force honest conversations about root causes, not just quick fixes. Done well, a corrective action register becomes your clearest signal of where the ISMS is actually improving, not just where it’s surviving audits.
— Martin
Plan Corrective-Action Workload With ISMS Calculator
Before you know how many corrective actions you can realistically close by a certification deadline, you need a sense of the effort involved, and that’s exactly the gap some toolkits aim to close. Its maturity assessment across the four Annex A control themes helps you spot where nonconformities are likely to cluster before an auditor finds them for you, while the platform’s benchmarks let you compare your remediation pace against the model reference rather than guessing in the dark.
If you’re staring down a stack of audit findings and trying to figure out how many hours, and how many weeks, closing them will actually take, start with the free 2-minute readiness check. It flags likely gaps fast enough to fold into your next planning meeting. From there, the customizable Gantt export gives you a timeline you can attach directly to a CAP submission as supporting evidence of your remediation schedule, and the ISO 27001 Cost Calculator turns that same readiness picture into a company-specific cost and effort estimate. Use estimates to help set target dates your team can aim to meet.
Where to Verify the Requirements Yourself
Don’t take secondhand summaries of Clause 10.2 as the final word, especially when you’re preparing language for an actual audit response. Check these directly:
- ISO/IEC 27001:2022 Clause 10.2 for the normative text on reaction, evaluation, implementation, and effectiveness review.
- ISO’s amendment and update page to confirm you’re working from the current edition before drafting a submission.
- Practitioner breakdowns like AuditBadger’s Clause 10 guide and ISMS Calculator’s guide to nonconformity examples for real-world phrasing you can adapt.
Sources
- ISO/IEC 27001:2022 (excerpt)
- ISO 27001 Clause 10: Improvement, Nonconformities, and Corrective Action — AuditBadger
- Developing a corrective action plan — U.S. Department of Labor (ILAB)
- ISO 27001 nonconformity: major vs minor guide — GovernanceDocs
FAQ
What Are the Five Steps of a Corrective Action?
The five steps are containment, root-cause analysis, planning and assigning the corrective action, implementation, and verification of effectiveness before closure. Practitioners often describe this as a contain, root cause, correct, verify, close cycle, and each stage needs its own documented evidence rather than a single closing summary.
What Is ISO 27001 in Simple Terms?
ISO 27001 is an international standard that sets requirements for building and running an information security management system, covering everything from risk assessment to how you handle audit findings. Clause 10.2, specifically, is the part that governs how you fix problems the standard’s own audits uncover and prove those fixes actually worked.
What Are Examples of Corrective Action?
Examples include adding a mandatory encryption check to a device onboarding checklist after an unencrypted laptop went missing, introducing quarterly access recertification after an audit found stale user permissions, or updating a vendor contract template after a supplier handled data outside agreed terms. Each example needs a named owner, a documented root cause, and a follow-up check confirming the change held over at least one full operating cycle.
When Is a Nonconformity Considered Closed?
A nonconformity is closed once the correction is complete, the root cause has been eliminated through a corrective action, and verification evidence confirms the action actually prevented recurrence, not just that the immediate symptom disappeared. Auditors specifically check whether similar nonconformities exist elsewhere in the organization before treating closure as final.
How Long Does a Corrective Action Take to Close?
Minor nonconformities are typically expected to close within 30 to 90 days depending on your certification body’s policy, while major nonconformities usually require action within about 30 days and often a follow-up audit rather than a desk review. Timelines vary by certification body, so confirm the exact window with yours before committing to a date in your corrective action plan.