Microsoft Purview and the permissions work that has to come first

Microsoft Purview brings information protection, data loss prevention, insider risk management, retention and compliance into one place. It is a large and capable product set, and organisations regularly start in the wrong place with it.

The wrong place is labels. The right place is finding out who can currently reach what.

The threat model, stated precisely

A sensitivity label does two things. It marks content, and — where encryption is applied — it restricts who can open it regardless of where the file travels.

What it does not do is change the permissions on the location where the content lives. If a document sits in a SharePoint site that everyone in the organisation can read, applying a “Confidential” label does not remove that access. It records that the document is confidential and leaves it readable by everybody.

That gap matters because the realistic threat for most organisations is not a sophisticated exfiltration campaign. It is:

• A site or a Teams channel that is far more open than anyone realised.
• A sharing link created for one purpose and still live years later, as in SharePoint and OneDrive sharing defaults.
• A guest account from a supplier relationship that ended.
• A departing employee with legitimate access to more than their role required.

None of those is addressed by classification. All of them are addressed by permissions.

Exposure: what to find out first

Before any Purview deployment, answer these:

Where is the data? Which sites, which Teams, which OneDrive accounts, which on-premises shares. An inventory, even a rough one.

Who can reach each location? Including organisation-wide access, guest access and anonymous links. This is the question that produces the uncomfortable answer.

What is over-permissioned? Sites open to everyone that should not be. Groups whose membership has grown. Guests who no longer need access.

Who owns each location? Not who administers it — who is accountable for deciding who should have access. Most remediation stalls here, because the owner is unknown or has left.

The content explorer and activity explorer in Purview help once classification is running, and the SharePoint admin centre’s sharing and access reports help before that. For a large estate, the access review capability in Entra ID governance is what makes the ownership question tractable at scale.

Assessment: run discovery before you enforce

Purview can find sensitive information without acting on it, and that is where to start.

Enable auditing if it is not already on. It is the evidence base for everything else, and retrospective collection is impossible.

Run sensitive information discovery. Built-in sensitive information types cover the common categories — payment card numbers, national identifiers, health identifiers — and trainable classifiers extend that. Let it run and look at what it finds and where.

Two findings are typical, and both are useful:

• Sensitive data in locations nobody expected, frequently in personal OneDrive accounts and in Teams channels created for a project.
• Far more false positives than expected, because a built-in type matching a number format matches a great many numbers. Tuning the types and their confidence levels is real work and it must happen before enforcement, or your data loss prevention policy will block legitimate work on day one.

Run data loss prevention policies in simulation or test mode, which reports what would have been blocked without blocking it. This is the same discipline as report-only Conditional Access, audit-mode ASR rules and audit-effect Azure Policy — and it is the same discipline for the same reason.

Hardening: the order that works

1. Fix permissions. Remove organisation-wide access where it is not warranted, revoke lapsed guest access, clean up sharing links, and establish owners. This is unglamorous and it is the step that actually reduces exposure.

2. Set the sharing defaults so the problem stops growing while you work through the backlog.

3. Enable auditing and run discovery, so you know what you are protecting and where it is.

4. Design a small label taxonomy. Three or four labels. Public, Internal, Confidential, and perhaps one highly restricted tier. Every additional label reduces the chance that users apply any of them correctly, and a taxonomy with fourteen labels is a taxonomy nobody uses.

5. Publish labels without encryption first. Let people apply them, see how they are used, and find out where the taxonomy does not fit reality. Labels that merely mark content are low-risk and informative.

6. Add automatic labelling, first in simulation. Automatic classification applied to a tenant without simulation will label things wrongly at scale, and unpicking that is tedious.

7. Add encryption to the most sensitive label only, once the taxonomy is stable. Encryption is where labels start affecting whether people can open files, including on devices and in applications that do not support it. It is also what breaks external collaboration in ways that need designing for rather than discovering.

8. Deploy data loss prevention, in test mode, tuned, then enforced — starting with the highest-confidence, lowest-volume rules.

9. Then retention and insider risk, which are separate programmes with their own stakeholders.

Detection

• Alert on sensitive content appearing in unexpected locations, which is what activity explorer is for.
• Alert on label downgrades — a user moving content from Confidential to Internal. Legitimate sometimes, and worth seeing.
• Watch data loss prevention policy matches for patterns rather than individual events, and feed the patterns back into tuning.
• Review the false positive rate. A policy generating mostly false positives is training users to click through it, which is worse than not having it.

Validation

• Confirm labels appear in the applications people actually use, on the platforms they use them on. Label support varies by application and platform, and a label that is invisible in the web client is a label half your users cannot apply.
• Confirm an encrypted document is unreadable by someone outside the permitted set, and readable by someone inside it, including on a mobile device and for an external collaborator who is supposed to have access.
• Confirm a data loss prevention policy blocks what it should and allows what it should, tested with realistic content rather than a contrived sample.
• Confirm the permissions work actually happened, by re-running the access report and comparing.

Operations

Governance is a role, not a project. Labels, policies and permissions drift. Somebody must own the review cycle, and if nobody does, the deployment decays into a control that reports compliance without providing it.

Train people on the taxonomy. Automatic labelling covers the obvious cases; users cover the rest, and they will not do it well if the labels are not self-explanatory.

Review guests and site access on a schedule, not once at deployment.

Expect to revisit the taxonomy once. The first design is always slightly wrong, and changing it later is harder once labels are applied at scale — which is an argument for starting small rather than for deferring.

Honest limits

Purview addresses data governance. It does not fix identity, it does not fix device security, and it does not compensate for a tenant where access is poorly controlled. A label is a statement about content; it is not a boundary unless encryption is applied, and encryption carries compatibility consequences that have to be designed for.

It is also a licensing-sensitive product set, with capabilities distributed across different subscription levels. Confirm what you are entitled to before designing around a feature, rather than discovering the gap at deployment.

Verification and limits

The distinction between labelling and permissions, sensitivity label encryption behaviour, simulation mode for automatic labelling, test mode for data loss prevention policies, and the role of content and activity explorer were checked against current Microsoft documentation on 20 September 2026. The deployment ordering and the emphasis on permissions first are my own judgement, based on the failure mode I have seen most often.

Nothing here was deployed for this article. Sensitivity labels with encryption change who can open existing files, and data loss prevention policies can block legitimate work — run discovery and simulation first, tune sensitive information types before enforcing, and start encryption with a single label. Capabilities and licensing requirements change; confirm both for your tenant.

References

• Microsoft Purview Information Protection
• Learn about sensitivity labels
• Learn about data loss prevention
• Get started with content explorer