Site Sensitivity and the Documents within

Reading Time: 6 minutes

Now that we can define some protection controls with a sensitivity label definition for SharePoint sites, Microsoft Teams, and Microsoft 365 Groups (referred to as the “container” for the remainder of this post), this starts to give us more control over the container once a sensitivity label has been applied.

[June 2020] This feature is in Public Preview. It can be enabled on your tenant using PowerShell using instructions in the link above. Microsoft has provided this roadmap for sensitivity labels in SharePoint and OneDrive.

[October 2020] If you want to turn off the email notification for notifying a user/owner when a document with a higher sensitivity level is stored on a site with a lower sensitivity level, you can use the following cmdlet: Set-SpoTenant -BlockSendLabelMismatchEmail <boolean>

[June 2021] Included the ‘external sharing’ setting that is now a property of a sensitivity label definition for site and group settings.

The roadmap below is included to highlight the changes that have been implemented since this post was originally published. Item 4 under ‘Top of mind’ is still not implemented.


This post focuses on the current interplay between a container’s sensitivity and the documents sensitivity living within it… something important to understand.

Currently, you cannot “lock in” the sensitivity setting for a container nor ask for a justification when changing it; however, this activity is logged in the Unified Audit log with the activities circled. You will see the old and new value when you change the sensitivity label.

Audit activities


Container Sensitivity

The 4 controls highlighted in the sensitivity label creation wizard shown below are applied to the container when the sensitivity classification is assigned at either container creation time or after-the-fact:

  1. Privacy of a Microsoft 365 group-connected team site (Is it public or private?)
  2. Guest access – whether external users can be added to the site. Remember, the ability to add external users must be enabled at the tenant level first in Azure Active Directory.
  3. External sharing to control if site content can be shared externally.
  4. Conditional Access for unmanaged devices when accessing the container. In preview, you can associate an authentication context with the label to enforce, for example, MFA, under certain circumstances.


A few important things to understand about this:

This is placing controls at the container level providing some access control. The 4 controls do not automatically assign that same sensitivity label to all documents within the container (although Microsoft is considering some capability to do this based on the roadmap). Because of this, you will still want to ensure individual documents within the container have the correct sensitivity label applied to implement the required controls and protection at a granular, document level.

Note: This will continue to hold true even if documents will eventually “inherit” the container’s sensitivity classification as there may still be times when you will store a file with a different sensitivity classification than the container it’s stored in.

Ways to set a document’s sensitivity

Here are some ways to ensure your documents have the right sensitivity setting:

  • set a default sensitivity label in the label policy published to a user (warning: doing this, you run the risk of your default label being less sensitive than your container classification may be since this is not a container-specific setting, but a user setting)
  • leverage client-side labeling: use auto-apply functionality to apply sensitivity labels to content where sensitive information type(s) are detected right when you’re working with a document from within Microsoft 365 apps (Office 365 ProPlus/Business client apps)
  • leverage service-side labeling: use auto-labeling policies to apply sensitivity labels to content at rest in SharePoint Online (and OneDrive for Business) based on sensitive information type(s)
  • leverage Microsoft Cloud App Security: by integrating this with Sensitivity labels you can automatically apply sensitivity labels on a specific library location. Note that there are limitations to this approach. (Reference: Microsoft Cloud App Security and Sensitivity Labels)
  • Eventually… maybe… although not sure how this will be implemented: documents within a container may inherit the sensitivity classification of the container. Microsoft is considering this option.

End-user education

To help end-users safely handle their sensitive content, let’s look at what happens if a document was created/uploaded to a container with a sensitivity label more sensitive than the container it was uploaded to…

Below I’m showing a SharePoint communication site called Legal Affairs that has been classified with a Confidential sensitivity label.

Site Sensitivity

I created a new document in Some Random Library in the site and decided to set the sensitivity of the document to Super Secret. In this tenant, the Super Secret sensitivity label is MORE sensitive (higher priority) than the Confidential sensitivity classification assigned to the Legal Affairs site (image):

Sensitivity label priority

Nothing prevented me from assigning the Super Secret sensitivity label and storing the document on the site, however a few minutes later I received an email advising me/warning me of the potential risk of what I had just done.

Two variants of the email text are shown below – the wording may change over time (circled), however I believe the intent of the message is to highlight to the end-user that either they (or a guest on the site if they’re an owner) has added/uploaded a document with a higher sensitivity than the site is set at.

Email warning

Guest message
If a guest has added a file with higher sensitivity

Why would this matter?

What’s the risk? The sensitivity label on a document protects the document regardless where it is stored, or whatever device it is accessed on because the sensitivity is stored with the document. Why would it matter if you stored it on a site with a lesser sensitivity control?

Although the protection controls would still be applied to the document based on its sensitivity label, there are a few scenarios I can think of where it would matter:

