SharePoint Permissions Matrix: Complete Security Guide (2026)

Key Takeaways

• A SharePoint permissions matrix maps each role to the exact actions it can perform — use it for access reviews, Copilot governance audits, and new site provisioning

• Six built-in permission levels (Full Control → View Only) cover every real-world scenario; avoid custom levels

• The Contribute permission level allows editing and deleting ANY item in a list by default — restricting to "own items only" requires additional list-level configuration

• Always assign permissions to Microsoft Entra ID or SharePoint groups, never to individual user accounts

• Microsoft 365 Copilot respects SharePoint permissions but actively surfaces overshared content — audit before Copilot goes live

What Is a SharePoint Permissions Matrix?

A SharePoint permissions matrix is a table that maps every role or group to the exact actions its members can and cannot perform — across sites, libraries, lists, and individual items. It answers "can User X do Action Y on Resource Z?" in a single reference, which makes it the go-to tool for:

• Access reviews — quarterly governance check against your intended permission model

• Copilot governance — knowing which groups can surface which content before rolling out M365 Copilot

• New site provisioning — documenting intended permissions before assigning any access

• Incident response — determining fast whether an overshared file was accessible to a given group

This guide covers the complete matrix, the inheritance model, Microsoft Graph API scopes for developer scenarios, PnP PowerShell audit scripts, and the Copilot risk calculus.

The Complete SharePoint Permissions Matrix

SharePoint Online ships with six built-in permission levels. This matrix maps them to the actions that matter for developers, admins, and end users:

Action	Full Control	Design	Edit	Contribute	Read	View Only
View pages and list items	✅	✅	✅	✅	✅	✅
Download documents	✅	✅	✅	✅	✅	❌
Add items / upload files	✅	✅	✅	✅	❌	❌
Edit items	✅	✅	✅	✅	❌	❌
Delete items	✅	✅	✅	✅	❌	❌
Manage personal views	✅	✅	✅	✅	❌	❌
Create and manage lists	✅	✅	✅	❌	❌	❌
Edit pages and web parts	✅	✅	❌	❌	❌	❌
Apply themes / site designs	✅	✅	❌	❌	❌	❌
Create and manage subsites	✅	❌	❌	❌	❌	❌
Create personal alerts	✅	✅	✅	✅	✅	✅
Manage alerts for all users	✅	❌	❌	❌	❌	❌
Manage permissions	✅	❌	❌	❌	❌	❌
Delete the site	✅	❌	❌	❌	❌	❌
Change site settings	✅	❌	❌	❌	❌	❌
View site usage data	✅	❌	❌	❌	❌	❌

Source: SharePoint permission levels — Microsoft Learn

Contribute and item editing: Contribute grants EditListItems and DeleteListItems for all items in a list by default — not just the user's own. Restricting a Contribute-level user to their own items requires configuring "Item-level Permissions" under List Settings → Advanced Settings, or creating a custom "Contribute (No Delete)" permission level.

Subsites: Only Full Control includes ManageSubwebs (the base permission for creating subsites). Design does not. Note that classic subsites are deprecated in modern SharePoint Online — Microsoft recommends hub sites instead.

Role-to-Group Mapping

Map those permission levels to the three default SharePoint groups and to guests:

Group	Default Permission Level	Typical Members
Site Owners	Full Control	1–2 trusted admins per site
Site Members	Edit	Active content contributors
Site Visitors	Read	Stakeholders, cross-team viewers
(custom) Reviewers	Contribute	Add, edit, and delete items in existing lists; cannot create or manage list structure
(custom) Designers	Design	Intranet designers, template builders
External / Guest	Varies	Permission set by sharing link type (Read or Edit) — configure default at SharePoint Admin Center

Developer Permissions: Microsoft Graph API Scopes

When calling SharePoint via Microsoft Graph or the SharePoint REST API, you need the right API permission scope alongside the SharePoint permission level. Key scopes for SharePoint operations:

