Data Governance Policy: What to Include (Template)

A data governance policy is the short, approved document that states how your organization treats its data: who owns it, how it is classified, what quality is required, who may access and share it, how long it is kept, and what happens when someone needs an exception. It should fit on three or four pages, be signed by an executive, and be readable by a new hire in ten minutes. This guide walks through every section of a data governance policy template with sample wording you can copy and adapt, whether you are a 20-person company writing its first policy or a 2,000-person organization replacing one nobody reads.

Policy vs standard vs procedure

Most policies fail because they try to be all three documents at once. Keep them separate and each stays short enough to use.

Document	What it says	Changes	Example
Policy	The rules and who is accountable for them. Written in “must” and “will” statements. Approved by an executive.	Rarely; reviewed annually	“All data must be assigned a classification level by its data owner.”
Standard	The specific requirements that satisfy the policy: levels, thresholds, formats, schedules.	As systems and regulations change; approved by the council	“Classification levels are Public, Internal, Confidential and Restricted, defined as follows.”
Procedure	Step-by-step instructions for a task, for a named role.	Often; owned by the steward or custodian	“To request access to Restricted data, submit ticket type X; the data owner approves within the ticket.”

The template below is the policy only. Classification levels, retention periods and quality thresholds are referenced from the policy and live in standards, so the policy does not need re-approval every time a retention period changes. Our guide to data classification and data retention policy covers those two standards. The policy sits inside the wider data governance framework, which also covers processes, tools and metrics.

The data governance policy template, section by section

Each section below has a short explanation and sample wording in a quote block. Replace the bracketed text, and keep the numbering so references from other documents still work.

1. Purpose

One paragraph on why the policy exists, tied to business outcomes.

This policy establishes how [Organization] governs its data so that reporting is trustworthy, legal and contractual obligations are met, customer and employee information is protected, and data can be used safely for analytics and artificial intelligence. It applies to all data created, collected, stored or processed by or on behalf of [Organization].

2. Scope

State what the policy covers and what it does not cover yet. Scope is what keeps version one achievable.

This policy applies to all employees, contractors and third parties who handle [Organization] data, and to all systems in which that data is held, including [ERP], [CRM], [data warehouse], [document management] and approved cloud services. Data domains in scope for this version are [customer, product, finance, employee]. Additional domains will be added by decision of the Data Governance Council and recorded in Appendix A.

3. Definitions

Define the handful of terms the policy relies on; point to the business glossary rather than reproducing it.

Data owner: the business leader accountable for a data domain, including its definitions, quality and access decisions. Data steward: the person who maintains definitions and quality for a domain on the owner’s behalf. Data custodian: the technical role responsible for the systems that store and process data. Critical data element: a data field designated by a data owner as essential to reporting, compliance or operations. Business glossary: the approved list of business terms and their definitions, maintained at [location].

4. Roles and responsibilities

Name the roles, not the people; the people go in an appendix so the policy does not change with every reorganization.

The Executive Sponsor ([role]) approves this policy, funds the data governance program and resolves escalated disputes. The Data Governance Council, chaired by [role] and composed of the data owners, approves standards, cross-domain definitions and exceptions, and meets [monthly]. Each Data Owner is accountable for the definitions, classification, quality thresholds and access decisions for their domain, and designates at least one Data Steward. Data Custodians in IT implement the technical controls that enforce this policy. All staff are responsible for handling data in accordance with its classification and for reporting suspected data issues to the relevant steward.

For a fuller description of each role and the RACI that goes with it, see our guide to data governance roles and responsibilities.

5. Data classification

The policy requires classification and names the levels; the criteria and handling rules per level belong in the classification standard.

All data in scope must be assigned one of the following classification levels by its data owner: Public, Internal, Confidential or Restricted. Data that has not been classified is treated as Confidential until classified. Classification criteria, labeling requirements and handling rules for each level are set out in the Data Classification Standard. Personal information, protected health information, payment card data and information subject to contractual confidentiality are classified Restricted unless the data owner documents a reason otherwise.

6. Data quality

The policy sets the expectation that quality is defined, measured and acted on; the rules and thresholds live in the quality standard or the catalog.

Each data owner must identify the critical data elements in their domain and approve data quality rules for them covering, at minimum, completeness, validity, uniqueness, timeliness and consistency. Quality against these rules is measured [monthly] and reported to the Data Governance Council. Data issues are recorded in the data issue log, assigned to the owner of the system of record, and corrected at the source. Reports built for executive or external use must use data from the designated system of record.

7. Access and use

Tie access to classification and least privilege; keep the approval path in a procedure.

Access to data is granted on the basis of job need and the minimum necessary to perform it. Access to Confidential data requires manager approval; access to Restricted data requires the approval of the data owner and is reviewed at least [quarterly]. Data may be used only for the purposes for which it was collected or for purposes approved by the data owner. Sharing data with third parties requires a written agreement covering confidentiality, security and, where applicable, privacy. Use of data to train or operate artificial intelligence systems requires the approval of the data owner and compliance with the AI acceptable use policy.

8. Retention and disposal

The policy commits to a retention schedule and disposal; the schedule itself is a standard.

Data is retained for the period specified in the Data Retention Schedule, which reflects legal, regulatory, contractual and operational requirements, and no longer. When the retention period ends, data is securely deleted or anonymized, and the disposal is recorded. Data subject to a legal hold is excluded from disposal until the hold is lifted. Data owners review the retention periods for their domain [annually].

9. Privacy and security

Do not duplicate the security or privacy policies; reference them and state how the three relate.

