Share via

Purview Information Protection On-Premises Scanning & DLP Alert Issue

Callie Hagedorn 80 Reputation points
2026-02-20T17:49:02.7933333+00:00

When a Purview DLP alert is triggered by sensitive information types (SITs like SSN or CCN) in an on-premise file, if we click "Open alerts page", a Purview alerts page attempts to open, but it churns and never populates.

If we click "See this alert in Security and Compliance Center", we do see alert details and events in Defender, but unlike other alerts, we can't see "Matched sensitive content".

For example, the following alert details are for a OneDrive / SharePoint file with sensitive content. The alert details give us the actual value / Matched sensitive content that triggered the alert.

However, an on-premise file does not give us the actual value / Matched sensitive content that triggered the alert, but instead just a GUID for the SIT for SSN.

Two questions:

  1. For on-premise files with SITs that trigger a DLP alert in Purview, why does the "Open alerts page" button cause the Purview page to just churn on a loading status eternally?
  2. For on-premise files with SITs that trigger a DLP alert and the alert details can be found in Defender, why can't we see the actual values that triggered the alert? DLP alerts for locations like Exchange, SharePoint, etc. show us the actual value and only on-premise files do not. Is this expected?
Microsoft Security | Microsoft Purview
0 comments No comments
{count} votes

Answer accepted by question author
  1. Pilladi Padma Sai Manisha 5,240 Reputation points Microsoft External Staff Moderator
    2026-02-25T16:25:01.21+00:00

    Hi Callie Hagedorn,

    Thanks for sharing the detailed scenario what you’re seeing with on-premises scanning and DLP alerts is expected behavior based on current Purview capabilities.

    1. “Open alerts page” keeps loading For alerts generated by the Microsoft Purview Information Protection Scanner on on-premises repositories, the Purview Alerts experience isn’t fully supported the same way as cloud workloads (Exchange, SharePoint, OneDrive). When the portal tries to open the Purview alert blade, it may stay in a loading state because the underlying alert data is surfaced primarily through Defender rather than the full Purview alert workflow. This is a known UI/experience limitation rather than a browser or configuration issue.
    2. Matched sensitive content not visible for on-prem files This is also by design. With on-prem scanning, only detection metadata (for example, the Sensitive Information Type GUID) is sent to the service. The actual matched values aren’t uploaded or exposed in the alert details due to architectural and privacy boundaries. Cloud locations can display “Matched sensitive content” because the data resides within Microsoft 365 services, but on-prem sources do not currently provide that level of visibility.

    Summary The behavior you described alerts visible in Defender, Purview alert page not fully loading, and only SIT GUIDs shown aligns with current product limitations for on-premises scanning. At the moment, Defender alert details represent the maximum available visibility for these events.

    Hope this helps clarify things, and please let me know if you’d like guidance on recommended monitoring or investigation workflows for on-prem DLP alerts.


1 additional answer

Sort by: Most helpful
  1. Q&A Assist
    2026-02-20T17:49:12.3933333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    For your questions regarding Purview DLP alerts related to on-premise files:

    1. The issue where the "Open alerts page" button causes the Purview page to churn indefinitely may be due to various factors, such as network connectivity issues, browser compatibility, or potential bugs within the Purview portal itself. Unfortunately, the context does not provide specific troubleshooting steps for this issue, so it may be beneficial to check for any updates or known issues with the Purview service.
    2. The reason you cannot see the actual values that triggered the alert for on-premise files, unlike alerts from other locations such as Exchange or SharePoint, is likely due to the way DLP policies and alerts are configured for different environments. The context does not explicitly state whether this behavior is expected or not, but it suggests that there might be limitations in how on-premise alerts are processed compared to cloud-based services. This could be a design choice or a limitation of the current implementation of DLP for on-premise files.

    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.