Microsoft Purview licensing: the cliff edges that decide your bill

Most Purview licensing questions are really one question asked five ways: what stops working if I stay on E3. The answer is not a tier, it is a set of cliff edges scattered across individual features, and two of them downgrade your protection silently rather than blocking you.

The name changed, the entitlement did not

Microsoft 365 E5 Compliance is now called Microsoft Purview Suite. Microsoft’s own licensing tables use the new name throughout and state that the rename does not affect service, functionality or pricing. If a vendor quote or an internal document still says E5 Compliance, it is describing the same thing.

UK list price at the time of writing is £9.20 per user per month on an annual subscription, excluding VAT. It requires Microsoft 365 E3, or Office 365 E3 with Enterprise Mobility + Security E3, as a base.

The cliff edges that actually cost money

These are the specific points where an E3 estate stops. Not the marketing comparison, the ones that change what happens in production.

The adaptive scope row is the one that catches people. Retention itself is an E3 capability, so a policy will build and apply happily. Adaptive scoping, the part that keeps the policy targeted as people join and leave, is not.

Two things that fail quietly

Most licensing gaps announce themselves with a blocked button. These two do not.

Customer Key reverts to default encryption

Because data encryption policies apply at tenant level, your tenant must hold at least as many Customer Key licences as it has users assigned Exchange or Teams licences, whichever number is greater. SharePoint is counted separately. Microsoft validates the count periodically, and if the tenant is short, encryption reverts to the default service encryption. You keep the configuration and lose the property you bought it for.

Teams retention has a thirty day floor

For several plans, retention or deletion of Teams chats and channel messages is only covered where the period is longer than thirty days. A twenty eight day deletion policy is a different licensing question from a thirty five day one, which is not an obvious place to look when a policy behaves unexpectedly.

The charge that is not a licence at all

Some Purview capabilities now bill by consumption rather than per user, and those require the tenant to be linked to an Azure subscription. Network data protection is the clearest example: it is a pay-as-you-go feature, so no per-user licence unlocks it and nothing happens until the Azure link exists.

Collection policies work the same way in reverse. They carry no licensing requirement of their own. You need to be licensed for the workload the policy touches, so a collection policy that includes devices needs endpoint DLP licensing to function.

Where you are almost certainly over-licensed

One line in the service description is worth more than most cost reviews: for shared locations such as SharePoint sites, Microsoft 365 Groups and Teams channel messages, users holding owner or member roles need the licence. Users with visitor or view-only roles do not.

In estates with large read-only populations, that distinction is the difference between licensing everyone who can see a site and licensing everyone who can change one.

Auditing what you actually own

Before any licensing conversation, establish which SKUs in the tenant genuinely carry Purview premium service plans. Marketing names are not reliable here and SKU display names are worse.

1# Requires Microsoft.Graph.Identity.DirectoryManagement.
2Connect-MgGraph -Scopes ‘Organization.Read.All’
3
4# Service plans that carry Purview premium capability. Names are stable even
5# when the SKU marketing name changes, which it has.
6$purviewPlans = @(
7    ‘M365_ADVANCED_AUDITING’
8    ‘RECORDS_MANAGEMENT’
9    ‘INSIDER_RISK_MANAGEMENT’
10    ‘COMMUNICATIONS_COMPLIANCE’
11    ‘INFORMATION_BARRIERS’
12    ‘PREMIUM_ENCRYPTION’
13)
14
15Get-MgSubscribedSku -All |
16    Select-Object SkuPartNumber,
17                  @{ n = ‘Purchased’; e = { $_.PrepaidUnits.Enabled } },
18                  ConsumedUnits,
19                  @{ n = ‘PurviewPlans’; e = {
20                        ( $_.ServicePlans |
21                            Where-Object { $purviewPlans -contains $_.ServicePlanName } |
22                            Select-Object -ExpandProperty ServicePlanName
23                        ) -join ‘, ‘
24                  } } |
25    Where-Object { $_.PurviewPlans } |
26    Format-Table -AutoSize

Anything with purchased units well above consumed units is either a migration remnant or a renewal nobody questioned.

What I would do

Work from the capability you actually intend to operate, not from the tier. Write down the three Purview features you will genuinely run in the next six months, find each one in Microsoft’s service description, and check the exact plan column. Two of those three are usually covered by what you already own, and the third decides whether the add-on is worth £9.20 a head.

Then check Customer Key licence counts and the visitor role population, in that order. One of them can silently remove protection you believe you have, and the other is where the money usually is.