Sensitivity Labels are considered an advanced IT consideration relating to Data Security & Compliance.
This article attempts to gently introduce the topic and terminology and how it relates to Atlas/SharePoint specifically.
Atlas 4.1 brings new functionality that helps clients leverage Container-Level Sensitivity Labels. You can read more about this here: Atlas 4.1 - Sensitivity Labels
For the purpose of this article keep in mind that Sensitivity Labels are....
- Required by the needs of a business, which are then...
- Translated in to Sensitivity Label definitions by IT Administrators and...
- Can then be used by Atlas Admins to Create Workspace Templates so that
- When Workspaces are created from these templates they will automatically and consistently have the correct Sensitivity Label!
Sensitivity Label Admin
As you can see form the schematic above, Business and IT Administrators define and create Sensitivity Labels applicable to the needs of each organisation. These are usually defined at the Tenant level in Azure or MS365.
These definitions describe:
- The Protection measures given by each Sensitivity Label
- Who can use each Sensitivity Label
- Where they can use each Sensitivity Label
In best-practice, Sensitivity Labels should be defined for a Single Purpose, applicable to either content OR container. Whilst technically possible, having Sensitivity Labels for a Mixed Purpose will quickly cause confusion for those defining them AND for those using them.
NOTE: Sensitivity Labels are NOT defined or managed in ATLAS; ONLY Used
For more information please read the guidance here: Get started with sensitivity labels - Microsoft Purview (compliance)
Sensitivity Label Types - Content or Container?
If set up in your M365 environment, Sensitivity Labels are a powerful security feature.
Your organisation might already have policies for Sensitivity Labels for content, like emails and Office Files; these are called Content-level Security Labels.
It's also possible to have Security Labels which can be applied in places where files can be stored, such as Microsoft Teams, SharePoint sites or MS365. These places are generally called containers; these could have Container-level Security Labels.
Security Features deployed with Sensitivity Labels
Sensitivity Labels applied to Containers (like a SharePoint site) DOES NOT mean that content (like an email or file) added to that container gets labelled (with the Container-level Sensitivity Label). Rather the content is protected, by controlling access to the Container.
This is important since if that content is moved outside of the container it loses the access protection it had whilst inside it.
In turn Sensitivity Labels applied directly to content, stay with the content wherever that content is placed.
For more detail on the Security Features applied by the Sensitivity Labels on Containers, Click Here.
For more detail on the Security Features applied by the Sensitivity Labels on Content, Click Here.
Applying Sensitivity Labels
From above, Sensitivity Labels are defined and created by Administrators with delegated roles (see this article for details).
Once created, they can be published to different user groups from Azure Active Directory. The members of those AAD groups will be able to apply the Sensitivity labels. In our context Atlas Administrators, would be members of those groups
To apply a Sensitivity label, the Atlas Administrator also needs permissions over the item (container or content) for which the label needs to be applied.
Atlas Administrators would only have visibility of Sensitivity Labels published to them at the Azure Active Directory level.
In turn, Atlas Administrators would only be able to apply Sensitivity Labels published to them at the Azure Active Directory level.
The same is true for some Atlas Users at the content-level; If they are a File contributor with Edit permissions, they would only see and be able to apply Sensitivity Labels, published to them at the Azure Active Directory level.