Now we move from foundation to operation. Having a governance framework on paper is very different from having one that actually shapes how people work. This post is about closing that gap.
The Policy Trap — Why Most Governance Programmes Stall Here
There is a predictable pattern in data governance programmes. An organisation spends months building a solid foundation — inventories, role definitions, principles. Then they sit down to write the policies. And that is where momentum dies.
Policies get drafted by committee. They grow long and vague. They use language no one outside a legal team would choose. They get approved, filed, and never opened again. Six months later, everyone knows the policies exist. Nobody can tell you what they actually say.
The reason this happens is almost always the same: the policies were written for compliance purposes, not for the people who need to follow them. Governance that isn't usable isn't governance — it's documentation.
This post will show you a different approach.
Step 1: Write Policies That People Will Actually Use
A data governance policy does not need to be long. It needs to be clear, specific, and actionable. The test for any policy you write is simple: can a new employee read this and understand exactly what they are and are not allowed to do?
The policies you actually need first
Resist the urge to write twelve policies at once. Start with the three that create the most risk if they don't exist:
Data classification policy. This defines how your organisation categorises data by sensitivity — typically four levels: Public, Internal, Confidential, and Restricted. Every other policy depends on this one, because the rules for handling data should vary by how sensitive it is. Under New Zealand's Privacy Act 2020, anything that qualifies as "personal information" should sit at Confidential or Restricted by default.
Data access and authorisation policy. This answers who can access what, under what conditions, and how access is granted, reviewed, and revoked. In the NZ context, this policy also operationalises your obligations under Privacy Principle 5 (storage security) and Principle 11 (disclosure of personal information). Access reviews — at least annually — should be explicitly required.
Data retention and disposal policy. This defines how long each category of data is kept and how it is securely disposed of when it is no longer needed. Privacy Principle 9 says personal information should not be kept longer than necessary. This policy is where that principle becomes a rule with teeth.
Each of these policies should be no longer than two pages. Write them in plain language. Test them by asking someone outside the team that wrote them to explain what they mean. If they struggle, rewrite.
Step 2: Build a Data Quality Framework
Data quality is the operational heart of data governance. You can have perfect policies and impeccable role definitions — but if the data itself is wrong, incomplete, or inconsistent, none of the rest matters. Decisions made on bad data are bad decisions, regardless of how well governed the process was.
The framework below gives you a practical structure for defining, measuring, and improving data quality across your organisation.
visualizeVvisualize show_widgetMaking quality measurable
Each dimension above needs a metric, a threshold, and an owner. Without all three, quality becomes subjective — and subjective standards get ignored when people are busy.
Here is a practical starting point for each dimension:
Accuracy — the percentage of records that match a verified source of truth. For customer data, this might mean periodically validating address records against an authoritative source like NZ Post. Set a target — 95% is a reasonable starting point for most operational data.
Completeness — the percentage of required fields that are populated. This is usually the easiest to measure and the fastest win. If 20% of your customer records are missing an email address, you now have a concrete improvement target.
Consistency — whether the same data attribute holds the same value across different systems. Customer names, for example, often drift between your CRM and your billing platform. Define which system is the "master" for each data type and measure deviation from it.
Timeliness — whether data is updated within a defined window relative to when the underlying event occurred. For financial reporting, this might mean transaction data must be reconciled within 24 hours of posting. Define your window per data domain.
Uniqueness — the absence of duplicate records. Duplicate customer records are one of the most common data quality problems in NZ organisations — particularly those that have grown through acquisition or run multiple customer-facing systems. Measure the deduplication rate and set a target to drive it toward zero.
Capture these metrics in a simple dashboard — even a shared spreadsheet works at the start. The goal is visibility. What gets measured gets managed.
Step 3: Build Your Data Stewardship Model
In Part 1, we defined the roles: executive sponsor, data owners, and data stewards. Now we need to give stewards something specific to do.
Data stewards are the operational heartbeat of your governance programme. They are the people closest to the data — the ones who notice when something looks wrong, who field questions from colleagues, and who keep the governance machinery running between formal reviews.
What a steward's regular responsibilities look like
A steward's core activities should be documented and scheduled, not left to good intentions. A useful starting cadence looks like this:
Weekly: Review data quality alerts from your systems. Flag any records that fall below quality thresholds. Escalate issues that require a data owner decision.
Monthly: Run a completeness report on your assigned data domain. Review any access requests that came through during the period. Update the data inventory if new data sources have been added.
Quarterly: Work with the data owner to review and confirm that retention schedules are being followed. Participate in the governance forum (see below). Review whether any policies need updating based on operational experience.
Annually: Support the formal data quality audit. Confirm that access controls are still appropriate for all users in your domain.
The steward's role is not glamorous. But it is the difference between a governance framework that lives in a document and one that actually protects your organisation.
Step 4: Establish a Governance Forum
Data governance needs a regular home — a structured meeting where issues are raised, decisions are made, and progress is reviewed. Without this, governance becomes reactive, driven only by problems rather than continuous improvement.
A monthly governance forum does not need to be elaborate. The minimum viable version includes the executive sponsor (or their delegate), data owners for each domain, and a rotating steward representative. The agenda should cover three things every time: quality metrics review, open issues and escalations, and any policy changes under consideration.
Document decisions. Circulate minutes. This creates the audit trail that regulators — including the Office of the Privacy Commissioner — expect to see when they ask how your organisation manages personal information.
Step 5: Navigate the NZ Compliance Landscape
For NZ organisations, data governance is not just good practice — it is increasingly a regulatory expectation. Understanding where the requirements come from will help you prioritise your governance efforts.
The Privacy Act 2020 remains the cornerstone. The key operational obligations your governance programme must address are: mandatory breach notification to the OPC (within 72 hours of becoming aware of a notifiable breach), individuals' rights to access and correct their personal information, and the requirement to take reasonable steps to ensure data is accurate before use (Principle 8). Your data quality framework directly supports this last obligation.
The NZ Government Data and Digital Strategy sets the direction for public sector agencies, but its principles — data as a shared asset, open by default, privacy protected — are increasingly influencing expectations in the private sector as well.
For regulated entities, the RBNZ's expectations around data quality in prudential reporting are significant. The RBNZ has been explicit that data governance weaknesses — particularly around data lineage and accuracy in capital and liquidity reporting — are an area of supervisory focus. Similarly, the FMA expects regulated entities to be able to demonstrate that the data underpinning their risk assessments and disclosures is reliable and well-controlled.
For health sector organisations, the Health Information Privacy Code 2020 adds specific obligations around health information, which sits at the most sensitive end of the data classification spectrum.
If your organisation operates across sectors, or has Australian operations, note that Australia's Privacy Act reform process (ongoing since 2022) is likely to introduce stronger data governance obligations that align more closely with GDPR-style requirements — something NZ-headquartered organisations with trans-Tasman operations should monitor.
Step 6: Choose Your First Tool — Carefully
At some point in this journey, you will need tooling. A spreadsheet-based data inventory gets you started, but it does not scale. The temptation is to invest in a sophisticated data catalogue early. Resist it.
The risk with buying a data catalogue before your governance processes are mature is that the tool becomes the governance programme — people focus on configuring the tool rather than actually governing the data. The tool should serve the process, not replace it.
For most NZ organisations at the early-to-mid governance maturity stage, the tool priority order looks like this:
First, a data quality monitoring capability — even basic SQL queries running on a schedule can surface quality issues before they become problems. Microsoft Purview, Ataccama, and Monte Carlo are purpose-built options; many organisations start with what they already have in their cloud platform.
Second, an access management and identity governance tool. If you are on Microsoft 365 (very common in NZ), Entra ID (formerly Azure AD) has governance features built in that most organisations underuse.
Third, a data catalogue — once you have stable processes, an established stewardship model, and a data inventory that is actually being maintained. Popular options in the NZ market include Microsoft Purview (which integrates with the Microsoft stack), Alation, and Collibra. Open-source options like OpenMetadata are worth evaluating for smaller teams.
What Part 3 Will Cover
The final post in this series is about scaling your governance programme toward maturity — automating quality checks, building a metrics-driven governance scorecard, integrating governance into your data and AI strategy, and making continuous improvement a structural feature rather than an aspiration. We will also look at what a genuinely mature data governance programme looks like in a NZ context, and the markers that tell you whether you are genuinely getting there.
Key Takeaways from Part 2
Write three core policies first — classification, access, and retention. Keep them short and plain-language.
A data quality framework needs five dimensions, each with a measurable metric, a threshold, and an owner.
Data stewards need a structured schedule of activities, not just a job title.
A monthly governance forum creates the decision-making home your programme needs and the audit trail regulators expect.
In NZ, governance obligations flow primarily from the Privacy Act 2020, with additional expectations from the RBNZ and FMA for regulated entities.
Choose tooling after your processes are stable — not as a substitute for them.