Microsoft Purview Blog articles

What stops a service-side auto-labeling rollout from being approved — and how to unblock it

Harish_Sonkusale — Tue, 03 Nov 2026 22:21:54 GMT

The four questions every approver asks

Access	Proof	Reversibility	Scale
“Will labeling change who can open our files?”	“Can we prove what gets labeled — and why?”	“Can we undo it if something goes wrong?”	“Will it finish at our size?”
Scenarios 1 · 2	Scenarios 6 · 8	Scenarios 3 · 7	Scenarios 4 · 5

What unblocks approval

Classify first, encrypt only where tested
Bounded simulations reviewed by data owners
Explicit approval gates
A rollback runbook tested before turn-on

Eight scenarios at a glance — and who needs to say yes

Sr.No	Scenario	What approvers ask	Security	Privacy & compliance	IT operations	Data owners
1	Label data at rest without widening access	Will a label open files to more people?	●	●	◐	◐
2	Sign-off from privacy and security teams	Can we see scope, samples and access impact?	●	●	◐	◐
3	Turn on safely, roll back safely	Can we undo it if it goes wrong?	◐	◐	●	◐
4	Scoping very large tenants	Will it finish at our size, and when?	·	·	●	◐
5	Simulations that never finish	Is it progressing or stuck?	·	·	●	·
6	Trust in what gets labeled	Why was this file labeled?	◐	◐	◐	●
7	Existing labels and conflicting policies	Will it overwrite our labels? Which policy wins?	◐	·	●	◐
8	Proving it works after go-live	Can we defend the numbers?	●	◐	●	◐

leads the decision · ◐ consulted · Illustrative: typical roles — adapt to your organization.

Five gates every policy should clear

A scheduled turn-on date activates a policy even if nobody reviewed the results [Learn ↗], and only Compliance Administrator or Compliance Data Administrator or Information protection can turn a policy on [Learn ↗] — make both part of your change control.

Pre-flight: miss one and the policy runs but labels nothing — with no error [Learn ↗]

✓ Auditing turned on
✓ Sensitivity labels enabled for SharePoint and OneDrive
✓ PDF labeling on, if PDFs are in scope
✓ Auto-labeling available in your region
✓ E5-tier licensing
✓ A sublabel or standalone label — never a parent
✓ Label scoped to files
✓ Encrypting label: “Assign permissions now”, no expiry
✓ Content Viewer role to review matches
✓ Compliance Administrator to turn on

Scenarios 1–4: earn the first “yes”

Each scenario: what worries Contoso, why approval stops, how to unblock it, and what to show approvers.

Scenario 1 · Label data at rest without widening access

Security · Privacy & compliance

“Will a label open our files to more people than today?” — especially files restricted with Information Rights Management (IRM). [Real-world]

Why approval stops

An encrypting label that grants all employees co-owner rights reads as wider access than the IRM already on some files. [Real-world]
Encrypting auto-labels in SharePoint and OneDrive must use “Assign permissions now” with no expiry, and the last modifier becomes the Rights Management owner. [Learn ↗]

How to unblock it

Label broadly with labels that classify but don't encrypt — access doesn't change. [Recommended]
Encrypt only a short list of high-risk sites, using groups that mirror site membership. [Recommended]
Keep IRM-heavy libraries out of client-side auto-labeling: it can replace unlabeled IRM when the user has the Export right; service-side does this only for email. [Learn ↗]

Show approvers: before-and-after access per label — members, guests, web, desktop and downloads.

Two kinds of labels

	Classify only	Classify + encrypt
Access changes?	No	Yes — label permissions apply
Rights Mgmt owner	—	Last person who modified the file
Use it for	Broad coverage at rest	A few access-tested, high-risk sites

Scenario 2 · Sign-off from privacy and security teams

Privacy & compliance · Security · Legal

Privacy and security teams pushed back on a large rollout, worried that labels could loosen existing access controls. [Real-world]

Why approval stops

No single view of scope, samples, access impact and conflicts; regional reviews add steps — Contoso excluded one region. [Real-world]
Simulation can trigger existing alert policies [Learn ↗], and labels alone don't stop Microsoft 365 Copilot from using content — that needs a data loss prevention (DLP) policy. [Learn ↗]

How to unblock it

Limit match previews to the Data Classification Content Viewer role — global admins don't have it by default. [Learn ↗]
Keep auditing on; label applied, changed and removed events are your evidence trail. [Learn ↗]
Respect regional boundaries with admin units or adaptive scopes; scope alert policies during simulation. [Learn ↗]
Reassure reviewers: auto-labeling doesn't change Modified or Modified By. [Learn ↗]

Show approvers: an approval pack each reviewer signs.

The approval pack

✓ Label meanings & encryption
✓ Owner-reviewed sample
✓ Who can view matches
✓ Audit trail
✓ Regional scope
✓ User communications
✓ Approver & pause criteria

Scenario 3 · Turn on safely, roll back safely

IT operations · Security · Business owners

A policy went live without business sign-off, labeled more than 20,000 items and confused users. [Real-world]

Why approval stops

A scheduled turn-on date activates a policy even if nobody reviewed the results. [Learn ↗]
Removing isn't restoring: a removal policy leaves files unlabeled and an active apply policy wins [Learn ↗]; bulk relabeling through Microsoft Graph is a protected, metered API. [Learn ↗]

How to unblock it

Separate authors from approvers — only Compliance Administrator or Compliance Data Administrator can turn a policy on. [Learn ↗]
No unattended turn-on dates; export simulation results before every edit or rerun. [Learn ↗]
Turn on one policy at a time; review daily for the first two weeks. [Recommended]
Test the rollback runbook on a pilot site before turn-on. [Recommended]

Show approvers: named approver, turn-on time, pause criteria and a tested rollback.

Safe rollout, with a way back

Scenario 4 · Scoping very large tenants

IT operations · Data owners

With hundreds of thousands of sites, Contoso couldn't approve a policy nobody could review — or a backlog with no end date. [Real-world]

Why approval stops

Limits shape the design: 500K labeled files a day per tenant (shared), 100 policies, 1,000 hand-picked or 50,000 adaptive-scope sites per policy, 20M matches per simulation. [Learn ↗]
Contoso split one scenario across policies to fit the old ceiling. Adaptive scopes refresh daily [Learn ↗] and can take days to fill. [Real-world]

How to unblock it

Hand-pick sites when the list is maintained; use an adaptive scope when it changes; choose All once quality is proven. [Recommended]
Segment by business unit or region; check scope membership before simulating. [Recommended]
Start under 20M matches, turn on, then expand while the policy stays on.
Location-based protection? Apply library default labels to existing files — one policy, up to 10 sites at a time. [Learn ↗]

Show approvers: a sizing sheet — sites, files, expected matches, days to clear

Work in waves across a large estate

Scenarios 5–8: keep the “yes” after go-live

Most surprises after turn-on trace back to classification, policy overlap or file state — not the policy itself.

Scenario 5 · Simulations that never finish

IT operations

Three policies showed “simulation in progress” for weeks, then expired with no files found; restarts didn't help. [Real-world]

Why approval stops

About 12 hours is typical but isn't a deadline — don't restart just because the count is flat. [Learn ↗]
A missing prerequisite fails silently [Learn ↗]; one of Contoso's adaptive scopes was several times the 50,000-site limit. [Real-world]

How to unblock it

Check Status and Duration, then re-run pre-flight: auditing, label and PDF support, a sublabel (not a parent), label scoped to files. [Learn ↗]
Validate scope size, then restart once — without editing the policy. [Recommended]
“Failed to create job”? Reconnect with Connect-IPPSSession -EnableSearchOnlySession (module 3.9.0+). [Real-world]
No progress after 48–72 hours [Recommended]: open a support case with status, timings and errors. [Learn ↗]

Show approvers: status, start time, duration, and expected / completed / failed locations.

When a simulation won't finish

Scenario 6 · Trust in what gets labeled

Data owners · Privacy & compliance

“Why was this file labeled — and will the next one be wrong?”

Why approval stops

Files kept matching after a detector changed: unchanged files are reclassified only when created or modified, and restarting simulation doesn't reclassify them. [Real-world] [Learn ↗]
Detectors need regular tuning, test tenants lack realistic data, and simulation counts are estimates. [Real-world] [Learn ↗]

How to unblock it

Raise confidence and instance counts, use AND logic and exceptions, and combine detectors. [Learn ↗]
Test detectors with positive and negative samples; refresh older files with on-demand classification — check cost and scope first. [Learn ↗]
Agree precision thresholds before simulating; have data owners review samples. [Recommended]

Show approvers: owner-reviewed precision and “why it matched” for each sampled file.

Three stages — each answers a different question

Scenario 7 · Existing labels and conflicting policies

IT operations · Security · Data owners

“Will this overwrite labels our people chose — and which policy wins?”

Why approval stops

Simulation shows one policy at a time; conflicts resolve only when all active policies run, and an apply policy beats a removal policy. [Learn ↗]
Unexplained “label apply failed” events [Real-world]; one documented cause is an existing label of equal or higher priority. [Learn ↗]

How to unblock it

Use one policy per protection intent and inventory the policies on each location. [Recommended]
Confirm label priority and set the manual-label override option deliberately. [Learn ↗]
Never pick a parent label — the policy runs but labels nothing. [Learn ↗]

Show approvers: the expected final label for representative files.

Will an existing label be replaced?

Label already on the file	Replaced by an auto-labeling policy?
Manual, lower priority	Only with the override option on
Manual, higher priority	No
Automatic or default, lower priority	Yes
Automatic or default, higher priority	No

Scenario 8 · Proving it works after go-live

Security · IT operations · Steering committee

The steering committee wanted counts it could defend, daily failure visibility, and clear conflict and retry attribution. [Real-world]

Why approval stops

Views count different things over different windows; Activity explorer lags 60–90 minutes and doesn't name the policy that labeled an email. [Learn ↗]
Coverage by simulation context shows only after turn-on, for 30 days. Only .docx, .xlsx, .pptx and PDF (opt-in) are labeled — not open files or list attachments, and no visual markings on documents. [Learn ↗]

How to unblock it

Use the Insights tab's 30-day labeled-versus-failed view [Learn ↗] and triage by failure code — transient codes retry on their own. [Learn ↗]
Review coverage after each wave; track unlabeled sensitive content in Data Security Posture Management (DSPM). [Recommended]
Plan for legacy .doc, .xls and .ppt files, which are on the roadmap. [Preview]

Show approvers: labeled, pending and failed by site · precision · backlog days.

Where matched files land — and failure triage

Labeled → sample
Pending → re-check
Failed → read reason
No match → check scope

Retries on its own	FileLocked · FileCheckOut · GetTagsFailure · RmsUnavailable
Needs a fix	UnsupportedFileType → turn on PDF labeling · EncryptedFileNotSupported → remove external encryption · DisabledOrUnsupportedLabel → publish the label
By design	CannotOverrideCurrentLabel · FileNotSupported · FileExtensionNotSupported · ZeroByteFile

The golden path to approval

Seven steps that turn the eight scenarios into one repeatable rollout.

Limits that changed in 2026

Best-case days to clear a labeling backlog

Best case at the daily maximum. Real throughput depends on eligible files, file state, failures and other policies sharing capacity.

Size it before you simulate — worked example (Contoso, illustrative)

Sites in scope	40,000	✓ within 50,000 per adaptive scope
Files in scope	60,000,000	from your storage reports
Expected match rate	10%	from a simulation sample
Expected matches	6,000,000	✓ under the 20,000,000 ceiling
Files labeled per day	300,000	your observed rate, not the maximum
Days to clear the backlog	20	matches ÷ files labeled per day

Useful PowerShell checks

Connect-IPPSSession -EnableSearchOnlySession
Get-AutoSensitivityLabelPolicy -Identity "<policy>" | fl Name,Mode,TestModeStatus, ExpectedLocations,CompletedLocations,FailedLocations
Set-AutoSensitivityLabelPolicy -Identity "<policy>" -StartSimulation $true

