ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The ISO 42001 data controls in Annex A.7 are where AI governance meets the raw material of every model: data. Biased, unlicensed or poorly documented data produces unreliable systems, and auditors know it.
Annex A.7 asks you to manage data for AI systems deliberately: why you use it, where it comes from, how good it is, where it has been and how it was prepared. Each of those questions needs a record.
This guide walks through the controls and the evidence that satisfies them. For the full set of control areas, see our ISO 42001 controls guide.
Free gap assessment
How much of ISO 42001 could you evidence today?
Score every clause and Annex A control of the AI management standard, free, and see where the programme really sits.
Run the free ISO 42001 gap assessment → or View premium report sample
Annex A.7 is titled data for AI systems. It contains controls on data for development and enhancement of AI systems, acquisition of data, quality of data, data provenance and data preparation.
It sits alongside privacy and information security controls rather than replacing them. A dataset can be secure and lawful and still be unfit for the purpose of a model, which is the gap A.7 addresses.
Like all Annex A controls, each applies according to your risk assessment and Statement of Applicability.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 38 AI risk scenarios, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
The official standard is summarized at ISO/IEC 42001:2023.
The first control asks you to define, document and implement data management processes related to AI system development. In practice that means rules for how data is selected, used, stored and retired during development and later improvement.
Write a short data management procedure for AI: roles, approved sources, handling rules, retention and review. Tie it to your existing data governance framework where one exists.
Our guide to the data governance maturity model helps you judge how far your current practice reaches.
Document how you acquire data: collected from users, purchased, licensed, scraped, generated or provided by customers. Record the legal basis, licence terms and any restrictions on use.
Check that you are permitted to use the data for training. Contracts, terms of service and privacy notices may limit it, and the risk of unlicensed training data is both legal and reputational.
Keep an acquisition record per dataset: source, date, owner, terms and approval.
Good records here make the ISO 42001 data controls easy to evidence.
Define what quality means for each use: completeness, accuracy, representativeness, timeliness, consistency and freedom from known bias. Set measurable criteria and check them before use.
Quality is use-specific. A dataset that is fine for one task can be wrong for another. Record the intended use alongside the quality results.
See our guide to AI data quality risk for the failure modes to test for.
Document the quality threshold you accept and who accepted it, because decisions about data quality are risk decisions.
| Control focus | What to document | Typical evidence |
|---|---|---|
| Data management for AI | Rules for selection, use and retirement | Data management procedure |
| Acquisition | Source, legal basis and terms | Acquisition record per dataset |
| Quality | Criteria and results for the intended use | Quality report |
| Provenance | Origin, lineage and owners | Dataset register and lineage records |
| Preparation | Cleaning, labelling and splitting methods | Preparation documentation and versioned code |
Provenance means knowing where data came from and what happened to it: origin, transformations, owners and movements. For training datasets, record sources, versions and lineage.
This supports reproducibility, audits, bias investigations and legal responses. If a customer asks which data trained a model, you should be able to answer.
Tools such as data catalogues and lineage trackers help, but even a well-kept register meets the intent if it is accurate and maintained.
Preparation covers cleaning, labelling, augmentation, filtering and splitting into training, validation and test sets. Each step can introduce error or bias, so document the methods and criteria.
Record who labelled data and how quality was checked. Label quality often limits model quality, and auditors may ask how disagreements were resolved.
Keep the preparation code or configuration under version control so you can reproduce the dataset.
Personal data in training sets triggers privacy obligations. Run a privacy review for each dataset and apply minimisation, retention and security measures. Our guide to DPIA for AI explains when a data protection impact assessment is needed.
Security controls protect datasets from tampering and theft. Poisoned data is an AI-specific risk, so restrict write access and monitor changes.
Align the work with your information security system, and with ISO 27001 if you hold it.
Treat privacy review as part of the ISO 42001 data controls, not a separate exercise.
Unrepresentative data is one of the main causes of unfair outcomes. Check whether your data covers the groups and conditions the system will face, and record gaps.
Pair data checks with outcome testing after training. Our AI bias testing guide shows methods.
If you cannot fix a data gap, document the limitation and apply mitigations such as human review.
If suppliers provide datasets or models, include data requirements in contracts: provenance, licensing, quality evidence and notification of changes. Annex A.10 covers supplier relationships.
If customers provide data, define how you may use it. Using customer data to improve models without clear permission creates legal and trust problems.
Keep these terms visible to the engineers who use the data.
Expect requests for the data management procedure, a dataset register, acquisition records, quality reports, provenance records and preparation documentation for a sampled system.
They may ask a data scientist to explain how a dataset was chosen and checked. Consistent answers that match the records are the best evidence.
Our internal audit guide shows how to rehearse this sampling.
A dataset register is the simplest way to evidence several controls at once. List each dataset with owner, source, purpose, legal basis, quality results, version, location, retention and linked AI systems.
Update it when datasets change. A register that stops at launch day misleads, so assign a person and review date.
This register also feeds your AI inventory and risk assessment.
Typical gaps are datasets with no recorded source, no quality criteria, unknown licence terms and preparation steps that live only in a notebook.
Another is covering only training data. Data used in evaluation, fine-tuning and retrieval can affect behavior and need control too.
A third is ignoring data drift after deployment. Quality does not stop at release, so monitoring should include data.
Our toolkit includes a dataset register template, so the ISO 42001 Toolkit saves you building it from scratch.
A small team can run the ISO 42001 data controls with a dataset register, a short procedure and a review step in the release gate. A large organization may add data stewards and catalogues.
Start with the datasets behind your highest-risk systems. Document those thoroughly, then extend to the rest.
The goal is traceable, fit-for-purpose data, not perfection.
Your risk assessment decides which A.7 controls apply. Record each control as included or excluded, with a reason, in the Statement of Applicability.
For each included control, name the procedure and evidence. A simple three-column view of control, procedure and evidence makes audits straightforward.
Review it when your data sources or models change.
Focus first on the ISO 42001 data controls that cover your highest-risk systems.
Systems built on foundation models raise new data questions. You may not control the base model’s training data, but you do control prompts, fine-tuning data and retrieval sources.
Treat retrieval corpora and fine-tuning sets as datasets: register them, check quality and licence, and control who can change them. A poisoned or outdated document in a retrieval index can change what the system says.
Record what you know about the supplier’s training data and what you do not. The gap is a risk to assess, not a detail to hide.
Applying the ISO 42001 data controls to these sources closes a gap many teams overlook.
Week one: list the datasets behind your in-scope systems and create the register. Week two: write the short data management procedure and quality criteria.
Week three: fill in provenance and acquisition records for the highest-risk datasets. Week four: add a data check to the release gate and train the team.
After the month, review the register monthly and add each new dataset at the point of acquisition. That habit is what keeps the controls alive.
They apply according to your risk assessment and Statement of Applicability. Systems that use or train on data usually need most of them.
No, but it is an efficient way to evidence several controls together.
No. It complements privacy and security controls by focusing on suitability and traceability of data for AI.
Apply the same questions: how it was generated, from what source data, how quality was checked and what limits it has.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026