Why Clause 10.2 Matters in an AI Management System
ISO 42001 is the first internationally recognised standard for AI management systems. It brings the familiar structure of other ISO standards into the world of artificial intelligence, and Clause 10.2 sits at the heart of how organisations respond when things go wrong. Whether you are an internal auditor, a quality or compliance manager, or someone working towards ISO 42001 certification, understanding this clause is not optional. It is where accountability for AI failures actually lives.
On this page
Nonconformity and corrective action under ISO 42001 Clause 10.2 follows the same logical sequence you will recognise from ISO 9001, ISO 14001, and ISO 45001. React to the problem, contain the damage, investigate the root cause, fix it properly, and check that the fix worked. What makes ISO 42001 different is the nature of the nonconformities themselves. AI systems introduce failure modes that do not exist in traditional quality or safety management, and auditors need to understand that context before they can assess whether a corrective action is genuinely effective.
This article walks through what Clause 10.2 requires, how it applies specifically to AI management systems, what auditors look for when they assess corrective action records, and the most common gaps organisations leave in their responses.
What Clause 10.2 of ISO 42001 Actually Requires
Clause 10.2 uses the same six step structure that appears across the High Level Structure. When a nonconformity occurs, the organisation must:
- React to the nonconformity and, where applicable, take action to control and correct it
- Deal with the consequences
- Determine the cause of the nonconformity
- Determine whether similar nonconformities exist or could potentially occur
- Implement any action needed
- Review the effectiveness of any corrective action taken
- Update risks and opportunities if necessary
- Make changes to the AI management system if required
The standard also requires that corrective actions are appropriate to the effects of the nonconformities encountered. That proportionality requirement is important. A minor documentation gap does not warrant the same depth of root cause investigation as a finding that an AI system produced biased outputs affecting real people.
Documented information is mandatory. The organisation must retain evidence of the nature of the nonconformities and subsequent actions taken, and of the results of any corrective action.
Exemplar Global Recognised Training ProviderRTP No. 310970
What Counts as a Nonconformity Under ISO 42001
A nonconformity under ISO 42001 is a failure to meet a requirement. That requirement can come from the standard itself, from the organisation's own AI policy, from its AI objectives, from the controls defined in its Statement of Applicability, or from legal and regulatory obligations related to AI.
In practice, nonconformities in an AI management system tend to fall into a few recognisable categories:
System and Process Failures
These are the most straightforward. The organisation has a documented procedure for conducting AI risk assessments, but an audit reveals that a new AI tool was deployed without one. That is a clear nonconformity against Clause 6.1.2 and the organisation's own procedures. The corrective action process under Clause 10.2 kicks in immediately.
AI System Performance Failures
An AI model begins producing outputs that fall outside acceptable accuracy thresholds. Monitoring data shows a drift in model performance that was not detected because the monitoring process was not functioning as planned. This is a nonconformity against the operational control requirements in Clause 8.1 and the monitoring requirements in Clause 9.1.
Impact Assessment Gaps
ISO 42001 introduces the concept of an AI system impact assessment. If an organisation fails to conduct these assessments at the required intervals, or if an assessment is found to be superficial and did not identify risks that later materialised, that is a nonconformity. Running AI impact assessments at planned intervals is a specific requirement, and auditors will check whether the intervals are defined and whether the assessments are being completed.
Documented Information Failures
The organisation's Statement of Applicability lists a control from Annex A as applicable, but there is no evidence the control has been implemented. The documented information required to demonstrate implementation is missing. This is a nonconformity that goes directly to the integrity of the AI management system.
Competence and Awareness Failures
Staff responsible for operating or overseeing AI systems cannot demonstrate that they understand the risks associated with those systems. Training records are absent or out of date. This is a nonconformity against Clause 7.2.
The Six Steps in Practice: An AI Context
Step One: React and Contain
The first response to a nonconformity is immediate containment. In an AI context, this might mean suspending an AI system that is producing harmful outputs, reverting to a previous model version, or switching to a manual process while the issue is investigated. The action needs to be proportionate and documented. An auditor will look for evidence that the organisation did not simply write up the nonconformity and move on without addressing the immediate consequence.
This is where many organisations fall short. They document the finding well but have no record of what they actually did in the hours and days immediately after the problem was identified. If an AI recruitment tool was found to be screening out candidates in a way that was potentially discriminatory, what happened to the candidates affected? What happened to the tool? The corrective action record needs to answer these questions.
Step Two: Investigate the Root Cause
Root cause analysis is where the quality of a corrective action is made or broken. In an AI management system, root causes are often more complex than in traditional quality or safety contexts. Common root causes in AI systems include:
- Training data that did not represent the real world population the model would encounter
- A change in the operating environment that the model was not designed for
- Inadequate validation before deployment
- A failure in the monitoring process that meant performance drift went undetected
- Insufficient human oversight at decision points where the AI output had significant consequences
- A gap between the intended use of the AI system and how it was actually being used in practice
Auditors assessing corrective action records will look for evidence that the root cause investigation went beyond the obvious. Stating that the model was not accurate enough is not a root cause. It is a symptom. The root cause is why the model was not accurate enough, and that requires a genuine investigation. Root cause analysis for corrective actions is a skill that takes practice, and it is one area where many organisations genuinely struggle.
Step Three: Determine Whether Similar Problems Exist
ISO 42001 Clause 10.2 requires the organisation to consider whether similar nonconformities exist elsewhere or could potentially occur. In an AI context, this means looking across the portfolio of AI systems in use. If one AI system failed because its monitoring process was inadequate, the organisation needs to ask whether the monitoring processes for its other AI systems are similarly inadequate.
This is a systemic check, not just a fix for the specific system that failed. Auditors will probe this. They will ask what other AI systems the organisation operates, and they will want to see evidence that the organisation considered whether the root cause of one nonconformity had implications for other systems.
Step Four: Implement Corrective Action
The corrective action must address the root cause, not just the symptom. If the root cause was that the AI risk assessment process did not include a step for evaluating training data quality, then the corrective action must update that process. If the root cause was that staff lacked the competence to identify bias in model outputs, then the corrective action must address competence, not just awareness.
Corrective actions in an AI management system often involve technical changes, process changes, and people changes simultaneously. An auditor will want to see that the action plan is specific, assigned to a responsible person, and has a realistic completion date.
Step Five: Review Effectiveness
This is the step that most organisations skip or perform inadequately. Implementing a corrective action and closing the record is not the same as verifying that the action worked. Effectiveness review means going back after a reasonable period and checking whether the root cause has actually been eliminated.
For an AI system, effectiveness review might involve reviewing monitoring data over a defined period after the corrective action was implemented, conducting a re assessment of the AI system's outputs, or re auditing the process that failed. The evidence of this review must be retained as documented information.
Auditors will look at the date the corrective action was closed and ask what evidence exists that the action was effective before it was closed. If the answer is that the action was assumed to be effective because the steps were completed, that is a problem. Completing the steps and achieving the intended outcome are not the same thing.
Step Six: Update Risks, Opportunities and the System
If a nonconformity reveals a gap in the organisation's risk assessment, the risk assessment needs to be updated. If the corrective action changes a process, the documented information for that process needs to be updated. If the finding has implications for the organisation's AI objectives or its Statement of Applicability, those documents need to be reviewed.
This step connects Clause 10.2 back to the planning clauses of the standard. It is how the management system learns and improves rather than simply responding to individual failures in isolation.
What Auditors Look For When Assessing Clause 10.2
When auditing corrective action records under ISO 42001 Clause 10.2, experienced auditors look for a small number of things that reveal whether the process is genuinely working or just generating paperwork.
Is the Nonconformity Clearly Described?
A well written nonconformity record states what was observed, what requirement was not met, and where the evidence of the failure was found. Vague descriptions like AI system not performing as expected do not give the corrective action process enough to work with. Writing nonconformities that hold up is a skill that directly affects the quality of the corrective action that follows.
Is the Root Cause Plausible and Specific?
The root cause stated in the corrective action record should be specific enough that someone reading it would know exactly what needed to change. Generic root causes like lack of training or process not followed are rarely sufficient. The auditor will probe whether the investigation actually went deep enough.
Does the Action Match the Root Cause?
If the root cause is that the AI impact assessment procedure did not include a step for assessing fairness implications, then the corrective action should be to update the procedure to include that step and to train the relevant staff on the updated procedure. If the corrective action is simply to conduct a one off fairness review of the specific AI system that failed, it does not address the root cause and the same failure will likely occur again.
Is There Evidence of Effectiveness Review?
This is the most commonly missing element. Auditors will look for a record that shows the corrective action was verified as effective, not just completed. The verification should be based on objective evidence, not on the opinion of the person who implemented the action.
Was the Corrective Action Timely?
Corrective actions that sit open for months without progress are a red flag. They suggest that either the organisation does not take the corrective action process seriously, or that the action is so poorly defined that no one knows when it will be complete. Auditors will check the dates and ask questions if the timeline looks unreasonable.
Common Nonconformities Against Clause 10.2 in ISO 42001 Audits
Based on what auditors consistently find when assessing corrective action processes, the following patterns appear most frequently in AI management system audits:
- Corrective action records that describe the immediate fix but contain no root cause analysis at all
- Root causes that describe the symptom rather than the underlying system or process failure
- Corrective actions that have been open for extended periods with no documented progress or escalation
- No evidence that the organisation considered whether similar nonconformities could exist in other AI systems
- Effectiveness reviews that consist of a statement that the action was completed, rather than evidence that the outcome was achieved
- Failure to update the AI risk assessment or Statement of Applicability following a significant nonconformity
- Corrective action records that are stored in a system that no one reviews, meaning findings are closed without meaningful oversight
Exemplar Global Recognised Training ProviderRTP No. 310970Connecting Clause 10.2 to Continual Improvement
Clause 10.2 does not operate in isolation. It feeds directly into the continual improvement requirements of Clause 10.1. When an organisation responds well to nonconformities, investigates root causes thoroughly, and verifies that corrective actions are effective, it generates genuine improvement in its AI management system. When the process is treated as a compliance exercise, the same problems recur and the management system stagnates.
The management review process under Clause 9.3 should draw on corrective action data as one of its inputs. If the management review is not receiving meaningful analysis of nonconformity trends and corrective action effectiveness, that is itself a finding. The connection between Clause 10.2 and the broader management system is something auditors will trace.
For organisations that are building their AI management systems for the first time, getting the corrective action process right from the beginning is far easier than trying to fix it after a certification audit finds it inadequate. The process does not need to be complex. It needs to be disciplined, documented, and genuinely followed.
Practical Advice for Quality and Compliance Managers
If you are responsible for maintaining an AI management system, here are the practical steps that will keep your Clause 10.2 process in good shape:
- Define what triggers a corrective action in your system. Not every observation or concern needs a full corrective action, but the threshold for raising one should be clear and consistently applied.
- Use a structured root cause analysis method. The 5 Whys is a good starting point for most AI management system nonconformities. Fishbone diagrams are useful when the root cause is genuinely complex and multi factorial.
- Assign every corrective action to a specific person with a specific due date. Shared ownership means no ownership.
- Build effectiveness review into the process as a mandatory step, not an optional one. Define what evidence will be used to verify effectiveness before the action is implemented, not after.
- Review corrective action trends at management review. Look for patterns. If the same root cause keeps appearing, the corrective action process is not working.
- Keep your corrective action records accessible and up to date. An auditor who cannot find the records will treat that as a finding in itself.
If you are preparing for an ISO 42001 internal audit or certification audit and want to build the skills to assess corrective action processes with confidence, Audit Workshop offers practical ISO 42001 auditor training at internal auditor and lead auditor levels. The training is grounded in real audit practice, not just clause by clause theory, and covers the specific challenges that AI management systems present to auditors who are more familiar with traditional quality or safety standards.
