How to Audit SharePoint Permissions Before Enabling Copilot

Key Takeaways

• A SharePoint permissions audit should answer two questions: who can access what, and is that access appropriate.
• Use Microsoft’s latest admin tools (including SharePoint Advanced Management) to find public sites, broken inheritance, risky links and ownerless sites at scale.
• Treat external users, “Everyone” groups, and anonymous links as high risk patterns to fix before Copilot is enabled.
• Start Copilot with a limited, low risk pilot scope, then expand once you’ve fixed the biggest oversharing issues.

Before turning on Microsoft 365 Copilot you need to know exactly who can see what in SharePoint, and fix any oversharing. Or, Copilot will simply magnify those issues. In our opinion at Silicon Reef, a focused permissions audit, done once and then embedded into governance, makes the difference between a smooth Copilot launch and a series of “Why did Copilot show me that?” moments.

Jump to:

• What a Copilot-Ready Audit Needs to Achieve
• Use Admin Reports to See “Who Can See What”
• Sweep for High Risk Sharing Patterns
• Work Through a Permissions Audit Checklist
• Use SharePoint Advanced Management to Scale the Audit
• Look Beyond SharePoint
• Document Findings and Prioritise Remediation
• Pilot Copilot with a Limited Scope
• How Silicon Reef Runs Permissions Audits

What a Copilot-Ready Audit Needs to Achieve

A Copilot-ready permissions audit is a structured check of your current security model against how Copilot will work day to day. It aims to reduce surprises by ensuring that Copilot’s scope mirrors a sensible, least privilege access model, not years of ad hoc sharing.

In our view, a good audit does three things:

• Gives a clear picture of access from the user’s perspective (“what can this person actually see?”).
• Identifies and ranks oversharing patterns – open sites, broad groups, risky links, stale access and external guests.
• Produces a concrete remediation backlog you can action before and during Copilot rollout.

This shouldn’t be a one off exercise. The most successful organisations build these checks into ongoing governance so Copilot remains safe as roles and content change.

Use Admin Reports to See “Who Can See What”

Microsoft has recently made it easier to see permissions from the user angle, which is critical for Copilot. The “Site permissions for users” report in the SharePoint admin centre lets you pick a user and see every site they can access, including whether that access is direct, via a group, or limited to specific libraries or items.

We recommend:

• Select a representative set of users: Copilot pilot group, senior leaders, HR, finance, and a few “power users”.
• Review their access footprint: are they seeing sites they no longer work with, or sensitive areas (HR, board, legal) that look out of place for their role.

For Copilot readiness, this report is invaluable because it tells you, in plain language, what Copilot could draw on for each user. Removing unnecessary access at this stage is far easier than dealing with incidents later.

Sweep For High Risk Sharing Patterns

Beyond individual users, you need a tenant wide view of known oversharing patterns. Common red flags we see include:

Public or broadly shared sites

Administrators should review sites set to “Anyone in the organisation” or those granting access to “Everyone” or large security groups. Use Permission State and Permissions reports in SharePoint Advanced Management to identify sites where “Everyone” has access or where many unique permissions exist.

Orphaned or ownerless sites

Use the Content Management Assessment in SharePoint Advanced Management to identify sites with no active owners or recent activity. This assessment highlights inactive or ownerless sites that often escape routine checks.

Risky sharing link settings

Review tenant settings that allow “Anyone” links without expiry or enable frequent use of “Anyone in the organisation” links for sensitive content. Use reports of existing anonymous and organisation-wide links to convert them to “specific people” links or remove them entirely.

External users and guest access

Review guest accounts to find users with broader access than required. Use third-party governance tools or Microsoft Entra ID views to list what guests can access across SharePoint and remove stale or over-privileged accounts.

This sweep usually reveals more oversharing than people expect. In our audits, it’s common to find legacy projects, migrated file shares and test sites still wide open years later.

Work Through a Permissions Audit Checklist

To make the audit systematic rather than ad hoc, it helps to follow a simple checklist. Adapted from Copilot readiness guidance and our own practice, key items include:

Public or ownerless Teams and sites

• List Teams and associated SharePoint sites that are public or have no clear owner; make them private where appropriate and assign accountable owners.

Broad access groups

• Identify where groups like “Everyone”, “All Staff”, or very large security groups are used directly on sites or libraries.
• Plan to replace them with role based groups (department, project, function) to reduce unintended exposure.

Sharing links and defaults

• Document your current default sharing policy and actual usage: how many “Anyone” links exist, how often are org wide links used.
• Move towards least privilege defaults, such as “Only people in this organisation” or “Specific people”, with expiry where external sharing is necessary.

