What Is Data Governance? Turning Data from a Liability into an Asset

In most organizations, data is an item that never appears on the balance sheet yet grows every year. Managed well, it speeds up decisions and gives reporting and AI initiatives a foundation they can rely on. Left unmanaged, it becomes a liability: it drives up storage and backup costs, produces reports that contradict each other and turns into hard questions during a privacy audit. What separates the two is not the volume of data but who is accountable for it, how it is defined and how it is protected. That framework is called data governance.

This article looks at data governance through the problems we encounter most often in the field and the concrete steps that can be taken at the database layer, rather than through policy documents.

When Does Data Become a Liability?

A lack of data governance rarely presents itself as a governance problem. It usually surfaces as a reporting crisis, a backup window that keeps growing or an audit finding. When we modernize legacy systems that have accumulated over many years in banking, the public sector and large enterprises, what we find tends to look like one of the following three scenarios.

One question, two different answers

In an ERP or data warehouse modernization, the biggest crisis almost always breaks out on the reporting side. Finance takes its numbers from SSAS cubes that are refreshed overnight by SQL Server Agent jobs. Sales or operations, meanwhile, still rely on an SSRS report written years ago that queries the live database directly. The two sources have different data cut-off times, treat returns and cancellations differently, and in most cases nobody has documented those differences. The result is that two different revenue figures for the same period arrive at the same management meeting, and the discussion is about which report is right before it ever gets to the number itself.

None of this is a technical fault. Each report is correct within its own logic. What is missing is a single, organization-wide definition of “revenue” and an owner who is accountable for it.

Tables nobody dares to drop

Almost every long-lived database contains tables that former DBAs or developers created and left behind under names like _temp, _backup_2018 or test_migration. These tables lengthen backups, slow down restores and therefore hurt your RTO, and can occupy terabytes of disk. Yet because nobody can confidently answer “will something break if I drop this?”, the data stays in place for years. Since most of these tables are copies of production tables, they usually contain unmasked personal data as well.

Unlabeled data and AI

Today, the two areas where missing governance costs the most are AI integrations and privacy audits. If you don’t know which data is sensitive, you can’t give a sound answer either to which sources an AI assistant may use or to an auditor asking how the data life cycle is managed. Both are covered in their own sections below.

What Data Governance Is, and What It Isn’t

Data governance is the set of roles, rules and processes that determines who owns data, how it is defined, which quality rules it must meet, who may access it under which conditions and how long it is retained. Data management is the technical implementation of those rules: backups, integration, the data warehouse, security configuration and so on. Governance decides what is done, by whom and why; management decides how.

The most common misconception we see is that data governance can be completed by buying a tool or publishing a policy. A data catalog or a comprehensive policy set is useful, but if table owners are unknown, KPI definitions are unwritten and permissions are never reviewed, those tools simply produce a tidier list of the existing mess. Governance is not a project; it is an ongoing operating model.

The Core Components of Data Governance

Regardless of the size of the organization, effective data governance rests on the components below. Each one should produce a concrete deliverable; otherwise governance remains a concept discussed in meetings but never reflected in the systems.

Governance Starts in the Database

Data governance is often seen as a business topic, but the database is where ownership and classification decisions are actually enforced and can be verified. The steps below use SQL Server, though the same approach applies to other database platforms.

1. Inventory: which tables take up space, and are they still used?

The first step is to list suspicious tables based on naming patterns and usage data. The query below returns tables whose names suggest a backup, a test or a year, together with their size and the last access time SQL Server has recorded:

SELECT
    s.name AS schema_name,
    t.name AS table_name,
    t.create_date,
    CAST(sz.total_pages * 8 / 1024.0 AS decimal(12,1)) AS size_mb,
    ua.last_access,
    (SELECT sqlserver_start_time FROM sys.dm_os_sys_info) AS stats_since
FROM sys.tables AS t
JOIN sys.schemas AS s ON s.schema_id = t.schema_id
CROSS APPLY (
    SELECT SUM(a.total_pages) AS total_pages
    FROM sys.partitions AS p
    JOIN sys.allocation_units AS a ON a.container_id = p.partition_id
    WHERE p.object_id = t.object_id
) AS sz
OUTER APPLY (
    SELECT MAX(v.access_time) AS last_access
    FROM sys.dm_db_index_usage_stats AS us
    CROSS APPLY (VALUES (us.last_user_seek), (us.last_user_scan),
                        (us.last_user_lookup), (us.last_user_update)) AS v(access_time)
    WHERE us.database_id = DB_ID() AND us.object_id = t.object_id
) AS ua
WHERE t.name LIKE '%temp%' OR t.name LIKE '%backup%' OR t.name LIKE '%copy%'
   OR t.name LIKE '%test%' OR t.name LIKE '%old%' OR t.name LIKE '%[_]bak%'
   OR t.name LIKE '%[12][0-9][0-9][0-9]%'
