Data Governance Policy: What It Must Actually Decide

A data governance policy should settle recurring decisions about data. It should not merely say that data is valuable, secure or everyone’s responsibility.

A useful policy names who can decide, what minimum controls apply, how exceptions are approved and what evidence proves the policy is operating. If those points are absent, the document may satisfy a policy register while leaving delivery teams to negotiate the same issues project by project.

This is also why a privacy policy and a data governance policy are not interchangeable. Privacy obligations are a critical input where personal information is involved. Governance also covers business definitions, quality, ownership, access, change, retention and use across the wider data estate.

Start with scope and authority

The first page should answer four questions:

1. Which data is covered, including operational systems, SaaS platforms, spreadsheets, analytics platforms and data used by applications or AI agents?
2. Which people and third parties are covered?
3. Which executive or governance body owns the policy?
4. Which laws, contracts, security standards and records obligations take precedence?

Avoid limiting scope to the central data platform. Important business data still exists in finance, CRM, HR, industry systems and local files. A policy that governs only the warehouse governs a copy, not the full lifecycle.

For Australian organisations subject to the Privacy Act, the OAIC’s APP 1 guidance is a useful test of substance. It says APP entities must take reasonable steps to implement practices, procedures and systems for compliance, not just publish a privacy statement. The exact legal obligations depend on the organisation and the data, so obtain legal advice where required.

The nine decisions the policy must make

1. Who owns a data domain

Assign an accountable business owner for each material domain, such as customer, workforce, supplier, product or finance. Ownership belongs with someone able to make business decisions about meaning, acceptable use, quality priorities and risk. It should not default to the engineer who stores the data.

The policy should state that an owner:

• approves critical definitions and intended uses;
• accepts or escalates material quality risk;
• approves access rules with security and privacy input;
• assigns operational stewardship; and
• reports unresolved issues to the named governance body.

One accountable owner does not mean one person performs every task. It means there is a clear final decision point.

2. How critical data and data products are identified

Not every field needs the same control. Define how the organisation designates critical data elements and data products. Criteria may include regulatory importance, financial reporting impact, operational dependency, sensitivity, use in automated decisions and the consequence of error.

The designation should trigger stronger requirements for documentation, quality monitoring, lineage, access review and change approval. Without a risk-based threshold, governance teams either try to govern everything or apply little control to anything.

3. Who approves definitions

The policy should establish a business glossary and a decision route for disputed terms. For each critical measure or term, record:

• the approved definition and calculation;
• accountable owner and steward;
• systems and reports where it applies;
• effective date and approved changes; and
• known exceptions or local variants.

A glossary does not remove legitimate differences. “Revenue” may have statutory, management and sales meanings. The control is to name those meanings clearly, identify where each applies and stop them being presented as the same measure.

4. What acceptable data use means

State permitted and prohibited uses, especially for personal, commercially sensitive and licensed third-party data. Cover analytics, exports, model training, prompts, automated decisions and access by applications or AI agents.

A practical rule requires a stated purpose, approved data source, lawful and contractual basis where applicable, minimum necessary access, named owner and review date. High-risk uses should require privacy, security, legal or risk review before release.

From 10 December 2026, APP entities have additional privacy-policy obligations in specified circumstances involving computer programs that use personal information for decisions that could significantly affect a person’s rights or interests. The OAIC’s APP 1 guidance explains the change. Treat this as a prompt to review automated-decision inventories and disclosure, not as a substitute for advice on applicability.

5. How access is granted and removed

The policy should require role-based, least-privilege access through managed identities and groups where practical. Define:

• who requests and approves access;
• segregation requirements for sensitive data;
• time limits for privileged or exceptional access;
• review frequency based on risk;
• leaver and role-change handling; and
• logging and investigation requirements.

Do not confuse catalog permissions with access to source data. Microsoft states that Purview Data Map and Unified Catalog contain metadata, not the underlying data, and their roles do not themselves grant underlying data access. The policy must connect discovery and approval workflows to the controls in source platforms, Microsoft Entra ID and other enforcement systems.

6. What data quality is acceptable

“Data must be accurate” is not an operable rule. Require critical data to have quality rules tied to its intended use. Each rule needs a measure, threshold, owner, monitoring method and response when the threshold is missed.

Relevant dimensions can include completeness, uniqueness, consistency, timeliness, validity and accuracy. The UK Government Data Quality Framework is a useful public reference for thinking about quality across the lifecycle. The organisation still needs to choose thresholds based on consequence, not copy generic targets.

7. How changes are controlled

Changes to source fields, definitions, transformations, classifications and interfaces can break reports and downstream processes. Require impact assessment, testing, approval and communication for material changes.

Lineage can help identify affected assets, but it does not make the decision. The accountable owner must decide whether the business impact is acceptable, while technical owners manage release and rollback.

8. How long data is kept

Define how retention and disposal schedules are set, approved and applied across source systems, analytics copies, backups and exports. Legal, regulatory and contractual requirements should be mapped to data classes with records or legal advice where necessary.

The OAIC’s APP 11 guidance covers reasonable steps to protect personal information and, in relevant circumstances, destroy or de-identify it when no longer needed. A policy should turn applicable obligations into system-level schedules and evidence, rather than relying on users to remember.

9. How exceptions and breaches are handled

Every policy needs an exception path. Require a business justification, risk assessment, compensating controls, accountable approver and expiry date. Permanent exceptions are usually undocumented alternative policy.

Also define how suspected breaches are reported, triaged and investigated, including links to security, privacy, records and incident processes. The governance body should review overdue exceptions and repeated breaches for systemic causes.

Put the policy into an operating register

A concise policy can point to controlled standards and registers rather than contain every technical setting. At minimum, maintain:

A tool can hold some of these records. Tool choice should follow the operating requirement, not define it. Set the required decisions and evidence before turning policy gaps into a software procurement exercise.

Use a review cadence that produces decisions

A workable cadence for a mid-market organisation is risk based:

• owners and stewards monitor critical quality and access exceptions as part of operations;
• a monthly governance forum decides unresolved definitions, quality remediation and expiring exceptions;
• a quarterly executive review considers material risk, cross-domain disputes and investment;
• the policy owner reviews the document at least annually and after significant regulatory, platform or operating change.

These frequencies are an operating recommendation, not a universal standard. Increase them where data changes quickly or consequences are higher. Reduce meetings where controls operate reliably and no decision is required.

Test whether the policy is real

Choose one important data product and ask for five pieces of evidence: its owner, approved definition, current access list, latest quality result and applicable retention rule. Then ask who can approve an exception.

If the answers require several days of investigation, the problem is not better policy wording. It is missing implementation.

If the organisation needs to move from those gaps to a sequenced operating plan, or resolve ownership, architecture and the first implementation scope, a Data Discovery & AI Readiness Roadmap can establish the decisions before technology is expanded.

Book a 30-minute fit call to determine whether the next step should be a roadmap or a defined governance implementation sprint.