Use CloudAppEvents to actually see what your DLP policies are catching

The DLP alerts page in the Purview portal does its job - it shows you that a policy matched and lets you triage individual incidents. But if you want to answer questions like "which DLP policy generates the most matches?", "which users trigger the most alerts?", or "what percentage of matches are false positives?" - the portal cannot help you.

There is no built-in way to aggregate, trend, or visualise DLP activity over time in Purview. You get individual alerts, not patterns.

CloudAppEvents in Microsoft Defender XDR solves this. It is an advanced hunting table that captures cloud app activity across your tenant, including every DLP rule match. The data is structured, queryable with KQL, and exportable. It is the foundation for real DLP reporting.

CloudAppEvents requires Microsoft Defender for Cloud Apps, which is included in Microsoft 365 E5 or available as an add-on.

You also need the Microsoft 365 connector enabled in Defender for Cloud Apps. Go to Settings > Cloud apps > App connectors and make sure Microsoft 365 is connected. Without this, the table will be empty.

Once connected, DLP events start flowing into the CloudAppEvents table automatically. No extra configuration is needed on the DLP side - if your policies are running, the matches appear.

When a DLP rule matches, CloudAppEvents captures the event with an ActionType of DlpRuleMatch. The rich metadata lives inside the RawEventData column as a JSON object.

The fields you care about:

• PolicyName - which DLP policy triggered
• RuleName - which specific rule within that policy matched
• Actions - what happened (Audit, BlockAccess, NotifyUser, etc.)
• SensitiveInfoType - the SIT that matched (e.g. Credit Card Number, UK National Insurance Number)
• Confidence - the confidence level of the SIT match
• Count - how many instances of the SIT were found
• Location - where it happened (Exchange, SharePoint, OneDrive, Teams, Endpoint)
• Severity - the severity level of the match

You also get the standard CloudAppEvents columns: AccountDisplayName (who triggered it), ObjectName (the file or message), IPAddress, Timestamp, and CountryCode.

Open Advanced hunting in the Microsoft Defender portal. Here are practical queries you can run immediately.

All DLP matches in the last 7 days:

CloudAppEvents | where Timestamp > ago(7d) | where ActionType == "DlpRuleMatch" | project Timestamp, AccountDisplayName, ActionType, ObjectName, RawEventData

DLP matches broken down by policy:

CloudAppEvents | where Timestamp > ago(30d) | where ActionType == "DlpRuleMatch" | extend PolicyName = tostring(RawEventData.PolicyName) | summarize MatchCount = count() by PolicyName | sort by MatchCount desc

Top 10 users triggering DLP matches:

CloudAppEvents | where Timestamp > ago(30d) | where ActionType == "DlpRuleMatch" | summarize MatchCount = count() by AccountDisplayName | top 10 by MatchCount

DLP matches by SIT type:

CloudAppEvents | where Timestamp > ago(30d) | where ActionType == "DlpRuleMatch" | extend SIT = tostring(RawEventData.SensitiveInfoTypeData[0].SensitiveInfoTypeName) | summarize MatchCount = count() by SIT | sort by MatchCount desc

These are starting points. Adjust the fields based on the exact JSON structure in your tenant - the RawEventData schema can vary slightly depending on the workload.

Once your KQL query returns the data you want, click Export in advanced hunting to download a CSV. This gives you up to 100,000 records per export.

For Power BI:

1. Run your KQL query with all the columns you need - flatten the JSON fields using extend and tostring() so each value gets its own column
2. Export to CSV
3. Open Power BI Desktop, import the CSV as a data source
4. Build your visuals - DLP matches over time (line chart), matches by policy (bar chart), top users (table), matches by location (pie chart)

If you want live data rather than CSV snapshots, use the Microsoft Defender XDR connector in Power BI. This lets you run KQL queries directly from Power BI on a refresh schedule. The data stays current without manual exports.

The result is a dashboard that tells you at a glance: how active your DLP policies are, where the matches are happening, which policies generate noise, and which users need attention. This is the reporting that Purview should give you out of the box but does not.

Advanced hunting data in Defender XDR retains for 30 days only. After that, the records are gone. If you want to trend DLP activity over months or build quarterly compliance reports, you need to store the data somewhere else.

Option 1 - Scheduled exports. Run your KQL query weekly or monthly and export to CSV. Store the files in SharePoint or a shared drive. Simple, manual, and works if you only need periodic snapshots.

Option 2 - Streaming API. Use the Defender XDR streaming API to push events to Azure Event Hubs or Azure Storage in real-time. From there, ingest into a data lake, Log Analytics workspace, or directly into Power BI via Azure Data Explorer.

Option 3 - Microsoft Sentinel. If you have Sentinel, connect the Defender XDR data connector. CloudAppEvents data flows into Sentinel's Log Analytics workspace where you control retention (up to 12 years with archive tiers). You can then query the data with KQL in Sentinel and build workbooks for long-term reporting.

Option 4 - Custom automation. Use a Logic App or Power Automate flow on a schedule to run a KQL query via the Defender XDR API and write the results to a SharePoint list, SQL database, or storage account. This runs unattended and gives you a growing historical dataset.

Whichever option you choose, do not discover the 30-day limit when you need 6 months of data for an audit. Set up your export pipeline the same week you deploy your DLP policies.