Data Governance That Engineers Don’t Hate: Policies, Ownership, and Automation

Say “data governance” in a room of engineers and watch the energy leave. The phrase evokes committees, forty-page policy documents, and approval workflows that turn a one-hour task into a three-week ticket. That reputation was earned — a generation of governance programs really did operate that way. But the underlying problem governance addresses is one every engineer has personally suffered: nobody knows what this data means, whether it’s right, who can fix it, or whether we’re allowed to use it.

This post reframes governance as an engineering discipline: five concrete questions every organization must answer, and the modern practice of answering them with code, automation, and ownership rather than committees and PDFs.

What Governance Actually Is: Five Questions

Strip away the enterprise vocabulary and data governance is the organizational capability to answer five questions about any dataset, quickly and reliably:

1. Who owns this? — accountability
2. What does it mean? — definitions and semantics
3. Can I trust it? — quality and freshness
4. Who may use it, for what? — access and ethics
5. Are we compliant holding it? — regulation and retention

Every governance framework, tool, and job title is machinery for answering these. If your program’s activities don’t trace back to one of the five, they’re theater.

Question 1: Ownership — the Keystone

Everything else fails without this one. An owned dataset has a named team (not a person — people leave) who answers for its meaning, quality, and access decisions. An unowned dataset is where incidents go to become archaeology.

What works in practice:

• Ownership declared in code, next to the asset — a meta: owner: field in the dbt model, a tag on the topic, an entry the catalog harvests — never in a spreadsheet that was accurate in March.
• Producing teams own by default. The team that generates the data understands it; assigning ownership to a central team recreates the bottleneck and the knowledge gap (the exact failure data mesh, covered earlier in this series, was invented to fix).
• Coverage as a metric. “94% of production datasets have a resolvable owner” is a governance KPI leadership can actually track.

Question 2: Definitions — Where the Dashboard Wars End

Most “data quality” escalations are actually definition disputes: two dashboards disagree on revenue because one nets refunds and one doesn’t — both pipelines are working perfectly. The fix is semantic, not technical: canonical definitions for the terms that matter, written down, owned, and — the modern move — encoded where tools consume them (a semantic layer for metrics, a glossary linked from the catalog for concepts; see the metadata management post in this series).

Prioritize ruthlessly: twenty well-governed definitions covering revenue, customer, active user, and churn beat a four-hundred-term glossary nobody maintains.

Question 3: Quality — Expectations as Executable Contracts

Governance’s answer to “can I trust it?” is not a promise — it’s published, automatically checked expectations:

# dbt: quality rules living with the model, run on every build
models:
  - name: fct_payments
    columns:
      - name: payment_id
        tests: [not_null, unique]
      - name: amount
        tests:
          - dbt_utils.accepted_range: {min_value: 0}
      - name: currency
        tests:
          - accepted_values: {values: ['USD','EUR','INR','GBP']}

The pattern generalizes (Great Expectations, Soda, warehouse-native constraints): rules live in version control, run in pipelines, and failures page the owner — closing the loop with question 1. Publish freshness and pass-rates on the asset’s catalog page and you’ve converted “trust me” into evidence. One discipline matters more than tool choice: a failing quality check must block or alert, every time. Checks that fail silently for weeks teach the organization that red is the normal color.

Question 4: Access — Least Privilege Without the Ticket Queue

The access question has a bad default at each extreme: lock everything down (analysts wait weeks; shadow copies proliferate — less control) or open everything (until the first leak). The workable middle:

• Classify data, not requests. Every column gets a sensitivity class at modeling time (public, internal, confidential, pii.*). Policies attach to classes: “non-privileged roles see pii.email masked.” New columns inherit governance by being classified — no meeting required.
• Role- and attribute-based grants, self-service for the safe tiers. Joining the marketing team grants the marketing role’s access automatically; only the sensitive tiers need human approval.
• Modern warehouse primitives do the enforcement: row-level security, dynamic masking, and tag-based policies in Snowflake/BigQuery/Databricks mean the policy is in the platform, not in a wiki begging to be followed.

-- Snowflake: policy attached to a classification tag, enforced everywhere the tag lands
CREATE MASKING POLICY mask_email AS (val STRING) RETURNS STRING ->
  CASE WHEN IS_ROLE_IN_SESSION('PII_READER') THEN val
       ELSE regexp_replace(val, '^[^@]+', '*****') END;
ALTER TAG pii_email SET MASKING POLICY mask_email;

Question 5: Compliance — Designed In, Not Bolted On

GDPR, CCPA, HIPAA, and their growing cousins all presuppose capabilities that are cheap at modeling time and brutal to retrofit: knowing where personal data lives (classification + lineage), erasing a person on request (identity resolution — hello, MDM), honoring purpose limitations (access policies), and deleting on schedule (retention rules per class). The through-line of this series applies one more time: compliance is mostly metadata, and metadata is cheapest at design time. Teams that tag PII in their schemas and contracts as they model can answer an auditor with a query; teams that don’t, answer with a consulting engagement.

The Operating Model: Federated, Automated, Thin

How to run this without recreating the committee monster:

• A thin central function sets the standards (classification scheme, definition process, retention rules) and owns the escalation path — it does not review every dataset.
• Domain teams execute ownership, definitions, and quality for their own data — governance as part of shipping, not a separate department’s afterthought.
• The platform enforces: CI rejects models without owners or with unclassified PII-pattern columns; tags trigger masking automatically; quality gates run in pipelines. Automation is what lets a three-person governance team cover a three-thousand-table estate.

This federated, policy-as-code shape is where the industry has converged — it’s the “computational” in data mesh’s federated computational governance, and the “active” in active metadata.

Starting From Zero: A 90-Day Version

1. Days 1–30: inventory via automated harvesting; declare owners for the top 50 assets by usage; adopt a four-tier classification scheme.
2. Days 31–60: encode the top ten metric definitions; add quality tests to the five most-consumed models; wire failures to owners.
3. Days 61–90: tag PII in the modeled core; attach one masking policy via tags; add the CI rule that new models require owner + classification. Publish a one-page scorecard: ownership coverage, test pass rate, definition count.

Notice what’s absent: a council, a manifesto, a tool procurement. Those can come later if scale demands them. Governance done well is mostly invisible — it’s the reason the analyst didn’t use the deprecated table, the reason the two dashboards agree, the reason the auditor left by lunch. The committees were never the point; the five answered questions were.