GuideGlobalISO/IEC 42001

ISO/IEC 42001 AI System Inventory

Build an inventory that connects each in-scope AI system to its purpose, lifecycle role, resources, data, responsible owner, suppliers and customers, impact assessment, risk treatment, controls, and monitoring.

ISO/IEC 42001 does not prescribe one universal inventory schema. Define fields from the organisation's context, AIMS scope, lifecycle roles, risk treatment, and selected controls.

Back to main artifact Review sources

Author: Sorena AI
Published: May 9, 2026
Updated: Oct 15, 2026

6 sections1 primary sources

Overview

Use this reference to define a controlled . Each record should describe the complete system and deployment context, identify the organisation's lifecycle roles and responsibilities, and link to current assessments, controls, decisions, monitoring, incidents, changes, and retirement evidence.

Section 1

What belongs in the AI-system inventory?

Inventory systems the organisation develops, provides, uses, or otherwise governs within the AIMS boundary. Include supplied AI services and embedded capabilities where the organisation's activities, responsibilities, risks, or impacts depend on them; do not limit discovery to internally trained models.

Use one stable record for the operational system: its business process, intended use, users, affected parties, deployment environment, model or tooling, data, infrastructure, people, suppliers, customer interfaces, documentation, support, monitoring, and lifecycle state.

A system can involve several organisation roles across its lifecycle. Record actual development, provision, deployment, operation, monitoring, procurement, and customer relationships instead of forcing one generic role label. Keep legal classifications in separate sourced fields when they are needed.

Include: a system or supplied service whose lifecycle activity falls within the approved AIMS scope.
Link rather than duplicate: keep assessments and operating evidence in their controlled systems of record and store current references in the inventory.
Escalate: records with no owner, unclear intended use, unresolved scope status, missing supplier information, or unsupported deployment.

Section 2

Field groups for a useful inventory record

The register should let a reviewer identify the system, understand what it does and where it operates, find accountable owners, locate the evidence used to approve it, and see whether the record is current. The precise fields can vary by organisation and system; ISO/IEC 42001 does not provide a mandatory inventory form.

Assign ownership by field group. The system owner maintains purpose and lifecycle state, while specialist owners maintain data, supplier, risk, impact, security, legal, monitoring, or incident information within their authority.

Identity and accountability: stable ID, name, description, owners, version, status, and record review date.
Purpose and context: intended use, unsupported or foreseeable misuse, business process, users, affected parties, locations, jurisdiction, deployment environment, and AIMS scope decision.
Lifecycle and resources: stage, organisation roles, development or procurement route, models and tooling, data, infrastructure, human competence, suppliers, components, customer interfaces, support, and retirement status.
Governance links: objectives, risk and impact assessments, treatment, statement of applicability, controls, approvals, technical and user documentation, monitoring, incidents, exceptions, corrective actions, and retention basis.

Section 3

Adapt the record to the sourcing and operating model

Use the same controlled inventory, but change the evidence fields and responsibility handoffs to match how the AI system is obtained and operated. The examples below are Sorena implementation patterns derived from ISO/IEC 42001 lifecycle, resource, supplier, customer, and responsible-use controls; they are not ISO classifications or automatic approval outcomes.

A single system may match several patterns. For example, a team can configure a supplied generative-AI service with internal retrieval data and embed it in a customer-facing workflow. Keep the supplier service, internal configuration, connected data, user experience, human review, and customer allocation visible in one system record or explicitly linked records.

Internally developed system: record the business owner, development team, model and tooling versions, training or evaluation data, design decisions, release criteria, deployment environment, operating owner, monitoring, and retirement plan.
Externally supplied AI service: record the supplier, service and model version where available, contracted purpose, data handling, configuration, supplier evidence, known limits, change notices, availability and support, exit plan, and the organisation's own deployment assessment. The organisation must assess and approve its use case instead of relying only on supplier assurance.
Embedded AI product or component: identify the containing product or process, supplied component, system boundary, intended function, update path, integrator responsibilities, user information, telemetry, failure handling, and which party can change or disable the AI behaviour.
Customer-configurable system: distinguish the provider's baseline design and documentation from customer-selected data, thresholds, prompts, workflows, users, and monitoring. Record the allocation of information, competence, approval, incident, and change responsibilities between provider and customer.
Generative-AI assistant or agent: inventory the model service, system instructions, retrieval sources, tools and permissions, memory, output destination, user population, prohibited uses, human review, evaluation set, logging, and provider or configuration changes.
Retired or replaced system: retain the decision, effective date, replacement, access shutdown, model and data disposition, supplier termination, user or customer communication, unresolved incidents, and any monitoring or record obligations that continue after use stops.

