Forum Discussion
Solved
Best practices for MIP (sensitivity label) rollout
Hello, I would like to know the best practices of rolling out MIP sensitivity labels. Who do I start with? the pepole with the most insensitive data, or some way else? Are there any ms-reccomended...
- Hi m-waqar
When it comes to sensitivity labels, people tasked with implementation feel pressure to make progress and they start to "wing it." This is a case where it pays to get it right, or as close to right as practical first time because some missteps are hard to undo. You can also get your users offside from day 1 by overreaching.
Treat this like any other initiative that has the potential to impact the user experience for all users and external collaborators. By design sensitivity labels and policies can restrict user access to documents...by design ransomware can do that too.
With minimizing user impact in mind:
Test it out on a small footprint first to appreciate the consequences of encrypting through sensitivity labels and the impact that can have. Perhaps create a test SPO site with mock data.
Use the "test/simulation" capabilities available with policies that consume sensitivity labels. Only enforce the policy once you are happy the results are as expected.
You can apply labels to one location, then modify the label to add another location, scaling out by location.
Make use of the built-in labelling provided by Microsoft.
Apply labels automatically to reduce user friction. Microsoft recommends allowing users to have first crack at labelling manually but that is just one of many, many options (and gotchas) available when it comes to labelling. Example gotchas - when you label a container it labels the container, not the contents of the container. When you remove a label, the label protection settings remain in place on the doc. Automatic labelling can increase but not reduce the sensitivity label level applied to a doc. Example option - I can't say without understanding your environment and goals whether you should use auto labelling and if so, which auto labelling approach. Which is why I recommend taking the slow road to victory here and reading the MS doco before you start. There is loads of reading material which in itself is a clue that Information Protection is not trivial. It's an entire MS exam.
This doc is essential reading and has real-world recommendations.
https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide
This document subsection outlines a strategy for rolling out sensitivity labels.
https://docs.microsoft.com/en-us/microsoft-365/compliance/get-started-with-sensitivity-labels?view=o365-worldwide#deployment-strategy-for-sensitivity-labels
I recommend that you enable co-authoring of docs that sensitivity labels encrypt, if it is not already enabled.
https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-coauthoring?view=o365-worldwide
There are also good, specific learning modules available at https://docs.microsoft.com/en-us/learn/paths/implement-information-protection/
Hope this helps. Ash
Hi m-waqar
When it comes to sensitivity labels, people tasked with implementation feel pressure to make progress and they start to "wing it." This is a case where it pays to get it right, or as close to right as practical first time because some missteps are hard to undo. You can also get your users offside from day 1 by overreaching.
Treat this like any other initiative that has the potential to impact the user experience for all users and external collaborators. By design sensitivity labels and policies can restrict user access to documents...by design ransomware can do that too.
With minimizing user impact in mind:
Test it out on a small footprint first to appreciate the consequences of encrypting through sensitivity labels and the impact that can have. Perhaps create a test SPO site with mock data.
Use the "test/simulation" capabilities available with policies that consume sensitivity labels. Only enforce the policy once you are happy the results are as expected.
You can apply labels to one location, then modify the label to add another location, scaling out by location.
Make use of the built-in labelling provided by Microsoft.
Apply labels automatically to reduce user friction. Microsoft recommends allowing users to have first crack at labelling manually but that is just one of many, many options (and gotchas) available when it comes to labelling. Example gotchas - when you label a container it labels the container, not the contents of the container. When you remove a label, the label protection settings remain in place on the doc. Automatic labelling can increase but not reduce the sensitivity label level applied to a doc. Example option - I can't say without understanding your environment and goals whether you should use auto labelling and if so, which auto labelling approach. Which is why I recommend taking the slow road to victory here and reading the MS doco before you start. There is loads of reading material which in itself is a clue that Information Protection is not trivial. It's an entire MS exam.
This doc is essential reading and has real-world recommendations.
https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide
This document subsection outlines a strategy for rolling out sensitivity labels.
https://docs.microsoft.com/en-us/microsoft-365/compliance/get-started-with-sensitivity-labels?view=o365-worldwide#deployment-strategy-for-sensitivity-labels
I recommend that you enable co-authoring of docs that sensitivity labels encrypt, if it is not already enabled.
https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-coauthoring?view=o365-worldwide
There are also good, specific learning modules available at https://docs.microsoft.com/en-us/learn/paths/implement-information-protection/
Hope this helps. Ash
When it comes to sensitivity labels, people tasked with implementation feel pressure to make progress and they start to "wing it." This is a case where it pays to get it right, or as close to right as practical first time because some missteps are hard to undo. You can also get your users offside from day 1 by overreaching.
Treat this like any other initiative that has the potential to impact the user experience for all users and external collaborators. By design sensitivity labels and policies can restrict user access to documents...by design ransomware can do that too.
With minimizing user impact in mind:
Test it out on a small footprint first to appreciate the consequences of encrypting through sensitivity labels and the impact that can have. Perhaps create a test SPO site with mock data.
Use the "test/simulation" capabilities available with policies that consume sensitivity labels. Only enforce the policy once you are happy the results are as expected.
You can apply labels to one location, then modify the label to add another location, scaling out by location.
Make use of the built-in labelling provided by Microsoft.
Apply labels automatically to reduce user friction. Microsoft recommends allowing users to have first crack at labelling manually but that is just one of many, many options (and gotchas) available when it comes to labelling. Example gotchas - when you label a container it labels the container, not the contents of the container. When you remove a label, the label protection settings remain in place on the doc. Automatic labelling can increase but not reduce the sensitivity label level applied to a doc. Example option - I can't say without understanding your environment and goals whether you should use auto labelling and if so, which auto labelling approach. Which is why I recommend taking the slow road to victory here and reading the MS doco before you start. There is loads of reading material which in itself is a clue that Information Protection is not trivial. It's an entire MS exam.
This doc is essential reading and has real-world recommendations.
https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide
This document subsection outlines a strategy for rolling out sensitivity labels.
https://docs.microsoft.com/en-us/microsoft-365/compliance/get-started-with-sensitivity-labels?view=o365-worldwide#deployment-strategy-for-sensitivity-labels
I recommend that you enable co-authoring of docs that sensitivity labels encrypt, if it is not already enabled.
https://docs.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-coauthoring?view=o365-worldwide
There are also good, specific learning modules available at https://docs.microsoft.com/en-us/learn/paths/implement-information-protection/
Hope this helps. Ash
- Good call Ash, just adding, there is a LOT of docs.
Make sure you are focusing on docs that are less than 12 - 18 months old.
Most of the docs are well up to date so will likely be only a couple of months old
This has recently become more confusing now that MS has rebranded *everything* in the compliance space as Purview - be aware that applying “Sensitivity Labels” to anything referred to a Data Map is likely to be Structured data (i.e. SQL?) and not what you thought it was?
I’ve successfully done this before with the help of SharePoint folks, they can be a big help (I focus on Security) - for my 2 cents, make sure you get the PM capturing all the specific use cases, test EVERYTHING, and take it one step at a time
