What ISO 42001 A.7.2 asks for the data management process behind AI
If you are the compliance lead or engineer who must show an auditor how training, tuning and evaluation data is managed for your AI systems, the core answer is this: A.7.2 requires your organization to define, document and implement data management processes for the development of AI systems. It is the umbrella data control in Annex A, and the document an auditor reads first when testing how data is handled across the AI life cycle. The other controls in the same objective area, 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, each refine one part of that process. A.7.2 is where you set the rules those narrower controls then apply. The risk A.7.2 addresses is ungoverned data producing unreliable or unlawful AI behavior. When no one has written down how data is selected, labeled, stored, reused and retired, a model can be trained on material nobody can justify, evaluated against a test set that leaked into training, or retrained on data whose rights have lapsed. Each of these failures surfaces later as a biased output, a privacy complaint or a model that cannot be explained, and none of them is easy to reconstruct after the fact. The control is hard to meet for a practical reason: AI data rarely sits in one place. Raw sources may live with a data engineering team, labeling may be outsourced to a supplier, evaluation sets may sit in a researcher's notebook, and experiment tracking may run in a separate tool. Before you draft the process, confirm with your teams which systems hold development and evaluation data, who owns each one, and which suppliers touch it. The documented process should name those owners and the tools in each step, so an auditor can trace a dataset from source to model without relying on verbal explanations.
Which AI systems, datasets, teams and suppliers A.7.2 covers
A.7.2 applies to the data management processes behind every AI system the organization develops or enhances, so scope decisions made early determine how much documentation and evidence the control needs. The cards below cover the decisions that most often change the work, and each one should be recorded in the statement of applicability so an assessor can follow the reasoning.
In-house AI systems in scope
Start with an inventory of AI systems that your teams build, train, tune or substantially modify. A.7.2 is about the data management processes used to develop and enhance these systems, so a system built entirely by a supplier and only configured by your staff sits in a different place. Record the boundary for each system, including who builds it and who owns the data flows. Confirm the list with engineering leads, since shadow projects are the usual gap.
Fine-tuning data counts as development
Fine-tuning a model on your own examples is a development activity, so the datasets used for it fall under A.7.2 and the processes that govern them. Treat the training and validation sets, their selection rules and their retention as in scope. Document who approved each fine-tuning dataset and where it is stored, because assessors will ask for that record first.
Retrieval data as enhancement
Retrieval-augmented systems draw on document stores, vector indexes and knowledge bases that change often. Decide whether these sources count as enhancement data for the system and bring them under the same data management process when they shape system behavior. Note which sources are refreshed automatically and who authorizes new sources, since that is where undocumented data tends to enter.
Third-party data owned by suppliers
When a supplier owns or supplies the data used to develop your AI system, A.7.2 still applies to how you define, document and implement the processes that use it. Your contract and supplier records should show what data is used, the terms under which it is used and who is accountable for its management. Ask suppliers for their data management documentation rather than assuming it exists.
Teams that touch development data
A.7.2 covers the people who handle development data, not only the engineers who train models. Data scientists, labelers, analysts, platform operators and contractors all need defined responsibilities for the data management process. List these teams in the scope record and link each one to a process step, so the process is implemented in practice and not only written down.
Statement of applicability justification
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls you need and justifies including or excluding each one. Excluding A.7.2 is hard to defend if you develop or enhance any AI system in-house, because the control is the umbrella for the other data controls. Record the reason for inclusion or exclusion, the systems it covers and the date of the decision, and have the decision approved by the people accountable for AI governance.
How an assessor tests the AI data management process
The first step is documentary. The assessor looks for a defined data management process for AI development and enhancement, written down, scoped to the AI systems in the organization's statement of applicability, and approved by someone with authority to set direction. The assessor checks whether the document names its owner, its purpose, the roles that run it and the points where it applies, such as data acquisition, labeling, retraining and decommissioning. A process that exists only as informal practice is usually recorded as a gap, even when the people involved know it well.
- Approval record: a signed or versioned approval showing who authorized the process and when.
- Scope statement: the AI systems and development activities the process covers, matched to the statement of applicability.
- Roles and owners: named accountable roles for data sets, not only for the platform team.
- Review history: evidence that the process was reviewed at planned intervals and after significant changes.
- Link to policy: traceability from the AI policy and related A.2 controls down to the process.
Before an assessment, confirm that the document is the current approved version and that every referenced template or tool still exists.
The assessor selects a sample of AI development projects or model versions and traces each one back to the documented process. The question is whether the project's data handling shows the steps the process requires. The assessor asks for the project's data inventory, the data sources used, the approvals obtained and the records created during development. Gaps appear when a project cannot be connected to the process at all, or when it was built before the process existed and no transition decision was recorded.
- Project selection: a sample that includes recent projects, retrained models and projects that used third-party data.
- Data inventory entries: each data set listed with its source, owner and intended use.
- Approval trail: sign-offs for data use that match the process's approval points.
- Development records: experiment or pipeline logs that show which data version fed which model.
- Exceptions: any project that deviated, with a documented justification and approver.
Illustrative example: a retrained fraud model whose training set has no owner in the inventory would be a finding even if the model itself performs as expected.
The assessor checks whether the process was followed consistently and whether changes to it were made under management control. This means reviewing the sampled records against each step, then reviewing how the process itself was changed over time. Changes should be requested, assessed for impact, approved, communicated to the people who run the process and recorded. An assessor will compare dates across the process version history and the project records to see whether projects used the version that was in force at the time.
- Version control: dated versions of the process with a clear change log.
- Impact assessment of changes: a note showing how a change affected in-flight projects.
- Communication records: evidence that developers and data owners were told about changes.
- Training or briefing records: proof that the people running the process knew the current version.
- Tool configuration history: change records for data platforms that enforce parts of the process.
Check that the change history can be reproduced from source systems, not only from a document that someone maintains by hand.
The final step covers nonconformities, the gaps the assessor records when practice does not meet the requirement. Two findings appear often: a process that was written but not followed, and datasets with no owner. The assessor will look at how the organization detected these problems, whether it recorded them, what it did about the cause, and whether it verified that the fix worked. The organization's internal audit and management review results are part of this evidence, because they show whether the organization found the problems first.
- Written but not followed: the process describes steps that projects skip, with no recorded exceptions.
- Ownerless datasets: training or evaluation data with no accountable owner or no inventory entry.
- Corrective action records: root cause, action, owner and due date for each nonconformity.
- Effectiveness checks: later sampling that confirms the corrective action worked.
- Internal audit findings: results from the organization's own review of the process before the external assessment.
Before the assessment, run your own sample and confirm that every nonconformity has a documented corrective action and that no dataset in use lacks an owner.
How to implement a data management process for AI development
This sequence takes an organization from knowing where its AI development data comes from to a tested, approved data management process that covers A.7.2. Each step produces a record an assessor can check, so the process is defined, documented and in use rather than only written down.
Inventory AI development data flows
Map every place data enters, moves through and leaves the AI development work: source systems, training and evaluation datasets, labeling tools, storage locations, and the teams or suppliers that touch them. The data science lead and the system owner usually run this with input from data engineering and security. It is done when the inventory lists each data flow with its owner, purpose and storage location, and when someone outside the project has checked it for gaps. Consider using the asset records already held in your CMDB or inventory tools.
Define the data management process with stages
Write the process as a sequence of stages, such as intake, classification, approval for use, preparation, storage, retention and disposal, with entry and exit criteria for each. Name the inputs and outputs of every stage so the process can be followed without asking the author. The AI or data governance lead drafts it and the process is complete when it is written as a controlled, versioned document that covers all data used for development and enhancement of AI systems.
Set roles and approval points in a RACI
Assign who is responsible, accountable, consulted and informed for each stage, and mark the approval gates where data may move to the next stage, such as approval to use a dataset for training or to retain it after a model release. Keep accountability with a named role inside the organization. The output is an approved RACI matrix with named roles, and evidence that the approvers accepted their responsibilities.
Link the process to the other A.7 controls and AI risk
Connect the procedure to the acquisition, quality, provenance and preparation controls so each stage points to the record that the related control requires. Also connect it to the AI risk assessment and the impact assessment process, so that data-related risks identified there are traced to the data stages that address them. The output is a traceability table showing each stage, its linked controls and risk entries, and the owner who reviews the links.
Pilot the process on one AI system
Run the approved process end to end on one AI system that is in active development, recording each approval, data movement and exception as it happens. The pilot shows whether the stages, roles and gates work in practice, and whether the records are produced without rework. The output is a pilot record with dated entries, the issues found and the changes made to the procedure. Document the pilot as a formal test, not as an informal trial.
Run an internal review and close findings
Have someone independent of the AI project review the pilot record, the inventory, the RACI and the traceability table against the written process. Log each gap as a finding with an owner and a closure date set by the organization, then confirm the fixes. The output is an internal review report and a finding log that shows each issue was resolved or accepted by an appropriate approver. Ask any external assessor later what internal review evidence they expect, since requirements for this step vary by certification scheme.
Evidence that satisfies A.7.2 and how to keep it current
An auditor testing A.7.2 looks for a written data management process, a current record of the data behind each AI system, and proof that people followed the process. The cards below cover each artifact and how to keep it accurate between audits, since stale records fail as quickly as missing ones.
Approved data management procedure
This is the document that defines how data for AI development and enhancement is managed: who owns each stage, which systems hold data, how retention and deletion work, and what approvals are needed before data enters a training or tuning pipeline. Confirm that it names the roles that actually operate the process and that the approval date and version are recorded. Set a review cadence the organization can meet, and log each revision with the reason for the change.
AI data inventory
The inventory lists every dataset, data store and data flow used to develop or enhance AI systems, with owner, location, classification and the AI systems that depend on it. An auditor compares it against what is running, so unlisted datasets are a common finding. Automated discovery from cloud accounts and asset tools reduces drift, but a named owner must still confirm each entry at a set interval.
Per-project process records
For each AI development or enhancement project, keep a record showing that the documented process was followed: the datasets selected, the approvals obtained, the data management steps taken and any exceptions granted. This is the evidence that connects the procedure to real work. Ask project leads to complete the record at defined milestones instead of reconstructing it before an audit.
Change and approval logs
Version control and ticketing history show how datasets, data pipelines and retention settings changed over time and who approved each change. Auditors sample these logs to confirm that changes followed the procedure. Ensure approvals are recorded in the same system as the change, that no one can approve their own change, and that emergency changes are reviewed after the fact.
Access records
Access logs and group membership reports show who could read, write or export AI development data and whether that access matched the documented roles. Review them on a fixed schedule, remove access that is no longer needed, and keep the review sign-off. Syscollector-style inventory from endpoints and identity system exports can supply the raw lists, but the review decision must be documented by a person.
Review cadence and ownership
Evidence goes stale unless someone owns the calendar. Assign an owner for each artifact, set review intervals for the procedure, inventory and access reviews, and track completion in a management review or internal audit schedule. Ask the certification body or auditor which evidence periods they will sample before setting these intervals, and confirm the intervals against the organization's own change rate.
What meeting A.7.2 costs in effort and money
This table breaks down the cost components of meeting A.7.2 by who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to scope internal effort and to compare written quotes, since no fixed price applies to every organization. The main takeaway is that open-source licenses remove software spend but not the staff time spent designing, documenting and evidencing the data management process.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Process design and documentation | Internal data, AI and compliance staff; optional consultant | One-time, then revised on change | Number of AI systems and datasets in scope, and how many data pipelines already have written procedures |
| Engineering time to instrument data flows | Internal platform or data engineers; implementation partner if contracted | One-time per pipeline, plus change work | Number of data sources, tooling already in place, and whether lineage and logging are built in or added later |
| Evidence upkeep | Internal owners of data records, logs and approvals | Recurring | Frequency of dataset changes, retraining cycles and how well records are kept in one system |
| Internal audit of the data management process | Internal audit or a qualified internal reviewer | Recurring, per audit cycle | Size of the AI portfolio sampled and the maturity of the records being checked |
| External readiness review (optional) | Independent reviewer or consultant, paid under a written scope | One-time before certification, sometimes repeated | Scope agreed in writing, number of systems reviewed and the gap between current records and A.7.2 expectations |
| Certification body audit fees | Accredited certification body, paid under its own quote | Initial certification and recurring surveillance | Audit duration set by the certification body, scope of the AIMS and its accreditation terms; confirm in the quote |
| Open-source software licenses | Usually no license fee for the core platforms; support contracts are optional | Recurring only if support is bought | Choice of self-hosted tools and whether the organization buys vendor or partner support |
| Infrastructure to host tooling | Internal IT or the client's cloud account | Recurring | Hosting model, storage for logs and records, and retention periods set by policy |
Who owns the process, who prepares evidence and who audits it
The organization owns the A.7.2 control. It decides which data management processes apply to AI development and enhancement, who is accountable for each dataset, and which changes need approval before data enters a training, tuning or evaluation pipeline. These decisions cannot be delegated to a vendor or consultant, because the organization must be able to explain and defend them to its auditor and to its own leadership.
- Process ownership: a named owner signs off the data management procedure and reviews it on a defined schedule.
- Data owners: each dataset used for AI development has an accountable business or data owner who approves its use.
- Approvals: change approvals for new sources, schema changes or retention decisions are recorded in a ticketing or change system.
- Competence: staff who run data pipelines are trained on the procedure, and training records are kept.
- Management review: leadership reviews the data management process as part of the wider AI management system.
Before engaging anyone, confirm that these owners exist by name and that their approvals already produce records.
An implementation partner prepares the systems and evidence that show the A.7.2 process operates. DeployOpen, for example, works inside the client's own infrastructure to deploy and configure self-hosted open-source platforms, document the workflow and assemble evidence. The partner does not decide what the organization's data management policy says, and it does not sign off that the control is effective.
- Hosted tooling: designing and deploying the inventory, logging and monitoring platforms that record where AI data lives and who touched it.
- Evidence collection: configuring exports and reports that an auditor can sample, such as asset inventories and pipeline logs.
- Readiness testing: running a gap analysis against the control and checking that evidence is produced consistently.
- Documentation: drafting procedures and runbooks that the organization reviews and adopts.
- Handover: training internal staff so the organization can operate and maintain the evidence after the engagement ends.
Ask the partner to state in writing which deliverables are documentation, configuration or testing, and which decisions remain with the organization.
An independent auditor or certification body tests whether the organization's A.7.2 process is defined, documented and implemented, and it issues any certificate. ISO does not certify organizations. Certification bodies that certify AI management systems must meet additional requirements set out in ISO/IEC 42006:2025, on top of ISO/IEC 17021-1. Accreditation of those bodies is voluntary, so ask whether a body holds accreditation for ISO/IEC 42001 before relying on its certificate.
- Document review: the auditor reads the data management procedure and the statement of applicability entry for A.7.2.
- Sampling: the auditor selects datasets and traces them through approvals, logs and records.
- Interviews: data owners and engineers are asked how the process runs in practice.
- Findings: nonconformities are raised, and the organization responds with corrective action.
- Certification decision: only the certification body decides whether to issue, maintain or withdraw the certificate.
Confirm that the auditor has no role in designing the controls it will later test.
Independence is the principle that the party testing a control is not the party that designed or operated it. An implementation partner can be helpful before an audit, but it cannot also be the certification body, and its staff should not perform the internal audit that clause 9 requires of the organization. The same person should not write the procedure, build the evidence and then judge it.
- Outsourced work: platform deployment, configuration, evidence exports, gap analysis and documentation drafts are commonly outsourced.
- Retained work: policy decisions, data owner approvals, risk acceptance and the statement of applicability stay with the organization.
- Internal audit: the organization should assign internal auditors who were not involved in building the controls.
- Certification: only an independent body issues reports or certificates.
- Conflicts: ask any partner to disclose relationships with the certification bodies it may be recommended to.
Request a written scope that lists each deliverable and the owner of each decision before work starts.
Where organizations fall short on AI data management
Most organizations that struggle with A.7.2 do not lack a data policy. They lack a named owner, a process that existed before the first model was trained, and records that tie each dataset to the tools that handle it. The gaps below are where assessors usually find the distance between what is written and what actually happens.
No named owner for training data
A.7.2 asks for data management processes to be defined, documented and implemented, and an auditor will first ask who runs them. When training data sits with the data science team, the platform team and a vendor at once, nobody can answer for retention, access or deletion. Closure: assign one accountable role for AI development data, write it into the AI roles record under A.3, and confirm that role signs off each dataset before it enters a training pipeline.
Process written after the fact
Teams often document data handling only when an audit is scheduled, so the document describes an idealized pipeline rather than the one that ran. Assessors compare dates on the procedure against dates on the model runs it governs. Closure: write the data management process before the next training cycle, version it, and record each change with the reason and approver so the history is visible.
Datasets used with no record
Notebooks, shared buckets and local copies let engineers train on data that appears nowhere in the documentation. Without a record, the organization cannot show which data shaped a given model version. Closure: keep a dataset register that lists each dataset, its version, storage location, owner and the model versions that used it, and make registration a gate in the pipeline rather than a follow-up task.
Unclear handling of third-party data
Public corpora, licensed datasets and data supplied by customers each carry different permitted uses, and teams frequently mix them without tracking the terms. A.7.2 requires the processes to cover data used in development, so third-party inputs fall inside scope. Closure: classify every external source by its license or contract terms, block use of unclassified sources in training, and confirm with legal counsel which terms apply to each category.
Tooling disconnected from the process
A documented process that lives in a wiki while the pipeline, storage and experiment tracker run on their own rules is hard to defend. Auditors look for evidence that the tools enforce the process, such as logged runs, access records and dataset identifiers. Closure: map each documented step to the system that performs it, then export the logs from those systems as the evidence for that step. Confirm which of your tools can export this data before you rely on them.
Questions buyers ask about A.7.2 cost, effort and outside help
How much effort does A.7.2 take to implement?
Effort depends mostly on how many AI systems the organization builds or changes, how many data sources feed them, and whether data management processes already exist in written form. A.7.2 asks the organization to define, document and implement data management processes for AI development, so the work has a documentation side and a practice side. Teams that already run formal data governance for analytics or machine learning usually need to extend existing procedures rather than start from nothing. Teams without any documented data process face the largest effort, because the process, its owners and its records all have to be built. No duration is stated here because no researched figure is available. Ask any consultant to base an effort estimate on a written scope that lists systems, data sources and existing documents.
Can we implement A.7.2 in-house without an outside partner?
Yes, an organization can implement A.7.2 with its own staff, because the control is a management and documentation requirement and the organization owns it. The work needs people who understand the AI systems, the data pipelines and the governance process, plus someone accountable for approving the process. Outside help is usually considered when the internal team lacks time, lacks experience with data pipelines or lacks infrastructure for the records an auditor will request. An implementation partner can prepare systems and evidence, but it does not decide whether the control is adequate and it does not issue any report. Confirm your internal capacity against the scope of your AI systems before deciding.
What does the work need from our team?
The work needs four kinds of input from the organization:
- A named owner for the data management process who can approve it and answer audit questions.
- Engineers who can describe how data moves through development, testing and tuning of each AI system.
- Records from existing data stores, pipelines, ticketing systems and access logs.
- Time from legal, privacy and security staff to confirm which data uses are permitted and how they are protected.
Ask for these inputs to be listed in the written scope so the team knows its commitments before work begins. Your own staff owns the decisions and the controls, while the partner prepares the material around them.
How long does A.7.2 implementation take?
The timeline depends on the number of AI systems in scope, the state of existing data governance and how quickly internal reviewers can approve documents. No researched duration is available for A.7.2 in this context, so this page does not give a number of weeks or months. Ask a potential partner for a timeline tied to a written scope, and ask which dependencies could extend it, such as approval cycles, access to data owners or the schedule of a planned certification audit. Certification timing is set by the certification body, not by the implementation work.
Does DeployOpen issue ISO 42001 certificates for A.7.2?
No. DeployOpen does not issue audit reports, attestations or certificates. DeployOpen plans, implements and documents the systems, controls and evidence that support A.7.2, and it can prepare those materials for review. Only an independent certification body accredited for the standard can issue an ISO/IEC 42001 certificate, and ISO itself does not certify organizations. Your organization owns its controls and decides which certification body to engage. Ask any partner to confirm in writing that it will not issue or sign a certification claim on your behalf.
How does A.7.2 relate to A.7.3, A.7.4, A.7.5 and A.7.6?
A.7.2 is the umbrella data control in the A.7 group. It requires the organization to define, document and implement the data management processes used to develop and enhance AI systems. The other controls refine parts of that process: A.7.3 covers how data is acquired and selected, A.7.4 covers data quality requirements and how they are met, A.7.5 covers recording provenance across the life cycle, and A.7.6 covers the criteria and methods for data preparation. In practice, the A.7.2 document sets the process and roles, and the four sibling controls supply the detailed records beneath it. An auditor will usually check them together, so design them as one set of linked documents rather than four separate projects.
What a fixed-scope A.7.2 engagement covers
A fixed-scope engagement for A.7.2 starts with a written scope that names the AI systems, the data pipelines feeding their development and enhancement, the data management processes to be defined, and the documents and records that will exist at the end. DeployOpen plans and implements that work inside your own cloud accounts, data centers or air-gapped networks, and the scope, deliverables and timeline are agreed in writing before any work begins. Ask the proposal to state which AI systems are in scope, which teams run their training and retraining pipelines, and which evidence items are deliverables. Anything not written into the scope should be treated as outside it until a change is agreed in writing.
The division of responsibility matters as much as the deliverables. Your organization owns its controls, including the data management process itself, its approval and its ongoing operation. DeployOpen prepares the systems, configuration and evidence that show how data for development is managed, but it does not issue audit reports, attestations or certificates. Only an independent auditor or certification body can assess your conformity, so confirm with that body early which records it expects to see. To make the work possible, you need to name data owners who can explain each dataset, grant read access to the systems that store and process training data, and assign decision makers who can approve the process, resolve conflicts about data use and sign off on the final documentation.
Before signing, check that the client inputs are scheduled, not assumed. Confirm with your data owners how many datasets and pipelines are in scope and who can answer questions about them. Confirm that the platform administrators can provision the access the work requires, and that a named person can review and accept the documentation. Ask your implementation partner to list every dependency on your side as a dated milestone in the statement of work, so a delay in one input does not silently extend the engagement. Verify with your auditor which evidence format they accept before the documents are drafted.
How DeployOpen scopes and prepares A.7.2 evidence
DeployOpen helps organizations define, document and implement the data management processes behind AI development inside their own infrastructure. The organization owns the A.7.2 process and its decisions, while DeployOpen prepares the systems, records and evidence an independent auditor or certification body would review.
How we scope
- Engagements are fixed-scope, with the A.7.2 data management processes, systems and datasets agreed in writing before work starts.
- The written scope names which AI development pipelines, data stores and teams fall under A.7.2 and which related controls are excluded.
- We confirm with you which evidence your statement of applicability and assessor will expect for this control.
How we build
- We document the data management process for AI development, covering roles, stages, approvals and recordkeeping, for your review and sign-off.
- We configure logging and inventory on self-hosted platforms so data movements and development assets leave traceable records.
- We test the controls we deploy and record the results so you can show how the process operates in practice.
How we hand over
- You receive the process documentation, configuration records, test results and an evidence index mapped to the agreed scope.
- Deliverables are written for your internal owners and the independent assessor, so they can follow the evidence without DeployOpen present.
- Ownership of the controls, approvals and any statement of applicability remains with your organization after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for systems that keep changing after handover.
- A retainer can keep the A.7.2 process records current as new AI development projects, datasets and teams are added.
- Ask any provider to confirm in writing who maintains the evidence, who approves changes and how audit requests are handled.
