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 · How long audit logs stick around · Best practices · When would you actually use this? · References
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"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.
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
Hope that saves a headache later. Questions go in the comments.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning