How to Clean Up Your SharePoint Permissions Before Turning on Copilot

Microsoft Copilot does not bypass your security boundaries. It follows your existing permissions to the letter. If an employee asks Copilot for a summary of company salaries, project margins, or disciplinary policies, the system will only read files that the employee already has access to read.

That sounds reassuring until you realise how SharePoint actually operates inside most businesses with 20 to 200 staff.

Over five to ten years of standard day-to-day operations, files get shared through chat messages, subfolders get detached from parent permissions, and busy managers create company-wide links to avoid administrative bottlenecks. Your security model likely relies on obscurity. Staff do not read your executive compensation spreadsheets simply because they do not know the files exist, not because they lack technical permission to view them.

Copilot eliminates security by obscurity. It surfaces relevant information instantly across your entire estate. Before you assign your first batch of licences, you need to clean up your permissions structure. Here is how to approach that work methodically without bringing your business to a standstill.

Why Copilot Makes Hidden Permissions Obvious

In a standard SharePoint environment, finding an overshared file takes deliberate effort. A junior staff member would have to navigate through obscure directory paths or search for specific file names in the hope of finding something sensitive. Most people do not bother, and those who do rarely find much.

Copilot changes the search interface from exact-match keywords to intent-based natural language. When a user asks, "What are the biggest financial risks the company faces this quarter?" Copilot queries all indexed content the user has permission to view. If a draft board deck or an unredacted audit report was saved in a folder marked with default "Company-wide" read access, Copilot will pull quotes directly from it.

The issue is not an AI flaw. It is a historical governance flaw that has gone unnoticed because traditional search tools were too blunt to expose it. The problem typically stems from three common practices:

• "Everyone except external users" being set as the default member group for internal team sites.
• "People in your organization" sharing links being generated for quick collaboration and never revoked.
• Broken permission inheritance at the folder or document level, where sensitive documents sit inside otherwise unrestricted document libraries.

Fixing this does not require locking down every single document in your archive. It requires identifying high-risk assets and simplifying how access is granted.

Step 1: Run an Immediate Discovery Audit

Before you alter any settings, you need an objective picture of what is currently exposed. SMBs do not have the time or personnel to inspect every folder manually, so you must start with automated discovery.

Begin in the SharePoint Admin Center. Review your active sites list and sort them by sharing settings and privacy status. You are looking for two immediate red flags: public sites that should be private, and sites with high volumes of external sharing links.

Next, focus on sensitive domains. In an SMB, sensitive data typically lives across five distinct categories:

• Payroll, executive remuneration, and staff reviews.
• Management accounts, banking details, and forward tax projections.
• Director-level strategy notes, acquisition plans, or partner dispute records.
• Employee medical notes and personal identifying information (PII).
• Proprietary customer pricing agreements or contract negotiations.

Locate where these documents currently reside. If your payroll spreadsheet is sitting in a subfolder inside a general "Company Operations" site, no amount of folder-level tweaking will provide robust protection over time. Note these locations down; they are your primary targets for isolation.

Step 2: Fix Structural Flaws Instead of Document Exceptions

The most common mistake businesses make during remediation is attempting to fix permissions file by file. This approach fails because it creates a maintenance nightmare. If you break permission inheritance on a single folder inside an open site, the next administrator who touches that site will likely overwrite your settings by accident.

Instead, move high-risk data into structurally isolated containers:

• Consolidate sensitive workloads into dedicated, restricted sites. Create a single, private "HR Management" or "Leadership" site with membership strictly limited to individuals who require access.
• Migrate sensitive legacy folders completely out of shared operational areas. Do not leave a "Confidential" folder inside your general "Finance" team site if that team site includes junior accounts staff who should not see management accounts.
• Reset broken inheritance across broad libraries. Re-establish clean inheritance from the site root downward so that documents automatically inherit the permissions of the site they live in.

If a file is truly sensitive, it belongs in a dedicated site with restricted membership, not tucked away in a subfolder with custom permissions.

Step 3: Compare Your Remediation Options

SMB leaders usually have three paths for cleaning up their data estate prior to a Copilot launch. The right option depends on your internal technical capacity and the age of your Microsoft 365 environment.

• Option 1: Manual internal cleanup. Your internal IT lead or office manager reviews sites, adjusts sharing links, and relocates sensitive folders. This option costs nothing in external fees, but it is slow and prone to human error. It only works well for small businesses under 30 staff with relatively fresh, uncomplicated data structures.
• Option 2: Automated third-party tooling. You deploy specialized software (such as AvePoint or ShareGate) to scan your tenant, identify overshared links, and batch-revoke broad permissions. This approach gives you clear reporting and saves significant administrative time, though it requires an upfront software licence and someone who understands how to configure the policies.
• Option 3: An external data readiness engagement. You bring in a specialist consultancy to run a comprehensive tenant assessment, deliver a remediation blueprint, and execute the structural shifts for you. This path carries a services cost, but it removes the burden from your internal team, ensures compliance with security standards, and reduces deployment delays.

For firms with 50 to 250 staff, relying entirely on manual internal reviews is rarely successful. The sheer volume of historic links created over years makes an assisted or automated approach far more dependable.

What to Do Before Issuing Licences

Once permissions are restructured, you need to validate your work before rolling out licences across the business.

Create a small pilot group of three to five users from different departments, including junior or administrative roles. Assign them Copilot licences first. Run deliberate prompt tests using realistic queries: ask about executive pay, redundancy plans, or commercial margins. If Copilot returns answers sourced from sensitive documents, check the citation link provided in the response to immediately identify which site or file still has overly permissive access.

Do not treat SharePoint permissions as a one-off project that ends when Copilot launches. Set a quarterly review cycle to audit new sharing links and site creations.

If you are currently evaluating Microsoft Copilot, pause licensing discussions until you have assessed your data readiness. Schedule a SharePoint permissions audit this week, identify where your high-risk files live, and resolve access gaps before you hand staff the keys to an AI assistant.