A.7.6 Data preparation: requirements and evidence

What ISO 42001 A.7.6 data preparation asks for in plain terms

If your AI team prepares training, validation or evaluation data by hand or through scripts, A.7.6 asks you to do two things: define and document the criteria you use to choose which data preparation steps apply to a dataset, and document the preparation methods you actually use. Preparation covers cleaning, labeling, normalization, splitting and similar transformations. The control does not dictate which techniques to use. It requires that the reasons for your choices and the methods themselves are written down and retrievable, so someone can reproduce the result later.

The risk A.7.6 addresses is simple to state and expensive to live with: a model or evaluation result that nobody can reproduce or explain because preparation choices were never recorded. Hard-to-audit situations usually look ordinary. Cleaning logic lives in an exploratory notebook that was edited without version history. Labeling rules exist only in the heads of two annotators. A train and test split is regenerated with a different random seed or a changed filter between runs, so the reported metrics drift and no one can say why. An assessor will ask which steps were chosen, why, and whether the same steps were applied to the data behind the reported results.

The organization owns this control. It must decide its preparation criteria, approve the methods and keep the records current. An implementation partner such as DeployOpen can help prepare the systems and evidence, for example version-controlled preparation pipelines, labeling guidelines and recorded split parameters, but DeployOpen does not decide your criteria or issue reports. Only an independent certification body issues an ISO/IEC 42001 certificate. As a first action, confirm which datasets feed your models and evaluations, then ask who can change each preparation step and where the change is recorded.

Which datasets, pipelines and teams fall under ISO 42001 A.7.6 data preparation

Scope for A.7.6 Data preparation starts with the AI systems the organization develops or provides, then follows the datasets and preparation steps those systems depend on. The decisions below determine what the statement of applicability must cover, which teams and third parties need to be documented, and what an auditor will sample.

AI systems in the statement of applicability

Start with the list of AI systems the organization develops, provides or uses, then decide which ones require A.7.6 in the statement of applicability. Under clause 6.1.3, each Annex A control is included or excluded with a justification, so an exclusion for a system that trains on its own data needs a documented reason. Scope should follow the AI systems the organization develops or provides. Confirm the boundary with the system owners before drafting the justification, because an auditor will test whether every in-scope system has a preparation record.

Preparation steps that count

Treat every transformation between raw data and model input as a preparation step. This includes cleaning, deduplication, labeling, normalization, feature encoding, and train, validation and test splitting. Each step needs a documented method and selection criteria, such as why duplicates are removed by exact match rather than fuzzy match. Steps performed in notebooks or ad hoc scripts are still in scope and must be recorded, not left to individual judgment.

Pipelines and datasets that feed training

Map every pipeline that produces a dataset used for development, fine-tuning, evaluation or retrieval indexing. Retrieval corpora and evaluation sets are easy to miss, yet they are prepared data too. Include versioned outputs of each pipeline so a reviewer can trace a given model version back to the preparation run that produced its inputs. Ask engineering for a list of scheduled jobs and manual runs that write to shared storage.

Internal teams with access to prepared data

List every internal team that edits, approves or consumes prepared data, including data engineering, data science, product owners who adjust labeling rules and security staff with read access. Each role should map to documented responsibility for the preparation method. Access that is broader than the role needs makes it harder to show who changed a split or a cleaning rule, so record access groups alongside the preparation records.

Third-party labelers and data vendors

External labeling firms and data vendors often apply preparation steps before data reaches the organization. Where a supplier labels, filters or splits data, the organization still needs its criteria and method documented, and the supplier's instructions must be part of the record. Check contracts for the labeling guidelines, quality checks and whether subcontractors are used. Responsibility for the preparation outcome does not transfer simply because a supplier performed the work.

Justifying scope boundaries

Where a dataset, step or team is excluded, write the reason in clause 6.1.3 terms: the control is not needed because the system does not use that data, or another control already covers the risk. Vague exclusions such as 'not applicable to this team' tend to draw follow-up questions. Review the justification whenever a new AI system, data source or labeling vendor is added, and confirm the change with the internal audit owner before the statement of applicability is reissued.

How to define preparation criteria that a reviewer can follow