Operation	Microsoft Graph Scope	Equivalent SP Permission
Read site content	Sites.Read.All	Read (tenant-wide)
Read/write list items and lists	Sites.ReadWrite.All	Edit (tenant-wide)
Manage sites and permissions	Sites.FullControl.All	Full Control (tenant-wide)
Read selected sites only	Sites.Selected	Read role on selected site
Read/write selected sites	Sites.Selected	Write role on selected site (functionally similar to Contribute)

Sites.ReadWrite.All grants read, create, update, and delete on documents and list items across the entire tenant. For most developer scenarios, prefer Sites.Selected — it scopes your app to specific sites and follows least-privilege. See the full Microsoft Graph permissions reference for the complete scope list.

The Three Default SharePoint Groups

Every SharePoint site comes with three default groups. Understanding their intent is the foundation of good permission hygiene:

1. Site Owners (Full Control)

• Who belongs here: 1–2 trusted administrators per site

• What they can do: Everything — including managing permissions, deleting the site, and adding/removing other owners

• Best practice: Keep this group as small as possible. Every person with Full Control is a potential risk vector

2. Site Members (Edit)

• Who belongs here: Active contributors — the team that creates and manages content

• What they can do: Add, edit, and delete items in all lists and libraries; create and manage lists

• Best practice: Use this for day-to-day content contributors

3. Site Visitors (Read)

• Who belongs here: Consumers of information — stakeholders, leadership, cross-team viewers

• What they can do: View content only, no editing

• Best practice: This is the right group for most users. When in doubt, start with Read and escalate only when requested

Permission Inheritance: The Golden Rule

SharePoint permissions flow downward through inheritance:

Site Collection
  └── Site (inherits from collection)
        └── Library (inherits from site)
              └── Folder (inherits from library)
                    └── Document (inherits from folder)

The golden rule: Set permissions at the highest possible level and let inheritance do the work. This keeps your permission structure clean, auditable, and manageable.

When to Break Inheritance

Breaking inheritance creates a unique permission scope — the item no longer inherits from its parent. Use it sparingly:

Legitimate reasons to break inheritance:

• A "Confidential" folder within a shared library that only managers should access

• An HR list containing sensitive employee data on a department site

• A project workspace folder that external partners need access to

When you should NOT break inheritance:

• Per-document permissions for individual files (use sensitivity labels instead)

• Giving one person "Full Control" on a single folder (add them to the right group instead)

• Creating complex permission trees more than 2 levels deep

The Hidden Cost of Broken Inheritance

Every broken inheritance point:

• Creates a management burden — someone has to remember it exists and maintain it

• Breaks the audit trail — you can't see the full picture from the site level

• Causes confusion — users get "Access Denied" on items they expect to see

• Slows SharePoint — the permission check engine must evaluate unique permissions at each level

Copilot and AI-Era Permissions

With Microsoft 365 Copilot analyzing content across your tenant, permission hygiene has become a security-critical concern.

The Copilot Oversharing Problem

Copilot is permission-bound — it will never show a user content they don't have access to. But here's the catch: in every SharePoint tenant I've audited, at least one sensitive library has "Everyone except external users" in its role assignments. It was added years ago, never reviewed, and never noticed because users rarely searched for content directly.

Now Copilot actively surfaces this content in summaries, chat responses, and document suggestions. A financial report shared with "Everyone except external users" three years ago? Copilot will include those numbers in a summary — because the user has access to them.

Preparing for Copilot: A Permission Cleanup Checklist

• Audit "Everyone" and "Everyone except external users" permissions — the highest-risk sharing configurations

• Review sites with external sharing enabled — ensure guest access is still needed

• Apply sensitivity labels to confidential documents — labels enforce encryption and DLP regardless of SharePoint permissions

• Enable Conditional Access — require MFA for all admin accounts and enforce device compliance

• Run a permission audit — document your current state with the PnP PowerShell scripts below and identify gaps against your intended model

