Complex DLP Rule Design Is, Well...Complex

One of the most common issues I'm tasked with resolving for my Purview customers is the structure of the DLP Rules within their DLP Policies. You build a rule based on common sense understanding and find that common sense isn't always the right approach.

It's easy to see the Boolean operator options in front of you and take them at face value. Looking at this rule logic, you would be forgiven for assuming that it would match on an email containing a Social Security number and an ITIN:

Unfortunately, that's not how Purview is expecting that condition to be built:

What you should do, is this:

Now we can add the Sensitive Information Type (SIT) that we want to link:

You would think that these are functionally the same, but Purview doesn't evaluate the first one as a Boolean "and". If you've built your rule that way, and you're not seeing the expected hits in the Activity Explorer, modify it to use a nested group.

❓Ok, but what about...

One thing to note is that there are still scenarios where you should use a non-nested group. Here, you can see that nesting a "Content Contains" condition only leaves a few options for the second condition:

when nesting a "content contains" group, your only options are SIT, Sensitivity Labels, or Trainable Classifiers

But, adding a second condition gives you way more options (like, way-way more):

looks a lot like Exchange Online mail flow rules, huh? :)

building Boolean "and" conditions without nesting

➕Bonus Options

One or the other:

One or the other, and, one or the other:

this is getting out of hand, now there are two of them

One or the other, and, one or the other AND another:

and and, Brute?

Hopefully this somewhat simplifies the complex. If you're having issues with your Purview DLP policies, let's connect and see where I can help!