Microsoft Purview guards your data. Who guards your Purview?

2026-09-21T07:00:00+00:00

Microsoft Purview is very good at telling you about your data.

Where sensitive information lives. Who opened what. Which email was blocked, which file was labelled, which user tried to share a customer register externally. Content Explorer and Activity Explorer answer those questions well, and most organisations running Purview use them.

What Purview will not tell you is anything about itself.

If a DLP rule is switched off, you are not notified. If a sensitivity label’s permissions are narrowed, or widened, nothing alerts you. If a threshold is changed from ten to fifteen, the product carries on quietly enforcing fifteen.

There is an audit log entry, somewhere, recording that a policy was modified. It will not tell you what the setting was before, whether anyone approved it, or whether the protection just became weaker.

This article describes how to make Purview report on its own configuration — so that when something changes, you find out, and you can see exactly what changed from what.

The approach is not new. Software engineering solved this problem decades ago. It has simply not been applied to compliance controls very often, and that is what I want to walk through.

The idea, in one paragraph

You write down what your configuration is supposed to be. You keep that description somewhere it cannot be quietly edited. On a schedule, something reads what the configuration actually is and compares the two.

If they match, you get a record saying so. If they do not, you get a report saying exactly what differs.

That is the entire mechanism. Everything below is about doing each part in a way you can rely on.

Part one: turn the configuration into a file

The first step sounds strange if you have only ever managed Purview through the portal.

Your policies, rules, labels and label policies can be read out of the tenant and expressed as a structured text file. Every DLP rule, every threshold, every permission on every label, every scope on every policy — written down as readable text.

Here is roughly what a fragment of one looks like:

DLPComplianceRule "Low volume - policy tip"
{
    Name     = "Low volume - policy tip";
    MinCount = "1";
    MaxCount = "9";
    Ensure   = "Present";
}

You do not need to be a developer to read that. A rule, its name, its instance thresholds, and a statement that it should exist.

Once your configuration is a file, three things become possible that were not possible before.

You can read it — the whole of it, in one place, rather than clicking through twenty portal pages.

You can compare it — two files can be set side by side and every difference shown, line by line.

And you can keep it — a file can be stored, versioned and retained in a way that a screenshot cannot.

The tooling that performs this export is open source and maintained with Microsoft engineers. It covers far more than Purview; for this purpose you point it at the compliance-related parts of the tenant only.

Part two: make it the approved baseline

A file on someone’s laptop is not a baseline. It is a snapshot.

What turns it into a baseline is that someone with authority has looked at it and agreed it is correct — and that this agreement is recorded.

In practice that means storing the file in a version-controlled repository, the same kind of system software teams use for source code. The important properties are simple:

Every version ever saved is kept. Nothing is overwritten
Every change records who made it, when, and a written reason
Changes can be required to pass through a review step before they are accepted

That last property is the one that matters for compliance. A written procedure saying “changes are reviewed” is a claim an auditor has to sample and hope about. A repository that will not accept a change without a named reviewer’s approval is a control — and it records every single instance automatically.

One to watch The repository belongs to the customer. Not to the consultant, not to the managed service provider. If the engagement ends, the organisation keeps its baseline, its full change history and its evidence. A monitoring arrangement that walks out the door with the supplier has not delivered anything durable.

Part three: read the live configuration on a schedule

Now you need to find out what the configuration actually is — regularly, and without anyone having to remember to do it.

That means an automated job that runs on a timetable, authenticates to the tenant, and performs the same export you did by hand in part one.

Two design points here are worth more than the rest put together.

It has to run as a non-human identity. A scheduled job at five in the morning has no person present to sign in. So it needs its own identity, with a credential it can use unattended. Get the credential handling wrong and you have created a highly privileged key that can rewrite your compliance configuration, stored somewhere it should not be. The credential belongs in a proper secrets store, fetched at run time and never written into the job itself.