Restart a simulation once, without editing the policy, after checking prerequisites and scope size

Top 3 behaviors to plan around

Access impact is yours to verify. Encrypting labels make the last modifier the Rights Management owner, and client-side labeling can replace unlabeled IRM. Test with the exact label. [Learn ↗]
Removing isn't restoring. A removal policy leaves files unlabeled — write and test a rollback runbook before turn-on. [Learn ↗]
Simulation is a single-policy estimate. Conflicts resolve only when all policies run — confirm final labels on samples after turn-on. [Learn ↗]

Top 3 actions that build confidence

Lead with classification-only labels; encrypt a small, access-tested set of sites. [Recommended]
Bring an approval pack: owner-reviewed sample, simulation export, rollback runbook, monitoring owner. [Recommended]
Start bounded, turn on one policy, and expand in waves with daily monitoring. [Recommended]

Automatically apply a sensitivity label ↗ Resolve issues with auto-labeling policies ↗ Resolve auto-labeling failures ↗

Classification and simulation concepts ↗ Review simulation results ↗ Insights tab for auto-labeling ↗

Adaptive scopes ↗ Sensitivity labels in SharePoint and OneDrive ↗ DLP for Microsoft 365 Copilot ↗

Secure by default: reduce false positives ↗ Graph: assign a sensitivity label ↗

Troubleshooting playbook for Auto labelling in SharePoint and OneDrive

Harish_Sonkusale — Mon, 19 Oct 2026 18:38:09 GMT

Auto-labeling policies are how most organizations label the backlog of files at rest, and with the tenant ceiling now up to 500,000 files a day, more teams run them at scale. When a policy doesn't label what you expect, the cause is almost always a missing prerequisite, simulation behavior or the label-precedence rules. I've put the field fixes in one place: run the checklist, find your symptoms, apply the fix. Scope: SharePoint and OneDrive, with Exchange differences called out.

How service-side auto-labeling works

Auto-labeling policies run in the service, not in Office apps. A policy (label + rules + scope) must complete at least one simulation; once it's on, SharePoint and OneDrive label matching files at rest, up to the tenant's daily maximum.

Figure 1. Service-side auto-labeling lifecycle and where to look when it stalls

Pre-flight checklist

Missing any one of these typically makes a policy run without labeling anything, and without an error.

E5/P2-tier license (Microsoft 365 E5, E5 Compliance, E5 Information Protection & Governance, or AIP P2)	PDF support enabled if PDFs are in scope (EnableSensitivityLabelforPDF = True)
Compliance Administrator or Information protection or Compliance Data Administrator role (Data Classification Content Viewer to preview matches)	Label published to at least one user, scoped to “Files & other data assets”, and not a parent label
Auto-labeling available in your region (the page is visible in the Microsoft Purview portal)	Encrypting labels use “Assign permissions now” and never expire; no S/MIME
Unified audit log turned on (required for simulation)	When files are created or edited with SIT, they are classified immediately. However, corner cases to check include Custom SIT created or edited after the file’s last change, and New SIT requiring old files to be checked again; these require on-demand classification.
Sensitivity labels enabled for SharePoint/OneDrive files (EnableAIPIntegration = True)	OneDrive accounts associated with their users (detached accounts aren’t supported)

Limits that matter (October 2026)

Setting or limit	October 2026 value
Auto-labeled files per tenant per day	500,000, shared by all SharePoint/OneDrive policies (was 100,000; rolling out, MC1461154)
Auto-labeling policies per tenant	Up to 100 policies
Explicitly selected locations per policy	1,000 SharePoint sites (was 100)
SharePoint adaptive scope	Up to 50,000 sites (configure with PowerShell)
Simulation size and duration	Up to 20,000,000 matched files (was 4M; MC1469958); ~12 h target
New policy provisioning	~24 h before Turn on / Edit / Delete are available
View coverage report	30 days after the latest simulation completes
Library defaults → existing files	1 policy per tenant, up to 10 sites

Also rolling out: editing an active policy without returning to simulation, Site Template filtering, detected-SIT summaries and a 30-day files-processed chart (MC1469958), the per-policy coverage report (MC1456609), and library default labels for existing files (MC1477181). If your tenant still shows the older values, the rollout hasn't reached it yet.

Symptom-to-fix triage

Symptom	Likely cause	Check → fix
Group 1	Setup and access
1. Auto-labeling page missing, or a policy can't be created or saved	No E5/P2-tier license; legacy portal instead of the Microsoft Purview portal; no Compliance Administrator or Compliance Data Administrator role; region not supported (backend Azure dependency).	Fix the license or role; check region availability. Get-Command New-AutoSensitivityLabelPolicy confirms the cmdlet exists. “No matching database is available” on save is transient: retry; open a case only if it persists 24 h.
Group 2	Simulation
2. Simulation stuck “In progress”, no results, or expired	It runs as a backend search job and finishes within 24 hours. 12 hour was the old typical time with 4M limit, however after upgrading to 20M, it may now take upto 24 hours. Editing the policy mid-run can leave the status stuck; a restart from an older PowerShell session can fail before any job is created.	Check TestModeStatus and LastSimulationCompletionDate; restart from a search-only session (Toolkit A), one policy at a time, no portal edits during the run. Results usually start within 24 h; open a case if matches haven't moved 48–72 h after restart.
3. Simulation finishes with zero matches and no error	Missing pre-flight item; scope misses the content; rule too strict (confidence, instance count, AND/OR logic, unpublished classifier); files unchanged since the SIT was created or edited; “Document property is” needs exact managed-property values (no regex; values with “&” may not match).	Walk the checklist; confirm the SIT exists in Content explorer; test with a new sample file in an in-scope site; run on-demand classification for older files, then rerun.
4. Simulation results incomplete or different after turn-on (also alert storms, duplicates stuck in simulation, Items to review not loading)	Simulation is per policy and point-in-time. It considers the file's existing label but no other policies. Files edited after the run are missed, and Matched items is a sample estimate. Duplicates start in simulation, and Items to review shares DLP's test-mode surface.	List all policies on the same locations or labels and rerun after editing. Above 20,000,000 matches, narrow the scope and rerun. Pause alert policies during simulation, set a duplicate's mode explicitly, and retry Items to review a few hours later.
5. Turn on, Edit or Delete greyed out; no content preview	Still provisioning (~24 h after creation); turn-on needs Compliance Administrator or Compliance Data Administrator; more than 20M matches. Preview needs Data Classification Content Viewer, which Global Admins don't have by default.	Wait 24 h and refresh; assign the role (for preview, e.g. the Information Protection Investigators role group); narrow the policy and restimulate.
Group 3	Turn-on and labeling
6. Policy on, but nothing labeled and no failures	Mode isn't Enable yet (still TestWithoutNotifications, or a scheduled turn-on hasn't happened; a displayed date isn't confirmation); distribution incomplete; label unpublished; files open or checked out; content out of scope.	Run Get-AutoSensitivityLabelPolicy … \| fl Mode,DistributionStatus and -IncludeProgressFeedback; check the Insights tab and Activity explorer. Allow 24 h; open a case at 48 h if every check passes.
7. Matched files not labeled after turn-on	SharePoint/OneDrive couldn't apply the label, so the file keeps its old label or none or user might have labelled manually.	Overview > Labeling failures card (top 3 reasons, 30 days) > Labeling failures tab > file > Details > Failure reason. Many files, same code? Check service health first, then check the failure-code table. Another way is checking history of the file through activity explorer.
8. PDFs not labeled	PDF support is off, so matching PDFs aren't sent for labeling: skipped silently, with no failure and no error.	Check: Get-SPOTenant \| fl EnableSensitivityLabelforPDF. Enable via the “Protect PDFs with Auto-labeling” banner or Set-SPOTenant -EnableSensitivityLabelforPDF $true (per geo in multi-Geo). Signed PDFs unsupported. Still unlabeled when enabled? Open a case.
9. Encrypting label fails, or output looks different	SharePoint/OneDrive policies need “Assign permissions now” with no expiry; S/MIME labels can't be auto applied. By design: no headers, footers or watermarks on documents; the RMS issuer/owner is the last modifier.	Run Get-Label -Identity <label> -IncludeDetailedLabelActions \| fl; switch to a compliant label. Also, by design: removing an encrypting label removes the encryption. Set expectations before rollout.
Group 4	Label outcomes
10. Library default label vs. SIT-based auto-labeling — which label wins?	Two mechanisms target the same file, and label priority decides. A library default overrides a lower-priority automatically applied label, but never a manually applied one. An auto-labeling policy replaces a default label only with a higher-priority label.	Compare priorities (Get-Label \| ft Name,Guid,Priority) and check how the file's label was applied (Activity explorer). Contact Support only if the higher-priority label doesn't win.
11. Existing label not replaced, or replaced unexpectedly	Manual labels stay unless “Replace manually applied labels with lower priority” is on. Automatic or default labels are replaced only by a higher-priority label. Within one parent, the highest-order sublabel wins.	Check how the label was applied (Activity explorer); compare priorities (Get-Label \| ft Name,Guid,Priority); review overlapping policies. Only a remove-label policy leaves files unlabeled.
12. Relabel files from an old label to a new one	The policy UI has no “current label” condition, so use one policy per mapping with the advanced rule “Document property is” InformationProtectionLabelId = <source label GUID>.	The target must outrank the source; also turn on the manual override if the old label was applied manually. Simulate on a small scope first; don't remove the old label first.
13. Too many wrong labels (false positives)	The rule is broader than the data: low confidence or instance count, loose AND/OR logic, or a classifier that doesn't fit.	Pause expansion; sample matches with their detected SITs. Raise confidence and counts, AND multiple SITs, tune a custom SIT, add location or file-type conditions, or split policies; then restimulate.
Group 5	Scale and scope
14. New limits or preview features not showing yet; planning against old limits	Limits rose in Sept–Oct 2026 (500K files/day, 20M simulation, 1,000 sites) and are rolling out tenant by tenant. Editing an active policy without re-simulating is also rolling out.	Previews and limit increases reach tenants in waves, so check the prerequisites and the Message center rollout dates. Track progress with View coverage, a link on the policy that opens a Sankey chart of labeled, pending, failed and not-processed files. It's available for 30 days after the latest simulation completes (LastSimulationCompletionDate) and greys out after that until you rerun simulation.
15. Fewer files labeled per day than expected	500,000/day is a tenant maximum shared by all active SharePoint/OneDrive policies: not per policy, not guaranteed, and 100,000 until the rollout reaches you. Failures cut throughput.	Check the 30-day files-processed chart and -IncludeProgressFeedback; fix dominant failure codes first; collect several days of evidence before opening a case.
16. Site in the adaptive scope, but existing files not labeled	Scope membership doesn't backfill files unchanged since the SIT was created or edited.	Confirm membership and that the scope is attached to the policy. Test a new, a modified and an unchanged file: only unchanged missed → on-demand classification; new or modified missed → open a case.
17. Library default label missing on pre-existing files	Library defaults apply only to new and edited files. Existing files need the auto-labeling option that applies library default labels to existing files (no content inspection).	Confirm the library has a default label and the site is in scope. Limit: one such policy per tenant, up to 10 sites; work in batches. Open, checked-out, locked, unsupported or unsupported-encrypted files are skipped; open a case only if none apply.
18. Some files are never labeled	At rest, only .docx, .pptx, .xlsx and PDF are supported. Open files, list-item attachments and 0-byte files can't be labeled. Exchange labels the email, not the attachments.	By design, no workaround; submit format requests as product feedback.

Reading Labeling Failure Codes

