SharePoint Permission Matrix Generator

What is a SharePoint Permission Matrix?

A SharePoint Permission Matrix is a structured document that maps out which users and groups have what level of access across your SharePoint sites, libraries, lists, and folders. It provides a clear, at-a-glance view of your security posture — making it essential for audits, compliance, and IT governance.

When You Need a Permission Matrix

• Security Audits — document who can access what before an audit or compliance review (ISO 27001, SOC 2, GDPR).
• Site Provisioning — plan the permission structure before creating new sites, so you start with the right security model.
• Employee Onboarding/Offboarding — quickly see which groups a new hire should be added to, or verify access is revoked when someone leaves.
• Broken Inheritance Reviews — identify where unique permissions have been applied and whether they follow your governance policies.
• External Sharing Reviews — track which resources are accessible to external users, guests, or partner organizations.

SharePoint Permission Levels Explained

• Full Control — complete administrative access including managing permissions and site settings.
• Design — can create lists/libraries and edit pages in the site.
• Edit — can add, edit, and delete list items and documents.
• Contribute — can add, edit, and delete their own items.
• Read — can view pages, list items, and download documents.
• View Only — can view pages and items but cannot download.
• Limited Access — not a level you assign. SharePoint grants it automatically so someone with rights to one document can traverse the site and library containing it. It appears in permission reports and confuses audits; seeing it on a site usually means a single item below was shared directly.

Inheritance is the model that actually matters

Permissions flow downward: site collection to site to list or library to folder to item. Every object inherits from its parent until someone breaks inheritance, at which point that object carries its ownunique permission scope and stops tracking changes made above it. That is the single most important fact for an audit, because a matrix built only from site-level groups will miss every place inheritance was broken.

Broken inheritance also has a hard technical ceiling. A list or library supports roughly5,000 unique permission scopes, and past that point permission operations begin to fail. Per-item sharing is the usual way a library gets there: a few hundred documents shared individually with different people will quietly build thousands of scopes. If a library is slow to open permissions or throwing errors on sharing, scope count is the first thing to check.

Groups: which kind, and why it matters

Three different things are all called groups in this stack, and mixing them up is the usual cause of an unmaintainable permission model:

• SharePoint groups — site-scoped containers (Owners, Members, Visitors by default, mapping to Full Control, Edit, and Read). They exist only within their site collection and cannot be used anywhere else.
• Entra ID (Azure AD) security groups — tenant-wide, manageable centrally, and usable for dynamic membership rules. These are what you want to hold actual people.
• Microsoft 365 groups— carry a mailbox, a Teams team, and a connected site. Membership of the connected site is governed by the group, so managing that site's permissions separately fights the platform.

The pattern that scales is Entra security groups nested inside SharePoint groups. Granting permissions to individual users is what makes offboarding a manual archaeology exercise; granting to a nested security group means removing someone from one place removes their access everywhere it was derived from.

Sharing links are permissions too

A modern SharePoint permission report that only enumerates groups and role assignments is incomplete.Sharing links— "Anyone with the link", "People in your organization", and "Specific people" — create their own access paths, and each one breaks inheritance on the item it targets. Anonymous links are the ones that matter most for compliance, because they grant access without any identity attached at all.

Site-level sharing settings can only be equal to or more restrictive than the tenant setting. Tightening the tenant does not retroactively revoke links that already exist, which is why an external-sharing review has to enumerate live links rather than read the current policy.

Gathering the real data

A matrix is only as good as its source. For anything beyond a single site, script the collection rather than clicking through the UI:

• PnP PowerShell — Get-PnPGroup and Get-PnPGroupMember for group membership, Get-PnPListItemPermission for item-level scopes, andGet-PnPList with HasUniqueRoleAssignments to find where inheritance is broken.
• Microsoft Graph — /sites/{site-id}/permissions and the drive item/permissions endpoint, which is where sharing links surface as first-class objects.
• SharePoint admin center and Purview — tenant-wide sharing reports, useful for finding the sites worth auditing in detail rather than for the detail itself.

Whatever the source, capture the date. A permission matrix is a point-in-time snapshot, and its value in an audit depends entirely on being able to say when it was taken and what changed since.