Scenario 1: If the site’s classification allows guest users to be added to the site and you store a document with a higher classification on it that should prevent external to access it, an external user won’t be able to open the document (they’ll receive the ‘Sorry, you don’t have permission to open this document’ message), however they will still be able to see the document listed in the library. Sometimes just seeing the title/properties of a document is a security risk.

In this example, an external user invited into a site classified as General can still see the Top Secret documents in the library even though they do not have permission to open them. (assuming the Top Secret sensitivity label has been configured with Rights Management to prevent access)

This slideshow requires JavaScript.

Scenario 2: Imagine you have the following 2 sensitivity labels defined with the following unmanaged device settings (image):

  • General: allow full access on unmanaged devices
  • Top Secret: block access on unmanaged devices

If you were to upload a document labeled as ‘Top Secret’ to a site classified as ‘General’, you would still be able to open this document from an unmanaged device simply by it being stored on a site with a lower classification (assuming you had sufficient rights to open it).

This is because, at the current time, the unmanaged device controls are at the site (container) level only and NOT at the document level.

This slideshow requires JavaScript.

Scenario 3: Reinforcing good end-user behavior when handling sensitive content.

It’s always a good idea to let a user know they’ve done this in case it was not intentional or if they don’t realize they’ve stored a document that is considered more sensitive than what the site will allow. It’s the pause this creates that allows an end-user to validate/acknowledge their action. Although an end-user is free to ignore the warning, the email suggests some follow-up actions for the end-user to take:

  • move the file to a different site
  • change the sensitivity label on the file if it was the incorrect label
  • change the sensitivity of the site

I’m looking forward to the additional controls that will be associated with a sensitivity label over time at both the granular, document level, as well as at the container level.

Thanks for reading.


Credit: Photo by Ann H from Pexels


  1. I am waiting for MS to provide platform or service level publishing of labels. Because the label controls may only apply to sites and have no reference on a site level. If a company has a classification “General” this may be public/private (I know they have added None) or external/internal, you cant guarantee the external access based on classification, and applying this label “blocks” graph api from overriding allowexternalaccess

  2. Great article as always. It is worth noting that the Sensitivity Labels are applied at the Site Collection level, and although you can currently set them at the subsite level, they will apply to the whole collection. So, if your architecture has many different classifications of site docked inside a collection then this may need to be rearchitected to make use of these labels.

    Also, there is currently no way to disable the automated email, or customize it. I believe MS are planning to offer the ability to turn this off at a tenant level to enable adoption without it.

    1. Hi James,
      This is yet another reason for avoiding subsites. If an org has decided to use subsites, then they need to realize they have to be the same sensitivity classification.
      When I find out about how to disable the message, I’ll include something in the post.

  3. First of all, congratulations for this site… I really like your articles…

    I am working with sensitivity labels and it has been a challenge.

    Recently, I am having a issue with pdf signed. We can’t assign a label to pdf file signed and in my company we work with a lot of this kind of documents. Do you know If microsoft is working in something to solve this problem or if there is something that we can do to overcome this problem?

    Thanks you,

    1. Hi Andre, i haven’t personally tested this. I believe auto-applying sensitivity labels to PDFs is on their roadmap. Perhaps ask your question on the Tech Community for further reach.

  4. Hi Joanne,

    thanks for this great article!
    We are just rolling this out. But some feature is missing for me: Initial labelling.
    Do you know if there is a way to have all already available documents classified as “Internal”?

    We enabled the labels on all possible areas.

    Thanks for sharing your knowledge!


  5. Dear Joanne,

    Thanks a lot for the great article! We are implementing sensitivity label on a container level, so Site and Unified Groups to control guest access to Teams.

    We are facing a problem: The labels are being assigned via Teams client and replicated perfectly to all M365 objects (team, group and sp site collection) – but if the user updates the label, the update is replicated to every object except to the sp site collection. This leads to the issue that the guest user cannot do any operation with files. Have you came across a similar problem?


    1. Hi Amelia, I have not tested this. Have you asked this same question in the Microsoft Tech Community? You will have broader reach for your question there. If you don’t get an answer there, ping me back and I’ll dig into it.

  6. Hi Joanne
    I have the same observation as Amelia Hernandez.
    When label is changed on existing Teams, then this change is not replicated to the SPO site collection.
    Can you dig into it?
    When googling this topic your page pop up – I cannot find any other docs on this topic.

    1. Hi Maciej – I don’t have spare cycles to dig into it right now. Please post your question on the Microsoft Tech Community in the S&C area for broader reach.

    2. I will be testing this scenario and will be sharing my findings with the product team if I can replicate the issue.
      I’ll follow up here with my findings.

    3. Have confirmed if you change the sensitivity label on the SharePoint side, it will change it on the Team side (not immediately, but within the hour). However… if you change it on the Teams side, it doesn’t seem to change it on the underlying SP side.
      My request of you is to log this as an official issue thru your Microsoft support channels. Several customers have noticed this. Hope this helps.

  7. Great blog….. Well i have a query. I have a require checkout enabled document library. While opening the file message gets pop up and says your org requires to select a label. Can you help me with this.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.