ORDER BY size_mb DESC;

2. Don’t drop anything before you verify its dependencies

To be sure a table is unused, you need to look at dependencies inside the database, but that alone isn’t enough. sys.dm_sql_referencing_entities only shows references from objects such as views, stored procedures and functions in the same database. It doesn’t show dynamic SQL, queries from other databases, application code, SSIS packages or SSRS reports.

SELECT referencing_schema_name, referencing_entity_name
FROM sys.dm_sql_referencing_entities(N'dbo.customer_backup_2018', N'OBJECT');

In environments that use SSRS, the ReportServer database shows which report ran, when and how often. This query is a good starting point both for finding unused reports and for finding old reports that, as in the first scenario, still query the live system. Keep in mind that by default the execution log only keeps the last 60 days.

USE ReportServer;
SELECT
    c.Path AS report,
    COUNT(e.TimeStart) AS executions,
    MAX(e.TimeStart) AS last_execution
FROM dbo.Catalog AS c
LEFT JOIN dbo.ExecutionLog3 AS e ON e.ItemPath = c.Path
WHERE c.Type = 2   -- report
GROUP BY c.Path
ORDER BY last_execution;

Before dropping a suspicious table, the most reliable method is to record every access to it with SQL Server Audit over a full business cycle, covering at least one month-end and preferably a quarter-end:

