Data lineage use cases: what they mean for your governance program

Your CFO flags a number in the board pack. You escalate. Three days later, your data engineering team confirms the pipeline ran without errors – but nobody can show the regulator where the figure originated, who approved the transformation, or which source system it came from. The pipeline is fine. The governance evidence is not.

This is the gap that data lineage use cases exist to close. Not the pipeline monitoring ones that data engineers care about – the governance accountability ones that CDOs and regulators care about. They are related but they are not the same thing, and confusing them is exactly why lineage programs fail to deliver what the business actually needs.

Key takeaways

• Data lineage use cases fall into two fundamentally different categories: engineering observability and governance accountability – and most organisations implement the first while assuming they get the second automatically
• In regulated EU industries, regulatory compliance – GDPR, DORA, BCBS 239 – is the highest-value lineage use case and the most underimplemented
• Data quality root cause analysis delivers the fastest time-to-value: lineage cuts investigation cycles from days to hours by pinpointing exactly where data broke and who owns it
• Impact analysis before system migrations is the risk reduction use case that often pays for an entire lineage implementation in a single project
• Business lineage (connecting source data to KPIs and regulatory reports) requires different implementation choices than technical lineage (pipeline monitoring) – and most tools default to the latter
• Collibra’s lineage capabilities cover governance use cases that DataOps tools don’t – but only when the implementation is scoped and activated for that purpose

What data lineage use cases actually mean

Data lineage use cases are the specific business problems that data lineage tracking enables organisations to solve – from regulatory audit readiness to data quality root cause analysis and migration risk management.

The definition is simple. The execution is where it gets complicated.

Most articles on this topic are written by data engineering tool vendors. Their use cases – pipeline monitoring, SQL query tracing, dbt model debugging – are legitimate. But they describe what data engineers do with lineage. A CDO or Data Governance Manager needs something different: lineage as governance evidence. Lineage that answers “where did this number come from and can we prove it?” rather than “why did this query fail?”

The distinction matters enormously when scoping a lineage implementation or choosing a platform. For a deeper look at how data lineage and data governance relate to each other structurally, see our article on data governance vs data lineage.

Use case 1: Regulatory compliance and audit readiness

This is the use case that drives lineage investment in banking, insurance, pharma, and any EU-regulated industry – and the one most implementation projects fail to fully activate.

Regulators don’t ask “is your pipeline healthy?” They ask:

• Where does this figure in your risk report originate?
• Which systems processed this personal data, and when?
• Can you demonstrate end-to-end traceability from source to submission?
• Who had access to this data at each stage of processing?

Data lineage is what makes those questions answerable.

GDPR

Under GDPR Article 30, controllers and processors must maintain a Record of Processing Activities (RoPA)  – which means knowing where personal data flows, how it is transformed, and which systems it passes through. Without lineage, those records are either incomplete or maintained manually, which creates both compliance risk and audit overhead. Lineage makes the map automatic and auditable.

BCBS 239

For banks subject to BCBS 239, the requirements are even more specific. The European Central Bank (through supervisory expectations on BCBS 239 compliance) clarifies that lineage must be complete – covering all data flows across all systems – and traceable to the attribute level. “We have a data warehouse” is not sufficient. “We can show you the column-level provenance of every number in this regulatory report” is. BCBS 239 compliance without proper lineage is not a stable position.

DORA

The Digital Operational Resilience Act requires financial institutions to map critical data flows and demonstrate operational resilience across their technology landscape. Lineage provides the dependency map that makes this possible – showing which systems and data flows underpin which business processes and reports.

Organisations preparing for BCBS 239 assessments or DORA audits frequently engage external teams specifically for lineage scoping and implementation, because the technical and governance requirements are distinct from standard data engineering work. If your organisation is at this stage, our Collibra consulting overview explains how we approach it.

Use case 2: Data quality root cause analysis

When a report shows the wrong number, someone has to find where it broke. Without lineage, that investigation typically involves a data engineer querying multiple systems, a data steward cross-referencing source files, and several days of back-and-forth before anyone knows which transformation introduced the error.

With lineage, the path is visible. You can trace backwards from the output to every upstream transformation, join, and source – and identify not just where the data broke, but who owns that step in the pipeline.

We’ve seen this repeatedly in client environments: what used to be a three-day root cause investigation becomes a same-day fix, because the lineage map shows exactly where the problem is. More importantly, it shows who is accountable – which is what actually prevents the same error from recurring.

This use case connects directly to data quality framework work: lineage is what gives data quality rules teeth by linking failures to specific data sources and owners rather than treating them as abstract metadata problems. For Collibra-specific data quality capabilities, see our Collibra data quality overview.

Use case 3: Impact analysis before system changes and migrations

Before you change a source system schema, retire a database, migrate from an on-premise data warehouse to cloud, or upgrade an ERP – you need to know what breaks downstream. Without lineage, that analysis is manual, slow, and incomplete. Teams discover dependencies they missed only after something stops working in production.

Data lineage maps answer the impact analysis question before the change happens:

• Which reports, dashboards, and analytics depend on this data source?
• Which downstream models or ML pipelines consume this table?
• Which regulatory outputs reference this field?
• Which data stewards need to be notified before this change goes through?

