Enterprise Data Governance

Executive summary

Every organization already governs its data, whether or not it has a program. The question is whether decisions about data are made deliberately, by accountable people against stated rules, or by default, by whoever touches the data last. Data governance makes those decisions explicit: it assigns authority over data assets, sets the policies and standards that bound everyday data work, and provides the forums through which conflicts are resolved and exceptions granted. It succeeds only when it changes decisions that would otherwise have gone differently.

This paper argues that governance should be federated by default, with enterprise minimums: a small central function sets the non-negotiable floor of policies, shared standards, criteria for critical data elements and shared services such as the catalog, while business domains own the data they create and make most operational decisions within that floor.

• Governance decides and oversees; data management executes, IT governance directs technology, and compliance is one of several outcomes.
• Programs fail for predictable reasons: compliance-only framing, paper decision rights, committee overload, tool-first starts and no link to business outcomes.
• The framework has six components: strategy and charter, policy hierarchy, organization and roles, core processes, metrics, and technology enablers.
• Decision rights are written as a RACI across the executive data council, domain owners, stewards, custodians and the governance office.
• Governance is measured by what it changes: coverage of critical data elements, issue cycle time, policy adoption, data quality trends and consumer satisfaction.

The closing section lays out a staged path: a first 90 days focused on sponsorship, charter, priority domains and a baseline; a first year that establishes the policy set, operating model and first scorecard; and a steady state in which governance is embedded in the processes where data decisions are made.

Why governance matters now

Data governance is the part of data management that decides; every other discipline executes within the decisions it makes.

Three forces have made data governance an executive concern. Regulators expect organizations to demonstrate accountability for the data they hold: the accountability principle of the General Data Protection Regulation (GDPR), the risk data aggregation principles that banking supervisors apply under BCBS 239, and the data governance obligations for high-risk artificial intelligence (AI) systems under the EU AI Act all presume that someone is accountable for specific data and can show how it is controlled. Analytics and AI have raised the cost of poor data from inconvenience to business risk. And data mesh and data product architectures distribute ownership, which makes explicit decision rights more necessary, not less.

Governance is also the data capability most often launched, stalled and relaunched. Each relaunch arrives under a new name and stalls for the same reasons: it was framed as compliance, it had no authority, it drowned in committees, it started with a tool, or it never connected to an outcome anyone was paid to deliver. The remedies are structural rather than motivational, which is why this paper spends as much time on decision rights, bodies and funding as on principles.

Defining data governance

DAMA-DMBOK defines data governance as the exercise of authority and control, through planning, monitoring and enforcement, over the management of data assets. Authority means that governance decides: it sets policy, approves or refuses, and arbitrates when functions disagree. Over the management of data means that governance is not itself the management of data; it directs and oversees the architecture, quality, metadata, security and integration work that other disciplines perform. In practice that authority is exercised through shared decision-making, because no single function understands the meaning, the risk and the technical reality of enterprise data at once.

The practical working definition is therefore a system of decision rights and accountabilities: who may decide what, about which data, within what constraints, and who answers for the result. A program that cannot say who approves a new use of customer data, or who may change the definition of revenue, has not yet established governance, however many policies it has published.

Governance and data management

DAMA-DMBOK places governance at the center of its framework, surrounded by the knowledge areas that execute data management, from architecture and modeling through integration, security, metadata and data quality. One sets the rules, approves exceptions and verifies compliance; the others do the work. A governance office that spends its time cleansing records or building pipelines has become a data management team and has given up the oversight stance that justified it.

Governance and IT governance

IT governance, as framed by COBIT and ISO/IEC 38500, directs and monitors the organization's use of technology; ISO/IEC 38505-1 applies the same evaluate, direct and monitor model to data. The subject matter nonetheless differs: IT governance asks whether systems are well chosen, well run and secure, while data governance asks whether the data inside them is defined, owned, fit for use and used appropriately. A system can comply fully with IT standards while holding data that no one owns or can define. The two intersect at architecture standards, security controls and change control.

Governance and compliance

