Data Governance and Data Catalogue Security Guide

Most organisations cannot say who owns a given dataset, how sensitive it is or who can read it, and the data catalogue that was meant to answer those questions has become another unsecured system holding the map to everything valuable. Data governance sets the decision rights: owners, stewards, classification and the rules for use. The data catalogue is where those decisions become metadata and, increasingly, where access is actually enforced, through tag-based policies in services such as AWS Lake Formation, Databricks Unity Catalog, Google BigQuery policy tags and Microsoft Purview Unified Catalog. This guide covers the governance model, how catalogues enforce access, how to secure the catalogue itself, and how to keep governance from drifting as data, SaaS and AI pipelines grow. It is written for security architects, data platform engineers and privacy teams who share responsibility for the same data estate.

Key takeaways

Governance is decision rights, not a tool. A catalogue only helps if every dataset has a named owner and steward who can say yes or no to access, and that ownership survives reorganisations.
Classification must drive access automatically. Tags or policy tags on columns and tables (for example classification=restricted) should grant or deny access, so a new table inherits the right controls without a ticket.
The catalogue is a high-value target. It lists where sensitive data lives, holds connection details for scanners and often grants access itself; protect its admin roles like privileged access.
Machine identities do most of the reading. ETL jobs, BI service accounts, scanners and AI pipelines hold the broadest grants and are rarely reviewed; govern them as non-human identities.
Measure drift, not just coverage. Track untagged sensitive columns, grants made outside the tag model and owners who have left, because governance decays quietly between audits.

What data governance covers and where security fits

Data governance is the system of accountability for data: who decides how it is used, which policies apply and how compliance is checked. Security teams often meet it only through classification labels, but the dependency runs both ways. Access control, DLP and retention all fail if nobody can say what a dataset is or who owns it.

DAMA-DMBOK: DAMA International's Data Management Body of Knowledge (2nd Edition, with a 2.0 revision launched in 2024 and a DMBOK 3.0 project started in 2025) treats data governance as the function that guides the other data management disciplines, including metadata management and data security. Use it for vocabulary and role definitions.
ISO/IEC 38505: ISO/IEC 38505-1 applied the ISO/IEC 38500 governance principles and model to data, aimed at governing bodies (boards and executives). ISO lists the 2017 edition as withdrawn, so check the ISO catalogue for the current edition before citing it; ISO/IEC TR 38505-2:2018 relates it to data management and refers to a data accountability map. Treat 38505 as the board-level layer, not an operational control set.
NIST Privacy Framework: Version 1.0 is the published version; version 1.1 has been issued as an Initial Public Draft. Its Identify-P function contains ID.IM-P Inventory and Mapping, which asks that systems, owners, data actions, purposes and data elements are inventoried and that data processing is mapped (ID.IM-P1 to ID.IM-P8). Control-P contains CT.DM-P Data Processing Management, including data destroyed according to policy (CT.DM-P5) and processing permissions that travel with data elements (CT.DM-P7). NIST is also developing a Data Governance and Management Profile, which had no public draft at the time of writing.
EU Data Governance Act: despite the name, Regulation (EU) 2022/868 is about data sharing (re-use of protected public-sector data, data intermediation services and data altruism), not internal governance. It has applied since September 2023. It matters if you act as or use a data intermediary; it does not define your internal catalogue controls.

Roles that must exist

Role	Accountable for	Security interface
Data owner (business)	Approves use and access, sets classification, accepts risk	Approves access requests and certifies access reviews
Data steward	Definitions, glossary terms, quality, lineage, tagging accuracy	Keeps classification tags correct so policies apply
Data custodian or platform team	Runs the warehouse, lake and catalogue; implements grants	Implements tag-based policies, logging, encryption
Catalogue administrator	Catalogue configuration, scanners, role assignment	Privileged role: PAM, MFA, separation from data owners
Privacy and security	Policy, classification scheme, monitoring, DPIAs	Defines rules, monitors access, investigates anomalies
Data consumers (people and workloads)	Use data within approved purpose	Request access through the catalogue; subject to review

