SharePoint keeps every deleted file, folder, and list item for 93 days regardless of how sensitive the content is or why it was deleted. That window exists to protect users from accidental loss, and it does that job well. It also means that every piece of confidential material a user deletes, every document containing personal data, every email attachment shared in a private channel and later removed, remains fully accessible to a site collection administrator for three months after the user believed it was gone.
What the SharePoint Recycle Bin Actually Stores
The recycle bin in SharePoint Online operates in two stages, and most end users only ever see the first one.
When a user deletes a file or folder, it goes into the site's first-stage recycle bin. The user can see it there, restore it with a click, or empty their bin if they are confident the content is no longer needed. When a user empties the first-stage bin, or when items age past the first-stage threshold, they move to the second-stage recycle bin: the site collection recycle bin. This second stage is invisible to regular users and site owners. Only site collection administrators can access it.
The combined retention period across both stages is 93 days from the original deletion date. Nothing in that pipeline is truly gone until that clock expires, and even then, content covered by a Microsoft Purview retention policy or litigation hold is preserved beyond 93 days in a separate preservation hold library that end users cannot see at all.
This means the recycle bin is not a wastebasket. It is an indexed, searchable, restorable archive of everything deleted in the past three months, accessible to anyone with site collection admin rights across all sites in the tenancy. For a large organisation with dozens of site collection admins, that is a meaningful data exposure surface.
The Compliance Angle: Deleted Is Not Gone
The practical implications depend on what kind of content lives in your SharePoint environment and what regulatory obligations apply to your organisation. Three scenarios come up repeatedly.
Data subject access requests (DSARs). Under GDPR and similar privacy regulations, individuals can request access to all personal data an organisation holds about them. The recycle bin counts. If a user's personal information appears in a deleted document that is still within the 93-day window, that data is technically held by the organisation and should be included in the DSAR response. Organisations that rely on periodic deletion sweeps to meet "right to erasure" requests need a process for clearing the recycle bin as part of the erasure workflow, not just deleting the content from the live library.
Confidential content and departing employees. When an employee leaves and their account is disabled, any content they created that was later deleted by colleagues or administrators remains in the site recycle bin until the 93-day window closes. A former employee's sensitive project files, personal performance reviews, or merger and acquisition documents can sit accessible in the second-stage bin long after the team assumed they were cleared. This is not a theoretical risk; it is a routine finding in SharePoint access audits.
Litigation holds and eDiscovery. When legal places a hold on a SharePoint site, deleted content within the retention window is preserved in place and captured by eDiscovery searches. That is exactly what holds are designed to do. The compliance risk is the inverse: organisations sometimes delete content intending to remove it from the scope of an investigation, without realising that the second-stage bin and preservation hold libraries continue to retain it. Compliance teams need to know that manual deletion does not remove content from hold scope.
The governance gap most audits expose: organisations have retention policies for live content and archiving policies for old content, but no defined policy for content in transit through the recycle bin. The bin is treated as a temporary buffer, not as a data store requiring governance, even though it holds data subject to the same regulatory obligations as everything else in SharePoint.
When Should You Empty the SharePoint Recycle Bin?
There is no single answer that fits every organisation, but the following criteria should trigger a review and targeted clear of the recycle bin:
- GDPR right-to-erasure request received: after fulfilling a deletion request in the live library, confirm the content is also cleared from both stages of the recycle bin and is not subject to a hold that would preserve it.
- Employee departure: when a user's account is disabled and their access to sites is removed, schedule a review of the second-stage bin for sites they had access to, particularly sites handling confidential project or HR content.
- Site decommission: before deleting or archiving a site, clear the recycle bin to avoid carrying forward sensitive deleted content into an archived state where governance controls may be lighter.
- Pre-migration cleanup: migration tools copy the recycle bin by default. Clearing it before a cross-tenant migration prevents deleted content from being migrated into the destination tenant unnecessarily.
- Security incident response: if a compromised account was used to access or manipulate SharePoint content, clear the bin for affected sites as part of the remediation process after confirming no eDiscovery hold is active.
- Scheduled quarterly hygiene: even without a specific trigger, a regular review of what the second-stage bin holds across high-sensitivity sites is good governance practice. Most organisations find content there they had no idea still existed.
Explore Recycle Master's bulk-clear and indexed search capabilities
Auditing What Is in the Bin Before You Clear It
Clearing the recycle bin without knowing what is in it is a risk of its own. The second-stage bin sometimes contains content that should not be permanently deleted: files accidentally removed during a bulk operation, content that colleagues are still expecting to restore, or items that turn out to be under a litigation hold.
The native SharePoint recycle bin view is sorted by deletion date and does not offer filtering by content type, site, or metadata beyond filename and size. For an organisation-wide audit, that is not workable. ShareMaster's Recycle Master provides indexed search across the recycle bin: search by filename, extension, deleted-by user, date range, or size, and see exactly what is in the bin before deciding what to restore and what to permanently clear. Running that audit before any bulk clear means decisions rest on real information, not assumptions about what was deleted.
The Report Master tool can export a snapshot of recycle bin contents to Excel for review by legal or compliance teams before sign-off on a permanent clear. That export also serves as a record that the content existed and was reviewed, which has value in regulated environments.
Clearing the Recycle Bin at Scale
For organisations with many site collections, clearing the recycle bin site by site through the SharePoint interface is not practical. A site collection admin must open each site, navigate to the site collection recycle bin, select items, and delete them, one site at a time. For a tenant with 200 active sites, that is a significant manual effort and introduces the risk of inconsistency: some sites get cleared, others do not, and the coverage is hard to audit.
PowerShell can automate recycle bin operations across multiple sites using the Clear-PnPRecycleBinItem cmdlet from PnP PowerShell, but scripting the correct scope, handling errors gracefully, and validating the outcome across a large tenant still requires meaningful effort from someone comfortable with the Microsoft 365 management APIs.
Recycle Master in ShareMaster handles this as a configured operation: connect to the tenant, select the sites or site collections in scope, review the indexed contents, and run the clear. The operation logs what was removed so the result is auditable. For environments where recycle bin management is part of a regular compliance workflow, having that capability in a GUI-driven tool with an audit trail is more sustainable than maintaining a PowerShell script that depends on a specific admin's availability and skill set.
Read the SharePoint recycle bin retention reference for a full breakdown of the two-stage model, retention periods, and which admin roles can act on each stage.
Frequently Asked Questions
How long does SharePoint Online keep deleted files?
SharePoint Online keeps deleted files for a combined total of 93 days across the first-stage and second-stage (site collection) recycle bins. The clock starts from the original deletion date. Content subject to a Microsoft Purview retention policy or litigation hold may be preserved beyond 93 days in a separate preservation library, even if the bin is manually cleared.
Who can access the second-stage recycle bin?
Only site collection administrators can view and manage the second-stage recycle bin. Regular users, contributors, and site owners cannot see it. This means content that end users believe they have permanently deleted by emptying their first-stage bin is still fully accessible to site collection admins until the 93-day period expires.
Does emptying the recycle bin permanently delete the content?
Emptying the first-stage bin moves items to the second-stage site collection bin; it does not permanently remove them. A site collection admin must also clear the second-stage bin to permanently delete the content. Even then, content under a Purview retention policy or eDiscovery hold cannot be permanently deleted until the policy or hold is lifted.