How is this different from just buying a data catalog?

Catalogs are useful for discovery and documentation, but they don’t enforce behavior. This approach treats governance as code—contracts at ingestion, tests in CI, access via Terraform, and lineage instrumentation—so the system itself prevents violations and produces audit evidence automatically.

Where should we start if we have nothing?

Start at the edges: enforce data contracts on ingestion and add dbt tests to Tier-1 models. In parallel, classify PII columns and apply a single masking policy. That alone reduces breakage and risk, and it doesn’t require boiling the ocean.

What if we’re primarily on Databricks or Snowflake?

Same patterns. On Databricks, use Delta Lake with table properties for classification, Unity Catalog for permissions, and OpenLineage Spark listener. On Snowflake, use masking and row access policies with Terraform-managed roles. dbt and Great Expectations work across both.

How do we measure success?

Track DQ incident rate, SLO attainment (freshness/completeness/accuracy), MTTR, access-request cycle time, and audit prep time. If those trend in the right direction within 90 days, your governance is working.

What about notebooks and ad-hoc data pulls?

Treat them as products. Run notebooks against governed compute (e.g., Databricks with Unity Catalog or Snowflake with roles), restrict access via roles, and require checked-in artifacts for anything promoted beyond exploratory work.

Data-engineering · Nov 1, 2025 · 10 minute read

The Data Governance Playbook That Survived an Audit and Shipped Features

Governance that engineers don’t hate: policy-as-code, quality SLOs, and locked-down PII that still lets marketing run campaigns.

Back to all posts

The Data Governance Playbook That Survived an Audit and Shipped Features

Key takeaways

Implementation checklist