Most organizations treat AI governance as a point-in-time compliance exercise. They document a policy, run a risk assessment, and consider the job done. What ISO 42001:2023 demands is fundamentally different: continuous, structured oversight of every AI system from the moment it is conceived to the moment it is retired. That end-to-end perspective is what separates a mature AI management system (AIMS) from a paper exercise — and it is precisely where auditors focus their attention.
In my work with more than 200 clients at Certify Consulting, the lifecycle management gap is the single most common finding I see in pre-audit assessments. Organizations handle development reasonably well, then lose control at deployment and completely forget about end-of-life. This article maps every stage of the AI system lifecycle to the specific ISO 42001:2023 requirements that govern it, so you can build a program that passes first-time — and keeps passing.
Why Lifecycle Management Is Central to ISO 42001
ISO 42001:2023 is built on the Plan-Do-Check-Act (PDCA) model, meaning the standard expects AI governance to be iterative, not static. Clause 6.1 (Actions to address risks and opportunities) and Clause 8 (Operation) together establish that risk controls must be applied at every operational stage of an AI system — not just at initial deployment.
This is reinforced by Annex A of the standard, which contains 38 controls organized across domains including AI system impact assessment, data management, system life cycle, and responsible AI. Crucially, Annex A Control A.6 is dedicated entirely to AI system life cycle management, signaling how seriously the standard's authors treated this topic.
A 2023 McKinsey survey found that only 21% of organizations with active AI deployments had formal processes for retiring or replacing AI models. That statistic illustrates exactly the kind of governance gap ISO 42001 is designed to close.
Stage 1: Design and Conceptualization
Every ISO 42001-compliant AI lifecycle begins before a single line of code is written. The design phase is where the foundational governance decisions are made — and where the most expensive mistakes are either prevented or embedded.
Clause 6.1.2 — AI Risk Assessment at Design Time
ISO 42001:2023 clause 6.1.2 requires organizations to identify risks and opportunities associated with AI systems in the context of their intended use. At the design stage, this means answering:
- What is the intended purpose of this AI system? (Clause 4.3 — Scope)
- Who are the affected parties, and what harms could occur? (Annex A, A.4 — Stakeholder engagement)
- What data will the system use, and does it introduce bias or privacy risk? (Annex A, A.7 — Data for AI systems)
A formal AI System Impact Assessment (ASIA) should be completed at this stage. Unlike a general risk assessment, the ASIA evaluates consequences for individuals, groups, and society — not just the organization.
Translating "Intended Use" Into Documented Scope
One practical tool I recommend to every client is an AI System Profile Document completed at design time. This document captures:
| Field | Example Entry |
|---|---|
| System Name | Customer Churn Prediction Model v1 |
| Intended Use | Predict 90-day churn probability for retention outreach |
| Prohibited Uses | Credit scoring, employment screening |
| Data Inputs | CRM transactional data, support ticket history |
| Affected Stakeholder Groups | Existing customers, customer success team |
| Risk Classification | Medium — limited consequential decision-making |
| Responsible Owner | VP, Customer Experience |
Documenting prohibited uses at the design stage is not optional under ISO 42001 — Annex A Control A.6.2 explicitly requires that the organization define and communicate use restrictions for AI systems.
Stage 2: Data Acquisition and Preparation
AI systems are only as trustworthy as the data they are trained on. ISO 42001 dedicates significant attention to data governance because biased, incomplete, or unlawfully obtained training data undermines every control that follows.
Annex A Control A.7 — Data for AI Systems
Control A.7 requires organizations to establish processes for data acquisition, quality assurance, provenance tracking, and privacy compliance. In practice, this means:
- Data provenance records documenting the origin, collection method, and applicable legal basis for all training data
- Data quality checks covering completeness, accuracy, representativeness, and temporal relevance
- Bias evaluation — documented analysis of whether training data reflects historical disparities that the model might perpetuate
The EU AI Act's Annex IV (which applies to high-risk AI systems) similarly mandates training data documentation — meaning organizations subject to both frameworks can satisfy both requirements with a single, well-structured data governance process.
According to IBM's 2024 AI in Business report, 35% of AI project failures are attributable to poor data quality, making this stage the highest-leverage point for risk reduction before development even begins.
Stage 3: Development and Testing
The development phase is where ISO 42001's operational requirements (Clause 8) intersect most directly with engineering practice. Clause 8.4 requires organizations to establish and implement processes to ensure AI systems are developed in accordance with their AIMS policies and objectives.
Verification, Validation, and Explainability
ISO 42001 does not prescribe specific technical methods, but Annex A Control A.6.3 requires that AI systems be verified and validated before deployment. Effective V&V processes under the standard include:
- Functional testing against defined performance criteria
- Adversarial testing to identify unexpected behaviors under edge cases
- Explainability assessment — can the system's outputs be explained to a non-technical stakeholder in a meaningful way?
- Bias and fairness metrics — are performance metrics consistent across demographic subgroups?
Organizations operating in regulated industries should note that explainability is not merely a best practice under ISO 42001 — it is an auditable requirement where consequential decisions are involved. I have seen this specific gap generate nonconformities in financial services and healthcare clients who assumed "black box" models were acceptable.
The ISO 42001 Development Checklist
Before an AI system can be approved for deployment under a conforming AIMS, the following should be documented:
| Checkpoint | ISO 42001 Reference | Status |
|---|---|---|
| AI System Profile Document completed | Annex A, A.6.1 | ☐ |
| AI Risk Assessment finalized | Clause 6.1.2 | ☐ |
| Training data provenance recorded | Annex A, A.7.1 | ☐ |
| Bias evaluation completed | Annex A, A.7.4 | ☐ |
| Verification and validation performed | Annex A, A.6.3 | ☐ |
| Explainability documented | Annex A, A.6.2 | ☐ |
| Security and robustness testing completed | Annex A, A.9 | ☐ |
| Deployment approval granted by AI Owner | Clause 5.3 | ☐ |
Stage 4: Deployment and Operationalization
Deployment is the stage where governance most frequently breaks down in organizations I assess. Systems go live under pressure, monitoring plans are deferred, and documented controls never make it into production operations.
Clause 8.4 — Operational Controls
ISO 42001:2023 clause 8.4 requires that operational controls be established for AI systems in deployment. This includes:
- Monitoring plans specifying what metrics are tracked, at what frequency, and by whom
- Incident response procedures for when AI outputs cause or risk harm
- Human override mechanisms — the standard's emphasis on "human oversight" (Annex A, A.6.5) means that any consequential AI decision must have a defined escalation path to a human decision-maker
Change Management for Deployed AI Systems
One of the most underappreciated ISO 42001 requirements is change control for deployed models. Annex A Control A.6.4 requires that significant changes to AI systems — including model retraining, threshold adjustments, or integration changes — be subject to the same review and approval process as initial deployment.
What counts as a "significant change" under ISO 42001? My practical guidance to clients is to treat any change that could affect system outputs, risk profile, or affected stakeholder groups as significant. This includes:
- Retraining on new or expanded datasets
- Updating model architecture or hyperparameters
- Integrating new data sources or APIs
- Changing the system's decision thresholds
A Gartner report from 2024 found that 74% of AI-related incidents in enterprise deployments involved a system that had been modified post-deployment without formal change control. That statistic alone should motivate every AIMS program manager to build a robust AI change management process.
Stage 5: Monitoring and Performance Review
ISO 42001 is explicit that AI governance does not end at deployment. Clause 9.1 (Monitoring, measurement, analysis, and evaluation) requires organizations to determine what needs to be monitored, the methods used, and when results will be analyzed and reported.
What to Monitor Under ISO 42001
Effective AI system monitoring under the standard covers three dimensions:
1. Technical Performance - Model accuracy, precision, recall, or domain-specific metrics - Data drift — are incoming inputs drifting from training distribution? - Concept drift — is the real-world relationship the model was trained on changing?
2. Operational Performance - System availability and response time - Frequency and nature of human overrides - Volume and type of AI-related complaints or escalations
3. Responsible AI Performance - Ongoing bias monitoring across protected demographic groups - Alignment with stated intended use — is the system being used as documented? - Regulatory compliance status — especially relevant as the EU AI Act enforcement timelines advance
Connecting Monitoring to Management Review
Clause 9.3 requires that AI system performance data be presented to top management as part of periodic management reviews. This is more than a formality — it creates accountability at the executive level for AI risks that are often siloed in technical teams. In a conforming AIMS, senior leadership must be able to articulate the performance and risk status of every material AI system in the organization's portfolio.
Stage 6: Incident Management and Continuous Improvement
Even the best-governed AI systems will occasionally produce unexpected or harmful outputs. ISO 42001's approach to incidents is consistent with ISO 9001 and ISO 27001: organizations must identify, respond to, and learn from incidents in a documented, systematic way.
Clause 10.2 — Nonconformity and Corrective Action
When an AI system produces an output that constitutes a nonconformity — a biased hiring recommendation, an erroneous medical triage result, a fraudulent transaction that slipped past a detection model — the organization must:
- Contain the immediate impact and protect affected parties
- Investigate root cause — was this a data issue, a model deficiency, a use-case boundary violation?
- Implement corrective action — which may include model retraining, threshold changes, or suspension of the system
- Update the AI System Profile and Risk Assessment to reflect lessons learned
- Report upward to AI governance bodies and, where required by law, to regulators
The connection between ISO 42001 incident management and regulatory obligations is increasingly important. Under the EU AI Act Article 62, providers of high-risk AI systems are required to report serious incidents to national market surveillance authorities — a requirement that maps directly onto a well-functioning ISO 42001 incident management process.
Stage 7: Decommissioning
Decommissioning is the lifecycle stage that organizations most consistently neglect — and it carries real compliance and reputational risk. An AI system that has been "turned off" but whose training data, model weights, and outputs remain in organizational systems is not truly decommissioned under ISO 42001.
Annex A Control A.6.6 — AI System Disposal
Control A.6.6 requires that when an AI system is retired, the organization addresses:
- Data retention and deletion — training data, model artifacts, and logged outputs must be handled in accordance with data protection obligations and documented data retention policies
- Documentation archival — the AI System Profile, risk assessments, and incident records should be retained for a defined period for audit and legal defensibility purposes
- Stakeholder communication — affected parties (internal users, external customers, regulators) must be notified as appropriate
- Dependent system review — any downstream systems or processes that relied on the decommissioned AI must be assessed and updated
The Decommissioning Checklist
| Task | Responsible Party | Completion Criteria |
|---|---|---|
| Formal decommission decision documented | AI System Owner | Signed approval on file |
| All active use cases migrated or retired | Operations Lead | No live dependencies confirmed |
| Model artifacts and weights deleted or archived | IT / MLOps | Data destruction certificate issued |
| Training data disposition completed | Data Governance | Deletion or retention documented per policy |
| AI System Profile updated to "Retired" status | AIMS Program Manager | Registry entry updated |
| Lessons learned captured for AIMS improvement | Quality / AI Lead | Incorporated into next management review |
| Regulatory notification completed (if required) | Legal / Compliance | Confirmation on file |
Lifecycle Management Across the AI Risk Spectrum
Not all AI systems require the same level of lifecycle governance rigor. ISO 42001 is a risk-based standard, meaning the depth of controls should be proportionate to the risk classification of the system.
| Risk Level | Example System | Key Lifecycle Requirements |
|---|---|---|
| Low | Internal chatbot for HR FAQs | Basic profile, annual review, standard decommission |
| Medium | Customer churn prediction model | Full ASIA, quarterly monitoring, change control |
| High | Automated credit decisioning | Full ASIA + external audit, monthly monitoring, regulatory reporting, enhanced decommission |
| Unacceptable | Real-time social scoring | Prohibited under ISO 42001 and EU AI Act — do not build |
This risk-tiered approach allows organizations to allocate governance resources proportionately — investing heavily in lifecycle controls for high-risk systems while applying lighter-touch processes to low-risk tools.
Building a Lifecycle Management Program That Auditors Trust
After leading AIMS implementations for more than 200 organizations at Certify Consulting, I have found that the programs that achieve and sustain certification share four structural characteristics:
-
A centralized AI system registry — a single source of truth that tracks every AI system from inception to retirement, including its current lifecycle stage, risk classification, and assigned owner.
-
Stage-gate approvals — formal checkpoints at design, pre-deployment, and decommission that require documented sign-off before a system can advance. This prevents systems from drifting through the lifecycle without governance oversight.
-
Integrated change control — AI system changes are routed through the same change management process as other IT and operational changes, with risk-based review requirements tied to change magnitude.
-
Lifecycle-aware monitoring — monitoring plans are built at design time and updated at each lifecycle stage, ensuring that what is measured evolves with the system's risk profile.
If your current AIMS program lacks any of these four elements, that is where an auditor will look first.
How ISO 42001 Lifecycle Management Compares to Other Frameworks
| Lifecycle Stage | ISO 42001:2023 | EU AI Act | NIST AI RMF |
|---|---|---|---|
| Design | AI System Profile, ASIA (Annex A.6.1) | Conformity assessment (Art. 9) | MAP function |
| Data | Data governance (Annex A.7) | Training data requirements (Annex IV) | MEASURE function |
| Development | V&V requirements (Annex A.6.3) | Technical documentation (Art. 11) | MAP + MEASURE |
| Deployment | Operational controls (Clause 8.4) | Post-market monitoring (Art. 72) | MANAGE function |
| Monitoring | Clause 9.1 performance monitoring | Serious incident reporting (Art. 62) | GOVERN + MEASURE |
| Decommission | Disposal controls (Annex A.6.6) | Not explicitly addressed | MANAGE function |
ISO 42001 is the only framework that explicitly addresses decommissioning through a dedicated Annex A control — making it the most complete lifecycle governance framework currently available to organizations building enterprise AI programs.
Key Takeaways for AI Governance Leaders
ISO 42001:2023 treats AI lifecycle management as a continuous, auditable process — not a one-time compliance event. Organizations that build stage-gate governance, maintain living AI system registries, and apply risk-proportionate controls at every phase are not only positioned to achieve certification — they are building the operational foundation for trustworthy, sustainable AI deployment.
The lifecycle management requirements in ISO 42001 are also your best preparation for the EU AI Act's conformity assessment requirements, which overlap significantly with the standard's Annex A controls. Organizations that implement a conforming AIMS now are creating reusable compliance infrastructure for the regulatory environment of the next decade.
For a practical assessment of where your organization stands on AI lifecycle management readiness, explore our ISO 42001 gap assessment resources or reach out to the team at Certify Consulting directly.
Last updated: 2026-04-01
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.