A criterion explains why a data preparation step is chosen, and a method explains how the step is carried out. Under A.7.6, a reviewer needs both. For example, a criterion might be that records failing a documented validity rule (such as a required field missing or a date outside the collection window) are excluded from training. The method is the exact procedure that applies that rule: the script or tool, its parameters, its version and the order in which it runs. Teams often document the method and skip the criterion, which leaves an assessor unable to tell whether a step was a deliberate choice or an accident of the pipeline. Write each criterion as a sentence that names the condition, the action and the reason, then attach the method that implements it.

Criteria should trace back to the intended purpose of the AI system. A preparation step that makes sense for a credit scoring model may distort a fraud or medical triage model, so the purpose statement recorded under the impact assessment and design controls is the reference point for every decision. Criteria also depend on the quality and provenance records kept under A.7.4 and A.7.5: a deletion rule should cite the quality dimension it protects, and a transformation should point to the lineage entry it modifies. Confirm with your own data owners which of these records already exist, so the preparation criteria reference them rather than duplicate them. The NIST AI Resource Center crosswalk, contributed by Microsoft and not an endorsement by NIST, maps AI RMF MAP 2.3 (scientific integrity and TEVV considerations, including experimental design and data selection) to B.7.6. Use it as a reference for the implementation guidance, and check the mapping against the standard itself before relying on it in an audit file.

For reproducibility, record the method in enough detail that a second engineer could rerun it on the same input and obtain the same output. Pin tool versions, store configuration files in version control with protected branches so changes need approval, and keep the random seed used for any splitting step. A useful check is to rerun the pipeline on a sample from an earlier snapshot and compare the outputs. Ask your implementation team to show where each criterion is stored, who approves changes to it and how a change to a split ratio or labeling rule would be traced to a specific model version.

How an assessor tests A.7.6 and what they ask to see

This table sets out what an assessor examines for A.7.6 Data preparation, the evidence they request for each point, and the findings they commonly raise. Read it as a checklist for building a traceable preparation record before the assessment starts, and confirm the wording of findings with your certification body.

Assessor examines	Evidence requested	Common findings
Documented criteria for choosing preparation steps	Approved criteria document with version history, showing why cleaning, labeling, normalization and splitting are used for each dataset type	Criteria are generic, unapproved or not linked to any specific AI system or dataset
Documented preparation methods	Method descriptions, scripts or pipeline definitions under version control, with named owners and approval dates	Methods exist only in analyst notebooks or personal files, with no record of which version ran
Sample of preparation runs traced to criteria	For a selected sample of runs, the run log, input dataset identifier, applied steps and the criterion each step satisfies	Runs cannot be matched to a criterion, or steps applied differ from those documented
Consistent application of splitting rules	Split definitions (for example, seed, ratio and stratification logic), logs showing the same rule applied across training, validation and test sets	Split seeds or ratios vary between runs without a documented reason, or test data leaks into training preparation
Consistent application of labeling rules	Labeling guidelines, annotator instructions, sample label reviews and records of disagreements resolved against the guidelines	Labeling guidance is outdated, or labelers applied different conventions to the same data
Reproducibility of results	Evidence that a sampled run can be repeated from its recorded inputs, code version and parameters, with matching outputs	Outputs cannot be regenerated, or the assessor finds undocumented manual edits between steps
Changes to preparation steps over time	Change records with reasons, approvals, impact notes and the datasets or models affected by each change	Steps changed without records, or prior models were built on preparation that no longer matches the documented method

Implementing A.7.6 data preparation in sequence

This sequence turns A.7.6 into a working record: each preparation step is inventoried, justified, versioned and proven reproducible, so an assessor can trace how a training or evaluation dataset was produced. The organization owns each output, and an independent auditor tests it.

