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 filtering 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 its search box matches on filename alone, so content type, deleted-by user and date range are columns you can sort but not filter. For an audit, that is not workable. ShareMaster's Recycle Master pages a site collection's bin down and filters it locally by filename, extension, original location, deleted-by user, date range or size, so you can see exactly what is in that bin before deciding what to restore and what to permanently clear. Because bins are scoped per site collection, an organisation-wide audit means repeating that per site: the recycling bin report, which returns item counts and sizes for every site you select, is the quickest way to decide which sites are worth opening. Running that audit before any bulk clear means decisions rest on real information, not assumptions about what was deleted.
ShareMaster's recycling bin report exports a CSV covering every site you select, giving item counts and total size for each stage per site. That is enough to show legal or compliance where deleted content is concentrated and how much of it there is, and it is a reasonable attachment to a sign-off request before a permanent clear. Be clear about what it is not: it lists no file names, deletion dates or deleted-by accounts, so it cannot evidence that a particular document existed or was reviewed. If you need item-level proof before clearing, capture it from the filtered view in Recycle Master, one site collection at a time, while the items are still in the bin.
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.