sharepoint is a graveyard

An IT director at a 400-person professional services firm was preparing for a Microsoft 365 Copilot rollout in mid-2025. The preparation included a SharePoint permission audit, which the Microsoft partner had strongly recommended before Copilot activation.

The audit produced the following counts. The tenant had 847 SharePoint sites. Of those, 412 had been created through the automatic Teams provisioning, every time a Team was created, a corresponding SharePoint site was generated. The rest had been created directly, for various purposes across the company’s history.

Of the 847 sites, 298 hadn’t been accessed by any user in over twelve months. 156 had last been modified more than three years ago. 62 were orphaned, they had no identified owner, either because the owner had left the company or because they had been created without an explicit owner.

Of the total permission grants across all sites, 41% were inheriting from parent sites, creating cross-site permission chains that were difficult to trace. 12% were “shared with everyone” permissions, typically granted because the original creator wanted to make a document broadly available without specifying a narrower audience. Thousands of individual documents had been shared via “anyone with the link” URLs that had been generated years earlier and never revoked.

The audit output was a report several hundred pages long. The IT director’s conclusion was that SharePoint permissions at the company had accumulated into an unreadable graph that no individual could fully comprehend. The Copilot rollout was deferred by a quarter while a remediation project was scoped.

This is not a specific-to-this-firm situation. It’s the general state of SharePoint in most mature Microsoft 365 deployments. The product’s architecture, combined with how teams actually use it, produces a permission sprawl that nobody planned and nobody has cleaned up.

This essay is about SharePoint specifically. What makes it a unique challenge, how the permissions accumulate, and what to do when AI deployments force the reckoning.

SharePoint is not one system

The first thing to understand about SharePoint is that it’s not a single system. It’s a platform with multiple surfaces, each creating its own content and permission objects.

Classic SharePoint sites, which include team sites and communication sites. Each has its own permissions, libraries, and pages.

Microsoft 365 Groups, which each get an associated SharePoint site automatically. Every Team in Microsoft Teams has an underlying Microsoft 365 Group, which has an underlying SharePoint site. The SharePoint site holds the files shared in the Team.

OneDrive for Business, which is personal SharePoint storage for each user. Individual users share files through OneDrive, generating sharing links that can be forwarded indefinitely.

Microsoft 365 Groups also have their own standalone sites, created for specific group purposes.

Private channels in Teams have their own dedicated SharePoint sites, separate from the parent Team’s site.

Each of these surfaces creates content that ends up in SharePoint, each with its own permission configuration. A typical user’s content is spread across their OneDrive, several Team sites, a few Group sites, and possibly some classic team or communication sites.

Auditing permissions across all of this requires touching each surface. The permission model is consistent across surfaces (at the underlying SharePoint level), but the configuration is distributed across all the individual sites, groups, and channels.

how SharePoint content ends up reachable

• inherited permissionsa parent site's access flows down
• "everyone" groupsused because it was quick
• anyone linksshared outside, never expired
• orphaned sitesthe owner left, the content stayed
• sites created by Teamsone per team, multiplying
• direct grantsone person, one folder

often still openusually handled

inheritance is the default

SharePoint permissions inherit by default. A site inherits from its parent, a library inherits from its site, a folder inherits from its library, a document inherits from its folder. Permissions at any level apply downward unless inheritance is explicitly broken.

This is an efficient design when used well. Set permissions at the site level, and everything in the site gets them. When you need an exception, break inheritance for the specific object.

In practice, inheritance breaks happen unpredictably. A user wants a specific document to be visible to a broader audience than the folder. They click “share” on the document, which breaks inheritance on the document and gives additional permission. The folder’s inheritance doesn’t matter for that document anymore.

Over years of these ad-hoc sharing actions, the inheritance chains become irregular. Some documents inherit from their folders. Some don’t. Some folders inherit from their libraries. Some don’t. Tracing a specific permission, why does user X have access to document Y?, requires walking the inheritance tree for that specific object, which is often a multi-step investigation.

The UI makes this harder to see than it should be. A user looking at a document can see who has access to that document. They can’t easily see whether that access came from direct assignment, from folder inheritance, from library inheritance, or from site inheritance. The mechanics are opaque to everyday users.