Classification as the bridge between governance and access

A classification scheme only reduces risk when it is applied at the level where access is enforced, which for structured data means tables and columns rather than whole databases. Keep the scheme short (three to five levels) and add a small number of data-type tags for regulated categories such as personal data, payment card data and health data. See the Data Classification Guide.

Discover before you tag: use the catalogue's scanners or a data profiling service to find sensitive columns. Google documents using Sensitive Data Protection data profiles to identify which BigQuery columns need policy tags; Microsoft Purview Data Map scans sources to capture metadata and classifications.
Tag at the column: a customer table usually mixes public product codes with personal data. Column-level tags let analysts use the table without seeing the sensitive fields.
Inherit by default, override deliberately: in Lake Formation, tables inherit LF-Tags from databases and columns inherit from tables, and an inherited value can be overridden. Make overrides visible in reports, because an override is where restricted data is most often downgraded by mistake.
Keep labels consistent across stores: the same classification should mean the same thing in the warehouse, the SaaS export and the DLP policy. See the Data Loss Prevention (DLP) Guide.

How data catalogues enforce access

Modern catalogues are no longer passive inventories. In several platforms the catalogue is the policy decision point, so its permission model is the access model. The main approaches differ in where policy lives and how it scales.

Platform feature	Model	Key objects and roles	Points to watch
AWS Lake Formation with AWS Glue Data Catalog	Tag-based access control (LF-TBAC) or named resource grants	LF-Tags (key-value), LF-Tag creators, LF-Tag expressions, grants such as SELECT on tables with a given tag	LF-Tags are not IAM tags; AWS recommends revoking named resource grants after verifying LF-TBAC, otherwise the two models overlap
Databricks Unity Catalog	Hierarchical privileges on securables	Metastore, catalog, schema, then tables, views, volumes, functions, models; USE CATALOG, USE SCHEMA, SELECT, MODIFY, BROWSE, MANAGE	Grants on a catalog or schema apply to current and future children; MANAGE is not included in ALL PRIVILEGES and allows privilege management without ownership
Google BigQuery policy tags	Column-level access via Data Catalog taxonomies	Taxonomy, policy tags (one per column), Data Catalog Fine-Grained Reader (`roles/datacatalog.categoryFineGrainedReader`), Policy Tag Admin (`roles/datacatalog.categoryAdmin`)	Access needs dataset permission plus Fine-Grained Reader; dynamic data masking can return null, default or hashed values instead
Microsoft Purview Unified Catalog	Federated governance domains with delegated roles	Governance domains, data products, Governance Domain Owner, Data Product Owner, Data Steward, Global and Local Catalog Reader	Users with Read on the underlying Azure or Fabric resource may see catalogue assets you did not intend; Microsoft recommends at least two Governance Domain Owners per domain

Choosing between tag-based and named grants

Named resource grants are simple to reason about for a small estate. AWS shows the problem at scale: with every principal needing every resource, grants grow as principals multiplied by resources, while a single tag model grows as principals plus resources.
Tag-based (attribute) grants scale and make new tables safe by default, but they move the risk to whoever can create or assign tags. Restrict tag creation and tag assignment to stewards and the platform team, and log every change.
Hierarchical inheritance (Unity Catalog) is convenient but grants on a schema silently cover future tables. Avoid broad SELECT on catalogs that receive new data from many teams.
Small organisations can usually rely on one platform's native model with a handful of tags. Large or multi-cloud estates need a single classification vocabulary mapped into each platform's tags and a central report of effective access. See the Data Access Governance Guide.

Securing the catalogue itself

The catalogue holds the most useful reconnaissance an attacker could want: an index of sensitive data, lineage that shows where it flows, and often the credentials scanners use to reach every source. Treat it as tier-zero data infrastructure.