Section 4

Record states, approvals, and evidence

Use explicit states such as draft, under assessment, approved with conditions, approved, suspended, and retired. Define the evidence needed to enter each state, who can approve the transition, and which missing fields block deployment or continued operation.

Keep decision history. An approval record should identify the authority, date, basis, conditions, evidence gaps, review trigger, and linked risk or impact treatment. A field value without its source or owner is not reliable evidence.

Draft: identity, purpose, owner, lifecycle role, scope status, and dependencies are recorded.
Under assessment: required risk, impact, supplier, legal, security, or other reviews are assigned and linked.
Approved: the decision authority, operating conditions, controls, monitoring, and next review are recorded.
Suspended or retired: use restrictions, access and support changes, data and record disposition, residual duties, and final approval are documented.

Recommended next step

Put the AI-system inventory into operation

Connect each system record to its owner, intended use, lifecycle roles, supplier dependencies, assessments, and operating decision.

Assessment workflow

Open Assessment Autopilot for ISO/IEC 42001

Create inventory fields, accountable owners, evidence links, and record review tasks.

Explore next step

Talk to Sorena

Talk through implementation

Review your current scope, evidence gaps, and next implementation steps.

Explore next step

Section 5

Common inventory failures

A model list is too narrow when it omits the business process, deployment context, intended use, users and affected parties, externally supplied components, customer responsibilities, human oversight, or lifecycle state. Duplicate records are also risky when teams cannot tell which one controls decisions.

Do not import legal roles, classifications, or approval labels without recording the facts, jurisdiction, instrument, and decision owner. ISO/IEC 42001 is a management-system standard; it does not replace separate legal inventories or determine compliance with every applicable rule.

Do not mark a system approved because the inventory form is complete.
Do not copy stale assessment conclusions into the record; link to the controlled current version.
Do not delete retired records when the AIMS or another applicable requirement calls for their retention.

Section 6

Keep inventory records current

Review each record at a planned interval and when intended use, deployment context, data, model or tooling, supplier, customer allocation, performance, affected parties, legal requirements, or lifecycle state changes. Define which changes trigger renewed risk and impact assessment.

Reconcile the inventory against procurement, product, architecture, access, supplier, and incident records. Investigate mismatches because they can reveal an unapproved system, stale owner, missed change, or incomplete retirement.

Measure overdue reviews, missing owners, unlinked assessments, unsupported suppliers, conditional approvals, and unresolved retirement actions.
Preserve the reviewer, date, evidence considered, changes made, and next trigger.
Feed systemic gaps into internal audit, management review, resource decisions, and corrective action.

Primary sources

References and citations

ISO/IEC 42001:2023 - AI management systems

iso.org7 citations

Referenced sections

Official ISO record for the current published edition; the standard's context, documented-information, assessment, and Annex A control requirements ground this inventory reference.
Clauses 4.1-4.3 connect intended purpose, organisation roles, and AI activities to AIMS scope; Annex A.4 and A.10 address resources and external responsibility allocations.
Annex A controls cover AI-system resources, impacts, lifecycle processes, data, information for interested parties, responsible use, and third-party and customer relationships.

Show 4 more

Annex A.4 and A.6-A.10 address resources, lifecycle processes, data, information for interested parties, responsible use, and third-party or customer relationships. The examples translate those control areas into organisation-defined inventory fields without presenting them as mandatory ISO forms.
Clauses 7.5 and 8.1 require controlled documented information and evidence that planned processes were carried out; Clauses 8.2-8.4 require retained assessment and treatment results.
The standard uses organisation-specific scope, risk, impact, lifecycle, and documented-information controls; it does not prescribe a model-only catalogue or universal legal classification.
Clauses 8.2-8.4 and 9.1-10.2 connect change-triggered assessments, monitoring, audit, management review, and corrective action.