A.7.5 Data provenance: requirements and evidence

What A.7.5 data provenance asks for and why auditors check it

An auditor or customer questionnaire asks where the training, evaluation or retrieval data behind an AI system came from, and the answer needs to be a documented process, not a spreadsheet written the week before the audit. Control A.7.5 asks the organization to define and document a process for recording the provenance of the data used in its AI systems, covering the origin of each data source, its lineage, the transformations applied to it and evidence that it has not been altered without record. The process has to work across two life cycles at once: the life cycle of the data itself and the life cycle of the AI system that consumes it. Auditors check it because provenance is what lets an organization explain a model's behavior. Without it, data cannot be traced to its source, undocumented changes to a pipeline shift results in ways nobody can reconstruct, and a model cannot be explained to a regulator, a customer or an internal reviewer.

Provenance is easy to confuse with two neighboring controls. A.7.3 covers how data is acquired and selected, including sources, rights and consent. A.7.4 covers whether the data meets defined quality requirements. A.7.5 asks a narrower and more mechanical question: can the organization show, for any dataset used by a system, where it came from, what happened to it on the way, and whether the copy in use is the copy that was recorded. A dataset can pass acquisition review and quality checks and still have no provenance record. The control is shared with the AI system life cycle, so the same records should support design, verification, deployment and operation decisions. The implementation guidance for this control (B.7.5) is linked to NIST AI RMF MAP 2.3 and MEASURE 2.9 in the NIST crosswalk, which Microsoft contributed and which NIST notes is not an endorsement. Confirm the mapping against the current documents before citing it in an audit file.

Three things usually make this hard. Data arrives from many sources, each with its own format and documentation, so origin is lost at the first handoff. Pipelines change silently when a transformation is edited, a feature is recomputed or a third-party feed alters its schema, and nothing records the change. Lineage is then rebuilt after the fact from memory and old tickets, which produces records that look complete but cannot be verified. A practical first step is to list every dataset used by each AI system and assign an owner who must record source, version, transformation steps and a content hash or equivalent integrity check at each change. Ask your team which of these records already exist, where they are stored and whether they can be reproduced from the pipeline itself.

Which datasets, pipelines and teams fall inside A.7.5 scope

Scope for A.7.5 Data provenance is set before any lineage is recorded. The choices below decide which datasets need records, how far back lineage must reach, and who must produce the evidence. Each one should be justified in the statement of applicability under clause 6.1.3.

Datasets used across AI system types

Start with an inventory of every dataset that touches an AI system: training corpora, fine-tuning sets, evaluation and benchmark data, retrieval corpora used at inference time, and prompt and reference data. Retrieval corpora and prompt libraries are often missed because they change outside the model release cycle. Record which systems each dataset feeds, so the provenance record for a dataset can be traced to every system that uses it. Ask whether any dataset is shared across systems, since a shared dataset multiplies the lineage to be kept.

Life cycle stages that must be traced

A.7.5 expects provenance to be recorded across the life cycles of both the data and the AI system. Decide which stages count: collection, labeling, transformation, training, evaluation, deployment and retraining. Each stage that changes data or its meaning is a point where an auditor may ask where a dataset came from and what was done to it. Document the stages in scope and the reason any stage is excluded, because that reasoning is what the statement of applicability must justify.

Teams that own pipelines and releases

Provenance records fail when no team owns them. Map who runs data ingestion, who prepares and labels data, who approves model releases and who operates retrieval indexes. Each team should know which lineage fields it must populate and when. Confirm that a named owner signs off on each dataset record before a model release, so the record reflects the data actually used and not a planned version.

Purchased and third-party datasets

Datasets bought, licensed or scraped from outside the organization need provenance records supplied by the supplier or gathered at acquisition. Ask suppliers for source descriptions, collection methods, version identifiers and any transformations they applied before delivery. Where a supplier cannot describe lineage, the gap belongs in the risk assessment and the statement of applicability. Confirm contract terms that require suppliers to notify changes to the data.

