A Data Governance Policy Template for a Lakehouse

Key Takeaways

A data governance policy template is a set of short, numbered clauses that say who owns data, how it is classified, who may read it, how quality and retention are handled, and how exceptions are approved. On a lakehouse, every clause should name the control that enforces it and the record that proves it ran.

• Length: nine sections and about two pages; anything longer stops being read.
• Effort: a mid-market team can fill the placeholders in a week and enforce most clauses with platform features it already pays for.
• Risk: a clause with no control behind it is the one an auditor or customer will test first.
• Fit: it works best once your governed data sits in one catalog rather than in exports and shared drives.

Most data governance policies I review were written for an audit and never touched again. They say “data shall be protected appropriately” and name no owner, no classification level and no system that does the protecting. The policy and the platform live in two different worlds.

A lakehouse closes that gap, because the controls a policy describes now exist as settings you can query. Unity Catalog captures lineage automatically, down to the column level, for queries run on Databricks. Governed tags, automated data classification and attribute-based access policies reached general availability on 13 May 2026. That means a clause can point at a policy object, not a promise.

The trouble is that templates found online are either a 30-page enterprise binder or a one-page statement of values. Neither tells a 400-person company what to write in section four. The template below is the asset: copy it, replace the bracketed placeholders, and map each clause to the control in the table that follows it.

What Should a Data Governance Policy Cover on a Lakehouse?

Nine sections cover what a buyer questionnaire, an internal auditor and your own engineers will ask. Each section has three parts: the clause your executives approve, the control your platform team configures, and the evidence a reviewer can pull without asking anyone. If you want the program design behind the policy (roles, operating cadence, how to sequence the build), our data governance consulting guide covers it. This article is only the policy text.

Write the clauses in plain sentences with “must” where you mean an enforced rule and “should” where you mean guidance. Keep the numbering stable so that a ticket, an exception or an audit finding can cite “clause 4.3” for years.

What Does the Template Say, Section by Section?

Copy the clauses as written. Replace anything in square brackets with your own value. Delete a clause rather than leave it vague.

Section 1: Purpose and scope

1. This policy governs all data that [Company] stores, processes or shares in the [Company] lakehouse and in any system that feeds it.
2. It applies to employees, contractors, service principals and AI agents that read or write that data.
3. Data held outside the governed catalog is out of policy and must be migrated or registered by [date].
4. The policy owner is the [Chief Data Officer / Head of Data]. It is reviewed every [12] months and after any material incident.

Section 2: Roles and accountability

1. Every catalog, schema and table must have an owner, and that owner must be a group, not an individual.
2. Each data domain has a named business owner who approves access and classification for that domain.
3. The data platform lead maintains the controls in this policy. The security lead reviews them every [quarter].
4. A data governance council of [names or roles] meets [monthly] to decide exceptions and policy changes.

Section 3: Data classification

1. All data must carry one classification: Public, Internal, Confidential or Restricted.
2. Columns holding personal data, payment data or [regulated category] must carry a governed tag naming that category.
3. Only members of [data-stewards group] may assign or change classification tags.
4. New tables must be classified before they are granted to any group outside the owning team.

Section 4: Access control

1. Access is granted to groups, never to individual users or personal tokens.
2. Access follows least privilege: read access by default, write access only to the owning pipeline’s service principal.
3. Restricted columns must be masked, and restricted rows filtered, by tag-driven policy for every principal outside the approved group.
4. Service principals used by jobs or AI agents must be inventoried with an owner and reviewed on the same cycle as human access.
5. Access is reviewed every [quarter] by the business owner of each domain.

Section 5: Data quality

1. Every gold table must have documented quality rules for completeness, validity and freshness.
2. Pipelines must enforce those rules at load time and record rows that fail them.
3. A gold table that breaches its freshness rule must be flagged to its consumers within [4 hours].
4. Quality results are reported to the council every [month].

Section 6: Lineage and change management

1. Production transformations must run on the governed platform so that lineage is captured automatically.
2. Changes to a gold table’s schema require impact analysis against its downstream consumers before release.
3. Production code is deployed from version control through a reviewed release process.

Section 7: Retention and deletion

1. Each table carries a retention period set by its business owner and confirmed by counsel.
2. Records needed to demonstrate legal or contractual compliance are kept for [period].
3. Data past its retention period is deleted, and the deletion is logged.
4. Deletion requests from individuals are fulfilled within [period] across bronze, silver and gold layers.

Section 8: Audit and monitoring

