Microsoft Purview Blog

7 MIN READ

Data Security Posture Reports

Sarahzin_Shane

Microsoft

Apr 14, 2026

Posture Reports are the authoritative proof that Microsoft Purview controls are not just configured, but actively protecting data at scale. They transform policy configuration into measurable, defensible security posture.

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.

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.