ISO/IEC 42001 Annex A for Acquired Training Data: Data Controls (A.7) and Supplier Controls (A.10)

How Annex A fits into an AI management system audit

Annex A is a reference set of controls that you select against your AI risk assessment and justify in a Statement of Applicability (SoA). It is not a checklist that applies in full to everyone. ISO/IEC 42001:2023 sets requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS) for organizations that develop, provide or use AI [1]. Certification is optional and is carried out by independent certification bodies [2].

Annex A is normative, and Annex B gives implementation guidance for each control. Secondary sources commonly describe Annex A as 38 controls under nine objectives, numbered A.2 to A.10; ISO's catalogue page and Online Browsing Platform describe the standard, but the full text is paywalled [1][3]. Confirm the exact control titles and wording against your licensed copy before you quote them in an SoA. The numbering used below follows the commonly published control list.

For most teams that buy data, A.7 and A.10 carry the training-data load. A.4 (resources, including data resources) and A.6 (AI system life cycle) also reference data, so the auditor will often follow one dataset across several controls. If you exclude any A.7 or A.10 control in the SoA while training on purchased data, expect a nonconformity discussion.

A.7 controls mapped to purchased data

Each A.7 control asks a different question about the same dataset, and the evidence for purchased data differs from internal data at every step. Commonly published control lists title them as follows: A.7.2 data for development and enhancement of AI systems, A.7.3 acquisition of data, A.7.4 quality of data for AI systems, A.7.5 data provenance and A.7.6 data preparation.

A.7.2, data for development and enhancement. This is the policy layer: which data management processes apply to training, fine-tuning, evaluation and retraining. For acquired data, write down which uses each license permits and who can approve a new use. A fine-tuning set licensed only for internal evaluation is a common gap auditors find when the training pipeline reads from the same bucket.

A.7.3, acquisition of data. Auditors look for a documented acquisition process: the business need, the source, the legal basis, the approval and the contract. For third-party data, that means a signed license or data agreement, not a web form acceptance or a sample download. Keep the record of who approved the purchase and which risk and impact assessment it referenced.

A.7.4, quality of data. You define quality requirements and show they were measured. ISO/IEC 5259-2 provides a data quality model and measurable characteristics such as completeness, accuracy and consistency [4]. ISO/IEC 5259-3 sets requirements for a data quality management approach, and 5259-4 covers process, including labelling for supervised learning [5][6].

A.7.5, data provenance. You record where data came from and what happened to it. For acquired data, provenance starts at the supplier: the originating system (for example a Zendesk or Salesforce Service Cloud export, a Jira project, a document management system), the extraction date, the consent or contract basis, and any transformation done before handover.

A.7.6, data preparation. You document the preparation methods you applied: de-identification, deduplication, filtering, tokenization, labelling and train/validation/test splits. Keep the scripts or pipeline versions, not just a narrative. If the supplier did part of the preparation, such as redacting names and account numbers, record their method and your verification sample separately.

A.10 controls for data suppliers

A.10 treats your data supplier as a third party whose responsibilities must be allocated and whose output must meet your requirements. The same lists title the controls A.10.2 allocating responsibilities, A.10.3 suppliers and A.10.4 customers.

A.10.2, allocating responsibilities. Write a RACI across the AI life cycle that names the supplier's part. Who confirms the supplier held the right to license the data? Who performs de-identification? Who notifies whom if a data subject complaint or rights challenge arrives after delivery? The contract and the RACI should match.

A.10.3, suppliers. You need a process that makes sure services, products and materials from suppliers meet your approach to responsible AI. For a data vendor, that is due diligence before signing, contract requirements that carry your quality and provenance needs, acceptance testing on delivery, and periodic review. Your existing ISO/IEC 27001 supplier process covers security [7], but it rarely asks about consent basis, license scope or labelling accuracy, so extend it rather than reuse it as is.

A.10.4, customers. This control matters when you pass AI outputs or models downstream. If your license restricts how derived models or outputs may be used, your customer terms and documentation must reflect that. For more on contract limits that come from upstream customer agreements, see checking customer contracts and DPAs for training use.

The evidence pack auditors sample for one acquired dataset

