SharePoint Audit Trail: What You Need to Know

SharePoint’s audit trail tracks who accessed, changed, shared, or deleted content, and when. It’s what you actually pull up when someone asks “who touched this file” or an audit needs a record of access history.

In this post: Four ways to get at it · Which -Operations value to actually use · Pulling more than 5,000 records · How long audit logs stick around · Copilot activity is audited too · Best practices · When would you actually use this? · References · Related reading

Four ways to get at it

Built-in audit logs (Microsoft Purview Compliance Center): tracks key activity out of the box, but retention and reporting depth are limited.
PowerShell for direct queries: more control than the UI — see the example below.
Third-party tools (ShareGate, AvePoint): enhanced reporting, real-time alerts, longer retention — worth it if compliance needs exceed what Purview retains natively.
SIEM integration (Splunk, Azure Sentinel): for larger environments correlating SharePoint activity with broader security monitoring.

Example query pulling file-access events from the last 30 days:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -Operations "FileAccessed" -ResultSize 1000 | Export-Csv -Path "C:\AuditLogs.csv"

Which -Operations value to actually use

The example query above only shows FileAccessed — worth knowing the rest of the actual operation names before you go looking for the wrong one. A few groups that cover most real audit requests:

File and page activity: FileAccessed, FileModified, FileDownloaded, FileUploaded, FileCopied, FileMoved, FileRenamed, PageViewed.
Sharing and access: SharingInvitationCreated, SharingSet, AnonymousLinkCreated, AnonymousLinkUsed, AccessRequestCreated, AccessRequestApproved.
Permissions: PermissionLevelAdded, PermissionLevelModified, PermissionLevelRemoved, SiteCollectionAdminAdded, GroupAdded, GroupRemoved.

One rename worth knowing if you’re working from an older script or guide: the event fired when a user deletes a file used to be FileDeleted, but Microsoft changed it to FileRecycled to reflect what actually happens (the file moves to the recycle bin, it isn’t destroyed) — a query still filtering on the old operation name will silently return nothing for delete events, not an error. And for anything specifically about sharing or permission changes rather than file activity, scope the search with -RecordType SharePointSharingOperations instead of the default -RecordType SharePoint — the two record types split file/site activity from sharing/permission activity, and querying the wrong one is a second, quieter way to come back with an empty result set that looks like “nothing happened” instead of “wrong scope.”

Pulling more than 5,000 records

The query above works fine for a small, targeted pull, but Search-UnifiedAuditLog caps at 5,000 records per call regardless of what -ResultSize is set to — a busy site’s activity over 30 days can blow past that easily, and the cmdlet won’t warn you that results were truncated unless you know to check. Pulling a genuinely large date range needs -SessionId to page through results in sequential blocks, up to a combined 50,000 records per session:

$sessionId = "AuditPull-" + (Get-Date -Format "yyyyMMddHHmmss")
$allResults = @()

do {
    $results = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
        -Operations "FileAccessed" -ResultSize 5000 `
        -SessionId $sessionId -SessionCommand ReturnLargeSet
    $allResults += $results
} while ($results.Count -eq 5000)

$allResults | Export-Csv -Path "C:\AuditLogs.csv" -NoTypeInformation

Keep the same -SessionId and -SessionCommand value across every call in the same pull — switching between session commands mid-session, or reusing a session ID for an unrelated query, is a documented way to get silently truncated or inconsistent results rather than a clear error.

How long audit logs actually stick around

Retention isn’t a single number, and it’s worth checking before assuming you can pull a year-old record. Baseline default is 180 days for most activity types. With an E5 license (or the Purview E5 eDiscovery and Audit add-on) applied to the user whose activity you’re querying, SharePoint, OneDrive, Exchange, and Entra ID records extend to 1 year by default — but note that’s per the license of the user who performed the action, not the person searching the log, and some workload types (Teams, Power Platform, Defender events) stay at 180 days by default even under E5 unless you configure a custom retention policy for them. Beyond that, a separate 10-year audit retention add-on exists, but it only applies where you’ve explicitly created and targeted a custom retention policy — buying the add-on alone doesn’t retroactively extend anything. If a compliance requirement genuinely needs multi-year lookback, don’t assume default retention covers it; check the policy, not the license tier alone.

Copilot activity is audited too

Worth knowing this is real and current rather than assuming audit coverage stops at direct file access: Microsoft 365 Copilot interactions with SharePoint content are captured in the same unified audit log, retrievable with `-RecordType CopilotInteraction`. This closes a real, current gap most people don’t think to check — if Copilot surfaces a sensitive file’s content in a chat response, that’s a genuine access event worth the same auditability as someone opening the file directly in a browser, and it’s exactly the kind of exposure this site’s coverage of Purview’s DSPM for AI capability was built to catch before it happens, not just log after the fact.

Best practices

Don’t log everything by default — focus on document access, permission changes, and security events. Logging indiscriminately costs performance and storage for little benefit.
Store logs securely — via Azure storage or SIEM integration, so the audit trail itself can’t be tampered with.
Set retention based on actual compliance requirements, not a guess — some industries need years, others need months.
Automate alerts for suspicious activity — large deletions, unusual access patterns, admin permission changes — rather than relying on someone noticing during a manual review.
Review periodically, not just when something’s already gone wrong.

Don’t log everything by default — focus on document access, permission changes, and security events.

When would you actually use this?

A sensitive document was modified or deleted and you need to know who did it and when — built-in logs or a PowerShell query answer this directly.
Native retention isn’t long enough for your compliance requirement — that’s the trigger for a third-party tool, not a workaround with the built-in logs.
Security wants SharePoint activity correlated with everything else happening across the environment — that’s what the SIEM integration is for, not something the native audit UI does.

References

Microsoft Purview Audit Log Search

SharePoint Retention Period: What You Need to Know — retention determines how long the audit data this post covers stays available.
SharePoint Compliance Policy and Governance — the governance framework audit trails feed into.

Hope that saves a headache later. Questions go in the comments.