Compliance is conformance with obligations imposed from outside: regulation, contract and standard. Governance is the organization's own decision about how data should be managed, which includes meeting those obligations but is not limited to them. Compliance-only governance covers only regulated data, only to the regulatory minimum, and only while an obligation is in view. Governance that also serves value covers the data behind pricing, supply, customer experience and AI, where no regulator is watching but the consequence of poor data is largest.

Scope of governance

Governance decisions fall into recurring categories: what data means, who is accountable for it, how good it must be, how sensitive it is and who may use it, how long it is kept, how it may be shared, and how it may be used, including as training data for AI. Not every data set warrants the same intensity. Mature programs concentrate on critical data elements (CDEs), the subset whose quality and control materially affect a business outcome or regulatory obligation, and apply lighter, largely automated controls to everything else. The CDE boundary is itself a governance decision made against published criteria.

Governance is measured by the decisions it changes, not by the documents it produces.

Why governance programs fail

The failure patterns of governance programs are consistent across industries, and each has a structural cause. Recognizing them early matters because the remedies are design decisions about authority, scope and funding that are far easier to make at the start than to retrofit. Five patterns account for most stalled programs, and they often occur together.

Compliance-only framing. Programs born from an audit finding inherit the scope of the finding: only regulated data is governed, only to the standard the regulator requires, and the business experiences the program as overhead. When the finding closes, the funding closes with it, and the organization learns to associate governance with constraint rather than with better decisions.

Decision rights that exist only on paper. A council is formed, but its terms of reference say that it advises. Data owners are named in a spreadsheet the named executives have never seen. When a genuine dispute arises, no one can rule, so seniority or inertia decides. The test is simple: name the last council decision that a powerful stakeholder disliked and that held anyway.

Committee overload. Programs multiply bodies faster than they establish authority: a steering committee, a council, working groups, a stewardship forum and a tooling group, with overlapping membership and no documented decision rights. Meetings become status reviews, senior members send delegates, delegates cannot decide, and the organization concludes that governance means meetings.

Tool-first starts. A catalog or quality platform is bought before scope, roles and processes exist, because a tool is easier to fund and to show than an operating model. It fills with assets that have no owner and terms with no approved definition, adoption stalls, and the vendor is blamed. Tools amplify an operating model that already works; they cannot substitute for one.

No link to business outcomes. Programs that set out to govern all data at once produce inventories and policies whose benefit no executive can see, and they are cut in the next budget round. Governance that starts with the data behind two or three decisions the organization cares about produces evidence of value within a year; governance of everything produces evidence of effort.

Guiding principles

Principles are decisions made in advance, and they are useful only if they are specific enough to exclude something. The six below follow directly from the failure patterns and are the basis for the framework and operating model that follow. Each is stated with its practical consequence, because a principle without a consequence is a slogan.

Principles conflict in practice: federation pulls against consistency, embedded controls against speed of change, measurability against governing what is hard to measure. The council arbitrates case by case and records each arbitration in the decision log, so that the organization accumulates precedent. A principle that has never constrained a decision is either redundant or not being applied.

The governance framework

The framework is the set of components a governance capability must have regardless of how it is distributed across the organization; the operating model, covered in the next section, decides where each component sits. The six components below appear, in one form or another, across established bodies of knowledge such as DAMA-DMBOK and the EDM Association's Data Management Capability Assessment Model (DCAM).

Strategy and charter

The charter is the instrument that creates authority. It is approved by the executive committee, not by the data function, and states the purpose and scope of governance, the principles, the roles and bodies, a summary of decision rights, the funding arrangement, the metrics to be reported and the review cycle. A charter longer than about ten pages is rarely read. Strategy connects the charter to business priorities by naming the two to four outcomes governance will serve first, the domains and critical data elements behind them, and the sequence in which further domains follow.

Policy hierarchy

