Audit-Based Alerts Retired from March 25, 2025

Publish bad news on Friday is the advice for anyone who wants the news to create less of a fuss. Publishing the news late on Friday before a holiday the following Monday (U.S. Presidents’ Day) might do an even better job of suppressing criticism. Some will consider the announcement in Message center notification MC1006620 (15 February 2025) that “Purview will retire the event alerts capability within the Purview Audit solution on March 24, 2025” to be bad news. It all depends on whether you use alerts based on audit events to learn when something happens in a tenant.

Activity Alerts

Microsoft introduced activity alerts and alert policies soon after the introduction of the unified audit log in July 2015. The idea is simple. The audit log holds some extraordinarily valuable information about what happens in a tenant, but a busy tenant can generate hundreds of thousands of audit events daily. Human administrators don’t have the time to keep on checking if events of interest (for whatever reason) show up in the audit log. Computers are very good at checking data, and activity alerts are predefined checks against new audit events as workloads ingest data into the audit log. If an event of interest is found, Purview sends email to administrators to tell them about the event (Figure 1).

Better Tools to Analyze Audit Events Exist

Although useful (and still used), a case can be made that activity alerts have passed their sell-by-date. The unified audit log holds an increasing amount of data generated by workloads from Entra ID to SharePoint Online to Teams to Purview. Better tools exist to allow tenant administrators to monitor events of interest, including connecting Office 365 data to Microsoft Sentinel where the data can be analyzed along with information gleaned from other sources. Many organizations run background jobs to extract audit events from the unified audit log for ingestion into an external SIEM. There’s even a Splunk add-on to extract audit data for Microsoft 365. And if you want to involve AI, there’s Security Copilot to consider.

And if off-the-shelf software isn’t available, PowerShell can be used to extract and analyze audit events using either the Search-UnifiedAuditLog cmdlet or the AuditLogQuery Graph API. The signs are that Microsoft wants customers to use asynchronous Graph-based audit searches because these searches absorb fewer resources. Removing the monitoring of new audit events to be able to generate audit alerts seems to be another attempt to restrict the resources consumed by audit activity.

Using either the cmdlet or Graph query, the same kind of processing to find and email alerts for audit events of interest is easily done using a combination of PowerShell and scheduled Azure Automation jobs.

Confusion with DLP Alerts

Data Loss Prevention (DLP) policies can also signal alerts when policy rules detect violations. MC1006620 confuses the issue slightly by reassuring tenants that DLP alerts are unaffected by the retirement of audit-based activity alerts.

Further confusion comes about in the assertion that customers who want to retain audit-based activity policies should recreate them using DLP policies. Outside of scenarios like unusual file downloads, I’m not sure if this is even possible for some of the activities audit-based alert policies highlight. Microsoft says that they will invest their development resources on the alerts functionality within DLP, which is fine even if it might not cover everything that might be exposed in an audit event.

In any case, as noted above, a range of options exist to monitor audit events and signal alerts if something of interest is discovered.

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.