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, turn it on, but disable alerting and user notifications. This lets SharePoint run the re-crawl and evaluate content against the new conditions without flooding your alerts dashboard or confusing users with policy tips on old documents.

While the re-crawl runs, check the activity explorer to see match volumes. You will know exactly what the impact will be before anyone sees a notification. No surprises.

Once the re-crawl finishes, turn alerting and notifications back on, then disable the old policy. This swaps the policies cleanly. The re-crawl already happened quietly, so when alerts start flowing they reflect genuine new activity, not years of historical data.

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.