Group	Codes	What to do
Retried automatically	FileLocked, FileCheckOut, GetTagsFailure, RmsUnavailable, Conflict, Transient, UnauthorizedAccessException, TransientErrorStorageConnection, GenericException, SqlThrottled, Unknown_SPException	No action; monitor “Spikes of SqlThrottled, TransientErrorStorageConnection or Unknown_SPException” often match a service incident; contact Support if Unknown_SPException repeats for the same files.
Needs your action	EncryptedFileNotSupported (remove password or non-Microsoft encryption) · DisabledOrUnsupportedLabel (publish or activate the label) · InvalidFileName (rename or shorten) · CancelledByEventHandler (review custom SharePoint event receivers) · QuotaExceeded (free space or raise the quota, then rerun) · UnsupportedFileType (enable PDF labeling; with PDF support off, PDFs may not appear here at all)	Fix is let the policy retry. Until then, the file keeps its previous label or stays unlabeled.
By design	CannotOverrideCurrentLabel (equal or higher-priority label already present) FileNotSupported / FileExtensionNotSupported · ZeroByteFile · DirectoryNotFound / FileNotFound (deleted or moved after classification)	Nothing to fix.

PowerShell toolkit

A · Restart a stuck simulation (ExchangeOnlineManagement 3.9.0+)

Update-Module ExchangeOnlineManagement

Connect-IPPSSession -EnableSearchOnlySession

Get-AutoSensitivityLabelPolicy -Identity "<policy>" -IncludeTestModeResults $true | Format-List

Set-AutoSensitivityLabelPolicy -Identity "<policy>" -StartSimulation $true

B · Distribution and progress

Get-AutoSensitivityLabelPolicy -Identity "<policy>" -DistributionDetail | Format-List Mode,DistributionStatus,DistributionResults

Set-AutoSensitivityLabelPolicy -Identity "<policy>" -RetryDistribution # only if distribution failed; one policy at a time

Get-AutoSensitivityLabelPolicy -Identity "<policy>" -IncludeProgressFeedback # to label / labeled in last 7 days / total

C · Labels and tenant settings

Get-Label | Format-Table Name,Guid,Priority

Get-Label -Identity "<label>" -IncludeDetailedLabelActions | Format-List

Get-SPOTenant | Format-List EnableAIPIntegration,EnableSensitivityLabelforPDF # SharePoint Online Management Shell

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled # Exchange Online PowerShell

Error “Failed to create job. Please close the current PowerShell session and open a new session using Connect-IPPSSession with the -EnableSearchOnlySession flag. This requires using ExchangeOnlineManagement v3.9.0 or higher.” (it may appear only after a timeout) means this case.

Before you open a support case

Open it promptly, because diagnostic data is retained only for a limited time. Include:

Tenant ID	Labeled, pending and failed counts for the same window
Policy name and GUID (shown in the portal URL), mode, and the UTC time it was turned on or last edited	Failure codes with 3–5 example file URLs
Label GUID, priority and encryption settings	Output of the toolkit cmdlets
Rule logic (SITs/classifiers, confidence, counts) and scope (sites or adaptive scope)	Service health check result
Latest simulation match count and LastSimulationCompletionDate	Expected vs. observed behavior and business impact

Good to know - Auto-labeling doesn't change existing Modified, Modified By or date values, in simulation or when labels are applied.

Learn more

Automatically apply a sensitivity label to Microsoft 365 data — https://learn.microsoft.com/en-us/purview/apply-sensitivity-label-automatically
Resolve auto-labeling failures in SharePoint and OneDrive files — https://learn.microsoft.com/en-us/troubleshoot/microsoft-365/purview/sensitivity-labels/auto-labeling-failures-sharepoint-onedrive
Review simulation results for auto-labeling policies — https://learn.microsoft.com/en-us/purview/auto-label-simulation-results
Use the Insights tab to analyze auto-labeling policies — https://learn.microsoft.com/en-us/purview/auto-label-insights-tab
Enable sensitivity labels for files in SharePoint and OneDrive — https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-onedrive-files
Configure a default sensitivity label for a SharePoint document library — https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-default-label
Set-AutoSensitivityLabelPolicy — https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-autosensitivitylabelpolicy

Meet the New Microsoft Purview Classifiers Experience: Your Admin Playbook for Public Preview

Sarahzin_Shane — Thu, 01 Oct 2026 15:01:07 GMT

Microsoft Purview Unified Classification Management Experience

Feature overview and administrator playbook

Overview
The new Classifiers experience brings supported Microsoft Purview classification types into one place where administrators can discover, create, inspect, and manage classifiers. It adds practical visibility into classified-item counts and policy dependencies so administrators can make more informed, lower-risk changes.

Why this experience is important

Classification underpins data protection, data loss prevention, and data security. As classifier inventories grow, administrators need a consistent way to understand what exists, where it is used, and what could be affected by a change.

Centralized visibility Search and filter supported classifiers from a unified inventory instead of navigating separate management locations.	Safer change decisions Review classified-item counts and affected policies before editing or deleting a classifier.
Stronger governance Establish clear ownership, testing, approval, validation, and review expectations.	Better coverage analysis Use matched-item information and Data Explorer to understand where classifications occur and where gaps may exist.

What administrators can do

Discover supported classifier types and understand what the organization already uses.
Create classifiers from a single entry point with type-specific preparation guidance.
Review classified-item counts and inspect policies that depend on a classifier.
Validate matched items across supported data sources and investigate unexpected coverage.
Access Classifiers through Information Protection, Data Loss Prevention, or Data Security Posture Management, depending on tenant availability.

Supported classification capabilities include sensitive information types, named entities, Exact Data Match, trainable classifiers, credentials, document fingerprinting, optical character recognition, and on-demand classification.

How the experience can help

Reduce context switching: Use one inventory to find and inspect supported classifiers.
Understand impact earlier: Identify policy dependencies before a change reaches enforcement.
Improve accountability: Connect classifiers to business owners, policy owners, and reviewers.
Standardize operations: Apply the same lifecycle to routine maintenance, quality improvements, and retirement decisions.

How the admin playbook helps

The companion playbook turns the preview into a practical operating guide. It is designed to be the first place an administrator goes to understand the value of the experience and apply it safely.

Explains the administrator value of unified classifier management.
Provides a continuous Inventory
Offers a decision guide for selecting an appropriate classification method.
Shows how to review policy impact and validate matched items.
Includes customer scenarios and answers to common licensing, permissions, and coexistence questions.

INVENTORY → ASSESS → TEST → APPROVE → CHANGE → VALIDATE → REVIEW

Resources

Public documentation
Current availability, permissions, supported classification capabilities, and product guidance.

Administrator playbook
A self-contained, interactive guide with workflows, screenshots, scenarios, and FAQs.

Scaling classification and labeling: an interactive reference architecture update

MaximeBombardier — Mon, 02 Nov 2026 18:31:43 GMT

In April, I published a set of referential architecture diagrams for Microsoft Purview — Microsoft Purview Referential Architecture Diagrams. They have been useful in workshops and training sessions for a simple reason: one picture is worth a thousand words - attempting to explain the complex in a single image.

Today I'm publishing an update focused on classification and labeling — and on the wave of public previews that make auto-labeling something you can scale across the entire estate with ease.

➡️ Download the interactive architecture on GitHub here. It's a self-contained HTML file - and it's a lot more than this picture!

Why now: auto-labeling scales to the whole estate

The most consequential change is surprisingly small. An auto-labeling policy can now be kept on while you edit it, without re-triggering simulation.

Anyone who has run auto-labeling at scale knows why that matters. Until now, tuning a policy meant turning enforcement off, re-simulating, waiting, and turning it back on — delays every time you refined a rule. That friction made it challenging for organizations from broadening scope as fast as they wanted to. Removing it changes the operating model: you can simulate once with your conditions and expand scope (sites) when you're ready, without hitting the simulation limit.

It arrives alongside a set of previews that lift every ceiling that used to cap the motion:

Capacity is up 5x. Auto-labeling for SharePoint and OneDrive moves from 100,000 to up to 500,000 files per tenant per day (Roadmap ID 567890).
Simulation goes from 4M to 20M items, so you can model against a real estate rather than a sample.
Policy scope gets much bigger. Select up to 1,000 individual SharePoint sites per policy, adaptive scopes support up to 50,000 sites, and you can filter sites by the SiteTemplate property when configuring a policy (Roadmap ID 570445, MC1469958).
Reporting finally tells you what happened. Audit and reporting now summarize the sensitive information types detected when labels are applied, and a new 30-day chart shows files processed per day so you can watch policy throughput.
A per-policy coverage report correlates files processed during enforcement to the latest simulation run — including the files that enforcement processed but simulation never saw (Roadmap ID 568935).
SharePoint library default labels now reach data at rest, applying the library's default label to existing files instead of only new or edited ones (Roadmap ID 559105, MC1477181).

Read together, these are one story: classify and label the whole estate — unblocking your Microsoft 365 Copilot deployment by securing the data that matters to you most. The scalability improvements are on by default, and existing policies continue to function unmodified with no end-user impact.

What the architecture shows

The diagram follows content through five stages, each framed as the question it answers:

User input — where information originates: files, email, Teams messages, files on devices, files in transit, and prompts.
Information is classified — what is it? SITs, Exact Data Match, named entities, document fingerprinting, trainable classifiers, and AI classifiers, with automatic (in-transit) and on-demand (at-rest) classification as the two entry paths.
Labeling files — what is the default security posture, and what did the user intend? Five labeling methods — default label from policy, client-side, library default, service-side auto-labeling, and manual — all converging on one node: the label is applied.
Protection — what do we do about it? DLP (including DLP for Copilot), encryption and usage rights, permissions, label inheritance on Copilot responses, Adaptive Protection, and retention.
Insights — what did we learn? DSPM, Activity and Content Explorer, the unified audit log, DLP alerts, and Insider Risk alerts.

How to use it - it's interactive!

It's a single self-contained HTML file — no dependencies or API call — it works offline.

Click any node to light up its full upstream and downstream path; everything unrelated dims. The detail panel then shows what it feeds from, what it feeds into, what it sees, what it can do, and — the section I'd argue matters most — what it can't do.
Explain runs three guided walkthroughs: Classification vs labels, When is it classified?, and How is it protected? These are my go-to openers for a workshop.
Isolate layer cuts the diagram by control plane — sensitivity label, SITs, classifiers, DLP, encryption, permissions, retention, audit.
Licensing lens filters to Included in E3, E5 only — the delta over E3, or Pay-as-you-go. Use it to answer entitlement questions honestly: where Microsoft publishes no SKU, the node says so instead of guessing. Always confirm entitlements on a quote, not from a diagram.
Overview only strips to titles for a clean read; Fit to width scales the whole thing to the window; light/dark follows your OS or the toggle; it prints cleanly to PDF.
Keyboard: Tab between nodes, Enter to select, Esc to reset.

Interactivity example - Clicking on 'Service-side auto-labeling' will highlight all relevant nodes only

Auto-labeling at scale

If you're standing up auto-labeling at scale, confirm the prerequisites node first — sensitivity labels enabled for Office files in SharePoint and OneDrive, PDF support enabled separately via EnableSensitivityLabelForPDF, auditing on (simulation requires it), labels published to at least one user, and label scope covering Files and/or Emails.

Simulate on your priority sites, review, enforce, then expand scope to more sites or all sites and keep going. Combine that with capabilities already GA — labeling files contextually by site + file types, and overriding manually applied labels — and you can finally clear the backlog of unlabeled files. note: more to come soon for a full deployment guide.

Feedback welcome — if a node is wrong, missing a limitation, or missing a link, tell me in the comments and I'll fix it in the next revision.

Close the gaps: layered data protection with Microsoft Purview across endpoint, browser, and network

Nick-MSFT — Mon, 31 Aug 2026 22:25:14 GMT

Three layers that work like a good team and slides to show it

Data Loss Prevention (DLP) is not new, many use it daily without ever even knowing it, but with AI bringing faster results for productivity so does the risk of data leakage. That is where we take a layered approach, meeting the end user exactly where they are working, on a device, or in a browser, or through that cute cat Office add-in that had to be installed. But don't think of layered protection as three products but more as three specialists who are each excellent at their own job and have the good sense not to try doing everyone else's.

