ISO 42001 Annex A.7.5: Preserve the Provenance of AI Data

What control A.7.5 requires in practice

Control A.7.5 asks the organisation to define and document a process for recording data provenance, meaning the history of the data used in its AI systems, across the life of the data and of the system. The emphasis is on a process, not a one-off label. Annex B guidance, drawing on a data quality standard, says a provenance record can cover how data was created, updated, transcribed, abstracted, validated and handed over, and that sharing without transfer of control and transformations can also count. It adds that, depending on source, content and context, the organisation should consider whether the provenance itself needs verifying. The outputs are a documented recording process and records for actual datasets that let a reviewer follow the history to the version really used.

Trace meaningful changes, not just the first source

Annex B.7.5 considers creation, updates, transformations, validation, sharing and changes in control. It also asks whether provenance verification is needed according to source, content and use. The guidance must be considered under clause 6.1.3(e), with implementation tailored under B.1.

A practical provenance process identifies which events matter for interpretation and how they are recorded. A source name is a start, but may not explain filtering, relabelling or other changes that materially affect the data. Keep the history connected with the version actually used.

Why control A.7.5 matters to the business

When an AI result is questioned, the first thing people ask is what the model was fed and how that material changed on the way. If the history stops at the supplier's name, nobody can say whether a filter, a relabelling or a merge altered the meaning. That uncertainty slows investigations, weakens evaluation results and makes it hard to answer customers or regulators with confidence. A sound provenance practice also discourages quiet copying of datasets between teams. Auditors favour this control because it is easy to test: pick a dataset behind an important result and ask for its story. Gaps become obvious immediately, and so does good practice.

How to implement control A.7.5

Keep the method simple enough that people will really use it. Resist the temptation to adopt heavy tooling first; a modest record that people maintain consistently serves the control better than an elaborate system that is bypassed whenever a deadline looms or a team changes hands.

1. Decide which events change the meaning of data in your context, such as filtering, relabelling, merging or transfer.
2. Define what is recorded for each event and who records it, including when data moves between teams or to a supplier.
3. Choose a maintainable place for the record that stays attached to the dataset version rather than to a person's files.
4. Decide when claims about origin need checking, based on the source's reliability and the consequence of a wrong claim.
5. State openly where history cannot be established, and assess what that means for the use.
6. Test the process on one dataset behind an important evaluation and see whether a reviewer can follow it unaided.
7. Include provenance in handover steps whenever ownership or storage changes.

Illustrative construction example: transformed images lose their context

Illustrative BPO example: labels change during preparation

A BPO provider uses client records labelled as routine or complex enquiries. During preparation, a team combines several categories to simplify an evaluation. The final dataset retains the client's name but not the category change.

A later assessment assumes that the labels reflect the client's original classifications. Provenance should make the transformation visible so the evaluation's meaning can be understood. Recording only who supplied the file would miss the event that changed its interpretation.

Define responsibility for the record

Identify who records relevant provenance information and where it follows the data. Shared and externally supplied data need attention as well as internally created material. A transfer between teams should not break the connection to important history.

Use existing data-management arrangements where suitable. The control does not mandate a blockchain, a particular metadata standard or one software architecture. Choose a method that can be maintained and used to answer the organisation's questions.

Decide when to verify provenance

A supplier's description can be useful, but its reliability and completeness may need examination. The guidance makes verification contextual. Consider the significance of an unsupported origin or transformation claim to the AI use and its consequences.

If provenance cannot be fully established, state the limitation and assess its effect. Do not invent history or treat a polished supplier record as conclusive evidence. The appropriate decision may involve further information, additional evaluation or restrictions on use.

Evidence and common failures