Data Governance for Boards and Leadership Teams

Executive summary

Boards can delegate the work of governing data; they cannot delegate accountability for it. Across privacy, prudential, operational resilience and AI regulation, the obligations that touch data attach to the organization and, in several regimes, explicitly to its management body. Boards also approve AI and analytics investments whose outcomes depend on data they have rarely examined. Yet most directors encounter data only when something has gone wrong: a supervisory finding, a breached customer file, a report that would not reconcile, or an AI pilot that stalled because no one could vouch for its training data.

This paper argues that the board's task is not to manage data but to be certain that someone accountable does, and to be able to show it. That requires treating governance as a system of decision rights and accountabilities rather than as a platform, an audit or a committee, and giving directors a small set of instruments with which to oversee it.

• Four cumulative drivers have brought data governance to the boardroom: regulatory accountability, the dependence of AI on governed data, operational resilience and value creation.
• Decision rights can be mapped by scope and nature; the board and executive committee own data strategy, risk appetite, policy, funding of shared foundations and the designation of critical data.
• Eight questions, asked without technical preparation, show whether ownership, fitness for use, data risk, AI inputs, responsiveness and resilience are under control.
• The Three Lines Model gives data accountability a shape the board already understands, and a chief data officer with a real mandate gives it an accountable executive.
• A one-page operating model, a time-limited escalation path and a quarterly dashboard of seven measures turn oversight from reactive to routine.

The closing sections cover how to fund foundations, use cases and the platform, six warning signs of a failing program that directors can detect from board papers alone, an illustration of a program reset, and a 100-day agenda that establishes oversight with the authority it needs. Everything after the first 100 days is operating rhythm.

Why boards must own data governance

The premise of this paper is simple. Across privacy, prudential, resilience and AI regulation, the obligations that touch data attach to the controller, the bank, the financial entity or the AI provider as an organization, and in several regimes explicitly to its management body. Directors can and should delegate the design and operation of data governance to management. The duty to oversee it, to resource it and to be able to demonstrate that it works stays with them.

In practice, many boards see data only through failures. A regulatory finding, a breach, an unreconciled report or a stalled AI pilot arrives in the board pack as an incident, by which point the choices are expensive. The aim of oversight is to replace that reactive exposure with deliberate attention, without turning the board into a data management committee. Analytics, AI and resilience programs inherit whatever data discipline exists beneath them, so the quality of that discipline is a board matter whether or not it appears on the agenda.

Boards can delegate the work of governing data. They cannot delegate the accountability for it.

Four reasons data governance has reached the boardroom

The four drivers are cumulative, not alternatives. Regulatory accountability is the most visible: the accountability principle of the General Data Protection Regulation (GDPR) requires controllers to be able to demonstrate compliance, the Basel Committee's BCBS 239 principles expect bank boards to oversee risk data aggregation, the EU Digital Operational Resilience Act (DORA) places responsibility for ICT risk arrangements with the management body of financial entities, and the EU AI Act sets data governance requirements for high-risk AI systems.

The second driver is strategic. Boards approve AI investments whose outcomes depend entirely on data they have never examined, and AI pilots often stall short of production because no one can vouch for the data behind them. The third is resilience: important services fail when their data fails, and recovery plans that do not identify the data each service depends on are incomplete. The fourth is value. The same ownership and quality discipline that satisfies a regulator is what lets data be reused across products, channels and analytics. A board that frames governance only as compliance will underinvest in it.

What five regulatory regimes expect of leadership

The table below is a map, not legal advice. Its common thread is the direction of accountability: each regime expects named people at or near the top of the organization to own, approve or certify arrangements that depend on well-governed data.

The scope summaries are simplified, and obligations depend on jurisdiction, sector and role, so specifics should be confirmed with counsel. Under the GDPR, Article 5(2) makes the controller responsible for, and able to demonstrate, compliance with the data protection principles, and Article 38(3) requires the data protection officer to report directly to the highest management level, free of instructions on how to carry out the role. BCBS 239 opens with governance: a bank's board should oversee senior management's ownership of implementing the principles, and board and senior management should promote the identification, assessment and management of data quality risks and review and approve the bank's risk data aggregation and risk reporting framework.

DORA makes the management body of a financial entity responsible for defining, approving and overseeing the implementation of its ICT risk management arrangements, gives it ultimate responsibility for ICT risk, and requires policies that maintain high standards of availability, authenticity, integrity and confidentiality of data. The EU AI Act requires training, validation and testing data for high-risk systems to be subject to data governance and management practices, and expects providers and deployers to support AI literacy among their staff; its obligations apply in phases and can change through amendment, so organizations should confirm which apply to them and when. Sarbanes-Oxley adds certification of periodic reports by the chief executive and chief financial officers and an annual management assessment of internal control over financial reporting, which rests on the data behind the numbers.