Endpoint DLP lives on the device. USB and removable media, clipboard, print, restricted apps. It carries the deepest classification support, EDM, fingerprinting, OCR, and it works offline, which turns out to be more useful than it sounds at 30,000 feet.
Browser Data Security lives in the session, inline in Edge for Business, checking content before an upload or a form submission. It is the most precise layer for AI prompts and for activity happening inside a managed web app, where nothing else is standing close enough to help.
Network Data Security lives on the wire, via Entra Global Secure Access or a third-party SASE. It handles traffic that never touches a browser at all, desktop apps, Office add-ins quietly phoning a friend, and it is the layer that supports inbound classification of content coming back from cloud and AI apps.

Each one has natural technical boundaries, and those are a design decision rather than an oversight. A network proxy is never going to have strong opinions about a USB stick. An endpoint agent is not positioned to unwrap an encrypted API call from a third-party add-in. Ask any one of them to cover all three domains and you would end up with something slower and less capable at each.

Deployed together, though, the edges line up rather nicely. That is the entire premise of layered protection, and it is what I built this asset to show.

What is actually in the slides

A coverage view across all three layers. Common activities — removable media, RDP sessions, add-in API calls, in-session copy and paste, inbound AI content, classification depth, inline prompt inspection — matched to the layer best positioned for each.

Example file flow from start to finish leveraging each layer where it works best

Six scenario walkthroughs. Realistic situations traced attempt by attempt, including one determined individual who tries three separate routes to get the same file to a consumer AI service. A departing employee and a USB drive. A contractor on a personal laptop. Files headed to personal cloud storage. Each shows which layer engages, and why.

Three attempts at egress blocked by the layer best suited for the task.

Deployment flows you can follow. Prerequisites, permissions, policy names, conditions, actions. Both browser patterns (managed device with unmanaged apps, unmanaged device with managed apps) and both network paths (Entra GSA, and third-party SASE including Netskope and iBoss).

Example policy from start to finish

Four reference architectures. Traffic flow diagrams for each browser and network model — what gets evaluated, where the Purview verdict comes from, where enforcement lands.

Reference architecture showing average flow pattern for sensitive data egree through Network Data Security

Collection policies explained thoroughly. The unsung plumbing underneath all of it. Anatomy, the full flow from event source to Activity Explorer, Insider Risk Management, eDiscovery, and Data Security Posture Management (DSPM), plus the operational details that are much nicer to learn about in a deck than in production.
Collection policy break down from end to end

The parts people keep coming back to

The coverage view is usually where planning conversations start. It gives everyone a shared picture of what is deployed today and what a sensible next step looks like; adding the browser layer to an existing Endpoint DLP footprint, say, or bringing in the network layer to extend coverage to add-ins and desktop apps.

The scenario walkthroughs are where it tends to click for a wider audience. Following one situation through several routes and watching a different layer step in at each turn, does more for the story than any static diagram I have drawn.

And the deployment flows are genuinely meant to be executed. Everyone is written to run against a pilot group first, with Conditional Access in report-only mode in production until you have confirmed the behavior. Please do that part. Your future self will appreciate it.

Who it is for

Architects scoping a deployment. Partners running workshops. Admins with Endpoint DLP already humming along who are working out what comes next. Anyone who would like a single starting point instead of a browser window that has stopped showing page titles.

Take whatever is useful. Pull individual slides into your own narrative or run the whole thing end to end it was built to be borrowed.

Things to keep in mind

Several capabilities in here are in preview or Pay-As-You-Go backed, and network-layer coverage depends on supported SASE/SSE integrations and how traffic is routed. The deck flags this as it goes. Check current availability on Microsoft Learn, and with your SASE provider for the network layer.

Now the fun

The full slide set is at https://aka.ms/purviewlayeredprotection.

It is a living reference, and it will keep evolving with the product. If it helps you plan something, or if there is a scenario you would like to see in the next version, I would love to hear about it.

Enhancements to Device Status API & Logged-In User Email in Endpoint DLP

Harish_Sonkusale — Fri, 05 Jun 2026 19:34:11 GMT

1. The Real‑World Problem Endpoint DLP analyst Faced (What Was Missing Earlier)

Before the introduction of the Device Status API enhancements and logged‑in user visibility, Endpoint DLP teams consistently struggled in below discussed areas:

Device Visibility Was Fragmented and Manual - Customers repeatedly told us:

We know some devices are unhealthy, but we don’t know who owns them.
We export the onboarding table to Excel every week just to understand drift.
By the time we detect a policy issue, the user is already blocked or impacted.

In practice, this meant:

Device onboarding views were static snapshots, not operationally actionable.
Admins relied on manual Excel exports to track onboarding, drift, and health.
Reporting pipelines were brittle and always out of date.

2. Device Status API: Why Customers Asked for This (Beyond “Reporting”)

The Hidden Cost of Excel‑Driven Operations as earlier, customers had to:

Export device onboarding data manually.
Rebuild dashboards every time they needed updated insight.
Repeat this process weekly or even daily for compliance and SOC reviews.

This approach failed at scale and created blind spots during incidents. When a device policy sync failed or appeared unhealthy, admins had no real‑time, view to answer basic questions like:

Is this device configured correctly?
Is the OS or Defender version lagging?
Is the issue widespread or isolated?

3. What the Improvement Unlocks (New Operational Reality)

From Static Views to Continuous Monitoring with the Device Status API:

Device health, configuration status, policy sync state, OS version, and Defender version become query able signals
Customers can power custom reporting and Advanced Hunting queries that are always current
SOC and Endpoint teams finally share a single source of device truth

This fundamentally changes how customers monitor Endpoint DLP not as a setup task, but as a living control plane. The Device Status API directly addresses this gap by making device‑level status continuously available through Advanced Hunting, allowing customers to build living dashboards instead of static reports.

4. The Old Workflow (Customer Pain)

Historically, when a device showed:

Policy Sync Failed
Unhealthy
Configuration mismatch

Admins had to:

Leave the Purview console
Open Microsoft Defender for Endpoint or Intune
Correlate device IDs or names
Identify the user
Start remediation

This context‑switching cost time, accuracy, and confidence.

5. The New Reality: User Context Where It Matters

Admins can now see who is logged in directly on the device onboarding page, aligning Windows with the macOS experience like:

Immediate user context during device issues.
Faster outreach and remediation.
One unified investigative surface.

What used to require three portals and multiple teams now happens in One Place.

6. When Customers Actually Needed This Data (But Didn’t Have It)

This improvement wasn’t driven by curiosity it was driven by failure points in production. Some of the common customer scenarios listed below:

Scenario	Before	Now / After Improvement
Scenario 1: Quarterly Compliance Reviews	Teams exported Excel files days before audits, resulting in stale data. Auditors questioned the reliability of reports.	Advanced Hunting queries power live compliance dashboards. Reports are defensible because the data is always current.
Scenario 2: Incident Post‑Mortems	Teams struggled to answer whether devices were healthy at the time of the incident or if policies were enforced versus just configured. Reviews relied on assumptions.	Device status, policy sync state, and OS/Defender versions are query able facts. Incident reviews shift from guesswork to evidence‑based analysis.
Scenario 3: Silent Policy Drift	Devices drifted due to OS updates, sensor lag, or configuration changes. Issues surfaced only after a DLP violation occurred.	Policy drift becomes detectable before enforcement failures. Endpoint DLP acts as a reliability signal rather than a last‑line alarm.

7. New enhancement on Device Status API

Device status API provides admins with access to device level information to integrate onboarded device information to custom reporting or use in advanced hunting queries.
It has helped admins track down users associated with devices instead reaching out to Entra, on-premises Active Directory, or Intune team.
During troubleshooting, if a device is not receiving policies on time, the device API allows quick identification of the device owner and assists in enabling always-on diagnostics or collecting logs directly from the device via Purview console.

8. Steps to capture User UPN

Admin can find the device status by login to Security.microsoft.com as security admin. Click on Investigation and responses > Hunting > Advanced hunting.
Device data can be found under DLPInfo JSON Column in the Deviceinfo table

3. Once we run above or any custom query as per requirement, you would see below as response.

4. Click on the loggedonuser field and expand the right-side information and look for DLPUPN under inspect record.

9. User login details on the Purview onboarding page

Admins now can see who is currently logged in on the device onboarding page. This update aligns the Windows experience with macOS, allowing admins to respond quickly if necessary.
In the past, when a device displayed a "Policy Sync Failed" or "Unhealthy" status, it was necessary to switch to Microsoft Defender for Endpoint (MDE) or Intune to identify the affected user. With this update, all relevant information is now accessible in a single view, streamlining the process.

Benefits -

Admins gain faster confirmation of device ownership and user context without extra investigation.
It simplifies troubleshooting onboarding or policy issues by surfacing the user alongside other device insights like status and IP.
No impact on users or DLP policies occurs, and it's enabled by default with no action required.

10.Steps to find User UPN on Purview admin console

Final Takeaway: Why This Matters More Than It First Appears

"These enhancements evolve Endpoint DLP from a static, deployment‑centric control into a continuously observable, user‑context aware security signal, significantly reducing investigation time, operational overhead, and trust gaps at scale"

Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance

Inwafula — Tue, 09 Jun 2026 21:17:12 GMT

Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure?

This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies.

Fig 1. AWS console page showing "ExpenseApprovalAgent" details of the Agent blade

Why Purview should be the central policy engine

Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made.

That is the value proposition for Microsoft Purview in cross-cloud AI scenarios.

Purview gives you:

A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content.
A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments.
A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams.
A way to apply data-aware controls to AI interactions, not just to storage locations.

In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well.

The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists.

What this Bedrock agent demonstrates

The sample solution in this blog is a cross-cloud AI pattern:

The frontend is a single-page browser-based chat app.
Users authenticate with Microsoft Entra ID via MSAL.
The backend runs in AWS Lambda.
The model is Amazon Bedrock using Nova 2 Lite.
Microsoft Purview evaluates prompts and model responses for DLP policy violations.

This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure.

The core architecture

Fig. 2 Architectural overview of the solution

As shown above the end-to-end flow follows this pattern:

A user signs in through Microsoft Entra ID from the frontend.
The frontend sends the user's access token and prompt to an API endpoint in AWS.
The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity.
Purview scans the full prompt for sensitive information before the model is called.
If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock.
Purview scans the model response before it is returned to the user.
The frontend shows the result along with a Purview evaluation badge.

That gives you two strong governance controls:

In-line data loss prevention enforcement, which can block risky requests before they ever reach the model.
Response-time enforcement, which can stop sensitive data from being returned even if a model generates it.

The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running.

Why this pattern is useful for security, governance, and compliance teams

There are three reasons this pattern is worth paying attention to.

First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point.
Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows.
Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough.

Policy definition in Purview

Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy

Collection policy

2. DLP policy

Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples

To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples

Once deployed, you will have:

An AWS Lambda function that calls Amazon Bedrock.
A browser frontend that authenticates with Microsoft Entra ID.
Microsoft Purview evaluating both prompts and responses.
A demo flow where safe prompts succeed and sensitive prompts are blocked.

With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview.

Minimal code integration requirements using the SDK

Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model.

Results of Purview’s verdict presented to user in the App UI

Review governance evidence in Purview Data Security Posture Management

Summary

The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds.

That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented.

Additional resources

Configure Microsoft Purview - purview-sdk | Microsoft Learn

Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft Learn

From Oversharing to Enforcement: A Practical Guide to AI Data Security with Microsoft Purview

George Smyrlis — Thu, 23 Apr 2026 14:58:26 GMT

Why AI Changed the Data Security Problem

AI does not create entirely new categories of risk—it supercharges existing ones. Traditional data leakage stems from ordinary behavior: sharing a document too broadly, sending an email to the wrong person, copying regulated data to an uncontrolled device. Generative AI amplifies all of these because of the power and speed with which it can proactively surface content that may be obsolete, over-permissioned, or ungoverned. DSPM exists to help with exactly this challenge: it continuously scans your environment to identify sensitive data, assess risk, and recommend actions to reduce exposure.

