What Is Data Governance?

Data needs owners and rules, too

Part 7 of 12 in "Databases for Non-Developers". This part covers data governance — turning the data quality problems we saw in Part 6 from accidents into a managed system.

---

In a meeting, the revenue numbers don't match. Sales is looking at the CRM, finance at the accounting system, product at the app's analytics dashboard. Someone asks, "Which number is right?" — but nobody is responsible for answering.

No amount of database performance tuning will fix this. You need to define what the data means, who is responsible for it, and how it may be used. That is the domain of data governance.

Governance is not a control department

Data governance is the system an organization uses to set decision-making authority and rules so that data is used valuably, safely, and responsibly. In plain terms, it's giving organization-level answers to these questions:

• What data do we collect, and why?
• What does each piece of data mean, and what standards apply?
• Who decides about quality and usage?
• Who can view and modify it?
• How long do we keep it, and when do we delete it?
• When something goes wrong, who owns the fix?

The goal is not to create more meetings or block every use of data. The goal is to let the right people use trustworthy data under the right conditions. An organization with good governance doesn't use data less — it uses data with more confidence.

Data management vs. data governance

If governance is traffic law, data management is closer to maintaining the roads and operating the traffic lights. You can't travel safely with only one of them. Without laws, the roads are chaos; without road maintenance, laws are just words on paper.

Three roles to distinguish

Names vary by organization, but these roles are usually needed.

Data owner

The data owner decides the purpose, use, and quality standards of data from a business perspective. For customer data, that might be the leader responsible for customer operations. "Owner" doesn't mean someone who uses it however they personally like. It means they hold the decision-making authority and the responsibility.

Data steward

The data steward makes sure definitions and quality standards are followed in day-to-day work. They spot duplicates, gaps, and conflicting terminology, and coordinate with the relevant departments. Think of them as the person in charge of keeping the data household in order.

Data custodian

The data custodian handles the operational side: access permissions, storage, backups, and technical protection. Database administrators, security teams, and cloud operations teams can share this role.

In a small organization, one person can wear several hats. What matters more than job titles is making decision rights and responsibilities explicit. And one mindset shift is required: responsibility for the content and definition of data belongs to the business side, not IT. IT is the warehouse keeper, not the owner of what's inside the warehouse.

Start with a data inventory

If you don't know what data you have, you can neither protect it nor use it well. You don't need to buy a massive management tool from day one. Start with your important data and build a list covering:

• The data's name and a plain-language description
• Where it is created and where it is stored
• The business owner and the technical contact
• Whether it contains personal or sensitive information
• Who is allowed to use it
• How long it is retained
• Where it is shared with other systems
• The date of the last quality and permissions review

Descriptions of data like this are called metadata — "data that describes data." Just as a photo file carries its capture date and location, data needs information explaining "what this is and where it came from." Data piled up without metadata is like boxes in a warehouse with no labels.

Classification makes protection standards clear

Protecting all data the same way either drives costs up unnecessarily or leaves your truly important data under-protected. An organization might classify data like this, for example:

1. Public: material anyone may see
2. Internal: material employees need for work, but which shouldn't be shared externally
3. Confidential: business and customer information only designated people should see
4. Highly sensitive: health, financial, and authentication information whose leak could seriously harm individuals or the organization

The classification labels matter less than what storage, transmission, sharing, and retention rules apply to each level.

Minimum governance for a small organization

Even a small organization can set these five things:

1. Build a list of important data
2. Name one business owner for each item
3. Write definitions of key terms and metrics in one place
4. Review access permissions and retention periods regularly
5. Define who reports and fixes quality and security issues, and how

The U.S. National Institute of Standards and Technology (NIST) Cybersecurity Framework 2.0 likewise treats security not as a purely technical task but as a matter of organizational risk management and decision-making, and includes "govern" among its core functions.

It's also worth knowing why governance initiatives so often fail: teams produce compliance documents without applying them to real work; IT pushes ahead alone and drifts away from reality; or an organization aims for company-wide perfection from the start, burns out, and stalls. Your odds are better if you start with a pilot: pick your most painful data (usually "customer data") and try unifying its definition → naming an owner → measuring its quality.

Key takeaways Data governance is not a set of restrictions blocking data — it's a decision-making system that makes data trustworthy and usable. Make definitions, owners, access permissions, quality, and retention and deletion standards explicit. You can start with a list of important data and one owner rather than a big committee.

Questions to think about

• Who gets to make the final call on the definitions of "customer" and "revenue"?
• Do you know where your important data gets copied and sent?
• When do you revoke access for people who have left or changed roles?
• Who measures and reports the quality criteria from Part 6 (accuracy, completeness, consistency…)?

Next: We'll look at why collecting lots of personal information can be a liability rather than an asset — the full lifecycle of personal data, from collection to deletion.

References: NIST Cybersecurity Framework 2.0, NIST Privacy Framework

---

Series contents

1. What Is a Database — and How Is It Different from an Excel File?
2. How Databases Keep Data Accurate
3. What Kinds of Databases Are There?
4. Databases, Data Warehouses, and Data Lakes
5. Why Choosing the Right Database Matters
6. Data Models and Data Quality
7. What Is Data Governance? ← You are here
8. Less Personal Information, Only What You Need
9. The Basics of Data Security
10. Why Do Data Breaches Happen, and What Should You Do When One Does?
11. Cloud and Serverless Databases
12. Databases in the AI Era