What governance is, and is not

Leadership teams often believe they already have data governance because they have bought a catalog, chartered a committee or passed an audit. None of those is governance. DAMA-DMBOK, the body of knowledge published by DAMA International, defines data governance as the exercise of authority and control (planning, monitoring and enforcement) over the management of data assets. In board terms, governance is about who decides, who is accountable and how compliance is verified.

Four misconceptions, and what governance is instead

Each misconception contains a half-truth. Technology matters, because policies that are not enforced in systems are not enforced at all, but a tool cannot decide which customer record is authoritative or which quality threshold is acceptable. Compliance matters, yet a program designed only to produce audit evidence will stop at the minimum and end when the finding closes. A committee matters only if it holds real decision rights and its members can commit their functions. And a cleanup fixes yesterday's data while the processes that produced the problem carry on. The right-hand panel is the test: if no one can name the owner of a critical data set and the decisions that owner is entitled to make, governance does not yet exist.

Decision rights by scope and nature

The decision-rights framing makes governance concrete. Every data decision has a scope, from a single domain to the whole enterprise, and a nature, from day-to-day operation to strategy. Plotting decisions on those two axes shows who should hold them.

The board and executive committee own the strategic, enterprise-wide quadrant: strategy, risk appetite, policy, funding of shared foundations, the designation of which data is critical, and arbitration when domains disagree. Domain data owners, typically senior business executives, own strategic choices within their domain. Stewards hold operational decisions about definitions and quality rules for the data assigned to them, and the governance office, working with the platform team, holds enterprise-wide operational decisions such as standards, tooling and monitoring.

Confusion arises when these are mixed: a council debating a field definition, or a steward deciding whether a regulatory data set is in scope. The board's job is not to take these decisions but to make sure each quadrant has named holders and that escalation between them works.

A test for any critical data set

Data governance is the system of decision rights and accountabilities for data. Everything else, from tools to committees, is implementation.

This principle is the lens for the rest of the paper. When management presents a governance program, directors should look past the platform roadmap and the committee charter and ask three questions about each critical data set: who decides what it means and how it may be used, who is accountable for its fitness for use, and who independently verifies both. If the answers are clear, and the people named have the authority and resources to act, the implementation choices are secondary. If the answers are vague, no tooling investment will compensate. The test also works in reverse: a lean program with clear accountabilities and modest tooling is usually healthier than a well-funded one that cannot answer the three questions.

Oversight and accountability

Oversight needs instruments. This section gives directors three: a set of questions to put to management, the Three Lines Model applied to data, and a view of where data accountability should sit in the executive structure.

Questions a board should put to management

The questions below are designed to be asked in a board or committee meeting without technical preparation. Good answers are specific, evidenced and owned; vague answers are a finding in themselves.

Each question targets a specific weakness. The ownership question tests whether accountability exists at all; the answer should be names and decision rights, not a department. The fitness question tests whether quality is measured against expectations the business has agreed, rather than assumed. The risk question connects data to the enterprise risk framework the board already oversees. The AI question exposes whether models draw on governed data; under the EU AI Act, the training, validation and testing data of high-risk systems must be subject to data governance and management practices.

Response time is a practical proxy for lineage and findability. The GDPR gives a controller one month to act on a data subject request, extendable by two further months where the complexity and number of requests make it necessary, and regulators and auditors rarely wait longer. The resilience question links data to the services that matter most; UK regulators use the term important business services, while DORA speaks of critical or important functions. Exceptions reveal where policy is being waived without anyone deciding to waive it. The last question tests whether oversight produces change or only reports.

The Three Lines Model applied to data

The Institute of Internal Auditors (IIA) publishes the Three Lines Model, an update of the earlier three lines of defense, and it translates cleanly to data. The model distinguishes management roles that own and manage risk (the first line), roles that provide expertise, support, monitoring and challenge on risk matters (the second line), and internal audit, which provides independent assurance to the governing body (the third line).

The first line is operational management: the business executives who own data domains, the stewards who work for them and the technology custodians who operate systems. They own the data and the controls over it and fix issues at source. The second line is the data governance office under the chief data officer, often paired with a data risk function in regulated firms. It writes policy and standards, monitors adherence, challenges the first line and reports to the executive committee. The third line is internal audit, which gives the board independent assurance that controls over critical data are designed and operating effectively; it tests the arrangement and reports on it independently, and it neither owns nor fixes the data. The board and its risk committee sit above the lines: they set the data risk appetite, approve policy and receive all three perspectives side by side.

