How to Search the Microsoft 365 Audit Log for SharePoint and OneDrive Deletion Events

Who Deleted that Document?

Many searches of the Microsoft 365 audit log are attempts to answer questions. A good example is to search the log to discover email deletion audit events to answer a question like “who deleted a specific message in a shared mailbox?”

The equivalent question for SharePoint Online and OneDrive for Business is “who deleted that document?” You might not care too much about deletions in OneDrive for Business accounts because these are personal storage under the control of individual users; the same might not be true for SharePoint Online deletions, especially in sites used by Microsoft Teams and Outlook Groups where the simplicity of the Microsoft 365 Groups membership model mandates that all members have equal access to group data. In a nutshell, any team or group member can delete any file in the site.

SharePoint’s Deletion Process

SharePoint routes deleted items through a two-stage recycle bin process. All group members can recover items from the first stage recycle bin. Items remain in the first stage recycle bin for 30 days and then move to the second stage. Only group administrators (owners) can recover items after they reach the second stage recycle bin, where they remain for another 63 days. Ninety-three days after their original deletion, SharePoint Online automatically removes the items permanently and they become irretrievable. That is, unless SharePoint Online is forced to retain files because they have a retention label or come within the scope of a retention policy. In that case, SharePoint Online keeps a copy of the file in the site preservation hold library until the retention period lapses (users being able to delete files with retention labels is a recent change).

The audit records captured for item deletions in the Microsoft 365 audit log are often the result of user activity. In other words, someone selects a document in a folder and deletes it. SharePoint Online (including OneDrive for Business) captures a FileDeleted event when this happens. However, other processes can remove items, including:

• A retention policy applying to the site removes items after a set period.
• An administrator deletes a user account, and the SharePoint system account removes items from the user’s OneDrive for Business account.

Users can access the site recycle bin and remove items from it. Often this is an innocent activity, but it can also be evidence that someone wants to remove an item that they don’t want to be found. When someone removes an item from the first stage recycle bin, SharePoint Online captures a FileDeletedFirstStageRecycleBin audit event. Retention policies can also remove items form the recycle bin. Only site administrators can access items in the second stage recycle bin (Figure 1). If they remove items from the second stage recycle bin, SharePoint Online captures a FileDeletedSecondStageRecycleBin audit event.

In summary, SharePoint Online generates audit events as items move through site recycle bins to permanent deletion. Deletions are often user-initiated but can be the result of system processes. The Microsoft 365 audit log ingests the audit records approximately 15 minutes of them happening, and once the records are in the log, we can search for and report the events using the Search-UnifiedAuditLog cmdlet.

Of course, you can also look for these events using the audit log search feature in the Microsoft 365 compliance center but given the volume of audit events to deal with and the need to analyze information to make sense of what happened, it’s usually better to use PowerShell.

Searching for SharePoint Online Deletion Events

To illustrate the process, I created a script that you can download from GitHub. The script is very simple:

• Set up search parameters (I used a 90-day search period, you can adjust as necessary).
• Search for the three deletion events.
• Examine the AuditData payload in each record and extract relevant information.
• Sort the results by operation and date and export to a CSV file. I also output the results using the Out-GridView cmdlet (Figure 2) to make it convenient to see what’s found.

As the code is PowerShell, you can change it to meet your needs.

If you want to distribute the report in other ways, you could:

• Format the content in HTML and send it via email (see this article for details).
• Create the report in a SharePoint document library (the basics of how to do this is explained here; the scenario is a script running in a Azure Automation runbook but the technique of using PnP cmdlets is the same in “regular” PowerShell).
• Post the report to a Teams channel or post a link to it in a message card created in a Teams channel using the inbound webhook connector. See this article for more information.

Watch the Volume of Audit Events

One thing to pay attention to is the volume of deletion events in large tenants. The Search-UnifiedAuditLog cmdlet can retrieve up to 5,000 audit records without doing anything special. To fetch more, you must either:

• Break up the search to stay within the 5,000-record limit by running multiple limited searches (perhaps a daily search).
• Set the SessionCommand parameter for Search-UnifiedAuditLog to ReturnLargeSet. This allows the search to return up to 50.000 records. You need to sort the data.

It might be advantageous to export the search results to an external repository. Many organizations use Splunk for this purpose because they want to keep Microsoft 365 audit data for longer than Microsoft does (90 days for Office 365 E3, 365 days for E5) and to use the search and analysis capabilities often found in dedicated log aggregator products. If you don’t have a copy of the Office 365 for IT Pros eBook (reporting and auditing chapter), you can read this discussion in the Microsoft Technical Community to understand the process.