Most Microsoft 365 tenants have a governance gap. Not because admins do not understand the problem, but because "governance" is a large, loosely defined category that is easy to defer when there are users waiting for help, migrations in progress, and licences to manage. This article is about making governance concrete: the three areas where the gap costs the most, and the practical first steps that produce real results without requiring a multi-year programme to get started.
Why governance keeps getting deferred
SharePoint governance rarely fails at the planning stage. Most organisations have some version of a governance policy document, often produced during the initial Microsoft 365 rollout or after a security audit. The problem is that the policy is written once and then left unchanged while the tenant grows, users are added and removed, new sites are created, and content accumulates.
The other factor is visibility. Without the right reporting tools, it is genuinely difficult to know whether permissions have drifted, how much storage is consumed by version history versus live content, or which sites are orphaned. When you cannot see the state of a system, it is hard to prioritise fixing it. Governance stays on the back burner not from neglect but from a rational response to uncertainty: if you do not know how bad the problem is, it is hard to justify the time to fix it.
The practical solution is to start with an audit rather than a policy. Find out what the environment actually looks like, then decide what to fix. A two-hour audit session produces more actionable information than a week spent drafting governance frameworks that will not be enforced until after the audit anyway.
The cost of ungoverned SharePoint
Before looking at where to start, it is worth being specific about what ungoverned SharePoint actually costs, because the costs are often invisible until something goes wrong.
Permission sprawl
In a SharePoint tenant without permission governance, unique permissions and shared links accumulate over time. A site that started with three members gains five more through direct shares over a year. A document shared externally for a project three years ago still has an active anonymous link. Former employees remain as site members in several sites. The practical effect is that sensitive content is accessible to people who should no longer have access, and no one knows because no one has looked.
The security risk from permission sprawl is real, but there is also a regulatory dimension. Organisations subject to data protection requirements (including general GDPR obligations) have a duty to ensure that personal data is accessible only to those with a legitimate need. An audit that surfaces unexpected external shares or lingering former-employee access is a compliance finding, not just a tidy-up task.
Storage and version history bloat
Version history is the most controllable cost in a Microsoft 365 storage budget, and in most tenants it is not controlled at all. SharePoint Online's default version limit of 500 versions per file applies per file across every document library in the tenant. Libraries that have been active for several years without a version trim policy carry hundreds of versions per file, often consuming 10 to 50 times the storage of the current working content.
The storage cost is direct: SharePoint Online charges based on total quota, and version history counts fully against that quota. The indirect cost is that quota problems appear suddenly, as a user cannot upload a new file with a quota exceeded error, rather than gradually with advance warning. The fix, at that point, requires urgent attention that disrupts other work.
For a deeper look at how version history accumulates and how to address it, see Why SharePoint Version History Quietly Fills Your Storage.
Orphaned sites and content
Project sites, team sites created for short-term initiatives, and personal sites for former employees accumulate in SharePoint over time. These sites are not actively managed, their owners are often no longer with the organisation, and they may contain sensitive content with no active oversight. They consume storage, create discovery risk, and complicate any future tenant migration or audit.
Starting point 1: The permissions audit
A permissions audit answers two questions: who has access to what, and is that appropriate given the current state of the organisation? For most tenants running their first audit, the findings fall into three categories:
- Former employees who still appear as site members, library editors, or site owners. These accounts are often disabled in Azure Active Directory but may still hold SharePoint permissions that have not been cleaned up.
- Unexpected external shares: anonymous or organisation-wide sharing links created for specific projects that were never revoked, now giving access to anyone with the link.
- Unique permission proliferation: libraries and even individual files that have had inheritance broken and custom permissions set, often for a short-term reason, and then forgotten. These create a patchwork of access rules that is difficult to audit manually.
The native SharePoint admin center shows sharing settings at the tenant level but does not provide a cross-site view of which specific links and unique permissions exist across all sites. The practical way to run a tenant-wide permissions audit is with a reporting tool that exports permission data in a format you can analyse.
ShareMaster's Report Master generates a permission matrix export covering site members, unique permissions, and sharing link data across all connected sites. Use that export to identify the three categories above, then prioritise removal by sensitivity of the content involved.
Once the backlog is identified, ShareMaster's Shared Links and Permissions tool provides bulk removal of sharing links and unique permission assignments without requiring manual navigation through each affected site or library.
Starting point 2: The storage audit
A storage audit tells you where quota is being consumed and by what. For most tenants, the audit produces two findings: a small number of sites consuming a disproportionate share of the total quota, and a large proportion of that consumption being version history rather than live content.
The SharePoint admin center shows total storage per site, but does not distinguish between current-file storage and version-history storage. To see that breakdown you need either a PowerShell query per library or a dedicated reporting tool.
ShareMaster's Report Master includes a storage utilisation export that shows version counts and ages per library. Sort by version storage descending to find the libraries carrying the heaviest historical backlog. Libraries with thousands of files and high average version counts are the first targets for a trim.
After the audit, the trim itself can be run with ShareMaster's Version Trimmer. Configure a keep policy (for example: keep the last 20 versions per file, delete anything older than 12 months beyond those 20) and apply it across the worst-offending libraries. For a step-by-step walkthrough of the trim process, see How to Trim SharePoint Version History.
The storage audit also identifies candidates for a different kind of cleanup: stale files and libraries that have not been accessed in years. For those, a bulk delete operation through Space Master is more appropriate than a version trim, since the content itself is no longer needed.
Starting point 3: Orphaned sites and content lifecycle
After permissions and storage, the third governance gap to address is orphaned and unmanaged sites. These are sites with no active owner, no recent activity, and often no clear connection to a current business purpose.
The SharePoint admin center's Active Sites view shows the last activity date and current owner for each site. Filter for sites with no activity in the past 12 months and no active owner to produce an initial list of candidates. For each candidate, determine whether the site should be:
- Archived: content is preserved in read-only form for reference or compliance, but no new content is added. Set the site to read-only in the SharePoint admin center.
- Migrated and decommissioned: content is moved to a current, actively managed site and the old site is deleted. Space Master's Bulk Delete Sites tool handles the decommissioning step across multiple sites in a single job.
- Retained and reassigned: the site is still needed, but the current owner has left. Assign a new owner and document the site's purpose in the site description.
Building a repeatable governance routine
One audit cycle addresses the backlog but does not prevent the next one from building up. The audit findings inform what forward-looking policies to put in place.
| Governance area | Recommended review cadence | Forward-looking policy |
|---|---|---|
| External sharing links | Quarterly | Set expiry dates on all external sharing links at the tenant level (SharePoint admin center > Policies > Sharing). Links older than 90 or 180 days expire automatically. |
| Former employee access | As part of offboarding process (not a periodic review) | Include a SharePoint permission review as a step in the standard HR offboarding checklist. Remove or reassign site ownership before the account is disabled. |
| Unique permission proliferation | Semi-annually | Adopt a principle of using group membership rather than individual user permissions. Direct user permissions on specific files or folders are a governance risk; group-based access is easier to audit and correct. |
| Version history storage | Annually (or before any major migration) | Set a tenant-level version limit for new libraries (SharePoint admin center > Settings > Version history limits). Run a Version Trimmer pass annually to address libraries that have drifted beyond the policy. |
| Orphaned sites | Annually | Require every site to have a named owner in the site description. Schedule an annual review of the Active Sites list, filtering for last-activity date and owner validity. |
The table above describes the review cadence for an established governance routine. For a first-pass audit, compress the timeline: run all three starting-point audits within a single governance sprint, address the critical findings, and then set up the recurring schedule.
The tooling question
SharePoint governance does not require specialised tooling to start. The native SharePoint admin center, combined with well-structured PowerShell scripts, can surface the same data that purpose-built tools provide. The difference is time and repeatability.
Scripted approaches require someone to author, test, and maintain the scripts, and they tend to be run less frequently because of the setup overhead. A permissions matrix script that takes a day to write and test gets run once; the governance gap it was meant to close reopens within months.
The case for purpose-built tooling is not that the native platform cannot do the job; it is that tools with purpose-built reports and bulk operations reduce the per-review effort to the point where quarterly reviews become practical rather than aspirational. ShareMaster's Report Master and Shared Links and Permissions tools were designed for exactly this kind of recurring audit workflow.
Summary
SharePoint governance is most valuable when it is specific and recurring, not when it is comprehensive and theoretical. Start with a permissions audit and a storage audit: two targeted exercises that surface the highest-risk and highest-cost problems in most tenants. Address the backlog, set forward-looking policies to prevent recurrence, and schedule the next review before you close out the current one. The organisations that maintain well-governed SharePoint environments are not the ones with the most detailed governance documents; they are the ones that review their environment on a regular, predictable schedule and act on what they find.