This is the practical page. If you want the argument about why this work is never finished, that is a separate piece. This one is just the list, ordered by risk rather than by product area, so you can work through it.
It is deliberately short. There are longer guides than this and most of them are written by people selling the remediation. What follows is the part that actually moves the needle, with links to the documentation for each step so you can go deeper where you need to.
Before any licence lands
1. Fix org-wide sharing defaults first
Everything else is cleanup. This is the tap. In the SharePoint admin centre, check the default sharing level for new sites and the default link type when someone hits Share.
If your default link type is “Anyone with the link”, every share your users create from now on generates an anonymous URL. Change it to “People in your organisation” or “Specific people” before you clean anything up, otherwise you are bailing out a boat with the hole still open.
2. Find the broadly shared sites
The grant to look for is Everyone Except External Users, and its older sibling, Everyone. These are the highest-impact finding you will get, because a single one of them can expose an entire site to the whole organisation.
The data access governance reports in the SharePoint admin centre will list these for you: sites shared with Everyone Except External Users, sites with the most sharing links, and sites with potentially overshared content. Start there rather than clicking through sites manually.
Triage what comes back by what is in the site, not by how many people can reach it. Fourteen overshared team sites full of meeting notes matter less than one overshared site containing payroll.
3. Deal with guests and external sharing
Guest accounts are the ones people forget, because a guest who has not logged in for two years looks exactly like a guest who logged in yesterday until you go looking.
Review guest access in the Microsoft 365 admin centre. Remove guests from projects that finished. Kill anonymous “Anyone with the link” sharing links that have no expiry, and set an expiry policy for the ones you keep so this problem has an end date built into it.
4. Spot-check broken inheritance on sensitive sites
Broken inheritance is how a library or folder ends up with permissions nobody intended, usually because someone needed to fix access to one file three years ago.
You are not going to fix every instance of this across the estate and you should not try. Take your list of sites that hold HR, finance, legal and board content, and check those. Unique permissions on a subfolder inside a site you thought was locked down is the classic finding.
5. Label what matters before you index it
Sensitivity labels attach protection to the content rather than to the location, which is the only approach that survives a file being moved, copied or attached to an email. Combined with Purview DLP, this is what stops the sensitive document being the problem rather than trying to stop every possible path to it.
Labelling everything is a multi-year programme. Labelling the handful of categories that would genuinely hurt is a fortnight, and gets you most of the protection.
The controls that buy you time
Two features exist specifically for the gap between “we want to deploy” and “the estate is clean”, and they are underused because people do not know they are there.
Restricted content discovery flags a site so its content does not surface in Copilot results, without changing anybody’s permissions. Nobody loses access to anything they had. The content simply stops being retrievable by the agent. This is the right tool for a site you know is a mess and cannot fix this quarter.
Restricted SharePoint search works the other way round, limiting discovery to an approved list of sites, currently capped at 100. It is a blunt instrument and it is meant to be temporary, but for an organisation that wants to pilot Copilot on known-good content while remediation runs, it is exactly the right blunt instrument.
Use both as scaffolding with a removal date, not as the fix. Content that is invisible to Copilot is still overshared, and the moment someone lifts the restriction to unblock a use case, you are back to the underlying state.
What this costs in licensing
Being straight about this, because a lot of guidance quietly assumes E5.
The data access governance reports and the basic admin centre controls come with the tenant. Sensitivity labels and DLP have meaningful capability in mid-tier plans and get considerably better higher up. SharePoint Advanced Management carries a good deal of the more useful governance tooling, and much of it becomes available once Copilot licensing is present in the tenant, which is worth knowing before you buy an add-on you may already effectively have.
Check the current requirements documentation rather than trusting any blog post on licensing, including this one. It moves.
The part that is not a checklist
Everything above is point-in-time. Work through it and your estate will be in a known good state on the day you finish.
It will not stay there, because the process that produced the sprawl is still running. Someone changes team next week and keeps their old access. A site gets shared for one afternoon. Inheritance gets broken to solve something urgent.
So the things worth putting in place alongside the cleanup are the ones that keep it clean: a mover process that removes as well as grants, access that is scoped and time-bound rather than standing, access reviews with an owner, and those governance reports on a recurring calendar entry rather than in a panic before a go-live.
Run the checklist. Then build the thing that means you do not have to run it again from scratch in eighteen months.
The rest of this series:
- Agent Access and the Permissions You Forgot You Granted
- Joiners, Movers and Leavers: the mover leg is where your permission model rots
- Least Privilege in Practice: standing access, scope, and just-in-time
ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.
