Last Updated: November 2, 2026
Quick Summary
To manage SharePoint permissions, work through three layers: users, groups, and permission levels, assigning levels to groups rather than individuals. Break inheritance only for a real reason, route access requests to a named owner, and audit unique permissions quarterly so stale access does not become a security finding.
- Assign permission levels to SharePoint groups instead of adding people directly, which is where sprawl begins.
- Contribute is the safer default than Edit because it limits deletion to items the user created.
- Reserve Full Control for a small, named owner group and audit its membership on a schedule.
- Check Microsoft 365 group and Entra ID membership before changing SharePoint settings when troubleshooting access.
- Capture a screenshot of the current permission set before changing any permission so you can restore it.
Table of Contents
- Start With the Permission Model Before You Click Anything
- SharePoint Permission Levels and What Each One Allows
- SharePoint Permission Inheritance: Break It Only When You Must
- How to Set SharePoint List Permissions for a Single List or Library
- SharePoint Access Requests: Route, Approve, and Review
- Sharing Links and External Sharing: Where Permissions Leak
- Audit and Troubleshoot Permissions Before Sprawl Sets In
- Schedule a Permissions Review With MTRC Enterprises
- Frequently Asked Questions
Start With the Permission Model Before You Click Anything
Most access problems in SharePoint start with a click, not a plan. Teams share a file, break inheritance to "fix" one request, and months later nobody can explain who sees what. Learning how to manage SharePoint permissions properly means understanding three layers first, which is why MTRC Enterprises teaches this model before touching a single setting.
SharePoint permissions is the system that controls who can view, edit, or share content in a site, list, or library. It runs on three connected layers.
Users, Groups, and Permission Levels: How the Three Layers Connect
Here is the model in plain terms:
- Users are individual accounts, like a person or a service account.
- Groups are containers of users. SharePoint groups collect people by role.
- Permission levels are bundles of rights, like Read or Edit, assigned to a group or user.
You assign a permission level to a group, and the group holds the users. Skip the group layer and you end up assigning rights person by person, which is where sprawl begins.
A common mistake is adding one person directly to a library with Edit rights "just this once." Do that ten times and you have ten exceptions nobody tracks. Use groups instead.
SharePoint Permission Levels and What Each One Allows
SharePoint permission levels are preset bundles of individual permissions that decide what a user can do with content. The standard levels cover most needs, and Microsoft documents each one in its SharePoint permission levels reference guidance. Here is what each level allows and where it fits:
| Permission Level | What It Allows | Best For |
|---|---|---|
| Full Control | Everything, including managing permissions and creating subsites | Site owners only, in a small named group |
| Design | Edit structure, themes, layouts, and master pages; cannot manage permissions | Content architects and site designers |
| Edit | Add, edit, and delete items and lists, including items created by others | Contributors who own a list's content |
| Contribute | Add, edit, and delete own items; cannot delete others' items | Day-to-day staff |
| Read | View pages, items, and versions; open but not modify | General audience |
| View Only | View but not download, print, or edit; enforced at the file level | Sensitive read access, regulated content |
| Limited Access | View a specific item shared with them; no access to the surrounding site | Exception access via sharing links |
How the Levels Actually Compose
A permission level is a container of granular permissions such as Manage Lists, Open Items, View Versions, and Create Alerts.
The distinction between Edit and Contribute trips people up. Edit lets a user delete anything in the list, including items other people created. Contribute limits deletion to items they created.
Limited Access is rarely assigned directly. SharePoint grants it automatically when you share a single item with someone who has no other access to the site, so they can reach that item without seeing the rest.
Creating and Changing Custom Permission Levels
When the standard levels do not fit, create a custom level instead of stacking direct grants. In Site settings, open Site permissions, then Permission Levels, and choose Add a Permission Level. Start from an existing level, then add or remove individual permissions. Common custom levels include:
- Read + Create Alerts for audiences that need notifications but not editing.
- Contribute without Delete for staff who should add and edit but never remove records.
- Design without Manage Permissions for designers who should not change access.
Custom levels are site-scoped. To reuse one across many sites, create it in the site collection's top-level site and let subsites inherit it, or deploy it through a site template.
How Permission Levels Interact with Microsoft 365 Groups and Entra ID
Modern SharePoint sites are usually connected to a Microsoft 365 group backed by an Entra ID (formerly Azure AD) security group.
When you troubleshoot access, check Microsoft 365 group and Entra ID group membership before changing any SharePoint setting. A user removed from a SharePoint group may still have access through a nested Entra ID group, the most common cause of "I removed them but they still have access."
SharePoint Permission Inheritance: Break It Only When You Must
SharePoint permission inheritance means a list or library automatically inherits permissions from its parent site. This is the default, and it keeps administration sane. When you break inheritance, the item gets its own permission set and stops following the parent.
Break inheritance only for a real reason:
- A confidential folder that needs a smaller audience
- A library used by one department only
- A single document with sensitive content
Every break adds a place you must review later. Break ten folders and you have ten permission sets to audit.
How to Restore Inheritance Without Losing Custom Permissions
Restoring inheritance is simple, but you lose the unique permissions when you do it. Here is the safe order:
- Note every user and group with unique access, and their level.
- Re-add anyone who still needs access to the parent, at the right level.
- Select the item, open Manage access, and choose Inherit permissions.
- Confirm and verify access for the affected users.
Once you restore, the item follows the parent again. If someone loses access they expected, you missed a step in the re-add.
How to Set SharePoint List Permissions for a Single List or Library
SharePoint list permissions let you lock down one list or library without changing the whole site. Use this when a single list holds sensitive data like HR records or financials.
- Open the list or library.
- Select Settings, then Permissions.
- Choose Stop Inheriting Permissions.
- Remove any groups that should not have access.
- Add the correct group and assign the right permission level.
- Save and test with a member account.
The same steps apply to SharePoint library permissions; only the starting menu differs.
For teams that want hands-on practice with these settings, SharePoint Fundamentals offers a two-day workshop covering document management, site navigation, permissions, and collaboration.
SharePoint Access Requests: Route, Approve, and Review
SharePoint access requests let users ask for access instead of hunting down an owner.
Turn it on in Site settings, then Site permissions, then Access requests settings. Set who receives requests and whether users can share links.
A working process has three parts:
- Route: send requests to a named owner or shared mailbox, not a single person who may be on leave.
- Approve: check the request against the person's role before granting anything.
- Review: clear the pending queue weekly.
The approval step is where least privilege lives. Grant the lowest level that lets the person do their job, Read, not Edit, for a report.
Sharing Links and External Sharing: Where Permissions Leak
Sharing links are the fastest way permissions leak. Microsoft's SharePoint sharing overview documentation explains the link types, but the practical rule is simpler: match the link to the audience.
- Specific people: best for sensitive files.
- People in your organization: good for internal sharing.
- Anyone with the link: highest risk, use sparingly.
External sharing and guest access widen the door further. Set a tenant-level policy for who can share externally, then review guest accounts on a schedule.
If a leak already happened, the Microsoft 365 security guidance on auditing and alerts helps you trace it.
Audit and Troubleshoot Permissions Before Sprawl Sets In
A permission audit is a scheduled review of who has access to what, and whether that access is still justified. For a deeper walkthrough, see How to Clean Up SharePoint Sprawl: A Step-by-Step Guide.
A Repeatable Audit Checklist
Work through these items in order. Each one maps to a control you can hand to an auditor or a new site owner.
- List every site with unique permissions and note the owner of each.
- Flag any item with more than one broken inheritance and confirm the reason is documented.
- Identify users with direct permissions outside a group and move them into a group or remove them.
Set a review cadence that matches the site's risk: quarterly for HR or financials, semiannual for a general team site. Put the cadence on a calendar with a named owner.
Troubleshooting Decision Tree: Diagnose Before You Change
When a user reports an access problem, resist the urge to grant access. Diagnose first, because the fix is often removing the wrong grant rather than adding a new one. Work from the item up, and stop at the first unique permission set you hit.
- Can the user reach the site at all? If not, check Microsoft 365 group and Entra ID group membership first. Teams membership grants site access, and nested Entra ID groups can grant access you did not assign in SharePoint.
- Can they reach the site but not the library or list? Check whether the list has unique permissions; if so, confirm the user's group is in the list's permission set at the right level.
- Can they reach the list but not a specific item or folder? Check for item-level sharing links and broken inheritance on the folder. A single shared file can grant Limited Access without granting the surrounding library.
- Can they open the item but not edit it? Confirm the permission level. Contribute allows editing own items; Read does not allow editing; View Only blocks download and print even when the file opens.
- Did access work yesterday and fail today? Check recent changes to group membership, sharing links, and inheritance. A restored inheritance or removed group member is the usual cause.
- Is the user seeing a sharing link that no longer works? Check link expiration and whether the link was revoked. Expired links fail silently for the recipient.
How Permission Changes Propagate Across Connected Services
SharePoint permissions do not live in isolation. A change in one layer can propagate to others, and understanding which changes travel is the difference between a clean fix and a new problem.
- Microsoft 365 group membership grants access to the connected SharePoint site, Teams channel, and shared mailbox. Adding someone to a Team adds them to the group and therefore to the site.
- Entra ID group membership flows into SharePoint groups when nested inside one. Removing a user from the SharePoint group does not remove them from the nested Entra ID group, so access persists.
- Sharing links are scoped to the item or folder and do not change group membership. Revoking a link removes access granted only through that link.
A common pattern is a user removed from a SharePoint group who still has access through a nested Entra ID group or a Teams membership. Fix the source layer, the Entra ID group or the Team, rather than adding a compensating denial in SharePoint, which the platform does not support cleanly.
Bulk Administration with PowerShell and Power Automate
Manual clicks do not scale past a few dozen sites. Use the SharePoint Online Management Shell and PnP PowerShell to list permissions across sites and report unique access in one pass.
Start with reporting before automating changes. Run a read-only report first, validate the output against a known site, and keep a rollback plan: export current permissions, change one site, verify with a test account, then roll out.
If permission sprawl has already taken hold, MTRC Enterprises can help teams set policy and close access gaps.
Schedule a Permissions Review With MTRC Enterprises
Permission problems rarely fix themselves. They compound quietly until an audit, a breach scare, or a failed migration forces the issue.
MTRC Enterprises helps IT and operations teams get this under control, with hands-on implementation alongside your team, knowledge transfer included in every engagement, and fixed-price scopes with defined deliverables.
Get started with MTRC Enterprises and build a permissions model your team can actually maintain. Schedule your free consultation to review your current setup.
Frequently Asked Questions
What is the difference between a SharePoint group and site permissions?
A SharePoint group is a container that holds users and is assigned a permission level. Site permissions are the actual rights, such as Full Control, Edit, Contribute, or Read, that determine what a user can do. You manage people through groups and manage capabilities through permission levels. This separation is what makes role-based access control practical: change the group membership, not the permission level, and the site's access model stays consistent.
How do I stop inheriting permissions on a SharePoint list or library?
Open the list or library, go to Settings, then Permissions for this list or library, and select Stop Inheriting Permissions. SharePoint copies the current parent permissions so you can then remove or add users and groups without affecting the site. Break inheritance only when the list genuinely needs a different audience, such as an HR folder inside a general team site. Each break adds administrative overhead, so document why it was done and review it during your next audit.
How do I check who has access to a SharePoint site?
Go to Site Settings, then Site Permissions, and review the groups and direct assignments listed there. Check each SharePoint group's membership, then look for unique permissions on lists and libraries, since those do not appear at the site level. For a full picture, use the site's sharing report or run a PowerShell script to export group members and unique permission scopes. Schedule this review quarterly so access does not accumulate unnoticed.
How do I manage access requests in SharePoint?
In Site Settings, open Site Permissions and select Access Requests Settings. Turn on Allow Access Requests, set the email address that receives requests, and choose whether members can share. Approvers should review each request against the permission level needed, grant the lowest level that works, and record the decision. Review pending and past requests monthly; unresolved requests often mean users are blocked or finding workarounds that bypass your governance.
