Purview doesn't write your rules. But it will enforce the ones you do.

Data governance is two different things that get confused for each other. One is the work of deciding, in language the business speaks — what we treat as confidential, how long we keep it, who is allowed to see it, and what happens when any of those rules get broken. That work belongs to the people who understand the business's risk appetite, its regulatory exposure, and its client commitments. It doesn't happen in a portal.

The second thing is enforcement — the control plane that makes the decisions real across email, files, Teams, and everywhere else data moves. For organizations in the Microsoft estate, that control plane is Purview. It is almost certainly already in the license. The value isn't in buying it. The value is in configuring it to reflect what the business actually decided.

The two get confused because IT usually gets handed the portal without being handed the decisions. So the defaults get turned on, the policy list looks busy, and the business still can't answer the question a client or a regulator is about to ask. The first conversation we have about governance almost never starts with Purview. It starts with a question the business already half-knew it couldn't answer.

Microsoft Purview is a capable, well-documented toolset. A competent administrator can stand up sensitivity labels, retention policies, and data loss prevention rules in a few weeks. The portal isn't the bottleneck. The bottleneck is upstream of the portal — in the work of deciding, in plain English, what your organization considers confidential, how long you're willing to keep things, who is allowed to see what, and what happens when any of those rules get broken.

That decision work isn't a technology problem. It's a leadership problem. It belongs to the people who understand the business's risk tolerance, its regulatory exposure, its client commitments, and its appetite for trade-offs between speed and control. The audience for a governance conversation is the C-suite, whoever owns legal or risk, and the executive who'll sign the next client security questionnaire — not the IT admin who will eventually implement the decisions.

That's also why we start every engagement with a questionnaire rather than a workshop. Twenty minutes of structured questions, completed by the business before we meet, gives us both the shape of the gaps and a clean agenda for the working session that follows. Without the questionnaire, we end up in a room waiting for someone to email the compliance officer and ask whether DLP is turned on. With it, we spend the session on the hard part — turning business intent into policy language that holds up under questioning.

A governance engagement is deliberately compact. Programs that run for a year without producing an enforced policy usually produce neither. The point of the work is to get the posture right quickly, then let the business operate — not to keep ourselves in the room.

The arc is four steps. They happen in order for a reason.

One — the questionnaire. Short, async, completed by the business before we meet. Twenty minutes of structured questions that surface where data actually lives, who has access, what's labelled, what's retained, and which of the existing controls are claimed versus actually enforced. The current state is a fact the business already has. The questionnaire pulls it into a form we can work with.

Two — the working session. Half day or full day, with the people who have the authority to make the calls. We open with a tabletop — three or four realistic scenarios that make the risk visible in the room instead of hypothetical in a briefing. A client asks for their records back. An auditor wants proof of a retention policy. A laptop goes missing. From there we move to the decision work itself — translating business intent into language for labels, DLP, retention, and access.

Three — the remediation and rollout plan. Based on the gaps the questionnaire and tabletop surfaced, a sequenced plan for configuring Purview and rolling out the policies. Quick wins up front. Sensitive workloads sequenced behind so the rollout doesn't itself cause an incident. Realistic dates, not aspirational ones.

Four — deployment and the rhythm. The policies get configured, the labels get applied where they matter, DLP moves from audit mode to enforcement when the business is ready, retention starts running. And a rhythm gets set — a quarterly review that checks what's drifted, what's been triggered, what needs to change. Governance that isn't revisited is governance that will be obsolete by the next audit cycle. This is where we usually stay on as the fractional voice the business doesn't want to hire full-time.

A governance engagement produces tangible things. A sensitivity label taxonomy written in the business's own language. DLP rules that reflect real risk tolerance instead of Microsoft's defaults. Retention policies the legal contact has actually signed off on. A rollout plan with owners and dates. A tabletop exercise the leadership team has been through, in a room, with the right people watching.

Those things matter. But the outcome the business actually hired us for is less visible. It's the shift in what you can answer, and how quickly. Before the engagement, every data question stalls on the same sentence — "we should probably figure out the governance first." After, it's figured out. A client security questionnaire gets answered in hours instead of a week of fire-drilling. A regulator asking about retention receives a policy, not a scramble. An incident becomes a process with owners, not a conference bridge at midnight.

That is the whole deliverable. The capacity to answer a hard question on a Tuesday afternoon, without turning Wednesday into a bad week. A program that holds up under questioning from outside the company, because everything underneath it was built to be answerable in the first place.