The Short Answer
Corrective action deals with a problem that has already happened. You fix the immediate issue, find out why it happened, and change something so it does not happen again.
Preventive action deals with a problem that has not happened yet. You spot a plausible failure, weakness, or trend and act before it turns into a real nonconformity or incident.
ISO 27001:2022 keeps an explicit clause for corrective action (clause 10.2). It does not have a separate clause called "preventive action" - that concept was absorbed into risk-based thinking in clauses 6.1 (actions to address risks and opportunities) and 10.1 (continual improvement). Preventive action is still expected. It just lives somewhere else in the standard.
Definitions Side by Side
| Aspect | Corrective action | Preventive action |
|---|---|---|
| Trigger | A nonconformity, incident, or audit finding that already occurred | A risk, weakness, trend, or near miss that could cause a problem |
| Purpose | Eliminate the cause so it does not recur | Eliminate the cause so it does not occur in the first place |
| ISO 27001:2022 clause | 10.2 (explicit requirement) | 6.1 risk treatment and 10.1 continual improvement |
| Typical evidence | Nonconformity record, root cause analysis, action plan, effectiveness check | Risk register entry, treatment plan, monitoring metric, improvement log |
| Timing | Reactive (after the event) | Proactive (before the event) |
What Clause 10.2 Actually Requires
When a nonconformity occurs, ISO 27001:2022 clause 10.2 requires you to:
- React to it - control it and correct it, and deal with the consequences.
- Evaluate the need to eliminate the cause - by reviewing the nonconformity, determining its causes, and checking whether similar nonconformities exist or could occur elsewhere.
- Implement any action needed.
- Review the effectiveness of the corrective action taken.
- Make changes to the ISMS if necessary.
You must also retain documented information on the nature of the nonconformity, the actions taken, and the results. In practice, that means a corrective action record per finding - not a single spreadsheet cell saying "fixed".
Correction Is Not Corrective Action
This is the distinction auditors test most often.
- Correction: a laptop was left unencrypted, so you encrypt it today.
- Corrective action: you find out that the build image had encryption disabled by default, fix the image, and add an automated check so no future laptop ships unencrypted.
If your records only ever show the first line, an auditor will raise a finding for an ineffective corrective action process - even though the immediate issue was resolved.
Practical Examples in an ISMS
| Situation | Correction | Corrective action | Preventive action |
|---|---|---|---|
| Leaver still had VPN access two weeks after exit | Revoke the account now | Fix the offboarding trigger between HR and IT, add a weekly orphan-account report | Extend the same joiner-mover-leaver check to contractors and third-party accounts before it fails there too |
| Internal audit found the risk register was not reviewed for 14 months | Review it now | Add a scheduled review owner, due date, and management review agenda item | Apply the same review cadence and ownership model to the SoA, policies, and supplier assessments |
| A phishing email led to credential theft | Reset credentials, contain the account | Root cause analysis, enforce phishing-resistant MFA on the affected system | Roll MFA out to the remaining systems that share the same weakness |
| Backup restore test failed | Restore from an older backup | Fix the backup job configuration and re-test | Add restore testing to every system in the same backup class |
How to Run a Corrective Action Properly
- Record the nonconformity. Describe what was observed, where, when, and which requirement or control it breaches.
- Apply the immediate correction. Contain the damage. Note it separately from the corrective action.
- Find the root cause. Use 5 Whys or a simple cause-and-effect analysis. Stop when you reach something you can change - a process, a control setting, a responsibility gap. "Human error" is almost never a root cause.
- Check for the same cause elsewhere. Clause 10.2 explicitly asks this. If one team's access reviews slipped, check every team.
- Define the action, owner, and due date. One owner. A real date.
- Verify effectiveness later. Come back after a defined period and prove the problem did not recur. Attach evidence: a log, a report, a screenshot, a re-test.
- Update the ISMS. Amend the policy, procedure, risk register, or SoA if the fix changed how you work.
How Preventive Action Shows Up in ISO 27001:2022
Because there is no clause named "preventive action", auditors look for preventive behaviour in these places instead:
- Clause 6.1 - risks and opportunities identified and treated before they materialise.
- Clause 8.2 and 8.3 - risk assessment and treatment performed at planned intervals, not just after incidents.
- Clause 9.1 - monitoring and measurement that surfaces negative trends early.
- Clause 9.3 - management review inputs covering trends in nonconformities and risk changes.
- Clause 10.1 - continual improvement of the suitability, adequacy, and effectiveness of the ISMS.
A good signal of a mature ISMS: your improvement log contains items that were never nonconformities. They came from near misses, metrics, supplier changes, or lessons from other organisations.
Common Mistakes Auditors Flag
- Recording only the correction and calling it a corrective action.
- Root causes written as "staff did not follow the procedure" with no analysis of why.
- No effectiveness check, or an effectiveness check performed the same day as the fix.
- Corrective actions with no owner or a permanently rolling due date.
- Never checking whether the same cause exists elsewhere in scope.
- No preventive or improvement items at all - every entry in the log is reactive.
Documentation You Need
At minimum, keep:
- A nonconformity and corrective action register with: source, description, immediate correction, root cause, action, owner, due date, status, effectiveness verification, and date closed.
- A continual improvement log for preventive and opportunity-driven items.
- Links from both into your risk register, internal audit reports, and management review minutes.
Our ISO 27001 document pack includes a corrective action and nonconformity register aligned to clause 10.2, and the internal audit checklist tool generates findings you can feed straight into it.
Frequently Asked Questions
Did ISO 27001:2022 remove preventive action? It removed the standalone clause, not the expectation. Preventive action is now delivered through risk-based thinking in clause 6.1 and continual improvement in clause 10.1.
Is a corrective action needed for every incident? Not every incident, but every incident that reveals a nonconformity with your ISMS, a control failure, or a repeatable cause should trigger one.
How long should a corrective action stay open? There is no fixed limit. Set a due date proportionate to the risk and evidence progress. Long-open actions with no movement are a common audit finding.
Who approves closure? Typically the ISMS manager or process owner, based on documented evidence that the action worked - not just that it was performed.
Next Steps
Start by auditing your own register. For each of the last ten entries, ask: is this a correction or a corrective action? Is the root cause something we can actually change? Did anyone verify it worked? If more than a couple fail those tests, your clause 10.2 evidence needs work before your next audit.
Found this article helpful?
Share it with your colleagues.