How to Secure Sensitive Data in Microsoft 365


We’ve come a long way since those days and have seen technology evolve to support data stored in business cloud platforms such as Microsoft 365. In recent years, the digital revolution has made data more portable and more accessible, but crucially it has also made that data more vulnerable in many ways. Fortunately, if your organization use the Microsoft cloud, you have several ways to secure sensitive data with Microsoft 365.

Still, many organizations are still unaware of the risk posed when they store their data in the cloud, and they may assume that controls for data security and privacy are present, enabled, and configured by default. This is a dangerous assumption, and the lines can get quite blurred. In this article, I’ll explain why you should secure authenticated access to Microsoft 365 services by following the principles of Zero Trust security.

Why you should secure your data in Microsoft 365

Data is the lifeblood of any organization – I’m sure this is a phrase you will have heard, and it is absolutely accurate in my opinion.  Businesses have always relied on data, which is collected, analyzed, processed, stored, and eventually disposed of.   

When I started my first job at a law firm in the late 1980s, the technology that we use today was not available. Yet data still flowed through the organization in the form of memos, internal envelopes, while you were out messages, printed time sheets, and storage boxes full of client files. If such physical data assets were lost, misplaced, or stolen, this would represent a significant risk to the organization. 

As of today, if you host your IT infrastructure on-premises, then you are completely responsible for this. However, as you begin to move to the cloud, some of these responsibilities are transferred to Microsoft in what has become known as the shared responsibility model between Microsoft (the provider) and you (the customer).

The shared responsibility model when data is stored in the cloud 

This is illustrated in the table below where we detail the responsibility model for on-premises infrastructure, a Software as a Service (Saas) model, a Platform as a service (Paas), and an Infrastructure as a Service (IaaS) model.

In the following table:

  • M = Microsoft
  • C = Customer
  • S = Shared responsibility.
 Responsibility SaaS PaaS IaaS On-premises
Responsibility always retained by customer  Information & data C
Devices C
Accounts & identities C
Responsibility varies by type Identity & directory infrastructure C
Applications MC
Network controls C
Operating system C
Responsibility transfers to cloud provider Physical hosts C
Physical network MC
Physical datacenter MC
The shared responsibility model when data is stored in the cloud 

In every possible model shown above, the responsibility for protecting data and information is the responsibility of the customer, i.e. you! So, where do you need to begin your organization’s journey to ensure that the data you store in Microsoft 365 services such as Microsoft Teams, SharePoint, and OneDrive is appropriately protected and secure?

Well, it doesn’t start with the data itself. It starts with identity and authentication. 

The principles of Zero trust security

There is considerable guidance available to IT administrators on how to secure authenticated access to Microsoft 365 services. Microsoft’s recommended best practice is to adopt a strategic approach based on the principles of Zero trust security, which are explained in the table below. 

Zero trust principle Purpose 
Verify explicitly Ensure that authentication to your environment is based on user identity, location, device health, service or workload, data classification, and anomalies. 
Assume breach Minimize your potential blast radius. Segment access and use end-to-end encryption and analytics to gain insights and improve threat detection and defences. 
Use least privileged access Use just-in-time and just-enough-access (JIT/JEA) to limit user access, and secure data with adaptive risk-based policies 
The principles of Zero Trust 

Effective identity authentication is the key building block to this process. And it’s astonishing to note that so many organizations are yet to take some very simple steps to secure their identity trust fabric methodology.  

Why multi-factor authentication (MFA) is essential

Implementing multi-factor authentication (MFA) is the most effective way to start. MFA is not something that is simply nice to have, it is crucial in these times of nation state cyber-attacks. It is estimated that 4 out of 5 successful cyber-attacks are delivered to environments where MFA has not been implemented.  

MFA in its most basic form is available across all Microsoft 365 environments. You can implement MFA even if you do not have Azure Active Directory premium licensing. 

Multi-factor authentication service settings in Azure Active Directory
Multi-factor authentication service settings in Azure Active Directory (Image credit: Rising)

MFA on its own is the most basic form of Azure AD Conditional Access, which when implemented across a Microsoft 365 organization can control authentication using policies that monitor signals from endpoints, risky sign-in activities, compromised users, compliance standards using Artificial Intelligence, and more. Conditional access can allow or block access to Microsoft 365 services based on meeting the required criteria set out in organizational policies. 

Figure 2: Conditional Access overview in Azure Active Directory 
Conditional Access overview in Azure Active Directory (Image credit: Rising)

But do these principles go far enough? Do they extend to protecting your actual data which you store in the cloud? The simple answer is no, they do not!

Securing authentication access to Microsoft 365 is indeed critical and it helps to safeguard against unauthorized parties and malicious actors from gaining entry to your tenant. But this does not apply any sort of protection to the actual data. 

So how do you go so far as to prevent sensitive and personal information from being lost, leaked, or otherwise misused?  This is where Microsoft Purview comes into play. 

