SharePoint Online Permissions: Troubleshooting & Best Practices for SMB

Introduction

Managing SharePoint Online permissions is critical for secure and efficient collaboration, but it can be challenging – especially for small and medium businesses (SMBs). SharePoint’s permission system is powerful yet complex, with hierarchical inheritance and numerous sharing options[1]. Many administrators find themselves asking “Who has access to this, and why?” when permissions issues arise[1]. Common scenarios include users getting “Access Denied” errors or, conversely, sensitive content being accessible to unintended people due to misconfigured sharing[2][1]. This report provides an SMB-focused guide to troubleshoot permission issues, check and audit existing permissions, and structure permissions in a way that is easy to maintain. We’ll cover best practices (like using groups and inheritance wisely), recommendations for reviewing permissions, and step-by-step instructions for common permission management tasks.

Common SharePoint Permission Challenges: As highlighted above, typical permission issues include users being mistakenly left without access (or given too much access), confusion from broken inheritance, and limited visibility into current permission assignments. For example, breaking permissions on a folder or file for one person can snowball into many custom exceptions, resulting in an “unwieldy spiderweb” of unique permissions over time[1]. Similarly, overly permissive sharing links (like “Anyone with the link”) can lead to files being forwarded broadly without oversight[1]. SMBs often have lean IT teams, so keeping permissions simple and consistent is key. In the next sections, we’ll outline best practices to preempt these issues and keep your SharePoint Online permissions both secure and manageable.

Best Practices for SharePoint Online Permissions Management (SMB)

Adopting clear permission strategies will prevent many issues before they occur. Below are the top best practices to ensure an easy-to-maintain permission structure, tailored for SMB needs:

• Use Groups for Permissions, Not Individuals: “Granting permissions directly to individual users can make management overly complex over time.” Instead, assign permissions to SharePoint security groups or Microsoft 365 Groups, and then add users to those groups[3]. This centralizes management – you can change a group’s access in one step rather than updating many individual entries. For example, rather than giving 10 people each Edit rights on a site, put them in a “Site Members” group that has Edit permission. SharePoint comes with three default groups per site (Owners, Members, Visitors), which correspond to common role levels (Full Control, Edit, Read)[4]. For communication sites or classic sites, use these built-in groups for assigning access[5]. For team sites connected to Microsoft 365 (Office) Groups, manage access via the group’s membership (Owners and Members) to keep consistency across Teams, SharePoint, and other services[1]. Using groups makes it easier to audit who has access and ensures consistency across your site collections.

• Keep Permissions Inherited at Site Level Whenever Possible: The best practice is to manage security at the site level, not at the individual file or folder level[6]. In SharePoint, subsites, document libraries, and items by default inherit permissions from their parent site. Breaking this inheritance in many places leads to a confusing patchwork of permissions. It’s recommended to grant access at the highest level (site or library) that makes sense for your content[1]. Avoid creating unique per-item permissions unless absolutely necessary. If you must grant an exception (say, a confidential folder within a site), document it and periodically review it[3]. A simpler structure (e.g. whole site or whole library access) is much easier for a small team to maintain than dozens of item-specific rules.

• Leverage Default Roles and Group Memberships: Take advantage of SharePoint’s standard roles: Owners (Full Control), Members (Edit/contribute), and Visitors (Read)[7]. For most SMB scenarios, these cover the needed levels of access. In a Microsoft 365 Group-connected Team site, all group Owners automatically become site owners and group Members become site members[7]. Use that mechanism to manage who can access the site: adding someone to the M365 Group gives them site access, and removing them revokes it, which keeps SharePoint and Teams in sync[1]. For a communication site (which isn’t M365 group-connected), assign users to one of the three SharePoint groups via the Site Permissions panel[7]. Sticking to these default structures means you rarely need to define custom permission levels or unique groups, reducing complexity. Only if a set of users needs a very different level of access than the default groups provide should you create a new SharePoint group or custom role.

• Restrict and Monitor External Sharing: SMBs often collaborate with external clients or partners, but it’s important to control this carefully. Review your SharePoint external sharing settings at both the tenant and site level to match your security comfort level[3]. It’s usually best to avoid “Anyone with the link” sharing in favor of more restricted options. Use “Specific People” links when sharing documents with external users so that only intended individuals can use the link[3]. You can also set expiration dates on external sharing links (for example, 30 days) to prevent indefinite access[1]. In the SharePoint Admin Center, you can define the default sharing link type (e.g. internal only by default)[1]. For each site, consider disabling external sharing entirely if it contains sensitive data that should never leave the organization. Regularly audit external access: SharePoint provides an ability to review files or sites shared externally (for instance, via the “Shared with external users” report in site usage, or using PowerShell) – use these to keep tabs on what’s been shared outside.

