Planning for a Microsoft Information Protection (MIP) deployment can seem complicated at first; however, the recommendations in this article can help guide you in the right direction. An efficient design will result in a simpler deployment, which will allow for a faster and more widely adopted end-user experience. For an introduction to MIP sensitivity labels, see Part 1 of this blog.
Overall Design
The design of your sensitivity labels and label policies should be based on compliance standards or other business requirements such as unique department needs. Although a specific department may have a need for a highly restrictive label, think about the rest of your organization because you can likely use the same label elsewhere. Deploying custom labels to specific groups of users should be limited because it complicates your deployment and in many cases isn’t necessary. When you consider how your labels will be deployed to various departments, you’ll likely find that various generic labels may be a more efficient design.
When you create similar sensitivity labels (based on purpose or targeted to a specific group of users), they can be grouped together under a single label called a top-level label. You can create sub-level labels under a top-level label. This allows for better organization overall, as well as simplifying groups of labels for end users. However, the top-level label is used only for organization; any settings configured on it are ignored. Sub-level labels don’t inherit any settings from their parent label. Figures 1 and 2 show examples of top-level versus sub-level labels.
A well-thought-out hierarchy for your top-level labels and sub-labels is critical to successful end-user adoption. Ideally, you should have no more than five top-level labels; any more than that would be rare in a well-planned deployment. Similarly, having more than five sub-labels within a top-level category is also rare. Overcomplicating the deployment with more than five top-level labels or sub-labels can cause end-user confusion and increase the level of training required for successful adoption. We often deploy a simple variation of Public, Confidential, and Restricted as top-level labels and limit the sub-labels to three.
Naming Conventions
A sensitivity label’s name is as important as the description that’s added to it. In general, the name shouldn’t imply any protections; however, it should be easily understood by users. For example, the Public label could have a description of “Data that can be consumed by anyone, internal or external with no restrictions.”The Confidentiallabel could have a description of “Data that can be consumed by employees, consultants, contractors, and business partners.”
Clear and concise names and descriptions for each sensitivity label (top-level or sub-level) will help guide users to make the correct selection quickly. Accurate names and descriptions will also reduce the chance that a user selects an inappropriate label for the content they need to protect.
Restrictions
When starting a design, you may be tempted to create a sensitivity label based on allowing a user to perform a certain function; however; that’s the opposite of what should be done. You should create a sensitivity label based on the restrictions it enforces. For example, a Confidential label could be deployed enforcing restrictions to prevent the ability to edit, copy, or print any content from a protected document. As another example, a Restricted label could be deployed that has similar restrictions to Confidential but also enforces document encryption to restrict access only to specified users. Thinking about label designs based on restrictions allows greater flexibility for reusing labels and limits the number of labels you’ll need to create and deploy.
Deploying Labels to Users with Label Policies
Label policies have priorities associated with them to assist with potential conflicting assignments. Although an end user can be assigned multiple label policies, only the settings from the label policy with the highest priority will take effect. The label policy with the lowest priority is shown at the top of the list, whereas the highest priority will be at the bottom. This is especially important when using special case policies for specific departments because, for example, a standard policy deployed to all users may exist in addition to an HR department policy. Let’s assume the standard policy was created first and as a result is first in the list, which would be the lowest priority. The HR department policy was created later and is lower in the list. If the standard policy has a default label of Confidential and the HR department policy has no default label assigned, the end user won’t have any default label enforced. However, if you reverse the positions in the list, moving the standard policy below the HR department policy, the end user will have a default label of Confidential enforced.
Super User Assignment Using Privileged Identity Management
The super user feature is critical because it allows an administrator to override the labels applied to content. If the content owner is unable to modify the label or permissions for any reason (e.g., out of office and unavailable, employee terminated, etc.), the super user can make changes. Although super user access can be assigned directly to a user account, best practice is to deploy to a group instead so you can utilize the just-in-time features of Privileged Identity Management (PIM) if you have Entra ID (formerly Azure Active Directory) Premium P2 licensing in your tenant. Utilizing PIM to provide access to the super user functionality allows for audit tracking because the user must activate the feature when it’s needed, and justification is required during that process. This also means that a user who has been granted the ability to act as a super user isn’t always operating with those permissions, but only when needed—and then the rights are removed automatically.
Minimize Complexity
Deploying MIP efficiently takes some planning to avoid duplicate sensitivity labels or large numbers of label policies. Before you start a pilot deployment, be sure to analyze the requirements within your organization and individual departments so that your deployment can be completed with as minimal complexity as possible. Limiting complexity also promotes better end-user adoption.
If you need help with planning a project to ensure its success, contact the experts at Ravenswood Technology.