Governance documents are organized in four tiers with different degrees of obligation and different owners. A policy states mandatory intent and is approved by the council. A standard makes a policy measurable by specifying what compliant looks like, for example the mandatory attributes a critical data element must carry. A procedure describes how a function performs a controlled activity and is owned by that function. A guideline records recommended practice; departing from it needs justification but no exception.

A minimum viable policy set contains a data governance policy that establishes roles and decision rights, a classification and handling policy, a data quality policy, a retention and disposal policy, an access and sharing policy, and a metadata and definitions standard. Privacy and security policies belong to those functions and are cross-referenced. Each document names an owner, an approval body and a review cycle, typically every two to three years for policies and annually for standards.

Organization and roles

Six roles recur. The executive sponsor holds the authority the charter conveys and chairs, or appoints the chair of, the council. The executive data council approves policy, sets scope and arbitrates. The governance office, usually under the chief data officer (CDO), drafts policy, maintains registers, prepares decisions, measures and trains. Domain data owners are accountable executives for a defined domain such as customer, product or finance. Data stewards exercise day-to-day care of definitions, quality and use on the owner's behalf, and data custodians operate the systems and technical controls in which the data lives.

Core processes

Five processes carry most governance decisions. Each is designed before tooling is selected, with a trigger, a decision-maker drawn from the RACI, an artifact that records the outcome and a service level that makes delay visible.

Policy exceptions. Raised when a domain cannot meet a policy or standard. The request states the gap, the business reason, the risk, compensating controls and an expiry date. Approval is tiered by risk: the domain owner for low risk, the council for the rest. Every exception is registered and reviewed before expiry; one renewed twice signals a policy that needs revision.

Issue management. Raised when data fails an expectation: a rule breach, a definition conflict, an unowned data set or a control failure. Issues are logged with severity, owner and target date, triaged by stewards, analyzed for root cause, remediated by the owning domain and closed when the fix is verified. The register is the list from which cycle time is measured.

Change control. Triggered by any change to a critical data element, shared data model, reference data set, business definition or data contract. The change carries a data impact assessment naming affected consumers, who are consulted before approval. Governance adds a data gate to the existing change process rather than creating a parallel one.

Access decisions. Triggered by a request to use data for a purpose or role not already entitled. Classification sets the path: public data is self-service, internal data is approved by role, and restricted data needs the owner's approval and a stated purpose. Entitlements are recertified periodically and decisions are recorded in the catalog.

Critical data element designation. Triggered when data is found to drive a regulatory report, a financial statement, a material decision, a customer outcome or a high-risk AI system. Designation applies enterprise criteria, assigns an owner and a steward, and obliges the domain to document definition, source of record, quality rules, lineage and controls.

Metrics and technology enablers

Each component carries at least one measure, published together as the scorecard described in the section on funding and measurement; a policy without a measure of adoption is incomplete. Technology is chosen after the processes it will automate have been designed. A data catalog holds the asset inventory, glossary, ownership, classification and CDE register; data quality tooling executes rules and reports trends; lineage tooling traces data from source to report; and workflow tooling routes exceptions, issues, access requests and change approvals to the people the RACI names. The selection criterion is fit with the designed processes and integration with identity, ticketing and the platform, not feature count.

Operating models and decision rights

The operating model decides where each framework component sits: which decisions are made centrally, which in the domains, and to whom the stewards report. Three archetypes cover the practical range, and the choice should be made deliberately against the criteria below rather than inherited from whichever team started the program.

Each archetype fails in a characteristic way. The centralized model reaches a first set of standards fastest, but at scale the central team becomes the bottleneck for every definition and access decision and drifts from oversight into operations. The federated model fits holding structures and data mesh architectures, but domains mature at different speeds, define shared concepts such as customer differently, and cross-domain disputes have nowhere authoritative to go. The hybrid model, in which the center owns the policy hierarchy, classification scheme, CDE criteria, glossary conventions, shared tooling and scorecard while domains own definitions, quality thresholds, access approvals and remediation priority, is the destination for most large organizations. Its demand is clarity: the list of enterprise minimums must be short, explicit and enforced.

Selection criteria