Statement of applicability and lineage depth

Clause 6.1.3 requires the statement of applicability to justify whether A.7.5 is included and why. Including the control commits the organization to recording provenance, so exclusion needs a defensible reason. The scoping choices also decide how far back lineage must reach: a dataset used in a release currently in service may need records back to its original source, while data used only in retired systems may fall outside the record. Confirm the depth with the auditor before collection begins.

How an assessor tests A.7.5 data provenance

This table sets out how an assessor typically tests A.7.5, what evidence they ask for, and where organizations most often fall short. Read each row as a test step paired with the proof it needs, and use the findings row to check your own readiness before an assessment begins.

Test area	What the assessor does	Evidence requested and common findings
Documented process and AI policy link	Reads the documented provenance process and checks that it names a process owner, applies to the AI systems in scope, and ties back to the organization's AI policy.	Evidence: the written process, its approval record and a clear link to the AI policy. Common finding: no named process owner, or a process that exists only as an engineering wiki page with no management approval.
Sampling and end-to-end tracing	Selects one or more AI systems in scope and traces a dataset from its source, through every stage, to the model version it trained or informed, then back again.	Evidence: a lineage record for each sampled dataset showing source, acquisition point, storage locations and the model versions that used it. Common finding: lineage that stops at the first pipeline stage or cannot name the model version that consumed the data.
Transformation records and reproducibility	Checks that each change to the data (filtering, cleaning, labeling, joins, splits, augmentation) is recorded and that a second engineer could rerun the steps and reach the same result.	Evidence: versioned pipeline code, parameter logs, run identifiers and a reproduction test. Common finding: transformations performed interactively in notebooks with no stored code, parameters or run record.
Integrity evidence	Looks for mechanisms that show a dataset or artifact has not changed without a record, and checks that those mechanisms are actually run.	Evidence: hash values or checksums for datasets, signed artifacts, access-controlled version history and change logs. Common finding: hashes computed once at ingestion and never rechecked, or datasets overwritten in place.
Coverage of both life cycles	Confirms that provenance is recorded across the data life cycle (acquisition, storage, use, retention, disposal) and across the AI system life cycle (development, deployment, operation, retraining).	Evidence: a life cycle map showing which provenance records apply at each stage and who maintains them. Common finding: records kept for training data only, with nothing for retraining runs, fine-tuning data or production inputs.
Interviews with data and engineering owners	Interviews data engineers, ML engineers and the process owner to confirm that the documented process matches how work is actually done.	Evidence: consistent accounts across roles, and staff who can locate a record without help. Common finding: the documented process describes a pipeline that has since changed, and staff are unaware of the update.
Currency of the provenance record	Checks dates and version history to confirm the provenance process has been reviewed and that records were updated when data or systems changed.	Evidence: revision history, review dates and change tickets linked to dataset or model changes. Common finding: provenance written once at launch and never updated after retraining or a change of data source.

How to implement a provenance process that passes review

This sequence moves from a documented provenance process with a named owner to a tested record set that an assessor can follow from a model output back to its data sources. Each step names the artifact it produces, so the result can be shown to an auditor.

