Analyzing Document Label Mismatch Audit Records

Document Label Mismatches With Sensitivity Labels of Different Priorities

Two years ago, Microsoft launched support for sensitivity labels in SharePoint Online, including the ability to detect a mismatch between the label assigned to an Office document and the label assigned to the site storing the file. The mismatch occurs when the document library has a higher priority than the site label. For instance, someone might upload a document labeled Highly Confidential to a site labelled General Access, or they might update a document to assign it with a label with a higher priority than the site label.

A document label mismatch mightn’t be a problem. Storing sensitive material in a site designated for less sensitive information could be exactly what the user intended to do. However, a mismatch might also create a potential issue when users with access to a site might see highly confidential material. In practical terms, the users might not be able to open the files because they don’t have the necessary rights, but they can see file metadata such as titles, authors, and so on.

Audit Record for Mismatch Missing Important Data

When it detects a document label mismatch, SharePoint Online generates a DocumentSensitivityMismatchDetected audit record in the Office 365 (unified) audit log. The audit record contains information about the:

  • The file name.
  • The site URL and relative location (full URL).
  • Sensitivity label and priority for the document label.
  • Sensitivity label and priority for the site label.

The big piece of missing information is the account name (user principal name) of the user who caused the document label mismatch. It’s not as if SharePoint Online doesn’t know who caused the problem. After all, SharePoint Online sends the miscreant an email notification (Figure 1) about the issue to prompt them to consider if a label change is necessary.

SharePoint Online email notification for a document label mismatch
Figure 1: SharePoint Online email notification for a document label mismatch

Dealing with Missing User Information

The solution exists in other audit data. When someone updates or uploads a document, SharePoint Online captures an audit event for the action. These events capture user information. Later, SharePoint detects the mismatch. SharePoint Online stores documents in lists, and each item in the list has a unique identifier. The identifier is in the audit event for the upload or change. It’s also in the event generated when SharePoint finds the mismatch. Therefore, we can reference the upload/change event to find who created the mismatch.

To illustrate the point, I wrote a PowerShell script to:

  • Connect to the compliance endpoint to collect information about the labels used in the tenant.
  • Build a hash table of the label identifiers and display names. The audit events log label identifiers, so we can use the hash table to find the display name.
  • Search the audit log for FileUpdated, FileModified, and DocumentSensitivityMismatchDetected events. The script looks back over the last 80 days. Given the volume of FileUpdated events often found in tenants, you could reduce this period.
  • Split the audit records into those for document mismatches and the other events.
  • Create a hash table composed of list identifiers and usernames from the document upload and change events.
  • For each of the document mismatch events, lookup the hash table to match against the list identifier and return the username responsible for the mismatch. Also resolve the sensitivity labels assigned to the document and site to the label display names.
  • Report the results. Figure 2 shows typical results as viewed through Out-GridView.

The full script is available from GitHub.

Audit data for document label mismatches reported by PowerShell
Figure 2: Audit data for document label mismatches reported by PowerShell

Some people like to block the messages sent by SharePoint Online using an Exchange Online mail flow rule so that they can send their own notifications to users. It would be easy to take the report data generated by the script and use that information to create and send appropriate messages, perhaps using the Microsoft Graph PowerShell SDK.

Blocking Email Notifications

To stop SharePoint Online sending emails to advise users about label mismatches, you can update the tenant configuration:

Set-SPOTenant -BlockSendLabelMismatchEmail $True

The setting affects all sites. It isn’t possible to block the notification emails about mismatched labels for selected sites. Blocking emails also stops SharePoint Online writing audit events to record document label mismatches. Microsoft plans to break the link between the two actions so that a tenant can block emails without stopping the creation of the audit records, but no date is available for this update.

Audit Mystery

It’s a mystery why Microsoft decided that the DocumentSensitivityMismatchDetected shouldn’t contain the user information, I see no logic in that decision, but once you know about it, you can compensate. Isn’t PowerShell wonderful?


Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Leave a Reply

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