PnP Script: Find Overshared Content Before Copilot Goes Live

Run this on each site before rollout to surface "Everyone" and "Everyone except external users" role assignments:

# Prerequisites: PnP.PowerShell 3.x, PowerShell 7.4.0+, Site Owner or SharePoint Admin role
Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/YourSite" -Interactive
$overshared = Get-PnPGroup | ForEach-Object {
    $group = $_
    $members = Get-PnPGroupMember -Group $group
    $everyone = $members | Where-Object {
        # "spo-grid-all-users" = Everyone except external users login prefix
        $_.LoginName -like "spo-grid-all-users" -or
        $_.LoginName -like "c:0(.s|true"
    }
    if ($everyone) {
        [PSCustomObject]@{
            SharePointGroup = $group.Title
            EveryoneLogin   = $everyone.LoginName -join "; "
        }
    }
}
$overshared | Export-Csv copilot-overshare-audit.csv -NoTypeInformation
Write-Host "Found $($overshared.Count) SharePoint groups with 'Everyone' members"

Any group flagged here means its content is in scope for every licensed Copilot user in your tenant. Remediate before rollout.

Group-Based Permissions: The Right Way

Never assign permissions to individual users. Always use groups.

Individual Permissions (Bad)

Documents Library:
  - john@company.com → Edit
  - sarah@company.com → Edit
  - mike@company.com → Read

This becomes unmanageable at scale. When John leaves, you have to find and remove his access from every site, library, and folder individually.

Group-Based Permissions (Good)

Documents Library:
  - Marketing Team (SP Group) → Edit
  - Executive Stakeholders (AD Group) → Read

When John leaves, you remove him from the group once, and his access is revoked everywhere.

SharePoint Groups vs. Entra ID Groups

Feature	SharePoint Groups	Microsoft Entra ID Groups
Scope	One site collection	Entire tenant
Management	Site owners	IT admins / Entra portal
Best for	Site-specific permissions	Cross-site, org-wide access
Dynamic membership	No	Yes (with Entra ID P1 — requires Microsoft Entra ID P1 license)
Nested groups	No	Yes

Recommendation: Use Microsoft Entra ID security groups for organization-wide access patterns (e.g., "All Marketing Staff"), and SharePoint groups for site-specific roles (e.g., "Project Alpha Owners").

External Sharing: Secure Collaboration

External sharing is essential for modern collaboration, but it needs guardrails:

Sharing Link Types

Link Type	Risk Level	When to Use
Specific People	🟢 Low	Always preferred — only named recipients can access
People in your organization	🟡 Medium	Internal-only content that any employee should see
People with existing access	🟢 Low	Just generates a link, doesn't grant new access
Anyone	🔴 High	Avoid in most cases — creates an anonymous link

Recommended Tenant-Level Settings

• Disable "Anyone" links at the tenant level (SharePoint Admin Center → Sharing)

• Set expiration on all guest links (30 days or less is recommended — see CISA SCuBA M365 SharePoint baseline)

• Require guests to authenticate — no anonymous access

• Restrict external sharing by domain — allowlist trusted partner domains

• Enable access requests — let users request access instead of sharing broadly

Building a Permission Audit Report

Prerequisites: PnP.PowerShell 3.x (Install-Module PnP.PowerShell), PowerShell 7.4.0+, and SharePoint Administrator or Site Owner role on the target site.

Regular permission audits are essential for compliance (ISO 27001, SOC 2, GDPR). Here's a practical approach:

Step 1: Document Your Permission Structure

Use the Permission Matrix Generator to create a visual map of your permission structure. Start with a preset template and customize it to match your environment.

Step 2: Check for Broken Inheritance

Using PnP PowerShell, identify all items with unique permissions:

Connect-PnPOnline -Url https://tenant.sharepoint.com/sites/YourSite -Interactive
# Get all lists with broken inheritance
Get-PnPList | Where-Object { $_.HasUniqueRoleAssignments } |
    Select-Object Title, HasUniqueRoleAssignments