Oversharing at Scale
Before AI, an overshared SharePoint file might sit unnoticed. Now, Copilot can summarize it in response to a casual prompt, distributing its contents far beyond the original audience.
Prompt Leakage
Users can inadvertently expose sensitive information—financial account numbers, health records, project code names—simply by typing them into a Copilot prompt. Because AI interactions feel conversational, users tend to drop their guard.
Shadow AI
Beyond sanctioned tools, employees experiment with unapproved AI services.
Autonomous Agents

Autonomous agents expand the data security threat surface by acting independently on sensitive information across systems and boundaries. Their ability to access and share data without direct user interaction increases the risk of oversharing, exfiltration, and unauthorized access, while also introducing complex behavior patterns that are harder to monitor, govern, and control using traditional security models.

What Microsoft Purview Now Brings Together

Data Security Posture Management (DSPM)

DSPM consolidates insights from Data Loss Prevention (DLP), Insider Risk Management, Information Protection, and Data Security Investigations into a single view for monitoring data risks, policy coverage, and posture trends. Now also in Public Preview, DSPM extends coverage to third-party SaaS and IaaS platforms such as Google Cloud Platform, Snowflake, and Databricks, and integrates with partner solutions including Cyera, BigID, and OneTrust for comprehensive risk insights.

A central innovation in this version is data security objectives—prominent, selectable cards that each represent a specific security goal. Selecting an objective guides administrators through an end-to-end workflow that groups together the most relevant Purview solutions—information protection, DLP, Insider Risk Management, and eDiscovery—so teams can focus on achieving a specific data security outcome rather than navigating separate solutions.

Each Outcome card displays key metrics such as the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. Within each outcome, DSPM surfaces suggested prioritized actions—applying sensitivity labels, configuring DLP policies, or investigating alerts—all tailored to the organization's data. Administrators can take action directly from the workflow, including remediating oversharing, configuring one-click policies, or launching investigations into suspicious activity.

DLP Integration for AI Interactions

DLP is one of the core solutions integrated into DSPM's unified approach. The Activity Explorer's AI activities tab captures events where DLP rules were matched during AI interactions—including prompts, responses, and browsing to generative AI sites. DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to help prevent incidents before they happen.

AI Observability and Agent Governance

Dedicated dashboards and metrics monitor risks associated with AI apps and agents. AI observability enables tracking of agent-specific activities—oversharing, exfiltration, and unusual access patterns—across both Microsoft and third-party environments. Enhanced reporting provides advanced filtering and customizable views, supporting granular analysis of sensitive data usage, DLP activity, and posture trends. Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response.

AI-Powered Security Operations

DSPM not only secures and governs AI apps and agents but also uses Microsoft Security Copilot and AI agents to help secure and govern data. AI analyzes access patterns, sharing behaviors, and policy gaps to surface actionable risks and can detect unusual activity such as excessive sharing or suspicious downloads. Under administrator guidance, AI agents can take direct action on detected risks—removing public sharing links, applying DLP policies, or revoking permissions. These actions are always audited. To streamline investigations, AI-driven triage agents review alerts from DLP and Insider Risk Management solutions, filtering out noise and highlighting the most critical threats.

Three Practical Starting Points

For many organizations adopting generative AI, the biggest hurdle isn't recognizing new risks—it's figuring out where to begin. A "boil the ocean" approach can stall progress, while tackling a few targeted areas delivers quicker wins.

The best early moves are those that reduce exposure quickly, improve visibility, and build a foundation for stronger governance over time.

Starting Point 1: Enable prompt-level protection for Microsoft 365 Copilot

An effective first step is to put guardrails on the prompts users enter into AI. Microsoft Purview DLP allows administrators to restrict Microsoft 365 Copilot and Copilot Chat from processing prompts that contain sensitive information. In practice, users are often more comfortable pasting data into a chat prompt than attaching it to an email, which means a well-meaning employee could inadvertently feed a confidential file or personal data into Copilot.

Enabling prompt-level DLP creates an immediate safety net: if a user's prompt includes, say, a credit card number or a customer's national ID, Copilot will detect it and refuse to process or share that content. DSPM provides suggested prioritized actions—including configuring DLP policies—that can be activated directly from the workflow, and recommended policies can start in simulation mode. Simulation mode lets you see what would have been blocked or flagged, without actually interrupting users, so you can fine-tune the policy and prepare your helpdesk for any questions. Once you're comfortable with the results, switching to enforcement mode will actively block disallowed prompts and log those events for review.

By activating this one control, you've significantly reduced the most immediate oversharing risk—the "oops, I pasted the wrong data" scenario—within hours of starting your AI governance program.

Tradeoff: Simulation mode provides safety but delays enforcement. For organizations with imminent regulatory exposure, consider shortening the simulation window and monitoring alert volumes closely.

Starting Point 2: Gain visibility into shadow AI usage before broad enforcement

The second step is to illuminate what's happening in the shadows. Before rushing into blocking every unsanctioned AI tool, it's crucial to understand how and where AI is being used across the organization. In most enterprises, there's an official layer of AI usage and an often larger, unofficial layer—employees experimenting with free online AI chatbots, writing assistants, or code generators.

DSPM provides this visibility. The Discover > Apps and agents dashboard shows AI apps used across the organization, including the top 20 most recently used agents, with details about sensitive data they accessed and how they are protected by Purview policies.

The AI observability page provides a broader inventory of all AI apps and agents with activity in the last 30 days, including how many are high risk and the total with sensitive interactions. The Activity Explorer's AI activities tab shows when users browsed to generative AI sites, the prompts and responses involved, whether sensitive information was present, and whether DLP rules were matched. Armed with this insight, you can make informed decisions. If you discover that the majority of "AI consumption" comes from just two external apps, you might focus your immediate controls on those two. Conversely, if the data shows most unsanctioned usage is low-risk, you might decide to monitor rather than block it.

The key is visibility first, enforcement second—letting real data guide where to tighten controls versus where to offer secure alternatives.

Tradeoff: Visibility without timely follow-through can create a false sense of security. Set a defined window (e.g., 30 days) after which findings must translate into at least one concrete policy action.

Starting Point 3: Operationalize DSPM objectives for Copilot

A stronger third starting point is to use DSPM as your operational guide, not just a dashboard of charts. DPSM introduces data security objectives—each one a focused end-to-end workflow for a specific outcome. Rather than configuring individual features in isolation, you select an objective and let Purview navigate you through achieving that outcome with the relevant tools.

For generative AI, the key objective to leverage early is "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions". By selecting this objective in the Purview portal, you're effectively telling Purview, "help me implement whatever is needed to make Copilot safe with our data." The DSPM interface then groups together the critical pieces: it may prompt you to enable a DLP policy, suggest applying or refining sensitivity labels on content, or surface an Insider Risk Management policy template for detecting AI-related risky behavior. It also surfaces metrics so you can track progress—for example, the percentage of data covered by policies, or the number of risky sharing incidents that have been remediated.

Using DSPM objectives keeps your team aligned on a clear goal from day one. It shifts the conversation from "what knobs do we turn on?" to "how do we achieve this outcome?" You follow a guided plan curated by the platform's intelligence rather than navigating five different admin pages and hoping it adds up to protection.

Tradeoff: Objectives streamline the path but can obscure the underlying complexity. Teams should periodically step outside the guided workflow to review the full policy landscape and ensure no coverage gaps exist between objectives.

From Visibility to Remediation: Turning Insights into Action

Automated Remediation at Scale

DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to prevent incidents before they happen. Under administrator guidance, AI agents within DSPM can take direct action on detected risks—removing sharing links, applying DLP policies, or revoking permissions—and these actions are always audited. This moves the operating model from manual, one-at-a-time fixes to systematic, policy-driven remediation.

Closing the Loop: From Risk to Standing Policy

DSPM's data security objectives surface suggested prioritized actions such as applying sensitivity labels, configuring DLP policies, or investigating alerts, all tailored to the organization's data. Reporting and analytics are organized by outcome, making it easier to identify and report improvements, compliance, and risk reduction. This turns recurring findings into standing preventive controls. Instead of re-running assessments and manually fixing the same patterns, administrators create durable policies that enforce the desired state going forward.

Alert-Driven Investigation and Tuning

Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response. Integrated investigation and forensics tools support rapid incident response and root cause analysis for data security events. Impact prediction visuals and progress tracking for remediation steps are surfaced throughout DSPM, enabling administrators to quantify the effect of their actions and adjust course.

The closed-loop process is: Discover (DSPM scans and risk assessments) → Remediate (automated actions and bulk fixes) → Prevent (create or tighten DLP and auto-labeling policies) → Monitor (alert review, investigation, and policy tuning).

What "Good" Looks Like in a Regulated or Risk-Aware Organization

A mature AI governance posture is defined by measurable outcomes and sustainable operating rhythms—not feature count:

Clear, communicated AI usage policies. Users know what is and is not acceptable in AI interactions because the tools reinforce the rules. DLP policy tips delivered at the moment of a violation are a primary training mechanism—they remind users in context why their prompt was blocked and what to do instead.
Measured enablement over blanket bans. Leading organizations allow Copilot with appropriate controls and restrict only truly unacceptable scenarios. Policies deployed initially in simulation mode provide data to calibrate enforcement thresholds before blocking. This avoids productivity backlash while preserving security posture.

High data hygiene and classification rates. Purview's AI protections depend heavily on sensitivity labels. If everything is unlabeled or "General," label-based controls have nothing to act on. Mature organizations invest in auto-labeling and mandatory labeling to close this gap before deploying AI at scale. DSPM's data security objectives include suggested actions such as applying sensitivity labels, directly tying classification to governance outcomes.

Quantifiable risk reduction. Security leadership can produce metrics from Purview that show trend lines: DSPM Outcome cards display the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. These figures feed directly into compliance reporting and audit evidence. Key metrics are tracked over time, supporting continuous improvement of the organization's data security posture.

Cross-functional governance. AI governance is not a solo IT Security effort. Stakeholders from security, compliance, legal, and business units review AI usage patterns, discuss policy tuning, and evaluate new Purview capabilities as they release. Role-based access controls within DSPM provide granular access to features and AI content for delegated administration and compliance, enabling this cross-functional model without overexposing sensitive data to every participant.

Tradeoff: Strict enforcement can frustrate power users and slow AI adoption. Organizations should explicitly define escalation paths—if a legitimate use case is blocked by DLP, there must be a fast process to review and adjust, rather than a permanent "no."

A Phased Adoption Model

Phase	Focus	Key Activities
Phase 1 — Quick Wins (weeks)	Visibility and baseline safeguards	Enable prompt-level DLP for Copilot in simulation mode. Run first DSPM data risk assessment for oversharing. Enable shadow AI discovery via DSPM's Apps and agents dashboard and AI observability page. Start from the DSPM objective "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions."
Phase 2 — Broad Enforcement (months)	Acting on findings	Switch DLP policies from simulation to enforcement. Use automated remediation actions (removing sharing links, applying DLP policies, revoking permissions). Expand sensitive information type definitions and add custom types. Rollout user communications explaining new controls and escalation paths.
Phase 3 — Mature Governance (ongoing)	Continuous improvement and AI-powered operations	Leverage AI-driven triage agents to filter alert noise and highlight critical threats. Conduct periodic DSPM posture reviews using Outcome card metrics. Tune policies based on impact prediction visuals and progress tracking. Extend protections to new AI apps and agents as they are adopted—DSPM's AI observability tracks agent-specific activities across Microsoft and third-party environments. Formalize cross-functional AI governance cadence.

*Phase 1 should take weeks, not months—the objective is to establish a baseline before risk accumulates.

*Phase 2 is where enforcement generates measurable risk reduction.

*Phase 3 is ongoing: as Microsoft continues extending Purview to additional AI apps and agent types, the governance framework must evolve in tandem.

The DSPM preview's integration with third-party SaaS and IaaS platforms (Google Cloud Platform, Snowflake, Databricks) and partner solutions (Cyera, BigID, OneTrust) means the governance perimeter can expand alongside the organization's AI footprint.

Conclusion

