Data governance that produces evidence: a 90-day Purview implementation that people actually use

Governance fails when it arrives as a policy document and a committee. It works when it is built into the tools people already use: the catalogue is where they look things up, the label applies itself, the access request goes to the person who actually knows, and the lineage diagram is generated rather than drawn.

Nobody has ever called us because they wanted governance. They call because an auditor, a regulator or a customer asked a question they could not answer. The question is nearly always the same one.

The question that exposes an estate

Who could see this dataset in the second quarter of last year?

In most organisations the honest answer takes a week, because permissions were granted to individuals over several years by several administrators, people changed role, workspaces multiplied, and nothing was ever reconciled against the policy.

The fix is unglamorous and it is the highest-value change available: access through directory groups that mirror your control model, so the question becomes a report parameterised by dataset and date range.

Start by measuring the gap

Before designing anything, extract the access reality and compare it to the documented policy. In a Power BI estate that means the admin APIs: workspaces, datasets, apps, individual grants, app permissions, external users, and sharing links.

This gap analysis is usually uncomfortable. The findings we see most often:

• Individual grants on production datasets, often to people who have changed role.
• Workspaces with "everyone in the organisation" access that were created for a pilot.
• External guest users retained long after the engagement that justified them ended.
• Several copies of a sensitive dataset, one of which has permissive access.
• Sharing links with no expiry.

It is also the most useful artefact of the whole engagement, and clients who stop after this phase still get genuine value. We have had two do exactly that, which is a legitimate outcome.

Classification before tooling

Deploying Purview before agreeing a classification scheme produces a catalogue nobody trusts, because the labels mean different things to different teams.

Agree the scheme first, with legal, security and the business in the same room. Four tiers is usually right, more than five and people guess. For each tier, state three things:

1. What qualifies, with examples from your actual data rather than abstractions.
2. The retention period, mapped to the obligation that drives it.
3. The handling rules: who may access, whether export is permitted, whether encryption applies.

Align this to an existing information security policy if you have one. Introducing a parallel taxonomy for analytics is how you end up with two schemes and no clarity.

Purview, and when it is not needed

Purview earns its place when you have enough assets that manual cataloguing has already failed. It scans, classifies and maintains lineage automatically. Below roughly a hundred assets with a stable team, a disciplined manual catalogue can genuinely be enough, and we say so rather than quoting a deployment.

Where it is justified, what it gives and does not give:

The deployment itself is not the hard part. Populating the glossary and getting stewards to maintain it is, which is why we stage stewardship training inside the implementation rather than after it.

Access control: groups, not grants

Design groups around how authority is actually delegated, not how the org chart is drawn. In practice that means granularity by function and by entity, site or region, because that is how most organisations actually restrict visibility.

The migration sequence:

1. Create groups mirroring the control model, named so their purpose is obvious from the name alone.
2. Map every existing grant to a group, flagging those that have no legitimate group, these are the ones worth a conversation.
3. Apply group-based permissions, then remove individual grants.
4. Test from a non-privileged account for each role, including drill-through paths.

Step four is where most implementations stop short. A row-level security rule that has never been tried from outside is an assumption, and drill-through is specifically where a correctly suppressed summary leaks the underlying row.

Then build the access request flow so it routes to the data owner rather than to IT. IT cannot judge whether a request is appropriate; the owner can.

The export problem

Exports to spreadsheets are where analytics estates actually leak, and it is rarely malicious, someone needed the numbers in a format they could work with.

Sensitivity labels applied in Power BI travel with the exported file, carrying encryption and access restrictions outside the platform. Export can also be blocked entirely for specific labels or audiences. Configure both, then test from an unprivileged account on an unmanaged device, because that is the scenario the control exists for.

Two related measures worth implementing at the same time:

• Small-number suppression in measures, where the data could identify an individual, applied consistently including on drill-through.
• Retention enforced in the platform against the actual obligation, rather than data kept indefinitely because deletion was never specified.

A 90-day plan

Each stage produces something usable on its own, which is what makes it safe to stop.

