[Updated March 2023] This capability is now available within the Purview DLP UI. Although the PowerShell technique I describe in this post will certainly still work, you can also configure it in the UI. Details are below.
Post originally written in 2018, but it is still relevant today so I updated it!
My background is SharePoint so most of my ideas tend to center around how I can integrate other services with it. The DLP capability in Microsoft Purview can provide some compliance controls based on many conditions, one of which can be a SharePoint content type! Do you think there would ever be a business need to apply a DLP Policy based on a specific content type in SharePoint. I think yes.
An example? Restrict external sharing for your company’s contracts. Are there other ways you could use DLP to restrict this? Yes, but I want to tie a SharePoint content type directly to a DLP policy so this is the scenario I’ll walk-thru in this post.
Microsoft link: Protect documents that have FCI or other properties
In the steps below, I assume you already know how to set up a content type, work with the SharePoint search schema and run PowerShell against the Security & Compliance Center. Let’s get started!
Step 1: I created a custom document content type in SharePoint called Contoso Contract.
Step 2: I added 2 documents to a library using the Contoso Contract content type and one document with the Document content type. I did this only to demonstrate the DLP Policy will be applied to the Contoso Contract documents and not to the Document content type. Pictured below is the library with the 2 types of documents.
Step 3: In the tenant search schema, I mapped the ows_ContentType crawled property to a new managed property, RefinableString03 and gave it a descriptive alias, ContentTypeAlias, as shown in image below:
Note: you could have the same Contoso Contract content type set up across many other site collections and use them anywhere in your tenant. This would mean the DLP policy would be in effect across any site collection in your tenant storing Contoso Contracts. This makes this a very scalable solution.
I tried using the existing SPContentType and ContentType managed properties but neither of them worked for setting a DLP rule. I had success with using one of the pre-configured RefinableString## managed properties instead.
Step 4: I requested a re-index of the library/site.
Step 5: To test the managed property setting, I entered the search request below to ensure the two documents of type Contoso Contract would be returned. I used the alias, ContentTypeAlias, in the search query but the managed property name, RefinableString03, would have worked equally as well.
[Update March 2023] Steps 6 and 7 below use PowerShell to configure the DLP condition. Alternatively, you can simply use the UI to configure the DLP rule’s condition to detect the content type as shown in this image:
Step 6: I configured the DLP Policy to be in effect across all SharePoint locations. This is how to do this via PowerShell.
Step 7: I configured the DLP Rule pointing to the new RefinableString03 managed property.
Note: you can use either the managed property name, RefinableString03, or the alias name, ContentTypeAlias, in the DLP Rule setting. Either will work however the alias is easier for others viewing the Rule to know which property it applies to:
- -ContentPropertyContainsWords “ContentTypeAlias:Contoso Contract”
- -ContentPropertyContainsWords “RefinableString03:Contoso Contract”
This will ensure the DLP Policy will be applied to Contoso Contract documents across your entire tenant (assuming you have the policy published to that location). I also restricted this policy for external sharing and set the DLP Policy tip and required an override.
"WithJustification" -NotifyPolicyTipCustomText "This is a Contoso Contract! Treat as Confidential" -NotifyUser "Owner"
Step 8: Nothing to do here but wait. 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 restrict external sharing restriction we’ve configured on the rule.
Step 9: I monitored the document library to test if all Contoso Contract content types were now protected by DLP policy as indicated by the policy tip that will show in the document property pane. Yes, they were! As expected, the regular Document content type was not protected by the DLP policy.
Step 10: I selected one of the documents protected by the DLP Policy and could see the policy tip and was required to enter an override if I wanted to share it externally. Sweet!
Go ahead and try this out in your own organization. It’s a good way to leverage some of the Information Architecture you already have set up in your environment and place a layer of protection on top of it – a great way to safeguard some of the “crown jewels” in your organization.
Thanks for reading.
Thanks for the testing and explanation. This makes perfect sense and is a great example of how managed properties can be leveraged for additional purposes. Hopefully MS will provide a UI screen for working with the DLP Compliance Policies
Hi Joanne – is it possible to do the same thing but apply a Classification Label instead of a DLP policy?
“Kind of”. There is a one-way sync from a SharePoint metadata value back to a classification label, but it has some deficiencies. I blogged about it a while ago if you want to take a read… https://joannecklein.com/2017/11/14/aip-labels-via-sharepoint-metadata/