# Get all folders with unique permissions in a library
Get-PnPFolderItem -FolderSiteRelativeUrl "Shared Documents" -ItemType Folder |
    Where-Object { $_.ListItemAllFields.HasUniqueRoleAssignments } |
    Select-Object Name

Step 3: Review High-Risk Permissions

Check for overly permissive access:

# Find items shared with "Everyone"
$web = Get-PnPWeb
$lists = Get-PnPList
foreach ($list in $lists) {
    $roleAssignments = Get-PnPProperty -ClientObject $list -Property RoleAssignments
    foreach ($ra in $roleAssignments) {
        $member = Get-PnPProperty -ClientObject $ra -Property Member
        if ($member.LoginName -like "everyone") {
            Write-Host "WARNING: $($list.Title) shared with $($member.Title)"
        }
    }
}

Step 4: Export Your Permission Matrix to CSV

Generate a full permission export for your audit report:

$siteUrl = "https://tenant.sharepoint.com/sites/YourSite"
Connect-PnPOnline -Url $siteUrl -Interactive
$report = @()
$lists = Get-PnPList | Where-Object { !$_.Hidden }
foreach ($list in $lists) {
    $roleAssignments = Get-PnPProperty -ClientObject $list -Property RoleAssignments
    foreach ($ra in $roleAssignments) {
        $member = Get-PnPProperty -ClientObject $ra -Property Member
        $bindings = Get-PnPProperty -ClientObject $ra -Property RoleDefinitionBindings
        foreach ($binding in $bindings) {
            $report += [PSCustomObject]@{
                Resource    = $list.Title
                Principal   = $member.Title
                LoginName   = $member.LoginName
                Permission  = $binding.Name
                UniquePerms = $list.HasUniqueRoleAssignments
            }
        }
    }
}
$report | Export-Csv -Path "permission-matrix-export.csv" -NoTypeInformation
Write-Host "Exported $($report.Count) permission assignments"

Use the PnP Script Generator to generate customized versions of these scripts for your specific environment.

Step 5: Review and Remediate

Open the CSV in Excel or Sheets, cross-reference each row against your intended permission model, and action any gaps. Use the Permission Matrix Generator to document the intended model if you haven't already.

7 Permission Anti-Patterns to Avoid

• "Just give everyone Edit access" — A common result of copying a site template without resetting permissions: entire departments end up with Edit on finance or HR libraries. When something leaks, nobody knows who changed what because the permission scope is too broad to audit.

• Breaking inheritance on every folder — Creates an unmanageable permission tree; every broken scope is a maintenance burden and an audit gap

• Using "Full Control" as the default — Violates the principle of least privilege and creates unnecessary risk vectors; Site Owners should be 1–2 people, not a whole department

• Forgetting to remove ex-employees — Use automated lifecycle policies with Microsoft Entra ID so access is revoked the day someone offboards, not the day IT notices

• Sharing entire sites with external users — Share specific libraries or folders instead; use "Specific People" sharing links, not "Anyone"

• Not documenting permission decisions — You'll forget why you granted that one contractor Full Control on a critical library; document it in your permission matrix at the time of the decision

• Ignoring the "Access Requests" queue — Users find workarounds (like creating "Anyone" sharing links) if they can't get access through proper channels; check the queue weekly

Quick Reference: Permission Decision Tree

When deciding what permission level to assign, use this decision tree:

Does the user need to manage site settings or permissions?
  → Yes → Full Control (make them a Site Owner)
  → No ↓
Does the user need to edit pages or apply themes?
  → Yes → Design (superset of Edit; adds page editing and theme/style application)
  → No ↓
Does the user need to create/manage lists, or add, edit, and delete any items?
  → Yes → Edit (make them a Site Member)
  → No ↓
Does the user only need to add and edit content in existing lists?
  → Yes → Contribute (configure item-level permissions if delete restriction is needed)
  → No ↓