Days 1 to 15, Assess. Access extract versus policy, data map, classification gaps, retention reality. Output: a risk-ranked remediation plan ordered by exposure rather than by ease.

Days 15 to 35, Define. Operating model with named owners and stewards, classification scheme, retention rules, access standards. Agreed with legal and the business, not drafted in isolation.

Days 35 to 70, Implement. Purview scanning and catalogue populated, labels published and applied with sensible defaults, access rebuilt onto groups, lineage switched on, suppression implemented in measures.

Days 70 to 90, Evidence. Access evidence reporting, audit pack generation, steward training, and the first governance review run with your team rather than for them.

Does it slow analysts down?

Badly implemented governance does, which is why adoption collapses. Done properly it is faster, and the effect is measurable:

• A searchable catalogue stops people rebuilding work that already exists. In one engagement, four near-identical copies of a key dataset were consolidated once the catalogue made the duplication visible.
• Group-based access means a new joiner is productive on day one instead of raising five permission requests.
• Certified datasets give analysts a sanctioned starting point, which removes the "is this the right source" question entirely.

We measure time-to-first-answer before and after, because a claim about governance improving speed should be testable rather than asserted.

What this does not cover

We are not a law firm. Your DPO or counsel owns the legal position, lawful basis, legitimate interests assessments, the regulatory interpretation. We build and document the controls that support it, and we produce the evidence they need to defend it.

Market-specific obligations vary considerably: works council co-determination in Germany, FINMA outsourcing expectations in Switzerland, regional reporting in Belgium, Central Bank outsourcing rules in Ireland. Those are covered on the locations pages, and the commitments we make inside client environments are on the data protection page.

Stewardship that survives the first quarter

Most governance programmes appoint stewards and then watch the role decay, because it was added to someone's job with no time and no authority.

What makes it stick, in our experience:

• Scope the role small. A steward owns a defined set of assets and a defined set of decisions, approving a glossary definition, approving access to their data. Not "data quality across the organisation".
• Give it a cadence, not a committee. A thirty-minute fortnightly review of new assets, open access requests and failing quality tests. If there is nothing to discuss, the meeting ends in five minutes, which is the point.
• Put the work in the tool they already use. An access approval that arrives in Teams gets done; one that requires logging into a governance portal does not.
• Report on stewardship, visibly. Assets without an owner, glossary terms without a definition, access requests older than five days. Visibility does more than escalation.

The failure mode to watch for is a steward who approves everything. That is not a governance failure, it is a scope failure: they have been asked to judge something they do not understand, and approving is the only safe response.

Answering a subject request against an analytics estate

Subject access and erasure requests are where governance stops being theoretical, and analytics estates are usually the weakest point because nobody maintains a map of which copies exist.

What you need in place beforehand:

1. Lineage from source to report, so you can enumerate where an individual's data has propagated rather than guessing.
2. A documented position on pseudonymised data, whether, in your implementation, it remains personal data. Usually it does, if you hold the key.
3. A deletion procedure for the warehouse that is a repeatable process rather than an ad-hoc statement run by an engineer, including how downstream aggregates and semantic models are refreshed afterwards.
4. A record of what you did, generated by the process rather than written afterwards.

The practical advice we give: handle erasure in the source systems and let the analytics estate inherit it through a full reload of the affected partitions. Deleting rows directly from a warehouse without a reproducible process creates a reconciliation problem that will surface months later and be impossible to explain.

What "good" looks like after a year

The test is not whether a policy exists. It is whether these four questions can be answered without a project:

• Who could see this dataset on a given date last year?
• Where did this figure in the board pack come from, and what feeds it?
• What is our retention period for this data, and is it actually enforced?
• If this table changes next week, what breaks?

An estate that answers all four from reports rather than investigation has working governance, whatever the documentation says. An estate that cannot answer them has a policy, which is a different thing.

If you want the assessment (the access extract, the gap analysis, the risk-ranked plan), that is a three-week fixed-price piece of work and the output is yours regardless of what follows. Book a technical review.