This policy operates alongside the Information Security Policy and the Privacy Policy. Where this policy sets a classification or retention requirement, the Information Security Policy defines the technical controls that enforce it. Personal information is handled in accordance with the Privacy Policy and applicable privacy law. Where requirements conflict, the stricter requirement applies, and the conflict is reported to the Data Governance Council.

10. Exceptions

Every policy needs an exception path, or people route around it. Make exceptions time-limited and recorded.

A deviation from this policy requires a written exception request stating the business reason, the data affected, the compensating controls and the duration. Exceptions are approved by the data owner for their domain, or by the Data Governance Council where more than one domain is affected, and expire after no more than [twelve months] unless renewed. All exceptions are recorded in the exception register and reviewed by the Council [quarterly].

11. Compliance and enforcement

Say how compliance is checked and what happens on breach, in neutral language agreed with HR and legal.

Compliance with this policy is monitored through data quality reporting, access reviews and periodic audits. Suspected breaches of this policy must be reported to [role]. Breaches are handled in accordance with [Organization]’s disciplinary and contractual procedures.

12. Review and maintenance

Give the policy an owner, a review cycle and version history.

This policy is owned by [role] and reviewed at least annually, or sooner when a material change in systems, regulation or organizational structure occurs. Changes are approved by the Executive Sponsor on the recommendation of the Data Governance Council. Version history is maintained in Appendix B.

Approval block and appendices

Approved by: [name, role, date]. Policy owner: [role]. Version: [x.x]. Next review: [month, year].
Appendix A: Data domains in scope and their owners. Appendix B: Version history. Appendix C: Related standards and procedures (Data Classification Standard, Data Retention Schedule, Data Quality Standard, Access Request Procedure, Exception Procedure).

How long a data governance policy should be

Three to four pages, excluding appendices. The test is whether a new manager can read it in ten minutes and tell you who owns customer data, what Restricted means, and how to get an exception.

A 20-person company can often fit it on two pages by merging sections 9 and 11 and keeping the definitions to four terms. A 2,000-person company should resist the pull toward twenty pages; everything that wants to grow (classification criteria, retention periods, system lists, approval matrices) belongs in a standard or procedure that can change without executive re-approval. If your draft contains a table of retention periods, you have written a standard into the policy.

Getting the policy approved and used

Approval is the easy part; adoption is the work. These steps make the difference in organizations of any size.

1. Draft with the owners, not for them. Share the template with the people who will be named as data owners and ask them to mark anything they could not commit to. A policy they edited is a policy they will enforce.
2. Agree the standards at the same time. A policy that references a Data Classification Standard that does not exist is unenforceable. Draft a one-page version of each referenced standard before approval.
3. Get legal and HR to read sections 7, 8 and 11. Access, retention and enforcement wording has employment and regulatory consequences. This is general information, not legal advice; check the current official text of any regulation that applies to you.
4. Approve at the right level. The executive sponsor signs, the council recommends, and the board is informed if there is one. Do not route a four-page policy through a twelve-person committee.
5. Publish where people already look. The intranet, the employee handbook, the onboarding checklist, the BI tool and the catalog.
6. Train by role, briefly. Owners and stewards get an hour on their responsibilities; everyone else gets ten minutes in onboarding on classification and whom to ask.
7. Put it in the workflow. Add classification to the new-dataset request form, owner approval to the access ticket, and the glossary link to report footers. Rules inside tools get followed.
8. Review it on the calendar. Put the annual review date in the council’s standing agenda the day the policy is approved.

A short data governance checklist for the first review: every in-scope domain has a named owner; every referenced standard exists; the exception register has entries (an empty register usually means people are routing around the policy); access reviews happened on schedule; the quality report reached the council each month.

Where PS3G fits

PS3G provides data governance consulting and implementation for organizations of every size. Writing the policy and its supporting standards is usually the second deliverable in our 90-day start, after the assessment and before the quality rules and catalog work. We draft from templates like the one above, run the owner workshops, align the wording with your security and privacy policies, and set up the exception register, issue log and review calendar that turn the document into a practice. We build and run our own regulated software products, so our policies are written by people who also live under them.

Related reading

• Data Governance Framework: Components, Examples and a Starter Template
• Data Governance Roles and Responsibilities: Owners, Stewards, Councils
• Data Classification and Data Retention Policy: Templates and Examples
• Data governance consulting and implementation services

Frequently asked questions

What should a data governance policy include?

A data governance policy should include a purpose, a scope that names the domains and systems covered, definitions of the key roles, the roles and their responsibilities, the requirement to classify data and the levels used, data quality expectations, access and use rules tied to classification, retention and disposal commitments, references to the security and privacy policies, an exception process, enforcement, and a review cycle with an approval block.

Who should approve a data governance policy?

An executive sponsor with authority over the functions that create and use the data, typically the COO, CFO or CIO, signs the policy. The data governance council of data owners recommends it, and legal and HR review the access, retention and enforcement sections. In a small company the founder or managing partner approves it. Boards are usually informed rather than asked to approve.

Is a data governance policy the same as a data retention policy?

No. The data governance policy is the umbrella document that commits the organization to classify data, manage quality, control access and retain data for defined periods. The data retention policy, or retention schedule, is a supporting standard that lists the periods for each type of record. Keeping them separate lets retention periods change without re-approving the whole governance policy.

How often should the policy be reviewed?

At least once a year, and sooner after a material change such as a new core system, a reorganization that changes data owners, a new regulation or contract requirement, or an incident that exposed a gap. Put the review date in the council’s standing agenda when the policy is approved, and record each version in the appendix so auditors can see the history.