Corrective Action vs Preventive Action in ISO 27001 (Clause 10.1)

Corrective vs Preventive Action: The Short Answer

• Corrective action fixes a nonconformity that has already happened and removes its root cause so it cannot recur. ISO 27001:2022 Clause 10.1 is the requirement.
• Preventive action addresses a potential nonconformity - something that has not happened yet but could. In ISO 27001:2022 the dedicated "preventive action" clause was absorbed into Clause 6.1 (Actions to address risks and opportunities): your risk treatment plan is your preventive action system.

If you only remember one thing: corrective action is reactive (an issue occurred, fix the cause), preventive action is proactive (a risk exists, treat it before it occurs).

What Clause 10.1 Actually Requires

ISO 27001:2022 Clause 10.1 ("Nonconformity and corrective action") requires that when a nonconformity occurs, the organization shall:

1. React to it - control it, correct it, and deal with the consequences.
2. Evaluate the need for action to eliminate the root causes so it does not recur, by reviewing the nonconformity, determining its causes, and checking whether similar nonconformities exist or could occur.
3. Implement any action needed.
4. Review the effectiveness of the corrective action taken.
5. Make changes to the ISMS if necessary.

And critically: retain documented information as evidence of the nature of the nonconformities, any subsequent actions taken, and the results of those actions.

That last point is what auditors test. No records = no corrective action in the auditor's eyes.

Where Preventive Action Lives in ISO 27001:2022

The 2013 version had Clause 8.5.3 "Preventive action". The 2022 revision removed that clause - not because preventive action stopped mattering, but because the entire risk-based approach in Clause 6.1 is preventive action:

• Clause 6.1.1 - actions to address risks and opportunities
• Clause 6.1.2 - information security risk assessment
• Clause 6.1.3 - information security risk treatment

When you identify a risk in your risk register and apply a treatment, you are performing preventive action under the 2022 standard. Auditors will look for the link between your risk register, your Statement of Applicability, and your operational controls.

Corrective vs Preventive Action: Side by Side

A Practical CAPA Workflow for ISO 27001

This is the workflow we use inside the Audit Room workspace and that holds up under UKAS-accredited certification audits.

Step 1 - Capture the Trigger

Every CAPA starts with a documented trigger. Acceptable sources:

• Internal audit finding
• External (certification or surveillance) audit finding
• Security incident (linked to your incident register)
• Management review action
• Risk review where the residual risk exceeds appetite
• Metric or KPI breach (for example, patching SLA missed two months in a row)
• Whistleblowing or staff feedback

Record: trigger source, date raised, who raised it, a clear statement of the nonconformity (what was required vs what was observed), and the clause or control reference.

Step 2 - Contain and Correct

Before you investigate root cause, deal with the immediate consequence. Examples:

• Revoke the access that should not have been granted
• Restore the backup that failed
• Patch the vulnerable system

Containment is not corrective action - it just stops the bleeding. Auditors expect to see this step recorded separately so it is clear you did not confuse "I fixed the symptom" with "I fixed the cause".

Step 3 - Root Cause Analysis

Use a structured method. The two most defensible in an audit:

• 5 Whys - ask "why" five times until you reach a systemic cause, not a person.
• Fishbone (Ishikawa) - categorize causes across People, Process, Technology, Environment, Measurement, Materials.

Stop when the cause is something you can actually change. "The engineer made a mistake" is rarely the root cause - "we have no peer review on production firewall changes" usually is.

Step 4 - Decide the Action

For each root cause, decide:

• Action description - specific and verifiable
• Owner - one named person, not a team
• Due date - realistic but firm
• Resource or budget impact - flag anything needing management approval
• Whether the ISMS itself needs to change - new policy, new control, change to risk treatment plan, change to SoA

Step 5 - Implement

Track to completion. Do not close the CAPA when the action is "done" - close it after Step 6.

Step 6 - Verify Effectiveness

This is the step most organizations skip and the one auditors specifically probe. After enough time has passed for the fix to be tested in real operation (often 30, 60, or 90 days), confirm that:

• The original nonconformity has not recurred
• The control change is operating as intended
• No new nonconformity has been introduced by the fix

Record the evidence (a re-test, a sample of records, a metric trend) and the date of the effectiveness review. Only then close the CAPA.

Step 7 - Feed Back into the ISMS

If the corrective action revealed a previously unidentified risk, add it to the risk register (Clause 6.1 - this is where preventive action gets renewed). If it revealed a weakness in a control, update your SoA and risk treatment plan.

Common CAPA Mistakes That Fail Audits

• Treating correction as corrective action. Closing a CAPA the day the patch is deployed, with no root cause analysis and no effectiveness check.
• One CAPA, many causes. Lumping unrelated findings into a single action so the log looks shorter. Auditors will ask you to split them.
• No owner or a team owner. "IT Team" is not an owner. Name a person.
• Permanent "in progress" status. A CAPA that has been open for 18 months with no movement is its own nonconformity at the next audit.
• No link to the risk register. If a corrective action shows the original risk assessment missed something, the risk register has to change. Auditors check this trace.
• No trend analysis. Clause 9.1 expects you to monitor and measure. If five CAPAs in a row are all about access reviews, that is a systemic finding, not five separate ones.

CAPA Documentation an Auditor Will Accept

At minimum, your nonconformity log should record:

• Unique CAPA reference
• Date raised and source
• Clause or control reference
• Description of the nonconformity (required state vs observed state)
• Immediate correction taken
• Root cause analysis method and result
• Corrective action(s), owner, and due date
• Implementation evidence
• Effectiveness review date, method, and outcome
• Date closed and closure approver

Word doc, Excel sheet, Jira project, or a purpose-built tool - the format does not matter as long as the fields are there and the evidence is retrievable.

Run Your CAPA Workflow Inside Audit Room

The Audit Room workspace on iso27001kit.com gives you an opinionated internal audit and nonconformity workflow that follows Clauses 9.2 and 10.1 - capture findings during the audit, raise corrective actions with owners and due dates, track them to closure with an effectiveness review, and export the full log for your certification body.

If your preventive actions live in your risk register, the Risk Copilot keeps them linked to controls and your SoA so the trace an auditor expects under Clauses 6.1 and 8 is automatic, not retrofitted the week before audit.

Open Audit Room - free preview - or start with the readiness check if you are not yet sure where your nonconformities are.