AI adoption and data protection are not opposing forces. Microsoft Purview now provides the visibility, policy controls, and remediation workflows to move from discovering AI risk to actively governing Copilot, third-party AI apps, and agents at scale. DSPM surfaces oversharing and AI usage patterns through unified dashboards, data risk assessments, and AI observability. DLP blocks sensitive data in prompts and restricts AI access to labeled content. Insider Risk Management detects adversarial AI behavior. AI-driven triage and remediation agents close the gap between identifying a problem and fixing it—with every automated action audited.

The path forward starts with practical actions: enable prompt-level DLP, illuminate shadow AI usage, and operationalize DSPM's "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective. From there, enforce what you find, measure the results using DSPM's outcome-based metrics, and progressively mature your governance posture.

Organizations that operationalize this loop will be in a strong position: able to say, "We use AI to work smarter—and we have the safeguards in place to do it safely."

Deploy scalable ring‑fenced Purview operations with Administrative Units

MaximeBombardier — Sat, 18 Apr 2026 01:22:01 GMT

As Microsoft Purview deployments mature, many organisations encounter the same scaling challenge: how do you decentralize operations without fragmenting governance or losing visibility? Administrative Units (AUs) provide a native way to solve this by enabling ring‑fenced operations—allowing teams to operate independently within clearly defined boundaries, while preserving central oversight.

This post focuses on the why behind using Administrative Units in Microsoft Purview, with a particular emphasis on scalable, ring‑fenced operations. We’ll walk through three reference architectures that illustrate how Administrative Units support real‑world operating models—without requiring multiple tenants or separate DLP platforms.

note: this article and visuals will focus on Administrative Units support in Purview Data Loss Prevention. However, Administrative Units are supported in additional solutions of Microsoft Purview. Refer to Administrative units in Microsoft Purview | Microsoft Learn for more details and support.

Why Administrative Units matter for scalable operations

Many large organisations operate with decentralized compliance and DLP teams, often aligned to regions, business units, or regulated functions. Historically, this led to one of two sub‑optimal patterns:

Multiple, disconnected DLP solutions or tenants
Centralized teams managing policies and alerts for parts of the business they don’t own

Administrative Units change this model by allowing organisations to:

Partition users (and supported resources) into logical units
Assign restricted administrators who can only see and act within their unit
Apply both global and AU‑scoped policies together, with predictable behavior

From a Purview perspective, this enables true business function autonomy, enforced through RBAC and data visibility boundaries, while keeping global services—such as classification—centralized.

Reference architecture 1: Layered governance with ring‑fenced operations

Scenario

An organisation wants to migrate from multiple legacy DLP solutions into Microsoft Purview while preserving independent operations for each business function or region.

Architecture highlights

This model introduces three distinct layers:

Central governance (Global)
- Global administrators define baseline policies applicable across the tenant
- Shared services such as classifiers and reusable components remain central
- Central teams retain cross‑tenant monitoring and reporting capabilities
Administrative Units (per business function)
- Each business function or region is mapped to an Administrative Unit
- RBAC, policy visibility, and alert management are strictly scoped to the AU
- Policies created here only affect users within that unit
Business function‑level operations
- Scoped DLP admins manage local policies
- Alerts and incidents are handled by the owning team
- Controls can be tuned to meet specific regulatory or operational needs

Why this matters

This architecture enables a phased migration:

Start with a single entity
Gradually scale across additional business functions
Avoid policy sprawl by consolidating and retiring legacy configurations

Crucially, tenant‑wide limits and global services remain unchanged, ensuring consistent performance as scale increases.

Reference architecture 2: Ring‑fencing user activity visibility to sub‑business functions

Scenario

“We have dedicated DLP analysts for executives. DLP alerts and activities for these users must only be visible to that team.”

Architecture highlights

This model refines the first architecture and allowing to have DLP analysts for a subset of users only.
Executive users are placed into a dedicated Administrative Unit representing a subset of users of a business unit.
Policies can be published to multiple Administrative Units (ex: Americas + Americas - Execs)

In this model:

Some DLP administrators may be assigned to multiple AUs so they can publish policies across them
Users must belong to a single AU to ensure clean visibility boundaries

Why this matters

This pattern is particularly effective for:

Executive monitoring
HR or Legal teams
Highly sensitive populations

It delivers strict separation of duties without duplicating policies or creating isolated tenants, and aligns with how Purview scopes alerts, activity explorer, and audit data when Administrative Units are used.

Reference architecture 3: User activity visibility for multi‑AU users

Scenario

Some users operate across multiple business functions—for example, executives or shared service leaders—while still requiring controlled visibility for analysts.

Architecture highlights

User activities are stamped with the sum of all Administrative Units the user belonged to at the time of the activity
Scoped DLP administrators:
- Can only create policies affecting users within their assigned AU. However the sum of their policies will be applicable.
Scoped DLP analysts:
- See all activities for users in their AU, even if those activities were generated by policies scoped to a different AU.

Why this matters

This model ensures:

No loss of investigative context for analysts
Predictable visibility when users span multiple organizational boundaries
Continued enforcement of AU‑based separation of duties

It also reinforces a key principle: Administrative Units control visibility and management scope — not the existence of the underlying activity data. Once a user's in scope of a policy, its related activities/alerts are visible to DLP analysts allowed to review this user's activities.

When not to use Administrative Units

Administrative Units are a powerful enabler for decentralized, ring‑fenced operations—but they are not required in every Purview deployment.

You may choose not to introduce Administrative Units in the following situations:

Single, centralized compliance team. If one team owns all policy creation, alert triage, and investigations across the organisation—and there is no requirement to restrict visibility—Administrative Units add limited value. In this model, global role groups already provide sufficient control.

No need for visibility or management separation. Administrative Units are primarily about scoping visibility and permissions. If all administrators are expected to see all users, alerts, and activities, AU‑based scoping may introduce unnecessary complexity without operational benefit.

Early or small‑scale Purview deployments. Organisations at an early stage of Purview adoption—running a small number of global policies—may find it simpler to start without AUs and introduce them later as operating models mature. Administrative Units do not change tenant limits or global services, so adoption can be phased over time.

Requirements driven purely by policy targeting. If the primary requirement is targeting users dynamically for policy application (rather than restricting administrator access or visibility), adaptive scopes alone may be sufficient. Administrative Units become relevant when who can see and manage data is as important as which users are in scope.

In short, Administrative Units are best introduced when organisations need to scale operations with clear ownership boundaries, not simply to organise users.

Centralized vs. Decentralized Functions in a Ring‑Fenced Operating Model

A scalable Microsoft Purview operating model relies on a deliberate split between functions that remain centralized at the tenant level and those that are decentralized to business functions or regions via Administrative Units (AUs). This balance enables autonomy without fragmentation, preserving global consistency while allowing teams to operate independently within defined boundaries.

Functions that Remain Centralized

Certain capabilities are intentionally retained at the global (tenant) level to ensure consistency, performance, and governance across the organisation. These functions are not delegated to Administrative Units:

Global governance and baseline policy definition
Central teams define tenant‑wide baseline policies that apply consistently across all users, regardless of AU membership. This ensures minimum protection standards and avoids divergent interpretations of risk.
Shared services and reusable components
Core services such as classifiers and other reusable components remain centralized to prevent duplication, reduce administrative overhead, and maintain consistent detection behavior across the tenant.
Cross‑tenant monitoring and reporting
Central teams retain visibility across Administrative Units for monitoring, reporting, and oversight purposes, ensuring that decentralization does not result in blind spots at the organizational level.
Tenant‑wide limits and platform behavior
Administrative Units do not alter tenant‑wide service limits or global platform characteristics. Keeping these aspects centralized ensures predictable performance and scalability as additional business functions are onboarded.

Functions that Are Decentralized via Administrative Units

Operational responsibility is decentralized to business functions or regions by mapping them to Administrative Units, with strict scoping enforced through RBAC and data visibility boundaries:

Policy creation and management scoped to the AU
Business function teams can create and manage policies that only affect users within their Administrative Unit, allowing controls to be tailored to local regulatory or operational requirements without impacting other parts of the organisation.
Scoped visibility of alerts, activities, and incidents
Administrators and analysts assigned to an AU can only see alerts, activities, and incidents for users in that unit. This enforces separation of duties and prevents unintended access to sensitive data belonging to other functions.
Local alert handling and incident response
Decentralized teams own the investigation and remediation of alerts generated within their AU, enabling faster response times and clearer accountability.
Operational tuning per business function
Controls can be adjusted within an AU to reflect specific risk tolerances, regulatory obligations, or operational realities, without creating policy sprawl or requiring separate tenants.

Why This Split Matters

By clearly separating centralized governance and shared services from decentralized, AU‑scoped operations, organisations can scale Purview deployments in a phased and controlled manner—starting with a single business function and expanding over time—while maintaining consistent governance, visibility, and performance across the tenant.

Key takeaways

Administrative Units in Microsoft Purview are not just a permissions feature—they are an operating model enabler. Used correctly, they allow organisations to:

Scale decentralized operations with confidence
Enforce ring‑fenced visibility and management boundaries
Combine global consistency with local autonomy

For organisations planning large‑scale Purview deployments or consolidating legacy compliance tooling, Administrative Units provide a foundational architecture for sustainable growth.

Learn more

Data Security Posture Reports (Custom Workspace and Charts)

Sarahzin_Shane — Wed, 15 Apr 2026 17:10:30 GMT

For more insights on OOB Reports, check out this article.

Overview: NOW IN PUBLIC PREVIEW

Microsoft Purview Posture Reports provide a clear, outcome‑based view of how effectively data protection controls, such as Sensitivity Labels and Data Loss Prevention (DLP) policies, are working across Microsoft 365. Rather than focusing on individual alerts or isolated events, Posture Reports help organizations answer a higher‑level, executive‑ready question:

Are our data protection controls consistently applied and actually reducing risk at scale?

Posture Reports transform complex telemetry from Audit logs, Activity Explorer, and policy enforcement into measurable, defensible insights that security, compliance, and business leaders can act on with confidence. Building on the out‑of‑the‑box experience, Custom Posture Reports enable teams to create scenario‑specific views tailored to their organization’s risk priorities.

Key capabilities include:

Custom dashboards with drag‑and‑drop sections and cards
Built‑in and custom metric or chart cards powered by Activity Explorer data
Flexible filtering to support focused investigations and reporting

Tips:

Start with clear questions, then choose cards that answer them
Avoid overcrowding reports; fewer, well‑chosen cards are more effective
Use metric cards for status, analytics cards for understanding
Treat custom reports as living assets, iterate as needs evolve

This allows security teams to move beyond one‑size‑fits‑all reporting and build views aligned to their unique data protection strategy.

Preview note: As this feature is in Preview, capabilities, terminology, and UX may change, and not all scenarios are fully documented yet.

Key Concepts

Where can I access these reports?

Three Locations:

Purview.microsoft.com -> Information Protection -> Reports

Purview.microsoft.com -> Data Loss Prevention -> Posture Reports

Purview.microsoft.com -> DSPM -> Reports (CUSTOM COMING)

What is a Custom Report?

A Custom Report is a user‑created report container where you assemble one or more cards to visualize Information Protection–related data (for example, labeling, classification, or protection activity). Unlike the built‑in reports, custom reports are designed to be adaptable to different audiences and questions.

Typical use cases include:

Tracking adoption of sensitivity labels over time
Monitoring where sensitive data is most concentrated
Creating executive‑friendly, KPI‑style summaries
Building analyst views for deeper investigation

Core Actions in the Custom Reports Experience

Add Report creates a new, empty report canvas. This is the starting point where you define:

The report name and purpose
Create custom reports with your preferred cards and analytics.

Add section is used to create a logical grouping within a custom report. A section acts as a container that helps organize cards on the report canvas into meaningful groupings based on purpose, audience, or storyline.

What a section does	How sections are used
Provides structure to a report by grouping related cards together Improves readability and navigation, especially in reports with multiple cards Helps separate different analytical themes within the same report	A report can contain one or more sections Each section can include multiple cards (metric cards, chart cards, analytics cards, or custom cards) Sections are added before cards, serving as the layout framework for the report

