Link to home
Start Free TrialLog in
Avatar of John Water
John WaterFlag for United States of America

asked on

Microsoft O365 Data Loss Protection (DLP) policy to block Social Security Number not functioning properly.

I have set a MS O365 DLP policy to stop Social Security Numbers in email (including sent to or sent from outside and within our company). The policy was fully tested and working properly within the last 10 days. Now I have found the policy will not consistently block the email when the social security number is in the body of the email.
We are using policy tips.
It seems that sometimes SSNs with dashes are identified (policy tips are displayed) and SSNs with no dashes are not identified (no policy tips are displayed). Other times it is the opposite - where SSNs with dashes are not identified (no policy tips) and SSNs with no dashes are identified (policy tips are displayed)
In all these testing the Key word of SSN or Social Security Number is right before the actual number.
When SSN appears in an attachment, either with or without dashes it is identified and policy tips are displayed.

I have also have found the same issues when attempting to send email from outside sender - when SSNs in the body of the email - not blocked and when SSNs in the attachment - are blocked.

We need to be able to block Social Security Numbers from being transmitted in emails.

Does anyone know any options? How has the DLP policies in MS worked for others?I do not see where any DLP data is in the Audit logs. Are there any other locations to provide any information on the DLP activity?
I have see references to use Transport rules for blocking SSN - anyone have any thoughts (positive or negative)?

Thank you
Avatar of Vasil Michev (MVP)
Vasil Michev (MVP)
Flag of Bulgaria image

"Common" sensitive types such as CC number and SSN are evaluated with lower certainty unless some "corroborative" evidence is found in the surrounding data, usually a keyword. Meaning that you can have 10+ SSNs in a single message and a detection will still fail if the surrounding text doesnt indicate that those are indeed SSNs and not some random numbers (which SSNs kinda are). Same for CC - I have attachment with 1000 CC numbers fail detection, while a single instance of the same table was detected just fine because I included the name, expiry and so on columns.

This is explained in the documentation:

You can always create custom sensitive types that are "fine tuned" for your specific needs.
Avatar of John Water


Thank you,
I reviewed the document and did verify the Key words "SSN" or "Social Security Number" are right before the actual numbers. This once was working with no issues and now it is not working consistently.
Are there any options to get any logs or such to get information on why it did not work? It really appears to trigger or not, with no evidence why it did or didn't.
With that, I am thinking only option is to re-create rule, any thoughts on this or any other option?

Again thank you for your time
Well, we only have some info in the logs for when matches occur, nothing afaik can tell you why a match didnt occur. Open a support case I suppose.
Yes, I have a support ticket opened but they have not gotten back with me yet and a lot of the time this site provides better solutions, faster.

thank you
Avatar of John Water
John Water
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial