Most organisations treat a sensitivity labels rollout as a project they will start when they are ready, and most of the time that is exactly right. In around 90% of the estates we assess, no labels are set at all. Implementations genuinely do begin from nothing, and the first stage of most programmes has no labelling in it.
The reason to check anyway is the minority where that is not true. Microsoft’s documentation states plainly that default labels and policies are now automatically created for new customers who have an eligible licence for Microsoft Purview. Not offered. Created. Where a tenant qualified, a taxonomy exists, a policy publishes it to every user, a default label is being applied to unlabelled content, and an auto-labelling policy is running on a clock, whether or not anyone in the organisation chose any of it.
Those two starting positions need completely different plans, and telling them apart takes about ten minutes. This piece covers both, in that order.
The first question is not what to build
It is what already exists.
Before designing anything, establish which of these is true in your tenant: no labels published at all, defaults created automatically that nobody has reviewed, or a deliberate configuration someone built. Most estates are the first. But only a check tells you that, and the cost of assuming wrongly falls entirely on the estates in the second group, where something is already running.
The distinction matters because the automatic defaults are not inert. The default label policy publishes to all users in the tenant, sets General \ All Employees (unrestricted) as the default label for unlabelled documents, email and meetings, and requires users to provide a justification to remove a label or lower its classification.
That last setting is the one to notice. A justification prompt is a user-facing behaviour change. If it appeared without warning, your service desk has probably already had the calls and nobody connected them to a labelling deployment nobody announced.
What the default taxonomy actually contains
It is more opinionated than most people expect, and considerably more granular than the five-label starting point Microsoft recommends elsewhere.
| Label | Sublabels | Protection applied |
| Personal | none | None |
| Public | none | None |
| General | Anyone (unrestricted), All Employees (unrestricted) | None |
| Confidential | Anyone (unrestricted), All Employees, Trusted People | Footer, and encryption on two of three |
| Highly Confidential | All Employees, Specific People | Watermark, and encryption on both sublabels |
The protection settings are where this stops being a filing exercise. Confidential \ All Employees applies encryption granting co-author rights to all users and groups in the organisation, with a footer reading “Classified as Confidential”. Highly Confidential applies a watermark reading HIGHLY CONFIDENTIAL. Highly Confidential \ Specific People applies Do Not Forward in Outlook and prompts for permissions in Word, PowerPoint and Excel.
Encryption travels with the file. That is the entire point of it, and it is also what makes an unreviewed default risky: a document encrypted under a label nobody chose is still encrypted when it reaches a customer, an auditor or a system that cannot open it.
There is a propagation detail worth planning around. Users see new labels within four hours in Office apps on Windows, macOS, iOS and Android, and within one hour for Word, Excel and PowerPoint on the web after a browser refresh, but you should allow up to 24 hours for changes to replicate everywhere. So a label change is not a same-afternoon rollback.
The policy that turns itself on
This is the part I would check today, before reading further.
Service-side auto-labelling creates policies that run in simulation mode, which previews what would be labelled without labelling anything. That is a sensible, cautious default and it is not the whole story.
If the policy is left unedited, it turns itself on automatically once a set number of days pass after simulation completes. For most tenants that is 7 days.
There is a longer first grace period for tenants onboarded after June 2022, which is simply the cohort date Microsoft applied the change from rather than anything you need to remember: those get 25 days the first time, then 7 days on every policy edited afterwards. If you do not know which side of that your tenant falls, plan for 7 and you will not be caught out.
So the failure mode is not someone enabling something rash. It is nobody doing anything at all. A policy created automatically, simulated automatically, and activated automatically because the team that would have reviewed it did not know it existed.
The default rules themselves are narrow and reasonable, which is partly why they slip through. Both client-side and service-side defaults key on credit card numbers: 1 to 9 instances in a document or email applies Confidential \ Anyone (unrestricted), and 10 or more applies Confidential \ All Employees. The second of those carries encryption.
Two timing details that matter for what you will see:
- The Exchange policy is created and begins simulation immediately
- The SharePoint and OneDrive policy is created but waits 25 days before simulation starts, deliberately, so that files have time to be created and saved
Which means an estate can look quiet for three weeks and then produce a simulation result nobody was expecting.
If you are in the 90%, this still matters
Most readers who check will find nothing published. That is the common case and the good one. It does not make this section irrelevant, it changes what the section is: not a fire to put out, but a decision to make before anything is switched on.
The clock starts whenever the defaults are activated, whether Microsoft creates them or you do. Knowing that simulation mode expires before you enable anything is the difference between choosing what gets labelled and finding out.
For the minority who do find something already running, the order of work inverts. You are not planning a rollout. You are deciding whether to keep one that has already begun, and the auto-labelling policy is the part of it with a deadline attached.
Microsoft’s deployment advice is narrower than most plans
The guidance is unusually restrained, and it argues against the way most labelling programmes are scoped.
Microsoft recommends forming a working virtual team covering business and technical requirements, proof of concept testing, internal checkpoints and approvals, and final deployment. Then, critically: identify your top one or two scenarios that map to your most impactful business requirements, deploy those, and only then return to the list for the next one or two.
One or two. Not a labelling strategy covering every scenario the platform supports.
That restraint is warranted, because the scenario list is enormous. Labels can extend to Windows File Explorer and PowerShell, encrypt documents and email, extend permissions to documents downloaded from SharePoint, protect Teams meetings and chat, protect voicemail, apply to containers such as groups and sites, set the default sharing link type, act as conditions in DLP policies, trigger retention, classify SQL database columns, apply in Power BI, and create protection policies in Microsoft Fabric. An organisation that tries to scope all of that at once produces a design document rather than a deployment.
On taxonomy, where you are starting fresh, Microsoft suggests Personal, Public, General, Confidential and Highly Confidential, with sublabels to group similar labels by category. And a point that gets skipped: give every label a tooltip with specific examples, but do not make it so long users will not read it, because some apps truncate long tooltips.
The instruction underneath all of it is the one I would put first. Always test and tailor your label names and tooltips with the people who have to apply them. A taxonomy that makes sense to the compliance team and not to the people clicking the button gets applied wrongly, and wrong labels are worse than no labels because they carry the authority of a decision.
Two mechanics that make a pilot straightforward
A label is defined once and reused across policies. You do not create separate labels for a pilot group. You create the labels, publish them in a policy scoped to a few users, and when you are ready you create a second policy with the same labels scoped to everyone.
And if your organisation uses administrative units in Microsoft Entra, label policies and auto-labelling policies can be scoped to them. Assign administrative units to members of the Information Protection role groups and those administrators are restricted to the users in those units. Scope a policy to the France administrative unit and it covers all users in France automatically, including new joiners, without anyone maintaining a group.
One exception, and it is easy to miss: protection policies do not support administrative units. If your delegation model depends on them, that is a gap to design around rather than discover.
Our position: adopt the defaults, do not inherit them
In our view the automatic defaults are a genuinely good starting taxonomy, and organisations should mostly keep them. The names are sensible, the sublabel structure is sound, and the protection settings are a reasonable first position. Rebuilding an equivalent from scratch is work that buys very little.
What we would not do is leave them unreviewed. There is a real difference between adopting a default deliberately and inheriting one silently, and it shows up the first time an encrypted document reaches somebody who cannot open it.
In our engagements the labelling problems that cause real disruption are almost never a wrong taxonomy. They are an encryption setting nobody examined, applied to more content than anyone expected, discovered when an external party could not open a file. The classification layer is forgiving. The protection layer is not.
So the sequencing we would argue for is: review what exists, decide explicitly whether to keep it, then turn off what you have not yet decided about. Simulation mode is doing you a favour by not labelling anything yet, and that favour has an expiry date measured in days.
The corollary is that the review is worth doing at the label level rather than the taxonomy level. Take the five names as given, then look only at which of them carry encryption and what that encryption grants. That is a short list, it is where the operational risk sits, and it is a far quicker conversation than designing a classification scheme from nothing.
Where labelling meets the AI question
Worth connecting, because these two conversations arrive together and are usually run by different people. A third belongs beside them: how a DLP policy is designed, because labels are only as useful as the rules that act on them, and the two projects should not be sequenced independently.
Labels are what make Microsoft Purview able to say what a document is, and that determination is what governs whether AI tooling can surface it. An estate with no labels does not have a neutral AI position. It has an unclassified one, which is a different and worse thing.
That is the same finding underneath Copilot readiness: the readiness question is rarely about the AI product and usually about whether the content estate underneath it has been classified and permissioned. A labelling rollout that stalls does not just leave a compliance gap. It blocks the thing the business is actually asking for.
Where to start
Four steps, and the first two take an afternoon between them.
Check whether labels are already published. In the Microsoft Purview portal, look at Information Protection. If labels exist that nobody remembers creating, you are in the inherited position rather than the blank page.
Check for auto-labelling policies in simulation and find out how long they have been there. This is the time-sensitive one, because an unedited policy activates itself. Editing a policy resets it to a 7 day window rather than stopping the clock, so the decision to make is whether you want it on, not whether you want more time.
Confirm the SharePoint and OneDrive prerequisite. Enabling sensitivity labels for SharePoint and OneDrive is a one-time manual step, and it is required before labels work in Office for the web or before auto-labelling policies for those locations function at all. There is a banner on the Information Protection overview page to do it. If you cannot see the banner, it is already done.
Then pick one or two scenarios, per Microsoft’s own advice, and resist the rest until those are live. A sensitivity labels rollout that delivers two scenarios properly is worth considerably more than a design document covering twelve.
Veratas builds and runs security and compliance controls across Microsoft 365, including the Purview information protection layer underneath them.
If labels are appearing in your tenant and nobody can tell you who configured them, talk to our team. Establishing what is actually published takes an afternoon, and it is a considerably better position than finding out when a file will not open.
Frequently asked questions
Do sensitivity labels get created automatically? Yes, for new customers with an eligible Microsoft Purview licence. Microsoft now creates a default set of labels, a publishing policy, client-side auto-labelling and service-side auto-labelling automatically. Existing customers who were not eligible can activate the same defaults from Data Security Posture Management.
What is the default label applied to unlabelled content? General \ All Employees (unrestricted). The default policy also publishes to all users in the tenant and requires users to give a justification before removing a label or lowering its classification.
Will an auto-labelling policy in simulation mode start labelling on its own? Yes. An unedited policy turns itself on once a set number of days pass after simulation completes, normally 7. Tenants onboarded after June 2022 get 25 days the first time, then 7 thereafter. If you are unsure which applies to you, plan for 7.
Why has our SharePoint auto-labelling policy not shown any results? The SharePoint and OneDrive policy waits 25 days before simulation even begins, so that files have time to be created and saved. The Exchange policy starts simulating immediately, which is why the two report on different timelines.
How many labels should we start with? Microsoft suggests Personal, Public, General, Confidential and Highly Confidential where no taxonomy exists, with sublabels for categories. More important than the count is testing the names and tooltips with the people who have to apply them.
Can we scope label policies to part of the organisation? Yes, using Microsoft Entra administrative units, which also restricts which users an Information Protection administrator can manage. Note that protection policies do not support administrative units.
How long do label changes take to reach users? Within four hours in Office apps, and within one hour for Word, Excel and PowerPoint on the web after a refresh. Allow up to 24 hours for changes to replicate to all apps and services.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.