AI security & compliance5 min read

ISO 42001 lifecycle controls: from design to decommission

How to implement ISO 42001 AI system lifecycle controls — requirements, design documentation, verification, deployment gates, monitoring and retirement — without stalling delivery.

By FORTE/CYBERx AdvisoryReviewed by FORTE/CYBERx Advisory10 August 2026

Why the lifecycle theme is the heart of the standard

The ISO/IEC 42001 lifecycle controls are what separate an AI management system from an AI policy. They require the organisation to define responsible development objectives, specify requirements, document design decisions, verify and validate behaviour, control deployment, monitor operation, and retain technical documentation and event logs.

Implemented well, they slot into the delivery process the organisation already runs and add perhaps a day of effort per system. Implemented badly, they become a retrospective documentation exercise that nobody trusts and every auditor discounts.

The design principle is simple: each control should be a decision point in delivery that produces an artefact as a by-product.

Requirements specification for AI systems

Start with a written statement of what the system is for and what it must not do. Record the intended users, the decisions it supports or makes, the acceptable error profile, the data it may access, the latency and availability expectations, and the explicit non-goals.

Include the performance threshold that defines acceptable. "The assistant answers policy questions" is not testable. "The assistant answers policy questions using only the approved policy library, cites the source document, and declines when no source supports an answer" is.

Set the human oversight requirement here rather than later. Deciding at requirements time whether a human approves every output, samples outputs, or only handles exceptions determines the architecture.

Design and development documentation

The documentation control asks for a record of design and development decisions. For a system built on third-party models, the substantive design decisions are the model and version selected, the system prompt, the retrieval or grounding configuration, the guardrails and filters, the tool or action permissions granted, the data boundary, and the logging configuration.

Record the alternatives considered and why they were rejected — particularly where a more capable but less controllable option was declined. That record is exactly what an auditor or a board wants when asking whether risk was considered before deployment.

Keep the documentation in version control alongside the configuration it describes. Documentation that cannot drift is documentation that stays true.

Verification and validation that means something

Verification asks whether the system was built to specification; validation asks whether it achieves its purpose in real use. Both are required, and both must test the deployed configuration rather than the model in isolation.

A workable test set has four parts: functional cases drawn from real business tasks, adversarial cases including direct and indirect prompt injection, boundary cases where the correct behaviour is refusal, and fairness cases that check consistent behaviour across cohorts where the system affects people.

Record results with dates, versions and the person who ran them. Re-run the set on model version change, prompt change, retrieval-source change and on a periodic cadence. Suppliers update models without asking, so periodic re-testing is not optional.

Deployment gates and change control

Define what must be true before an AI system reaches production: an approved impact assessment, a completed test set, a named business owner and technical owner, logging enabled, a documented rollback or disable path, and user-facing transparency in place.

Route AI changes through the existing change management process rather than a parallel one, but add AI-specific change classes: model version, system prompt, grounding data source, tool permissions and guardrail configuration. Each of those can change behaviour materially without changing a line of application code.

Stage the rollout. A limited user group with elevated monitoring for a defined period surfaces the failure modes the test set missed, at a scale where they are recoverable.

Apply this to your organisation

Want this assessed against your environment?

Send us the specifics and a senior advisor will respond within one business day.

Operation, monitoring and event logs

The monitoring control requires ongoing oversight of AI system behaviour in operation. Decide what to capture and for how long: inputs and outputs at an appropriate level of detail, the identity of the requester, the sources retrieved, the tools invoked, refusals, escalations to human review, and user-reported problems.

Balance logging against privacy. Logging full prompt content can create a sensitive-information repository that itself needs classification, access control and retention limits — a point where the ISO 42001 and Privacy Act positions must agree.

Set thresholds that trigger action: a rise in refusal rate, a fall in citation coverage, an unusual pattern of tool invocation, a spike in cost, or user complaints above a defined level. Monitoring without a threshold is a dashboard nobody reads.

Incident handling for AI failure modes

Extend the existing incident process rather than creating a new one. Add AI-specific categories: harmful or discriminatory output, disclosure of information the requester should not see, systematic inaccuracy, unauthorised autonomous action, and model or supplier compromise.

Predefine the containment options. For most AI systems containment means disabling a tool permission, reverting a prompt or model version, restricting the user group, or switching to a fully human path. Whoever operates the system should be able to do these without a change advisory board convening.

Feed every incident back into the risk assessment and the test set. An incident that does not change the test set will recur.

Retirement and decommissioning

Decommissioning is the most neglected part of the lifecycle. Plan for it at design time: what happens to the grounding data, the logs, the fine-tuned artefacts, the integrations, the credentials, and the users who depend on the system.

Record the decision to retire, the migration path for affected users, the deletion or retention position for each data store with reference to legal obligations, and confirmation that credentials and API access were revoked.

Retire deliberately rather than by neglect. A dormant AI integration with live credentials and a stale grounding index is both an unmanaged risk and an audit finding.

Making the lifecycle affordable

Tier the effort. Define two or three impact classes and attach a proportionate lifecycle to each — a lightweight path for internal productivity tools with no personal information, a full path for anything that affects customers or people.

Template the artefacts. A one-page requirements and design record, a standard test set that teams extend, and a deployment checklist cover most of the theme for most systems.

Measure the overhead. If the governed path takes materially longer than the ungoverned one, teams will route around it, and the management system will document a reality that no longer exists.

Sources and further reading

This article provides general information and decision support. It is not legal advice, audit assurance, certification advice or a guarantee of outcome.