Data as a product: why trust and governance still lag

At a glance

What this is: This is an analysis of why data-product thinking only works when governance, lineage, access and reliability are built into the pipeline, not layered on afterward.

Why it matters: It matters because IAM and data-governance teams increasingly control who can consume trusted data products, how provenance is preserved and which datasets can be reused safely across analytics and AI use cases.

By the numbers:

• Modern organisations generate around 400 million terabytes of data per day, according to DataBahn.
• IoT devices alone exceed 21 billion by 2025, according to DataBahn.
• 76% of companies say data-driven decisions are a top priority, according to DataBahn.
• 67% of companies admit they do not fully trust their data, according to DataBahn.

Context

Data as a product is a governance model for making datasets discoverable, owned and reliable enough to reuse at scale. The problem is that most organisations still treat data as raw exhaust, so lineage, access control and quality assurance lag behind demand.

That gap matters to identity and access teams because trusted data products depend on enforced access boundaries, clear ownership and auditable consumption paths. In practice, the article is arguing that data trust is no longer just a data-engineering issue; it is an entitlement and governance issue as well.

Key questions

Q: What breaks when data products do not have clear ownership?

A: When data products do not have clear ownership, requests stall, quality issues linger and no one is accountable for definitions or lifecycle changes. The marketplace becomes a directory of assets without a governance owner behind each one. That leads to duplicated pipelines, inconsistent use and unresolved access disputes.

Q: Why do lineage and metadata matter so much for trusted analytics?

A: Lineage and metadata let consumers judge where data came from, how it was transformed and whether it is fit for reuse. Without them, analysts and automated systems are forced to trust outputs blindly, which increases the chance of bad decisions, duplicated effort and hidden errors spreading across downstream products.

Q: How should organisations govern reusable data across multiple teams?

A: Organisations should combine domain ownership with federated guardrails, so local teams manage their products while central policy defines quality, access and documentation standards. That model preserves agility, but it only works if the standards are enforced consistently and the catalog stays current as products change.

Q: When does a data product model actually improve trust?

A: It improves trust only when quality checks, access controls and provenance are enforced before consumption. If the product is merely labelled and catalogued without those controls, it still behaves like raw data with better packaging, and users will eventually stop relying on it.

Technical breakdown

What changes when data is treated like a product?

Data as a product applies product-management discipline to datasets. That means each dataset has an owner, a documented purpose, a defined interface, and service-level expectations for freshness, quality and availability. The model works only when the dataset is packaged for consumption, not just stored for later use. In governance terms, this shifts data from passive inventory to an actively managed service with lifecycle responsibilities. It also creates a clearer boundary between source data, curated product data and downstream reuse. Practical implication: teams must assign explicit accountability for each data product and treat its quality commitments as enforceable controls.

Practical implication: assign explicit ownership and enforce service-level expectations for each data product.

Why do lineage and metadata determine trust?

Lineage tells consumers where data came from, what transformed it, and how far it can be trusted. Metadata provides the business meaning, schema context and usage guidance that make the product understandable to non-producers. Without those two pieces, even accurate data becomes hard to reuse because users cannot judge provenance or interpret fields confidently. This is why data-product models pair catalogs, glossaries and transformation records with the dataset itself. In identity terms, the governance question is not only who can see the data, but whether consumers can prove what they are consuming and how it changed. Practical implication: lineage and metadata should be mandatory inputs to every approval for reuse.

Practical implication: make lineage and metadata mandatory inputs to every reuse decision.

How do pipeline controls turn data quality into an enforceable property?

A data product only earns trust when quality is checked before consumption. That requires validation gates, monitoring, alerting and policy enforcement in the pipeline, rather than post-hoc clean-up in dashboards or reports. The article’s layered architecture, with Bronze, Silver and Gold stages, is a way to isolate raw ingestion from curated output and verify quality step by step. This is also where access control matters, because policy has to travel with the data product as it moves. Practical implication: push quality checks and access rules upstream so bad or unauthorised data never becomes a trusted product.

Practical implication: push quality checks and access rules upstream so bad or unauthorised data never becomes a trusted product.

NHI Mgmt Group analysis