Privileged roles: catalogue administrators, tag creators, Governance Domain Owners and holders of MANAGE can change who sees data. Put them behind phishing-resistant MFA and just-in-time elevation, and keep them separate from day-to-day analyst accounts.
Scanner and connector credentials: scanning a source needs read access to its metadata and often its data. Use managed identities or vaulted, scoped credentials per source, never a shared administrator account. See the Service Account Security Guide.
Metadata visibility: decide whether everyone may discover that a dataset exists. Databricks recommends granting BROWSE on catalogs to all account users so people can find data and request access without reading it; that is reasonable for most data, but restricted projects (M&A, investigations) may need hidden metadata as well.
Glossary and lineage integrity: a steward who can rewrite a column's classification can effectively grant access. Require approval for downgrades from restricted classifications.
Audit logs: enable the catalogue's audit trail and send it to the SIEM. Databricks exposes Unity Catalog events in the system.access.audit system table, with fields such as service_name, action_name and identity_metadata; Lake Formation and Glue activity appears in AWS CloudTrail. See the Cloud Logging and Audit Trail Guide.

Where identity fits: workloads, BI tools and AI pipelines

The broadest standing access in most data platforms belongs to non-human identities: ETL and orchestration jobs, BI tool service accounts, reverse-ETL connectors, catalogue scanners and, increasingly, retrieval pipelines that feed AI assistants. They are often granted catalog-wide or warehouse-wide read because tag design came later.

Inventory workload principals alongside datasets: the catalogue should show not only who owns a table but which service principals can read it and why.
Scope by tag, not by catalog: a reporting service account should hold SELECT on classification=internal data for its domain, not on everything.
Require MFA and network policies for human access to warehouses: the Snowflake breach showed what happens when infostealer-captured credentials work against accounts without MFA; data from organisations including Ticketmaster and Santander was taken. See the Snowflake Security Guide.
AI data governance: embeddings, vector stores and fine-tuning sets copied from governed tables lose their tags. Record lineage from source to AI store, carry classification forward and exclude restricted columns at extraction. See the AI Governance Guide.

SaaS and cloud data governance

Catalogues usually cover the warehouse and lake well and SaaS poorly. Customer records in a CRM, files in collaboration suites and data exported by OAuth-connected apps sit outside the tag model.

Federate where you can: Lake Formation supports tag-based control for federated catalogs, including sources such as Amazon Redshift, DynamoDB, SQL Server and Snowflake; Purview Data Map scans multicloud sources. Use federation to bring metadata in, even if enforcement stays in the source.
Govern exports: track scheduled exports and connectors from SaaS apps into the lake, because each one copies data out of its original controls. See the SaaS and OAuth App Governance Guide.
Residency as metadata: record processing location (NIST PF ID.IM-P7 asks that the processing environment is identified) so residency rules can be checked automatically. See the Data Sovereignty and Residency Guide.

Implementation roadmap

Agree decision rights (weeks 1 to 4): publish the owner, steward and custodian roles, a short classification scheme and the approval rule for access to restricted data. Name owners for the 20 to 50 most important datasets first.
Discover and baseline (weeks 3 to 8): run scanners on the main warehouse and lake, list sensitive columns, and export the current effective access for people and service principals. This baseline is your rollback reference.
Design tags (weeks 6 to 10): define tag keys and values (classification, data domain, regulated type), who may create them and who may assign them. Test in a non-production catalog with synthetic data.
Pilot one domain (weeks 8 to 14): apply tags and tag-based grants to one data domain, run them alongside existing named grants, and compare access results. Only when they match, revoke the named grants, as AWS recommends for LF-TBAC.
Bring in workloads (weeks 12 to 20): move service principals and BI accounts to tag-scoped grants, rotate scanner credentials into a vault or managed identity, and enable masking for restricted columns.
Monitor and review (ongoing): stream catalogue audit logs to the SIEM, run quarterly owner-certified access reviews, and report drift metrics to the data governance board.

