Unity Catalog governance: a practical playbook

Getting onto Unity Catalog is a project with a start and an end date. Governing it is not. Once the migration is done, or once you’ve enabled UC on a fresh workspace, you’re left running a permission system, an audit trail, and a naming convention indefinitely — and most teams under-invest here because there’s no ticket that says “do governance.” Here’s what actually running it well looks like.

Naming and ownership: decide once, enforce forever

Unity Catalog’s three-level namespace (catalog.schema.table) is only useful if the levels mean something consistent. The pattern that holds up in practice is catalog per environment or business domain (prod, staging, or finance, marketing if domains are cleanly separated), schema per team or data product, and table names that describe content, not lineage stage — leave bronze/silver/gold to tags or a schema prefix, not the table name itself.

The part teams skip is ownership. Every catalog and schema in Unity Catalog has an OWNER, and by default it’s whoever ran the CREATE statement — usually a service principal from a Terraform apply or a one-off notebook run. That’s not an owner, that’s an accident. Set ownership explicitly to a group, not an individual: ALTER SCHEMA finance.claims OWNER TO finance_data_team. Individuals leave; groups don’t. If you can’t name the group that owns a schema in under five seconds, you don’t have an owner of record — you have whoever answers Slack first when something breaks.

GRANT design: start from deny, not from convenience

Unity Catalog’s privilege model is genuinely fine-grained — SELECT, MODIFY, CREATE, catalog-level USE CATALOG/USE SCHEMA — but fine-grained only helps if you use the granularity. The common failure is granting at the catalog level because it’s one statement instead of twenty, which quietly hands every table in prod to whoever needed one table in it.

Grant at the schema level as the default unit, and drop to table-level or row/column-level only when a schema genuinely mixes sensitivity levels. Two features do the real work here:

• Row filters restrict which rows a query returns based on the caller’s identity or group membership — the standard use is a region or tenant_id column filtered against is_account_group_member(), so the same view serves every region team without a table per region.
• Column masks redact or hash specific columns for callers outside a group — SSN, email, name fields — while leaving the rest of the row queryable. This is what turns “the analytics team needs this table but not the PII in it” from a table-duplication problem into a one-function policy.

Both are defined as SQL functions attached to the table with ALTER TABLE ... SET ROW FILTER / ... SET MASK, which means they’re versioned and reviewable like any other schema change — put them in the same migration files as your DDL, not in a wiki page someone will forget to update.

Lineage and audit logs: don’t wait for the audit to look

Unity Catalog captures table- and column-level lineage automatically for anything that runs through it, and every access is logged to the account’s audit log system tables. The mistake is treating both as something you’ll query when an auditor asks. By then you’re reconstructing history under time pressure instead of demonstrating a running control.

For GDPR-adjacent obligations, column-level lineage answers “where did this personal data end up” directly — trace a masked email column forward through every downstream table and you have your data flow map without interviewing five teams. For SOC 2-adjacent access reviews, the audit log system tables (system.access.audit) let you answer “who queried this table in the last quarter” with a query instead of a guess. The useful habit is a scheduled job that snapshots access patterns weekly — not to act on immediately, but so that when someone does ask, you have twelve months of history instead of whatever the retention window happens to cover.

Tagging: useful only if it’s governed too

Unity Catalog lets you attach tags to catalogs, schemas, tables, and columns, and it’s tempting to use tags for everything — cost center, PII flag, data product, sensitivity tier, project name. The result after a year is fifteen tags per table, half of them stale, none of them queried by anything. Tag sprawl is a governance failure with the same shape as permission sprawl: it looks like diligence and functions as noise.

Keep tags to a short fixed vocabulary tied to something that consumes them. pii: true/false is worth having because it can drive column masks and access reviews. sensitivity: public/internal/restricted is worth having if it maps to an actual grant policy. A free-text notes tag or a team tag that duplicates schema ownership isn’t. If a tag doesn’t feed a policy, a dashboard, or a query someone actually runs, it’s decoration — and decoration decays into misinformation, because nobody updates a tag nobody looks at.

The failure modes that show up in every review

A few patterns recur often enough to call out specifically:

• Over-permissioned service principals. The service principal that runs your nightly job gets MODIFY on a whole catalog because it was easier to set up once, and it stays that way for years because nothing forces a review. Scope service principals to exactly the schemas their job touches, and treat a service principal with catalog-wide write access as an incident, not a convenience.
• No owner of record. Covered above, but it’s worth repeating: this is the single most common thing we find in governance reviews, and it’s also the cheapest to fix. An ALTER SCHEMA ... OWNER TO statement takes thirty seconds; finding out nobody owns a schema after a breach takes a lot longer.
• Tag sprawl and grant sprawl as parallel problems. Both come from the same root cause — permissions and metadata added under deadline pressure and never revisited. Neither gets cleaned up by itself. Put a recurring quarterly review on the calendar for both, or accept that the estate only grows more permissive over time.

Governance that only exists at migration time isn’t governance, it’s a one-time cleanup that starts decaying the day after. Zephico is a Databricks Consulting Partner, and our Databricks-certified engineers run these reviews as ongoing engagements, not one-off audits — because the failure modes above only show up months after the migration, not during it. If your Unity Catalog setup hasn’t had a permissions review since it went live, talk to us about what one would find.