SharePoint tenants accumulate technical debt invisibly. Permissions granted for a project that ended two years ago, version history sitting at the 500-copy default since day one, shared links sent externally and never reviewed again. These are not unusual configurations. They are the default outcome of a platform that makes collaboration frictionless and governance optional. By the time the symptoms become visible, the problem is usually years in the making.
None of the five signs below require a security incident to surface. They are quiet indicators that the gap between what your tenant is configured to do and what your governance policy says it should do has grown wide enough to act on.
1 Storage reports show high usage but nobody can explain why
The Microsoft 365 admin centre shows total storage consumed per site. It does not break that figure down into current document content, version history, recycle bin items, and metadata overhead. When a site collection approaches its quota and the admin team has no immediate explanation, that is almost never a sign that users uploaded too many working files. It is almost always a sign that version history and recycle bin accumulation have been running unchecked.
The ratio is surprising when you first measure it. In an unaudited tenant, 60 to 80 per cent of SharePoint storage is often version history and recycled content rather than live working files. A library that looks like a 20 GB problem from the outside can be carrying 180 GB in version history that is counted against the same quota allocation. The working content is a small fraction of the total footprint.
"We assumed we had a file growth problem. After running a storage report broken down by category, we found 73 per cent of our quota was version history on four document libraries. Trimming those freed more capacity than deleting the project archives we were about to remove."
A storage audit starts with a report that separates version history from live content, sorted by library and site. ShareMaster's Report Master exports this breakdown to Excel, giving you a document you can sort, prioritise, and share with stakeholders rather than a web dashboard you can only screenshot.
For the version history side of this problem, see the guide to trimming SharePoint version history at scale.
2 No one can describe the current permission structure from memory
In a well-governed SharePoint environment, the permission model is simple enough that a senior admin can sketch it in three sentences: who gets access, via which groups, and whether any sites have unique permissions outside the standard structure. In most real tenants, that description is not possible.
Permissions accrete over years. A consultant was granted access for a project and never removed. A site was set up with unique permissions to keep it separate from the standard department structure, and then the reason for the separation was forgotten. A user was added to a site owner group to solve an urgent problem three years ago and is still listed there. Each of these is a small, defensible decision at the time. In aggregate they produce a permission model that nobody can fully describe, audit, or verify.
The diagnostic question is direct: if you needed to produce a document showing which users can access which sites and libraries in your tenant, how long would that take? If the honest answer is "days, and it would probably be incomplete", your permission model has outgrown what manual review can handle.
What a permission snapshot reveals
A permission matrix export typically surfaces three categories of finding in most unaudited tenants:
- Stale external users. Accounts for contractors, vendors, or partners who left months or years ago, still carrying Read or Contribute access to live sites.
- Over-privileged accounts. Users assigned Owner or Full Control on sites they only needed to view, because raising a ticket to give the right level of access at the time seemed like more work than the escalated grant.
- Orphaned unique permissions. Subsites or libraries where inheritance was broken for a specific reason that no longer applies, leaving a permission structure that differs from the parent without any documented rationale.
The guide to exporting SharePoint permissions to Excel covers how to produce this snapshot without PowerShell scripting.
3 The recycle bin contains items from more than 30 days ago
SharePoint Online keeps deleted items for up to 93 days across its two-stage recycle bin. Items sit in the site-level first stage, then move to the site collection second stage. Site owners and site collection administrators can restore from either stage throughout the retention window.
Items sitting in the recycle bin for more than 30 days without review represent two separate problems. The first is a compliance exposure: deleted content is still readable by admins and discoverable by auditors for as long as it remains in the bin. If your data governance policy requires permanent deletion of certain records within a defined window, an unreviewed recycle bin is a gap in that control that a regulator can find.
The second is a storage cost. Recycle bin content counts against site quota. It is common to find tenants where a site is approaching its quota limit and a significant proportion of the "storage in use" figure is items nobody intends to restore. The content is effectively deleted from the users' perspective but is still consuming quota from the tenant's perspective.
Reviewing the recycle bin only reactively, when a user reports a file missing, means the backlog of aged deletions grows indefinitely. ShareMaster's Recycle Master provides indexed search across the tenant-wide recycle bin, making it practical to identify items by age, size, or type and clear them in bulk without scripting.
4 External sharing is enabled but no one knows who has access
SharePoint Online's sharing model is designed for ease of use. A user can generate a sharing link for any file or folder in seconds, choose an expiry (or no expiry), and send it to anyone outside the organisation. The link persists until it is explicitly revoked. When the user who created it leaves the organisation, the link keeps working. It does not change if the file moves to a different library. It does not self-audit.
The audit question: if you listed every active sharing link across your tenant today, how many would point to external recipients, how many would be set to "Anyone with the link", and when was each last used? In most unaudited tenants the answer to all three questions is "we do not know."
Links shared with "Anyone with the link" are the highest-risk category because they are not tied to a specific identity. A link sent to a vendor for a document negotiation two years ago can be forwarded indefinitely to anyone. The original recipient does not need to be involved for the link to remain active and accessible.
For a structured approach to identifying and revoking stale external access, see the guide to auditing SharePoint shared links. The Entra ID admin centre also surfaces external user activity, which can be cross-referenced with the SharePoint sharing audit to prioritise which links to revoke first.
5 Version history is at the 500-version default and has never been reviewed
Every file save in a SharePoint document library creates a new version. The default limit is 500 major versions per file. That limit applies per file, not per library. A library with 8,000 active documents has a theoretical version history ceiling of 4,000,000 stored copies. In heavily used libraries, version counts of 100 to 300 per file after two or three years of active use are routine.
The version limit does not retroactively trim existing history when you change it. Reducing the setting to 50 today stops new versions from accumulating beyond 50 going forward, but it does not delete the existing 300 versions on files that already have them. To actually reclaim storage, you need to explicitly delete existing versions - the native SharePoint admin centre provides no cross-library bulk version deletion tool.
The migration multiplier
Version history compounds the cost of any future migration. A migration tool that transfers content from a SharePoint source to a destination copies all versions of every file by default. A library that is 80 GB of current working content can require 1.5 TB or more of bandwidth and destination storage when version history is included. Running a version trim before a migration is one of the highest-return preparation steps available. For the context on storage limits and what counts against quota, see the SharePoint versioning defaults reference.
What a SharePoint health check actually involves
A health check does not need to be a multi-week project. A practical first pass covers four areas:
| Area | What to produce | Typical time with the right tools |
|---|---|---|
| Storage audit | Storage by site and library, broken into current content vs version history | 30-60 minutes |
| Permission review | Permission matrix for the top 20 most-accessed sites, flagging external users and over-privileged accounts | 1-2 hours |
| Shared links audit | List of all active external links, filtered by type and last-accessed date | 30-60 minutes |
| Recycle bin review | Tenant-wide recycle bin contents, filtered by age and size | 30-60 minutes |
The result of each step is a prioritised action list rather than a vague sense that cleanup is overdue. The combination of a storage report and a permission matrix alone is typically enough to identify the three or four interventions that will have the most measurable impact on quota, compliance posture, and admin confidence.
Each of these tasks involves data that SharePoint holds but does not surface conveniently through its native admin tools. The gap between what the platform stores and what it makes easy to query is exactly where dedicated tooling pays for itself.