Governance DocsGovernance Docs
Browse Toolkits

CART

No products in the cart.

ISO Compliance Insights & Best Practices

ISO 42001 corrective action workflow from nonconformity to root cause and effectiveness review

ISO 42001 Corrective Action: The Essential 2026 Guide to Nonconformities

ISO 42001 corrective action is how your AI management system proves it learns from its own failures. Clause 10.2 requires you to respond to nonconformities, fix their causes and check that the fix worked.

Auditors read your corrective action log like a health record. A log that shows real problems, honest root causes and closed actions suggests a living system. An empty log suggests nobody is looking.

This guide explains the clause, a practical workflow, the fields your log needs and AI-specific examples. For the improvement clause as a whole, see our clause 10 improvement guide.

Free gap assessment

How much of ISO 42001 could you evidence today?

Score every clause and Annex A control of the AI management standard, free, and see where the programme really sits.

Run the free ISO 42001 gap assessment →  or  View premium report sample

What clause 10.2 requires

When a nonconformity occurs, the organization must react to it and, as applicable, take action to control and correct it and deal with the consequences. It must then evaluate whether action is needed to eliminate the cause so it does not recur or happen elsewhere.

That evaluation includes reviewing the nonconformity, determining its causes and determining whether similar nonconformities exist or could occur. Any action needed must be implemented, reviewed for effectiveness and, if necessary, lead to changes in the AI management system.

Finally, you must retain documented information as evidence of the nature of the nonconformities, the actions taken and the results of those actions.

The authoritative clause text is described at ISO/IEC 42001:2023.

Correction versus corrective action

A correction fixes the immediate problem: pull the faulty model from production, retrain on clean data or notify affected users. A corrective action removes the cause so the problem does not return.

Auditors care about both, but they care most about the second. A log full of corrections with no root cause analysis shows firefighting, not improvement.

Record both steps separately, so the story reads clearly: what happened, what you did immediately, why it happened and what you changed.

If you are unsure which category an event falls into, record the correction first and decide on corrective action after a short review.

Where nonconformities come from

Sources include internal audits, external audits, management review, monitoring results, incidents, customer complaints, supplier failures and staff reports. Each should feed the same log.

In AI work, common sources are model drift beyond tolerance, biased outputs, missing impact assessments, undocumented training data and overdue reviews. Our guides on model drift risk and AI incident management explain how these surface.

Define what counts as a nonconformity in your procedure: a failure to meet a requirement of the standard, your own policy or a legal obligation.

Capture the evidence at the time, not weeks later, so the log stays accurate and the audit trail holds.

A seven-step ISO 42001 corrective action workflow

One: log the issue with date, source and description. Two: contain and correct it. Three: assess the impact and who is affected. Four: find the root cause.

Five: decide the corrective action, owner and due date. Six: implement it and collect evidence. Seven: review effectiveness after a defined time and close the record.

Keep the workflow short enough that people use it. A form that takes an hour to fill in will be avoided, and avoided forms mean unreported problems.

StepQuestion to answerEvidence
Contain and correctWhat do we fix right now?Incident or change record
Root causeWhy did it happen?Analysis note
Corrective actionWhat will stop it recurring?Action plan with owner and date
VerifyDid it work?Effectiveness check result
LearnWhat does the trend show?Management review input

Root cause analysis that holds up

Use a simple method such as five whys or a cause and effect diagram, and keep the analysis proportionate to the problem. A minor late review does not need a workshop, but a biased production model does.

Look beyond the person. If an engineer skipped a step, ask why: missing training, unclear procedure, time pressure or a broken tool. Root causes in systems and processes lead to fixes that stick.

Write the cause in one clear sentence that someone else can understand a year later.

Sound root cause work is the heart of ISO 42001 corrective action.

The fields your log needs

A good log has an ID, date, source, description, immediate correction, root cause, corrective action, owner, due date, evidence of completion, effectiveness check date and result, and status.

Add the clause or control affected and a severity rating. These let you analyse trends, which management review expects. See our management review guide.