Administrators can investigate specific items using PowerShell or the Graph API. For large-scale audits, the investigation has to be scripted, because the number of documents in a typical tenant is too large to inspect individually.

“share with everyone” is common

A specific default that shows up frequently: the permission to share with everyone in the organization.

When a user wants to share a document broadly, say, a training deck they want to make available company-wide, they can choose “everyone in the organization” as the audience. The document becomes accessible to every employee of the tenant.

This is a legitimate use case. Internal communications, company-wide resources, and publicly-intended documents benefit from broad sharing.

The problem is that “everyone in the organization” is often used where a narrower audience would have been appropriate. The user needed to share with the Marketing team. They couldn’t remember whether there was a Marketing Microsoft 365 Group, or they didn’t want to look it up. They clicked “everyone” because it was fast.

The document is now accessible to every employee, including future employees who join the company after the document was shared. The permission scales with the tenant, as the company grows, so does the audience that can access the document.

For documents that weren’t actually intended for everyone, sensitive financial documents, HR documents, confidential strategy documents, this is a leak. The original creator intended a narrower audience. The clicks didn’t match the intent.

Auditing “everyone” permissions is one of the highest-value activities in a SharePoint permission cleanup. Find every document and site with “everyone” permissions. Review whether the sharing is appropriate. For any document where the sharing isn’t appropriate, scope it down to the actual intended audience.

This is tedious work. It’s also the work that has the highest impact on AI data governance, because AI retrieval systems will index everything accessible to the querying user, and “everyone” permissions expand the query surface for every user in the tenant.

the link-sharing problem

SharePoint supports link-sharing: generating a URL that anyone with the URL can use to access a file. Link sharing is how most casual sharing happens, because it’s fast.

The problem with link sharing is that the link persists. Once generated, the URL is a valid credential for accessing the file. Anyone who has the URL, through forwarding, screenshots, cached email, or any other means, can use it.

Links can be configured with various restrictions: internal users only, specific people, anonymous (external). The default depends on admin settings. Many tenants have the default set to “anyone with the link” for ease of use, which means anonymous external sharing is possible by default.

Once a link is generated, revocation is possible but requires finding the specific link and explicitly revoking it. Users don’t usually do this. The links remain valid for years.

A mid-market company often has thousands of active link-shares across its tenant. Many of them point to documents that were shared for specific one-time purposes. The one-time purposes ended. The links are still valid.

Auditing link shares is possible through admin tools but is a large job for an unaudited tenant. The specific investigation is to pull all active share links, filter for ones that haven’t been accessed in the last year or that were shared with broad audiences, and revoke them.

the orphaned site problem

A SharePoint site has an owner. The owner is a user (or users) with administrative rights on the site. When the owner leaves the company, the site becomes orphaned if no replacement owner is assigned.

In a large tenant with many sites, orphaned sites accumulate. Teams are created, an owner is assigned, the owner eventually leaves, nobody is designated as the replacement, and the site sits without ownership.

The content in the orphaned site continues to exist. The permissions continue to apply. But there is no human responsible for the site. Changes to the site are unauthorized in the sense that nobody with legitimate authority exists to authorize them.

Microsoft’s specific guidance is to identify orphaned sites and either reassign ownership or archive/retire them. Both actions require deliberate effort.

The reassignment requires finding someone willing to be the owner. For a site whose purpose isn’t clear (because the original owner is gone and the site’s purpose isn’t documented), finding a new owner is hard. Nobody wants to own a site they don’t understand.

The archival requires a decision that the site is no longer needed. Making that decision requires confidence that the content in the site has been preserved or migrated elsewhere if needed. The confidence is often lacking.

So the orphaned sites persist, neither owned nor retired, in a permanent limbo.

the Teams proliferation factor

Microsoft Teams, since its broad adoption around 2020, has been the biggest driver of SharePoint site creation.

Every Team creates a SharePoint site. Every Team channel (public or standard) adds content to that site. Every Team private channel creates its own dedicated site.

