Table of Contents
DLP Policy Synchronization Cycle is Only Part of the Story
When I was testing the DLP policies to block external email for Microsoft 365 Copilot processing and to block sharing of files with specific domains or users (SMTP addresses), I was puzzled by how long it took for policies to become effective.
I am accustomed to the delay imposed by the DLP policy synchronization cycle. Microsoft has been trying to speed up synchronization of policy changes across the service, but it still seems to take several hours to propagate policy or rules updates to workloads like Exchange Online, SharePoint Online, and Teams.
However, it wasn’t a question of hours. The new policies took days to become effective. The rule settings looked OK. The Purview portal reported that DLP policy synchronization was complete. But the blocks imposed by the DLP rules stubbornly refused to function.
Eventually the DLP Policies Worked
When dealing with new or preview software, you’re never quite sure if things don’t work because all the necessary software has still to reach a tenant. Inside a cloud service the size of Microsoft 365, it can take weeks for new functionality to reach every tenant. With no control over deployment and no visibility into what has reached your tenant, it’s hard to be sure that a change is fully effective within a tenant. But policy creation worked smoothly, so software deficiencies didn’t seem to be the root cause.
Eventually, everything worked. DLP stopped using external email to ground prompts and prevented users sharing files from SharePoint Online and OneDrive for Business with specific domains. And then a strange thing happened in Activity Explorer, which suddenly reported hundreds of rule matches for the newly enabled policies (Figure 1).
My tenant is small and I typically see just a few DLP rule match events daily. Seeing hundreds of events was odd and deserved investigation. I discovered that the events were retrospective DLP rule matches. In other words, DLP applied its controls not only to new activity, but also to existing sharing links and external email already present in user mailboxes.
As you’d expect, DLP used rule settings to block items. Figure 2 shows details of a DLP rule match for the policy to block external email. The policy settings include a block list for consumer email domains, and this block is for a message from Gmail.com received in September 2022.
Background Processing Delays DLP Policy Enablement
Then the penny dropped. The delay wasn’t caused by policy synchronization. Instead, SharePoint Online and Microsoft Search had to perform background processing to identify and mark items affected by the new policies.
SharePoint Online must identify and mark files that match policy settings so that external users attempting to access those files through sharing links are blocked. Microsoft Search must update its indexes so that Copilot can no longer use external email from specific domains or users as a knowledge source. This processing takes time, especially in large tenants.
A similar principle applies elsewhere in Microsoft 365. Microsoft also adjusts Microsoft Search results in its Restricted Content Discovery (RCD) feature to make sure that Copilot ignores complete sites. If Copilot doesn’t know about items because Microsoft Search doesn’t include the items in its results, then the items are never processed by AI.
Retrospective Application for DLP Policies Makes Sense
Although it might seem strange to apply a policy retrospectively, it makes sense in a DLP context. Organizations use DLP policies for a reason, and if a decision is made to stop sharing files with specific domains or users, then it’s reasonable to check for previous sharing that matches the new rule and implement the block for those items too.
In the same way, if it is deemed appropriate to stop Copilot using external email to ground its prompts, then why should that rule only apply to new email? Old email remains available to Copilot unless specifically excluded, so applying the policy retrospectively ensures that all matching items are treated consistently. And besides, the older the email, the more likely it is to contain obsolete material.
Retrospective application is a useful addition to DLP. It adds to the previous DLP capability of applying rules to new content or actions. The extra background processing means that some new policies can take longer to become fully effective than administrators expect, but the payoff is that existing content is brought into compliance instead of waiting for new activity to occur. In that respect, a little delay makes no difference.
Learn how to use Purview Data Loss Prevention and to exploit the information available to Microsoft 365 tenant administrators through the Microsoft 365 for IT Pros eBook. We love figuring out how things work.