Changing a DLP policy caused thousands of alerts on old data

The team had a working DLP policy covering SharePoint and OneDrive. It detected credit card numbers with a minimum count of 5 per document. They wanted to tighten it to a count of 1.

They edited the existing policy rule, changed the SIT instance count from 5 to 1, clicked Done, and saved. Within hours the DLP alerts dashboard was flooded. Thousands of alerts on documents that had been sitting untouched in SharePoint for months or years.

The data was not new. The policy change caused SharePoint to re-evaluate everything in scope.

Every DLP workload evaluates content on events - when someone uploads a file to SharePoint, sends an email, or posts a Teams message. SharePoint and OneDrive are no different. If a user uploads sensitive content to a site covered by a DLP policy, it triggers an evaluation immediately.

But SharePoint and OneDrive also have a second mechanism. They re-crawl existing content when a policy changes. When you modify a policy rule condition - SIT thresholds, content types, scope - SharePoint re-evaluates everything already sitting in the locations covered by that policy. If your policy covers all SharePoint sites, it re-scans the lot.

This is not a bug. SharePoint needs to know whether existing content now matches or no longer matches the updated conditions. The only way to do that is to re-process what is already there.

If you have alerting or incident reports enabled on the policy, every new match generates an alert. A single threshold change can produce thousands of alerts on old data that now meets the criteria.

This creates two problems. First, the alert noise is overwhelming. Your security team spends days triaging alerts that are not actual incidents - they are historical data that always existed but previously fell below the threshold.

Second, if you have user notifications turned on, users start receiving policy tips on documents they have not touched in months. This creates confusion and erodes trust in your DLP programme.

The re-scan can also take time. We have seen it take up to a week for large environments to finish re-processing. During that window, alerts keep trickling in.

Instead of editing an existing policy, create a new policy with the updated rules in simulation mode. This lets SharePoint run the re-crawl and evaluate content against the new conditions without generating alerts or enforcing actions.

Once simulation completes and you can see the match volumes in the activity explorer, you know exactly what the impact will be. No surprises.

Then enable the new policy and disable the old one. This swaps the policies cleanly. You still get the re-crawl, but you controlled when it happened and reviewed the results before anything fired.

This is slower and less convenient than just editing the rule. But it avoids a flood of alerts on old data, confused users, and a security team buried in false positives.

The rule of thumb: treat any DLP policy change that affects SharePoint or OneDrive conditions as a new deployment, not an edit.