A customer emails your support team and asks what personal data you hold about them. Under the General Data Protection Regulation (GDPR), you generally have one month to answer. The request lands in a shared inbox, gets forwarded to IT, then to marketing, then to a sales manager who still keeps a spreadsheet of trade-show leads. Three weeks later, someone asks who's responsible for pulling the answer together, and nobody is quite sure.

Nothing in that story is a technology problem. The data exists, and the systems work. What's missing is agreement on who owns which data, which rules apply to it, and who makes the call when something is unclear. That agreement is what data governance provides.

What is data governance?

In practice, data governance is a set of standing decisions. Who can approve access to customer data? Which system holds the official version of a customer record? How long are contracts kept, and who signs off before they're deleted? What happens when someone finds an error in a report the board relies on? A governance program makes sure each of these questions has an agreed answer, an owner, and a place where the answer is written down.

The goal is data people can trust: accurate enough to rely on, secure, available to the right people, and handled in line with legal and contractual obligations.

A practical example: a retailer decides that customer email addresses are owned by the marketing team, may only be used for the purposes they were collected for, are deleted after a set period of inactivity, and can be accessed by support staff only through the customer relationship management (CRM) system. Each of those decisions is a governance decision, and that layer is what Formalize's data governance capabilities are built around. Storing and syncing the addresses across systems, by contrast, is data management.

Data governance vs data management: what is the difference?

The two terms are often used interchangeably, but they do different jobs. If governance is the traffic code, data management is the driving.

The lines aren't rigid. Data stewards and system owners often work on both sides: they help shape the rules and apply them in daily work.

Why is data governance important?

Most organizations come to data governance through a symptom: two reports that disagree, an audit request that takes weeks, or a regulator asking for evidence. Governance addresses the causes behind those symptoms:

• Trust in the numbers: When definitions and ownership are agreed, reports from different teams are easier to reconcile.

• Clear accountability: Each important dataset has someone responsible for it, and everyone knows who that is.

• Privacy, security, and compliance: Regulations like the GDPR and standards like ISO 27001 expect organizations to know what data they hold, who can access it, and why.

• Less duplication: Consistent rules reduce parallel copies, conflicting spreadsheets, and one-off workarounds.

• Auditability and risk management: Documented governance decisions create a trail, which makes it possible to show how data risks are identified and handled.

• A foundation for analytics and AI: Dashboards and models are only as reliable as the data behind them.

What are the core components of data governance?

There's no single official model, but most programs rest on four building blocks. When people talk about the "four pillars of data governance," these are usually what they mean.

1. People and accountability: Data owners, data stewards, and the people with decision rights, from a governance council to the teams that handle data every day.

2. Policies and standards: The rules for data quality, access, classification, retention, and use.

3. Processes and controls: How those rules are applied in practice, and how the organization checks that they're followed.

4. Technology and oversight: The systems that support governance with monitoring, evidence, and reporting.

None of the four works on its own. Policies without owners go stale, and owners without processes end up improvising.

What is a data governance framework?

A data governance framework is the structured model an organization uses to set up governance roles, policies, processes, controls, and responsibilities, and to connect them. That connection is the difference between a framework and a collection of individual data policies. A retention policy, an access policy, and a classification scheme are each useful, but a framework defines how they relate, who decides when they conflict, and how compliance with them is measured.

A typical framework covers ownership and decision rights, standards and policies, processes and controls, escalation paths, and the measures used to track whether governance is working.

Common data governance frameworks

Several recognized frameworks give organizations a starting point. None of them is universally best, and each fits a different kind of challenge:

These frameworks aren't mutually exclusive. Many organizations take their vocabulary from DAMA-DMBOK, borrow roles from the DGI model, and align controls with COBIT or ISO 27001, depending on what their auditors and regulators expect. The choice of framework matters less than whether its responsibilities and controls are applied consistently. If your data governance program also needs to connect with regulatory and compliance frameworks such as ISO 27001, NIS2, or DORA, explore Formalize's compliance blueprints.

How to implement data governance

A practical way to put the four components in place is to work through six steps, starting narrow and widening over time:

1. Define governance objectives and scope

Start with the data that matters most: data tied to regulatory obligations, customer trust, or critical business decisions. A focused scope, such as customer personal data or financial reporting data, gets further than an attempt to govern everything at once.

2. Establish ownership and responsibilities

Name data owners, who are accountable for a dataset and decide how it may be used, and data stewards, who look after its quality and day-to-day handling. Ownership belongs in the business, not with IT by default.

3. Map critical data and requirements

Document which data exists, where it lives, who uses it, and which policies, risks, and regulations apply. For personal data, much of this overlaps with the GDPR's records of processing activities.

4. Define policies, standards, and controls

Set rules for access, quality, classification, retention, and acceptable use, and decide how you'll check that they're followed. A policy without a control is a statement of intent.

5. Build governance into operational workflows

Translate the rules into tasks, approvals, reviews, and escalation paths that people encounter in their normal work. If a new system can go live without anyone reviewing the data it handles, governance only exists on paper.

6. Monitor and continuously improve

Track exceptions, open risks, and evidence over time, so problems surface early rather than during an audit.

One dataset, six steps. Here's how the sequence plays out for customer data at the retailer from earlier:

That record is what you'll need the next time someone asks why the model was allowed to use the data.

Data governance best practices

Once the basics are in place, a few habits decide whether a program lasts beyond the first push:

• Measure what governance changes: Track a few concrete indicators, such as the share of critical data with a named owner, overdue reviews, or open exceptions.

• Put rules where decisions happen: A policy is far more likely to be followed when it shows up in the workflow where the decision is made.

• Write policies people can follow: Short, specific rules in plain language get applied. Fifty-page documents get filed.

• Keep decisions traceable: Link each decision to the action taken and the evidence behind it, so you can show why something was done.

• Schedule reviews around change: New regulations, new systems, and new uses of data, such as AI, are the moments when governance needs a second look.

Data governance, compliance, and AI

Regulation is one of the strongest drivers of data governance, because most data rules expect organizations to prove how they meet them. That proof depends on governance.

The GDPR's accountability principle makes controllers responsible for complying with its principles, and requires them to be able to demonstrate it. Records of processing activities, retention rules, access controls, and DPIAs are all governance work. Information security standards such as ISO 27001 add expectations around asset inventories, information classification, and access control.

AI adds a further layer. Under the EU AI Act, providers of high-risk AI systems must apply data governance and management practices to the data used to train, validate, and test those systems, including checks for quality, relevance, and possible bias. Following the Digital Omnibus on AI, these high-risk obligations apply from December 2, 2027, for stand-alone systems and from August 2, 2028, for AI embedded in regulated products, according to the European Commission.

Even outside the high-risk category, any AI tool that uses personal data brings the GDPR into play. Organizations that already know which data they hold, and under which rules, are in a far better position to use AI responsibly. Our AI Act page covers this in more detail.

How Formalize supports data governance

Formalize focuses on the governance layer: the owners, policies, risks, and evidence that sit above the data itself.

• Processing activities in context: Records of processing linked to the systems, suppliers, and risks they involve, alongside DPIA and transfer impact assessment (TIA) workflows.

• Policies with a lifecycle: Drafted, approved, published, and tracked for acknowledgment, with version history.

• Owners, approvals, and a full activity history: Every policy, control, and task has a named owner, with role-based permissions, and each decision is recorded together with its evidence.

• Data governance alongside GDPR, ISO 27001, NIS2, and the AI Act, in the same system instead of separate tools.