Organizational Structure for a Data Governance Initiative


As within any organization, there is a multitude of corporate “assets” which are managed or governed by a dedicated function:

  • The Human Resource department is responsible for its human capital, among which current employees but also future recruitments
  • The facilities department is responsible for real estate and other properties
  • The sales department is responsible for keeping and expanding existing the customer base and the acquisition of new customers

Until recently data has not been seen as an asset and therefore its management has been subdued or been accommodated in another function (e.g. HR, sales, facilities…). But the data tide is changing, and organizations have come to acknowledge that data is too important for an organization to be left unattended. The two main reasons for an increased focus on data are:

  • the necessity for data to comply with internal and external guidelines
  • and the competitive advantage that an organization can achieve with data in relation to its competitors

Therefore, the management of the integrity, the security and compliance of data, also known as, “data governance” has gained increasing attention in the data landscape.
The way data governance is rolled out across the organization and how it is embedded within each organizational layer is of course paramount for the success of the program itself. An unsupported or unaligned organization structure can have a detrimental effect on the data governance program. This document aims to facilitate the reader in finding or choosing an appropriate organizational structure for its data governance purposes.

Some basics

A data governance program is a program across the whole organization which manages the integrity, the security, and compliance of data, not the data itself.
A data steward is responsible for enacting this data governance program for his/her data domain or for his/her division.
A data custodian is the IT role. This person is responsible for maintaining data directly on the IT infrastructure in accordance with business requirements
An Owner (Data Owner) usually a senior business person who has the resources, budget, and authority to be able to make changes to that data if necessary.

A data governance council is a cross-functional committee which:

  • develops and approves policies, standards, and processes for data
  • allocates funding for and prioritizes data governance initiatives
  • defines the spectrum of data domains data governance applies to
  • measures progress and compliance in accordance with the developed policies, standards, and process

The data governance council normally meets on a regular basis, at least monthly

The key variables for the data governance organization

Which variables determine how you should organize your data governance structure? Management involvement, ownership, the data governance council setup, the level of federation, and the level of integration play all a key role in setting up your organizational structure. Each of these variables has an important impact on the overall success and are further discussed below.

Level of management involvement

A data governance program needs specialized knowledge and dedicated resources. This requires commitment, sponsorship, and leadership for oversight, which should be provided by executive management. Depending on which level in the organization the funding and the leadership are endorsed, there might be a strong vertical line structure with reporting councils on multiple levels. If for example, the organization is very hierarchical, and the data governance initiative comes from the top, multiple governance bodies might be necessary to commensurate with the different levels within this hierarchy. In any case, an efficient and effective roll-out of the data governance program should not be hampered by a multi-level approach. The executives who have a key interest in making sure that data is governed according to the strategies set, will regularly want to see performance indicators and reporting from its base to make sure the initiatives are executed accordingly.

In case the data governance organization does not have a strong top-down culture and the organization of the data governance program is left to the middle management (which is not ideal), other rules apply. Depending on your corporate culture, it might be beneficial to involve all or just a few departments from the start to get the necessary buy-in. In case a budget has been set for the next amount of years and the data governance program has to prove its value a more pragmatic approach might be necessary. In this case, you might want to keep the data governance team rather small, focus on the use cases where data governance adds value, and further attach more parts of the organization as data governance becomes more established. This is especially important when data governance still has to prove its value towards executive sponsors and additional budgets are pending. Once you have hit the critical point where data governance has become a day-to-day activity for most of the involved departments, the program has become viable and the middle management can act as the executive surrogate for establishing strategical data governance goals.

Data owners are not data stewards

It is important to acknowledge that data owners do not do the same thing and do not have the same responsibilities as data stewards. In its day-to-day activities, a data owner is normally busy with the management of data. This is different from the responsibilities of the data steward who is mandated with the role to manage the integrity, the security, and the compliance of data, in short, data governance policies. Data stewards normally are assigned within and aligned with business functions or subject areas because most initiatives are business value-driven. Both responsibilities co-exist but are ideally not shared as a decision from a data owner perspective is not always aligned with a decision from a data steward.
This is often the case when a business resource is both the system (containing the data) owner and data governance steward. For example, a system owner might consider his system as the system of reference, not realizing that other more core back-to-source components are better suited for this purpose.
Therefore, in a perfect world, the role of a data owner and data steward does not overlap, and the responsibilities of data governance are carried over to other individuals in the organization. As a minimum data should be governed on a level higher than where the ownership takes place, to guarantee independence and oversight.

