Use AIP Labels in DLP Policy Rules

Reading Time: 5 minutes

If you’re using Azure Information Protection (AIP) in your organization, you’ll know that once a document has been assigned an AIP label, it is stored in clear text as a document property called Sensitivity. This is visible in the backstage of the Office client in Advanced Properties. What’s great about this is it allows the label to be leveraged in other applications simply by reading the document property.

An example of an application that can leverage this property is Data Loss Prevention (DLP). We can configure DLP rules based on AIP labels as an added level of protection for documents. This is what I’ll demonstrate in this post.

Please refer to this post, Use AIP Labels in SharePoint Search, where I discuss another way to leverage the AIP label using the SharePoint search mechanism.

Scenario: You have a Top Secret AIP label configured in your organization to be used for all highly sensitive documents. You may have configured some protection controls in AIP such as encryption, preventing copying/forwarding and inserting visual markings (watermark/header/footer). For additional data protection, you may also want a DLP Policy with a rule enabled on any content labeled Top Secret to block people from sharing or to restrict access to everyone except the primary site collection admin, document owner and person who last modified it. In this post, I’ll demonstrate how to restrict access. Check out my other post, A SharePoint Content Type DLP Policy, to see how to block external sharing at a document content type level.

TLDR? Here are the steps:

  1. Create the AIP labels in a policy
  2. Publish the AIP Policy
  3. Add some documents to a document library
  4. Label some documents with the Top Secret AIP Label
  5. Wait for them to be crawled
  6. Create a managed property mapped to the Sensitivity crawled property
  7. Test search results for the AIP-labeled documents
  8. Add a DLP Policy and DLP Rule for the Top Secret label via PowerShell
  9. Wait for DLP Policy to take effect
  10. Monitor document library to ensure DLP action is enforced

Step 1 and 2: Create AIP Labels and Publish

Configure AIP labels in the Azure Portal by adding them to the Global Policy. In this example, I’ve added 3 labels: General, Confidential, Top Secret:

AIP Labels

Step 3 and 4: Add documents and label them

If you have AIP configured in your environment, you will see an Information Protection bar under the Office ribbon in the Office client programs (not in the Online versions). It will display your published AIP labels.


In this example, I created several documents on a Microsoft Team’s library in the General channel (folder) and labeled five of them Top Secret. They are highlighted by the yellow stars in the image below

Documents in Library

Step 5 and 6: Search Configuration

These steps will be familiar to you if you’ve done any kind of search configuration in SharePoint. The crawled property for the AIP labels is called Sensitivity.

Note: The AIP labels are also in the crawled properties with the name MSIP_Label_*_Name where * is the ID of the Label (you can find the ID on the bottom of the configuration screen for each label). Please refer to this post by @MikaelSvenson titled Using Azure Information Protection (AIP) Labels in SharePoint search where he shows how to use those crawled properties.

I recently discovered the Sensitivity crawled property was in the search schema as well which allowed for a simpler mapping (and appears to work equally as well).

Map the Sensitivity crawled property to one of the RefinableString## pre-configured managed properties in the search schema. In this example, I’ve mapped it to RefinableString02, provided a descriptive alias, SensitivityAlias, and initiated another crawl on the library/site where the content is stored.


Step 7: Test

To ensure the managed property has been populated with the AIP Label names before we set up the DLP rules, search for the managed property on the top left search box on the SharePoint site. You can use either the RefinableString02 or SensitivityAlias names in your search query. Once content is crawled, you will get your 5 Top Secret documents returned as results:


Step 8: Create DLP Policy and Rule via PowerShell

Now that we have the search index returning the AIP labels, we can leverage this in our DLP rule.

We cannot add a rule pointing to an AIP Label thru the UI so we must use PowerShell. Refer to Create a DLP policy to protect documents with FCI or other properties for detailed instructions on the PowerShell commands and references.

DLP Policies are configured in the Security & Compliance center so we start by connecting to that to run our PowerShell. Reference: Connect to the S&C Center

Create a new DLP Policy called TopSecret_policy to be applicable to all Exchange, SharePoint and OneDrive locations:

[code language=”powershell” light=”true”]
New-DlpCompliancePolicy -Name TopSecret_policy -ExchangeLocation All -SharePointLocation All -OneDriveLocation All -Mode Enable

Create a DLP Rule in the TopSecret_policy by leveraging the RefinableString02 managed property. In this example, I’ve chosen to block access to Top Secret documents to anyone inside the organization with the exception of the owner, author and site owner and will place the Blocked Access red icon on each of those documents.