Define the provenance process and its owner
Write a provenance procedure that states what is recorded, when it is recorded, where records are kept and who is accountable for them. Tie it to the AI policy and the roles already defined under the internal organization controls, so the process has an owner with authority over data teams and engineering. The output is an approved process document with a named owner and a review date set by the organization. It is done when the document names the lifecycle stages it covers, including data collection, training, fine-tuning, retrieval indexing and operation, and when the owner has signed it off.
Inventory the datasets and AI systems in scope
List every dataset and AI system the process must cover, including training sets, evaluation sets, fine-tuning data, retrieval corpora and any data an AI system uses at runtime. Mark which systems are built in-house, which use third-party models or data, and which are vendor products. The output is a dataset register that links each dataset to the AI system that consumes it. It is done when data owners have confirmed the list and no consuming system is missing, because an unlisted dataset is the most common gap an assessor finds.
Define the provenance record schema
Set the fields each record must hold: origin (source system or supplier), license or rights reference, dataset version, transformations applied, integrity identifier such as a content hash, and the AI systems or model versions that consumed it. Agree the allowed values and who completes each field. The output is a written record schema, with examples marked as illustrative, that data and engineering teams both use. It is done when a sample record for one dataset can be completed without asking the schema owner for clarification.
Instrument pipelines to write records automatically
Where the platform allows it, have ingestion, transformation and training jobs write provenance fields at the point they run, instead of relying on people to update a spreadsheet afterward. Store records in a version-controlled or access-logged location and track changes to the pipelines themselves. Open-source tooling can help: pipeline and pipeline-run metadata, SBOMs for the software that touched the data, and trace logs of model calls. The output is pipeline change logs and sample generated records. It is done when a pipeline change produces a visible record and a reviewer can see who changed the job and when. Confirm each tool's capabilities in your own environment before you rely on it.
Run a trace exercise on one real dataset
Before the audit, choose one dataset that feeds a live AI system and trace it end to end: from its source and license, through each transformation, into the training or retrieval step, and to a sample output. Check that the integrity identifier still matches the stored data and that every hop has a record. The output is a trace report listing each gap, its owner and the fix. It is done when an engineer who did not build the pipeline can reconstruct the chain from the records alone. Treat the report as internal evidence, not as an audit result.
Review the process and update it from findings
Feed the trace report, incident records and any changes to data sources or AI systems back into the process document, dataset register and schema. Record each change with its reason and approver, and confirm that the AI policy and the internal audit or management review cycle pick up the update. The output is a revised process, a change history and a closed list of trace findings. It is done when the owner can show that the process changed in response to evidence, which is what an assessor looks for when testing whether the control is operating rather than only written down.

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

A.7.5 is tested by records, not by intent. The cards below cover the six evidence artifacts an assessor usually asks to see, and each one includes a routine that keeps it accurate between audits. The organization owns these records; an implementation partner can help build the tooling and templates, but the independent certification body decides whether the evidence is sufficient.

Documented provenance process

This is the written procedure that defines what provenance means in your organization, which systems must record it, who owns each step, and how records move from source to model. Assessors check that the process covers both the data life cycle and the AI system life cycle, not only the training run. Review it at each model release and record the approver and date. Confirm that the document names the roles responsible for each record in the dataset register and the trace reports, so gaps show up as ownership questions rather than surprises.

Dataset register with origin and version

A dataset register lists every dataset used in development, enhancement or operation of an AI system, with its source, licence or permission basis, collection date, owner and version identifier. Each new version should get its own entry rather than overwriting the old one, so earlier model behavior can be traced. Keep the register in version control or a controlled system of record. Tie every new entry to the ticket that introduced it, and run a quarterly check that each dataset in production has a current entry.

Transformation logs and pipeline definitions

Pipeline definitions and transformation logs show each cleaning, joining, filtering or labeling step applied between source and model input. Store pipeline code and configuration under version control so the exact steps for any dataset version can be re-run and compared. Logs should record input and output versions, parameters and the executing run. Before each audit, confirm that a rebuild from a recorded pipeline version reproduces the dataset version used for the model, and note any step that relies on manual intervention so it can be documented.

Integrity records and signed manifests

Integrity records, such as cryptographic hashes of dataset files and signed manifests listing them, let you show that a dataset used for training matches the one recorded at intake. Generate hashes when data is accepted and again before each training run, and store them outside the storage location they protect. A mismatch is a finding to investigate, not a routine event. Check periodically that the manifests still verify, and keep the verification output as evidence that the chain of custody was tested.

Trace reports from source to model

A trace report follows one dataset from its source record through every transformation to the model version and deployment it fed. It is the evidence that links the register, pipeline and integrity records into a single story. Choose several datasets across different sources and model releases and produce a trace for each, including the operations and tooling that ran. Run this trace on a fixed schedule and after any significant pipeline change, and file the results with the model release ticket so the assessor can sample them directly.