The data governance council

The data governance council is normally the central body for deciding, executing, and monitoring data governance initiatives.

Data governance life cycle

A data governance council can be split up according to its overall function within the lifecycle of the data governance program.

  • An executive council responsible for the “decision” making and setting strategic initiatives (e.g. data harmonization/standardization), normally represented by the CDO
  • An operational council responsible for the execution and translation of the strategic initiatives in concrete policies, standards, and processes (e.g. identify the system of record for critical data elements)
  • An audit council/team responsible to monitor the success and performance of the initiatives which reports back to the executive council (e.g. measure usage or reference of the system of record in the consumption of critical data elements)

A data governance initiative is cyclical and never-ending… But keep in mind, that the data governance council should have the mandate to change course to other initiatives in case priorities change, the current initiative has hit a critical mass or the benefits does not longer outweigh the cost. In the end, data governance is about how you can create value out of data for your organization overall.


Data governance initiatives are cross-organizational as data is normally shared and flows across departments. It is therefore a certainty that all departments which use data are represented (normally all of them). The data governance council is normally represented by business or data stewards who have the mandate to make and execute data governance decisions. A typical organizational structure has domain representatives/business/data stewards by functional domains like human resources, marking, sales, supply chain, finance… and combine them with subject matter experts to cover specialty functions on the different data governance topics: Architecture, Solutions, Processes, Data Security, Data Integrity, Compliance,… When there are many participants it might be necessary to have a data governance officer who is responsible for following up on actions, has a direct line to the CDO, and has direct responsibility for the successful execution of the data governance program. If the organization decides to have a lot of stewards across the organization, it might be beneficial to not stuff all stewards into the data governance council but have a more slim version of the steward team in the council. This could be a dedicated team (appointed or voted) with representation for all business lines or a team that changes mandates ( e.g. every ½ year a new member is added and another leaves) on a frequent basis to guarantee a companywide representation.

Working groups

Sometimes, it might be necessary to further extend responsibilities to working groups or sub-committees, especially when there are multiple initiatives in parallel. In a complex environment it is common to set up separate working groups for different key initiatives:

  • Policy working group, a working group responsible to cascade data governance compliance guidelines, policies, and standards to all levels of the organization. The group operationalizes standards to a data level and monitors completion and success of the implementation.
  • Data integrity working group, a working group responsible to manage the integrity of the data by setting targets for the quality of the data (e.g. according to data quality dimension like completeness, consistency…), by determining and aligning data with the selected sources of reference and reducing data redundancy.
  • Security working group, a working group responsible for governing sensitive and restricted data.
  • (Business) process working group, a working group responsible for setting and enabling processes for data governance, for example, validation and approval mechanics.

As a practical example, a GDPR workgroup can be defined in the organization which combines different subject matter experts and data stewards to address the GDPR implications. The workgroup can act either have a full mandate to implement the GDPR standards and requirements or can work as a catalyst and delegate tasks to more specialized working groups, like the security working group to address requirements around personal private information.
When working with working groups strong coordination between the groups is necessary as function overlap might occur. In addition, each of the groups should perform work relevant to priorities and use cases set by the executive committee.


