SharePoint Permissions Audit: How to Find Out Who Has Access

SharePoint makes it easy to share files, sites, and libraries -- sometimes too easy. Over time, permissions accumulate. Former employees retain access, shared links sit active long after a project ends, and individual file permissions override the clean group structure that was set up at launch. A permissions audit is the process of reviewing who has access to what and cleaning up anything that should not be there. For small businesses without a dedicated security team, regular audits are one of the simplest ways to reduce risk and stay on top of compliance obligations.

Why Permissions Audits Matter

Three problems show up repeatedly in organizations that skip permissions audits.

Former employees still have access. When someone leaves the company, their Microsoft 365 account may be disabled, but direct sharing links, guest accounts, and permissions granted to personal email addresses can survive long after offboarding. A permissions audit catches these orphaned access entries.

Compliance requirements demand proof of access control. Regulations like GDPR, CCPA, and industry-specific frameworks require organizations to demonstrate that personal data is accessible only to authorized personnel. When a data subject request arrives, knowing exactly who had access to what -- and when -- is essential. For more on the boundaries of these requests, see this guide on DSAR exemptions.

Over-sharing creates invisible risk. A site that was shared with "Everyone except external users" during a company-wide announcement may still carry that permission months later. Sensitive HR documents, financial reports, or client data can end up visible to the entire organization without anyone noticing -- until something goes wrong.

Auditing with Built-In SharePoint Admin Tools

SharePoint provides several native tools for reviewing permissions. None of them give a single, comprehensive view, but together they cover the essentials.

Site Permissions Page

Every SharePoint site has a permissions page accessible through Site Settings > Site Permissions (classic experience) or Settings > Site permissions (modern experience). This page shows the groups and individuals who have access to the site, along with their permission levels. It is the first place to check during an audit. Look for individual users who were added outside of groups, unexpected guest accounts, and permission levels that seem too broad for the user's role.

Sharing Reports in the SharePoint Admin Center

The SharePoint admin center provides sharing activity reports that show which files and sites have been shared externally. Administrators can filter by site, date range, and sharing type. These reports are useful for identifying external sharing links that are still active and determining whether external access is still justified.

Microsoft 365 Access Reviews

Organizations with Azure AD Premium P2 licenses (included in Microsoft 365 E5) can use access reviews to automate periodic checks. Access reviews prompt group owners or managers to confirm whether each member still needs access. Members who are not confirmed are removed automatically. This feature is powerful but requires licensing that many small businesses do not have.

Site Collection Administrators List

Each site collection has its own list of administrators with Full Control. This list is separate from the site's Owners group and is easy to overlook. Check it by navigating to the SharePoint admin center, selecting the site, and reviewing the administrators listed. Remove anyone who no longer needs that level of access.

Auditing with PowerShell

The built-in admin interface works for spot checks, but auditing permissions across dozens of sites by hand is slow. PowerShell scripts using the PnP PowerShell module can pull permissions data from every site, library, and folder in a tenant and export the results to a CSV file for review.

A typical audit script connects to each site collection, retrieves the role assignments for the site and its lists, identifies any items with broken inheritance (unique permissions), and logs the results. The output usually includes the site URL, the user or group name, the permission level, and whether the permission was inherited or set directly.

Key commands to know include Get-PnPSiteCollectionAdmin for retrieving site collection administrators, Get-PnPGroup for listing SharePoint groups and their members, and Get-PnPListItem combined with Get-PnPProperty for checking item-level permissions. These commands can be combined into a script that runs on a schedule and emails the results to an administrator.

PowerShell audits are thorough, but they require someone comfortable writing and maintaining scripts. For businesses without that skill set, third-party tools are a more practical option.

Third-Party Permissions Reporting Tools

Several third-party tools specialize in SharePoint permissions reporting. They generally offer advantages over the native tools in three areas.

Consolidated views. Instead of checking permissions site by site, third-party tools aggregate data across the entire tenant into a single dashboard. Administrators can see every site, library, folder, and file where a specific user has access -- all in one place.

Historical tracking. Native SharePoint tools show the current state of permissions but not how they changed over time. Third-party tools often log permission changes so that administrators can answer questions like "When did this person get access?" and "Who granted it?"

Automated alerts. Some tools monitor for specific events -- a new external sharing link, a change to a site's permission level, or a user added to an admin group -- and send alerts in real time. This shifts the audit model from periodic review to continuous monitoring.

Popular tools in this space include ShareGate, Avepoint, Netwrix, and CoreView. Each offers a different balance of depth, usability, and price. For small businesses, the main decision point is whether the cost of a third-party tool is justified by the time saved and the risk reduced compared to manual or PowerShell-based audits.

Common Findings in Permissions Audits

Certain issues appear in nearly every permissions audit, regardless of organization size.

Over-shared sites. Sites created for a specific project or department that were shared with broad groups -- sometimes the entire organization -- and never locked down afterward. The content may have been harmless at creation, but the site is now used for sensitive documents that the original audience should not see.

Stale external sharing links. Links generated for vendors, clients, or contractors during active engagements that remain accessible months or years later. Anonymous links (links that do not require sign-in) are especially risky because there is no way to know who has used them.

Broken inheritance. Individual files or folders with unique permissions that override the parent library's settings. These are difficult to track because they do not appear in the site's top-level permissions view. They often result from one-off sharing actions -- someone right-clicked a file and shared it directly rather than using the library's group permissions.

Excessive site collection administrators. Multiple people with Full Control at the site collection level, often because admin access was granted for a one-time task and never revoked. Every site collection administrator has the ability to change permissions for every user on that site, so this list should be as short as possible.

Guest accounts with no expiration. External users invited as guests who retain access indefinitely because no expiration policy was configured. Azure AD supports guest expiration policies, but they must be enabled and configured manually.

Quarterly Audit Checklist

For most small businesses, a quarterly permissions audit strikes the right balance between thoroughness and practicality. The following checklist covers the essential steps.

• Review site collection administrators. Confirm that every person on the list still needs Full Control. Remove anyone who does not.
• Check SharePoint group membership. Open each site's Owners, Members, and Visitors groups. Remove former employees, former contractors, and anyone whose role no longer requires access.
• Identify external sharing links. Use the admin center's sharing reports or a PowerShell script to list all active external links. Revoke any that are no longer needed.
• Scan for broken inheritance. Run a PowerShell script or third-party tool to find items with unique permissions. Evaluate whether each exception is still justified and remove those that are not.
• Verify guest account status. Review the list of guest users in Azure AD. Disable or remove accounts for external collaborators whose engagements have ended.
• Check sensitivity label assignments. Confirm that sites and libraries containing sensitive data have the correct sensitivity labels applied and that the labels enforce the intended access restrictions.
• Document findings and actions. Record what was found, what was changed, and who approved the changes. This documentation is essential for demonstrating compliance during audits or regulatory inquiries.

Running this checklist every quarter -- and after any significant organizational change such as a layoff, reorganization, or vendor transition -- keeps SharePoint permissions aligned with actual business needs. The goal is not perfection but steady improvement: each audit should find fewer issues than the last.