Rollback: keep named grants in place during the pilot so revoking a tag grant restores the previous state; script grant changes as code so any change can be reverted from version control.

Detection and measurement

Monitor the catalogue as both a control plane and a data access path.

What to log: grant and revoke events, tag creation and assignment, classification downgrades, ownership transfers, new external locations or connections, scanner credential changes, and large or unusual reads of restricted tables.
What to alert on: a restricted tag removed from a column, a principal granted MANAGE or ALL PRIVILEGES at catalog level, a service principal reading restricted data outside its schedule, and bulk exports to new destinations (MITRE ATT&CK T1530 Data from Cloud Storage and T1213 Data from Information Repositories describe the collection behaviour to look for).

Metric	What it shows	Target direction
Share of critical datasets with a named, current owner	Decision rights are real	Towards 100%; owners who have left flagged within 30 days
Sensitive columns found by scanning but untagged	Classification coverage gap	Falling each quarter
Grants made outside the tag model	Governance drift	Near zero after migration
Service principals with catalog-wide read	Over-privileged workloads	Falling; each exception has an owner and expiry
Access review completion and revocation rate	Reviews change access, not just certify it	Completed on time with non-zero revocations
Median time to approve a data access request	Governance is usable, so people do not copy data around it	Days, not weeks

Common failure patterns

Catalogue as shelfware: a catalogue populated once by a scanner, with no owners and no enforcement, gives a false sense of control. Tie at least one access decision to it from the start.
Two access models at once: tag-based grants added on top of old named grants leave the old access in place. Migrate, compare and revoke.
Tag editors with no oversight: anyone who can change a classification tag can grant access. Restrict and log tag assignment, and alert on downgrades.
Warehouse accounts without MFA: stolen passwords against data platforms remain the simplest route to bulk data, as the Snowflake breach showed.
Copies that lose governance: extracts to spreadsheets, SaaS exports and AI vector stores carry the data but not the tags, owners or retention rules.
Scanner accounts with god mode: one shared high-privilege credential used to scan every source becomes the most valuable secret in the estate.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	NIST Privacy Framework
Data inventory and metadata	ID.AM-07, ID.AM-08	CM-8, PM-5	5.9 Inventory of information and other associated assets	ID.IM-P
Classification and labelling	ID.AM-07	RA-2	5.12 Classification of information, 5.13 Labelling of information	ID.IM-P6
Roles and ownership	GV.RR-02	PM-23 Data Governance Body	5.2 Information security roles and responsibilities	GV.PO-P
Catalogue-enforced access	PR.DS-01	AC-3, AC-6	5.15 Access control, 8.3 Information access restriction	PR.AC-P, CT.DM-P
Masking and de-identification	PR.DS-01	AC-3	8.11 Data masking	CT.DP-P2
Retention and purpose	ID.AM-08	SI-12, PT-3	5.34 Privacy and protection of PII	CT.DM-P5, ID.IM-P5
Catalogue audit logging	PR.PS-04	AU-2, AU-12	8.15 Logging	CT.DM-P8

In CIS Controls v8.1, Control 3 (Data Protection) covers this ground, in particular the data management process, data inventory, access control lists, classification scheme, data flow documentation and logging of sensitive data access.

Practitioner checklist

Name an owner and steward for every critical dataset and alert when an owner leaves.
Publish a classification scheme of three to five levels with regulated data-type tags.
Scan the main warehouse and lake and tag sensitive data at column level.
Restrict who can create and assign classification tags, and alert on downgrades.
Migrate to tag-based or attribute-based grants, then revoke the old named grants.
Protect catalogue admin roles with phishing-resistant MFA and just-in-time elevation.
Give scanners scoped, vaulted or managed credentials per source.
Scope service principals and BI accounts by tag and review them quarterly.
Send catalogue and data platform audit logs to the SIEM with alerts for grant and tag changes.
Track lineage into SaaS exports and AI data stores and carry classification forward.

Data Governance and Data Catalogue Security Guide: Ownership, Classification and Access