Let us have a closer look at a typical initiative.

  1. The management of company XYZ decides that “correct” customer data and customer KPIs are critical to further expand the customer market share of the organization. Many customers have only bought “one” service from the company but have not been targeted for other services the company provides. Some of the systems contain inconsistent customer data and to get a correct and single view of each customer, an initiative is needed to harmonize and standardize the “critical” customer data.
  2. The data governance council immediately acknowledges that some of the customer data is inconsistent across systems and sometimes even wrong. For example, some data has gone missing (e.g. inactive customers) or is inconsistent with other systems(e.g. old addresses). The data governance council decides that to tackle this initiative it needs to:
    1. Determine which of the customer data is critical on a scale of high, medium, low
    2. Chart out in which reports, KPIs and regulatory requirements this critical data is used
    3. Determine in which systems this critical data resides
    4. Determine which system(s) will be the system of reference
    5. Set up guidance/policies for the data owners what to do if another system stores or handles data differently than the system of reference
    6. Determine priorities and set planning for execution of the above
  3. The data or system owners will receive the guidance and policies by the stewards and will operationalize this guidance in each of the systems. The owners and stewards work closely together. As the steward is responsible for the governance roll out he/she reports any anomaly during the implementation. The data owners report progress and issues to the data governance council or stewards. As an example, one data owner has notified the council that about 75% of the current reporting is not using a system of reference for the reported data.
  4. An assigned data governance audit team ( 2 members of the data governance council) keeps an overview of the progress and successful execution of the initial rollout. On a regular basis, the audit team reports to the data governance and executive team. In the latest review, they have reported that:
    1. 50% of the systems have been harmonized with the system of reference
    2. there were 12 cases where wrong data input has been used
    3. the number of data elements used in customer reports was reduced by 25%

Level of federation

Each organization has to analyze if it is needed to roll out data governance initiatives on a companywide level or leave some discretion up to the local bodies. This is not only determined by how the organization is operated but can also be driven by how data is organized and managed within the company. Some of the data might be recently acquired through a merger or an acquisition. In other cases, systems and data operate independently from the parent company, and data is transferred to the holding only on a reporting basis. Sometimes the data is not supposed to leave the country or other local policies and regulations apply. In any case, when organizing the data governance structure, one should be aware of all these factors before communicating and rolling out the organizational structure.

It is important to recognize that although data can be situated in different independent hubs, it is still recommended to share best practices and give the possibility to compare. For example, the definition and calculation of gross margin might be different on the holding level and the different local departments. Still, it is beneficial for as well the holding as the different local country entities to explore these different definitions and calculation methods, as well as which data is used. This boosts transparency and opens doors for further alignment and communication. In any case, a complete disconnect between the data on a local and global level would be detrimental to the overall data governance case. In a strongly federated structure, the holding organization can opt to organize data governance initiatives on a global level and mandate some of these initiatives to a local operating data governance council. To avoid overlap or misalignment regular communication and reporting between these two governing bodies will be essential.

Level of integration in existing organizational structure

An organization can choose to embed a data governance structure into the existing organizational/functional structure or set up a separate data governance structure independent from the existing procedures and practices.
Both options deliver distinct advantages.

Embed in the organization

In case the organization chooses to embed the data governance structure into the existing organization, this automatically follows the specifics of the overall business organizations, for example, the choice to centralize or decentralize.
Data governance processes can be added to existing practices as an extension of existing responsibilities. The employees are normally accustomed to existing operating procedures, so it will be easier to extend those. Embedding data governance in an existing structure assumes that the mandate for action and responsibility is the same and this may lead to misinterpretations if this is not the case. It is as well important to acknowledge that data ownership might be quite different from the subject area/department ownership as both do not always align. This might lead to setting responsibilities to data governance resources who do not actually own or control the data assets in their specific department or subject area.

Separate organization

When rolled out as a separate organization structure, the data governance body might better correspond to the actual data ownerships within your organization. This will be particularly relevant if the organization is rolled out and communicated top-down. Clear responsibilities need to be set for management, budgeting, and resource allocation to data governance. The structure can be managed and monitored separately from the existing organization structure which increases the transparency about the data governance program. More investment might be needed at the start of the program for this approach, but if executed right, extensive benefits might be captured in the long term.


In this section we discussed several variables which drive how the data governance organizational structure will be set up:

  • The level of management involvement
  • The level of federation
  • The choice to integrate data governance into the existing organization structure or not
  • The choice of the data stewards
  • The organization of the data governance council, driven by the before mentioned variables

By now it should have become clear that there is no panacea for setting up a data governance structure, but different variables determine what will work for you as an organization. At the heart of the decisions you will make for each of the variables described, two key questions should be asked:

  • Has something like this worked before for other initiatives in the past?
  • Will the choice we make, make it easier to demonstrate the value of the data governance program?

You have to login to comment.