Data provenance

ISO/IEC 42001 Control A.7.5 requires you to establish and maintain records showing where AI data came from, how it changed, and who handled it across its lifecycle. To operationalize this quickly, define a provenance standard, instrument your pipelines to capture lineage and transformations, and retain auditable evidence tied to each AI system and dataset. ¹

Key takeaways:

• Build a “provenance record” that covers origin, legal basis, lineage, transformations, and chain of custody for every dataset used by an AI system.
• Automate capture through data pipelines and MLOps tooling; manual spreadsheets rarely survive audits.
• Tie provenance evidence to risk decisions: dataset approval, model release gates, and third-party data intake.

“Data provenance” is the ability to prove where your AI data originated, what happened to it, and who had custody over time. Under ISO/IEC 42001 Annex A Control A.7.5, you must keep records of provenance for data used in AI systems. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat provenance as an auditable recordkeeping requirement, not a research project. Examiners and internal auditors will test whether you can reconstruct the chain from a model in production back to the datasets (and sources) that trained, tuned, evaluated, or informed it. They will also look for controls that prevent “mystery data” from entering AI workflows, especially data obtained from third parties, business users, or ad hoc exports.

This page gives requirement-level implementation guidance you can hand to engineering, data governance, and product teams: who is in scope, what records to keep, how to capture them, what evidence to retain, and how to avoid common failure modes that create audit findings and operational risk.

Regulatory text

Requirement: “The organization shall establish and maintain records of the provenance of data used in AI systems.” ¹

Operator interpretation: You must be able to produce durable records, for each AI system, showing the origin and lineage of the data that was used (training, testing, validation, retrieval, prompts/grounding, fine-tuning, reinforcement signals, human feedback datasets), what transformations occurred, and how the data moved across people, systems, and third parties over time. The control is satisfied by documented, repeatable recordkeeping that stands up to audit, not by informal team knowledge.

Plain-English interpretation (what the requirement means)

Data provenance means you can answer, with evidence:

• Where did this data come from? Internal system, customer-provided, third party, public source, partner feed.
• What is the lineage? Parent datasets, merges/joins, sampling, labeling, enrichment, de-duplication, filtering.
• What changed and when? Transformations, feature engineering, tokenization, anonymization/pseudonymization, quality checks, exclusions.
• Who had custody? Owners, approvers, processors, third parties, storage locations, access paths.

Auditors typically care less about having a perfect diagram and more about whether your records are complete, consistent, and reconstructable for the data actually used by the AI system that is deployed.

Who it applies to (entity + operational context)

Control A.7.5 applies broadly to organizations that build, buy, or use AI systems. ¹

You should treat the following as in scope:

• AI providers/builders: You train, fine-tune, or materially modify models; you design data pipelines; you publish models internally or externally.
• AI users/operators: You deploy third-party models but supply data for fine-tuning, retrieval-augmented generation, evaluation, or ongoing learning.
• Organizations with shared services: Central data platform teams, analytics, MLOps, model risk management, and security all touch custody and lineage.

Operationally, provenance is critical anywhere data crosses boundaries:

• Third-party data intake (data brokers, SaaS exports, labeling shops, consultants).
• Cross-domain data sharing (marketing to product, HR to analytics, customer data to AI).
• Production AI systems with frequent data refresh or continuous improvement loops.

What you actually need to do (step-by-step)

1) Define the provenance standard (one-page minimum)

Create a written “Data Provenance Standard” that states:

• What counts as “data used in AI systems” (training, evaluation, inference-time context).
• The minimum required provenance fields (see checklist below).
• Where records live (system of record) and retention expectations.
• Required approvals before a dataset can be used.

This is the document you will point to when auditors ask, “What does good look like here?” It also prevents each team from inventing its own version of provenance.

2) Establish dataset identity and ownership

You need stable identifiers so provenance records remain valid even as data changes.