• Regulatory intensity. Heavier, more prescriptive regulation strengthens the case for central policy and independent oversight of its adoption.
• Diversity of business lines. Conglomerates with distinct customers favor domain ownership; integrated businesses sharing one customer base favor central standards.
• Shared data. The more customer, product and reference data crosses domains, the more cross-domain decision rights must be centralized or formally arbitrated.
• Architecture direction. Data mesh and data product strategies presume domain ownership and need federated execution, with minimums enforced through the platform.
• Maturity and talent. Early programs need more central capacity; domains take on more as owners and stewards develop, so the model should be expected to shift.
• Jurisdictional spread. Operations across data protection regimes need local access and transfer decisions within central classification and transfer standards.

Decision rights as a RACI

A RACI chart assigns, for each decision, who is Responsible for the work, who is Accountable for the outcome and holds the final say, who is Consulted beforehand and who is Informed afterward. Each decision has exactly one Accountable role. The table below is written for a hybrid model and should be adapted rather than adopted.

Three practices keep the RACI alive: publish it in the charter and the catalog, test it against real cases in the first quarter, and set thresholds that route routine decisions away from the council. A council that approves individual access requests has been given work, not authority.

Governance bodies and cadence

Governance bodies exist to make decisions that individuals cannot make alone, because the decision crosses domains or commits the enterprise. Each needs a mandate, a membership, a cadence, defined inputs and outputs, and the decision rights it holds under the RACI. Three kinds of body, supported by the governance office, are sufficient for most organizations.

The executive data council is chaired by the executive sponsor, typically the chief operating officer, the chief financial officer or the CDO. Its members are the domain data owners together with the chief information officer, the chief information security officer, the head of risk or compliance, and the data protection officer or legal counsel. It approves policy, sets scope and CDE criteria, arbitrates cross-domain disputes, approves high-risk exceptions and reviews the scorecard. It works from decision papers circulated in advance that state a recommended option, and every decision is recorded in a decision log.

Domain data forums are the working level: each is chaired by the domain owner and attended by the domain's stewards, the custodians of its principal systems and its major consumers. The forum approves domain standards and definitions, prioritizes remediation, grants exceptions within the owner's threshold and prepares anything that must go to the council. Working groups are time-boxed teams chartered to produce a specific deliverable, such as a classification scheme or a retention schedule, and they disband when it is approved. Standing working groups without deliverables are the main source of committee overload.

Escalation paths

Escalation gives decision rights teeth. The default path runs from steward to domain owner, to the domain forum, and to the council; cross-domain matters go from the two forums to the governance office for mediation and then to the council. Each level has a time limit, for example ten business days, after which an unresolved matter escalates automatically. Definition disputes, exceptions above a threshold, conflicts over remediation priority or funding, and access or sharing disputes should all be explicitly escalable. A path that is never used is as diagnostic as one that is overloaded: the first means disputes are settled by seniority, the second that thresholds are too low or owners are not deciding.

Integration with risk and compliance

Data governance shares its vocabulary and machinery with enterprise risk management: policies, controls, issues, exceptions and assurance. Organizations that already operate a risk framework should position data governance within it, so that data risk is a recognized category of operational risk, data controls sit in the control library and are tested, and the same registers and reporting lines are used. A parallel apparatus with its own taxonomy doubles the burden on the first line and weakens both.

The three lines model

The three lines model, which the Institute of Internal Auditors now publishes as the Three Lines Model (an update of the earlier three lines of defense), distinguishes management roles that own and manage risk (the first line), roles that provide expertise, monitoring and challenge on risk matters (the second line), and internal audit, which provides independent assurance to the governing body (the third line). Applied to data, domain owners, stewards and custodians are the first line. Compliance, privacy, information security and, in many regulated firms, a data risk function form the second line. Internal audit tests whether the arrangement works.

Where the CDO office sits is a design decision. In the first line it is an enabler close to delivery; in the second line it has independence to challenge but is further from the work. Banks subject to BCBS 239 often split the role into a first-line CDO office that executes governance and a second-line data risk function that oversees it. Whichever structure is chosen, no single function should both run a control and provide the independent assessment of it.