Inventory preparation steps for each AI system
The data owner and the AI system team list every preparation step applied to each dataset used for development, enhancement or evaluation of an AI system. Typical steps include cleaning, deduplication, labeling, normalization, feature transformation and train, validation and test splitting. Record the input dataset, the output dataset and the system each step serves. The closing output is a preparation register with one row per step, and the team confirms that no step runs outside the register.
Write selection criteria tied to intended purpose
For each step in the register, the AI governance owner and the technical lead write the criteria that decide whether the step is applied and how. Each criterion links to the intended purpose of the AI system and to the data quality requirements set under A.7.4. Explain why a step is excluded where a common step is not used. The output is a criteria record that a reviewer can read without the engineers present. Confirm with the team that the criteria were written before results were reviewed, so the record reflects the original design.
Document methods and tool versions per step
The engineers document the method used for each step, including parameters, thresholds, random seeds where splitting is random, labeling guidelines and the library or tool name and exact version. Where a human labeler applies the step, record the guideline version and who performed the work. Store this as a method sheet attached to the preparation register. The output is a method sheet per step. The check is that a second engineer can read the sheet and name the tool version without asking the author.
Place preparation code under version control
Keep all preparation scripts, configuration files and split definitions in a version control system such as a self-hosted GitLab instance. Enable protected branches so the main branch cannot be pushed to directly and changes merge only after review by a named reviewer. Keep force pushes disabled unless a documented exception applies. Run a static analysis tool such as Semgrep Community Edition in the pipeline to catch common coding faults in preparation code. The output is a repository with review history that ties every dataset version to a commit.
Run a reproducibility check on the dataset and split
Using only the recorded inputs, the preparation register, method sheets and a tagged commit, a second team member rebuilds the prepared dataset and the train, validation and test split from scratch. Compare the rebuilt output with the stored version by checksum or record count, and log any difference along with its cause. Repeat the rebuild after any change to a step. The closing output is a reproducibility test result, signed off by the data owner. Ask your independent auditor which evidence format they accept for this test before you finalize the template.

Evidence that satisfies A.7.6 and how to keep it current

A.7.6 is tested by whether the criteria and methods for data preparation are documented and whether a reviewer can rerun a preparation and get the same result. The six artifacts below work together: the criteria explain the choices, the method register and code record how they were applied, and the run, split and approval records show that each dataset was prepared the same way and changed only through review.

Preparation criteria document

This is the written rule set that explains why a cleaning, labeling, normalization or splitting step is chosen for a given dataset and model purpose. It should name the acceptance conditions for each step, such as how missing values are handled and what label agreement is required. An assessor will check that the criteria exist, that they match what the team actually did, and that they were reviewed after the AI system's intended purpose or data sources changed. Confirm the owner and review cycle are written into the document itself.

Register of preparation methods

Keep a register listing each preparation method in use, its version, the library or tool that implements it, and the datasets it has been applied to. A version change in a normalization routine or labeling guideline can alter model inputs, so the register should show which version produced which dataset. Review the register whenever a tool is upgraded and record who approved the change. This makes it possible to explain a past result without guessing which method was in place.

Preparation scripts under version control

Store every preparation script or notebook in a Git repository with protected branches so that changes to preparation logic must pass review before they are merged. Protected branches can block direct pushes and keep force pushes disabled, which protects the history auditors will read. Tag the commit used for each released dataset so the exact code can be retrieved later. Confirm that notebooks are exported or pinned so that hidden cell state does not change results.

Run records with inputs and outputs

Each preparation run should record the input dataset identifier and hash, the parameters used, the software environment, and a hash or summary of the output. Observability tools can capture each step with timing, inputs and outputs, which gives a reviewer a trace rather than a reconstructed account. Rerun a sample of runs after material changes and compare output hashes. Any difference should be explained in the record before the dataset is used again.

Split definitions and seed records

Record how training, validation and test sets were divided, including the rule, the proportions, the stratification keys and the random seed. Without the seed and the split definition, the same data can produce different partitions and different reported performance. Store the split definition alongside the dataset version and check that no test records appeared in training after any re-preparation. Revisit the split record whenever the source data is refreshed, since the old partition may no longer match.

Approval records for changes

Keep a dated record for each change to criteria, methods, scripts or splits, showing the reason, the reviewer, the impact on datasets already prepared and the decision. Link each approval to the merge request or review ticket so the change history is traceable. Set a recurring review, and trigger an earlier one when a new data source is added or the system's purpose changes. Ask whether your approval workflow requires a named accountable role for AI data decisions.

What meeting A.7.6 costs in money and effort

