Data Governance: If everyone jumped off a cliff…?

Growing up as kids, we all wanted something other kids had or did, because well, we were kids. “But everybody is doing it!!!” Right?

My parents, whenever I said something like this, used to ask me to explicitly name everybody who met this condition. Of course, I stopped after a few names every time. And I am sure more than a few of us grew up with our parents telling us: “If everyone jumped off a cliff, would you?”

This brings me to the point: “common” does not mean “best.”

How many times have we heard that 70-80% of data-related initiatives do not do well? That the vast majority of data governance implementation does not work as intended is no exception.

Common practice does not mean best practice.

One of the most common approaches to data governance is the committee-driven and/or compliance-driven implementation. I have run into many organizations that do exactly this in an attempt to implement data governance. Sometimes one, sometimes the other, sometimes both. It is what “everyone” is doing. If everyone is doing it, it must be because it works, right?

However, there are several fundamental issues with this approach.

The committee-driven approach to data governance is ineffective.

The first issue with the committee-driven approach is that it is too slow for data needs. Data just moves and changes too quickly. This approach tends to work for regulatory compliance, but regulations move at a much slower pace.

The second and more fundamental challenge with the committee-driven approach is the gap between committee decisions and getting those decisions executed. Deciding that things need to be done does not convert itself to getting them done. Too often, everyone knows what they should be doing as an organization. However, their data governance model is not structured to close that gap.

Data governance problems are people, not compliance, problems.

Unfortunately, beliefs persist that the purpose of data governance is to ensure compliance with every regulatory detail. However, the scope of data governance is much broader than this.

Data governance problems are really people problems. Data governance does not govern data itself but instead the behavior of people around data.

This does not mean automation has no place. Rather, the problem is that compliance-driven data governance is usually implemented simply as a set of rules to be met without considering how human behaviors influence the extent to which such rules are met.

With or without automation, such an approach is harder and slower to react in practice. It ends up in a bureaucracy because people have all these hoops to jump through just to get some simple things done and the response is slow.

This approach is also often purely prescriptive with a focus on policing. It provides little guidance on how people are expected to behave around data. The policing mentality that frequently comes with compliance-driven data governance is not just the opposite of empowerment. It is anti-data-culture, whatever “data culture” means in practice.

Compliance as the driver of data governance has ethical challenges.

Regulations are always reactive; they follow practice, not the other way around. They are introduced because adverse effects have already happened somewhere.

As an extreme example, I recall one specific case in which a politician personally experienced something he did not like and went medieval to create a regulation that probably did more damage than solve problems. No one bothers with preemptive regulations just because something might happen. Regulations make you do things because the damage has already been done somewhere else.

Regulations also force you to do things whether or not you agree with them. It is not doing the right thing because it is the right thing to do. It is not implementing good data practices because they are good practices. This is an ethical problem.

The reactive nature of this approach also means always having to play catch up. You do not want to be perpetually chasing regulations. They are reactive to start with, and there are just so many of them. If you choose to chase them, you will always be behind good practices. Once you get behind, it puts everyone in a fire-fighting mode. Each time, you get further behind. Good luck with ever achieving full compliance.

Compliance does not guarantee data privacy.

Another issue with compliance-focused data governance is that perfect regulatory compliance does not guarantee data privacy or security. This is because privacy disclosure is a result of an act of a person, not a technical display of sensitive information. And people have ways of getting around regulatory details, intentional or otherwise.

In the early 2000s in the U.S., the Healthcare Information Portability and Accountability Act (HIPAA) Privacy Rule was up for compliance. I was tasked with the statistical analysis of the disclosure risk for a healthcare information services company. The objective of the analysis was to quantify the disclosure risk given the de-identification of the sensitive data elements.

Despite the AES-256 encryption of all 18 sensitive data element types per HIPAA, the analysis showed high re-identification probabilities in ways people did not expect. If someone gained access to the data and spent even a marginal effort trying to re-identify the individuals, it would have been easy enough. So much so that, if I recall correctly, the expected fines would have been in millions of dollars daily.

Regulations may specify sensitive data elements in technical terms, but people will figure out a way to disclose through triangulation. It is not limited to the elements within the same data source, but also triangulation against external data, including public data. This was the hardest thing for people to see. At the end of the day, all the precautions were not going to prevent privacy breaches (which are different from security breaches—this is an important distinction).

The scope of data governance must include good data management practices. This is not just to get ahead of regulations but also to provide coverage in spots regulations can never address. Not only do you get in front of regulations by adopting good data management practices, but you govern how people behave with and around data. Then, you simply adjust to or supplement with the specifics of each regulation.

Do not complicate data governance!

This starts with realizing that data governance is an accountability and decision-making infrastructure about data. It is not just a compliance mechanism.

Every attempt at data governance I have witnessed has made it way more complicated than it needs to be. It is anything but transparent because of the complexity. Things are disjointed and siloed, and the balls get dropped. These are the very things data governance is supposed to prevent.

I have been an advocate and have implemented versions of what is now called Just Enough Governance or Adaptive Governance well before it was called that. Keep it simple. Stress effectiveness and minimize disruption. Incorporate as little formality as you can get away with.

I have multiple examples of this approach that evolved into very effective data practices. In each case, the focus was on implementing basic organizational infrastructure for good data management practices just on principle. Then, compliance simply follows good data management practices.

Data governance: My view from the trenches

Here are proven data governance approaches in my view from the trenches:

• Data governance needs to be reg-agnostic and system-agnostic.
• Among other things, data governance needs to be a mobilization mechanism for the things that need to get done.
• Data governance activities need to be a formal part of the day-to-day responsibilities of the core members of the data governance organization. For them, it is more than a few hours of meetings every few months. If you think otherwise, I assure you what needs to be done is not getting done. This is a big problem with execution.

Separate the data practices objectives from regulatory compliance objectives. No, I am not saying data governance has nothing to do with compliance. Rather, data governance cannot be led by or consumed with compliance. It becomes consumed with compliance when it starts and ends with compliance. Data governance defined within the regulatory compliance context is the best way to get bogged down.

I have seen this implemented in several ways. The effective ones, however, create a parallel and interconnected but separate accountability structure between data management and regulatory compliance. It does not necessarily mean they are separate organizations or even personnel. But each has its own distinct path for how things bubble up or cascade down. This is not a very common approach at all, but one that works quite well from my experience.

At the end of the day, why is your data governance the way it is? Is it because it is what you know from what everyone else in your circle is doing? But is it effective? Is it really working?