• Assign dataset IDs and versioning rules (immutable versions, clear “latest” pointer).
• Name a dataset owner (accountable) and a data steward (operational).
• Define allowed storage locations (data lake zones, approved buckets, approved SaaS).

3) Implement provenance capture in your data pipelines

Operationalize provenance by capturing it where work happens:

• Ingestion: source system, export method, time of pull, credentials/service account used, third-party contract reference (if applicable).
• Transformations: code commit hash, job run ID, parameter set, schemas before/after.
• Quality gates: results of checks, exclusions applied, labeling QA outputs.
• Publishing: where the dataset version is stored, who approved promotion to “AI-approved.”

Manual processes can exist for low-risk pilots, but they tend to degrade quickly. Build provenance fields into pipeline templates and CI/CD checks so teams cannot bypass them.

4) Cover the full AI lifecycle, not only training

Many programs stop at training data and miss:

• Evaluation datasets (benchmarks, red team corpora, domain-specific test sets).
• Fine-tuning and feedback datasets (human feedback, support tickets, review labels).
• Inference-time data (retrieval indexes, vector stores, prompt libraries, grounding corpora).

Treat each as a dataset with the same provenance expectations, because they influence outputs and risk.

5) Add chain-of-custody controls (who touched it, and how)

Provenance records must align with access and change control:

• Access logging for storage and critical tables.
• Approval workflows for adding new sources and promoting datasets to production.
• Third-party handoffs documented (who sent it, how, what integrity checks you performed).

If you cannot show custody, you cannot credibly show provenance.

6) Create a “provenance packet” per AI system release

For each production AI system (and material updates), compile a release packet that references:

• Dataset IDs and versions used.
• Where provenance records are stored.
• Evidence of approvals and checks.
• Exceptions and compensating controls.

This packet becomes the single artifact auditors and risk committees ask for.

7) Monitor drift in provenance quality

Add ongoing checks:

• Orphan datasets used by AI jobs without a registered provenance record.
• Pipeline steps without logged transformation metadata.
• Third-party sources without an owner, contract reference, or intake review.

Provenance record checklist (minimum fields)

Use this as your baseline schema for a provenance record:

• Dataset name, ID, version, owner, steward
• Purpose and AI systems using it
• Source type (internal / customer / third party / public)
• Source details (system name, table/files, export method, date/time pulled)
• Legal/contract reference for third-party sources (contract/SOW reference ID)
• Collection context (business process, original purpose statement)
• Transformations (jobs, code references, parameters, feature generation)
• Labeling/enrichment details (who labeled, guidelines version, QA results)
• Storage locations (raw, processed, curated) and access controls reference
• Chain of custody (systems and parties that handled it)
• Known limitations (bias notes, coverage gaps, quality issues)
• Approval status for AI use and approver identity/date

Required evidence and artifacts to retain

Auditors look for durable, retrievable evidence. Keep:

• Data Provenance Standard (and change history). ¹
• Dataset register/inventory with owners and version history.
• Provenance records for each dataset version used by AI systems.
• Pipeline evidence: job logs, run IDs, code references, transformation metadata.
• Access and custody evidence: access logs, approvals, service account inventories.
• Third-party intake evidence: data-sharing terms, SOW references, delivery receipts, integrity checks performed.
• AI system release packets tying model versions to dataset versions.

A practical tip: store evidence pointers (links, IDs) in your GRC system while leaving raw logs in the engineering systems. The goal is fast retrieval during an exam.

Common exam/audit questions and hangups

Expect these questions:

• “Show me the training data sources for this production model, with versions.”
• “How do you know a dataset wasn’t altered after approval?”
• “Which third parties provided data used in this AI system?”
• “Where are transformation steps documented, and can you reproduce them?”
• “How do you prevent unapproved datasets from being used in model training or retrieval?”

Typical hangups:

• Teams can describe provenance verbally but cannot produce records quickly.
• Dataset versions are mutable (“we overwrite partitions”), which breaks lineage.
• Third-party datasets exist outside governed storage, so custody is unclear.