Note: you can use either the managed property name, RefinableString02, or the alias name, SensitivityAlias, in the DLP compliance rule. Both will work although the alias will make it much easier for others looking at the rule to know which property the rule is for.

  • “RefinableString02:Top Secret”
  • “SensitivityAlias:Top Secret”

[code language=”powershell” light=”true”]
New-DlpComplianceRule -Name TopSecret_content -Policy TopSecret_policy -AccessScope InOrganization -BlockAccess $true -ContentPropertyContainsWords “SensitivityAlias:Top Secret” -Disabled $false

Once the DLP Policy and Rule have been added via PowerShell, you will see them in the Data Loss Prevention section of the Security & Compliance Center. However, you will not be able to view the details of the rule or change it thru the UI.

Step 9: Wait for DLP Policy to take effect

DLP policies are synced to the locations we’ve configured in the policy and will then asynchronously start to evaluate the content and enforce the block access restriction we’ve configured on the rule.

In just a few minutes, the Blocked Access indicators were there!

Important: DLP leverages the search index in SharePoint to constantly monitor new and changed content. Due to this, there is a period of time before content is crawled when a DLP rule may not detect content that it should.

Note: as soon as the DLP action took effect, this prevented these documents from being returned in search results due to the BlockAccess restriction. However, know that the documents are still being crawled in order for the DLP rules and actions to be applied on any new/changed documents.

Step 10: Monitor Library for Blocked Access indicators

As you can see by the image below, the DLP blocked access indicators are now showing for the 5 documents labeled with the Top Secret AIP label. Great news!

Top Secret Documents in LibraryV3


It is my opinion that you should use both AIP and DLP to protect your documents and to safeguard against accidental sharing of sensitive information. This is one way of doing  that.

Thanks for reading.


Credit: Photo by Smugglers Lair on Unsplash


  1. Hi Joanne
    Everything works fine with Office files. What about pdfs? When I assign an AIP Label to a pdf it is saved as a custom property but it looks like the property is not picked up by search.This is an issue when I want to use DLP etc.

    1. Hi Andy,
      Thanks for the comment. I just tested this and my results are the same as yours – I can’t get search to pick up the managed property on PDFs either. I’ll update the blog to state that. To be clear, I believe what I’m covering in this post is functionality coming to DLP thru the GUI and perhaps they’ll address this at that time. We’ll have to wait and see.

  2. Great post Joanne, many thanks for sharing. Do you know if this approach will also work with Exchange? I would like to avoid having to apply AIP protection (encryption) to documents stored in SharePoint Online to avoid it conflicting with Search, co-authoring etc. Would a DLP policy designed to prevent documents being shared externally (based on an AIP label) prevent a document being emailed if it was downloaded from SharePoint first and then added as an attachment in Outlook?

    1. Hi Paul,
      There is a setting on the AIP policy for email messages to apply a label that matches the highest classification of any docs attached. I would think you could use this to make the AIP label for your scenario a higher classification than your default label (if you have one), and then then the email would be “upgraded” to the AIP label of the attached docs. DLP could then act on that label. I’ve never tried this exact scenario, but it should work.

      1. Thanks Joanne, that’s a great shout! I will give it a try. I had assumed until I read your post that DLP policies would only work with Office 365 labels however I now see that you can create them based on SharePoint Search managed properties (thanks to the crawled property for AIP labels). Not sure how to craft a DLP policy based upon the AIP label associated with an email rather than the Office 365 label though. I will do some more digging.

  3. Thanks for sharing Joanne. Did you use this recently? I have tried this approach with the new unified labels with no luck. It looks like the Sensitivity crawled property doesn’t get populated.

    1. Hi there, I haven’t. I’ll check this out when I get a bit of time and will update the post for sensitivity labels. Great question.

    2. Hi, you can use the guid of the label. It seems like sensitivity isn’t populated. I Used MSIP_Label_xxxcebc-xxxx-46f9-b754-1421c45ad750_Name with a managed property Confidential_meta:xxxcebc-xxxx-46f9-b754-1421c45ad750,Confidential

      1. I’ve also been told you can use the “InformationProtectionLabelId” managed property that holds the guid of the sensitivity label guid. I’ll soon test this but thought I’d share.

  4. Hi, I’ve done some testing with the “InformationProtectionLabelId” Managed Property and it works. However, it does not work in OneDrive for some reason. Any difference between for OneDrive sites regarding this?

  5. Hi Joanne!
    Is it necessary enable AIP integration in SPO (Set-SPOTenant -EnableAIPIntegration $true) for the DLP rule works?

    1. Hi Alvaro, I don’t think so. The only time I’ve used that PowerShell cmdlet is when I want to enable the auto-apply functionality for sensitivity labels on the Office apps (desktop clients).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.