Change records for data and pipelines

Change records capture each update to a dataset, a pipeline step or a data source, including the reason, the reviewer, the impact on the affected models and the decision to retrain or not. Assessors look for changes that bypass the provenance record, so link each change to a register entry and a model release ticket. Review the change log at each release and search for pipeline edits with no matching register update. Use the log to answer the question an auditor is most likely to ask: which data changed between two model versions, and who approved it.

What meeting A.7.5 costs in money and effort

This table compares the main cost components of meeting A.7.5 Data provenance, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Read each row as a question to put to a quote: the drivers show where scope decisions change the bill. The main takeaway is that open-source tooling removes license spend, but engineering, hosting and evidence upkeep remain.

Cost component	One-time or recurring, and who is paid	What drives it up	What lowers it
Tooling and licenses	Mostly no license fee for the supplied tools (Apache-2.0 or MIT). Hosting and infrastructure are recurring; the implementation partner or internal team is paid one-time for setup.	Number of environments to host, retention volume of traces and SBOMs, and any commercial add-ons you choose to buy	Reusing existing hosting and storage, limiting retention to what the policy requires, confirming license terms with each project
Engineering time to instrument pipelines	One-time for the initial instrumentation of each data pipeline; recurring when pipelines change. Paid to internal engineers or an implementation partner.	Number of data sources, number of pipelines, and how many pipelines lack consistent versioning or logging today	Capturing lineage automatically at pipeline steps, using existing version control, and instrumenting shared pipeline components once
Evidence upkeep	Recurring. Internal data owners or compliance staff maintain provenance records, SBOM and dataset version history, and transformation logs.	Model release frequency, number of dataset versions, and regulated or personal data that needs source and consent records	Generating records from tooling output, a single provenance register with named owners, and a fixed review cadence
External testing or review	Recurring or periodic. An independent tester or reviewer is paid per engagement, scoped in writing.	Number of AI systems in scope, depth of review of data integrity and tampering controls, and use of adversarial testing against data pipelines	Narrowing scope to high-impact systems, testing once per major change, and sharing one evidence pack across reviews
Auditor sampling time	Recurring at each audit cycle. The certification body or assessor charges for the time it spends sampling and testing records.	Number of datasets and models sampled, gaps in lineage records that force follow-up, and records spread across unconnected systems	A clear index linking each model to its datasets, consistent record formats, and records that are complete before the audit starts

Which open-source tools can produce A.7.5 evidence

No single tool records the full provenance of AI training and operating data. Each of the four tools below covers one part of the record an assessor may ask for: model testing, runtime trace lineage, component origin and software inventory. Use them together and confirm each project's current feature set and license terms in its documentation before relying on it.

garak model testing reports

garak probes language models for hallucination, data leakage, prompt injection and misinformation, and writes a JSONL report of every attempt and evaluation plus a hit log of attempts that found a vulnerability. For A.7.5, these reports can show that model behavior was tested against known data risks, which supports the claim that the data was examined in context. It does not trace where training data came from, so it cannot replace a dataset provenance record. Confirm the probe list and report format in the project's README.

Langfuse runtime lineage traces

Langfuse captures each trace of a request, including LLM calls, retrieval steps, tool executions, inputs, outputs, token usage and metadata. For A.7.5, these traces can show which retrieved data sources and transformations fed a given output, which is runtime lineage. They record what happened during operation, not how the underlying data was originally acquired or prepared. Confirm the trace fields your deployment captures and your retention settings in the observability documentation.

Dependency-Track component provenance

OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components, and tracks license use by component with SPDX license IDs. For A.7.5, it supports provenance of the software components and libraries that process or package data in the AI system. It does not record the origin of datasets or model training data. Confirm which SBOM formats and license data sources your version imports.

Trivy software inventory

Trivy identifies OS packages and software dependencies in a target and can produce them as a software bill of materials, and it can also scan existing SBOMs. For A.7.5, its output gives a dated inventory of the software stack that stores, transforms and serves AI data, which is useful when an assessor asks what changed between data processing runs. It does not identify the origin or license of datasets. Confirm the SBOM formats and scan targets supported by your Trivy release.