• Follow the Principle of Least Privilege: Grant each user the minimum level of permission they need to do their job[6]. In practice, this means, for example, giving read-only access to users who only need to consume information, rather than edit access. Avoid the temptation to give everyone higher privileges “just in case” – unnecessary Full Control or Edit rights can lead to accidental changes or deletions[6]. Especially never put all users in the Owners group; Full Control allows deletion of the site or changing settings[6]. Instead, limit Full Control to a select few administrators. If the built-in roles don’t meet a specific need, you can create a custom permission level (for instance, a role that can edit but not delete items)[3]. SharePoint Online provides five main predefined levels (Full Control, Edit, Contribute, Read, and more) and supports defining custom levels[4]. It’s best to add new custom levels rather than modify the defaults, so you retain a known baseline[4]. In general, start with the lowest necessary access and only elevate if required.

• Review and Clean Up Permissions Regularly: Permissions tend to “drift” over time – people change roles or leave, and content gets reshuffled. Make it a routine to audit your SharePoint permissions on a schedule (e.g. quarterly or biannually)[3]. An admin or site owner should list who currently has access and verify it’s still appropriate. Remove users who no longer need access – for example, if a temporary contractor’s project ended, ensure their permissions (or guest account) are revoked[6]. Office 365’s audit log or third-party tools can help identify when users last accessed content, which is useful for clean-up. Some organizations use scripts or tools to generate permission reports (one example: a tool like DeliverPoint can report SharePoint access rights[3]) – SMBs might not need fancy software, but even a manual review of group memberships and shared links is valuable. Document any unusual permission setups (like if inheritance was broken deliberately) so that the context isn’t lost and can be revisited later[3]. Finally, train site owners or managers on these practices[3]. In an SMB, the person managing SharePoint might also wear other hats; investing a bit of time to understand permission concepts pays off by preventing mistakes.

By adhering to these best practices – using groups, simplifying inheritance, locking down external sharing, least-privilege assignments, and regular reviews – SMBs can maintain a secure yet flexible SharePoint environment that doesn’t require constant firefighting.

Checking and Auditing Existing Permissions

To troubleshoot or maintain SharePoint permissions, you first need to see what permissions are in place. SharePoint Online provides built-in ways to check who has access to sites, libraries, or even individual files/folders:

Site Permissions Page (Site-Level Overview): If you are a site owner, you can view the overall site permissions via Settings (gear icon) > Site Permissions. This will show the three default SharePoint groups (Owners, Members, Visitors) and who is in each group[7]. On modern team sites, it also shows the Microsoft 365 Group membership (Owners/Members). By expanding each group, you can review which users or AD security groups are members. This page also allows inviting new people and will add them to the selected group automatically (e.g. choosing “Read” adds them to Visitors)[7]. For a quick audit, list out the members of each group and ensure they are correct for the site’s purpose.
“Manage Access” Panel (File/Folder-Level Sharing): For individual files or folders, SharePoint’s Manage Access feature shows exactly who can access that item. To use it, navigate to the document library, select the file or folder, and click the “ Manage access” option (often found in the info/details pane or via the context menu). This panel has tabs for People, Groups, and Links[8]:
- The Groups tab shows which SharePoint groups have access (and their permission level) inherited from the site. This tells you, for instance, that all members of “Site Members” group can edit the file[8].
- The People tab lists any individuals who have unique access to that item (for example, directly shared via the Share dialog)[8].
- The Links tab lists any share links that grant access (like anyone-with-link or specific-people links) and who has used those links[8]. This is a convenient way to audit sharing on a specific file/folder: you might discover that a file was shared with a guest external user or via a link open to your whole organization, and then take action to remove or tighten that if needed.
Check Permissions Tool (Effective Access for a User): SharePoint has a built-in “Check Permissions” feature that lets you input a user or group’s name and see what level of access they have and how they have it. To use this, go to the site’s Advanced permissions settings (from Site Permissions page, click the Advanced permissions link, which brings you to the classic permissions page). On that page, click the Check Permissions button, enter the user or group name, and click Check Now[8]. The result will show something like: “User X: has Contribute access via ” or “has access via sharing link”[8]. For example, it might say “Mary has Edit access to this item as a member of Site Members group.”[8] If the user has no access at all, it will show None[8]. This tool is extremely useful to troubleshoot – if a user says they can’t get into a site or file, run Check Permissions on them at the site (or item) to confirm if they are indeed missing permission and, if they do have permission, which group or link is granting it. (It might reveal that they do have access through a group, which means their issue might be elsewhere, like a sync/login problem, or they’re looking at the wrong location.)
Understanding “Limited Access” Entries: When reviewing site permissions, you might encounter a user listed with Limited Access. This status appears when a user has access to a specific item (like a single file or folder) but not to the parent site or library as a whole[5]. SharePoint gives them a behind-the-scenes limited access so they can reach the item. For instance, if you share one document to an external user, that user will show up with Limited Access at the site level. Limited Access by itself isn’t a full permission level — it’s a placeholder that allows the unique permission on the item to function. If you see many users with Limited Access, it’s a sign that there are lots of item-level shares; you might review those to ensure they’re all still needed. You can click “Show users” next to the limited access message to see which items are shared uniquely[5].
Audit Logs and Reports: Office 365 provides audit logging that can capture permission changes and access events. An admin (with appropriate roles) can search the Unified Audit Log for events like “Shared file, added user to group, removed user from site” etc. While this isn’t a real-time view of permissions, it’s useful for after-the-fact auditing or monitoring unusual changes. Additionally, in the SharePoint Admin Center, you can see external users and their access, and for each site, you can retrieve a report of what has been shared externally. For a broader insight, you might use PowerShell scripts (for example, using Get-SPOUser and Get-SPOSite cmdlets) to enumerate who has access to what on your sites[1]. SMBs with fewer sites might not need a full tenant-level report often, but if you suspect some sites have overly permissive settings, it might be worth running a script or using a third-party reporting tool to get a full picture[1].

