In an earlier post, we looked at how SharePoint permissions work and how they get out of hand — broken inheritance, oversharing, sharing links with no authentication barrier. That post treated permissions as a document-and-folder problem. But there's a governance failure mode that sits one level up, at the site itself, and permissions hygiene alone won't catch it: the ownerless site.
How a site becomes orphaned
It rarely happens on purpose. Someone creates a site for a project, or inherits ownership when a team reorganises. Time passes. That person leaves the organisation. Their account is deprovisioned as part of standard offboarding, but nobody thinks to check whether they were the only owner of a SharePoint site.
The site doesn't break. It doesn't throw an error. It keeps running exactly as before. Members can still access it, still edit documents, still share content with others. The only thing missing is anyone who can be held accountable for it, anyone who can approve access requests, review who has access, or revoke a sharing link that should never have been created.
Nobody notices, because nothing visibly stops working. That's what makes it dangerous.
Why single ownership is a ticking clock
In the earlier post, we noted that only Owners can revoke access that a Member has shared. That's a sensible design, but it has a sharp edge. If a site has exactly one owner, and that owner leaves without a handover, there is now genuinely nobody who can revoke that access without escalating to IT or a Global Administrator to force a change.
This is why "does the site have an owner" is the wrong question. The right question is "does the site have more than one active owner", because a single point of failure in ownership is still a single point of failure, even before anyone has left.
What to actually check
The starting point is simple, and it's the check most organisations still don't run: how many people are listed as owners of each site, tenant-wide. Zero owners and single-owner sites are both worth flagging, zero because there's genuinely no one accountable, and single-owner because the site is one departure away from zero.
It's worth noting this is a first-line check, not a complete one. A site can list two names as owners while one of those accounts has since left the organisation, offboarding processes typically deprovision a user's licence and mailbox, but don't always prompt a review of every SharePoint site that user happened to own. A fuller audit would cross-reference owner accounts against current directory status, but even the simpler owner-count check surfaces the bulk of the risk and is a good place to start.
Where this compounds the problem from the earlier post
Orphaned sites are exactly where the sprawl described in our earlier permissions post tends to accumulate unnoticed. Nobody is running the periodic access review. Nobody is checking which libraries have broken inheritance. External sharing links granted eighteen months ago for a project that finished are still live, because reviewing them was never anyone's job once the original owner left.
A periodic permissions audit only works if there's someone positioned to act on what it finds. An orphaned site has an audit trail nobody reads.
The fix: a minimum of two active owners, always
The governance rule here is simple to state, and surprisingly often skipped in practice: every site should have at least two owners, and that should be checked periodically, not assumed to remain true after the site is created.
This isn't about bureaucracy for its own sake. It's the same logic as any single-point-of-failure risk: if the answer to "what happens if this person is unavailable" is "nobody can act," that's a gap worth closing before it matters, not after.
A script to find these sites
Rather than relying on a manual review, this is straightforward to audit at tenant scale with PnP PowerShell, checking every site's Owners group and flagging:
- Sites with zero owners
- Sites with exactly one owner
- A secondary count of lists/libraries with broken inheritance on each site, as a sprawl indicator
System-managed sites (App Catalog, Search Center, and similar) are skipped automatically, since they don't follow the standard owner/member/visitor model and aren't meaningful for this kind of audit.
The full script is available in the scripts library — Get-SPOOrphanedSiteRisk.ps1. It produces a CSV ranked by risk level, so the sites needing attention first are at the top.
Where to go from here
Permissions hygiene and ownership hygiene are two separate governance disciplines that need to work together. Clean inheritance means nothing if there's no active owner to maintain it. The next step, if you haven't done this recently, is simple: run the audit, find your zero-owner and single-owner sites, and assign a second owner to each before it becomes urgent.
Need help auditing site ownership across your tenant?