ISO 42001 Annex A.4.3: Describe the Data Resources Behind AI Results

What control A.4.3 requires in practice

Control A.4.3 asks the organisation to document information about the data resources its AI system uses, as part of identifying resources under A.4.2. The focus is on information about the data, not the data itself. The control statement does not list particular fields, so the organisation decides what is relevant to its system. Annex B, which is guidance, suggests topics to consider: where the data came from, when it was last updated, the category it belongs to in machine learning terms such as training, validation, test or production, how it is labelled, what it is intended for, its quality, retention and disposal arrangements, known or possible bias issues and how it was prepared. The organisation can extend or trim this list according to its own role and risks. The record is useful when someone who did not build the system can understand what data supports each use.

Describe the purpose and context of the data

Annex B.4.3 points to information such as origin, updates, lifecycle use, labelling, quality, preparation and known bias issues. It also considers retention and disposal arrangements. The guidance is required consideration under clause 6.1.3(e), while the organisation can tailor implementation under B.1.

As an original documentation test, ask whether a reviewer can distinguish data used to develop a system from data used to evaluate it and data received during operation. These distinctions matter because evidence drawn from one population may not justify a conclusion about another.

Why documenting AI data resources matters

AI results reflect the data behind them, so unexplained data produces unexplained results. A business that cannot say where its data came from, how current it is or what it was meant for will struggle to defend an output to a client, a regulator or its own staff. Data documentation also protects against quiet drift in meaning: a field is redefined, a source stops being updated, or information collected for one purpose is reused for another. The cost of discovering such problems after deployment, including rework and lost confidence, usually far exceeds the effort of recording them early. Clear data records also help privacy and security colleagues, because retention, disposal and sensitivity questions can be answered from one place.

How to implement control A.4.3

Aim for a description a reviewer could use to judge whether the data is suitable, not a catalogue of file names. Data descriptions are most valuable where results depend on them, so begin with the sources that influence important outputs and widen the effort as needs become clear.

1. Identify the data used at each stage of one system, separating data for development, for evaluation and from live operation.
2. For each source, record origin, owner, last update and the purpose it was collected for.
3. Note how data is labelled or categorised, who did it and what quality checks were applied.
4. Record known limitations such as gaps in coverage, imbalance or possible bias, in plain language.
5. Connect each source to retention and disposal rules, and to privacy or confidentiality requirements.
6. Test the record by asking a colleague outside the project whether they can tell which data supports which conclusion.
7. Update the description whenever a source, preparation step or intended use changes.

Illustrative manufacturing example: images change with the product

Illustrative BPO example: historical calls have a different purpose

A BPO provider receives historical call transcripts from a client to evaluate an AI summariser. The transcripts were previously edited for training and omit some difficult interactions. If the provider describes them simply as customer call data, reviewers may mistake them for a representative operating sample.

The provider records the source, preparation history and intended evaluation use to the extent known. Missing information is made visible and considered in the conclusion. It does not invent provenance or represent incomplete supplier information as verified fact.

Connect documentation with data controls

A.4.3 is a resource-information control. The data theme addresses controls for acquisition, quality, provenance and preparation. The resource record should link to relevant evidence rather than duplicate every operational detail.

For example, an evaluation record may explain how a dataset was selected and prepared, while the resource description identifies its role and limits. Clear links help someone understand which version supported a result without maintaining conflicting copies of the same information.

Keep the record current enough for decisions

Data can change without a new product name. An updated source, revised labelling method or different population may affect the evidence. Determine how relevant changes are recognised and reflected in the documentation.

Protect sensitive information while retaining useful descriptions. A data-resource inventory need not expose all underlying personal or confidential data to everyone who reads it. The purpose is to support authorised understanding and decisions, not create unnecessary access.

Evidence and common mistakes