Frequent implementation mistakes (and how to avoid them)

1. Spreadsheet-only provenance tracking

   • Fix: make provenance capture part of ingestion and pipeline templates; require dataset registration before use.

2. Only tracking “source,” not “transformations”

   • Fix: require transformation metadata (job ID, code reference, parameters) for each curated dataset version.

3. Ignoring inference-time data

   • Fix: treat vector stores, retrieval corpora, prompt libraries, and cached indexes as governed datasets with versions and approvals.

4. No ownership

   • Fix: enforce named owners and stewards; block production use if ownership is blank.

5. Third-party data intake bypass

   • Fix: route all external data through a standardized intake workflow with custody logging and a contract reference.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak provenance increases your exposure in three ways:

• Inability to investigate incidents: you cannot trace problematic outputs back to specific data sources or transformations.
• Change-management failures: model behavior changes and you cannot explain why because data lineage is incomplete.
• Third-party and legal risk: if a third party challenges permitted use, you may not be able to prove chain of custody and allowed purpose tied to the dataset.

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Assign an executive owner and an operational owner for provenance.
• Publish the Data Provenance Standard with a minimum required field list.
• Identify AI systems in production or near-production and prioritize them.
• Stand up a dataset register and require ownership for any dataset used by prioritized systems.

Days 31–60 (instrument and gate)

• Implement provenance capture in ingestion and transformation pipelines for prioritized systems.
• Add release gating: no model promotion without dataset IDs, versions, and provenance pointers.
• Define third-party data intake workflow and require contract reference IDs in provenance records.
• Start building AI system “provenance packets” for the prioritized systems.

Days 61–90 (scale and audit-proof)

• Expand controls to evaluation and inference-time datasets (retrieval corpora, vector stores).
• Add monitoring for orphan/ungoverned datasets used by AI jobs.
• Run an internal audit-style drill: pick one production model and reconstruct lineage end-to-end from records.
• Operationalize exception handling (documented rationale, compensating controls, time-bound remediation).

Tooling note (where Daydream fits naturally)

If you are already tracking third-party relationships, data-sharing terms, and system inventories, Daydream can act as the coordination layer: map third-party data sources to AI systems, attach provenance artifacts and contract references, and generate audit-ready evidence packets without chasing artifacts across teams.

Frequently Asked Questions

Does “data provenance” mean I must track every single row back to origin?

ISO/IEC 42001 A.7.5 requires records of provenance for data used in AI systems, not row-level lineage in all cases. Capture enough lineage, transformation, and custody detail to reconstruct what datasets and versions influenced the AI system. ¹

We use a third-party foundation model. Are we still in scope?

Yes if you provide data that the AI system uses, such as fine-tuning data, evaluation sets, or retrieval/grounding corpora. You need provenance records for the data you supply and control. ¹

What’s the minimum viable provenance record for a pilot?

Start with dataset ID/version, owner, source details, purpose, transformation summary, storage location, and approval status. Expand to full chain-of-custody and transformation metadata before production release. ¹

Where should provenance records live: GRC tool or data platform?

Keep primary technical lineage in engineering systems (pipelines, catalogs, logs) and store pointers, approvals, and audit packets in your GRC system. Auditors need fast retrieval and clear accountability more than a single monolithic repository. ¹

How do we handle data transformations done by data scientists on laptops?

Treat unmanaged local transformations as a provenance risk. Require registered notebooks/code, controlled data access, and a path to reproduce transformations in managed pipelines before the dataset can be approved for AI use. ¹

What evidence is most persuasive in an audit?

A production AI release packet that ties model version to dataset versions, with provenance records, approvals, and pipeline logs that demonstrate transformations and custody. It should be possible to recreate the lineage without relying on staff memory. ¹

Footnotes

1. ISO/IEC 42001:2023 Artificial intelligence — Management system