Add Card lets you place a visualization or metric onto the report canvas. Each card answers a specific question, such as “How much data is labeled Confidential?” or “Where is sensitive content growing fastest?”

Cards are the building blocks of custom reports and can be mixed and matched within the same report.

Permissions: in order to create these reports, you must have permissions to create labels and DLP policies.

Built‑in (OOB – Out of the Box) cards:

Custom reports include two built‑in card types that can be added to sections:

Metric cards – predefined cards used to display key metrics and trends
Analytics cards – predefined cards that provide deeper analytical insights

Note: In addition to built‑in cards, you can add custom cards (such as metric‑based or chart‑based custom cards) to tailor the report to your scenario.

What is a Metric Card?	What is an Analytic Card?
Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context.	Analytics cards provide richer visualizations that help users explore patterns and trends in the data.
What they do: A Metric card is used to create a card that pairs a primary metric with its historical trend This allows users to answer not just “What is the value?” but also “Is it improving or declining?” Metric cards are commonly used for adoption, growth, and compliance health indicators These cards focus on showing trends over time	What they do: Show distributions, breakdowns, or trends over time Enable comparison across locations, labels, or workloads Support investigation and analysis rather than just reporting These are useful when you need a visual representation rather than a single metric. Display data using charts such as bars, lines, or other visual formats

What is a Metric Card?

What is an Analytic Card?

Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context.

Analytics cards provide richer visualizations that help users explore patterns and trends in the data.

What they do:

A Metric card is used to create a card that pairs a primary metric with its historical trend
This allows users to answer not just “What is the value?” but also “Is it improving or declining?”
Metric cards are commonly used for adoption, growth, and compliance health indicators
These cards focus on showing trends over time

What they do:

Show distributions, breakdowns, or trends over time
Enable comparison across locations, labels, or workloads
Support investigation and analysis rather than just reporting
These are useful when you need a visual representation rather than a single metric.
Display data using charts such as bars, lines, or other visual formats

Custom cards allow you to define tailored views aligned to your organization’s unique questions.

What they do:

Focus on specific scenarios not covered by default cards
Combine dimensions or filters relevant to your business context
Adapt reporting to regulatory, regional, or operational needs

When to use them:

Organization‑specific KPIs
Regulatory or audit‑driven reporting
Advanced scenarios that go beyond standard dashboards

Custom cards are especially useful for mature programs where built‑in reports are no longer sufficient on their own.

Custom Card Configuration

The following example illustrates how a metric‑based custom card can be configured to track adoption trends.

Scenario: Track adoption of the Confidential sensitivity label over the last 30 days.

Card type:

Custom card (built from a Metric card)

Metric configuration	Filters applied	What this card shows
Metric: Number of items labeled Confidential Time range: Last 30 days (custom) Display format: Compound (shows total count with trend direction)	Sensitivity label: Confidential Workload: SharePoint	The current total number of items labeled Confidential Whether labeling activity is increasing or decreasing over the last 30 days A focused view of adoption for a specific label and workload

This type of custom card is well‑suited for adoption tracking, executive summaries, and ongoing compliance health monitoring.

Metric card configuration:

Metric cards currently surface up to 7 days of data, providing recent context for the selected metric. Custom surfaces up to the last 30 days of data.
You can choose different display formats, such as:
Number – a raw count or value
Percentage – a proportional view of the metric
Compound – a combination of value and trend for quick interpretation
You can apply filters to limit the data set to specific criteria (for example, a particular label, location, or workload), allowing the metric to reflect a targeted scenario rather than all data

Chart cards are used to visualize data as a graphical chart and can be created as custom cards when you need a visual representation rather than a single metric.

Click on Chart Card and under Chart card configuration, select the primary activities: Sensitivity Label

Then define the Chart Type

Based on the configuration options shown in the UI, the following chart types are available:

Vertical bar – compares values across categories using vertical bars; commonly used for side‑by‑side comparisons
Horizontal bar – compares values across categories using horizontal bars; useful when category labels are long
Pie – shows proportional distribution of values across categories
Donut – similar to a pie chart, with a central area that improves readability
Line chart – visualizes trends or changes over time

Selecting the appropriate chart type helps ensure the custom card clearly communicates the intended insight and improves overall report readability.

These cards are commonly used for trend analysis, distribution views, and comparative reporting. Both make patterns easier to understand.

Real World Example

The business goal this report is addressing is to prove security value and risk reduction, especially to leadership and stakeholders, by tying data protection investments to measurable outcomes.

Primary Business Goal: demonstrate that the organization’s data protection controls are effective in reducing financial data risk.
The report shows that sensitive financial data is not only being found, but consistently labeled and enforced through DLP, validating that controls are working as intended.

Supporting Business Objectives

Executive assurance & trust	Provide leadership with evidence that compliance and security controls are actively protecting financial data, not just configured.
Risk reduction validation	Show that financial SITs are being systematically identified and governed, reducing exposure and improper data handling.
Value justification for security investments	Correlate auto labeling and DLP outcomes to demonstrate ROI on Purview, labeling, and policy investments.
Operational confidence	Confirm that auto‑labeling policies are accurately detecting sensitive data at scale and triggering appropriate DLP enforcement.
Audit and compliance readiness	Establish defensible proof that sensitive financial data is discovered, classified, and protected consistently across the environment.

Step 1: Create a report, add a name, and description

Step 2: Add a section called Key Outcomes (title and description) and add metric cards to show the data at a glance.

Step 3: Add another section. Include the following two out of the box charts available.

Step 4: Add another section with the out of the box charts

Step 5: Add the last section that ties everything together. One out of the box chart and another custom chart.

