Eighteen months ago Jordan's company had 30 employees and a single Microsoft 365 tenant managed by one IT generalist. Today it has 210 employees across three office locations, seven product teams, and a Microsoft 365 environment that nobody has reviewed since the company was small. Jordan inherited the role of IT manager six months ago. The first task on the list: figure out what state SharePoint is actually in.
This is not an unusual scenario. Fast-growing companies prioritise shipping product and hiring people. The IT infrastructure expands to support that growth, but governance rarely keeps pace. Team leads create sites when they need somewhere to put files. Contractor access gets granted as people join and rarely reviewed when they leave. Storage climbs unchecked. The tenant that worked fine at 30 people starts showing cracks at 200.
What a SharePoint Governance Audit Reveals
A first-pass audit of a fast-growing company's SharePoint tenant typically surfaces the same categories of problems in the same order of severity. Jordan's audit was no different. The findings fell into four buckets:
- Storage overuse without a clear culprit. The tenant was using over 80% of its pooled storage quota. No single site was obviously responsible. The problem was distributed: dozens of sites each holding more than they should, driven by version history accumulation and large files that had never been cleaned up.
- Permission sprawl. Forty-seven unique permissions had been applied at the folder or document level across active sites. Eleven former contractors still had active access. Three sites had been shared externally during a project the previous year and never revoked. None of this was visible without running a permissions report.
- Orphaned sites. Fourteen SharePoint sites showed zero file activity in the previous 90 days. Six of them had no identifiable owner. Three were project sites for work that had been completed and handed to clients over a year ago.
- Uncontrolled Teams channels with SharePoint storage. The product teams had been creating Microsoft Teams channels freely. Each Teams channel creates a SharePoint document library. Jordan found 23 document libraries created by Teams channels that the teams themselves had forgotten about, several containing large uploaded files that had never been moved or deleted.
None of these problems were the result of bad intentions. They were the natural consequence of a tenant that had scaled without a governance framework attached to the growth.
Why SharePoint Governance Had Slipped
Jordan identified three structural reasons, each common in fast-growth environments. First, there was no site provisioning process. When a team needed a SharePoint site or Teams channel, they created it themselves. No approval, no naming convention, no owner assignment. Over 18 months that produced a long tail of sites with inconsistent names, varied permission models, and no documentation.
Second, offboarding was handled by the HR system and Active Directory, but SharePoint permissions were not part of the offboarding checklist. Revoking access to Entra ID (formerly Azure AD) removed the former employee's sign-in, but SharePoint unique permissions that had been granted directly to that user account remained in place. In theory the user could not sign in; in practice, any shared links they had created were still active.
Third, storage was invisible. The Microsoft 365 admin center showed total tenant storage consumption, but nobody had looked at it since the tenant was provisioned. There was no alert configured for quota thresholds, and no periodic review of which sites were consuming the most storage. The 80% usage figure came as a surprise.
The pattern is predictable. When a tenant is small, the admin can hold the full picture in their head. When the tenant doubles and doubles again, that stops working. A governance framework that relies on individual memory rather than documented process and tooling breaks down at scale.
The Cleanup Sprint
Jordan blocked out three days for the initial cleanup. The goal was not to build a perfect governance framework from scratch; it was to reduce immediate risk, reclaim storage before hitting the quota ceiling, and establish a baseline the team could maintain going forward.
Day 1: Storage and version history. Jordan used ShareMaster's Space Master to run a storage utilisation report across all sites. The report identified the five sites responsible for over 60% of the storage overuse, and within each site, the libraries with the highest version counts. Jordan ran the Version Trimmer on each high-impact library, keeping the last 15 versions per file and deleting everything older than 90 days. The trim completed overnight. By the following morning, the tenant had recovered enough storage to bring the usage level back below 50%.
Trimming existing versions reduces immediate pressure but does not prevent future accumulation unless the library version limits are also adjusted. Jordan set the version limit to 15 on each affected library as part of the sprint so the problem would not quietly rebuild over the following months.
Day 2: Permissions and external sharing. Report Master's permission matrix export produced a spreadsheet of all unique permissions across active sites. Jordan sorted by last-login date for external accounts, identified the 11 former contractors, and removed their access in bulk. The 3 sites with active external shares were reviewed: two were revoked immediately; the third was an active client portal that needed to stay but was updated to view-only access for the external accounts.
Day 3: Orphaned sites. Jordan emailed the managers of the 14 inactive sites asking whether the sites were needed. Eight responses came back within the day: seven confirmations to delete, one request to archive content first. The remaining six sites with no identifiable owner were deleted after a 72-hour hold period with no objections. Space Master's Bulk Delete Sites removed the confirmed candidates in a single operation.
See how Report Master surfaces permissions across your tenant
What Changed After Three Days of Work
Storage dropped from 82% of quota to 44%. The permission report went from 47 unique permissions (including 11 stale contractor accounts) to 19, all of which Jordan could trace to a current business reason. Fourteen orphaned sites were gone, and the remaining active sites all had an identified owner recorded in a simple spreadsheet Jordan maintained as the new site register. The 23 Teams-created document libraries from finding 4 were not part of the three-day sprint - deleting a Teams channel also removes its SharePoint library, so those decisions required channel-owner confirmation. Jordan flagged the list to the product team leads and tracked resolution separately over the following two weeks.
The change that mattered most operationally was visibility. Before the audit, Jordan had no reliable picture of the tenant's state. After three days, there was a documented baseline: current storage per site, active external shares, permission assignments, and a site register with owners. Future audits would not require starting from scratch.
Jordan also put three lightweight process changes in place: a 90% storage alert in the Microsoft 365 admin center, a quarterly reminder to run the permissions report in ShareMaster, and an item added to the HR offboarding checklist to flag SharePoint permission review alongside Active Directory deprovisioning. None of these required significant tooling investment. They required only that someone had done the initial audit and knew what the exposure actually was.
For the step-by-step process Jordan used to reclaim storage quickly, see the guide on how to reduce SharePoint storage fast.