Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community
SOLVED

Container level vs item level Sensitivity Labels

Copper Contributor

Hi Sensitivity Label Gurus, 

I would like to get your perspective on how customers generally use sensitivity labels. Do they use policies to automatically apply sensitivity label at item level or they apply sensitivity label manually at container like Site or Group.  

 

I understand the nuances of item vs Container level and manual vs automated sensitivity label. I want to understand based on your experience which option customer most of the times prefer.  

2 Replies
best response confirmed by DipteshChk (Copper Contributor)
Solution

Hi @DipteshChk 

 

Thank you for posting your question! Honestly, this is a bit of a loaded question.

 

First, setting a label on a container/group does not apply that label to all files within that container. I just want to make sure that is well understood. (You can set a default label for all files in a SharePoint library, but that only applies to new or modified files)

 

Regarding use of the labels and label policies, I have never seen a customer be successful when they dive straight into automatic labeling. Labels need to have a crawl, walk, run approach to them. The best journeys start with manual labeling for client-side (in real-time, within the files) rolling out to pilot users first to fully test the functionality of the labels to ensure they are behaving as expected. After the pilot you should begin periodically (every week or two) rolling out manual labeling to more business units.

 

After piloting manual labeling, still before going straight into auto labeling, you should introduce recommended labeling to get the users accustomed to the system detecting content within the files.

 

It could be 12 -18 months before you have fully deployed auto labeling for files (client-side).

 

During the client-side phasing, you can run auto-labeling policies (service-side, data at rest) in simulation mode to not only begin assessing the impact of auto-labeling but also identify where your large chunks of sensitive data lie, along with content explorer, and possibly identify areas of clean-up where it pertains to duplicate or historical data.

 

I don't recommend having the service-side auto-labeling policies actually applying labels before your entire org has had a chance to use and understand labels on the client-side.

 

From a label policy perspective, you'll likely want to set a default label, which is fine. But I strongly discourage setting a default label that applies encryption. If user A creates a file and shares it with user B who is in the label pilot, when user B opens the file to review it, the label will encrypt the file and make user B the rights management owner of a file that should be owned by user A only. It creates a mess. Control internal access based on the files storage location and then when the file is done being edited and ready for sharing outside of it's original location it should have an encrypting label applied.

 

Additionally, you should leverage Defender for Cloud Apps File Policies to scan for sensitive files that were shared before your labels were configured. Then you can use Governance Actions to apply the necessary label or revoke external access.

Great articulation ! Thanks. This really helps.
1 best response

Accepted Solutions
best response confirmed by DipteshChk (Copper Contributor)
Solution

Hi @DipteshChk 

 

Thank you for posting your question! Honestly, this is a bit of a loaded question.

 

First, setting a label on a container/group does not apply that label to all files within that container. I just want to make sure that is well understood. (You can set a default label for all files in a SharePoint library, but that only applies to new or modified files)

 

Regarding use of the labels and label policies, I have never seen a customer be successful when they dive straight into automatic labeling. Labels need to have a crawl, walk, run approach to them. The best journeys start with manual labeling for client-side (in real-time, within the files) rolling out to pilot users first to fully test the functionality of the labels to ensure they are behaving as expected. After the pilot you should begin periodically (every week or two) rolling out manual labeling to more business units.

 

After piloting manual labeling, still before going straight into auto labeling, you should introduce recommended labeling to get the users accustomed to the system detecting content within the files.

 

It could be 12 -18 months before you have fully deployed auto labeling for files (client-side).

 

During the client-side phasing, you can run auto-labeling policies (service-side, data at rest) in simulation mode to not only begin assessing the impact of auto-labeling but also identify where your large chunks of sensitive data lie, along with content explorer, and possibly identify areas of clean-up where it pertains to duplicate or historical data.

 

I don't recommend having the service-side auto-labeling policies actually applying labels before your entire org has had a chance to use and understand labels on the client-side.

 

From a label policy perspective, you'll likely want to set a default label, which is fine. But I strongly discourage setting a default label that applies encryption. If user A creates a file and shares it with user B who is in the label pilot, when user B opens the file to review it, the label will encrypt the file and make user B the rights management owner of a file that should be owned by user A only. It creates a mess. Control internal access based on the files storage location and then when the file is done being edited and ready for sharing outside of it's original location it should have an encrypting label applied.

 

Additionally, you should leverage Defender for Cloud Apps File Policies to scan for sensitive files that were shared before your labels were configured. Then you can use Governance Actions to apply the necessary label or revoke external access.

View solution in original post