A to-do list on a clipboard beside a laptop and pen, representing a pre-deployment checklist

The Permissions Work to Do Before You Deploy Microsoft 365 Copilot

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 (Reports, then Data access governance) will list these for you: a site permissions snapshot across the tenant that shows the sites with Everyone Except External Users or very large audiences, plus activity reports for sites where content was recently shared with Everyone Except External Users and sites with the most new sharing links. Start there rather than clicking through sites manually. These reports are a SharePoint Advanced Management feature; the licensing section below covers who gets them.

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 or organisation-wide search, without changing anybody’s permissions. Nobody loses access to anything they had, and people can still find files they own or recently worked on. The rest of the site’s content simply stops being discoverable through Copilot. This is the right tool for a site you know is a mess and cannot fix this quarter. It needs Copilot licensing in the tenant, and on large sites the change can take days to propagate through the index.

Restricted SharePoint search worked the other way round, limiting discovery to an allow list of up to 100 sites. Microsoft is retiring it: from 31 July 2026 it can no longer be newly enabled, and Microsoft points customers to restricted content discovery instead. If your tenant already has it switched on, treat it as something to plan your way off, not something to build on.

Use restricted content discovery 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 basic admin centre controls (sharing defaults, default link type, guest management) 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 the more useful governance tooling, including the data access governance reports, restricted content discovery and restricted access control. Per Microsoft’s prerequisites page, you get those capabilities when at least one user in the tenant is assigned a Microsoft Copilot licence, when you buy the SharePoint Advanced Management Plan 1 add-on, or with Microsoft 365 E7. Microsoft 365 E5 on its own gets a cut-down version of the data access governance reports (activity reports, no snapshot reports) and none of the other features. A few features, such as restricting site creation by apps, still need the Plan 1 add-on even with Copilot. So once Copilot licensing is present you may already effectively have the add-on you were about to buy.

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:

Enjoyed this guide?

New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.

Scroll to Top