You’ve built the labels: Public, Internal, Confidential and maybe an HR label. Open a Word document, pick one from the Sensitivity menu, and it works. Then you open the Operations site. Years of field tickets, JSAs, FLHAs and inspection reports came across from the old file server, and none of them has a label.
The obvious fix is to set a default label on the library, but that doesn’t do what you’d expect. Your retention plan depends on those labels, so this step has to be right.
Here is the order we’d run it in, with the catches at each step.
Check sensitivity label licensing before you plan anything
Manual labelling, where a user picks a label in Word, Excel or Outlook, comes with Microsoft 365 E3. Almost everything else in this post is a premium feature. Library default labels, service-side auto-labelling and auto-applied retention labels are generally reported to need one of these:
- Microsoft 365 E5
- E5 Compliance
- The E5 Information Protection & Governance add-on on top of E3
- The Purview Suite for Business Premium
Check the Microsoft Purview service description for your exact plan before you commit to a design. If you’re short on licences, you’ll find out fast: setting a library default with PnP PowerShell fails with a licensing error.
On E3 alone, you’re limited to manual labelling. That means no library defaults, no service-side auto-labelling and no auto-applied retention.
Phase 1: default sensitivity labels on the libraries that matter
A default sensitivity label on a document library does two things. It labels files uploaded after you set it. It also labels existing files when someone edits them, if they’re unlabelled or carry a lower-priority label.
It does not touch files nobody edits. As of late September 2026, Microsoft’s documentation still says exactly that.
So phase 1 stops the backlog from growing. Set defaults where new content lands: the HSE library where crews file JSAs, the field ticket library, the contracts library in Finance.
A few prerequisites trip people up:
- Scope the labels to files and other data assets, and publish them to the site admin who will set the default.
- Turn on sensitivity labels for SharePoint and OneDrive (EnableAIPIntegration). This tenant setting can take up to 24 hours to take effect.
- Turn on EnableSensitivityLabelforPDF if you need PDFs labelled. Scanned field tickets are usually PDFs.
- Make sure the library doesn’t have IRM enabled.
- Skip labels that use user-defined permissions, expiring access or Double Key Encryption. Those can’t be library defaults.
- Expect empty files to stay unlabelled.
When you set the default, leave “Extend protection on download, copy, or move” unticked. Microsoft advises against using that preview option here.
The override rules matter later. A library default never overrides a label a user applied by hand, whatever its priority. It does override a lower-priority automatic label or a lower-priority policy default.
Phase 2: label the existing files already there
This is the real gap, and Microsoft is closing it. Message center post MC1477181 announces an opt-in auto-labelling policy. It applies a library’s default label to existing files that are unlabelled, that predate the default, or that carry a lower-priority label.
The policy runs in the background without inspecting content, so a field ticket with no personal or financial data still gets labelled. Rollout is scheduled for early to mid October 2026.
The limits will shape your plan. You get one policy per tenant, covering up to 10 SharePoint sites. A Compliance Administrator or SharePoint Administrator has to set it up. Microsoft hasn’t stated the licensing yet, so plan as if it’s premium.
With only 10 sites, you’ll work in waves. Start with the sites where an unlabelled file would do the most damage. For a drilling contractor or oilfield services company, that usually means HSE, Operations and Finance. Project archives and departmental sites can come later.
Your options until the new policy arrives
Until the feature lands, or if you aren’t on a premium licence, each option has a catch:
| Option | What it does | The catch |
|---|---|---|
| Open and save each file | Triggers the library default | Changes Modified and Modified By. On an archive of JSAs, that wipes out the date you’d use to decide what’s old. |
| Standard service-side auto-labelling | Labels files that match content conditions, such as sensitive information types | Can’t label everything. Most field tickets won’t match any condition. |
| Script it with the Microsoft Graph assignSensitivityLabel API | Works on files nobody opens | Protected API that needs extra approval from Microsoft. Metered, must be enabled first, and charges may apply. Labels applied this way don’t add the label’s watermarks, headers or footers. |
Larger auto-labelling limits on the way
Simulation capacity goes from 4 million to 20 million items. A policy will be able to target up to 1,000 selected sites, or up to 50,000 through adaptive scopes. General availability is planned for late October 2026.
The roadmap also raises daily SharePoint and OneDrive throughput from 100,000 to 500,000 files per tenant, listed for November 2026. Treat that date as provisional.
Phase 3: give people a window to relabel
Once the defaults are in place, the people who know the content can fix what’s wrong. An HR folder inside the Operations site library will have picked up Internal from the library default when it shouldn’t have. An incident investigation file might need Confidential.
SharePoint has no proper bulk relabelling. The Sensitivity column is read-only in Grid view, and when you select several files, the Details pane doesn’t show a label. Users relabel one file at a time, in the Office app or from that file’s details. If a whole folder needs a different label, send it to IT.
Library defaults and the new at-rest policy won’t override a label someone picks by hand. Fixing mistakes after that means relabelling file by file or running a script. So before the window opens:
- Write a one-page guide with examples from your own documents: which label a field ticket gets, which a JSA gets, which a payroll export gets.
- Publish an end date.
- Hold to it.
Phase 4: auto-apply retention labels by sensitivity label
Retention goes last because of how it behaves. An auto-apply retention policy never replaces a retention label that’s already on a file. Once a retention label is auto-applied, nothing changes it automatically: not an edit to the content, not a policy change, not a new policy. If a user relabels a JSA from Internal to Confidential after retention was applied, the retention label stays as it was.
The mechanics are simple:
- Get each sensitivity label’s GUID with Get-Label in Security & Compliance PowerShell.
- For each mapping, create an auto-apply retention policy with the KQL condition
InformationProtectionLabelId:<GUID>. - Run a simulation. It usually finishes in one to two days, and the results expire after seven.
- Publish, then allow up to seven days for labels to appear. In practice it can take longer.
Because this condition uses a searchable property, it reaches existing SharePoint and OneDrive items as well as new ones.
Watch the edges. Files that are only partly indexed can be missed, and draft or never-published items aren’t supported.
Have whoever owns your records schedule sign off on the mapping before anything is published. Correcting it later means manual work.
If a SharePoint migration is still ahead of you
The cheapest time to plan labels is before content moves. When we migrated about 4 TB of DocuShare content to SharePoint Online for E.S. Fox (delivered through Whitecap Canada), we defined the target information architecture before any file moved. That covered the site hierarchy, content types, taxonomy and permission model, and every batch was reconciled against the source before sign-off.
Label and retention design belongs in that same step. Decide which libraries hold what, which label each library carries and which retention label follows from it.
We plan and deliver SharePoint migrations, including the information architecture and permission design that has to come first. See our SharePoint migration work.