Jamie hands in his notice on a Tuesday. By Wednesday morning, IT has disabled his Entra ID account, wiped his device, and removed him from the payroll system. By Thursday, his manager is asking why the project intranet site is showing a "no owner" warning, why a contractor Jamie had shared a folder with still has active access, and why his name still appears on a dozen SharePoint group membership lists.
The Entra ID side of offboarding is well understood. The SharePoint side often is not.
This post covers the five most common governance gaps that persist in SharePoint Online after an employee account is disabled or deleted, and what IT teams typically need to do about each.
Why SharePoint Doesn't Clean Up Automatically
SharePoint Online stores its own permission model separately from Entra ID account status. Disabling an account in Entra ID prevents the user from authenticating, which is the right first step. But it has no automated downstream effect on SharePoint group memberships, site ownership records, sharing link records, or content the user created. Those records persist in their original state until someone explicitly modifies or removes them.
This design is intentional. A site that suddenly loses all its members or owners because an account was disabled would be operationally dangerous. SharePoint deliberately does not cascade account status changes into content or permission changes. The consequence for admins is that offboarding a user from SharePoint requires deliberate action, separate from Entra ID account management, and the scope of that action scales with how active the user was across the tenant.
Gap 1: Orphaned Site and Library Ownership
SharePoint site owners hold elevated privileges that members do not: they can change site settings, modify sharing policies, add or remove site members, and permanently delete sites. When the only person with owner permissions on a site or library leaves and their account is removed, that site becomes ownerless in a practical sense.
The site still exists. Existing members can still read and edit content (depending on their permission level). But no one can manage the site until an admin uses the SharePoint admin centre to assign a new owner. In a tenant with hundreds of team sites, identifying every site where a departing employee held sole ownership is not a trivial task. Most tenants discover these orphaned sites reactively, when someone reports that a site setting cannot be changed, rather than proactively during the offboarding process.
Good practice is to require at least two site owners on every site, reducing the risk of single-owner situations. For existing sites where the departing employee is the only owner, the SharePoint admin centre's Active Sites view lets admins search by owner and reassign.
Gap 2: Stale SharePoint Group Membership
SharePoint groups (Members, Visitors, Owners, and any custom groups) are managed at the site collection level and are entirely separate from Microsoft 365 Groups or Entra ID security groups. A user added directly to a SharePoint group stays in that group after their account is disabled. They cannot use that membership to access content (because they cannot authenticate), but the record exists and will reactivate if the account is re-enabled or repurposed.
This matters most in two scenarios. First, if a contractor or vendor account is temporarily disabled and later re-enabled for a different person, the residual SharePoint group memberships give the new holder of that account unexpected access. Second, stale group membership produces inaccurate permissions reports, making it harder to demonstrate a clean access state to auditors or during due diligence processes.
Removing a user from SharePoint groups across a large tenant requires either running the Remove-SPOUser PowerShell cmdlet against each site collection individually, or using a tool that generates a tenant-wide permissions matrix and supports bulk removal. A structured SharePoint permissions audit before and after an offboarding event is the clearest path to a verified clean state.
Gap 3: Sharing Links That Keep Working
This is the gap that surprises admins most often. Sharing links in SharePoint Online do not expire when the person who created them leaves.
A sharing link is independent of the account that created it. Disabling or deleting the creator's Entra ID account has no effect on the link. It continues to work for anyone who holds it, for as long as the link's own expiry date allows, or indefinitely if no expiry was configured.
This is especially significant for "Anyone" links (anonymous links that work without signing in) and "People in your organisation" links, both of which can be used by people who have no other relationship with the departing employee's content. A sales manager who shared a proposal folder with a prospect using an Anyone link is gone. The prospect still has the link. The link still works.
Revoking the link requires a site owner or SharePoint administrator to navigate to the file, open the Manage Access panel, and explicitly delete the link. For employees who were active SharePoint users, the total number of sharing links they created across multiple sites and libraries can be substantial. Auditing and revoking those links manually is time-consuming; most organisations only do it when a specific link becomes a problem. The more defensible approach is to use a tool that can surface all sharing links associated with a specific user across the tenant and bulk-revoke them as part of the offboarding workflow. See ShareMaster's guide to auditing SharePoint shared links for how to approach this.
Gap 4: Unique Permissions on Libraries and Items
Beyond group membership and sharing links, SharePoint also supports direct user permissions (unique permissions) at the library, folder, and item level. These are even harder to find than group memberships because they exist outside the group membership model and are not visible in the standard site member view.
A departing employee might have been granted direct edit access to a sensitive folder on 12 different sites, none of which they appear as a site member on. Finding those access points requires a full permissions report that covers unique permissions breakage - something neither the SharePoint admin centre nor standard PowerShell produces in a single output. ShareMaster's Report Master handles this directly: it generates a permissions matrix covering every location a user can access, including uniquely-permissioned items.
Gap 5: Version History and Content Retention
When employees create documents in SharePoint, those documents continue to exist in the library after they leave. Version history for those files also persists. For most content this is exactly the right behaviour. But there are two scenarios where it creates a governance problem.
The first is storage cost. Employees who used version history extensively may have left behind hundreds of version copies of large documents. These consume storage quota with no ongoing business value once the creator has left and no one is maintaining those documents.
The second is compliance. If the organisation is subject to retention requirements, content owned by a departed employee must still be covered by the appropriate retention policies. Content in a library governed by a retention label continues to be retained correctly. Libraries without retention policies leave that content unmanaged. A content governance review during offboarding should confirm that the departing employee's active sites and libraries are covered by appropriate Microsoft Purview retention labels before their account is removed from site ownership.
A SharePoint Offboarding Checklist
| Step | Action | Tool or method |
|---|---|---|
| 1 | Identify all sites where the user holds site owner permissions | SharePoint admin centre (Active Sites, filter by owner) or ShareMaster Report Master |
| 2 | Assign a replacement owner to any site where the user was the sole owner | SharePoint admin centre or PowerShell Set-SPOUser |
| 3 | Remove the user from all SharePoint groups across the tenant | PowerShell Remove-SPOUser per site collection, or ShareMaster bulk remove |
| 4 | Audit and revoke sharing links created by the user | ShareMaster Shared Links and Permissions; or PowerShell via PnP SharePoint |
| 5 | Identify and remove unique direct permissions on libraries, folders, or items | ShareMaster Report Master permissions export; manual via site Manage Access panels |
| 6 | Confirm key sites are covered by retention policies in Microsoft Purview | Microsoft Purview compliance portal (Retention policies view) |
Audit shared links and permissions with ShareMaster
When Should You Run the SharePoint Offboarding Audit?
The right answer is before the account is disabled, not after. Attempting to identify sites where a person held owner-level permissions is much easier when the account still exists in search and filter results. Once the account is deleted from Entra ID, some admin tools will no longer surface it in filter queries, making the audit harder.
A practical trigger is the IT ticket that initiates offboarding. Before closing the Entra ID account, run the permissions report. After confirming the user has been removed from all SharePoint groups, sharing links have been revoked, and ownership has been transferred, close the Entra ID account. That sequence is rarely the default workflow in most organisations; it typically becomes the default after one significant incident where residual access caused a problem.
Note that this guide covers SharePoint site-based content. The departing employee's OneDrive for Business is a separate governance concern handled through the Microsoft 365 admin centre and Entra ID account lifecycle policies, and is outside the scope of SharePoint site administration.
Frequently Asked Questions
What happens to SharePoint site ownership when an employee account is deleted?
When an Entra ID account is deleted, any SharePoint sites where that person was the sole site owner become effectively ownerless. SharePoint does not reassign ownership automatically. The site remains accessible to existing members, but no one holds owner-level permissions to modify site settings or manage access until an admin assigns a new owner via the SharePoint admin centre.
Do sharing links created by a departed employee stay active?
Yes. Sharing links in SharePoint Online remain active after the link creator's account is disabled or deleted. A link does not expire because the person who created it has left the organisation. It continues to grant access to anyone who holds it until it is explicitly revoked by a site owner or SharePoint administrator.
How do you bulk-remove a leaving employee from all SharePoint permissions?
SharePoint Online does not provide a native tenant-wide user-removal tool. Options include running the Remove-SPOUser PowerShell cmdlet against each site collection individually, reviewing site memberships via the SharePoint admin centre, or using a permissions audit tool such as ShareMaster Report Master to generate a full permissions matrix and then bulk-remove the user across multiple sites.