By Compyl Research · Last reviewed September 2026
Data governance is the set of policies, roles and controls that determine who can access which data, how it is classified, how long it is kept and how its quality is maintained. It used to be a data-team concern. It is now a compliance prerequisite, because almost every recent regulation — from the EU AI Act to state privacy law — assumes you already know what data you hold and where it lives.
Key takeaways
- The driver changed. Data governance was historically justified by analytics quality. It is now justified by regulation: you cannot answer a deletion request, evidence an AI system’s training data, or scope a PCI assessment without it.
- It is not the same as data management or data security. Governance sets the rules and assigns accountability; management operates the pipelines; security defends the perimeter. Conflating them is why programs stall.
- Ownership is the failure point, not tooling. Most programs die because nobody owns a domain. Named data owners with decision rights matter more than any platform.
- Start with an inventory you can defend — what data you hold, its classification, where it lives, who can reach it, and how long you keep it. Everything else builds on that, and every regulator asks for it first.
Why data governance became a compliance requirement
For most of its history, the business case for data governance was analytical: cleaner data, fewer conflicting reports, better decisions. That argument struggled to win budget because the cost of bad data was diffuse.
The case is now regulatory, and much harder to defer. Several obligations that arrived in the last few years all assume the same foundation:
- Privacy law assumes a data inventory. Responding to a deletion or access request within a statutory deadline requires knowing every system that holds a given person’s data. You cannot search what you have not mapped.
- AI governance assumes data lineage. ISO/IEC 42001 and the EU AI Act both expect you to describe the data an AI system was trained and operated on. That is a data governance artifact, not a machine learning one.
- Retention obligations run in both directions. Some records must be kept for a defined period; personal data must not be kept beyond its purpose. Satisfying both at once requires classification and a retention schedule that is actually enforced.
- Scoping decisions depend on it. PCI DSS scope, HIPAA’s definition of a designated record set, and DORA’s ICT asset register all turn on knowing where regulated data flows.
- Third-party risk inherits it. You cannot assess a vendor’s handling of your data without knowing what data they receive.
The practical consequence: data governance is no longer a project the data team runs when there is time. It is the substrate several compliance programs stand on, and its absence surfaces as findings in all of them at once.
Data governance vs data management vs data security
These three get used interchangeably and are not the same thing. The distinction matters because they have different owners and different failure modes.
| Data governance | Data management | Data security | |
|---|---|---|---|
| Question it answers | Who decides, and what are the rules? | How does data move and stay usable? | How is it protected from misuse? |
| Typical owner | A governance council or data owners in the business | Data engineering or IT | Security team |
| Core artifacts | Policies, classification scheme, data inventory, retention schedule, ownership register | Pipelines, models, catalogs, quality rules | Access controls, encryption, monitoring, DLP |
| Failure looks like | No one can say who owns a decision | Reports disagree with each other | A breach, or access nobody revoked |
Governance is the layer that makes the other two accountable. A strong security program on ungoverned data still cannot tell a regulator what was in the system that was breached.
What each framework expects you to have
| Obligation | What it assumes about your data governance |
|---|---|
| GDPR and UK GDPR | A record of processing activities, a lawful basis per purpose, defined retention, and the ability to locate and delete an individual’s data across systems |
| US state privacy laws | An inventory sufficient to honour access, correction and deletion rights within statutory deadlines, plus categories of data sold or shared |
| ISO/IEC 27001:2022 | Classified information assets with owners (A.5.9 through A.5.13), and retention and disposal handled deliberately |
| ISO/IEC 42001 and the EU AI Act | Documented data provenance, quality and governance for the data used to train and operate AI systems |
| PCI DSS v4.0.1 | Known cardholder data flows and storage locations — scope is defined by where the data actually is, not where you think it is |
| HIPAA | A defined designated record set, minimum necessary access, and retention of required documentation |
| DORA and financial regulation | An ICT asset and data register, with critical data identified and dependencies mapped |
| SOC 2 | Confidentiality and privacy criteria that depend on classification and defined disposal |
Read down the right-hand column and the same four artifacts keep appearing: an inventory, a classification scheme, named owners, and a retention schedule. Build those once and most of the column is satisfied.
How to implement data governance
- Set goals tied to an obligation, not to an ideal. “Answer deletion requests within 30 days across all systems” funds itself. “Improve data quality” does not. Pick the two or three outcomes a regulator or customer is actually asking for.
- Find the executive owner before the tooling. Data governance crosses IT, legal, security and the business, which means it needs someone senior enough to settle disputes. Programs without that sponsor stall at the first territorial disagreement.
- Inventory what you hold. Systems, data types, volumes, locations, and who can reach them. It will be incomplete on the first pass — publish it anyway and improve it, because an imperfect inventory beats none and is what every other step depends on.
- Classify with as few tiers as you can defend. Public, internal, confidential, restricted is enough for most organizations. Every additional tier multiplies the handling rules people have to remember and therefore ignore.
- Assign data owners by domain, not by system. Someone owns customer data; someone owns employee data; someone owns financial records. Owners approve access, set retention and answer questions. This is the single highest-impact step and the one most often skipped.
- Write policies that reference the classification. One data governance policy, plus a retention schedule and an acceptable use standard, is usually enough. Long policies nobody reads are worse than short ones people follow.
- Set retention and actually enforce disposal. A retention schedule that is documented but never executed is worse than none — it evidences that you knew what you should have deleted and did not.
- Instrument it. Access reviews, classification coverage and retention execution should produce evidence automatically rather than being reconstructed before an audit.
- Review quarterly and after every material change — a new system, a new jurisdiction, an acquisition, or a new AI use case.
Who owns what
| Role | Accountable for |
|---|---|
| Executive sponsor | Funding, arbitration between functions, board reporting |
| Data governance lead | The framework, the policies, the inventory, and the cadence |
| Data owners (business) | Access approval, classification and retention decisions for their domain |
| Data stewards | Day-to-day quality, metadata and issue resolution within a domain |
| Security | Enforcing the controls the classification implies |
| Legal and privacy | Lawful basis, regulatory interpretation, individual rights requests |
| IT and data engineering | Implementing controls in systems and pipelines |
Small organizations combine these — one person can be lead, steward and privacy contact. What cannot be combined away is the business data owner, because the decisions they make are business decisions, not technical ones.
Data governance in regulated industries
Financial services and banking carry the heaviest version of this problem: decades of records across core banking, lending, payments and CRM systems, often several generations of technology deep, with multi-branch and multi-entity structures that fragment the same customer across systems. Add mobile channels producing continuous transaction data, and regulators — DORA, NYDFS, GLBA, and banking supervisors generally — expecting a defensible data and ICT asset register. The practical starting point in banking is almost always regulatory scope first: identify the data in scope for each obligation, then work outward, rather than attempting an enterprise-wide inventory in one pass.
Healthcare turns on the designated record set and minimum necessary access, with the added complication that clinical systems rarely delete anything. Technology companies usually have the opposite problem: fewer systems, but data flowing into analytics, support and AI tooling faster than governance can follow, and a growing obligation to describe what any of it trained.
What to measure
- Inventory coverage — the share of known systems with documented data types, owners and classification.
- Ownership coverage — the share of data domains with a named, current owner.
- Retention execution — records disposed on schedule against records due for disposal. The gap here is a live liability.
- Access review completion and the rate of access revoked at review, which indicates whether reviews are real.
- Time to fulfill an individual rights request, measured against the statutory deadline rather than internal target.
- Classification accuracy, sampled — automated classification drifts, and nobody notices until an audit.
Common failure points
- No named business owner, so every decision escalates and nothing is decided.
- Too many classification tiers, so nobody applies them consistently and the scheme becomes decorative.
- An inventory built once for an audit and never maintained, which is worse than none because it is confidently wrong.
- Retention documented but not enforced — the most common finding, and the one with the clearest downside in litigation or breach.
- Shadow data in spreadsheets, personal drives and SaaS tools outside the inventory, which is where most rights requests eventually fail.
- Treating it as a tooling purchase. A catalog with no owners and no policy documents your problem in more detail; it does not solve it.
Where Compyl fits
The four artifacts every framework asks for — inventory, classification, ownership, retention — are the same four artifacts, requested in different words by different auditors. Compyl holds them once in one control library mapped across 70+ frameworks, so the data inventory that answers a GDPR record of processing also evidences ISO 27001 A.5.9, PCI DSS scoping and the data governance expectations in ISO 42001. Access reviews and retention execution generate evidence automatically rather than being reconstructed before each audit, and data owners are tracked with review dates rather than living in a spreadsheet nobody has opened since the last assessment.
See how one data inventory satisfies GDPR, ISO 27001 and SOC 2 at the same time in a 20-minute walkthrough — request a demo, or read the data retention policy guide for the retention half of the problem.
Frequently asked questions
What is data governance?
Data governance is the framework of policies, roles and controls that determines who can access which data, how it is classified, how long it is retained and who is accountable for its quality and use. It sets the rules; data management operates the systems that follow them.
What is the difference between data governance and data management?
Governance decides the rules and assigns accountability — classification, ownership, retention, access policy. Management executes: pipelines, catalogs, quality processes and storage. Governance is typically owned by the business with legal and compliance input; management sits with IT or data engineering.
Why is data governance important?
Because most current regulation assumes it. Answering a deletion request, evidencing what data trained an AI system, scoping a PCI assessment or producing an ICT asset register all require knowing what data you hold and where it lives. Without that foundation the same gap surfaces as findings across several compliance programs at once.
How do you implement a data governance framework?
Tie goals to a real obligation, secure an executive owner, inventory what you hold, classify with few tiers, assign business data owners by domain, write a short policy plus a retention schedule, enforce disposal, instrument the evidence, and review quarterly. Assigning owners is the step that most determines whether the rest survives.
Who is responsible for data governance?
An executive sponsor funds and arbitrates; a governance lead runs the framework; business data owners make access, classification and retention decisions for their domain; stewards handle day-to-day quality; security enforces the controls; legal and privacy interpret obligations. Roles can be combined in smaller organizations — except the business data owner, whose decisions are not technical ones.
What is data governance in banking?
The same discipline under heavier conditions: decades of records across core banking, lending, payments and CRM systems, multi-entity structures that fragment a single customer, continuous mobile transaction data, and regulators expecting a defensible data and ICT asset register under DORA, NYDFS, GLBA and supervisory guidance. Banks generally start from regulatory scope rather than attempting an enterprise-wide inventory in one pass.
What should a data governance policy contain?
Scope and objectives, the classification scheme and handling rules per tier, named roles and decision rights, access approval process, retention and disposal schedule, requirements for third parties receiving data, and a review cadence. One readable policy plus a retention schedule beats a long document nobody follows.
How does data governance relate to AI governance?
AI governance depends on it. ISO/IEC 42001 and the EU AI Act both expect you to describe the provenance, quality and permitted use of the data an AI system was trained and operates on. That description is a data governance artifact. Organizations attempting AI governance without a data inventory usually discover they are building the inventory anyway.
Sources: GDPR Articles 5 and 30; ISO/IEC 27001:2022 Annex A controls 5.9–5.13; ISO/IEC 42001; PCI DSS v4.0.1 scoping guidance; HIPAA Privacy Rule; DORA ICT risk management requirements. Verify current obligations against the published texts before relying on them for an audit.