The common failure is a second line that owns data or performs first-line fixes, which removes challenge and blurs accountability. Where the chief data officer's team also runs first-line data services, as it often does, regulated organizations commonly place a separate data risk function in the second line so that no single function both operates a control and gives the independent opinion on it.

Where data accountability sits in the executive structure

Structure signals seriousness. A chief data officer (CDO) without policy authority or a budget is an advocate, not an accountable executive. The board's interest is that the CDO's mandate, reporting line and budget are consistent with one another, and that data risk reaches the board through the same channels as other material risks.

• An explicit mandate. Policy authority, a budget for shared foundations and a seat at the executive table, written into the role rather than implied.
• A reporting line chosen for the mandate. Reporting to the chief executive or chief operating officer gives enterprise scope and authority; to the chief financial or chief risk officer, a control and risk emphasis that suits regulated firms; to the chief information officer, platform alignment at the risk of framing data as an IT concern. There is no single right answer.
• Risk committee oversight. Data risk reported alongside operational and technology risk, not in a separate forum the board never sees.
• A data risk appetite statement. Approved by the board and reported against by management, in the same way the board approves appetite for credit or operational risk.
• Independence where the law requires it. The GDPR data protection officer reports directly to the highest management level, and that independence should be visible in the structure.

The operating model on one page

Directors do not need to design the operating model, but they should be able to see it on one page: who decides, who executes, how issues escalate and what leadership sees each quarter. The board does not sit inside this structure; it oversees it.

Roles and bodies

The operating model above is the minimum structure that makes decision rights work. The executive sponsor, usually a member of the executive committee, gives the program its authority and resolves what the council cannot. The data governance council, typically chaired by the chief data officer and composed of domain data owners, sets policy, designates critical data, prioritizes investment and resolves cross-domain conflicts; it does not manage data day to day. Domain data owners are senior business leaders accountable for the data their functions create and use, and they decide for that data. Data stewards, who work in the domains, maintain definitions and quality rules and triage issues.

The governance office is the small central team that runs the operating rhythm, maintains policies and standards, monitors compliance and prepares the evidence the board receives. The data platform team turns policy into enforced defaults in catalogs, pipelines and access controls, so that decisions become the path of least resistance rather than a matter of goodwill. Risk, compliance and internal audit connect the model to the three lines.

The escalation path from issue to board

Escalation is where governance programs most often fail quietly. Issues are logged and then age, because no one is obliged to move them. The path below gives each level a defined authority and a time limit.

Stewards handle most issues: they assess impact, fix within existing standards and escalate when a fix needs money or a process change. Domain owners decide those cases and may formally accept residual risk if it sits within appetite. The governance office takes cross-domain issues and requests for policy exceptions, and the council decides conflicts between domains and larger exceptions. Anything outside risk appetite, with regulatory exposure or affecting an important business service reaches the executive committee and, through the risk committee, the board.

Two design rules keep the path honest. Every level has a service level and a named deputy, so absence does not stall a decision. And an issue that stalls at any level is reported upward as a stalled issue, so that aging becomes visible to the people who can act on it.

What leadership should see every quarter

A quarterly dashboard for leadership should answer the board's questions with trends rather than snapshots. Seven measures are enough.

Coverage of critical data elements with a named owner comes first because nothing else on the dashboard is reliable without it. Quality trends should be reported against thresholds the business has agreed, not as a composite score that hides which rule failed. Issue aging by severity shows whether the escalation path works. Policy exceptions, with their age and approver, show where the organization is quietly accepting risk. Service levels for regulatory, audit and customer requests are a practical proxy for lineage and findability, because answering quickly requires knowing where data lives and where it came from. AI readiness reports which production models draw on owned and assessed data, and mapping important business services to their data closes the resilience loop.

The targets in the table are structural end states, not external benchmarks. Trends over successive quarters matter more than any single level, and a dashboard that is green everywhere in a program's first year is almost certainly measuring the wrong things.

Funding and warning signs

Funding is where many governance programs fail, and drift is how they fail. This section covers how to pay for foundations, use cases and the platform, how directors can recognize a failing program from board material alone, and what a reset looks like.

Funding foundations, use cases and the platform

