Purview eDiscovery is not working correctly using “Sensitive Type” KeyQL: (Microsoft BUG)

Question

Purview eDiscovery is not working correctly using “Sensitive Type” KeyQL: (Microsoft BUG)

Sergio Londono 886

Hello Team,

I am running in eDiscovery using KeyQL or Query builder data at REST in EXO (Stale emails) that contain sensitive Info like:

Canada Social Insurance number.

We need to delete all the emails in our internal employees that contain “Canada Social Insurance number” before Jan 01, 2020

The query run correctly, however, the output statistics pull out other type of sensitive Info, this means that the eDiscovery is not discovering what is was requested in the KeyQL query.

Canada Social Insurance Number a2f29c85-ecb8-4514-a610-364790c0773e
User's image

User's image

KeyQL Query:

(SensitiveType:a2f29c85-ecb8-4514-a610-364790c0773e|1..|85..100) AND Date>2025-01-01 Please see

The output of the Query:

User's image

In addition with this problem, Why we can't delete the stale emails using as condition the "Sensitive info", so, If I need to delete the emails before 2020 with "Canada Social Insurance number", how can I do it? It will be almost impossible if the cybersecurity team needs to do with the end-user email by email?
User's image

Best regards,

Accepted answer

0 additional answers

Your answer

Answer 1

Vasil Michev 119.5K MVP Volunteer Moderator

There are some known issues with the UI experience, in particular when using KeyQL queries. Let's just say that Microsoft didn't properly test the new experience before releasing it (and removing the old one). In effect, you are better off using PowerShell and the New-ComplianceSearch cmdlet. And you will end up using PowerShell anyway, as the new experience does not support purging items, as you've noted above. So back to New-ComplianceSearchAction.

The Graph API method should also work, as the issues are only with the UI, afaik.

Sergio Londono 886 Reputation points

2025-06-07T14:25:03.3466667+00:00

Hello @Vasil Michev ,

the internal in Microsoft confirm that remove items using powershell is not available when query use "Sensitive Type", However, why if the KeyQL is only searching for "Canada Social Insurance Number" the output bring other type of sensitive type?

Canada Social Insurance number: a2f29c85-ecb8-4514-a610-364790c0773e
KeyQL Query only searching for Canada Social Insurance number:

(SensitiveType:a2f29c85-ecb8-4514-a610-364790c0773e|1..|85..100) AND Date>2025-01-01

Why did the query bring other kind of sensitive type?
Venkat Reddy Navari 3,125 Reputation points Microsoft External Staff Moderator

2025-06-09T03:19:59.4833333+00:00
Hi Sergio Londono Thanks for sharing the screenshot, it clearly shows that the query is returning unrelated sensitive info types, despite being scoped specifically to Canada Social Insurance Number using the correct GUID:

(SensitiveType:a2f29c85-ecb8-4514-a610-364790c0773e|1..|85..100) AND Date>2025-01-01

This appears to be a known issue in the Microsoft Purview eDiscovery UI, where KeyQL queries may include items with multiple Sensitive Info Types (SITs), even if only one is targeted. This may result from overlapping detection patterns or backend misclassification.

Recommended Next Steps:

Try a stricter confidence range like |85..100 to reduce false positives.

Run the same query using PowerShell (New-ComplianceSearch) to confirm whether this is UI-specific.

Since purging based on SensitiveType isn't supported, consider tagging or exporting the items and filtering post-export.

If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
Sergio Londono 886 Reputation points

2025-06-09T19:20:35.6666667+00:00
@Venkat Reddy Navari ,

yes, that is a limitation in Microsoft eDiscovery, very huge limitation as we can't protect STALE emails with sensitive data.

Try a stricter confidence range like |85..100 to reduce false positives.--> Already DONE

Run the same query using PowerShell (New-ComplianceSearch) to confirm whether this is UI-specific. --> New UI is not working good in Powershell, it is only for the classic.

Since purging based on SensitiveType isn't supported, consider tagging or exporting the items and filtering post-export. Yes, that is the only approach, however, it is not feasible as the number of employees and STALE sensitive data is big.

I just want to bring this up in MIcrosoft as eDiscovery is not provinding the right features to reduce cybersecurity risk, the STALE Sensitive email will remain in users' mailbox until there is a feasible solution from Microsoft.

THis problem is not only problem in my company, this issue I believe is for 95% of companies out there using Exchange Online.

Best regards,

Share via

Purview eDiscovery is not working correctly using “Sensitive Type” KeyQL: (Microsoft BUG)

0 additional answers

Your answer