SharePoint permissions best practices: who should have access, and how to keep it right

Most permission problems start the same way: access granted to a person instead of a group, or a library that stopped inheriting from its site and was never looked at again. Microsoft's own guidance points the same way.

1. Grant access to groups, not people. On team sites, manage access through the Microsoft 365 group or the team. Microsoft recommends against managing the site's permissions separately from the group. On communication sites, use the Owners, Members and Visitors groups.
2. Keep Owners small, and Members to the people who create content. Microsoft describes the usual communication site as a few owners, a small number of members, and a large number of visitors.
3. Put large audiences in Visitors with a security group. Microsoft notes that nested security groups can cause performance issues.
4. Share single files with links, not site access. Giving someone access to a site gives them access to all of its content. For one file, a Specific people link is the most restrictive kind.
5. Break inheritance only on purpose, and write down why. Every library or folder with its own permissions is a decision someone has to remember. If it can be a separate site instead, it's usually easier to manage.
6. Keep confidential sites closed to guests. If content should never leave the company, store it in a site with external sharing turned off.
7. Know who receives access requests. By default they go to the site's owners, or the group administrators on group-connected sites. Make sure that's someone who reads them.

None of this is new. What's hard is applying it consistently across thousands of sites, by dozens of site owners, for years.

A permissions review asks whether the access you have today is still right. For SharePoint Online, Microsoft's tools are the place to start.

SharePoint Advanced Management (included with Microsoft 365 Copilot licenses, according to Microsoft) adds:

• Data access governance reports: sites with sharing links, content shared with "Everyone except external users", and a permission state report.
• Site access review: an admin sends a finding from those reports to the site's owner, who reviews and fixes the access, then marks the review complete.
• Restricted access control and restricted content discovery, to limit who can reach a site and what search and Copilot surface.
• Site ownership and inactive site policies, so every site has an owner who can answer for it.

Microsoft Purview sensitivity labels add a second layer: how sensitive a file is, and the protection that follows from it.

Use both. They find access that is too broad by any standard, and they get the right person looking at it.

What a review still leaves to people: whether a given group should have access. Take a Finance site open to all of Sales. It isn't "Everyone", so it won't stand out in a breadth report. Anyone in Finance would tell you it's wrong, because it isn't how your team grants access. That judgment lives in your past decisions, which brings us to the next two sections.

If oversharing before Copilot is your main worry, start with How to fix SharePoint oversharing before Copilot.

A review fixes yesterday's access. Every new site, library and file is a fresh decision, and that's where drift starts.

Good practice here is simple to say:

• Decide access when the site is created, not when someone complains.
• Follow the pattern for that kind of site: a Finance project site gets Finance Members and Leadership; an HR case library stays with HR.
• Start narrow and widen on request, rather than the other way around.
• Ask a person whenever the default would widen access beyond what that part of the tenant usually has.

The pattern in the second point is rarely written down. It exists in your tenant's current permissions: thousands of decisions your admins and site owners have already made. A permission matrix that tries to capture it is out of date the week it's finished.

When someone without access opens a link, SharePoint can let them ask for it. The request goes to the site's owners, or to an email address you set, under Settings → Site permissions → Change how members can share → Allow access requests. Owners approve or decline from Site contents → Access requests, choosing the permission level. Show History lists past decisions.

Best practices for access requests:

• Send requests to people who know the content, not a shared IT inbox.
• Approve at the lowest level that does the job: Read before Edit.
• Record why. The message box on the request doubles as your audit note.
• Treat routine and unusual requests differently. Most requests are routine and get approved. The few that aren't get the same quick click, because approvers have learned to expect yes.

That last point is the real problem. In our benchmark of 32,769 real access requests (Amazon's public dataset, not SharePoint), 94.2% were approved. A high approval rate makes it important to distinguish routine requests from unusual ones.

Automating SharePoint access requests with Power Automate usually means a flow that routes the request, records it and starts an approval. Power Automate is good at moving a request to the right person. Without decision rules or an external model, the flow does not tell that person which requests look routine and which deserve a careful look. That needs your history.

First review your training examples and remove stale or overbroad access. Otherwise a model can repeat those mistakes. Your current permissions and your past access requests are a record of how your team decides, even if nobody ever wrote the rules down. A model trained on them learns those patterns. For each new site, file or request, it can say what your team would normally do, and how sure it is.

What we measured, on public data (neither dataset is SharePoint):

• Who should be in a group. On 36,063 people's real group access, a model trained on past membership was right 97.8% of the time on people it never saw. It gave access wrongly to 0.9% of people who shouldn't have it. Checking the 5.9% of answers it was least sure about would have caught 72% of its mistakes. The group access benchmark →
• Which access requests are routine. On 32,769 real requests, treating as routine only the ones the model was most sure about (79% of them) still sent 73% of the requests a person had denied to a person. The best rule we built, handling the same share, let through about twice as many denials (221 against 103). The access-request benchmark →

The honest finding matters too: no method, the model included, predicted denials well enough to decide on its own. The model's job is to sort, and a person's job is to decide.

StayCharted AI Model Trainer turns your SharePoint permission history into a private model that suggests access for what comes next. It works from an export. It doesn't connect to your tenant, and it never changes permissions.

• Upload your permission export as it is. StayCharted recognizes three formats: the PnP PowerShell permission report, SharePoint's sharing report, and Microsoft Graph JSON. It combines them into one row per item, with the groups that can open it, such as Finance Owners:Full Control; Finance Members:Edit. It leaves out Limited Access, site collection administrators and system accounts, and people who came in through a sharing link, and tells you how many of each.
• See how often it agrees with you before you rely on it. The model is tested on items it never trained on. For each group, the report shows how often it was added wrongly (oversharing) and how often it was missed (someone left out), as separate numbers.
• Get suggestions for new sites and files. Fill a file of new items, or ask from a Power Automate flow through the API when a file is created. Each answer has a confidence and says whether it needs review.
• Sort access requests. Train a second model on past requests and their outcomes. Your flow asks it about each new request, and the unsure ones get a full review.
• A person approves anything that widens access. Answers below your cutoff wait in the Review Queue (Essentials and Business). Corrections become examples for the next version.
• Windows file shares too. The same approach works for NTFS, SMB and NFS folder permissions, with export scripts in our guide.

Try it on sample data first. On Start here, the SharePoint permissions card loads a sample permissions report and trains a model on it, so you can see the suggestions before exporting anything of your own.

Try the SharePoint sample free → · SharePoint access with Power Automate → · AI for SharePoint and file permissions →