Sensitivity labels and DLP

• Check whether sensitivity labels are consistently applied and whether Data Loss Prevention policies are in place for key data types (HR, finance, customer).
• Note coverage gaps; these become recommendations for your Copilot security baseline.

The outcome of this checklist is a prioritised set of fixes, aimed first at content that is both sensitive and overshared – the most dangerous combination when Copilot is in the picture.

Use SharePoint Advanced Management to Scale the Audit

If your licenses include SharePoint Advanced Management (SAM) – now bundled with Copilot licences – you can automate parts of this work. SAM is particularly useful where you have hundreds or thousands of sites and manual review is unrealistic.

Features we find most helpful:

Site Lifecycle Report

• Identifies inactive sites with no recent file activity, which are prime candidates to archive, lock to read only, or temporarily hide from search until cleaned up.

Oversharing Policy Report

• Highlights sites with too many unique permissions, shares to large groups, or extensive anonymous links.
• Deduplicates group membership to reveal the true number of people with access, which can be eye opening for large security groups.

Site Access Reviews

• Automates periodic reviews where site owners are asked to confirm that everyone with access still needs it.
• For Copilot readiness, we recommend running access reviews on highly sensitive sites before Copilot is widely enabled.

These tools spread the workload. \instead of central IT trying to fix everything, site owners become active participants in cleaning up access.

Look Beyond SharePoint

While SharePoint and Teams files are the main sources Copilot uses for documents, it also draws on OneDrive, Teams chat, email and other Microsoft 365 locations. A SharePoint permissions audit is therefore necessary but not sufficient.

Areas to check:

OneDrive sharing

• Are employees setting “Anyone” or org-wide links on personal files that then become de facto shared storage.
• Are there patterns of personal OneDrives being used as team file stores, which complicates governance.

Teams channel settings

• Public teams and channels tying into SharePoint sites that may be more open than intended.

Cross M365 risk insights

• Microsoft Purview’s Data Security Posture Management (DSPM) for AI can scan key SharePoint sites and flag unlabelled sensitive files, overexposed links, and unusual access patterns.

You don’t need to reach perfection across every workload before you start, but you should know where the main risks sit and plan to address them.

Document Findings and Prioritise Remediation

An effective audit ends with a clear remediation plan, not just a list of worries. We usually help clients structure this as a backlog that fits into regular change cycles.

Typical remediation items:

• Break inheritance from “Everyone” groups on specific sites and replace with more targeted access.
• Remove users or groups who no longer need access (for example, old project teams, leavers not fully cleaned up, or historic vendors).
• Tighten default sharing policy and remove high risk anonymous links or convert them to named user links.
• Apply or extend sensitivity labelling to key libraries and sites, focusing first on HR, finance, legal and board level content.

We recommend tagging each item with impact (high/medium/low) and effort, then addressing high impact, low effort changes first so you quickly reduce Copilot risk.

Pilot Copilot With a Limited Scope

Rather than moving straight from audit to full rollout, it’s safer to run a Copilot pilot with both limited users and limited content scope. Microsoft suggests an initial Copilot deployment where the AI has access to around 100 low risk sites, allowing you to validate that no unexpected content appears in responses.

A practical pattern:

• Choose a pilot group of employees from non sensitive areas (for example, internal comms, IT, project management) who are keen to test Copilot.
• Use restricted search or site selection to limit Copilot’s index to a curated set of sites you have already audited and cleaned.
• Monitor prompts and outputs during the pilot; if Copilot surfaces anything surprising, treat it as feedback for further permission tightening.

This phased approach – audit, remediate, pilot, then broader deploy – lets you build internal confidence and governance “muscle” without freezing innovation.

How Silicon Reef Runs Permissions Audits

In our projects, a Copilot-focused permissions audit follows a repeatable pattern, but is tailored to each organisation’s size, sector and risk profile. The work is often triggered by a wider SharePoint redesign or ISO / regulatory review, with Copilot readiness as a key outcome.

Common elements include:

• Discovery workshops to understand business structures, high-risk data areas and existing pain points (“I can see too much” vs “I cannot see what I need”).
• Technical assessment using the admin tools and reports described above to build a picture of current access.
• Findings and recommendations presented in plain language, often grouped into “must-do before Copilot”, “should-do-soon”, and “nice-to-have”.
• Support through change – helping clients implement new group models, refine site structures, and communicate changes to users so the audit actually results in safer, clearer access.

The organisations that benefit most are those that treat the audit as a foundation for ongoing governance, not just a pre-Copilot tick-box. They come out not only safer for AI, but with a SharePoint environment that’s easier to manage, easier to navigate, and better aligned to how their people really work.