It has to read, and only read. The identity needs enough access to see the compliance configuration and no more. How much access that actually is, and how it is granted, is less obvious than it should be — there are two separate permission layers involved, only one of which is visible in the place you would expect to find it.

Part four: compare

With the approved baseline in one hand and the live export in the other, you compare them.

The output is a diff — a line-by-line account of what differs. It shows three kinds of change, and they look different from each other:

Something was added. A new policy nobody approved:

+   DLPCompliancePolicy "New policy"
+   {
+       Name = "New policy";
+       Mode = "Enable";

Something was modified. The same property, with the old value and the new:

-       MaxCount = "9";
+       MaxCount = "5";

Something was removed. A line that is simply gone, with nothing replacing it:

-       ApplyContentMarkingFooterText = "Internal working material";

That third shape deserves attention. Nothing else in your environment will tell you what that footer text used to say. The portal shows the current state. The audit log records that the label was modified. The diff is the only record, anywhere, of the previous value.

Part five: report

A diff is for engineers. It is precise, fast, and nearly unreadable to anyone else.

So the last step turns it into something a compliance owner can act on: a readable report of every deviation, what it changed from and to, and — critically — a place for a decision.

Every deviation should close with one of two outcomes:

Restored — the tenant was wrong; the approved configuration was put back
Adopted — the change was legitimate; it is now the new approved state

Both are valid. What matters is that one of them is written down, by a named person, with a reason.

One to watch The system detects. It should never remediate on its own. Automatically reverting drift sounds appealing and is almost always wrong for compliance controls. A change made for a good reason, silently undone, creates a new incident and a very unhappy administrator. The report goes to a human; the human decides.

The report runs every period, whether or not anything changed. The quiet months matter most — a dated record saying compared, no deviations is evidence of continuous operation. A quiet month with nothing recorded is indistinguishable from a month nobody looked.

Where this goes wrong

Building the mechanism is a fortnight’s work for a competent engineer. Making it trustworthy is most of the rest.

The failure mode that matters is not a monitoring job that breaks. Broken jobs are obvious.

It is a monitoring job that reports success while checking nothing.

An export that silently misses part of the configuration produces a smaller file. A smaller file compares cleanly against the baseline. A clean comparison produces a clean report. Green light, no findings — and a control that was never actually read.

There is a mirror-image failure too: a comparison that flags a difference that is not really there, because the same configuration is written out slightly differently from one run to the next. Leave that unexplained and it recurs every month, the report fills with noise, and a genuine change eventually drowns in it.

I have seen both. Neither announces itself. Designing against them — knowing where the blind spots are and turning silent failures into loud ones — is the part that separates a monitoring service you can rely on from one that produces reassuring documents.

What you end up with

Put together, the approach answers the three questions any supervisory authority or auditor asks about a control:

They ask	You show
What is the approved configuration?	The baseline file, and who approved it
What changed, and who approved each change?	The repository history — every change, author, date and reason
Did it operate continuously?	A dated record of every scheduled comparison, and what each found

The first question is usually answerable today with some effort. The second rarely is. The third almost never is, because nothing was recording the months in which nothing happened.

Where to start

Not with the technology.

Start with a decision about what your controls are supposed to be, and a named person accountable for that decision. The export, the repository and the schedule are the easy half.

If you can say, today, “this is our approved Purview configuration, and this is who signed it off” — you have a baseline. Everything else is making sure you find out when reality stops matching it.

If you cannot, that is the first conversation to have.

AV works with information protection and compliance in Microsoft 365, with a focus on Swedish public sector organisations. If you would like to know what your Purview configuration actually looks like today — written down, in full, in one place — that is usually where we start.

Alexander Vik

Microsoft Purview guards your data. Who guards your Purview?

The idea, in one paragraph

Part one: turn the configuration into a file

Part two: make it the approved baseline

Part three: read the live configuration on a schedule

Part four: compare

Part five: report

Where this goes wrong

What you end up with

Where to start