6.2 Clause 10 Improvement
Key Takeaways
- Clause 10.1 requires continual improvement of the AIMS’s suitability, adequacy, and effectiveness—not only fixing isolated tickets.
- Clause 10.2 follows a systematic cycle: react, evaluate need for action to eliminate cause, implement, review effectiveness, and change the AIMS if necessary.
- Documented information of nonconformities, actions taken, and corrective-action results is required; verbal fixes without records fail evidence tests.
- Internal and external audit findings must feed the same corrective-action discipline; “training reminder” alone is often ineffective if systemic cause remains.
- AI-related NCs (unmonitored drift, missing impact assessment, unfair outcomes, uncontrolled retrain) need process- and system-level cause analysis, not only hyperparameter tweaks.
6.2 Clause 10 Improvement
Auditor focus: Clause 10 asks whether the organization learns. When monitoring, audits, incidents, or complaints show the AIMS or an AI system is not conforming or not effective, does management react, remove causes, prove effectiveness, and improve the system—or only restart the model and hope?
Clause 10 Improvement is the Act stage of the AIMS. It typically includes continual improvement (10.1) and nonconformity and corrective action (10.2). Recurring model failures, repeated missing impact assessments, or reopened certification findings at surveillance all signal weak Act. Strong organizations treat improvement as a managed process with owners, records, and effectiveness checks.
10.1 Continual Improvement
The organization shall continually improve the suitability, adequacy and effectiveness of the AIMS. Continual improvement is broader than corrective action. Corrective action reacts to nonconformity; continual improvement also includes proactive enhancement—better metrics, clearer AI policy, tighter third-party AI diligence, refined risk criteria, or lifecycle automation that reduces error.
| Source | Example AIMS enhancement |
|---|---|
| 9.1 metric trends | Add fairness monitoring after slice error rates worsen |
| 9.3 management review | Fund human-oversight tooling for high-risk uses |
| 9.2 internal audit themes | Standardize model card templates across products |
| External change (regulation, customers) | Update AI policy and impact assessment criteria |
| Opportunity / innovation | Approved evaluation harness for generative systems |
Auditor test: Ask for improvement backlog or management review outputs that changed the AIMS last cycle. “We improve models every sprint” is not automatically AIMS continual improvement unless management-system suitability, adequacy, or effectiveness improved (process, control, competence, documentation, objectives).
10.2 Nonconformity and Corrective Action
When a nonconformity occurs, the organization shall:
- React—control and correct it and deal with consequences as applicable.
- Evaluate the need for action to eliminate cause(s) so it does not recur or occur elsewhere—review the NC, determine causes, and check for similar or potential NCs.
- Implement any action needed.
- Review the effectiveness of corrective action taken.
- Make changes to the AIMS if necessary.
Actions shall be appropriate to the effects of the nonconformities. Retain documented information on the nature of NCs, subsequent actions, and results of corrective action.
What “good” looks like
| Step | Intent | Weak practice | Strong practice |
|---|---|---|---|
| React | Stop harm; restore control | Ignore bias complaint for weeks | Constrain model path; notify owners; contain incident |
| Cause evaluation | Systemic cause, not only symptom | “Analyst error” with no process review | Analysis covering data, ownership, monitoring, competence, vendor |
| Implement CA | Change the system | Email reminder only | Control, procedure, tooling, training redesign; SoA update if needed |
| Effectiveness | Prove recurrence reduced | Close ticket when email sent | Criteria checked after suitable period (e.g., metric within threshold; no recurrence in N releases) |
| Change AIMS | Update the management system | Leave obsolete procedure live | Update policy, risk method, lifecycle gates, roles, records |
Correction vs corrective action: Correction fixes the instance (retrain a broken version; complete one missing impact assessment). Corrective action removes cause (release gate requiring assessment before production; block pipeline without it). Exam items often test this distinction.
Documented information package
Sample CA records for: NC description (requirement vs evidence); immediate correction vs longer-term CA; cause analysis depth proportional to risk; owners and due dates; effectiveness result (not blank “effective?” fields); AIMS document or process changes.
Audit Findings Follow-Up
Findings from internal audit (9.2), certification/surveillance, customer audits, and sometimes regulatory exams should enter the same NC/CA process. Verify:
- Clear requirement references (clause / control / internal requirement).
- Severity drives response time and escalation.
- Fast containment for high-risk AI issues (safety, discrimination, security of AI systems).
- Cause analysis that does not only blame a junior engineer when governance failed.
- Effectiveness verified before true closure—especially before certification follow-up acceptance.
- Recurring similar findings across products signal ineffective CA or weak 10.1.
Classifying NCs, writing findings, and verifying CA after Stage 2 are expanded in the closing-the-audit chapters. Here, master the Clause 10 requirement the auditee must meet regardless of who raised the finding.
AI-Related NCs: Effective vs Ineffective CA
| AI-related NC | Ineffective CA | Effective CA |
|---|---|---|
| Production drift; no alerting (9.1 / operation) | “We retrained once” | Drift detection, thresholds, on-call ownership; procedure update; effectiveness = alerts and response within SLA |
| High-risk system live without impact assessment | One retrospective form | Release gate; RACI; re-sample next deployments; update process/SoA |
| Fairness complaint: disparate slice errors | PR statement only | Define fairness metrics; re-evaluate data/model; monitoring; human review; effectiveness on slice metrics |
| Third-party LLM change altered behavior | “Watch Slack” | Notification requirements; evaluation harness before version change; rollback; update third-party/Clause 8 change control |
| AI policy not communicated to tool users | Resend PDF once | Awareness program, completion tracking, sample interviews |
| Training-data security issue also under ISMS | Close as “duplicate” with no AIMS view | Coordinate ISMS CA and AI data quality/lineage/lifecycle updates |
Scenario walkthrough
Stage 2 finding: three of five sampled customer-facing models lack defined production monitoring for quality and drift, contrary to AI policy and 9.1 design expectations.
- React: Prioritize monitoring for highest-impact models; temporary enhanced human review if warranted.
- Cause: No standard monitoring requirement in lifecycle procedure; teams optimized for launch accuracy; AIMS owner never verified 9.1.
- CA: Mandate metric sets by risk tier; monitoring templates; product-owner competence; internal audit re-sample within six months.
- Effectiveness: All tier-1 models have live metrics and monthly analysis; no recurrence in next sample.
- AIMS change: Procedure revision, training records, possibly an objective on “% models with approved monitoring packs.”
Closing the certification NC after “adding a dashboard for one model” without lifecycle change should fail effectiveness at follow-up.
Auditor Tips and Traps
- Separate correction from corrective action in interviews and records.
- Proportionality: a low-risk checklist typo needs less analysis than discriminatory credit outcomes.
- Ask whether the cause could exist elsewhere (other models, regions).
- For vendor AI, the client still owns AIMS CA—verify client-side process change and acceptance testing.
- Trap—retraining as universal CA: may correct a drifted instance; does not fix missing monitoring, weak data governance, or absent human oversight.
- Trap—closing on plan only: “We will implement next quarter” is not completed CA.
- Trap—ISMS collision: an AI data-poisoning event may need both security CA and AI data/lifecycle CA without two contradictory narratives (see 6.3).
Clause 10 completes PDCA: evaluation without improvement is dashboard culture, not a management system.
In ISO management system language used by ISO/IEC 42001 Clause 10.2, what is the key difference between correction and corrective action?
A production credit model drifted and produced elevated error rates. The team retrained once, closed the ticket the same day, and made no monitoring or process changes. How should a lead auditor evaluate this against Clause 10.2?
Which documented information is expected as evidence of Clause 10.2 implementation?
How should certification audit nonconformities relate to the organization’s Clause 10 process?