Sted
Get started
Sted
Get started

LinkedIn Newsletter

ISO 42001 operation and the AI system lifecycle

ISO 42001:2023 8.1 asks you to plan and control the processes that run your AI management system, and 8.2 to 8.4 to repeat risk, treatment and impact work as planned. Annex A turns this into lifecycle controls, A.6.1.2 to A.6.2.8, from requirements through monitoring and event logs, and data controls, A.7.2 to A.7.6.

The requirement in plain English

Operational planning and control (ISO 42001:2023 8.1). You set criteria for the processes the management system needs, run them to those criteria, and keep enough documented information to show they ran as planned. You control planned changes, review the effects of unintended ones, and control processes, products and services that come from outside, such as a model or dataset bought from a supplier.

Repeating the assessments (ISO 42001:2023 8.2, 8.3 and 8.4). You rerun the AI risk assessment and the AI system impact assessment at planned intervals and on significant change, carry out the treatment plan, and keep the results. The risk and impact assessment page covers what goes in them.

The lifecycle controls in Annex A. For AI you develop, the controls follow a system’s life. You set objectives for developing AI responsibly (ISO 42001:2023 Annex A 6.1.2) and a defined design and development process. You specify requirements for each new or substantially changed system (ISO 42001:2023 Annex A 6.2.2) and document its design. You verify and validate it against criteria (ISO 42001:2023 Annex A 6.2.4) and release it through a defined deployment process (ISO 42001:2023 Annex A 6.2.5). You decide what running and monitoring it involves (ISO 42001:2023 Annex A 6.2.6), give the technical documentation each audience needs (ISO 42001:2023 Annex A 6.2.7), and decide which events are logged and when (ISO 42001:2023 Annex A 6.2.8).

The data controls in Annex A. For data used to develop and improve AI, you define its requirements (ISO 42001:2023 Annex A 7.2), and then how it is acquired, its quality, a record of its provenance, and how it is prepared, such as cleaning and labelling, under controls A.7.3 to A.7.6.

Bought-in AI follows a shorter path. The development and training-data controls often do not apply, but deployment, monitoring, use within the intended purpose and supplier control still do.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 40-person company builds a document classification model that insurers use to route claims. Every system follows one written lifecycle procedure with gates.

Before any data is gathered, a use case record sets the purpose, users, inputs, outputs, oversight model and classification, and is approved. A development plan follows. Each training set has a dataset record: source, licence or consent basis, collection period, known gaps and the preparation steps. Experiments are logged so a result can be reproduced.

Acceptance criteria for accuracy and for performance gaps between claim types are set before testing begins. The evaluation report tests against them, and a bias and fairness review sits beside it. A deployment readiness record collects the evidence, and the deployment approver, who did not work on the model, signs it off.

A monitoring plan sets drift, accuracy and complaint thresholds with an action for each. Monthly monitoring records show the figures. Event logs keep each prediction’s model version and input reference for two years, to support customer queries.

Retraining is a change, not routine: it re-enters the procedure at evaluation, and the impact assessment is reviewed. When a model is retired, the record shows when, why and what replaced it.

Evidence an auditor expects

  • Operational criteria and records (required documented information under 8.1): evidence the lifecycle procedure ran as written for a sampled system.
  • Use case and requirements: approved before development began.
  • Dataset records: provenance, quality checks and preparation for each training set.
  • Verification and validation results: tested against criteria set beforehand, with the decision to release.
  • Deployment approval: who approved, against what evidence, and their independence from the build.
  • Monitoring plan and results: thresholds, results over time and actions taken when one was crossed.
  • Event logs and change records: what is logged, retention, and how retraining or changes were controlled.

Common mistakes

Acceptance criteria written after the test

Criteria chosen once results are known prove nothing. Fix them in the requirements and date them before evaluation.

Monitoring without thresholds

Dashboards that nobody acts on are not monitoring. Each measure needs a threshold, an owner and an action.

Data with no provenance

Scraped, purchased or customer data used without a record of its source and terms fails the data controls and creates copyright and data protection exposure. Record provenance when the data arrives, not at the audit.

The builder approves the release

When the developer signs off their own model, independence is lost. Name a deployment approver who did not build it, and record conflicts where a small team cannot avoid them.

Vendor models outside the process

Fine-tuned or bought-in models skip the procedure because “someone else built it”. Clause 8.1 expects externally provided processes and services to be controlled, so put them through the lighter path.

How Sted helps

  • Sted’s knowledge base includes an AI Use Case Definition and Classification Record (REC-AIUC), one per AI system under the AI System Lifecycle Procedure (PRC-AISL), which sets out the use case, its users, inputs, outputs and human oversight model and, in its Risk Classification and Regulatory Assessment section, the classification reached, and is approved before data collection or model development begins.
  • Records are part of the Full Management System plan.
  • Under the AI System Lifecycle Procedure (PRC-AISL) Sted’s knowledge base carries a record for each stage of an AI system’s life, the AI Development Plan (REC-AIDP), Dataset Record (REC-DSET), Experiment Record (REC-AIER), Model Evaluation Report (REC-AIME), Bias and Fairness Assessment Record (REC-AIBF), Deployment Readiness and Integration Test Record (REC-AIDR), Post-Deployment Monitoring Plan (REC-PDMP) and Post-Deployment Monitoring Record (REC-AIPD), tagged to the ISO 42001 Annex A lifecycle, data and resource controls.
  • Records are part of the Full Management System plan.
  • Under the Acceptable Use Policy (POL-AUP) Sted’s knowledge base carries an AI Tool Approval and Use Record (REC-AITA), tagged to ISO 42001 controls A.9.2 and A.9.4 on the responsible use of AI systems.
  • Records are part of the Full Management System plan.

Sted holds the lifecycle records and their approvals. It does not test, evaluate or monitor your models; your teams do that and record the results.

Frequently asked questions

Do the lifecycle controls apply to AI tools we buy rather than build?

Partly. The design, development and training-data controls usually do not, and you can exclude them with a reason. Deployment, operation and monitoring, use within the intended purpose, and supplier controls do apply, because you decide how the tool is introduced and watched. Clause 8.1 also expects you to control processes and services you get from outside.

How often should an AI system be monitored?

As often as its risk and rate of change need, set in a monitoring plan before release. A model making customer decisions daily might be checked weekly against drift and fairness thresholds; an internal summariser might be reviewed quarterly. What matters to an auditor is that each check has a threshold and an action when it is crossed.