Foundations such as policy, standards, the catalog, lineage and the governance office benefit everyone and no one in particular, so no single business case will pay for them. They should be funded centrally as a multi-year program with an executive owner, and measured by coverage, adoption and risk reduction. Use cases should be funded by the business sponsors who benefit, and should consume the foundations rather than rebuild them; their success is measured by the business outcome. The platform sits between the two and works best funded as a product, with consumption shown back (reported without billing) or charged back to encourage sensible behavior.

Typical cost categories across all three are people, process design and change, technology, and the ongoing cost of running what is built. Sequencing matters as much as the split: a minimum set of foundations should precede the first use cases, and the platform should scale with demand rather than ahead of it.

Warning signs of a failing program

Failing programs rarely announce themselves; they drift. The six signs below are the ones directors can detect from board material alone, and each has a deliberately modest response.

None of the responses requires the board to manage data. Each asks management for something inspectable: a map, a mandate, an aging report, an exception register, a threshold report or a link to the roadmaps that give governance a reason to exist beyond compliance. A program that cannot produce them within a quarter has told the board what it needs to know.

An illustration: resetting a stalled program

Consider a regional bank that has run a governance program for two years, centered on a catalog deployment, when a supervisory review finds weaknesses in risk data aggregation. The board has seen green quality scores every quarter, while the failing rules sat in an appendix no one read. Data owners exist in a policy document but have no objectives, budget or authority, and two AI pilots have stalled because no one can confirm where the customer data came from. The composite is illustrative and describes no single institution.

The reset does not start with new technology. The executive committee approves a decision-rights map and writes ownership into executive objectives. The council narrows scope to the data sets behind regulatory reporting and explicitly defers the rest. Reporting moves to threshold-based results by data set, with issue aging, delivered to the risk committee, and the board approves a data risk appetite statement under which exceptions become time-limited and visible. The pattern generalizes: fix accountability and visibility first, and the tooling already in place starts to earn its keep.

A 100-day agenda for the executive team

One hundred days is enough to establish oversight, not to finish governance. The agenda below is sequenced so that each phase produces something the next one needs, and so that the board receives its first evidence before the period ends.

The first twenty days establish facts: which data is critical, who owns it in practice, what regulators, auditors and incidents have already said, and whether the chief data officer's mandate and reporting line fit the job. The second phase settles decision rights: the executive committee approves the decision-rights map, names owners with objectives and charters the council. The third sets appetite: a draft data risk appetite statement, quality thresholds for the most critical data, and an escalation path with time limits.

The fourth phase funds foundations centrally, chooses two use cases that will pull on them and fixes a minimum platform scope. The final phase produces the first quarterly dashboard, briefs the risk committee and agrees the internal audit plan, so that the third line is engaged from the start rather than discovering the program at its first audit. Everything after day 100 is operating rhythm.

Where to start

The first steps are deliberately within the board's own gift. None requires a budget decision, and each turns an abstract program into something directors can inspect.

1. Ask the questions. Put the eight questions to management at the next board or risk committee meeting. Asking costs nothing and sets the tone.
2. Inspect the decision rights. Ask for the decision-rights map and the named owners of critical data, with the decisions each owner is entitled to make.
3. Put data into the risk framework. Commission a data risk appetite statement for board approval, reported against in the same way as other risk appetites.
4. Create the cadence. Agree the quarterly dashboard measures and the date of the first report.
5. Launch with authority. Start the 100-day agenda with a named executive committee owner, so that the work begins with the authority it needs.

Boards do not need to manage data. They need to be certain that someone accountable does.

Glossary

Data governance

The exercise of authority and control (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.

Critical data element (CDE)

A data element whose quality and control materially affect a business outcome, a regulatory obligation or an important service.

Data owner

The accountable executive for a data domain, with authority over its definitions, quality expectations and use.

Data steward

A role in the business that maintains definitions and quality rules and triages issues on the data owner's behalf.

Data governance council

The senior body that sets data policy and priorities, designates critical data and resolves cross-domain conflicts.

Governance office

The small central team that runs the governance cadence, maintains policy and standards, monitors adherence and prepares reporting.

Data risk appetite statement

A board-approved statement of how much data-related risk the organization will accept, written so that management can report against it.

Three Lines Model

The IIA's model distinguishing management roles that own risk, roles that provide expertise, monitoring and challenge, and internal audit, which provides independent assurance.

Management body

In EU financial regulation, the body (typically the board) empowered to set an entity's strategy and oversee its management.

Important business service

The UK regulators' term for a service whose disruption could cause intolerable harm to customers or markets; DORA's comparable concept is a critical or important function.

Showback and chargeback

Reporting consumption of a shared service to the units that use it (showback), or billing them for it (chargeback).