Who owns A.7.5 and what an implementation partner can prepare

Your organization owns A.7.5. The provenance process is a management decision about which data may enter AI systems, how its origin is recorded and who answers for it when something is wrong. An implementation partner can draft material, but the policy, the dataset owners and the decision to include or exclude A.7.5 in the statement of applicability must come from inside the organization, with accountable people named for each.

Provenance policy: Approve the rules for what provenance must capture, how long records are kept and when a gap blocks a dataset from use.
Dataset owners: Name an accountable person for each dataset, who confirms its source, licence terms and transformations.
Record sign-off: Review and approve provenance records before a dataset is used for development or operation, and keep a dated approval trail.
Applicability decision: Record in the statement of applicability whether A.7.5 applies, with the justification that clause 6.1.3 requires.
Internal audit input: Give internal audit access to records so the organization can test its own process before an external assessment.

Check that every dataset in use has a named owner and a signed record. Ask whether that owner could explain the data's origin without the partner in the room.

Where organizations fall short on A.7.5 and how to close each gap

Most A.7.5 findings come from a small set of recurring gaps: provenance records that stop early, transformations nobody recorded, and records that drift from the data they describe. Each card names the gap, the fix and the evidence an assessor would expect to see.

Provenance stops at ingestion

Many teams log when a file lands in the data lake and nothing after that. A.7.5 covers the life cycle of the data and the AI system, so the record must carry origin, lineage and each transformation through to training, validation and operation. Check whether you can trace a model input back to its source system and the extraction job that produced it. Evidence: lineage records linked from each dataset version to the model version that consumed it.

Transformations happen in untracked notebooks

Cleaning, joining, labeling and filtering often run in ad hoc notebooks that no one versions or records. The result is a dataset that cannot be reproduced from its inputs. Move transformation steps into version-controlled pipeline code with parameters captured per run, and record which code commit produced each output. Evidence: pipeline run logs and the code revision for every derived dataset, reviewed before release.

No owner for dataset records

When no named role is responsible for provenance records, entries go stale or are never written. Assign an accountable owner for each dataset and a reviewer who checks the record before the dataset enters training or operation. The owner should match the roles defined under your AI governance structure. Evidence: a register that names the owner and reviewer for each dataset, with dated approvals.

Supplier datasets arrive without origin data

Datasets bought or downloaded from third parties often come with little information about where they were collected, under what terms or which version was delivered. Require suppliers to state source, collection method, version and change history before the data is accepted. Record a hash or checksum at receipt so later changes are detectable. Evidence: a signed intake record per supplied dataset, with the checksum and the supplier's documentation attached.

Records not updated when data changes

A provenance record written once at launch becomes wrong as soon as the dataset is refreshed, corrected or relabeled. Tie record updates to the data change process so a new dataset version cannot be used until its provenance entry exists. Compare stored checksums against the data in use to catch silent edits. Evidence: version history showing each dataset change with a matching record update and approval date.

No trace run before the audit

Teams often discover gaps only when an assessor asks them to walk a model back to its data. Run a trace on one or more production models before the audit window, from output back to source. Record what could and could not be traced, then fix the gaps. Evidence: a dated trace exercise with the results, the gaps found and the remediation tickets closed.

Questions buyers ask about A.7.5 cost, effort and outside help

How much effort does A.7.5 data provenance take for a small team with few datasets?

For a small team with a handful of datasets, the work is mostly defining one provenance procedure, writing a record template, and capturing origin, lineage, transformations and integrity checks for each dataset that feeds an AI system. The effort is driven by the number of data sources, how often data is refreshed, how many transformation steps sit between raw data and model input, and whether provenance is already recorded in pipelines or only in people's memory. Few datasets with stable pipelines usually means a short, mostly documentation-led effort. Ask any provider to break the work into the procedure, the per-dataset records, the tooling changes and the evidence collection, and to state which of these the organization must staff itself.