Regulatory drivers

Regulation rarely prescribes a governance structure, but several regimes presume one. The summary below is for orientation; jurisdiction-specific obligations should be confirmed with counsel.

GDPR accountability principle, Article 5(2). The controller is responsible for, and must be able to demonstrate compliance with, the principles in Article 5(1): lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, and integrity and confidentiality. Demonstrating compliance requires documented ownership, decisions and controls.

GDPR records of processing, Article 30. Controllers and processors must maintain records of processing activities; a controller's records cover purposes, categories of data subjects and personal data, recipients, international transfers, envisaged retention periods where possible and a general description of security measures. Accurate records depend on a data inventory with named owners: in practice, the catalog and the ownership model.

BCBS 239. The Basel Committee's principles for effective risk data aggregation and risk reporting comprise fourteen principles, eleven for banks and three for supervisors. They apply to global systemically important banks, and supervisors are encouraged to apply them to domestic systemically important banks as well. Principle 1 requires board and senior management oversight of risk data as a governance matter; Principle 2 requires a supporting data architecture and IT infrastructure. In practice they drive taxonomies, lineage, quality controls and named ownership for risk data.

EU AI Act, Article 10. Training, validation and testing data for high-risk AI systems must be subject to data governance and management practices covering, among other things, design choices, data collection processes and origin, preparation operations such as labeling and cleaning, the assumptions the data is meant to represent, the availability and suitability of the data, examination for possible biases and measures to address them, and the identification of data gaps. The Act's obligations apply in phases, so organizations should confirm which obligations apply to their systems and when.

Sector and financial reporting rules. Sarbanes-Oxley requirements for internal control over financial reporting extend to the data feeding financial statements; HIPAA governs protected health information in the United States; and the EU Digital Operational Resilience Act (DORA) requires financial entities to manage information and communication technology risk, including risks to the integrity and availability of data.

Integration follows from these drivers: map each policy to the risk taxonomy and the obligations it satisfies, record data controls in the enterprise control library with a test frequency and an owner, use the risk function's issue and exception tooling rather than a separate one, and report the governance scorecard to the risk committee as well as the council.

Compliance is an outcome of good governance, not its purpose.

Funding and measurement

Funding models

How governance is funded determines how it behaves. A program funded entirely as a central cost center behaves like a service nobody asked for; one funded entirely by projects disappears when the projects end. Four sources are commonly combined.

Central standing budget. The governance office, shared tooling and the enterprise minimums are funded as a permanent capability within the CDO or COO budget; a secretariat cannot be project-funded without losing continuity. The risk is that the center grows to do work that domains should fund.

Domain budgets for stewardship. Stewards and remediation are funded by the domains that own the data, which keeps accountability and cost together and prevents the center from becoming the owner by default. Domains need a clear expectation, typically a time allocation for named stewards and a remediation budget line.

Program funding for build phases. Establishing the policy set, the catalog and the first wave of domains is legitimately a transformation investment with a start and an end. Every program-funded capability should name the run budget that takes it over and when the transfer happens.

Use-case and regulatory funding. Funding attached to a priority use case or a regulatory remediation produces fast, visible results and is often how programs begin. The risk is scope captured by the funder. The remedy is to deliver the funded scope while building the reusable components, the registers, glossary conventions and operating model, on the central budget.

Measuring governance

Governance should be measured by what it changes. Leading indicators show whether the machinery works: coverage of critical data elements, adoption of policy and speed of decisions. Lagging indicators show whether it produces results: data quality trends, incidents attributable to data and the satisfaction of data consumers. Activity counts such as meetings held or policies published are context, not results.

The scorecard is produced quarterly by domain and consolidated for the council, with an annual version written for the board in outcome language. Targets are set per domain, and every scorecard carries a short narrative of the decisions made in the period. A scorecard that is green across the board in a program's first year is almost always measuring activity.

A staged path forward