Data-product governance is now an access-control problem, not just a data-model problem. The article frames trust as a function of ownership, lineage and reliability, but the deeper issue is that consumption rights determine whether a product is actually safe to reuse. If consumers cannot be tied to specific entitlements and policy enforcement points, then “trusted data” remains a naming convention rather than a governed state. The practical conclusion is that data-product programmes should be reviewed alongside identity and access governance, not only within data engineering.

Trusted data products create a new entitlement surface. Once datasets are packaged for repeated use, they behave more like governed services than passive tables. That means access review, lifecycle ownership and logging become part of the product contract. The governance burden shifts from one-time publication to continuous authorization and provenance assurance, which is where many programmes still fall short. The practitioner takeaway is that reusable data should be treated as a controlled service with explicit consumption rules.

Lineage is the named control gap that separates useful data from usable data. The article repeatedly points to hidden lineage as a reason trust lags behind demand, and that is the right framing. Lineage is not merely documentation, because it determines whether downstream teams can assess integrity, trace transformations and avoid blind reuse. In governance terms, incomplete lineage makes every downstream decision more fragile. Practitioners should treat lineage quality as a control objective, not a reporting artifact.

Productising data does not remove governance debt, it concentrates it. Packaging datasets for broad reuse increases the impact of weak controls because one broken product can spread bad assumptions across multiple teams and models. That is why federated governance only works when standards are enforced consistently at the domain level and validated centrally. The field should stop treating data products as a shortcut around governance. They are a stricter form of governance, and the control model has to match that reality.

What this signals

Data-product programmes will increasingly be judged by control integrity, not by catalog size. The useful question for practitioners is whether ownership, lineage and access enforcement survive contact with real consumers. If those controls are weak, the product layer simply accelerates the spread of inconsistent data across analytics and AI workflows.

Trusted reuse creates governance pressure on identity and entitlement processes. As more teams consume shared datasets, security teams need to know which users, workloads and services are authorised to access each product and why. The control challenge shifts from data publication to persistent entitlement management.

Data productisation exposes a specific trust gap: the system knows where data lives, but not always whether it is safe to consume. That is why lineage, freshness and access policy need to be enforced as operational controls rather than treated as documentation.

For practitioners

• Assign a named owner to every data product Make one team accountable for accuracy, availability, remediation and documentation so there is no ambiguity about who fixes broken or stale data.
• Enforce lineage before reuse Require source, transformation and dependency lineage to be present in the catalog before any dataset can be promoted for broad consumption.
• Embed access policy in the delivery path Apply read and subscription rules in the pipeline so only approved consumers can subscribe to high-trust data products and sensitive fields stay protected.
• Validate freshness and quality at each layer Use Bronze, Silver and Gold stage checks to stop low-quality data from reaching trusted downstream products or analytics consumers.
• Treat the data catalog as a control plane Keep schemas, glossary terms, SLAs and usage guidance current so the catalog becomes the operational record for governed reuse.

Key takeaways

• Data-as-a-product only works when ownership, lineage and access rules are enforced as controls, not treated as documentation.
• The article’s core evidence is a scale problem and a trust problem, with huge data volumes colliding with weak governance and fragmented reuse.
• Practitioners should treat the catalog, policy enforcement and quality checks as part of the same governance plane.

Key terms

• Data Product: A data product is a curated data asset with named ownership, defined meaning, and expected quality. It gives AI systems a stable source of business truth rather than an informal dataset that different teams may interpret differently.
• Lineage Graph: A lineage graph is the connected record of how data assets, models, prompts and outputs relate to one another across a system. In AI governance, it provides the structural view needed to explain dependencies, identify change impact and support decisions when an AI result is questioned.
• Federated Governance: A governance operating model where central teams define policy and control standards, but business domain owners make access decisions inside those guardrails. It fits organizations where risk, process knowledge, and operational responsibility are distributed across functions, regions, or platforms.
• Data Catalog: A data catalog is an inventory and classification layer for data assets. It helps organisations identify what data they have, who owns it, and how it should be governed, which makes it a practical foundation for privacy, stewardship, and access control in complex environments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It is designed for practitioners who need to connect identity control to broader security and data governance programmes.