Corrective actions in the AIMS: how to set up clause 10.2 of ISO 42001

Every organisation with an AI management system runs into nonconformities: an internal audit finding that risk assessments are not being updated, a production model producing biased output, a complaint from an affected individual. Clause 10.2 of ISO/IEC 42001 prescribes what has to happen next. The process itself is familiar ground for anyone maintaining an ISO 27001 or 9001 system. The AI-specific interpretation is not, and that is exactly where an auditor looks. This article covers the steps of 10.2, root cause analysis for AI nonconformities and the evidence you need to be able to show.

A correction is not a corrective action

The standard draws a distinction that tends to blur in practice. The correction is the immediate response: contain the problem and deal with the consequences. The corrective action addresses the cause: why could this happen, and what changes so it does not come back?

An example. Monitoring signals that a credit scoring model performs measurably worse for a specific group of applicants after retraining. The correction: roll back to the previous model version and reassess the affected applications. The corrective action starts with the question why the fairness test did not stop this. Perhaps the group was missing from the test data, perhaps there was a test but no threshold that blocked the deployment. The answer determines the action: expand the test data, build a blocking gate into the deployment process, or both. Whoever only rolls back and moves on has postponed the problem until the next retraining.

The steps of clause 10.2

In plain terms, the standard asks the following for every nonconformity. React to the nonconformity and deal with the consequences. Evaluate whether action is needed to eliminate the cause, so the nonconformity does not recur. Implement that action. Then verify whether it has been effective. And adapt the AIMS itself where necessary, because sometimes the nonconformity is a symptom of a broken process. Documented information must be retained on each step: the nature of the nonconformity, the actions taken and the results.

That last step, adapting the management system, is the one most often skipped. If three nonconformities in a year share the same underlying cause, for instance model changes bypassing change management, then the change process itself is due for revision. Individual actions per nonconformity will not fix that.

Where nonconformities come from

Nonconformities arrive from more sources than the internal audit alone. Think of monitoring signals (drift, declining fairness metrics), AI incidents, complaints from users or affected individuals, findings from the management review and reports from employees. A working 10.2 process gives all of these one route: the nonconformity is logged, classified (minor or major, for example), assigned to an owner and given a deadline.

The AI incident deserves separate attention here. In our audit practice this is one of the most common findings under chapter 10: an incident involving harmful or biased AI output is handled as a technical issue. The model is adjusted, the ticket closed. The link to the AIMS is missing, so nobody asks which governance process made the incident possible. The lesson never reaches the management system. The remedy is procedurally simple: add a fixed step to the incident procedure that assesses, for every AI incident, whether an AIMS nonconformity sits behind it, and record that assessment.

Root cause analysis for AI nonconformities

The familiar techniques work for root cause analysis, such as the 5 Whys or a fishbone diagram. The difference lies in the cause categories you need to consider for AI. Besides process and people, these are: the data (quality, representativeness, provenance), the model (behaviour after retraining, drift) and the governance (missing gates, unclear responsibilities, outdated risk assessments).

A root cause analysis that stops at "human error" or "the model underperformed" is almost always too shallow. Keep asking. Why could one person deploy a model without review? Why did the data quality check not notice that a source field had changed? Underneath a technical nonconformity there is often a governance cause, and a technical fix does not remove it.

Verifying effectiveness

The step most often recorded as missing during audits: verification. Implementing an action is not the same as establishing that it works. Schedule a review moment for every corrective action and record how you measure its effect. In the credit scoring example: is the blocking fairness gate demonstrably part of the deployment process by now, and did the next retraining actually pass through it? A record with only the status "completed" tells an auditor nothing; a verification with date, outcome and reviewer does.

What evidence an auditor expects

During a certification audit or an internal audit of chapter 10, a limited set of documents comes up. A nonconformity and corrective action procedure that applies to the AIMS. A register or log of nonconformities, with classification, owner and status. Root cause analyses, at least for the more serious cases. Effectiveness verifications with date and outcome. And for AI incidents: the link between the incident report and the corresponding nonconformity in the register. The interview questions are correspondingly concrete: walk me through the handling of a recent nonconformity, show me the root cause analysis, demonstrate that the action works.

Organisations with an ISO 27001 system can extend the existing nonconformity register instead of building a second one. The condition is that AIMS nonconformities are identifiable and that the cause categories accommodate AI.

Keep it small and let it run

The risk with clause 10.2 is overengineering: a form with twenty fields that nobody fills in, after which nonconformities get resolved outside the register. A ten-field register that is actually used is worth more than an elaborate process on paper. Start small, log the minor nonconformities too and let the process run for a few months before the certification body arrives. An empty register at the first certification audit is not a sign of perfection; auditors read it as a sign the process is not being used.

The internal audit module of the Secure Audit platform contains, for clause 10.2, the criterion, the interview questions, an example of a good setup and the documents you want to have at hand. It lets you test in advance whether your improvement process will hold up in an audit. Get in touch for a no-obligation conversation.