USE master;
CREATE SERVER AUDIT Audit_LegacyTables
    TO FILE (FILEPATH = N'D:\SQLAudit\');
ALTER SERVER AUDIT Audit_LegacyTables WITH (STATE = ON);
GO
USE SalesDB;
CREATE DATABASE AUDIT SPECIFICATION Audit_LegacyTables_Spec
    FOR SERVER AUDIT Audit_LegacyTables
    ADD (SELECT, INSERT, UPDATE, DELETE ON OBJECT::dbo.customer_backup_2018 BY public)
    WITH (STATE = ON);
GO
-- Read the captured events:
SELECT event_time, server_principal_name, client_ip, application_name, statement
FROM sys.fn_get_audit_file(N'D:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT);

3. Label your sensitive data

You can’t design masking or access policies without knowing which columns hold personal or financial data. SQL Server’s Data Discovery & Classification feature in SSMS suggests classifications based on column names and lets you label columns. From SQL Server 2019 onwards, these labels can be managed in T-SQL and queried from the sys.sensitivity_classifications view:

ADD SENSITIVITY CLASSIFICATION TO dbo.Customer.NationalId
WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'National ID', RANK = CRITICAL);

SELECT
    SCHEMA_NAME(o.schema_id) AS schema_name,
    o.name AS table_name,
    c.name AS column_name,
    sc.label,
    sc.information_type,
    sc.rank_desc
FROM sys.sensitivity_classifications AS sc
JOIN sys.objects AS o ON o.object_id = sc.major_id
JOIN sys.columns AS c ON c.object_id = sc.major_id AND c.column_id = sc.minor_id;

Bear in mind that the recommendations are based on column names only. Personal data stored in free-text fields such as description or notes won’t show up in that scan, so those fields need to be reviewed together with the business teams.

4. Restrict visibility

Once data is labeled, the next step is to limit who can see what. Dynamic Data Masking (SQL Server 2016 and later) returns masked values to users who lack permission. Since SQL Server 2022, the UNMASK permission can be granted at column, table and schema level:

ALTER TABLE dbo.Customer
    ALTER COLUMN NationalId ADD MASKED WITH (FUNCTION = 'partial(2,"*******",2)');

-- SQL Server 2022 and later: unmasked access to this column only
GRANT UNMASK ON dbo.Customer(NationalId) TO RiskAnalystRole;

When restrictions are needed at row level, for example when a regional manager should only see customers in their own region, Row-Level Security is the right tool. Regularly reviewing who holds which role is what keeps these controls effective; we cover that in detail in our SQL Server security hardening guide.

One Version of the Truth: Giving KPIs an Owner

The fix for the SSAS versus SSRS conflict in the first scenario is not to write yet another report. First, the calculation rule, the data cut-off time and the transactions included in a critical term such as “revenue” are defined in writing, and a business owner is assigned to that definition. A single approved data source that follows the definition, usually the data warehouse or a semantic model, then becomes the common source for every department. Old reports that query the live database directly are either retired or moved to the approved source, based on the ReportServer usage data.

A side effect of this approach is better performance. Once the reports that load the operational database with heavy queries during business hours are gone, blocking and resource consumption on the live system drop noticeably. We help design reporting architectures like this as part of our business intelligence services.

Missing Governance in AI Projects

Suppose you are building a RAG (retrieval-augmented generation) assistant that can query internal documents and the database, backed by PostgreSQL, pgvector and Azure OpenAI embedding models. Technically, the system may work flawlessly. But if your data isn’t labeled and your access policies haven’t been tightened, the model may pull unmasked national ID numbers or financial risk reports from log tables left behind by an old ERP service, or from a report folder that was never hardened, and summarize them for an employee who has no right to see them.

The source of that risk isn’t the model; it’s the data the model is given. Two rules are therefore critical in RAG projects. First, index only sources that have been classified and approved by their owner. Second, enforce access control at query time, in the data layer. In PostgreSQL this can be done with a Row-Level Security policy on the embedding table, so that vector similarity search only runs over rows the user is entitled to see:

ALTER TABLE document_chunk ENABLE ROW LEVEL SECURITY;

CREATE POLICY document_access ON document_chunk
    FOR SELECT
    USING (access_group = ANY (string_to_array(current_setting('app.user_groups', true), ',')));

-- The application passes the authenticated user's groups into each transaction
BEGIN;
SET LOCAL app.user_groups = 'sales,operations';
SELECT id, content
FROM document_chunk
ORDER BY embedding <=> $1
LIMIT 5;
COMMIT;

The important detail is that the application must not connect as the role that owns the table. In PostgreSQL, table owners and superusers are not subject to these policies unless FORCE ROW LEVEL SECURITY is set. In applications that work through a single database user via an ORM such as Prisma, it also needs to be tested that the user context is passed into the session correctly for every transaction. We handle the data-readiness side of AI projects as part of our data analytics and AI services.

Privacy Audits: Proving the Data Life Cycle

Privacy regulations such as GDPR in Europe and KVKK in Türkiye expect a data controller not only to protect personal data, but also to show why it is processed, how long it is kept and how it is disposed of when that period ends. Under KVKK, for example, controllers that must register with VERBİS are required to maintain a retention and disposal policy aligned with their personal data inventory; periodic disposal may not be spaced more than six months apart, and records of deletion, destruction or anonymization must be kept for at least three years.

Most organizations have such a policy on paper. The problem is that it doesn’t match what is actually in the database. When a database health check or penetration test finds unowned _backup tables containing personal data, or orphaned database files forgotten on disk, it becomes clear that this data was never in the inventory and never entered the disposal process. Once the data life cycle can’t be proven, the issue stops being a technical finding and becomes a compliance problem with real exposure to formal warnings and administrative fines.

That’s why the privacy inventory and the database inventory need to be linked. The list of classified columns should be mapped to the data categories in the inventory, and legacy table clean-ups should be recorded as part of the disposal process. Capturing who accesses tables that hold personal data with SQL Server Audit also answers the “who accessed this data?” question auditors ask.

A Realistic Start in 90 Days

The most common reason data governance initiatives fail is that the organization tries to cover all of its data at once. A more realistic approach is to start with the 10 to 20 data elements that matter most to the business and widen the scope once those deliver results.

• Days 1–30: Visibility. Inventory your critical databases, list suspicious legacy tables and unused reports, and label columns that hold sensitive data. Identify the 10 to 20 KPIs that management argues about most.
• Days 31–60: Ownership and definitions. Assign a business owner to each critical data element and KPI, write the definitions down and get them approved. Build the permission matrix, remove excessive privileges and start auditing suspicious tables.
• Days 61–90: Control and continuity. Move the approved definitions onto a single reporting source, apply masking and access rules, and carry out a recorded legacy clean-up based on the audit results. Make data quality rules and a monthly review meeting part of the routine.