How does A.7.5 effort grow for a large data platform?

Effort grows with the number of pipelines, data owners, teams and AI systems that share data. A large platform needs lineage captured automatically where possible, consistent naming of datasets and versions, integrity evidence such as checksums or signed manifests, and a way to trace a model's training data back through every transformation. Each additional shared dataset multiplies the records to keep current. Ask for a written scope that lists in-scope AI systems, data sources and pipelines, because that list, not the platform's size alone, determines the work.

Can our own team implement A.7.5 without an outside partner?

Yes, the organization can define and run its own A.7.5 process, and the standard places that responsibility on the organization itself. In-house teams usually need time from data engineers, data owners and whoever maintains the AI governance records, plus someone who understands how an assessor will test the evidence. Outside help is most useful for the technical setup, such as wiring lineage capture into pipelines or producing SBOM and scan outputs, and for a readiness review before the audit. Whichever route is chosen, the organization keeps ownership of the process and the decisions it records.

What do engineering and data owners need to provide for A.7.5?

Engineering needs to expose where data comes from, what transforms it, and where each version is stored, usually through pipeline logs, dataset versioning and access records. Data owners need to confirm origin, legal basis for use, permitted purposes and who approves changes to a dataset. Both groups should agree on the record format, the review frequency and the escalation path when provenance cannot be established. Without these contributions from both sides, the process will document intent rather than actual lineage, which is the gap an assessor is most likely to find.

How long does A.7.5 preparation take, and what drives that time?

No supplied duration exists for A.7.5 preparation, so no timeline can be stated here. The main drivers are the number of AI systems in scope, how many data sources lack existing lineage records, the state of pipeline tooling, and how much data-owner review is needed. Ask any provider for a written scope and a written schedule that names the milestones, the dependencies on your staff, and the point at which evidence is considered ready for an independent assessment.

Can a consultant or implementation partner certify our A.7.5 control or ISO 42001?

No. A consultant or implementation partner can prepare the process, systems and evidence for A.7.5, but only an independent certification body issues a certificate for ISO/IEC 42001. ISO itself does not certify organizations. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Keep the preparation partner separate from the body that assesses you, so that the people who built the evidence are not the people who judge it.

Is A.7.5 alone enough to pass an ISO 42001 audit?

No. A.7.5 is one of 38 Annex A controls, and it sits inside the broader AI management system that clauses 4 to 10 require. The organization must justify in its statement of applicability which Annex A controls it includes or excludes, and an assessor will look at how provenance records connect to AI risk assessment, impact assessment, documented information and internal audit. A strong provenance record with no governance around it will not satisfy the assessment. Check your statement of applicability before deciding how much effort the provenance work deserves.

How DeployOpen scopes and prepares A.7.5 evidence

DeployOpen plans, implements and documents the systems that record data provenance for AI systems inside your own infrastructure. We prepare the process, the records and the evidence for A.7.5 Data provenance, while your organization owns the control and an independent certification body issues any certificate.

How we scope

Written scope lists the AI systems, datasets and pipelines whose provenance records fall under A.7.5 Data provenance.
Scope names the life cycle stages covered, from data acquisition through training, retraining and operation.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure self-hosted tooling to capture origin, lineage and transformation records for each dataset in scope.
Integrity evidence is produced with checksums and SBOM generation, such as Trivy output, stored alongside each AI system release.
Security testing of AI systems can produce garak reports that you can attach to provenance and validation records.

How we hand over

You receive the documented provenance process, record templates and a map of where each evidence type is stored.
Runbooks explain how staff update lineage records when data sources, transformations or model versions change.
Your internal owner receives a walkthrough so the control can be operated and evidenced without outside help.

How we support

Ongoing support and upgrades of the provenance tooling are available as a retainer after handover.
Continuous testing can be added so that provenance gaps are found before an assessor samples them.
Ask your certification body or auditor which provenance records they expect to sample before finalizing the scope.