ISO 42001 Annex A.4.2: Document the Resources an AI System Depends On

What control A.4.2 requires in practice

Control A.4.2 asks the organisation to identify and document the resources it needs for the activities at each relevant stage of an AI system's life cycle, and for other AI-related activities that matter to it. It is the umbrella control for the rest of theme A.4. The key words are relevant and activities: the record is not an inventory of everything the organisation owns, but an account of what particular AI work depends on. Annex B, which gives guidance, groups resources into system components, data, tooling, system and computing resources and people, and notes that any of these may be supplied by the organisation, a customer or a third party. It also says documentation may take forms such as data flow or architecture diagrams and can feed impact assessment. If a needed resource turns out to be unavailable, the guidance points back to revising the design or deployment requirements.

Describe resources in relation to an activity

Annex B.4.2 connects resource documentation with risk and impact understanding. It includes resources supplied internally, by customers or by third parties, and suggests that diagrams can help explain relationships. This guidance must be considered through clause 6.1.3(e), while implementation can be tailored under B.1.

As an original method, start with a meaningful activity such as producing a recommendation or evaluating a model. Identify the data, tools, computing and people that make it possible. Explain what would change if an important resource became unavailable or unsuitable. The purpose is decision support, not exhaustive collection of irrelevant technical details.

Why AI resource documentation matters

Risk and impact assessments are only as good as the description of the system they examine. When the resources behind an AI service are undocumented, assessments rest on assumptions, and surprises arrive during operation: a data feed is withdrawn, a supplier changes a model, or the one person who understands the pipeline leaves. Documented resources let management see dependencies before committing to a client, a delivery date or a change. They also shorten investigation after an incident, because the team can trace quickly what the system used. For organisations that rely on customers or third parties for part of the system, the record makes the division of responsibility visible, which helps in contract discussions and in explaining accountability to interested parties.

How to implement control A.4.2

Keep the record close to a real system and a real activity, so it stays useful and current. The aim is a record management can read in minutes and use in decisions, so resist the urge to capture every technical detail at the outset.

1. Choose one AI system or service that matters to the business and state its intended use in a sentence.
2. For each life-cycle stage you perform, such as development, evaluation, operation or support, list what the work needs.
3. Group the needs under components, data, tools, computing and people, and note whether each comes from you, a customer or a supplier.
4. Draw a simple diagram showing how these resources connect, since relationships are what an asset list usually misses.
5. Ask what would change if each important resource became unavailable or unsuitable, and note the answer.
6. Feed the record into your impact and risk work, and revise design or deployment plans where a resource gap appears.
7. Name an owner for keeping the record current and tie updates to system changes.

Illustrative IT example: a hidden evaluation dependency

Illustrative construction example: the customer supplies critical inputs

A construction consultancy uses AI to forecast progress from project updates. The customer controls part of the source information, while subcontractors provide other updates. The consultancy's resource map initially shows only its own database and the AI tool.

Documenting the external inputs and their interfaces helps the team understand missing-data risks and impact assumptions. The consultancy does not gain control over every supplier by drawing the map. It gains a clearer basis for deciding what information, acceptance conditions or limits its own process needs.

Choose a form that explains the relationships

A linked inventory, data-flow description or architecture diagram can be useful. Choose the form that readers can maintain and use. A diagram that hides external dependencies behind one cloud icon may be visually neat but operationally weak.

Distinguish resources needed for development, evaluation, deployment and operation where those stages differ. A test environment may have expertise or capacity that the operating service lacks. That difference can affect whether a proposed design or deployment remains feasible.

Use the information in assessment and change

Resource documentation should inform risk assessment and impact assessment. A dependency on incomplete customer data or unavailable review expertise can change the consequence analysis and treatment choice.

The guidance also notes that unavailable resources can require reconsideration of design or deployment requirements. Do not approve a control on the assumption that a resource exists when no one can obtain it. Make the constraint part of the decision.

Evidence and common mistakes