If your organization has struggled to get started with delivering data security and insider risk management capabilities (specifically, with the help of Microsoft Purview technologies), you’re not alone.

Honestly, I’ve noticed most organizations struggle with designing and implementing these critical practices.

Why is it so difficult then? In my experience so far, there can be at least a few key reasons to this struggle.

• Misplaced (or lack of) ownership
• Low understanding of current risks
• Practical technical experience and know-how

Here are my thoughts on each of these, and some other notes on Information Protection sensitivity labeling in particular.

Misplaced (or lack of) ownership

IT can sometimes initially get ownership of some emerging and necessary practices just because technology and cloud services are somehow involved. Data and people security have often turned out to be one of these.

I’ve run into many organizations delegating sole design responsibility for capabilities like sensitivity labeling, data loss prevention, data lifecycle or insider risk management to IT, because they sound adjacent to cybersecurity tooling like the Defender product family.

This, with all due respect to my talented and hardworking colleagues in IT, might be ill-advised.

While IT is definitely the function that implements these capabilities and translates non-technical goals to technical controls, the benefits gained from Purview solutions often align more closely with the goals of functions like Legal, Compliance and Risk Management. Functions such as HR and Comms also play a key role in helping to ensure successful outcomes.

Truthfully, significant cross-department collaboration is key to any successful Purview initiative. This is a core challenge and the reason why many information protection and insider risk management development programs can stall after facing early design difficulties.

IT can definitely help translate business risks and requirements to technical controls and implement the necessary tooling, but only after other, more suitable functions define the broader challenges and desired outcomes in non-technical terms.

Low understanding of current risks

It is tempting to try to move directly to designing and creating technical controls without first understanding your current data estate and the risky movements of sensitive information in it. However, any Microsoft Purview solution not informed by real visibility is bound to be based on guesswork and won’t necessarily help mitigate the most significant risks. Data security is not just about checking a box and moving on. It’s a continuous, iterative process.

That’s why I advocate taking the time to conduct a thorough discovery phase (in technical terms, this means leveraging both built-in and custom sensitive information types, DLP policies in audit mode, Defender for Cloud Apps file policies, on-premises MIP scanner, Sentinel / Log Analytics etc, Content Search, Insider Risk Management analytics etc.) before even designing things like sensitivity labels and DLP controls.

A solution based on analysis of real-life data is always better than a solution based on guesswork.

Practical technical experience and know-how

To not disrupt production, you really need to understand how Microsoft Purview features work under the hood. Not everything is spelled out in documentation.

For example, configuring a sensitivity label to enable applying encryption to sensitive information seems straightforward, but when you take things into production, you might notice that some systems used in critical business processes don’t actually work that well with encrypted files, which needs to be taken into account. Let’s say I’ve learned this the hard way.

There are a ton of tweaks and refinements unique to each organization that are usually needed to transform an initial design document into a sustainable, production-ready solution. Many of these can be anticipated when you have experience, while some you will only detect and adjust for over time.

A lack of experience can leave too many need-to-know questions unanswered, presenting unacceptable risks of a disruption to production.

Some thoughts on sensitivity labeling

For data classification through Microsoft Purview Information Protection sensitivity labels – one of the key first steps for many orgs – there is a double challenge:

The obvious

You need to get people to apply sensitivity labels to documents, email, Teams teams etc. without disrupting productivity too much. This challenge is one most organizations I have worked with have been able to anticipate.

Yes, forcing everyone to manually classify and label everything they produce can accomplish the surface-level goal of being able to check the box called “data classification is in use”. And yes, people will grumble at first and then probably get used to the new normal over time.

However..

The not-so-obvious

Goodhart’s law applies to many things, including tracking the success of Microsoft Purview sensitivity labeling rollouts:

When a measure becomes a target, it ceases to be a good measure. 

What I mean by this is that just because people are labeling things, doesn’t mean they are labeling them correctly.

If people are expected to be the only ones responsible for deciding the criticality of the information they produce, there’s a problem: the majority of individuals in an organization are not likely to have a comprehensive understanding of which sensitivity label should be used for which type of information – especially when it comes to the highest sensitivities.

This means that you are looking at nearly certain, massive under- or overclassification of your data estate if you go with manual labeling (without or especially with a default sensitivity label configured) alone.

This, in turn, can render the whole practice of classifying information far less effective and also destroys accurate visibility to the most critical and risky bits of information that data security responsibles need.

All of these points mean that I think you need to reinforce a well-designed data security rollout with support of several kinds:

• Communications
• Traditional training
• Reinforcement of correct practices with DLP Policy Tips
• Help from internal champions networks
• Amplification and support from business leaders
• Automatic sensitivity labeling for the most critical scenarios

In short, if you don’t keep people in the loop and only measure whether or not data is being classified, you’ll end up falling in the trap of Goodhart’s law.

The indicators I look for

There are some key indicators I look for in an organization when I am assessing their readiness to build data and people security practices:

• Well-defined roles and responsibilities
  • Legal, Risk Management and/or other non-IT functions create the demands and set high-level goals
  • IT designs and implements – with strong design input from the functions above and others.
• An understanding of the “crown jewels” – the ability to describe what the organization’s most important data looks like, where it should be located and how it should be handled
• Knowledge of approved data egress scenarios – whether or not the organization understands and can define the legitimate cloud services and external organizations their data can and should be egressed to, especially outside of Microsoft cloud services.
• Clarity of goals and intent – whether or not an organization is able to define the desired outcome for any data & people security initiative in non-technical terms. For example:
  • “We want to be able to identify, classify, protect and control the movements of our most sensitive and risky information in Microsoft and other cloud services.”
  • “To ensure organizational resilience, we need to be able to discover and manage our most significant insider risks to help ensure valuable information isn’t exfiltrated through negligence or malicious intent.”

So if your organization is struggling..

If you feel like your organization is struggling to improve data security using Microsoft Purview capabilities, the tried-and-tested starting point for me has been to..

• Gather a team of people from the functions I described (and others you might identify as relevant) and define clear data & people security goals & outcomes everyone can both understand and get behind.
• Focus on discovery first. Understand which information is the most valuable (=risky) and which real risks are the most significant. Rely on real analytics from Purview tools and not just educated guesswork.

After executing these properly, you’ll find the following steps significantly easier to pull off with confidence.