A spreadsheet works for most organizations. What matters is consistency and traceability, not the tool.

Our toolkit includes a corrective action log template, so the ISO 42001 Toolkit speeds this up.

ISO 42001 corrective action examples for AI systems

A drift monitor shows accuracy below the agreed threshold. Correction: roll back to a previous model. Cause: retraining schedule did not account for seasonal data changes. Action: add seasonal checks and automatic alerts.

A recruiter flags biased screening results. Correction: suspend automated ranking. Cause: training data underrepresented some groups. Action: rebalance data and add bias testing to release gates. See our guide to AI bias testing.

An audit finds that impact assessments were skipped for two systems. Correction: complete them now. Cause: no trigger in the change process. Action: add an impact assessment step to release approval.

Checking effectiveness

An action is not finished when it is implemented. Set a date to check that the problem has not recurred and that the new control works. For example, review the next three releases or the next quarter of monitoring data.

Record the check and its result. If the problem recurs, reopen the record and look for a deeper cause.

Effectiveness checks are where many organizations lose marks, because they close the action when the work is done instead of when the result is proven.

Pick a realistic review window. Too short and the problem has not had time to recur, too long and the action drifts out of attention.

Clause 10.1 requires continual improvement of the suitability, adequacy and effectiveness of the system. Corrective action data is one of your best inputs: count issues by source, area and cause.

Report trends to management review and decide whether to change processes, resources or objectives. A rising number of supplier issues, for example, may justify stronger supplier controls.

Show that decisions came from the data. This is the loop auditors want to see.

Share anonymized lessons with other teams, so one team’s fix prevents the next team’s incident.

Common findings on corrective action

Typical findings include open actions past their due date, no root cause, no effectiveness check and no link between audit findings and the log. Another is a log with only a handful of entries for a large system.

Do not hide problems. Auditors would rather see ten honest, well-handled issues than none. A healthy ISO 42001 corrective action process shows the system is detecting weakness.

Review overdue items weekly, and escalate when owners miss dates.

Honest ISO 42001 corrective action records are a strength, not a weakness.

A target such as closing most actions within the agreed deadline gives management a simple health indicator.

Handling audit findings

Treat internal and external audit findings the same way. Log each nonconformity, agree the correction and root cause and set dates. Your certifier will usually specify timeframes for major and minor findings.

Ask the auditor to confirm that your planned action addresses the finding before you implement it. It prevents rework.

Our internal audit guide explains how findings are classified and reported.

Ask the owner of each finding to present the fix at the next review so ownership stays visible.

Who owns corrective action

The AI governance lead usually owns the process and the log, while action owners sit in the teams that must change. Top management owns the culture: they decide whether staff feel safe reporting problems.

Set escalation rules. An action overdue by a set number of days goes to the governance lead, and a major overdue action goes to top management. Visible escalation keeps the system moving.

Make reporting easy and blame-free. People report what they believe will be handled fairly, and a healthy ISO 42001 corrective action process depends on that trust.

A quick-start for your first corrective action log

Create a simple table with the fields above. Seed it with any open audit findings, recent incidents and monitoring exceptions from the last six months.

Run a short review each month: new items, overdue items, items awaiting effectiveness checks. Take a summary to the next management review.

After a quarter, look for patterns. If three actions share a root cause, fix the process, not just each case.

ISO 42001 corrective action FAQ

What is the difference between correction and corrective action?

A correction fixes the immediate problem. A corrective action removes the root cause so it does not recur.

How long do we have to close an action?

Your procedure sets internal deadlines. For audit findings, the certification body sets timeframes, so check its rules.

Do all incidents need corrective action?

Not all. Evaluate whether action is needed to eliminate the cause. Minor, one-off events may only need a correction, but record your reasoning.

What does an auditor check?

They sample records for root cause, completed actions, evidence and effectiveness checks, and look for trends.

When a standard changes, know first

One email a month: edition changes, new deadlines, and what they mean for documentation you already have. No sales sequence.

We don’t spam! Read our privacy policy for more info.