Monitoring Updates to Sensitivity Label Policies and Labels

Keeping an Eye on Who’s Updating Sensitivity Label Policies

A reader remarked that there doesn’t appear to be a way to monitor changes made to Microsoft Purview sensitivity label policies or retention label policies. Given that retention policies and labels dictate how long content remains within a tenant and sensitivity labels and policies dictate who can access content, this seems like an oversight. The expectation expressed was that the Purview compliance portal should show who last updated both policies and labels instead of just the last modified date (Figure 1) together with who created the policy.

Displaying the last modified date for labels and policies is easy because Purview updates the objects each time an administrator makes an amendment. Showing who created a policy is mildly interested, but knowing who last changed a policy is more interesting, especially for organizations that want to exert tight control over who manages labels and policies. However, the only place Purview captures details changes is in the audit records for updates.

I don’t know why Microsoft doesn’t stamp label and label policy objects with details of the account used to make changes. It’s probably because of two factors. First, the presence of properties like WhenCreated and WhenChanged is common for PowerShell objects, but I can’t recall ever seeing a property to note the account that last updated an object like a mailbox, site, or group. Second, the audit log is designed to capture much more information about object updates than just who made the change.

A case can be argued that there’s no point in recording who changed an object in its properties when that information is available in the audit log. On the other hand, finding and retrieving the information about who last changed a label or label policy from the audit log is not going to be a fast operation, which is probably why it’s not done.

Searching the Audit Log

Extracting information from the audit log is a well-worn trail at this point and the basic mechanics are well understood.

• Identify the operations you want to find audit events for.
• Search the audit log for those operations (like Set-LabelPolicy to update a sensitivity label policy).
• Analyze and report the data.

Script to Find and Analyze Audit Events for Changes to Labels and Label Policies

To demonstrate the technique for updates applied to sensitivity labels and label policies and retention labels and label policies, I wrote a PowerShell script (downloadable from GitHub). The script:

• Connects to Exchange Online, the compliance endpoint, and the Microsoft Graph PowerShell SDK.
• Retrieves information about sensitivity labels and creates a hash table to resolve label GUIDs found in audit records to display names.
• Runs the Search-UnifiedAuditLog cmdlet to look for Set-LabelPolicy, Set-Label, Set-RetentionCompliancePolicy, and Set-RetentionComplianceRule events. The first two deal with sensitivity labels and policies. The second deals with retention policies and policy rules.
• There’s also an “Update label” event that seems to capture updates to sensitivity labels. Unlike the other events, these actions are performed by a service principal called Microsoft Exchange Online Protection. Some events are logged in what seems to be a background process that updates all the labels in the tenant at one time. Other Update label events occur immediately following a Set-Label event. One interpretation is that the Set-Label event follows an update to a label made in the Purview compliance portal. A subsequent Update label event then occurs if the sensitivity label applies encryption, and the update is for the Microsoft Information Protection template for the label.
• After finding the audit records, analyze the audit payload in each to extract the relevant information and capture the data in a PowerShell list. The audit payload differs across audit events, so interpretation can be a mixture of knowledge and inspired guesswork (here’s an example of analyzing audit events generated when users assign sensitivity labels to files).

The results are shown in Figure 2.

Demonstrating a Principle

The script is intended to illustrate the principle of using audit events to track changes to labels and label policies and improvements to the code are possible. For instance, only one service principal ever seems to turn up in the audit events (75367c9a-9a5b-41be-840f-ee9ee448c1f5, Microsoft Exchange Online Protection). If this is the case, then a hardcoded check is sufficient to resolve the GUID to a display name and no connection is needed to the Microsoft Graph PowerShell SDK. For now, the call to the Get-MgServicePrincipal cmdlet remains to handle the situation where other service principals update labels.

Knowing who changed a sensitivity label policy is an example of how tools like PowerShell fill in gaps left in Microsoft 365. Another example is monitoring changes made to container management labels assigned to groups and teams. Both demonstrate why mastering PowerShell is a good skill for tenant administrators to gain. Apart from filling in some gaps, you’ll also learn a lot more about how Microsoft 365 works, and that’s a good thing.

---

Make sure that you’re not surprised about changes that appear inside Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.