This table breaks the cost of meeting A.7.6 into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where self-hosted open-source tooling saves license spend but not staff effort. No prices or durations are stated because none are supplied for this control.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Criteria and method documentation	One-time, then reviewed periodically	Number of datasets, number of preparation steps, and how many teams must agree on the criteria	Write one standard set of criteria for cleaning, labeling, normalization and splitting, then record only exceptions per dataset
Engineering time to version and rebuild pipelines	One-time build, recurring upkeep	Whether preparation runs as scripts in a repository or as manual steps in notebooks	Keep preparation code in version control with protected branches and reviewed merges, so each run can be rebuilt from a tagged commit
Reproducibility testing	Recurring, at each material change	Pipeline complexity, randomness in splitting, and the number of model versions that must be reproduced	Fix random seeds and split logic in code, then rerun a reference preparation and compare outputs automatically in CI
Tooling and license spend	Recurring for commercial tools, usually none for open source	Commercial lineage or labeling platforms versus self-hosted open-source components	Self-hosted open-source tools remove license fees, but staff time to install, patch and operate them remains a cost to plan for
Evidence upkeep	Recurring	How often datasets, criteria and preparation records change, and how well records are linked to model versions	Store preparation parameters and run logs alongside each model release so evidence is generated during work, not reconstructed later
External review	Optional, periodic	Scope of the review, whether it covers only documentation or also rebuilt outputs, and the reviewer's day rate	Ask the reviewer to test a sample rebuild rather than read documents alone, and agree the scope in writing first
Auditor sampling time	Recurring, per assessment cycle	How many datasets and model versions the auditor samples and whether records are easy to find	Index preparation records by dataset and model version so the auditor can trace one sample without assistance

Who does what for A.7.6: your team, a partner and the auditor

Your data and engineering team owns A.7.6. The organization must define and document the criteria for choosing data preparation steps and the methods it uses, and those decisions belong to people who understand the training, validation and operational data for each AI system. A partner can draft documents, but the criteria only count as your controls once your accountable owners review, approve and enforce them.

Selection criteria: Decide when cleaning, labeling, normalization, deduplication and splitting are applied, and why each step fits the intended purpose of the system.
Method records: Name the tools, parameters and versions used for each preparation step, and state who may change them.
Approval gates: Assign an owner who signs off preparation changes before they reach training or evaluation data.
Labeling rules: Define who labels data, the guidance they follow and how disagreements are resolved.
Ongoing ownership: Keep the criteria current when datasets, models or business uses change.

Before accepting any draft, confirm that your own staff can explain each preparation step and point to the approval that authorized it.

Common gaps that fail A.7.6 and how to close them

Most A.7.6 findings are not about missing preparation steps. They come from preparation that happened but cannot be reproduced, explained or tied to a trained model. The cards below cover the gaps that appear most often and the evidence that closes each one.

Preparation kept in unversioned notebooks

Cleaning, filtering and encoding often live in notebook cells that are edited in place and never committed. An assessor asking how a training set was produced gets an answer that changes with whoever last ran the notebook. Move preparation code into a versioned repository, run it as a scripted pipeline, and store the commit hash with each output dataset. Check that a clean checkout can regenerate the same dataset.

Criteria written after the fact

A.7.6 asks the organization to define its criteria for selecting data preparations before or as it applies them. Criteria written once a model underperforms look like justification rather than design. Record the selection criteria in a dated document approved before preparation runs, and reference that document from each preparation record. Ask whether the approval date precedes the first run.

Splits that change between runs

Train, validation and test splits generated with an unfixed random seed produce different partitions each time the pipeline runs. Results then cannot be reproduced, and test data can leak into training across runs. Fix and record the seed, the split ratios and the stratification keys in the pipeline configuration. Store the resulting split membership lists with the dataset version so an assessor can confirm the same records were used.

Labeling rules held by individuals

When labeling guidelines exist only in a labeler's memory or in chat messages, label consistency cannot be shown and changes in judgment go unrecorded. Write a labeling guide with definitions, examples and edge cases, version it, and track inter-annotator agreement on a sample. Record which guide version each labeled record was produced under.

Third-party preparation without a documented method

Vendors or labeling services that clean, enrich or normalize data on the organization's behalf can change methods without notice. The organization still owns A.7.6 for that output. Require the provider to document each preparation method and its version in the contract or statement of work, and to deliver the method record with each dataset. Confirm these terms before signing, because a provider's internal records are not the organization's evidence.

No link between dataset version and trained model

If a model cannot be traced to the exact preparation run and dataset version that produced its training data, the preparation criteria cannot be checked against what the model learned from. Record the dataset identifier, preparation pipeline commit, split seed and parameters in the model's training metadata. Confirm that an assessor can start from any deployed model version and reach its preparation record without asking the team to reconstruct it.

Questions buyers ask about ISO 42001 A.7.6 before hiring help

