Data for AI systems: the five controls of ISO 42001 Annex A.7

A model trained on skewed, outdated or unlawfully obtained data produces outputs with exactly those defects. No amount of clever architecture fixes that. Annex A.7 of ISO 42001 addresses this at the source with five controls on data for AI systems: data management for development (A.7.2), acquisition of data (A.7.3), data quality (A.7.4), data provenance (A.7.5) and data preparation (A.7.6). This article walks through them the way an auditor does: what is required, which questions to expect and where things go wrong in practice.

What Annex A.7 covers

Annex A of ISO 42001 is organised into domains. The data domain sits between the controls on the AI system life cycle (A.6) and the information for interested parties (A.8), and that is no accident. The data determines what the system can do, and the documentation about it determines what you can explain to users and regulators. As with all Annex A controls, the risk assessment and the Statement of Applicability determine which controls apply. For organisations that develop or adapt AI systems, all five are almost always in scope. Organisations that only consume ready-made AI services do not escape entirely either: a connected knowledge base or a set of fine-tuning examples is also data for an AI system.

A.7.2: data management for development

The first control asks for documented, working processes for managing the data used to develop or improve AI systems. In an interview, an auditor will ask, for example, how training, validation and test data are separated and how leakage of test data into training is prevented. That sounds technical, but the consequence is very practical: with data leakage between those sets, you measure performance the system will not deliver in production.

A second recurring question concerns reproducibility. Can you repeat a training run with exactly the same data? That requires version control on datasets, with a recorded link between data version and model version. In organisations where data management is informal, we keep finding the same deviation: there is no procedure for assembling and splitting datasets, and nobody can reconstruct afterwards which data a model was trained on. The suitability of the data should also be assessed per project: is this data relevant to the purpose, representative of the target population and checked for harmful bias?

A.7.3: acquisition of data

The second control is about where you obtain data and whether you are allowed to. For every data source, a legal basis should be recorded, certainly when personal data is involved. For third-party data, the standard expects due diligence: where does this data come from, how was it collected, what is its quality and does the collection comply with the law? Contracts with data suppliers should cover usage rights, restrictions and quality commitments.

The sharpest example in practice is scraped or publicly available data. Publicly findable does not mean freely usable. An auditor wants to see that the use of such sources was reviewed legally and ethically before the data entered a training pipeline. The common deviation here is predictable: data is collected ad hoc, without a recorded legal basis and without prior review. That is more than an audit finding. It can also mean a model has to be retrained because its foundation does not hold up.

A.7.4: quality of data

Control A.7.4 asks for defined quality requirements for the data that AI systems use, and for demonstrable compliance with them. Useful criteria are accuracy, completeness, consistency across sources, timeliness and representativeness. The catch is in the word demonstrable. Quality criteria on paper are quickly written; the auditor asks about measurements, thresholds and what happens when a threshold is breached.

In a mature setup, automated quality checks are built into the data pipeline, with alerts to the team when quality drops below the agreed level. The most common deviation is that quality is only assessed during development. After go-live the incoming data changes, and a system that ran on good data last year can be working on polluted input today without anyone noticing. Quality monitoring should therefore continue into the operational phase, and identified issues should be documented, including their effect on the system's outputs.

A.7.5: data provenance

Data provenance is regularly confused with data quality, but it is a subject of its own. Provenance is about the history of the data: which source it comes from, how it was collected, which transformations were applied and who touched it when. The standard asks for a documented process to record that provenance throughout the life of the data and the AI system.

The litmus test we use as auditors: pick a random dataset from the training pipeline and ask the team to trace it back to its original source, including every intermediate step such as cleaning, aggregation and anonymisation. If that fails, there is work to do. Provenance records also need to keep up when data is supplemented or corrected; a register that was never updated after its first delivery does not count as a working process in an audit. Good provenance records make it possible to reason back from a model output to the source data, which saves a great deal of time during incidents and regulator inquiries.

A.7.6: data preparation

The last control covers everything that happens to data before a model sees it: cleaning, labelling, augmentation and feature engineering. The standard asks for documented criteria for choosing preparation techniques. Why were missing values handled this way? Why these labelling instructions?

Labelling deserves specific attention here. If you label manually, you need labelling guidelines, trained annotators and quality control, for example by measuring agreement between annotators. Without that control, a label is the opinion of an individual annotator, and that opinion trains the model. Data augmentation should also be assessed for the risk of introducing artefacts or bias. The deviation we see most often here: the preparation happened, but none of it was documented. The result is a model for which nobody can explain how the training data came about.

What the auditor requests

The common thread through all five controls is the same: procedures on paper, and evidence that they work. In concrete terms this means a data management procedure for AI development, documentation per dataset such as datasheets or data cards, recorded legal bases and due diligence files for external data sources, quality criteria with corresponding measurements, provenance records with transformation logs, and documentation of labelling and preparation decisions. The internal audit module of our platform contains this guidance per control, with interview questions and expected documents, so you can run the internal audit on A.7 before the certification body arrives.

Start with the model you already have

Our advice for anyone starting out: take the most important AI system currently in operation and answer the five questions of this domain for that single system. Where does the data come from, is its use lawful, has the quality been measured, is the provenance traceable and is the preparation documented? The gaps that become visible are almost always the same gaps that apply to the other systems. That turns the approach for the rest of the portfolio into repetition rather than reinvention.