ISO 42001 Annex A.7.2: Manage Data During AI Development and Enhancement
ISO 42001 control A.7.2 concerns defining, documenting and implementing data management processes for AI development. The process should make consequential data decisions deliberate and traceable. A well-described model can still be undermined by unsuitable, poorly understood or inappropriately handled data.
What control A.7.2 requires in practice
Control A.7.2 asks the organisation to define, document and carry out data management processes for developing AI systems. Three verbs matter. Defining means the approach is decided rather than left to individual engineers. Documenting means others can read how it works. Implementing means real datasets are actually handled that way, so a written policy alone does not meet the control. The scope is development, which in practice includes later enhancement when new data is added or the system is retrained. Annex B guidance lists topics a data process can cover: privacy and security consequences of using sensitive data, threats that arise from depending on data, the ability to explain how data shaped an output, whether training data resembles the real operating setting, and the accuracy and integrity of the data. The output is a working process plus records showing it applied to specific datasets.
Manage the data's role in the system
Annex B.7.2 considers sensitive-data implications, relevant threats, provenance, representativeness and data integrity. It connects these issues with transparency where needed. The guidance must be considered through clause 6.1.3(e), while B.1 allows suitable implementation for the organisation's activities.
Start with the intended use and the role of data in development or enhancement. Identify who selects sources, assesses suitability, controls preparation and decides whether changed data can be used. These practical responsibilities should connect with the wider development process rather than sit in an isolated data policy.
Why control A.7.2 matters to the business
A model is only as sound as the material it was built from. Many costly AI failures trace back to data that looked plentiful but did not match the real setting, or that arrived through an informal route nobody reviewed. A defined data process protects the business from rework late in a project, from awkward questions in customer due diligence and from surprises when a model is retrained with a new source. It also makes responsibilities visible: who may add data, who checks it and who can stop its use. Auditors treat this control as a window into the maturity of the whole development function.
How to implement control A.7.2
Start from the datasets that matter most, then build the process around how they are actually handled. Expect to adapt existing engineering and security routines rather than invent a parallel bureaucracy, and make sure each step has a named person so that decisions are never left to whoever happens to be building the model that week.
- Inventory the datasets used or planned for each AI development or enhancement, with the role each plays.
- Name who proposes data, who assesses its suitability and who approves its use, and who may stop it.
- Define handling rules covering sensitive content, access and protection, drawing on existing security and privacy arrangements.
- Describe how the process connects acquisition, quality, provenance and preparation decisions so they form one flow.
- Add a trigger so any new source, changed preparation or new target population is reviewed before release.
- Apply the process to one live dataset end to end and keep the trail as proof of implementation.
- Review the process after the first real enhancement and fix the steps people skipped.
Illustrative software example: enhancement introduces new source material
A software provider improves an AI knowledge assistant by adding customer-supplied technical notes. The original development process used reviewed public material. The new notes contain different terminology and may include confidential content or outdated instructions.
The data process identifies the changed source and relevant handling, quality and evaluation questions before incorporating it. The organisation does not assume that a customer's willingness to upload information resolves every use or protection issue. Appropriate review connects the data decision with the system's purpose.
Illustrative manufacturing example: development data misses a condition
A manufacturer develops an AI aid using images collected during normal daytime production. The intended service also operates on other shifts with different conditions. The data management process should make that gap visible before the evaluation is described as representative of the whole use.
The team considers suitable additional evidence or operating limits and records the decision. It does not treat a large volume of similar images as proof that all relevant conditions are covered. Quantity and fitness for purpose are different questions.
Connect the data controls
The process can link acquisition, quality, provenance and preparation. The purpose is a coherent flow of decisions and evidence. Separate records can be used if their relationships remain understandable.
Changes during enhancement need attention as well as initial development. A new source, altered preparation method or different target population can affect the meaning of prior evaluation. Identify how such changes become visible to people responsible for assessment and release.
Balance access and protection
People need enough data access to perform authorised work, while sensitive information requires appropriate protection. The data process should connect with relevant security, privacy and contractual arrangements. This control does not itself establish legal permission to acquire or use a dataset.
Where supplier information is incomplete, make the limitation explicit. Assess what it means for development and claims about the system. Do not manufacture confidence by replacing an unknown source history with a generic statement that data is suitable.
Evidence and common mistakes
The control includes an implemented process, not just a documented intention. Evidence may follow a dataset from selection through preparation and use in a development decision. It should show how material concerns were addressed.
Common weaknesses include treating all accessible data as usable, leaving data decisions entirely to whoever builds the model and updating datasets without reconsidering evaluation. Another is assuming security controls alone establish representativeness or fairness. Different data questions need appropriate evidence.
Frequently asked questions
Does this control apply only to initial development?
No. Enhancement can introduce consequential data changes. The process should address relevant development activities over time.
Is a documented policy enough?
No. The control includes implementation. Examine actual data decisions and evidence, not only the policy's existence.
Can we integrate data management with existing processes?
Yes, where they address the AI development needs and preserve clear responsibilities and evidence.
Connect a dataset decision with development governance
Discuss an AI data-management process with Sterling, starting from a current development or enhancement. Scoped support can include documentation and Effivity ISO & GRC automation software. AI Risk & Impact Assessment helps teams examine data-related consequences. Return to the data theme or the library.