What is Data Governance?
Data Governance is the set of policies, processes, roles and standards that define how an organization collects, manages, uses and protects its data. It is not a tool or a technology: it is an organizational and operational framework built as much on human decisions as on infrastructure.
Governance answers questions that every data organization eventually runs into: who has the right to modify this data? What is the official definition of an 'active customer' at our company — and why do Marketing and Finance report two different numbers? Where is our users' personal data stored? Who is accountable when a critical data point is wrong and feeds a bad KPI into an executive dashboard? Governance turns these unanswered questions into clear, documented and enforced policies.
Data Governance vs Data Management: what is the difference?
The two terms are frequently confused. Data Management is the broader term: it covers every technical and organizational practice used to manage the data lifecycle, from creation to archiving. Data Governance is a sub-domain of Data Management — it is the steering framework that defines the rules, responsibilities and standards that Data Management then implements technically.
In practice: Data Management builds and operates the pipelines, the data lake, the data warehouse and the tooling. Data Governance decides which data must meet which quality rules, who can access what, and how business definitions are arbitrated. The DAMA-DMBOK formalizes this relationship by placing Governance as the central domain that steers the 10 other domains of Data Management.
The scope of data governance
Data governance typically covers six operational domains: data quality (measuring and continuously improving it), metadata management (documenting data about data), master data management (a single source of truth for key entities), data lineage (end-to-end traceability of data flows), security and privacy (GDPR, regulatory compliance, access controls), and the data catalog (inventory and documentation of data assets).
These six domains do not operate independently: a data catalog without lineage is static documentation that quickly goes stale. A quality policy without Data Stewards to enforce it stays on paper. Effective governance orchestrates these domains coherently.
Governance applies at three levels: data (raw facts — '42', 'Paris', '2024-03-15'), information (interpreted data — 'customer age: 42 years'), and metadata (data about data — 'this column contains customer age in whole years, owner: CRM team, sensitivity: confidential'). A good data catalog governs all three levels.
Why Data Governance has become critical
Three converging forces have made Data Governance unavoidable in modern organizations: exponential data growth, increasing regulatory pressure, and the reliance of strategic decisions on trustworthy data. A fourth, emerging force — generative AI — amplifies and accelerates this need.
Data quality: a directly quantifiable business issue
An IBM study estimates that poor-quality data costs US businesses $3.1 trillion per year. The consequences are direct and numerous: executive dashboards that contradict each other (Marketing reports 12,000 active customers, Finance reports 9,500 — because 'active customer' is not defined the same way in both teams), marketing campaigns sent to invalid addresses, machine learning models trained on erroneous data that produce biased predictions, and accounting reconciliations that take weeks of manual work.
Poor data quality is not a technical problem — it is an organizational one. Data degrades because no one owns its quality, there is no shared definition of what 'good data' means, and there is no process to detect and fix anomalies. Governance is the organizational remedy to this problem.
Regulatory compliance: GDPR, the EU AI Act and beyond
GDPR (in force in Europe since May 2018) turned the governance of personal data into a legal obligation. Knowing exactly where every user's personal data lives, who accesses it, since when, for how long it is retained, and how to delete it on request (the right to erasure): these are legal requirements that only structured governance can meet systematically and with a full audit trail. Fines can reach 4% of global annual revenue — Amazon was fined 746 million euros in 2021, Meta 1.2 billion in 2023.
The EU AI Act (in force since 2024) adds a new regulatory layer that amplifies the need for governance: high-risk AI systems must document their training data (lineage, quality, detected bias), maintain audit logs and guarantee decision traceability. Data governance becomes the prerequisite for AI compliance.
Generative AI amplifies and reshapes the need for governance
Generative AI models deployed inside companies create three new governance risks. First, sensitive data disclosure: an employee who pastes confidential data into a ChatGPT prompt potentially exposes it. Second, amplified bias: an LLM fine-tuned on ungoverned data can reproduce and amplify the biases present in its training data. Third, uncontrolled RAG: a Retrieval-Augmented Generation system connected to an ungoverned data lake can surface incorrect, outdated or confidential information to unauthorized users.
According to IDC, the world's data volume was projected to reach 175 zettabytes by 2025. Without adequate governance, this exponential growth makes management and compliance proportionally more complex — every new ungoverned data source is a new risk to quality, security and compliance.
IDC DataSphere, 2020Key roles in data governance
Data governance distributes responsibility across a clearly defined set of roles. The most common mistake is assuming governance is the exclusive responsibility of the technical data team — it is a shared responsibility model between business and IT.
Chief Data Officer (CDO)
The CDO is the executive accountable for data strategy and governance at the enterprise level. They set the data vision, allocate resources, arbitrate ownership conflicts between domains, and represent the value of data to the executive committee. Still rare in the early 2010s, the role has since become widespread in large enterprises as data has turned into a strategic asset in its own right.
The CDO is distinct from the CTO (who owns infrastructure and systems) and the CIO (who owns business applications and IT). Their scope is specifically the value, quality and governance of data as a strategic company asset.
Data Owner
The Data Owner is a business role, not an IT one. They are the business leader accountable for a specific data domain: the CFO for financial data, the CHRO for HR data, the CMO for marketing data. They decide who can access data in their domain, validate the official business definitions (what counts as an 'active customer' for our department?), and are accountable to leadership for the quality and correct use of data within their scope.
A Data Owner does not need to be technical. Their role is to bring business authority and context. They delegate implementation to Data Stewards.
Data Steward
The Data Steward is the operational backbone of governance. They translate the Data Owner's policies into concrete action: documenting metadata in the data catalog (definitions, types, sensitivity, sample values), monitoring quality metrics, resolving detected anomalies, and training teams on best practices for entering and using data.
This is often a part-time role (20-30% of someone's time), held by business analysts, data analysts, or subject-matter experts close to the data. Naming a Data Steward without giving them dedicated time is a common mistake that dooms a governance initiative.
Data Custodian
The Data Custodian (often the Data Engineer in modern organizations) is the technical guardian of data. They manage the infrastructure (databases, data lake, ingestion pipelines), technically implement the access controls defined by the Data Owner (via IAM policies, Snowflake roles or data masks in Databricks Unity Catalog), and ensure the physical and logical security of data.
Data Council: the governance steering committee
The Data Council (or data governance committee) is the cross-functional steering body that brings together the CDO, the Data Owners of major domains, IT and legal representatives, and key business stakeholders. It meets periodically (monthly or quarterly) to arbitrate ownership conflicts, validate contested business definitions, prioritize quality initiatives, and approve governance policies.
The Data Council is the equivalent of a board of directors for data: it does not run day-to-day operations but makes the structuring decisions that steer the entire governance program.
The DAMA-DMBOK framework: the global reference
The DAMA-DMBOK (Data Management Body of Knowledge), published by DAMA International with its 2nd edition dating from 2017, is the most widely used reference for structuring data governance and management. It breaks data management into 11 knowledge domains organized around a central core: Data Governance.
The 11 DAMA-DMBOK domains
The DAMA-DMBOK structures Data Management into 11 domains: Data Governance (overall, central steering), Data Architecture (modeling the organization's data structures), Data Modelling & Design (designing logical and physical schemas), Data Storage & Operations (database management, performance, backups), Data Security (access controls, encryption, anonymization), Data Integration & Interoperability (ETL/ELT, APIs, event streaming), Documents & Content (managing unstructured documents), Reference & Master Data (reference data shared across systems), Data Warehousing & Business Intelligence (analytics), Metadata Management (managing active metadata), and Data Quality (measuring and continuously improving quality).
Governance is the central domain that steers the other 10: it defines standards, allocates responsibilities and tracks compliance within each of the other domains. This is why DAMA typically represents the DMBOK as a wheel, with Governance at the hub.
The CDMP certification: the professional standard
The CDMP (Certified Data Management Professional), issued by DAMA International, is the reference certification for data governance and data management professionals. It covers all 11 DAMA-DMBOK domains and comes in three levels: Associate (a 100-question exam on the DMBOK), Practitioner (specialization in 2 domains), and Master (specialization in 5 domains). The CDMP is increasingly requested in job postings for Data Governance Manager, Deputy CDO and Senior Data Steward roles.
The DAMA-DMBOK 2nd edition (2017) is the bible of data governance professionals. It structures 11 knowledge domains around a wheel model with Governance at the center. The CDMP certification derived from it is internationally recognized as the standard of competence in Data Management.
DAMA International, DAMA-DMBOK 2nd Edition, 2017The 6 dimensions of data quality
Data quality is not a binary notion (good or bad): it is measured across several independent dimensions, as defined by the DAMA-DMBOK. Understanding these dimensions is essential for designing meaningful quality tests and communicating with business teams about the real state of their data.
The 6 DAMA dimensions: completeness, accuracy, consistency, uniqueness, validity, timeliness
Completeness measures whether all expected data is present: a null email field in 30% of rows in a customer table is a completeness problem. Accuracy measures how well data reflects reality: a zip code that does not match the city is an accuracy problem. Consistency measures whether the same piece of information is identical across systems: a customer marked 'active' in the CRM but 'inactive' in the billing system is a consistency problem.
Uniqueness measures the absence of duplicates: two records for the same customer with different IDs create manual deduplication work and skew analysis. Validity measures conformity to an acceptable range of values: an age of -3 or 150 is invalid even if present. Timeliness measures whether data is available when and to whom it is needed: accurate data delivered three days late can be useless for real-time use cases.
Measuring and monitoring quality: Great Expectations, Monte Carlo, dbt tests
Great Expectations is the reference open-source Python library for writing declarative data quality tests. You define 'expectations' (assertions about the data) — expect_column_values_to_not_be_null, expect_column_values_to_be_between — that run automatically in pipelines and generate documented HTML reports. It is the unit test, applied to data.
Monte Carlo is the market-leading Data Observability platform: it continuously monitors quality metrics (freshness, volume, schema, value distribution) and automatically detects anomalies (a table that has not been updated in 3 hours when it usually refreshes hourly). dbt ships native quality tests (not_null, unique, accepted_values, relationships) built directly into SQL transformations. Soda is an open-source alternative to Monte Carlo for data observability.
The empirical rule for the cost of quality: fixing a data error at the point of entry costs $1. Detecting and fixing it during integration costs $10. Fixing it after it has already affected an executive report or an ML model can cost $100 (or more, in terms of the bad decisions made on top of it). Investing in prevention and early detection is always cheaper than fixing things late.
Data lineage: tracing the data lifecycle
Data lineage is the complete traceability of a data point's journey: where it comes from (source system), what transformations it went through (ETL, SQL, dbt models), where it is stored, who consumes it, and in which reports or models it appears. It answers the question: if this 'revenue' column in my dashboard is wrong, where is the problem coming from?
Without lineage, impact analysis is impossible: when a source schema changes (a field renamed, a type changed), there is no quick way to know which pipelines, tables and reports are affected. With complete column-level lineage, that analysis takes seconds in the catalog tool.
Table-level vs column-level lineage
Table-level (or dataset-level) lineage shows that the 'fact_orders' table is fed by 'raw.orders' through a dbt transformation — but it does not say which column comes from which source. This is useful for understanding overall architecture but insufficient for debugging and compliance.
Column-level lineage traces every column individually: 'the revenue column in the Q4 report comes from the amount column in raw.transactions, transformed by the staging.stg_transactions view and then aggregated in mart.fct_revenue.' This is the level required by GDPR (tracing personal data across every system) and by the EU AI Act (documenting the training data of AI models).
OpenLineage, DataHub and lineage tools
OpenLineage is the open (CNCF) standard for emitting and collecting real-time lineage events from orchestrators (Airflow, Prefect, Dagster) and transformation frameworks (dbt, Spark). It lets teams aggregate lineage from multiple tools into a single central catalog. Marquez is the reference open-source OpenLineage backend.
DataHub (open-source, built at LinkedIn) and Apache Atlas are the open-source data catalogs that natively integrate lineage. Collibra and Alation offer automated lineage in their enterprise tiers. dbt automatically generates a lineage graph of every SQL transformation defined in a project — visible in dbt Docs — and exports it through DataHub or OpenLineage integrations.
There are two approaches to collecting lineage. Passive (or static) lineage parses SQL code or dbt definitions at compile time — quick to set up but can miss dynamic transformations or undocumented sources. Active (or dynamic) lineage intercepts execution events in real time via OpenLineage — more accurate and always current, but requires integration in every tool of the pipeline. Combining both is recommended for complete governance.
Data governance tools
Data governance relies on two main categories of tools: data catalogs (inventory, documentation and lineage) and data quality / data observability tools (monitoring and remediation). The choice of tool should follow organizational maturity — not the other way around.
Enterprise data catalogs: Collibra, Alation, Atlan
Collibra is the historical enterprise market leader, with advanced stewardship features (approval workflows for business definitions), end-to-end lineage, GDPR compliance (mapping personal data) and a business glossary. It targets large organizations with complex governance needs and sizeable budgets.
Alation stands out with a recommendation engine built on real SQL query usage patterns — it recommends the most trustworthy tables and columns based on observed usage. Atlan is the modern cloud-native option, very popular among younger data-driven organizations (data mesh, dbt-first), with a highly collaborative interface and native dbt, Airflow and Snowflake integrations.
Open-source alternatives: DataHub, OpenMetadata, Apache Atlas
DataHub (open-source, created at LinkedIn, maintained by Acryl Data) is the most widely adopted open-source data catalog in modern ecosystems. It supports automated lineage from dbt, Airflow, Spark and Kafka, a business glossary, sensitivity tags and access policies. Apache Atlas remains the reference in Hadoop/Cloudera ecosystems.
OpenMetadata is a newer alternative aiming to become the most complete open-source catalog: lineage, data profiling, built-in quality tests, collaboration, an open API. Databricks' Unity Catalog is not a traditional data catalog but provides centralized governance (ACLs, data masking, lineage) across every asset in a Databricks Lakehouse.
Data quality and data observability
Great Expectations is the reference open-source Python library for declarative quality tests. Monte Carlo is the leading Data Observability platform — it automatically detects freshness, volume, schema and distribution anomalies on critical tables. Soda Core (open-source) is an alternative to Great Expectations with native cloud support and declarative YAML checks. dbt tests remain the recommended starting point for dbt-first organizations.
How to start a governance initiative in 90 days
Data governance is not deployed as a 6-month project with an enterprise tool and a new department. It is an ongoing program that starts with quick wins on a narrow scope and expands progressively as it demonstrates value.
The key steps to get started (90 days)
The first 90 days should produce visible results. Month 1: identify Critical Data Elements (CDEs) — the 20% of data that generates 80% of business value (customers, products, revenue). Name Data Owners for these domains. Build a minimal business glossary with the 20 most disputed definitions. Month 2: implement the first quality tests (Great Expectations or dbt tests) on the identified CDEs. Document this data in a minimal data catalog (this can be an enriched Confluence page before rolling out Collibra). Month 3: present the first quality metrics to the Data Council. Show concrete value: 'We reduced customer duplicates by 23%, and HR and Finance now use the same definition of FTE.'
Centralized vs federated governance: which model to choose?
Centralized (hub-and-spoke) governance puts the central Data Governance team at the core of the system: it defines standards, tools and processes, and business domains apply them. This fits smaller or heavily regulated organizations (banking, insurance, healthcare) where consistency and compliance take priority over speed.
Federated (or distributed) governance, aligned with Data Mesh thinking, gives business domains the autonomy to define and manage their own data, with a central team that sets minimum standards (interoperability, security, metadata quality) without controlling content. This fits large, decentralized organizations where iteration speed is critical. In practice, most organizations adopt a hybrid model: centralized standards and tooling, federated responsibility and execution.
The most common mistake is buying Collibra or Alation before naming Data Owners, defining processes or allocating time to Data Stewards. A data catalog without active stewards becomes an empty repository within 6 months — exactly like a company wiki nobody maintains. Tools amplify governance that already exists; they do not create governance that does not.
Explore the Data & AI cluster
Frequently asked questions about Data Governance
What is Data Governance?
Data Governance is the set of policies, processes, roles and standards that define how an organization collects, manages, uses and protects its data. It answers questions like who owns which data, who can access it, how it is defined, and how its quality is assured. It is not a tool but an organizational framework.
What is the difference between Data Governance and Data Management?
Data Management is the broader term: it covers every practice used to manage the data lifecycle (pipelines, storage, quality, security). Data Governance is a sub-domain of Data Management — it is the steering framework that defines the rules, responsibilities and standards that Data Management then implements technically. The DAMA-DMBOK places Governance at the center of the 10 other Data Management domains.
What is the difference between a Data Owner and a Data Steward?
The Data Owner is a business leader who holds authority over a data domain — they decide on policies and validate business definitions. The Data Steward is an operational role that implements these policies: documenting metadata, monitoring quality, and fixing issues day to day. The Data Owner sets direction; the Data Steward executes.
What is the DAMA-DMBOK?
The DAMA-DMBOK (Data Management Body of Knowledge) is the global reference for data management, published by DAMA International (2nd edition, 2017). It structures Data Management into 11 knowledge domains, with Data Governance as the central domain that steers the other 10. The CDMP (Certified Data Management Professional) certification is based on this framework.
What are the 6 dimensions of data quality?
The DAMA-DMBOK defines 6 dimensions: Completeness (all expected data is present), Accuracy (data reflects reality), Consistency (the same value across every system), Uniqueness (no duplicates), Validity (data conforms to accepted values) and Timeliness (data is available when needed). Great Expectations and dbt tests let you measure these dimensions automatically in pipelines.
What is data lineage?
Data lineage is the complete traceability of a data point's journey: where it comes from, what transformations it went through, and where it is consumed. Column-level lineage traces every column individually. It is essential for impact analysis (knowing which pipelines are affected when a source schema changes), GDPR compliance, and EU AI Act requirements. OpenLineage is the open standard; DataHub and dbt offer automated lineage.
How is Data Governance related to GDPR and the EU AI Act?
GDPR requires knowing exactly where personal data is stored, who accesses it, how long it is retained, and how to delete it on request. The EU AI Act (2024) requires documenting the training data of high-risk AI models (lineage, quality, bias). Data Governance is the organizational framework that makes it possible to meet these obligations systematically and with a full audit trail.
What is a data catalog?
A data catalog is a centralized inventory of an organization's data assets: tables, columns, files, reports, ML models. It documents metadata (business definition, owner, sensitivity, lineage) and lets teams discover and understand the data available to them. Leading tools include Collibra, Alation and Atlan (enterprise) and DataHub, OpenMetadata (open-source).
What is Master Data Management (MDM)?
Master Data Management is the management of reference data shared across multiple systems: customers, products, suppliers, employees. The goal is to maintain a single, reliable 'golden record' for each entity to avoid inconsistencies between systems (a customer with 3 different IDs in 3 different systems).
Where should you start a Data Governance initiative?
Start by identifying your Critical Data Elements (CDEs) — the 20% of data that generates 80% of business value. Name Data Owners for these domains. Build a minimal business glossary with the 20 most contested definitions. Implement the first quality tests on the CDEs. Present the results to the Data Council after 90 days. Prioritize quick wins on a narrow scope over a global program.