ISO 42001 Annex A.7.6: Choose and Document AI Data Preparation Methods
ISO 42001 control A.7.6 addresses defining and documenting criteria for selecting data preparation methods and the methods used. Preparation can make data usable for a task, but it can also change meaning. A routine cleaning step should not become an unexplained alteration to the evidence supporting an AI system.
What control A.7.6 requires in practice
Control A.7.6 asks the organisation to define and document two linked things: the criteria it uses to choose data preparation, and the preparation methods it then applies. Preparation means the work done to make raw data usable for an AI task. Annex B guidance mentions examining distributions, cleaning, filling missing entries, normalising and scaling values, labelling target variables and encoding categories as numbers, and notes that careless preparation can lead to system errors. The guidance also points out that the organisation should write down why it chose specific methods for a given task, not only which ones it used. The outputs are a documented selection rationale, a record of the methods and transformations applied to real datasets, and enough clarity that another competent person can explain the prepared data.
Choose the method from the task and data
Annex B.7.6 discusses preparation approaches such as examining distributions, handling missing entries, scaling, labelling and encoding. These are examples to consider, not a requirement to apply every technique. Clause 6.1.3(e) requires consideration of the guidance, and B.1 permits suitable implementation.
Explain why a method is appropriate for the data and intended task. The control's emphasis on criteria prevents the choice from depending entirely on a tool's default setting. A method suitable for one dataset can produce misleading results in another context.
Why control A.7.6 matters to the business
Preparation is where well-meant tidying can quietly change what data means. Replacing missing readings, merging categories or dropping awkward cases may make a pipeline run smoothly while removing the very signal the system needs. Documented criteria protect the business from outputs it cannot explain, and from results that cannot be reproduced when a team member leaves or a tool is updated. They also help when a client challenges a decision, because the reasoning is on record. Auditors look for evidence that preparation choices were deliberate and connected to quality requirements, rather than inherited from a software default nobody questioned.
How to implement control A.7.6
Choose each method for a reason you can state, and keep the record close to the data. Many teams rely on pipelines that apply transformations automatically, so the practical task is to make that automation understandable and to keep a trace of what it did, not to slow the work down with manual paperwork.
- Write the criteria for choosing preparation methods, tied to the task, the data type and the consequences of error.
- Before applying a method, check why entries are missing or unusual, using people who know the domain.
- Record the specific methods and transformations applied to each dataset, including settings and any tool defaults accepted.
- Compare quality results before and after preparation to see what information was lost or shifted.
- Link the record to provenance entries so the prepared version can be traced back to its source.
- Reassess earlier results whenever a preparation method changes, since a shift in outputs may come from the preparation rather than the model.
- Ask a second competent person to explain one material transformation from the records alone.
Illustrative manufacturing example: missing readings have meaning
A manufacturer prepares equipment data for an AI planning aid. A default process replaces missing readings with a typical value. However, missing readings sometimes indicate a particular operating state that matters to the intended prediction.
The team examines the reason for missingness and the effect of the proposed preparation. It documents its criteria and chosen response rather than assume that removing blanks always improves quality. Appropriate domain expertise helps distinguish an administrative gap from meaningful operating information.
Illustrative software example: categories are combined for convenience
A software team groups several customer enquiry categories into one label to simplify development. Some of the original categories have different consequences when the AI assistant gives an incorrect answer.
The preparation decision should consider whether the combined label preserves the distinctions needed for evaluation and use. If it obscures a consequential class, the team needs a different approach or a clearly limited claim. Fewer categories can make analysis easier while making the evidence less useful.
Record the criteria and what actually happened
A general procedure can explain how methods are chosen, while a dataset-specific record identifies the methods and transformations applied. Keep the relationship clear enough that a competent person can understand the prepared data and its limits.
The control does not prescribe a universal technical notebook or file format. Choose a maintainable record that fits the activity. Where automated pipelines apply transformations, the organisation still needs to understand their relevant purpose and effect rather than rely on unexplained automation.
Evaluate the effect on meaning and quality
Preparation should connect with data-quality requirements. Examine whether the result remains suitable for the task and whether significant information was lost or altered. Technical success of a transformation does not establish that the prepared data is appropriate.
Preserve the relevant history through provenance. If a result later proves misleading, the organisation should be able to identify how the data was prepared and which assumptions informed the decision.
Evidence and common mistakes
The required control outcome includes documented selection criteria and methods. Useful evidence can link those decisions with the prepared dataset, relevant checks and evaluation results. Test whether another competent person can explain a material transformation without guessing.
Common weaknesses include using defaults without considering the task, removing unusual cases because they are inconvenient and changing labels without recording the effect. Another is assuming that preparation automatically eliminates bias. The resulting system and consequences still need appropriate evaluation.
Where a preparation method changes during development or operation, consider its effect on earlier evidence and comparisons. A new output distribution may reflect the preparation change rather than a change in the model's underlying capability.
Frequently asked questions
Must every dataset use all preparation methods mentioned in Annex B?
No. Select suitable methods using defined criteria and document what is used for the task.
Are tool defaults an adequate selection rationale?
Not by themselves. Examine why the method suits the data and intended use, including the consequences of changing or removing information.
Does cleaning prove data is fit for purpose?
No. Evaluate the prepared data against relevant quality requirements and the system's intended task.
Examine a preparation choice that changes the evidence
Discuss AI data-preparation criteria with Sterling, including documentation and assessment interfaces. Agreed support can include Effivity ISO & GRC automation software. AI Risk & Impact Assessment helps teams connect data choices with consequences. See the data theme and the library hub.