Does the user need to download documents?
  → Yes → Read (make them a Site Visitor)
  → No → View Only

FAQ: SharePoint Permissions Matrix

Q: What is the difference between SharePoint permission levels and permission groups?

Permission levels define what actions a user can perform (Full Control, Edit, Read, etc.). Permission groups (Site Owners, Site Members, Site Visitors) are containers that hold users and are assigned a permission level. You assign users to groups; you assign groups to resources at the site, library, list, or item level.

Q: Should I use SharePoint groups or Microsoft Entra ID groups?

Use Entra ID security groups for any access pattern that spans multiple sites or the entire tenant — and for dynamic membership (auto-updates when someone joins or leaves a team). Use SharePoint groups for site-specific roles. Never add individual user accounts directly to a SharePoint permission level.

Q: Can Contribute users delete other people's items?

Yes — by default. The Contribute permission level includes DeleteListItems which applies to all items in a list, not just the user's own. To prevent Contribute users from deleting others' items, configure "Item-level Permissions" under List Settings → Advanced Settings, or create a custom "Contribute (No Delete)" permission level that omits DeleteListItems.

Q: How does Microsoft 365 Copilot use SharePoint permissions?

Copilot is permission-bound — it never surfaces content a user can't access. However, it actively searches and summarizes all content within a user's permission scope, which means overshared content becomes far more visible. Run a permission audit before rolling out Copilot. The M365 Copilot Governance Checklist covers the full pre-rollout checklist.

Q: What is the Sites.Selected permission in Microsoft Graph?

Sites.Selected is a Microsoft Graph API permission scope that lets an application access only specific SharePoint sites rather than all sites in the tenant. It is the least-privilege option for developer apps and is strongly preferred over Sites.ReadWrite.All for any production integration. See the Microsoft Graph permissions reference for configuration steps.

Q: How do I export a SharePoint permissions matrix to CSV?

Use PnP PowerShell with the Get-PnPList + Get-PnPProperty RoleAssignments pattern shown in Step 4 above, then import the CSV into the Permission Matrix Generator for a visual view and gap analysis.

Q: What is "broken inheritance" in SharePoint?

Broken inheritance means an item (library, folder, or document) no longer inherits permissions from its parent — it has its own unique permission scope. Every broken inheritance point creates management overhead, hides the permission picture from the site level, and slows SharePoint's permission check engine. Avoid it except for genuinely confidential content.

Tools for Permission Management

• Permission Matrix Generator — Use this first: visualize and export your permission structure as CSV or Markdown to confirm your current state matches your intended model before running any bulk changes

• PnP Script Generator — Use when you need a one-off PnP PowerShell script tailored to your site URL and permission requirements, without writing it by hand

• PnP PowerShell — Use for scripted audits and bulk permission changes at scale; the examples in this post are all PnP-based

• SharePoint Admin Center — Use for tenant-level sharing policies (Anyone links, guest expiration defaults) and site-level access reviews that don't need scripting

• Microsoft Purview — Use when permissions alone aren't enough: sensitivity labels, DLP policies, and compliance reporting enforce protection even if a file is accidentally shared

What's Next

• SharePoint AI Copilot Governance Checklist (2026) — Full governance checklist once permissions are locked

• Enterprise Governance: SharePoint AI Developer Checklist — Broader M365 governance for developers

• PnP PowerShell: SharePoint Online Scripts & Admin Guide (2026) — Full PnP PowerShell reference

Good permission hygiene isn't a one-time project — it's an ongoing practice. With the corrected permissions matrix above, the right group structure in place, and quarterly PnP PowerShell audits, it becomes routine rather than reactive.

---

Test Your Expertise

Think you've mastered SharePoint permissions and the broader Microsoft 365 ecosystem? Take the M365 Challenge Mode | Developer Quiz to test your knowledge against increasingly difficult enterprise scenarios.