Data Governance Framework: Components, Models, and a 90-Day Plan
A data governance framework is the set of decision rights, policies, roles, and controls that determines who can decide what about an organization's data and how those decisions are enforced in the systems where the data lives. Data governance itself is, in the DAMA-DMBOK definition, "the exercise of authority and control (planning, monitoring, and enforcement) over the management of data assets." A working framework names an owner for each critical data domain, sets quality and access rules for its critical data elements, and wires those rules into the catalog, the pipelines, and the access policies. BD Emerson starts every program with one or two critical domains and a 90-day plan, because a framework that tries to govern everything at once rarely changes anything in the platform.
What is data governance?
Data governance is the decision-making layer of data management. It sets who decides, by what rules, and with what evidence, while data management does the daily work of moving, storing, securing, and fixing data. The DAMA Wheel in DAMA International's Data Management Body of Knowledge shows eleven knowledge areas with data governance at the center, surrounded by disciplines such as data architecture, data quality, metadata, and data security, because each of those depends on decisions that governance makes. DAMA lists the second edition, revised in 2024, as current and began a DMBOK 3.0 effort in 2025.
In practice, governance answers four questions for every important dataset: who owns it, what it means, how good it has to be, and who may use it for what purpose. When those answers are written down, assigned to named people, and enforced in the platform, auditors, regulators, and AI teams can rely on the data. When they live only in a slide deck, the systems behave exactly as they did before.
The nine components of a data governance framework
A complete framework has nine components, and each one produces an artifact that someone owns and an auditor can inspect. The table lists them in the order BD Emerson builds them.
| Component | What it defines | Core artifact | Typical owner |
|---|---|---|---|
| Roles and decision rights | Who approves definitions, access, quality thresholds, and exceptions | Governance charter and RACI | Chief data officer or governance council |
| Policies and standards | The rules every dataset follows, from classification to naming | Data policy, classification standard, naming standard | Governance council |
| Data ownership and stewardship | Accountability for each domain and its critical data elements | Owner and steward register | Business data owners |
| Data quality | Measurable thresholds for critical data elements | Quality rules, thresholds, and scorecards | Data stewards |
| Metadata and cataloging | Business meaning, technical location, and lineage | Business glossary, data catalog, lineage maps | Metadata or platform team |
| Privacy and security | Classification, access, masking, and lawful use | Access policies, masking rules, records of processing | CISO and privacy officer |
| Lifecycle and retention | How long each class of data is kept and how it is disposed of | Retention schedule and legal hold procedure | Records management with legal |
| Issue management | How data problems are logged, triaged, escalated, and closed | Issue log with severity levels and service levels | Data stewards |
| Metrics | Evidence that the program changes outcomes | Governance scorecard | Governance lead |
Decision rights come first because every other component depends on them. A quality threshold without an owner who can approve it is a suggestion, and an access policy without someone authorized to grant exceptions gets bypassed the first time a deadline slips.
Reference models: DAMA-DMBOK, DCAM, and others
Reference models supply vocabulary, scope, and a maturity yardstick, and none of them is a project plan. The table summarizes the models BD Emerson sees most often and what each one is good for.
| Model | Publisher | What it covers | Best use |
|---|---|---|---|
| DAMA-DMBOK, second edition (revised 2024) | DAMA International | Eleven knowledge areas with data governance at the center, plus roles, activities, and deliverables | Shared vocabulary and program scope |
| DCAM v3 | EDM Council | Eight components, 34 required capabilities, and 101 sub-capabilities, scored against evidence | Scored maturity assessments and peer benchmarks, available to member firms |
| CDMC | EDM Council | 14 key controls for protecting data in cloud environments and meeting privacy requirements | A control set for cloud data platforms |
| ISO/IEC 38505-1 | ISO and IEC | Guiding principles for governing bodies on the use and protection of data | Board-level accountability |
| ISO/IEC 25012:2008 | ISO and IEC | Fifteen data quality characteristics, viewed as inherent or system dependent | Choosing quality dimensions for rules |
| Data mesh principles (2020) | Zhamak Dehghani | Domain ownership, data as a product, a self-serve platform, and federated computational governance | Federated operating models |
DCAM v3 suits organizations that need a scored baseline for a regulator or board, and the EDM Council's CDMC framework turns governance into 14 controls for data in the cloud. ISO replaced the 2017 edition of ISO/IEC 38505-1 with a 2026 edition, which gives boards a governance-of-data standard alongside ISO/IEC 38500 for IT. ISO/IEC 25012 is a useful checklist when stewards write quality rules, and Zhamak Dehghani's data mesh principles describe the federated end of the spectrum. BD Emerson's view is to borrow vocabulary from DAMA, scoring from DCAM when you need a benchmark, and controls from CDMC when your critical data sits in cloud platforms.
Centralized, federated, or hybrid: which operating model fits?
Pick the operating model that matches how the rest of the business makes decisions, because governance that runs against the company's structure gets ignored. DAMA-DMBOK describes centralized, replicated, and federated variants, and in practice three models cover most programs.
| Model | How decisions are made | Fits when | Main risk |
|---|---|---|---|
| Centralized | One governance office sets and enforces policies, definitions, and quality rules | Smaller firms, one dominant data platform, or a regulator-driven program on a short deadline | The central team becomes a queue, and domains route around it |
| Federated | Domains own their data and decisions inside a small set of global rules | Large firms with strong business units, or a data mesh | Definitions drift between domains when global standards are not enforced |
| Hybrid | A central office owns policy, classification, and shared definitions, and domains own stewardship and quality | Most mid-size and large enterprises | Unclear boundaries between central and domain decisions |
BD Emerson's decision rule is to start centralized for the first 90 days, even in a federated company, because the first domain needs one team that can make and record decisions quickly. Move to hybrid once two or more domains have named owners and working stewards, and hand decisions to domains only after the platform enforces the global rules.
How data governance supports regulatory compliance
Most data regulations ask for the same evidence: an inventory, an owner, a retention rule, access control, and proof of accuracy. A governance framework produces that evidence once and reuses it across regimes. The table maps specific obligations to the component that answers them; confirm how each one applies to your organization with counsel.
| Regulation | What it requires | Component that answers it |
|---|---|---|
| GDPR | Data minimization, accuracy, and storage limitation under Article 5(1)(c) to (e), accountability under Article 5(2), records of processing under Article 30, and erasure under Article 17 | Lifecycle and retention, data quality, metadata and cataloging |
| CCPA, as amended by the CPRA | Disclosure of how long each category of personal information is kept, and collection, use, retention, and sharing that is "reasonably necessary and proportionate" under Cal. Civ. Code section 1798.100, plus risk assessments under regulations in effect since January 1, 2026 | Lifecycle and retention, privacy and security |
| HIPAA | Minimum necessary use and disclosure under 45 CFR 164.502(b), and retention of required documentation for 6 years under 45 CFR 164.316(b)(2)(i) | Privacy and security, policies and standards |
| Sarbanes-Oxley Act | Management's assessment of internal control over financial reporting under Section 404, which reaches the systems and data behind the financial statements | Data quality, issue management, lineage |
| BCBS 239 | Fourteen principles for risk data aggregation and risk reporting, starting with governance and data architecture | Roles and decision rights, data quality, lineage |
| EU AI Act | Article 10 data governance and management practices for the training, validation, and testing data of high-risk AI systems | Data quality, metadata and lineage, privacy |
Two of these deserve more detail. BCBS 239, which the Basel Committee published in January 2013, applies first to global systemically important banks (G-SIBs) and turns governance into supervisory expectations for the accuracy, completeness, timeliness, and adaptability of risk data. The Committee's November 2023 progress report on 31 G-SIBs found "significant work remaining at most banks to fully adopt the Principles," seven years after the expected compliance date.
Article 10 of the EU AI Act requires the training, validation, and testing data sets of high-risk AI systems to be subject to data governance and management practices covering design choices, data origin, preparation, and examination for bias, and to be relevant, sufficiently representative, and, to the best extent possible, free of errors and complete. The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since July 27, 2026, deleted Article 10(5), moved the rules on processing special categories of personal data for bias detection into a new Article 4a, and set the application date for these high-risk requirements at December 2, 2027 for Annex III systems and August 2, 2028 for Annex I systems. For most AI teams, the data governance work behind Article 10 is the longest part of preparing for those dates.
A 90-day plan anchored on one or two critical data domains
Start with one or two domains that carry real risk or real value, and govern them completely before adding a third. BD Emerson picks the first domain with three tests: a regulatory report, financial statement, or AI use case depends on it, a business leader will accept ownership, and its quality problems already cost someone time each week. Customer data and revenue data pass all three in most companies.
| Phase | Days | Work | Exit criteria |
|---|---|---|---|
| Charter and owners | 1 to 30 | Approve the charter and decision rights, pick the domains, name owners and stewards, list 25 to 50 critical data elements (CDEs), and baseline their quality | A signed charter, named owners, and a CDE list with baseline scores |
| Rules and catalog | 31 to 60 | Approve classification, access, and retention policies, write glossary definitions and quality rules for each CDE, register the domain's tables in the catalog with lineage, and open the issue log | Approved policies, a catalog entry and rule for every CDE, and an issue log in use |
| Enforce and measure | 61 to 90 | Tag sensitive columns and apply masking and row-level policies, schedule quality checks that alert stewards, publish the first scorecard, and hold the first council decisions on exceptions | Policies enforced in the platform, a published scorecard, and a backlog for the next two domains |
The plan works because each phase ends with the platform behaving differently. If day 90 arrives with approved policies and no enforced tags, masks, or quality alerts, the program has produced documents, and the next 90 days belong to enforcement before any new domain starts. In a lakehouse, the enforcement work maps onto the layers in our medallion architecture guide: tag and mask in silver, and certify in gold.
How do you measure whether data governance works?
Useful metrics measure what changed in the governed domains: ownership, quality, enforcement, and response time. Each metric below comes from a system of record, so nobody has to self-report it.
| Metric | Definition | Source |
|---|---|---|
| Ownership coverage | Share of critical data elements with a named owner and steward | Data catalog |
| Quality pass rate | Share of quality rule runs that pass, by CDE and domain | Quality monitoring |
| Issue resolution time | Median days from logging a data issue to closing it, by severity | Issue log |
| Classification coverage | Share of columns in governed stores scanned and tagged for sensitivity | Catalog or discovery tool |
| Enforcement coverage | Share of sensitive-tagged columns with an active masking or row policy | Platform policy inventory |
| Lineage coverage | Share of regulated reports with lineage traced to source systems | Lineage tool |
| Request response time | Median days to fulfill data subject access and deletion requests | Privacy request system |
BD Emerson's 90-day targets for a first domain are full ownership coverage, a quality baseline for every CDE, and enforcement on every column tagged as sensitive. After that, the quality pass rate should rise quarter over quarter; a flat rate means the rules exist and nobody is fixing what they find.
Why AI governance depends on data governance
AI governance controls what models and agents do, and data governance controls what they know and can reach, so the second has to exist before the first can work. A retrieval-augmented assistant answers from whatever its index can read, and an agent with database tools inherits whatever permissions its service account holds. If ownership, classification, and access policies are missing, the AI system exposes the gap to every user who asks.
The standards make the dependency explicit. EU AI Act Article 10 governs training and testing data for high-risk systems, and ISO/IEC 42001, the AI management system standard, includes Annex A controls on data for AI systems covering data quality, provenance, and preparation. Our guide on how to build an AI governance framework covers the AI side. The practical shortcut is to register models, prompts, and agents in the same catalog as tables, so one set of owners and policies covers both.
Data governance tools by category
Tools enforce a framework, and none of them can define one. Four categories matter: enterprise catalogs and governance suites such as Collibra, Alation, Atlan, and Informatica; platform-native catalogs such as Databricks Unity Catalog, Snowflake Horizon Catalog, Microsoft Purview, and Google Cloud Knowledge Catalog; data quality and observability tools; and privacy and sensitive data discovery platforms such as BigID and Securiti. Buy the native catalog of the platform that holds most of your critical data elements first, and add an independent catalog when three or more platforms hold them. Our ranked guide to the best data governance tools compares ten platforms against a weighted rubric.
Data governance best practices
These practices separate programs that pass audits from programs that produce binders, and each one follows from the build sequence above:
- Name decision rights before writing policy: every policy states who approves it, who grants exceptions, and who can stop a noncompliant use.
- Govern critical data elements first: 25 to 50 CDEs in one domain teach more than a glossary of 2,000 terms that nobody owns.
- Enforce in the platform: a classification tag should trigger a mask or row policy automatically, and a failed quality rule should alert a named steward.
- Keep owners accountable and stewards hands-on: owners decide, stewards fix, and the governance office runs the process.
- Write retention into pipelines: a retention schedule that no job enforces leaves the oldest data in the riskiest place.
- Report one page to leadership each month: ownership, quality, enforcement, and open issues by domain.
- Register AI assets in the same catalog: models, prompts, and agents get owners, classifications, and lineage like any table.
Frequently asked questions
What is a data governance framework? A data governance framework is the set of decision rights, policies, roles, and controls that determines who can decide what about an organization's data and how those decisions are enforced. It covers ownership and stewardship, data quality, metadata and cataloging, privacy and security, retention, issue management, and metrics, and it names an accountable owner for each.
What are the main components of data governance? The nine components are roles and decision rights, policies and standards, data ownership and stewardship, data quality, metadata and cataloging, privacy and security, lifecycle and retention, issue management, and metrics. Decision rights come first, because every other component needs someone with the authority to approve rules and grant exceptions.
What is the difference between data governance and data management? Data governance decides: it sets who owns data, what the rules are, and how compliance is checked. Data management executes: it builds and runs the pipelines, databases, security controls, and quality processes that follow those rules. DAMA-DMBOK places governance at the center of its data management knowledge areas because each of them depends on governance decisions.
How long does it take to implement a data governance framework? BD Emerson plans 90 days to govern a first domain: 30 days for the charter, owners, and critical data elements, 30 for policies, catalog entries, and quality rules, and 30 for enforcement in the platform and a first scorecard. Enterprise coverage grows domain by domain after that, and we plan for two or three more domains per quarter once the model works.
Should we use DAMA-DMBOK or DCAM? Use DAMA-DMBOK for vocabulary and scope, and use DCAM when you need a scored maturity assessment or a peer benchmark, which financial services firms often do. The two work together. Add the EDM Council's CDMC controls if your critical data sits in cloud platforms, and ISO/IEC 38505-1 if the board wants a governance-of-data standard.
Who should own data governance? A chief data officer or a governance council owns the framework, business leaders own their domains' data, and data stewards own day-to-day definitions and quality. The platform team runs the tools and enforces policies in the platform, and the CISO and privacy officer own classification, access, and lawful use of personal and sensitive data.
If you are scoping a data governance program, our data strategy team can run the first 90 days with you, from the charter and critical data elements to enforced policies, and our data privacy consulting team can align the privacy and retention components with GDPR, CCPA, and HIPAA.
About the author