1. Access, permission changes and policy changes on the lakehouse are logged.
2. Audit records are kept for at least [period] in a table the security team controls.
3. Reads of Restricted data by unexpected principals trigger an alert to the security lead.

Section 9: Exceptions and enforcement

1. Exceptions are requested in [ticketing system], approved by the business owner and the security lead, and expire after [90] days.
2. Every active exception is listed in a register the council reviews [monthly].
3. Breaches of this policy are handled under [HR or security incident procedure].

Which Unity Catalog Control Enforces Each Section?

This is the part most templates skip. A clause without a control is a wish. Here is how each section maps to a lakehouse mechanism on Databricks, and what a reviewer can see.

A few mechanics matter. Governed tags are account-level tags whose allowed values are defined by a tag policy, and only principals with the ASSIGN permission on a tag can apply it, which is how clause 3.3 becomes enforceable. Row filter and column mask policies attach to a catalog, schema or table and evaluate everything beneath it, so a newly tagged column inherits protection without a new grant. The audit log system table is in Public Preview with a 365-day default retention, so if clause 8.2 asks for more, copy the events into your own table on a schedule. Our audit log retention guide walks through that job.

For section 5, the rule set itself is the hard part. The data quality framework we published explains how to choose completeness, validity and freshness rules per gold table before you write them into a pipeline.

Where Do Data Governance Policies Break Down?

• Clauses name people, not groups. The owner leaves and the clause points at nobody. Name roles in the policy and groups in the catalog.
• Classification is optional in practice. If an untagged table can still be granted to analysts, clause 3.4 is decoration. Make classification a step in the release checklist and report untagged tables monthly.
• Service principals are left out. Jobs and AI agents read more data than most people do. A policy that reviews only human access misses the largest readers.
• Retention is written but never run. A retention period with no deletion job means you hold everything forever, which raises both storage cost and exposure.
• Exceptions never expire. A temporary grant from two years ago is a permanent grant. Put an expiry date on every exception and review the register.

How Do You Adapt the Template to Your Company?

Start with the process, not the platform. Map how a new data source arrives today, who asks for access and who says yes. The policy should describe a workflow you have already agreed on, not invent one. As a Lean Six Sigma practitioner I see the same defect in governance that I see in operations: automating an undefined process just produces defects faster.

Then fill the placeholders with values you can actually enforce this quarter. A 90-day exception expiry you enforce beats a 30-day one nobody checks. Have counsel set the retention periods, because they depend on the laws and contracts that apply to you. As one example, Colorado’s SB 26-189, effective 1 January 2027, requires developers and deployers of covered automated decision systems to keep records needed to demonstrate compliance for at least three years.

Finally, configure the controls in the table and run the evidence queries once before the policy is approved. If a query returns nothing, the clause is not ready. If you want a second set of hands wiring these controls into Unity Catalog, our Databricks consulting team builds exactly this layer. This template is general information, not legal advice; your counsel decides what your policy must say to meet the laws that apply to you.

Score Yourself: Is Your Policy Ready to Enforce?

Give yourself one point for each statement that is true today. Be strict: true means you can show the evidence, not that someone believes it.

• Every governed table has a group owner.
• Every column holding personal or payment data carries a governed tag.
• Only a named steward group can assign classification tags.
• Restricted columns are masked by policy, not by a view someone has to remember.
• Every service principal and AI agent identity has an owner and a review date.
• Every gold table has written quality rules enforced in its pipeline.
• You can show lineage from a source system to a production dashboard.
• A deletion job runs against at least one retention period.
• Audit records are retained for the period your policy states.
• Every open exception has an expiry date.

8 to 10: approve the policy now; the controls already exist. 5 to 7: approve it with dated actions for the gaps, owned by name. 0 to 4: do not publish the policy yet. Consolidate the data into one governed lakehouse first, because a policy over silos describes controls you cannot run.

Frequently Asked Questions (FAQs)

What should a data governance policy include?

At minimum: scope, roles and ownership, classification, access control, data quality, lineage and change management, retention and deletion, audit and monitoring, and exceptions. Each clause should name the control that enforces it.

How long should a data governance policy be?

About two pages of numbered clauses for a mid-market company. Procedures and technical standards can sit in separate documents that the policy references, so the policy itself stays readable.

Who should own the data governance policy?

A senior data leader, such as a chief data officer or head of data, owns the document. Business owners approve access and classification for their own domains, and the security lead reviews the controls.

Can Unity Catalog enforce a data governance policy on its own?

It enforces the technical clauses: ownership, tags, grants, row filters, column masks, lineage and audit logging. It cannot decide retention periods, approve exceptions or own accountability. Those stay with people named in the policy.