Protecting data with Microsoft Purview 

Microsoft Purview is the new umbrella term for Compliance features and services within Microsoft 365, and as it relates specifically to data protection there are two key features to consider, which are Data Loss Prevention (DLP) and Information Protection. 

Data loss prevention and Information as part of the Microsoft Purview solutions catalog 
Data loss prevention and Information as part of the Microsoft Purview solutions catalog (Image credit: Rising)

Before you consider implementing either of these technologies, however, it is important to step back and consider the data stored within your Microsoft 365 environment. What types of information do you hold?   

Data classification

The Data classification section in the Microsoft Purview Compliance Center helps you to identify this by matching Sensitive info types and Trainable classifiers to content detected in emails, documents, containers, and chat messages. 

Figure 4: Data classification overview in Microsoft Purview 
Data classification overview in Microsoft Purview (Image credit: Rising)

The Content Explorer section will guide you to the Sensitive info types that you are storing in Microsoft 365. Examples of these can include financial and medical data. And they can be broken down by region. 

Data classification Content explorer view in Microsoft Purview 
Data classification Content explorer view in Microsoft Purview (Image credit: Rising) 

Using Data Classification in conjunction with Assessment templates, which are available in the Microsoft Purview Compliance Manager, you can derive the correct Data Loss Prevention policies, and Information Protection sensitivity labels that you need to stop your information being accidentally shared or accessed by unauthorized parties. 

Data Loss Prevention (DLP) 

With Data Loss Prevention policies – sensitive information such as medical records and credit card numbers can be detected and prevented from accidental or malicious sharing. DLP policies may be targeted to the following Microsoft 365 services: 

  • Exchange email 
  • SharePoint sites 
  • OneDrive accounts 
  • Teams chat and channel messages 
  • Microsoft Defender for Cloud Apps 
  • On-premises repositories 
  • Power BI (in preview) 
  • Endpoints 

The policies you configure can be set to alert the end user when there is a policy match and block the activity. In some cases, policies can allow the end user to override the policy and provide a justification for this. And / or report the policy match as a false positive. An example of how a user is notified of a DLP policy match is shown below. 

User alerted to a DLP policy match in Microsoft Word
User alerted to a DLP policy match in Microsoft Word (Image credit: Rising)

By clicking on More Options, the user can see more information about why a policy match has occurred, and any actions available to them, such as overriding the policy or reporting a false positive. This is shown in the image below 7. 

More information on the DLP policy match
More information on the DLP policy match (Image credit: Rising)

There are a rich set of features that can be configured within a DLP policy, which include low and high-volume detection rules, conditions, alerts, and notifications. You can even use DLP policies in conjunction with sensitivity labelling. 

Sensitivity labeling 

Sensitivity labeling is a powerful Information Protection feature within Microsoft Purview that can be used to classify, mark, and encrypt files, emails, and containers (such as Teams or M365 groups) so only those authorized for that content can access it.   

Sensitivity labels differ from DLP policies in the sense that they are designed to protect your content from being accessed outside of the organization by parties who are not authorized for it. When content is encrypted by a label, that protection travels with the content no matter where it goes.  So, if someone not authorized to consume content protected by a label receives it, they will not be able to access it without credentials that can be validated against the applied label permissions. 

The labels that you configure for your organization may be applied manually or automatically depending on your requirements and your level of Microsoft 365 licensing, and these labels are made available to your end users by configuring label policies, which will surface the required labels within Microsoft 365 applications for your users including Outlook, Word, and Excel. The image below shows how the Sensitivity bar appears with Microsoft Word and presents the available labels. 

Sensitivity labels shown within Microsoft Word 
Sensitivity labels are shown within Microsoft Word  (Image credit: Rising)

Additionally, labels can be targeted at the container level to protect Teams, SharePoint sites, and Microsoft 365 groups. The image below shows a sensitivity label applied to a team in Microsoft Teams. 

A container label applied to a team in Microsoft Teams
A container label applied to a team in Microsoft Teams (Image credit: Rising)

It should be noted that there is no correlation between labels applied at the container level and the item level, and no inheritance takes place on files within a team that are protected with a container label. 


Securing your sensitive data within Microsoft 365 is something that you should approach with a strategy based on defense in depth. The more principles of security, compliance, and identity that you enable and configure, the better protected you will be.   

For example, if you have sensitivity labels and policies configured for your users, but you are not enforcing MFA, you are simply making an attacker’s job easier, as they can access your Microsoft 365 data assets without a layer of protection that could have stopped them from getting this far. But now they are in, and they can potentially access your sensitive data and maybe even remove the encryption that labeling provides.   

Once your data is out in the wild unprotected, it’s already too late. So, please take the necessary steps to protect your organization today with a zero-trust strategic approach to Security, Compliance, and Identity. You’ll be very glad that you did!