ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The ISO 42001 AI system lifecycle controls sit in Annex A.6, the largest group of controls in the standard. They tell you how an AI system should move from idea to retirement under control: requirements, design, testing, deployment, monitoring and records.
This is where AI governance becomes engineering practice. Policies and committees matter, but an auditor will test whether a real model had written requirements, was tested before release and is monitored today.
This guide walks through the Annex A.6 controls in lifecycle order and shows the evidence for each. For all nine control areas, see our ISO 42001 controls 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
Annex A.6 covers responsible development of AI systems. It starts with objectives and processes for responsible development, then moves through requirements and specification, design and development documentation, verification and validation, deployment, operation and monitoring, technical documentation and event logs.
These controls apply when you develop AI systems. If you only buy or use them, some map to supplier controls in Annex A.10, but you should still decide each one’s applicability in your Statement of Applicability.
Annex B gives implementation guidance for each control, and Annex A itself is normative only where you select the control.
The authoritative text is summarized at ISO/IEC 42001:2023.
Start by defining what responsible development means for your organization: for example, fairness testing before release, documentation of training data and human oversight for high-impact decisions.
Then write a process that turns those objectives into steps. A secure development life cycle for AI usually includes gates for risk review, impact assessment, testing and approval.
Link the process to your ISO 42001 AI objectives so the intent is measured.
A defined process makes the ISO 42001 AI system lifecycle repeatable across teams.
Every AI system should have written requirements: purpose, users, expected performance, constraints, data needs, legal and ethical requirements and acceptable failure modes.
Capture them before building. A specification that appears after the model is trained is a description, not a requirement.
Include requirements that come from your impact assessment, such as explainability for affected people. Our impact assessment guide shows how the outputs feed in.
Document the design choices that matter: model type, architecture, features, training approach, thresholds and known limitations. Record why you chose them.
Keep version history for models, datasets and code so you can reproduce what was deployed. Reproducibility is a strong evidence point for auditors and a practical help during incidents.
Keep documentation proportionate. A short, accurate record is better than a long one that nobody updates.
Our toolkit includes lifecycle templates, so the ISO 42001 Toolkit speeds up the paperwork.
Verification asks whether you built the system right: does it meet the specification? Validation asks whether you built the right system: does it work for its intended use and users?
Define test criteria before testing: accuracy, robustness, fairness, security and safety measures with thresholds. Record the results and any accepted limitations.
Our guide to AI bias testing gives methods for fairness checks, and approval should require evidence that the tests passed.
Retest after significant changes, because a model that passed last quarter may behave differently after new data or a new dependency.
| Lifecycle stage | Key control focus | Evidence |
|---|---|---|
| Requirements | Purpose, constraints, legal and ethical needs | Specification document |
| Design and build | Documented choices and versions | Design record, version history |
| Verify and validate | Tests against defined criteria | Test reports with thresholds |
| Deploy | Controlled release and approval | Release checklist and sign-off |
| Operate | Monitoring and logs | Dashboards, logs, incident records |
Control the move to production. Use a release checklist covering approvals, risk and impact review, testing evidence, user information, rollback plan and monitoring setup.
Deployment also includes changes. Treat a significant model update as a new release, with the same gates as the original.
Keep the approval records. They show who accepted the risk and when.
Once live, monitor performance, drift, errors, user feedback and misuse. Define thresholds and owners, and decide what triggers retraining, rollback or retirement.
Feed monitoring results into objectives and management review. Our guide to AI model drift risk explains what to watch.
Make sure incidents flow into your incident process. See the AI incident management guide for the workflow.
Review thresholds regularly so monitoring still reflects the ISO 42001 AI system lifecycle risks you accepted.
Annex A.6 expects technical documentation that supports use, operation and maintenance. Typical contents include intended use, architecture, data sources, performance results, limitations and operating instructions.
Different audiences need different views: developers need detail, operators need runbooks and users need plain information. Plan each.
This also supports legal obligations in some regions, since regulation may require technical documentation for certain AI systems.
Annex A.6 includes recording of event logs so you can trace what an AI system did. Decide what to log: inputs, outputs, decisions, model versions, overrides and errors, with attention to privacy.
Set retention periods and protect logs from tampering. Logs are the base for investigations, audits and improvement.
Avoid logging more personal data than necessary. Align log content with your data protection rules.
Review log access regularly, since logs often contain information that needs protecting.
Lifecycle thinking includes the end. Plan how to retire a system: stop use, notify users, archive records, delete or retain data as required and revoke access.
Keep a record of retirement decisions. An old model running unmonitored in a corner is a real risk and an easy audit finding.
Update your AI inventory when systems retire, so scope and risk records stay accurate.
For a sampled system, auditors may ask for the requirements document, design record, test results, approval, monitoring dashboard and logs. They follow one system through the lifecycle.
Prepare two or three well-documented examples that show the process working. Consistent evidence across the lifecycle beats perfect evidence in one stage.
Our internal audit guide shows how to rehearse this trace.
A consistent ISO 42001 AI system lifecycle produces evidence as a by-product of normal work.
Typical gaps include no written requirements, testing without thresholds, no approval record for deployment, no monitoring after release and logs that are not retained.
Another is applying controls only to new systems and ignoring legacy models. Bring existing systems into the process on a risk-based schedule.
A third is treating the lifecycle as a data science matter only. Legal, risk and business owners need defined roles in the gates.
Include lifecycle checks in each internal audit of the ISO 42001 AI system lifecycle controls.
A small team can run the lifecycle with a short template per stage and a single approval gate. A large organization may add review boards and tooling.
The question is not how heavy the process is, but whether it consistently produces the evidence the controls expect.
Start with your highest-risk systems, then extend the process to the rest.
Your risk assessment decides which Annex A.6 controls are applicable. If a control is excluded, record the reason in the Statement of Applicability.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 38 AI risk scenarios, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
For each applicable control, name the procedure and the evidence. This table of control, procedure and evidence is exactly what an auditor will sample.
Review it whenever your development process changes.
Take a customer support classification model. Requirements state the purpose, accuracy target, languages and the rule that low-confidence cases go to a human. Design records the model type, training data sources and known limits.
Testing checks accuracy by language and customer group against the thresholds, plus security tests for prompt injection. Deployment needs a release checklist and approval from the product owner and the AI governance lead.
In operation, dashboards track accuracy, escalation rate and complaints, and event logs record model version and decisions. This one example shows the ISO 42001 AI system lifecycle working from requirement to evidence.
Keep the example as a reference case in your records. Auditors often ask for a single system to be traced end to end.
Version control, model registries, experiment tracking and automated test pipelines make the controls easier to operate and to evidence. They create records automatically.
Pick tools that fit existing engineering habits. A control that requires a separate manual process will be skipped under pressure.
Whatever the tooling, make sure records are retained, searchable and linked to the system in your AI inventory.
Some do not, but you must decide applicability for each and justify exclusions. Third-party controls in Annex A.10 apply to suppliers.
Annex A.6 expects event logs where appropriate. Decide what to log based on risk, purpose and privacy, and document the reasoning.
Detailed enough to support operation, maintenance and audit. Keep it proportionate and up to date.
Yes if they are in scope. Bring them in on a risk-based schedule and record the plan.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026