Step 6: for the custom chart above, Do a vertical bar, pivot (the groupings at the bottom of the chart) to Activity. Then, add filters (Sensitive info type: the SITs and Activity: DLPRuleMatch.

The report highlights key outcomes, label adoption, application areas, and auto labeling policies. It identifies the main SITs used in labeling and connects them to DLP, demonstrating that the admin's data security measures are effective, particularly with financial information.

Using AI to simplify insights

This AI integration builds on Microsoft Purview’s existing reporting stack (Posture Reports, Activity Explorer and Audit) and introduces AI-assisted interpretation, summarization, and report composition to reduce manual analysis and accelerate decision-making.

To access the report AI Summary: Click on the report and open “View Details”

AI will prepare and summarize the report.

AI Report Components

Executive Summary	Delivers a high level, leadership friendly narrative of the most important insights. Highlights overall posture, major risks, and notable improvements or regressions. Summarizes overall activity (for example, total labeled items and dominant platforms) Calls out major observations and limitations (such as lack of trend comparison due to retention) Provides a concise interpretation of what the data means at a point in time This section answers: “What happened, and what should I know without reading the full report?”
Key metrics	This section provides the essential quantitative data that forms the foundation of the report. Establishes a baseline that can be tracked over time Quantitative measures such as: Number of policy triggers or Label adoption rates Lists the primary counts, categories, and time range used for analysis Clarifies what measurements are available and which are not (such as trends) This section answers: “What are the exact numbers this report is based on?”
Distribution Breakdown	This section shows how activity is distributed across categories or dimensions. Breaks total activity into meaningful segments (for example, Mac vs. Web Browser) Displays proportional impact using counts and percentages Helps identify concentration areas or imbalances across platforms This section answers: “Where is activity happening the most?”
Trend Analysis	Evaluates changes over time when historical data is available. Compares current activity to prior periods Highlights increases, decreases, or stability in behavior Clearly calls out when trend analysis is not possible due to data limitations This section answers: “is behavior improving, worsening, or staying the same over time?”
Key Findings	Synthesizes insights derived from metrics, distributions, and trends. Interprets the data rather than restating it Identifies notable patterns, gaps, or risks (for example, platform skew or low adoption) Connects observations to possible operational or policy implications. This section answers: “What stands out as important or concerning?”
Assessment	Provides an overall evaluation of the security or compliance posture Combines findings into a holistic judgment Assesses scope, coverage, and effectiveness of current practices Describes whether the posture is sufficient or limited This section answers: “How healthy is our current posture?”
Status	Summarizes the assessment into a simple outcome indicator.
Recommendations	Guides next steps based on observed gaps and risks. Suggests practical actions to improve coverage or effectiveness. Aligns recommendations to best practices and product capabilities. Prioritizes changes that reduce risk and improve consistency. This section answers: “What should we do nex
References	Provides traceability and supporting documentation. Links to authoritative Microsoft documentation used to inform recommendations Allows readers to validate guidance or explore implementation details This section answers: “Where can I verify or learn more?”

Full AI Report Summary

Summary

Posture Reports represent a shift from security configuration to security outcomes. They empower organizations to confidently answer critical questions about risk, readiness, and return on security investment, especially in an AI‑driven world.

As reporting continues to evolve, Posture Reports will play a foundational role in how customers prove, improve, and communicate their data security posture.

Data Security Posture Reports

Sarahzin_Shane — Wed, 15 Apr 2026 17:18:17 GMT

Proving Your Data Security Posture with Confidence

Microsoft Purview Posture Reports help organizations prove (not just assume) that their data security controls are working. They provide a clear, outcome‑based view of how effectively sensitivity labels and Data Loss Prevention (DLP) policies are protecting sensitive data across Microsoft 365. Rather than focusing on individual events or alerts, Posture Reports answer a higher‑level question:

Are our data protection controls consistently applied and enforced across the organization?

We designed Posture Reports to give security, compliance, and business leaders a defensible, measurable view of data security posture, especially critical as organizations adopt Copilot and other AI tools.

Purview reporting offers unified data security insights, helping teams identify and address top risks quickly. By consolidating intelligence, it highlights vulnerabilities so you can take prompt action. With contextual information and measurable results, Purview streamlines responses to threats, improves resilience, and supports a proactive security strategy. Microsoft Purview reporting dashboards drive security decisions because they convert massive, fragmented security telemetry into decision‑ready insights: what’s happening, where the risk is, whether controls are effective, and what to do next. For insights on customizing these reports, check out this article.

Where can I access these reports?

Three Locations:

Purview.microsoft.com -> Information Protection -> Reports

Purview.microsoft.com -> Data Loss Prevention -> Posture Reports

Purview.microsoft.com -> DSPM -> Reports

Posture Reports Basics

The out-of-box (OOB) reports are built with a combination of Metric and Analytic cards. Note: these reports are refreshed hourly.

What is a Metric Card?	What is an Analytic Card?
Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context.	Analytics cards provide richer visualizations that help users explore patterns and trends in the data.
What they do: A Metric card is used to create a card that pairs a primary metric with its historical trend This allows users to answer not just “What is the value?” but also “Is it improving or declining?” Metric cards are commonly used for adoption, growth, and compliance health indicators These cards focus on showing trends over time	What they do: Show distributions, breakdowns, or trends over time Enable comparison across locations, labels, or workloads Support investigation and analysis rather than just reporting These are useful when you need a visual representation rather than a single metric. Display data using charts such as bars, lines, or other visual formats

What is a Metric Card?

What is an Analytic Card?

Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context.

Analytics cards provide richer visualizations that help users explore patterns and trends in the data.

What they do:

A Metric card is used to create a card that pairs a primary metric with its historical trend
This allows users to answer not just “What is the value?” but also “Is it improving or declining?”
Metric cards are commonly used for adoption, growth, and compliance health indicators
These cards focus on showing trends over time

What they do:

Show distributions, breakdowns, or trends over time
Enable comparison across locations, labels, or workloads
Support investigation and analysis rather than just reporting
These are useful when you need a visual representation rather than a single metric.
Display data using charts such as bars, lines, or other visual formats

These cards are commonly used for trend analysis, distribution views, and comparative reporting. Both make patterns easier to understand.

Report Insights

The following table goes into each OOB report and breaks down different viewpoints to help understand how to use them.

Report	Where it shows	Data Security Decision Intent	Why	What it shows	Key Metrics	Filter by
Label distribution and adoption in Microsoft 365	DSPM Reports Information Protection Reports	Expand auto labeling to high volume unlabeled areas Simplify or consolidate confusing labels Look for high label coverage areas as additional enforcement opportunities Prioritize training/auto-labeling in areas with low label adoption	Label coverage is the foundational signal for downstream controls	Label activities by workload Sensitivity labels by platform for endpoint devices Sensitivity label usage Label activities by application methods	Total labeled items Auto-labeled items Manually labeled items Labeled by default	How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User
Auto-labeling coverage	DSPM Reports Information Protection Reports	Which auto-labeling polices to promote from audit to enforce Where false positives need tuning before enforcement Which sensitive data types are under-protected Whether auto-labeling can safely scale further	Can we trust our classification signal enough to automate protection?	Auto-labeling by enforcement (which are in sim mode vs. enforcement mode) Auto-labeled items by policies Top auto-labeling policies (most active auto-labeling policies by number of items they have labeled) Auto-labeling policies by platform for endpoint devices	Total labeled items Auto-labeled items Auto-labeled emails Auto-labeled files	How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User
Sensitivity Label Changes	DSPM Reports Information Protection Reports	Whether to restrict or justify label downgrades Where insider risk controls may be needed (users downgrading heavily) Which labels need stronger default enforcement? Whether user behavior is increasing data exposure	Label changes are often an early warning signal of oversharing or misuse	Sensitivity label transition trends (timelines for label upgraded/downgraded/removed over time) Sensitivity label removed across workloads (where labels have been removed) Types of Sensitivity labels downgraded (to which sensitivity labels items were often downgraded) Sensitivity label downgrade methods (Analyze sensitivity label downgrades by application method/workload. Dual chart helps identify if this is happening manual or automatic) Sensitivity label downgrades by user (which users are most frequently downgrading)	Labels upgraded Labels removed Labels downgraded Labels downgraded manually	How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User
Top users triggering DLP Policies	DSPM Reports Data Loss Prevention Posture Reports	Whether activity reflects risky behavior or broken workflows Which users or roles need targeted controls or guidance If DLP policies are too broad or too noisy If insider risk investigations should be warranted or considered	Distinguish Real risk vs policy misalignment vs. normal business activity	DLP Policies Triggered by Users (DLP rule match per rule)	Unique users involved in triggers Total users with repeated triggers	Policy Location (Workload) Endpoint Device Activity
Most triggered DLP Rules or Activities	DSPM Reports Data Loss Prevention Posture Reports	Which policies need tuning or scoping Where enforcement can be strengthened safely Which risks are systemic vs. isolated Whether DLP is actually aligned to sensitive data	High volume DLP rules should drive prioritization, not alert fatigue	Top DLP Rules Triggered DLP Rules Triggered by Device Activity (most common endpoint activities triggered)	Total rules triggered Unique users involved in triggers Total protective actions taken	Policy Location (Workload) Endpoint Device Activity
Most triggered DLP policies	DSPM Reports Data Loss Prevention Posture Reports	Are my highest‑priority policies aligned to real user behavior Shows whether your most critical policies are: Actively protecting data, or rarely triggered (possibly mis-scoped or irrelevant)	Which DLP policies are most actively protecting sensitive data, is this the highest risk?	DLP Policies Triggered by Workload	Total policy trigger volume Unique users involved in triggers Total rules triggered	Policy Location (Workload) Endpoint Device Activity

Report

Where it shows

Data Security Decision Intent

Why

What it shows

Key Metrics

Filter by

Label distribution and adoption in Microsoft 365

DSPM Reports

Information Protection Reports

Expand auto labeling to high volume unlabeled areas

Simplify or consolidate confusing labels

Look for high label coverage areas as additional enforcement opportunities

Prioritize training/auto-labeling in areas with low label adoption

Label coverage is the foundational signal for downstream controls

Label activities by workload

Sensitivity labels by platform for endpoint devices

Sensitivity label usage

Label activities by application methods

Total labeled items

Auto-labeled items

Manually labeled items

Labeled by default

How applied

Activity

Location

Platform

Sensitivity label

Sensitive info type

Policy

Rule

How applied detail

Sensitive info type confidence

User

Auto-labeling coverage

DSPM Reports

Information Protection Reports

Which auto-labeling polices to promote from audit to enforce

Where false positives need tuning before enforcement

Which sensitive data types are under-protected

Whether auto-labeling can safely scale further

Can we trust our classification signal enough to automate protection?

Auto-labeling by enforcement (which are in sim mode vs. enforcement mode)

Auto-labeled items by policies

Top auto-labeling policies (most active auto-labeling policies by number of items they have labeled)

Auto-labeling policies by platform for endpoint devices

Total labeled items

Auto-labeled items

Auto-labeled emails

Auto-labeled files

How applied

Activity

Location

Platform

Sensitivity label

Sensitive info type

Policy

Rule

How applied detail

Sensitive info type confidence

User

Sensitivity Label Changes

DSPM Reports

Information Protection Reports

Whether to restrict or justify label downgrades

Where insider risk controls may be needed (users downgrading heavily)

Which labels need stronger default enforcement?

Whether user behavior is increasing data exposure

Label changes are often an early warning signal of oversharing or misuse

Sensitivity label transition trends (timelines for label upgraded/downgraded/removed over time)

Sensitivity label removed across workloads (where labels have been removed)

Types of Sensitivity labels downgraded (to which sensitivity labels items were often downgraded)

Sensitivity label downgrade methods (Analyze sensitivity label downgrades by application method/workload. Dual chart helps identify if this is happening manual or automatic)

Sensitivity label downgrades by user (which users are most frequently downgrading)

Labels upgraded

Labels removed

Labels downgraded

Labels downgraded manually

How applied

Activity

Location

Platform

Sensitivity label

Sensitive info type

Policy

Rule
How applied detail

Sensitive info type confidence

User

Top users triggering DLP Policies

DSPM Reports

Data Loss Prevention Posture Reports

Whether activity reflects risky behavior or broken workflows

Which users or roles need targeted controls or guidance
If DLP policies are too broad or too noisy

If insider risk investigations should be warranted or considered

Distinguish Real risk vs policy misalignment vs. normal business activity

DLP Policies Triggered by Users (DLP rule match per rule)

Unique users involved in triggers

Total users with repeated triggers

Policy

Location (Workload)

Endpoint Device

Activity

Most triggered DLP Rules or Activities

DSPM Reports

Data Loss Prevention Posture Reports

Which policies need tuning or scoping

Where enforcement can be strengthened safely

Which risks are systemic vs. isolated

Whether DLP is actually aligned to sensitive data

High volume DLP rules should drive prioritization, not alert fatigue

Top DLP Rules Triggered

DLP Rules Triggered by Device Activity (most common endpoint activities triggered)

Total rules triggered

Unique users involved in triggers

Total protective actions taken

Policy

Location (Workload)

Endpoint Device Activity

Most triggered DLP policies

DSPM Reports

Data Loss Prevention Posture Reports

Are my highest‑priority policies aligned to real user behavior

Shows whether your most critical policies are: Actively protecting data, or rarely triggered (possibly mis-scoped or irrelevant)

Which DLP policies are most actively protecting sensitive data, is this the highest risk?

DLP Policies Triggered by Workload

Total policy trigger volume

Unique users involved in triggers

Total rules triggered

Policy

Location (Workload)

Endpoint Device Activity

Customer Use Cases

What are some customer concerns Posture Reports address OOB?

Use Case	Situation	Guidance
Labeling & auto-labeling program rollout: “Are we increasing coverage and preventing drift?”	Customer situation: A customer is rolling out sensitivity labels and auto-labeling. Leadership asks: “Are we labeling more content?” Security asks: “Are sensitive items still unprotected?” And compliance asks: “Are users downgrading labels?”	In posture reports, Information Protection coverage includes label distribution/adoption, auto-labeling posture, and posture drift through label transitions (e.g., label downgrades). This maps directly to “coverage + drift + enforcement” conversations. The built-in IP posture set also calls out label distribution and adoption, auto-labeling policy coverage, and sensitivity label activity as core reports. For “active data” posture, the design intent explicitly includes questions like “What % of my active data estate is labeled vs not labeled?” and “What %/count of unlabeled data has sensitive info?” and “How is labeling protection trending over 30 days?”: perfect for proving program progress (or identifying gaps).
DLP tuning & noise reduction: “Which policies/rules are actually firing, and who’s tripping them?”	Customer situation: The DLP admin is overwhelmed: policies exist, but they don’t know which ones are actually driving volume (or pain), and which users are repeatedly triggering violations. They need to prioritize tuning based on real-world triggers.	Surfaces most triggered DLP rules, most triggered DLP policies, and top users triggering DLP policies. This is directly aligned to the operational question “Are our policies effective?” The service-description blurb explicitly frames DLP posture reports as highlighting most triggered rules, highest-volume policies, and top policy violators. This is exactly what admins use to decide what to tune first. Helps teams move from anecdotal “DLP is noisy” to a ranked view of where to focus (policy/rule/user).
CISO Reports, “Are we safer this quarter?” posture readout	Customer situation: A CISO (or compliance leader) needs a repeatable, executive-ready snapshot of how the organization is protecting sensitive data, without stitching together audit logs, Activity Explorer screenshots, and spreadsheets. Posture Reports are explicitly positioned as “executive-ready visibility” across Information Protection + DLP.	Provides OOB, executive-ready visibility into data protection posture across Information Protection and Data Loss Prevention, so the CISO can answer “Is Purview doing what we intend it to do?” and “Where are the gaps?” quickly. Enables a consistent monthly/quarterly narrative from built-in metrics and trends, with hourly refresh called out as a customer/partner value driver (great for “freshness” credibility in leadership reviews). Uses a rolling window approach; guidance is to save/export what you want to retain for future reference (great for recurring readouts).

Frequently Asked Questions (FAQs)

Question	Guidance
What is the least permission required to see Posture Report section for DLP?	Information Protection Reader
We can see Activity Explorer details inside the reports in a non-simplified view, where all confidential information is visible. If someone has the Security Reader role, will they be able to see these things?	Security Reader can see Activity Explorer content surfaced inside Posture Reports, including user/activity-level details that may expose sensitive metadata. If you want a role that can view posture reports but not see confidential item-level signals, Security Reader is not the safe minimum; Information Protection Reader is.
Why are our DLP "Device Posture" reports are not in the Posture Reports and only on the DLP Overview page?	It will move. Right now, the traffic on home page is high, so we launched there. There will eventually be a deep clone into our "Posture Reports" section, however, it will take some time before it shows up.
Can I get reports going back longer than 30 days?	We're working on increasing this number but at this time, the reports go back a max of 30 days.
Is there any impact on tenant performance when enabling new reporting features? How quickly will reports populate after enabling the feature?	No significant impact is expected. If labeling, scanning, and/or DLP policies are already active, reports populate instantly when the feature is enabled (assuming E5 is in place). No additional intrusive operations are performed on the tenant.
Can we customize these reports?	We have a current public preview in place for posture report customization.

Stay tuned for more updates as we continue to build out Microsoft Purview Reporting.

Co-Authors: Kevin Kirkpatrick and Jane Switzer

Microsoft Purview Referential Architecture Diagrams

MaximeBombardier — Wed, 30 Sep 2026 01:56:58 GMT

The Microsoft Purview architecture diagrams provide a referential view of how data classification, sensitivity labeling, Data Loss Prevention (DLP) and Insider Risk operate across Microsoft 365 workloads. These diagrams are intended to help organisations understand where policy evaluation occurs, how signals flow between services, and how enforcement is applied consistently.

Rather than prescribing a single deployment model, the diagrams illustrate common architectural patterns used to protect sensitive data across endpoints, email, and collaboration services.

2026-09-09 - New Classification and auto-labeling interactive referential architecture now available here: Scaling classification and labeling: an interactive reference architecture update | Microsoft Community Hub.

Classification: How Content Sensitivity Is Determined

This diagram shows how content is classified across Microsoft 365 workloads and connected locations.