Empowering self-service is important to us at Microsoft. Every employee should be able to create the resources they need without engaging IT to do it for them. To support this level of freedom, we rely on a strong governance strategy to identify and protect valuable content. By ensuring accountability, our employees are able to create the containers and content they need to stay productive.
With sensitivity labels, Microsoft Digital Employee Experience (MDEE), the organization that supports, protects, and empowers the company, can now proactively enforce policies to keep shared workspaces safe. Microsoft 365 groups, SharePoint sites, Teams, Viva Engage communities, and any container used throughout Microsoft now utilize sensitivity labels to identify and proactively protect valuable information. In doing so, Microsoft can strengthen self-service without exposing sensitive information.
What sensitivity labels mean for Microsoft
Regardless of the technology behind it, labels represent a visual cue to people interacting with a shared workspace or document. Labels can inform an enterprise’s governance practices, letting the organization describe the landscape to properly manage it and enact the right policies.
At Microsoft, labels enable our employees to identify different degrees of value. Based on the label, we can apply the right amount of protection.
Previously, when a Microsoft employee created a new group a Microsoft Azure Active Directory (AAD) label would help classify it, denoting who should have access to the shared workspace according to Microsoft’s policies. On its own, an AAD label doesn’t do anything; it’s simply a string of descriptive text incapable of enforcement. Custom scripts run by administrators would apply policy rules based on these AAD labels. As a consequence of the gap between classification and enforcement, users could accidentally ignore the policies, creating circumstances where the group is out of compliance. Once the non-compliant container is recognized and remediated by the custom solutions, the user might be surprised or disrupted by enforcement actions taken to protect and secure the workspace.
In moving to sensitivity labels, we in MDEE are able to further empower users with compliant self-service right out of the box. Enforcement happens through sensitivity labels, so users are never disrupted or required to take additional compliance actions; they have a clear understanding of classification from the start, creating a better user experience while protecting the enterprise. The migration allows the organization to retire several custom solutions that are no longer necessary. Sensitivity labels have also enabled us to unify content and container classifications, creating consistent taxonomy and the opportunity for centralized administration.
Labels define the culture
Applying labels to a workspace not only informs the organization as to what a site or container is, but drives a culture of good governance. To have a successful implementation of sensitivity labels, MDEE built strong, meaningful, and self-explanatory labels. Alignment with partners at Microsoft Digital Security and Resilience (DSR) meant labels could communicate the level of sensitivity in the workplace or document without a technical explanation.
At Microsoft, we use four labels for container and file classification:
- Highly confidential. The most critical data for Microsoft. We share it only with named recipients.
- Confidential. Crucial to achieving Microsoft’s goals. Limited distribution—these are on a need-to-know basis.
- General. Daily work used and shared throughout Microsoft, like personal settings and postal codes. We share these throughout Microsoft internally.
- Public. Unrestricted data meant for public consumption, like publicly released source code and announced financials. We share these freely.
These definitions inform policies from a technological side, and once taxonomy was established, we were able to enforce consistent security policies across the company. From a user’s perspective, understanding these terms is easier to comprehend than the underlying rules and settings behind the classifications. Labels are intended to support security without creating an extra burden for users. It’s not always easy for users to understand the details of security, but they do understand constructs like “General,” “Confidential,” and “Highly Confidential.”
Aligning on label taxonomy also secured buy-in for company defaults. For some companies, governance policies are open by default, whereas Microsoft is closed.
With the new sensitivity labels, container classification communicates four things:
- Privacy level. Labels determine whether the workspace is broadly available internally or a private site.
- External permissions. Guest allowance is administered via the group’s classification, allowing specified partners to access teams when appropriate.
- Sharing guidelines. Important governance policies are tied to the container’s label. For example, can this workspace be shared outside of Microsoft? Is this group limited to a specific division or team? Or is it restricted to specific people? The label establishes these rules.
- Conditional access. While not implemented at Microsoft, tying identity and device verification to container labels introduces additional governance controls.
Unification makes things simpler
Prior to sensitivity labels, AAD tagged containers at a tenant level with document labeling being handled by security and compliance, or Microsoft Purview Information Protection. As a consequence, the two artifacts lived in two separate locations, requiring administrators to visit different sites for managing governance.
The two locations also meant container labels worked a little differently than document labels. Where tenant-level AAD labels for a container would display an entire list of classifications, document labels only showed classifications that were appropriate to the user. Once unified, sensitivity labels for containers only populate appropriate classifications, limiting the list to valid labels for the users and groups.
Shifting labels from AAD to Microsoft Purview Information Protection, where data-loss prevention and retention takes place, unified labels across the company, reduced the workload for administrators, and allowed Microsoft to take another step forward in readying the environment.
Strategic governance with labels
By using terms for labels that mean something to people, label definition becomes intuitive and reinforces a culture of accountability. Establishing this level of awareness creates corporate buy-in. Getting the company to stand behind these specific label classifications not only supports a consistent experience, but informs corporate strategy decisions around privacy and sharing.
Rationalizing a hierarchy of policies establishes where you are today and where you’ll be tomorrow. Currently, there’s no concept of inheritance between a container and its content. Labeling a workspace highly confidential does not pass that trait on to documents stored inside. In the future, however, unified taxonomy and centralized administration creates the opportunity for an efficient connection between the workspace’s label and the classification of documents within.
Readying Microsoft for sensitivity labels
For some organizations, those coming from a green state with no existing AAD classifications in place, sensitivity labels can be easily onboarded, and offer a chance to introduce a strong culture of governance.
But for companies like us at Microsoft, where existing AAD labels and custom governance solutions were already established, moving to sensitivity labels required preparation and alignment across the company before migration could occur.
Aligning on label definition
Onboarding sensitivity labels gave us an opportunity to create consistent classification language for containers. This entailed conversations about balancing employee experience and enablement with security and legal implications. Agreeing on taxonomy and selecting terms with meaning allowed us to protect the enterprise while empowering self-service.
Planning the migration
With clear taxonomy and a strong governance strategy, we were ready to start working on the logistics of applying sensitivity labels to existing containers. Careful coordination, including organized efforts and timing, prevented users from experiencing any disruptions in productivity or security while sensitivity labels were rolled out.
Synchronizing timelines with stakeholders
For a short period, we existed in a unique hybrid state, with both AAD and sensitivity labels active across the enterprise. To avoid any derailments or threats to the environment, we in MDEE had to time the conversion of existing labels to new sensitivity labels correctly.
Whether it be Microsoft Teams, Viva Engage, or a Microsoft 365 group, certain user interface and backend changes had to be completed to enable sensitivity labels. All stakeholders agreed to tasks and workloads that needed to be completed during a specific release cadence. This allowed the hybrid environment to be resolved without placing Microsoft at risk.
Coordination between stakeholders also meant MDEE had to support teams with smaller engineering capabilities, empowering them to complete tasks on schedule.
Mapping the scope of impact
There are over 333,000 Microsoft 365 groups at Microsoft, 55,000 SharePoint sites, and thousands of Viva Engage communities. Planning out the migration meant closely surveying these environments to understand what might be encountered and require attention before, during, and after the migration.
- How many groups are already labeled? Whether they be sensitivity labels or AAD labels, the current environment was evaluated for labels and their classification. Roughly 86 percent of groups at Microsoft had some kind of label prior to migration.
- Do existing containers map to sensitivity labels? Since previous tags were strings of text, they did not necessarily align with the new taxonomy. To reduce confusion, existing AAD labels were mapped to Microsoft Purview Information Protection container labels.
- What were the challenges they had to overcome? Once teams in MDEE understood the labelling conventions of containers, they could better understand if an area might break due to changes.
- Which groups have exceptions? Certain users required exceptions for policies relating to specific containers. Identifying these items meant we could avoid disruptions to users with specialized needs, all without exposing valuable information.
Resolving and retiring custom solutions
Having mapped out the environment, we could then reduce our reliance on the custom tooling that scanned AAD labels to trigger security and compliance settings. From an engineering perspective, this straightforward step meant labels would no longer call an API but make calls on behalf of users to get applicable labels.
- Remove old references.
- Locate and update calls and permissions.
- Ensure that anything still needing custom tooling is handled with delegate permissions.
Addressing label assignment to groups
Only group owners and global administrators can assign a label to a group directly. This posed a unique challenge for us. Custom scripts run by global administrators could change the labels of these containers, but it was estimated to take at least 27 hours, which far exceeds Microsoft’s access policy for global administrators. Adding to the challenge, the administrator’s computer would be locked down and required to stay active throughout the duration.
Having a global administrator handle these responsibilities wasn’t going to happen and giving someone global administrator status for one job was a non-starter.
This required us to develop a different solution.
Thinking through the problem, the team recognized that labels set in SharePoint through AAD will get synced back to Microsoft 365, which is also a container. Knowing this, we were able to use custom workflows to map and migrate sensitivity labels for containers through an app, instead of a group owner, without compromising security.
Develop a rollback plan
Migrating to sensitivity labels would not use deployment rings. Once the PowerShell script was executed, the environment would be transformed by the new classification system. Extensive testing was done to identify break points and what the system could handle, but we also built tools to revert to the last good state if needed.
Several scenarios were defined, and of these, key indicators and circumstances were recognized as trigger events that would necessitate a rollback. Simultaneously, certain scenarios also helped to identify if there were any points of failure that we could coexist with until a fix was put in place.
Test tenants can only reveal so much about the real environment, and the team had the data points in place to demonstrate a successful migration but having a rollback plan in place meant they could reverse course and restore Microsoft’s environment to a working state in a pinch.
Readying users
Part of our duty is to inform and educate users about new features.
Sensitivity labels not only meant new label structures and compliance practices, but introduced new concepts, like parent and child labels for containers.
Child labels already existed for documents, but AAD labels were unable to offer this kind of granular definition for containers. The combination of parent and child labels in containers required users to understand how this relationship might impact shared workspaces, especially unique situations like containers that are internally confidential and require an NDA for external users.
Previous steps, like creating consistent taxonomy and classification across labels, made it easier for users to understand the impact of new labels.
Post-deployment validation
After migrating to sensitivity labels, we carefully examined the environment to make sure our workloads interacted as expected. This included testing multiple Microsoft 365 applications, provisioning groups in Viva Engage, and making sure that the correct labels were being applied by default.
Our team also checked to make sure users, legacy applications, and custom tooling were no longer able to make groups without labels. After investigating the Microsoft 365 environment, we felt confident that we could move forward with finalizing the migration to sensitivity labels for other product partners.
Our labelling environment now supports modern productivity while keeping the company safe. Users can freely self-service new groups without accidentally violating our governance practices. Tying policy enforcement to labels transformed a reactive compliance process into a proactive model, reducing the workload on administrators and allowing us to retire several custom solutions.
- Labels now self-enforce. Users who create a group in Microsoft’s environment will now be prompted to select a label classification, which will apply the correct ruleset on creation. Sensitivity labels make tags more than just a string of descriptive text, but a way to assure compliance in a self-service environment.
- Ability to release new policies quickly. We have already created and released new policies and guiding principles, all enabled by the speed and agility surrounding sensitivity labels. Several compliance policies can be tied to sensitivity labels, which makes it easy to push and enforce rules.
- Managing the tenant is easier. Under AAD labels, changing taxonomy meant you had to re-write over string values on every group. Sensitivity labels make managing at a tenant level easier.
With sensitivity labels rolling out across Microsoft, it’s easier for users and for us to support self-service and governance at the same time.
Tags: change management, Microsoft 365, SharePoint, Teams
