In this section I will go through the following topics relating to security and compliance settings for Microsoft Teams.
- Plan and configure retention policies
- Plan and configure sensitivity labels
I’ve decided to give these two topics a dedicated post because when it comes to Microsoft Teams, and Microsoft 365 in general, too many organizations do not have a grasp on where their important data lives across the ecosystem of products. As a result, protecting that data becomes extremely difficult.
Plan and configure retention policies
Retention policies for Microsoft Teams can seem complex as Teams is not a siloed application, it is supported by other apps in the platform. When planning retention policies for the different aspects of Teams, different types of policy target different components of Teams. The policy type and Teams workload are shown in Table 1.
|Policy Type||Teams Workloads|
|Office 365 Group||Email (Group Mailbox) and Files (SharePoint Site)|
|SharePoint / OneDrive||Teams Files (SharePoint Site) and personal shared files (OneDrive)|
|Teams channel messages||Messages within regular Teams channels|
|Teams chats||Personal Teams chat|
|Teams private channel messages||Messages within private Teams channels|
When planning retention policies, particularly when you have policies for other workloads, keep note of the following:
- Teams chat and channel message retention can be created as a single policy but can’t be mixed with other workloads
- Teams private channel messages requires a standalone policy
It’s also important to understand how Teams messages are stored, for a full breakdown, check out this post but in short, Teams message compliance records are stored within the user or group Exchange mailbox. This is particularly important for retention policies that process message deletion because the deletion actually occurs on the Exchange mailbox, and is then synced to Teams.
Speaking of deletion, a common misconception of retention policies is that they are designed to protect against loss of data. While this is partially true, it’s equally as important to purge data that you no longer need or are legally required to remove.
For example, a typical retention requirement for Teams chat and channel messages might be to retain all chat and channel messages for one year and then delete them. To configure this policy, open the Microsoft 365 Compliance Center and navigate to “Information Governance” -> “Retention Policies” and select “New retention policy”. Give the policy a name and description as shown in Figure 1 and click next.
On the type page, choose a static policy. Adaptive policies are currently in preview (more on them later). On the locations page, select “Teams channel messages” and “Teams chats” (Figure 2) then click next, you can use the “Included” and “Excluded” options to narrow down the scope to specific users or Teams.
Finally, configure the retention and deletion options. For this example, shown in Figure 3, I have selected to retain all Teams chat and channel messages for one year and to delete the items after that. The minimum time frame that can be configured is one day.
On the review page (Figure 4), verify the configured settings and then hit “submit” when you are happy.
Once the policy is created, it may take a couple of days before you see any changes applied. This is because the policy needs to process the data it applies to and for messages, we also need to consider the sync from Exchange to Teams that I mentioned earlier.
Adaptive Policies are a preview feature that allow you to create retention policies based on specific criteria in a user, site or group. For example, a scope to capture all users in the finance department located in Ireland as shown in Figure 5.
The scope can also be defined using the Advanced Query Builder to customize the query even more. Once created, the scopes can be used to target retention policies as shown in Figure 6.
Adaptive scopes are still preview at the time of writing so most likely will not be on the exam but can be very useful and solve a lot of pain points around retention policy assignments.
Plan and configure sensitivity labels
I wrote about Sensitivity Labels a few times in the past, in my MS-500 exam guide for example I wrote about planning and deploying sensitivity labels in Office 365 and also this post on how to get started with sensitivity labels. That said, sensitivity labels aren’t specific to one application and do have some Teams (or rather, Microsoft 365 Groups) specific functionality also. Labels are defined in the Microsoft 365 Compliance Portal and a single label can be applied (using label policies) to one or more of the below:
- Files & Emails
- Groups & Sites
- Schematized Data Assets (Preview)*
For this post, I’ll break down the functionality into two different areas, file (and email) classification and group (and site) classification.
*Note: Schematized data assets are a preview feature and not related to Teams so I won’t cover them here. They can include SQL, Azure SQL, Azure Synapse, Azure Cosmos, AWS RDS, and more.
File classification with sensitivity labels allows an organization to predefine classification labels that are applied at item level to a document or email. These labels will classify a document and also optionally, encrypt with Azure AD Rights Management (RMS) and/or mark the content with headers, footers or watermarks. This essentially provides classification, protection and identification functionality to single items.
When defining a label, it must be given a name and it a very basic level, the sensitivity label can then be deployed to users to allow them to classify documents of different types. To enhance the benefit of the label, encryption and marking can also be configured.
Encryption allows and admin to specify a predefined audience and permission level for a label which is then enforced using RMS. For example, when configuring a label to meet the following requirement:
“This document should only be modified by users in the Finance department. All other internal users will have read only access to the document and external users will be prevented from opening it.”
Then the label must define the two audiences and associated permissions as shown in Figure 7.
One exception to this is when creating a label with the option “Let users assign permissions when they apply the label”. This option will prompt users to define the audience when they classify the document. As a general rule practice, try not to get too granular with creating different levels of sensitivity labels for uncommon audience requirements. A custom label using this setting will allow for that granular flexibility.
RMS keys are managed by Microsoft and require a Microsoft account sign in to gain access, the time that this access persists before another sign in is required can be defined in the “Allow offline access” setting. For certain regulated organizations, the Double Key Encryption functionality can be useful as it allows an organization to use their own key as a second level of encryption where required.
Marking can also be configured to add watermarks, headers and footers based on the classification label. For example, in Figure 8, the label has been configured with a watermark and footer.
Auto-labelling for files and emails
For organizations with Azure Information Protection Plan 2 licensing (or any license that contains it, such as Microsoft 365 E5), labels can be configured to automatically apply based on the content of the file or email. This can take the decision of which label to apply away from the user and label based on Sensitive Information Types or Trainable Classifiers. For example, Figure 9 shows an auto-labelling configuration to apply a label when there is high confidence that a credit card number is present in the file or email.
Applying sensitivity labels to Microsoft 365 Groups inherently will apply the label to the related Team. The functionality provided by labels to groups / Teams is different however from what you get for files and emails. Specifically, you can control two aspects of the object, privacy and access. Note that classifying groups using sensitivity labels is different from applying Azure AD Group Classifications.
To show how sensitivity labels apply to groups, let’s take another example requirement:
“Groups classified with this label should not allow external sharing or Guest user access and the group membership should be private. Group file data should also only be accessible from corporately managed devices”
To achieve this, we can first define the privacy settings shown in Figure 10 to set the group as private and prevent guest access.
Next, on the the access settings, we configure the SharePoint sharing controls to block external sharing and the Conditional Access settings to block access to unmanaged devices (Figure 11).
For the Conditional Access settings, we can also leverage the Authentication Contexts preview feature to provide more granular control.
With this label deployed to users using a labelling policy, when groups or Teams are created, the user will be prompted to assign a label and the underlying group will inherit the settings defined.
Retention Policies and Sensitivity Labels go way beyond Teams in terms of scope and usefulness and are two of the most important considerations when planning for governance and compliance in your tenant. While it’s important for the exam to understand how they work with Teams, I recommend checking out my previous posts which look at sensitivity labels and retention policies in a more holistic manner. In the next post I will finish the Security and Compliance topic with DLP, Conditional Access and Information Barriers.