How much effort does ISO 42001 A.7.6 data preparation take?

The effort depends on how many AI systems use prepared data, how many preparation steps each one runs, and whether those steps are already scripted. A.7.6 asks the organization to define and document its criteria for choosing data preparation steps and the methods it uses, such as cleaning, labeling, normalization and splitting. If a team already runs versioned pipelines with written rules, the gap is mostly documentation and evidence. If preparation is manual, undocumented or varies by engineer, the work includes standardizing methods before anything can be recorded. No effort figure is supplied for this control, so ask any provider to base its estimate on a written inventory of your datasets and pipelines.

How long does it take to get ready for A.7.6?

No duration is supplied for this control, so treat any timeline you receive as an estimate that needs checking. The main drivers are the number of AI systems in scope, the maturity of current data pipelines, how much preparation logic lives in notebooks or ad hoc scripts, and how quickly the team can agree on selection criteria. Readiness also depends on the certification timing you plan, because the auditor needs to see the criteria operating over time, not only written once. Ask for a milestone plan with named inputs and owners before you accept any date.

What does the internal team need to provide for A.7.6?

The internal team owns the decisions and the records. It needs data owners who can state why each preparation step is chosen, engineers who can show the code and configuration that performs each step, and a reviewer who approves the criteria and changes. Expect to provide the list of datasets, the preparation methods in use, the rationale for splitting and labeling choices, and the version history that links a model to the data it was trained on. A partner can structure these records, but it cannot supply the business justification for your data choices.

Can our team implement A.7.6 without an outside partner?

Yes, an internal team can implement A.7.6 if it has data engineering and governance skills and the time to maintain the records. The control is about documented criteria and reproducible methods, so the work fits naturally into existing version control, pipeline and review processes. Teams that struggle usually lack a single owner for the criteria, or they have no way to reproduce past preparation runs. Before deciding, check whether you can rerun a preparation for a given model and show the same output, because that is the test an assessor will apply.

What can a partner do for A.7.6, and what can it not do?

A partner can plan the scope, set up self-hosted pipelines and version control inside your environment, document preparation methods and collect evidence. DeployOpen prepares systems, controls and evidence for assessments, and most engagements are fixed-scope with deliverables agreed in writing before work starts. A partner cannot decide your data policy, approve your criteria on your behalf, or issue the certificate. Only an independent certification body can certify your management system, so confirm that the body you plan to use accepts the evidence your partner prepares and that the two roles stay separate.

How does A.7.6 relate to the NIST crosswalk reference to AI RMF MAP 2.3?

The NIST AI Resource Center crosswalk maps AI RMF MAP 2.3, which covers scientific integrity and testing, evaluation, verification and validation considerations including experimental design and data selection, to B.7.6. That is the only AI RMF subcategory the crosswalk links to this control. NIST states that posting the crosswalk is not an endorsement, and the crosswalk is a mapping reference, not a substitute for the standard or an assessment. Use it to show that your data selection and experimental design records serve both frameworks, and confirm the mapping with the current NIST document before citing it to an auditor.

How DeployOpen scopes and prepares A.7.6 evidence

DeployOpen helps organizations set up the data preparation records, pipelines and evidence that A.7.6 asks for, inside their own infrastructure. The organization keeps ownership of its criteria and methods, and only an independent certification body can issue a certificate.

How we scope

Written scope lists which AI systems, datasets and preparation steps fall under A.7.6 before work starts.
Scope names the preparation methods to document, such as cleaning, labeling, normalization and splitting.
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.

How we build

Set up version-controlled records of preparation criteria and methods in self-hosted GitLab Community Edition.
Configure protected branches so approved preparation changes need review before they reach production pipelines.
Capture preparation runs and their inputs and outputs in Langfuse traces so each dataset version can be reproduced.

How we hand over

Deliver a documented preparation procedure with selection criteria, method descriptions and named owners for each step.
Provide reproducibility evidence: run logs, configuration history and a mapping of each dataset to its preparation record.
Hand over runbooks so the organization's own staff can maintain the records after the engagement ends.

How we support

Run review checkpoints with the organization's data owners and compliance lead before the evidence pack is finalized.
Ask your independent auditor early which preparation records they expect to sample, and confirm that list in writing.
Available retainers cover upgrades, periodic evidence refreshes and re-validation when preparation methods change.