Auditors usually pick one or two datasets and trace them from purchase to model, so build the pack per dataset. The structure below works as a register entry and links each artifact to the control it evidences.

Illustrative example: invented to show structure; it does not describe an available dataset.

Cross-link the register entry to your model cards and dataset documentation so the auditor can move from a production model back to a license in one step. The AI training data audit readiness guide covers the wider evidence pack regulators and customers request.

Supplier due diligence questions that satisfy A.10.3 and feed A.7

Good supplier diligence answers A.10.3 and simultaneously produces the A.7.3 to A.7.5 evidence, so you do not collect it twice. Ask each data supplier the following, in writing, before signing:

1. Which systems did the data come from, and over what time window?
2. What gives you the right to license it: ownership, customer terms, consents, or a prior license? Provide the relevant clause or consent text.
3. Does the data contain personal information, health information or minors' data, and what de-identification method was applied? How was a sample verified?
4. What quality measures did you compute, using what definitions? Can you map them to ISO/IEC 5259-2 characteristics [4]?
5. If labels exist, who produced them, under what guidelines, and what was inter-annotator agreement?
6. What transformations happened between the source system and delivery?
7. How will you notify us of a rights challenge, a correction or a withdrawal after delivery?
8. How is delivery controlled: access-controlled transfer, logging, and who can see the data in transit?

Keep the answers in the supplier file and copy the dataset-level facts into the provenance record. For the operational side of running this across a growing vendor list, see managing many data suppliers.

How A.7 and A.10 evidence serves other regimes

The same records that pass a 42001 audit also cover most regulatory disclosure asks, provided you structure them once. EU AI Act Article 10 requires high-risk systems trained on data to use data sets subject to governance practices that address data collection processes and the origin of data [8]. As of October 2026, Regulation (EU) 2026/1744 moved the high-risk start dates and amended Article 10 [10]; see the Article 10 data governance guide.

California AB 2013 requires developers of generative AI systems offered to Californians to post documentation about training data, including sources and whether data was purchased or licensed [9]. Those fields come straight from your A.7.3 and A.7.5 records. The training data disclosure comparison shows how one supplier record can feed AB 2013, the EU training-content summary and other disclosure regimes.

Teams already working to NIST AI RMF can map the same evidence; the NIST AI RMF guide for third-party training data covers that framework's Govern and Map functions. NIST AI RMF is voluntary and not a certification scheme, but the same evidence can be reused when the control mapping is explicit.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Where teams fail 42001 data and supplier audits

Most findings come from timing and traceability rather than missing policies. The recurring patterns:

• Retroactive approvals. Data arrived and was used before the A.7.3 approval or license was executed.
• Provenance that ends at the vendor. The record names the supplier but not the originating system, extraction window or consent basis, so A.7.5 is only half met.
• Quality thresholds without definitions. "Good quality" is asserted with no metric definitions; adopt data governance terminology and ISO/IEC 5259 measures [4][5].
• One-time supplier review. Auditors typically read A.10.3 as requiring ongoing oversight, so a single onboarding questionnaire with no review after renewal or a new delivery will draw a finding.
• Orphaned copies. Deleted or expired datasets still sit in eval caches, embedding indexes or notebooks. Tie access controls after delivery to the license register.

For the definition auditors typically apply, see data provenance. The compliance hub lists related regulation and standards guides, and the provenance guide covers source, rights and permitted use in more depth.

How SourceX supports buyers building 42001 evidence

SourceX sources operational datasets from US companies on request, such as support and sales histories, engineering records and documents, and manages the licensing process. Every dataset is rights-reviewed for ownership and consents, delivered under a license that defines records, uses, term and delivery, and comes with diligence materials covering source, rights, preparation and allowed use. Personal details are removed or replaced before delivery, the method is recorded and a sample is checked. You can describe the data your AI management system needs.

Request training data with 42001-ready records

If you are buying third-party data for an AI system in scope of ISO/IEC 42001, describe the dataset you need and the uses you plan. SourceX assesses data and licensing permissions with US suppliers, and nothing is contracted until the supplying company agrees. Start your request at SourceX for AI data buyers.