Create DLP Policy Based on Sensitivity Label
Create a DLP Policy where you can add the Sensitive Label on it because currently, only Sensitive info type and Retention Label can be added
This capability is now in Private Preview – sign up at: https://aka.ms/mipc/DLPlabels-preview
Stephen Walsh commented
Great that this is in ***** Preview now. Can it be extended to also look at classifications of attachments in the same way that SITs are also detected in attachments?
David Cawley commented
When will this be rolled out to GA?
Please when this will be on GA ? It's an urgent features !
Dipen Ds commented
@Nir Hendler. How long it takes for Private Preview to be enabled.
Adam Arndt commented
DLP should be based upon sensitivity label, not retention label. Documentation has said that sensitive labels are coming soon for quite a while now.
This is really important for our compliance program.
This is extremely important, Microsoft fix it.
I agree this capability is needed. I need to protect content with sensitivity labels/AIP labeled content. Microsoft, any updates?
Brian Pumphrey commented
Supposedly the devs were working on this issue around the time you shared the idea. I haven't seen anything else mentioned, nor does it exist on the roadmap. This is a very much needed feature, seeing as an end user can overwrite an automatically applied Retention Label.
I couldn't agree more.... What does a retention label have to do with loss prevention? DLP should be based on sensitivity label, or AIP label, not retention labels. As Joanne Kline says:
“AIP labels have everything to do with protection of your corporate assets.” (Except the ability to create a DLP policy based on the sensitivity label)
“Retention labels have everything to do with compliance and regulatory requirements in your organization as it relates to retention and disposition.”
Dan M commented
So now that sensitivity tags are now in the SCC, my question is why on earth do DLP policies in SCC only allow you to create policy based on "retention" tags. Retention tags should have NOTHING to do with DLP.
I would love the ability to create O365 compliance DLP policy based on AIP label. Don't see that capability today......specifically, I can tag AIP label using transport rule but have no way to influence O365 label in same fashion. Need compliance DLP condition that can operate on AIP label or ability to tag O365 label in transport rule.
I do not agree with this.
At a recent Ignite session about AIP I saw that Microsoft intents to synchronise the O365 labels and the AIP labels. That is a mistake! Do not do that!
Why? O365 labels should be used for retention policies only. The option to use O365 labels in DLP is a wrong step, instead you should use AIP labels in DLP and leave O365 labels for retention purposes only.
So, my advise: use AIP and DLP for protection and use O365 labels for Retention. Sure there can be a relation to each other if you like, but do not integrate!
Eddy Veldboer commented
Be sure to integratie with AIP labels (Not confused with Office 365 Labels (for retention).
Douglas Plumley commented
It would be great if we could utilize labels in Azure AD conditional access policies as well, this would allow us to require MFA when a user is accessing sensitive content.
Absolutely agree. The 82 sensitivity types that I can see are all well and good, though we wish to label docs as Confidential, Sensitive, Public and have DLP rules around those - ie "if it's labeled as Confidential it cannot be sent outside of the organisation, and the head of HR is alerted".
Douglas Plumley commented
Recently classification labels were introduced in the Security & Compliance Center to help with retention of certain types of data classifications.
We also have Azure Information Protection sensitivity labels (personal, public, internal, confidential, secret).
DLP sensitive information types are good, but it would be even better if we could simply label groups of data as sensitive and apply DLP vs. trying to determine they are sensitive via the DLP sensitive information types. This would remove the complexity of trying to create custom sensitive information types when the out of the box types don't meet your needs.