Governance capability is built in stages, and the order matters more than the pace. The first 90 days establish authority and scope; the first year builds the machinery and proves it on a few domains; steady state embeds governance in the processes where data decisions are made, so that the program recedes and the discipline remains.

The first 90 days

1. Secure the executive sponsor and have the charter approved by the executive committee, including scope, principles, bodies and funding of the office.
2. Constitute the executive data council and hold its first meeting on a real decision, typically the selection of priority domains.
3. Select two or three priority business outcomes and the domains and systems behind them; defer everything else explicitly.
4. Name domain owners for the priority domains and interim stewards for their principal data, and brief each on decision rights and time expectations.
5. Inventory existing policies, standards and bodies, retire or merge duplicates, and map gaps against the minimum policy set.
6. Agree the CDE criteria, draft the first CDE list, and stand up the decision log and the issue and exception registers with baseline measures.

The first year

• Approve the minimum viable policy set and its standards, and publish the RACI in the charter.
• Confirm the operating model once the priority domains have exercised it, and formalize steward roles with time allocation and objectives.
• Establish the catalog with glossary, ownership and classification for the priority domains' CDEs, populated by stewards rather than by the office.
• Run the exception, issue, access and change processes with service levels, add data gates to project intake and change control, and report the first quarterly scorecard.
• Bring the next wave of domains into scope and commission an independent maturity assessment against a recognized model, such as the EDM Association's DCAM, to baseline progress.

Steady state

In steady state governance runs on a fixed rhythm: forums monthly, the council quarterly, standards reviewed annually, policies and the charter on a multi-year cycle. Controls are embedded and increasingly automated: classification applied at creation, access policies enforced by the platform, quality rules executed in pipelines, and data contracts governing changes to shared data products. Data products and AI systems are governed within the same framework, and the third line periodically tests the arrangement. The signs of arrival are behavioral: decisions flow through forums without prompting, domains ask for governance services before a launch, exception volumes fall as policies are revised to match reality, and executives cite the scorecard in their own reviews.

Conclusion

Data governance is the decision system of data management. Its failure modes are well known: compliance-only framing, decision rights that exist only on paper, committee overload, tool-first starts and no link to outcomes. The remedies are structural: a charter that conveys real authority, a hybrid operating model with explicit enterprise minimums, decision rights written as a RACI, few decision-focused bodies with a working escalation path, funding that keeps accountability and cost together, and a scorecard that measures change rather than activity. Governance succeeds when the organization stops noticing it as a program and starts relying on it as the way decisions about data are made.

Glossary

Data governance

The exercise of authority and control, through planning, monitoring and enforcement, over the management of data assets.

Decision rights

The documented allocation of who may decide what, about which data, within what constraints.

Data domain

A bounded area of business data, such as customer or product, with a single accountable owner.

Data owner

The accountable executive for a data domain or critical data element, with authority over its definition, quality expectations and use.

Data steward

A role that exercises day-to-day care of definitions, quality and appropriate use on behalf of the data owner.

Data custodian

The technical role that operates the systems and controls in which data is stored, moved and protected.

Critical data element (CDE)

A data element whose quality and control materially affect a business outcome or regulatory obligation, and which therefore receives the most intensive governance.

Policy hierarchy

The tiered structure of policies, standards, procedures and guidelines, each with a distinct degree of obligation and owner.

Policy exception

A documented, approved and time-limited departure from a policy or standard, with compensating controls.

Operating model

The way governance components are distributed between a central function and business domains.

Enterprise minimums

The small set of policies, standards and shared services that the central function owns and every domain must adopt.

RACI

A matrix assigning, for each decision, the roles that are Responsible, Accountable, Consulted and Informed.

Executive data council

The senior body that approves data policy, sets scope, arbitrates cross-domain disputes and reviews the governance scorecard.

Governance office

The central function, usually under the chief data officer, that runs the governance secretariat, methods, registers and measurement.

Three lines model

A risk governance model distinguishing management roles that own risk, roles that provide expertise, monitoring and challenge, and internal audit, which provides independent assurance.