Tip: It’s a good practice to periodically audit permissions on key sites. For each important site (like those with sensitive data), have the site owner or admin:

Review the members of Owners, Members, Visitors groups.
Check if any unique permissions exist on libraries or folders (Site Permissions > Advanced > look for any message about “some items have unique permissions”[5](https://support.microsoft.com/en-us/office/customize-permissions-for-a-sharepoint-list-or-library-02d770f3-59eb-4910-a608-5f84cc297782)).
Use Check Permissions for a couple of sample users (e.g., a regular team member, an external partner) to verify the setup is as expected.
Document any irregularities (e.g., “Folder X in Documents library is shared with external user Y with edit rights”) and decide if they are still necessary.

By proactively checking, you can catch issues like someone still having access after they left the company, or a confidential file that was accidentally shared too broadly. This reduces the chance of permission problems and also makes troubleshooting easier since the environment stays tidy.

Troubleshooting Permission Issues: Step-by-Step Approach

Even with good practices, permission issues can occur. When a user reports a problem (like “I can’t access the site/folder” or “User X shouldn’t see Y document”), a systematic troubleshooting process helps identify and resolve the issue efficiently. Below is a step-by-step approach:

Gather Information from the User: Start by clearly identifying which site or content the user is trying to access and what error or outcome they are seeing. Are they getting an “Access Denied” message, or perhaps they can see a site but not a particular folder? Also note the user’s role (are they an internal employee, a guest, part of a specific department?). Understanding the scope of the issue (one file vs. entire site) will guide your investigation[2]. If the user sees an “Access Request” (they clicked a link and it let them send a request for access), that indicates they currently have no permission there at all.
Verify the Permissions Hierarchy: Check the permission inheritance and structure for the resource in question. Determine the nearest parent site or library that controls permissions. For example, if the issue is with a file, see if that library has unique permissions or inherits from the site. Ensure the user has access at each level: site -> library -> folder -> item[2]. If at any parent level the user is not included, that would cause a denial downstream. For instance, if a document library is set to only allow a “HR Team” group and the user isn’t in that group, the user will be denied for all files in that library. Use the Check Permissions tool on the site or library to see the user’s access (or lack thereof) as described earlier[8]. If the site itself denies the user, focus on fixing site-level membership; if the site is fine but a subfolder is unique, the issue is at that subfolder.
Examine Group Memberships: Most permissions in SharePoint come via group membership. Verify which groups the affected user belongs to. Compare that to which groups should have access. For example, if the site’s Members group has edit rights, confirm if the user is in that Members group. It’s possible the user was never added, or was removed. Conversely, if a user is seeing something they shouldn’t, check if they were accidentally added to a group that grants that access (e.g., their name might have been added to the Visitors group of a site they shouldn’t view). In an Office 365 Group-backed site, check the Office 365 Group membership list. In classic sites, check the user’s entry via Site Permissions > Check Permissions which will list groups[8]. If the user is missing from the expected group, that’s likely the cause of “no access.” Add them to the appropriate group (see the guide in the next section) and have them retry. On the other hand, if the user has unwanted access through a group, you’ll need to remove them from that group or adjust that group’s privileges (covered below under removal). Keep an eye out for group sync issues as well – if using AD security groups, ensure the user is in the right AD group; if there’s a delay in Azure AD syncing, the SharePoint site may not “see” their updated membership immediately[2].
Identify Unique or Broken Permissions: If group membership isn’t the issue, consider whether unique permissions are at play. Has someone broken inheritance on a particular subsite, library, or folder? These “permission break” points can cause inconsistencies. For example, maybe the user was added to the site, but a specific library was set to unique permissions and they weren’t included there – result: they can access the site homepage but get denied in that library. Navigate to the relevant library or folder and check its permissions (Settings > Library Settings > Permissions for this library). If you see a message “This library has unique permissions” or users listed directly, then inheritance was broken. Review those unique permissions: is the user (or a group they belong to) present? If not, that’s the gap[2]. You can choose to add the user/group there or possibly re-inherit permissions if the unique setup was not needed (restoring inheritance will make it match the parent site’s permissions again). Conversely, if troubleshooting someone seeing too much, look for unique grants that might have given broader access than intended (for instance, a folder shared with “Everyone”). Unique permission configurations should be carefully audited here.
Check for Deny or Policy Settings: SharePoint allows explicit deny permissions or other advanced policies, though these are less common in SharePoint Online (more typical in on-premises). If someone set up a permission policy that denies certain groups, it could override other permissions and cause unexpected access issues[2]. For example, if a “Deny Edit” permission was applied to a user on a particular list, that user cannot edit even if a group says they should. In Office 365, explicit denies would usually come from things like Information Rights Management or conditional access policies rather than SharePoint’s UI. It’s rare in an SMB scenario, but if all else fails, verify that there are no special deny entries (the classic permission page would show a red cross icon if a deny is in effect). Also, check site-level settings such as site collection read-only locks or missing licenses for the user – but those are edge cases. Typically, a straightforward SharePoint Online site won’t have deny rules set unless an admin specifically added one via advanced settings or code.
Review External Sharing Settings (if applicable): If the user in question is an external guest who can’t access something, the issue might be the site’s external sharing setting. Each site (especially new-style sites) can allow or disallow guest access. If a site disallows externals and you try to share with a guest, they’ll be unable to enter even if they got an invite. Similarly, if a guest can access the site but not open a document, it could be that the document is using a sharing link type they can’t use (like “Organization only” link, which guests can’t open). Ensure the site’s sharing setting is at least as permissive as needed (e.g., set to allow existing guests or new guests as appropriate). For internal users, also consider if the content is in a site they have never been given access to – maybe the user assumed they should have access but the site owner hasn’t shared it with them yet (communication gap). In such a case, the solution is simply to grant them access following governance procedures.
Use the Tools to Pinpoint the Issue: At this stage, leverage the tools described in the previous section:
- Run Check Permissions for the user on the site and on the specific item (if it’s a single file/folder issue). This will explicitly tell you if the user has any access and through what means[8].
- Look at the Manage Access panel on the item in question to see if perhaps a sharing link was expected but not in place, or if the user was mistakenly removed.
- Check if the user appears in the Site Members or Visitors list. If not, that’s the red flag. These tools often pinpoint the exact cause (e.g., “None” in Check Permissions means the user needs to be added somewhere).
Apply the Fix – Adjust Permissions: Once you’ve identified the likely cause, fix the permissions configuration:
- If the user was not in the appropriate group, add them to the site’s Members/Visitors (or relevant) group to grant access (or if inappropriate access, remove them from a group).
- If inheritance was broken and the user needs access there, either add the user (or a group they are in) to the unique permissions on that library/folder or if the unique setup is unnecessary or overly complicated, restore inheritance to simplify and then add the user via the normal group.
- If a sharing link was too permissive (e.g., “Anyone” link causing unintended access), consider disabling that link and using a tighter one.
- If the user’s access is through a link and they need permanent access, a better fix is to formally add them to the site or relevant group instead of relying on a link.
- In any case, aim to resolve by aligning with best practices (for example, if you find a user was given direct permissions, you might move them into a group for cleaner future management). While making changes, be mindful of the interface limitations: If you try to edit a user’s permissions on an item and see the option is greyed out, it’s likely because that item currently inherits permissions – you’d need to break inheritance first to individually modify or remove a user[9]. Similarly, if the site is group-connected, you typically manage members via the M365 group rather than the SharePoint UI (the UI will prompt you accordingly).
Test and Confirm Resolution: After making permission changes, verify that the issue is resolved. Have the user try accessing the resource again. If possible, test it yourself by logging in as a test account with similar permissions. Note that permission changes might not take effect instantaneously on the user’s end due to caching[10]. SharePoint Online’s interface can sometimes take a few minutes to reflect new access (for example, a user added to a group might need to sign out and back in, or close their browser, to pick up the new token)[10][9]. If the user still cannot access after being added, have them clear their browser cache or try an incognito window/different browser[9] – this often bypasses any cached credentials and forces a fresh permissions check. Likewise, if you removed someone’s access, double-check they truly can’t get in (you might use the Check Permissions tool again for their name to confirm it now shows “None”). In case the user still has access after removal, it means they still belong to a group granting it or a link is still active – re-check group memberships and sharing links for any you might have missed[9].
Document and Prevent Future Issues: Once resolved, take note of what the issue was and how it was fixed. Was it a process mistake (user never added to the site) that you can address by improving your onboarding checklist? Or was it a rare scenario of someone needing access outside of normal groups (maybe consider creating a new group if that’s a recurring need)? Document any permission changes you made, especially if you had to create new unique permissions or groups, so that this knowledge isn’t lost[2]. Keep an eye on the situation to ensure the fix sticks – for example, if the problem was due to a broken inheritance that you decided to remove (restore inheritance), make sure site owners don’t break it again without a good reason. If multiple similar issues arise, it might point to a need for user training or revisiting your permission architecture (see best practices above). For SMBs, a brief guide to site owners on how to manage access (and the importance of using the correct groups) can greatly reduce permission mishaps.

If you follow this systematic approach, most permission issues can be identified and resolved logically. It boils down to finding where the permission break is – at what level is the user’s access cutoff or opened – and then correcting it in line with your governance. Often, the fix is simply adding the user to the right place or removing an unintended permission. By carefully checking each layer and using SharePoint’s tools (Manage Access, Check Permissions), you remove the guesswork and zero in on the cause of the issue.

Step-by-Step Guide: Common Permission Management Tasks

In this section, we provide concise, step-by-step instructions for key tasks to manage SharePoint Online permissions. These tasks will help implement the best practices and fixes discussed above, and are geared toward administrators or site owners in SMB environments.

Checking a User’s Permissions on a Site or Item

To troubleshoot or audit, you often need to confirm what access a particular user has.

To check a user’s permissions on a SharePoint site:

Navigate to Site Permissions: Go to the site in question. Click the Settings (gear) icon in the top right, then choose Site permissions. In the site permissions pane, click Advanced permissions settings (this opens the classic permissions page for the site).
Use “Check Permissions”: On the Ribbon of the classic permissions page, click Check Permissions. In the dialog, enter the user’s name or email and click Check Now[8].
Review Effective Access: The result will show what permissions that user has on the site and through which group or mechanism[8]. For example, it might say the user “has Read access via group” or “None” if they have no access[8]. It may list multiple entries if the user has access via different paths (e.g., via a group and via a sharing link).

To check a user’s permissions on a specific file or folder:

Navigate to the library where the item resides and locate the file or folder.
Click the “…” (ellipses) or select the item and open the Details/Information pane (often an “i” icon). In the details pane, find the Manage Access section[10].
In Manage Access, click Advanced (usually an option if you scroll the Manage Access dialog/pane)[10]. This will take you to the item’s permission page (which looks similar to a site’s permission page).
On the item’s permission page, click Check Permissions and enter the user’s name, then Check Now[10].
Read the effective permissions as in the site case. This will tell you if the user has access to that item and if so, by what means (group, or direct share, etc.)[8].

Alternatively, on modern SharePoint, there’s a quicker way: in the Manage Access panel itself, you can use the search box “Enter a name or email” under the People section – typing a user’s name there will show if they have access and at what level (this effectively surfaces similar info).

Using these steps, you can quickly verify “does user X have access here, and how?” which is fundamental for deciding any permission changes.

Granting a User Access to a Site

When a new team member or an existing user needs access to a SharePoint site (or you discover someone lacks access during troubleshooting), the recommended method is to add them to an appropriate group for the site rather than granting individual rights.

For a Communication Site or classic SharePoint site (no Microsoft 365 group):

Go to the site and click the Settings (gear) icon > Site permissions.
Click Invite people (in modern UI) or Share site. Enter the user’s name or email.[7]
Select permission level: Choose the level of access – options typically are Full Control, Edit, or Read. (In modern Share dialog, these map to adding the user to Owners, Members, or Visitors groups respectively[7].) For example, choose Read to give view-only access (this will add the user to the Visitors group automatically).
(Optional) Uncheck the box to notify by email if you don’t want to send an email invitation (you might do this if you’ve already communicated access to the person).
Click Add or Share. The user will be added to the site’s permission group at the level specified[7]. They can now access the site according to that group’s rights.

Under the hood, this process is adding the user into one of the site’s SharePoint groups. You can verify by expanding the group list on the Site permissions page – the user’s name will appear under Owners, Members, or Visitors depending on what you chose[7].

For a Team Site connected to a Microsoft 365 Group (e.g., created via Teams or Office 365):\ In this case, the preferred method is to manage membership through the Microsoft 365 Group:

Open the site (or the associated Team in Microsoft Teams). On the SharePoint site, you may see a “Members” link or icon in the top right corner (it might show the current members’ icons). Click Members (or alternately, in Teams, go to the team’s Manage team > Members).
Click Add members. In SharePoint’s interface, this might prompt a panel to add members to the Microsoft 365 Group[7][7].
Enter the person’s name/email. Choose whether to add them as a Member (default, which gives edit rights on the site) or an Owner (which is like site admin)[7].
Click Save or Add. This action adds the user to the Microsoft 365 Group, which in turn grants them access to the SharePoint site (and other connected services like the Team, Planner, etc.)[7].

Because Microsoft 365 group sites don’t have a Visitors role via the group, if you need to give someone read-only access without making them a full member, you have two options:

Option 1: Temporarily treat the site like a standalone site and use Site permissions > Grant Access (as per communication site steps) to directly add the user with Read. This will add them to the Visitors group of the site without adding to the M365 group (SharePoint Maven calls this “Option 3” – sharing the site only)[7].
Option 2: Create a separate communication site for read-only audiences if applicable. Most SMBs just add needed users as members even for read, or use the first option for ad-hoc read access.

After adding a user, they should receive an email notification (if you kept that option checked) and can access the site by navigating to its URL. Always ensure you add users to the correct site (it’s a common mistake to add someone to a similarly named site or group by accident).

Creating and Using Permission Groups

While default groups suffice in many cases, sometimes you’ll want a custom SharePoint group – for example, a “Project Alpha Members” group for a subset of people who need access to only one library. Creating a SharePoint group allows you to re-use that group on various parts of the site or even across sites (if you assign it permissions).

To create a new SharePoint security group on a site:

Go to Site permissions > Advanced permissions settings (classic permissions page).
Click Create Group (usually in the Ribbon or near the top of the groups list).
On the Create Group page, enter a Name for the group (e.g., “Project Alpha Members”). You can add a description if desired.
Set the Group Owner (by default, the person creating it or site owners can be owners of the group).
Choose group settings: e.g., who can view or edit the membership (usually keep default so only owners can edit membership).
Assign a Permission Level to this group for the site. You’ll see a list of permission levels (Full Control, Edit, Contribute, Read, etc.). Select the appropriate level that this group should have on the site. For instance, if this group is meant to edit content, choose Edit; if read-only, choose Read.
Click Create.

This will create the group and automatically grant it whatever permission level you chose on the site. Initially the group is empty, so next:

Add users to the group: After creating, you’ll be taken to the group’s page (or you can access any group by clicking on it from the Advanced permissions page). Use the New > Add Users button (in classic interface) or “Add members” in modern interfaces to add people to this group. Enter the names/emails of users (or even other AD groups) to include, and confirm. Now those users are members of the new group.

You can use the new group to grant permissions elsewhere if needed. For example, you could break permission on a particular library and assign your new group Access just to that library (giving that group maybe higher or lower rights there as needed). This approach is cleaner than adding each of those individuals one by one to the library.

SMB Tip: Avoid proliferation of too many custom groups on a small tenant – stick to a clear naming convention and only create a group if you know you’ll manage it separately from existing ones. Each site’s groups are local to that site (unless you explicitly use the same named AD security group). So, “Project Alpha Members” group on Site A won’t automatically grant anything on Site B unless you also add it there. For cross-site consistency, you might use an Azure AD Security Group added into SharePoint groups, but that requires Azure AD management. Many SMBs find a few well-chosen SharePoint groups per site strikes the right balance.

Modifying Permissions for a Library or List (Breaking Inheritance)

Sometimes you want a specific document library or list within a site to have different permissions than the rest of the site. For example, in a team site, you might have a library that only managers should see. This requires breaking permission inheritance and then setting unique permissions on that library.

To set unique permissions on a document library (or list):

Navigate to the library (or list) on the site. Click the Settings (gear) icon > Library settings (or List settings for a list)[5]. In modern UI, you might need to click Settings > Site contents > … > Settings gear on the library.
On the Library Settings page, under Permissions and Management, click Permissions for this document library (or similar for list)[5]. You’ll see the library’s permission page, which by default will state it inherits from the parent (site).
Click Stop Inheriting Permissions (on the Ribbon “Permissions” tab). Confirm the prompt. Now the library’s permissions are independent from the site[5].
Immediately after breaking inheritance, the library will have a copy of the parent site’s permissions (everyone who had access to the site still has it here, but now you can change it). Adjust the permissions as needed:
- Remove any groups or users that should not have access to this library. For example, if you want to restrict it from regular members, you might remove the “Site Members” group from the library’s permissions.
- Grant access to specific group or users that need access if they aren’t already listed. For example, if this library is for managers, you might have a “Managers” group – click Grant Permissions, enter “Managers” group, and assign (perhaps Edit or Read as appropriate).
- You can also change permission levels for a group on this library. For instance, maybe on the site “Members” have Edit, but on this library you want members to only have Read – you can edit the “Site Members” group entry here and lower it to Read.
Click OK/Save if necessary for any dialogs. The library now has a tailored permission set. Only the groups/users listed on its permission page have access; it no longer automatically includes everyone from the parent site.

To restore inheritance: If later you decide this unique permission setup is too much to manage, you can reverse it by going back to the library’s Permissions page and clicking Delete unique permissions / Inherit Permissions (the button may say “Delete unique permissions”, which essentially means “restore inheritance”). This will wipe out the custom settings on that library and re-inherit from the parent site’s current permissions[3]. Use this carefully – if you had very specific grants, you will lose them. It’s wise to document or screenshot the custom permissions before inheriting in case you need to reference what was there.

Note: Avoid breaking permissions at too granular a level (like individual items) frequently, as noted earlier. If you do break inheritance at a subfolder or item level, the steps are similar: go to that folder’s manage permissions and stop inheritance, then adjust. But manage such exceptions sparingly.

Removing or Revoking User Access

When someone should no longer have access to a site or content (e.g., they changed teams or left the organization), you’ll want to remove their permissions.

To remove a user from a site:

If the user was given access via a SharePoint Group: Remove them from that group. Go to Site permissions > Advanced, click the group name (e.g., Site Members), select the user, and choose Remove User from group. This revokes their access that was via that group.
If the user was given direct permissions (uncommon in SMB best practice, but possible via the Share dialog or someone adding them explicitly): Go to Site permissions > Advanced. If you see the user’s name listed individually with a permission level, check the box next to their name and click Remove User Permissions. In modern UI, the site permissions pane might list “Guests or individual people” if any – you can remove them there as well.
If the site is an M365 Group site: remove the user from the Microsoft 365 Group (via Outlook, Azure AD, or the Members panel). Once they’re no longer a member, they lose access to the site automatically.

To remove a user’s access to a shared file or folder:

Use the Manage Access panel on that item. Under the People section, if the user is listed with access, click the dropdown by their name and select Stop Sharing or Remove[8]. If their access was via a link you gave them, you might instead disable that link in the Links section.
If you had broken inheritance on a folder and added a user directly, you’d remove them on the folder’s permission page similar to above (select and remove).

After removal, the user might still show up with Limited Access on the site (due to sharing history) until all their direct links are removed. The key verification is using Check Permissions for that user – it should now show “None” for the site or item[8]. If it still shows access, it means they have it through some other route (perhaps another group). For example, an employee who moved departments should be removed not only from the site’s Members group, but also from any other groups (maybe a custom group) on that site or others that still grant access[9].

External Users: Removing an external user’s access can be done by removing them from the site’s guests (same as removing from groups or direct as above). Additionally, you might want to delete their guest account from your tenant if they no longer should have any access. This is done in the Microsoft 365 Admin Center (Azure Active Directory). However, simply removing them from SharePoint permissions will suffice for that site/library.

Always double-check by attempting to access as that user or using Check Permissions to ensure the removal is effective.

Customizing Permission Levels (Advanced)

SharePoint provides a set of default permission levels (Full Control, Edit, Contribute, Read, etc.) which cover most needs[4]. In some cases, you might require a custom level – for instance, a “Review” role that can edit content but not delete, or a “Contribute without delete” role. This is advanced and should be done sparingly (and only by experienced admins) because overly granular roles can confuse management. But here’s how to do it:

To create a custom permission level on a site:

Go to Site permissions > Advanced permissions settings. In the Ribbon, click Permission Levels[4].
You will see a list of existing permission levels. It’s best not to modify the built-in ones; instead click Add a Permission Level (or you can copy an existing level to start from its settings).
Give the new permission level a Name and description.
In the list of granular permissions (a long list of checkboxes like List Permissions, Site Permissions, Personal Permissions etc.), check the actions that you want to allow for this level. For example, to create “Edit without delete”, you might start with Edit and then uncheck “Delete Items” and “Delete Versions”.
Scroll to bottom and click Create (or Save).

Now you have a new permission level available on this site. You can assign it to users or (better) to groups via the usual permission assignment dialog. For instance, you could create a group, and when granting that group permission, choose your new custom level from the drop-down instead of the standard ones.

Note: Custom levels are scoped to the site collection. And remember the advice: only create custom levels if default ones don’t align with your needs, and do not edit or delete the default levels[4][3]. For SMB scenarios, custom roles aren’t often needed unless you have a very specific workflow (because they increase complexity). But the option is there.

Monitoring and Auditing Permissions Over Time

Managing permissions is not a one-and-done task. You should monitor changes and review access regularly to ensure the permission structure remains healthy:

Use Audit Logs: As mentioned, enable and utilize Office 365’s Unified Audit Log. Search for activities like “Added member to SharePoint group”, “Shared file externally”, “Site permission modified” etc. This helps you keep track of who is changing permissions or sharing content. For example, if an owner on one site keeps breaking inheritance or adding individuals, you might need to coach them on best practices.
Schedule Reviews: Set periodic reminders (perhaps every 6 months) to review each site’s permissions, especially for critical sites. Have site owners confirm the current membership of their groups is still valid. This can catch things like stale accounts or overly broad access. Microsoft’s recommendation and real-world best practice is to conduct regular permission reviews[3][1].
External Access Report: On the SharePoint Admin Center, you can get a report of files shared with external users. SMBs can use this to make sure ex-employees or old partners don’t retain access. Similarly, checking the list of guest users in your tenant periodically and validating if those accounts are still needed is wise.
Adhere to Governance Policies: If your organization has a security policy (even if informal), align your permission reviews with that. For instance, if policy says “Remove access immediately when someone leaves”, ensure your offboarding IT checklist includes removing from SharePoint groups. If policy says “client data sites must not be shared externally”, use the admin settings to enforce external sharing off on those sites.
Tools for Insight: If built-in capabilities aren’t enough, there are third-party tools (like Orchestry, ShareGate, etc.) that provide dashboards of SharePoint permissions and can alert you to issues. These can be overkill for some SMBs, but they highlight that the biggest challenge is often visibility – make sure you at least document your sites and who the primary owners are, so nothing falls through the cracks[1]. You can also maintain a simple spreadsheet inventory of sites with columns for Owners, Members, any special access, external sharing enabled, last review date, etc. This manual step can greatly help in tracking the state of permissions.

By continuously monitoring in these ways, you’ll catch and fix issues proactively. That means fewer surprise “I can see something I shouldn’t” or “I can’t get to my file” support tickets.

Conclusion

SharePoint Online permissions management for SMBs doesn’t have to be overwhelming. By understanding the common pitfalls (like too many unique permissions or oversharing) and following best practices (like group-based assignments and least privilege), you can set up a permission structure that is both secure and maintainable. Always start by planning your permissions at the site level – decide who should be owners, members, visitors – and try to keep to that model. Use the built-in tools to check and audit permissions, so you always know “who has access.” And when issues do arise, approach them methodically: verify the user’s access at each level, adjust group membership or inheritance as needed, and document the changes.

With regular reviews and a bit of training for those who manage sites, your SharePoint Online environment will stay clean and under control. In an SMB setting, resources are limited, but the steps outlined (which leverage mostly out-of-the-box features) are usually sufficient to handle permissions without needing expensive solutions. Stick to the fundamentals – clear structure, careful granting, and consistent reviews – and you’ll mitigate most permission problems before they impact your users[3][3]. This ensures that your team can collaborate efficiently on SharePoint, with the right people accessing the right content.

By implementing these best practices and using the step-by-step guidance, you’ll be well-equipped to troubleshoot permission issues and manage SharePoint Online permissions like a pro, keeping your SMB’s data both accessible and secure. [3][1]

References

[1] SharePoint Permissions Management: Best Practices Made Simple

[2] Troubleshooting Access Control Issues in SharePoint – Reco

[3] Top 5 Common SharePoint Permissions Mistakes and How to Fix Them

[4] How to set SharePoint Permissions – Complete Guide – LazyAdmin

[5] Customize permissions for a SharePoint list or library

[6] Top 10 SharePoint permissions best practices

[7] How to properly set up Permissions on a SharePoint Site

[8] How to check user access and permissions for a file or folder on a …

[9] How to Set User Permissions in SharePoint: Your Step-by-Step Guide

[10] TROUBLESHOOTING 101 for 365 | SHAREPOINT – CHECKING ITEM PERMISSIONS