In a mid-market company that adopted Teams aggressively, hundreds of Teams might have been created over the years. Each of them has a SharePoint site. Many of those Teams are no longer actively used, projects ended, teams reorganized, people moved on. The Teams are still in the tenant, with their associated SharePoint sites, with whatever content was shared in them during their active period.

Teams have their own lifecycle problem, mirroring the SharePoint site problem. Owners leave. Teams are abandoned. The underlying Microsoft 365 Groups persist, with their SharePoint sites, with their permissions. The cleanup happens rarely.

Microsoft has added lifecycle management features, Group expiration policies, activity-based archival, owner reassignment workflows. These help for tenants that configure them. Most tenants haven’t configured them, or have configured them lightly.

The Team proliferation is why the 847-site tenant in the opening example had 412 of its sites coming from Team provisioning. The Teams feature is tightly coupled to SharePoint site creation, and every Team created is a site created.

the AI deployment is the forcing function

SharePoint permission cleanup is the kind of work most companies have known they should do for years and haven’t done. The work is large, unglamorous, and often doesn’t have a visible payoff.

AI deployments, specifically Microsoft 365 Copilot, but also third-party tools that index SharePoint content, have changed the payoff calculation. Copilot queries retrieve across every document the querying user can access. The permission sprawl directly becomes the Copilot exposure.

The opening example’s IT director deferred the Copilot rollout to remediate SharePoint. This is a reasonable and common choice. The alternative, deploying Copilot on top of a permission mess, produces the “Copilot leaked our data” incidents that become executive-level attention.

The specific framing that works is: SharePoint remediation is now a prerequisite for AI deployment, not just general hygiene. The remediation has a business owner (the AI deployment sponsor), a timeline (the AI rollout deadline), and a budget (the AI project budget). The organizational conditions that enabled the remediation project, which hadn’t existed for years, exist now.

Companies that use the AI deployment as the forcing function for SharePoint cleanup get two outcomes. The SharePoint hygiene they’ve needed for years. The AI deployment they wanted. The cleanup gets done because AI is waiting on it. The AI deployment is safer because the cleanup was done first.

cleaning SharePoint before an AI rollout

1. 1assess the tenantSites, permissions, sharing and orphaned content.
2. 2archive stale sitesUntouched for a year, owners given a window to object.
3. 3scope down "everyone"Replace it with the audience that needs it.
4. 4fix old inheritance breaksRemove the ones nobody can explain.
5. 5then deploy the AI assistantIt will find whatever is left.

the exercise

Here is the specific SharePoint cleanup exercise for the month you’re preparing for any AI deployment.

Run the Microsoft 365 tenant assessment tool against your tenant. The tool produces a report of sites, permissions, sharing, and orphaned content. Review the report.

Identify sites that haven’t been accessed in twelve or more months. Flag them for archival. Notify any identifiable owners and give them a window to claim or object. For sites without an identifiable owner, archive after the window.

Identify “everyone” permissions. For each one, review whether the sharing is appropriate. Most will be inappropriate by current intent, because they were set up casually. Scope them down to specific audiences.

Identify inheritance breaks that predate the current administration. Review whether they’re still needed. Many will be residual from past situations that no longer apply. Remove unnecessary breaks.

Identify link shares. Revoke links that haven’t been accessed recently. Rotate links that remain, on a policy that requires re-sharing periodically.

Identify orphaned Teams. Trigger the reassignment workflow or archive them.

Before enabling Copilot (or any other AI tool that indexes SharePoint), run a test query as a non-admin user. Imagine what a marketing coordinator or a junior analyst might query and check what comes back. If the results include things you don’t want them to see, the cleanup isn’t complete.

After Copilot is enabled, review usage patterns monthly. Queries that surface inappropriate content point to permission issues that survived the pre-deployment cleanup.

SharePoint has been accumulating permissions for however long your company has been on Microsoft 365. The permissions reflect ten years of individual sharing decisions, made casually, by people who are no longer at the company, on content that no longer matters.

The AI tool will read all of it. The permission graph is the only thing standing between what the AI returns and what you intended to be returnable.

Clean up the graph. Then let the AI in.