The Complete Guide to SharePoint Permissions

SharePoint permissions can feel like a maze — especially when you're managing dozens of sites, libraries, and users across an organisation. Get them wrong and you either lock people out of content they need, or expose sensitive documents to the wrong audience. This guide explains how SharePoint permissions actually work, from the basic building blocks to enterprise-level governance.

Permission Levels: The Building Blocks

SharePoint uses predefined permission levels — each a bundle of individual rights — assigned to users or groups. Rather than toggling 33 separate rights per user, you assign a permission level that maps to a role.

You can create custom permission levels in Site Settings → Site Permissions → Permission Levels if none of the defaults fit your needs — for example, a level that allows reading and downloading but not editing.

The Three Default SharePoint Groups

Every new SharePoint site creates three permission groups automatically:

• [Site Name] Owners — Full Control. Reserved for IT staff or department heads who manage the site itself.
• [Site Name] Members — Edit (or Contribute, depending on template). Day-to-day users who create and manage content.
• [Site Name] Visitors — Read. Anyone who should view content but not edit it.

You can also connect SharePoint groups to Microsoft 365 Groups or Microsoft Entra security groups, which means membership is managed in one place and automatically reflected across all connected SharePoint sites.

Inheritance and Unique Permissions

SharePoint permissions flow downward by default. A site's permission settings are inherited by its libraries, which are inherited by folders, which are inherited by individual files. This is called permission inheritance.

Sometimes you need a specific library, folder, or item to have different permissions from its parent — for example, a restricted HR library on an otherwise general intranet site. To do this, you "break inheritance" and set unique permissions on that item.

Sharing Links: How Most Permissions Get Set Today

In modern SharePoint, many users share content by generating sharing links rather than editing permissions directly. There are three link types:

• Anyone links (anonymous) — No sign-in required. Use only for fully public content such as public downloads. Can be disabled at the tenant level.
• People in your organisation links — Any signed-in Microsoft 365 user in your tenant can access the link. Safe for broad internal sharing.
• Specific people links — Only named individuals can access. Best for sensitive documents shared with a defined audience.

Each link type can be configured with View or Edit access, an optional expiry date, and a password. Administrators control which link types are available at the tenant level in SharePoint Admin Center → Policies → Sharing, and can restrict this further per site.

External Sharing

SharePoint lets external users (guests) access content without a Microsoft 365 licence. The guest accepts an email invitation and signs in with any Microsoft or personal account. External sharing is controlled at two levels:

1. Tenant level — Sets the maximum sharing capability. Configured in SharePoint Admin Center → Policies → Sharing.
2. Site level — Can only be equal to or more restrictive than the tenant setting. Configured per site in Site Settings → Site Permissions.

For most organisations we recommend setting the tenant to "New and existing guests" (requiring sign-in rather than anonymous access), and restricting sensitive sites to "Only people in your organisation". Guest access expiry of 60–90 days with auto-renewal on activity is a sensible default.

Best Practices for SharePoint Permissions

• Use groups, not individuals. Add Microsoft 365 groups or Entra ID security groups to SharePoint groups. When someone joins or leaves a team, update the group — not 12 separate site permissions.
• Principle of least privilege. Grant the lowest permission level that allows someone to do their job. Default to Contribute rather than Edit; Read rather than Contribute.
• Avoid unique permissions below the library level. Break inheritance at the library level only. Document every exception in your governance log.
• Set sharing link defaults carefully. Configure sharing link defaults per site to "Specific people" for sensitive libraries, and limit expiry to 30–90 days for Anyone links.
• Disable legacy features you don't need. If your organisation doesn't use anonymous sharing, disable it tenant-wide. Fewer available options means fewer accidental mistakes.

Governance: Keeping Permissions Under Control Long-Term

Permissions drift over time. People move roles, projects end, and guest accounts go stale. A permissions governance plan must include:

• Named site ownership: Every SharePoint site has two named owners (redundancy for holidays and departures). Owners are accountable for the site's content and permissions.
• Quarterly access reviews: Owners attest that each group member still requires access. Microsoft Entra ID Access Reviews can automate this — guest users receive a self-service prompt and accounts with no response are automatically disabled.
• Guest lifecycle policy: Guests expire after a defined period (90 days is common) unless their access is renewed by a site owner.
• Offboarding checklist: When employees leave, their Entra ID account is disabled — but their named sharing links may remain active. IT should revoke active sharing links and remove departing users from any groups with external access during offboarding.

Common Permission Mistakes (and How to Avoid Them)

• Granting Full Control too broadly. Full Control should be reserved for site owners — not everyone who asks for elevated access. Most requests can be satisfied with Edit.
• Copying permissions from a person rather than from a group. Copying individual permissions creates ungoverned, invisible access that never gets cleaned up.
• Ignoring the default sharing link type. If your tenant's default sharing link is "Anyone", every document shared via the share button is potentially public. Audit this immediately.
• Using SharePoint groups differently per site. If "Members" means Edit on one site and Contribute on another, your governance model is inconsistent. Standardise permission levels across sites.