This is particularly high-value in SAP and ERP migration contexts. When critical business data moves from legacy systems to S/4HANA, or when SAP data needs to be visible in Collibra alongside other enterprise sources, lineage is what makes the migration plannable rather than chaotic.

We built a custom SAP-to-Collibra lineage implementation for a client that needed to track data flows across MDG, BW, data lakes, and BI reporting – specifically to enable impact analysis and transparency before system changes. That work is documented in our custom Collibra SAP lineage case study.

In a separate project for a pharmaceutical company, we implemented Snowflake custom technical lineage in Collibra – processing 65,000 queries in three hours and giving the client full visibility into data flows without ever needing to log into Snowflake directly. Both projects demonstrated the same principle: lineage pays for itself when it prevents a migration from going wrong.

Use case 4: AI and ML model governance

This use case has moved from theoretical to urgent since the EU AI Act entered into force in 2024.

As organisations deploy machine learning models into production – and as the EU AI Act introduces accountability requirements for high-risk AI systems – the question of data provenance becomes regulatory, not just technical. Which data was used to train this model? Was it complete, accurate, and processed correctly? Does it include personal data that may create GDPR obligations for the model’s outputs?

Without lineage, these questions cannot be answered with confidence. With lineage, the full trail from raw data source through feature engineering to training dataset is traceable and auditable.

For organisations running AI governance programs in Collibra, lineage connects the model registry to the data it depends on – creating the accountability chain that regulators and internal risk functions increasingly require. See our Collibra AI governance overview for how this is implemented in practice.

Business lineage vs. technical lineage – choosing the right scope

Most organisations implement technical lineage first. It is faster to deploy, easier to automate, and immediately useful for data engineers. But technical lineage and business lineage solve different problems.

	Technical lineage	Business lineage
What it tracks	Tables, columns, SQL queries, ETL jobs, pipeline steps	KPIs, reports, business glossary terms, regulatory outputs
Who uses it	Data engineers, BI developers	CDOs, Data Governance Managers, compliance teams
Primary use case	Debugging, pipeline monitoring, migration planning	Audit readiness, report certification, impact on business outcomes
Key question answered	Why did this query fail?	Where does this number come from?
Collibra capability	Technical lineage via connectors (Snowflake, SAP, dbt)	Business lineage via data catalog, business glossary linkage

The gap between them is where most governance programs get stuck. Technical lineage exists and functions correctly. Business lineage has not been implemented. The data engineering team can trace any query in the stack. The CDO cannot explain a regulatory report figure to an auditor. We call this “Pipeline Paradox”.

Both types are available in Collibra, but they require different implementation choices and different activation work. Collibra data lineage covers the platform capabilities in detail. For the distinction between lineage and the broader catalog, see data catalog vs data lineage.

Signs your data lineage use cases aren’t delivering

These are the signals we see most often in organisations that have lineage tooling but have not realised the governance use cases.

#1 Engineers can trace data but compliance cannot produce audit trails. The pipeline team has full visibility in their tooling. The compliance team is still building audit responses manually. This is the Pipeline Paradox in practice.

#2 Data quality investigations still take days. If root cause analysis requires cross-team coordination and multiple system queries despite having lineage, the lineage is not connected to the right assets or the right owners.

#3 Lineage maps exist at the table level only – column-level has not been activated. For BCBS 239 and GDPR purposes, table-level lineage is typically insufficient. Regulators require attribute-level traceability. If column-level lineage has not been scoped and implemented, you have an incomplete compliance posture.

#4 Business glossary terms are not connected to lineage. If your business glossary and your lineage live as separate objects in Collibra with no linkage between them, business users cannot navigate from a KPI definition to the data source that produces it. This breaks the core governance use case.

#5 SAP or ERP data appears in reports but lineage stops at the data warehouse boundary. Cross-system lineage that does not extend to source ERP systems leaves a significant gap in both root cause analysis and regulatory reporting traceability.

#6 Teams are not using the lineage that exists. Adoption is the final signal. If lineage maps are technically complete but nobody outside the data engineering team uses them, the business lineage use cases have not been realised. Measuring this is part of a healthy data governance metrics program.

When to handle data lineage in-house vs. bring in experts

Some lineage implementations are genuinely straightforward. Others are not. The distinction matters for scoping and budget.

Handle in-house when: Your data stack is modern and homogeneous (Snowflake, dbt, a standard BI tool), your regulatory requirements are limited, you have experienced data engineers available, and your use case is primarily technical lineage for pipeline monitoring.

Bring in experts when:

• You have regulatory compliance requirements (BCBS 239, DORA, GDPR audit readiness) that require business lineage, not just technical lineage
• Your environment includes SAP, legacy ERP systems, or custom data sources that require non-standard connectors
• You are implementing Collibra lineage after a previous attempt that did not deliver business value – this is a scoping problem as much as a technical one
• Your lineage implementation needs to connect to business glossary, data ownership, and data quality workflows, not just map technical pipelines
• Column-level lineage is required for compliance purposes

If your organisation is activating data lineage in Collibra or assessing which use cases to prioritise first, our Collibra use case implementation team works specifically with regulated EU enterprises on this. We also provide Collibra technical implementation teams for organisations that need dedicated delivery capacity.

Frequently Asked Questions