Before You Turn On Microsoft Copilot: 10 Things to Check First
Turning Copilot on is easy. Turning it on in an environment that is ready for it is the harder part. Copilot works by querying the data your users have access to. That means your permissions, governance and security posture directly determine what Copilot can surface. Check these 10 things before you deploy.
Microsoft's own SharePoint documentation now explicitly identifies overshared content, ownerless sites and poor permissions hygiene as the primary pre-deployment risk for Copilot and its agent capabilities. This is not a fringe concern — Microsoft is saying it clearly in its deployment guidance.
The 10 pre-deployment checks
- 1
Review SharePoint permissions across your most sensitive sites
SharePoint permissions accumulate over years without review. Finance documents, HR records, board papers and client files often end up accessible to far more people than intended. Copilot will surface these when users search for related content. Run a permissions report and understand what each site allows.
- 2
Identify and clean up 'Everyone' and 'Everyone except external users' sharing
'Everyone' group sharing means any authenticated user in your tenant can access that content — including new starters on day one. Search your tenant for sites and documents shared with these groups. They are common and often unintentional.
- 3
Audit anonymous sharing links
Anonymous sharing links give access to a document without any authentication. They are intended for short-term external collaboration but frequently remain active indefinitely. Review SharePoint sharing reports and expire or revoke links that have no current purpose.
- 4
Identify ownerless and inactive SharePoint sites
Sites without active owners are a governance gap: nobody is accountable for the content, nobody reviews permissions, and nobody knows what should be there. Copilot agents in particular traverse ownerless sites. Assign ownership or archive sites that are no longer active.
- 5
Apply sensitivity labels to documents containing sensitive information
Sensitivity labels from Microsoft Purview allow you to classify documents (Confidential, Internal, etc.) and apply policies to them. Labelled content can be excluded from certain Copilot queries or handled with additional controls. Without labels, Copilot treats all accessible documents equally.
- 6
Review external guest access in Teams and SharePoint
Every external user invited to a Teams channel or SharePoint site still exists as a guest in your Entra ID unless explicitly removed. Review your guest list. Remove guests who no longer need access. Understand what each remaining guest can currently see.
- 7
Confirm MFA and Conditional Access are configured
Copilot access via compromised credentials is a real risk. Before deploying Copilot, confirm that MFA is enforced for all users and that Conditional Access policies prevent access from unmanaged or non-compliant devices. A compromised account with Copilot access is significantly more damaging than one without.
- 8
Understand who Copilot will be licenced for and what they have access to
Do not enable Copilot for every user at once. Start with the roles where the return is clearest. For each user in the pilot group, understand what data they have access to and whether that access is appropriately scoped before they start using Copilot to query it.
- 9
Identify where sensitive information lives in your email and documents
Payroll data, client financials, legal correspondence, HR records: where do these live, who has access, and what would happen if Copilot surfaced them in response to a broad query from someone who is technically permitted to see them but practically never would? Map your sensitive content before deployment.
- 10
Document your intended Copilot use cases before deployment
Copilot without defined use cases tends to be underused and poorly evaluated. Before deploying, agree with your team on two or three specific workflows where you expect Copilot to add value. Measure those. It is a better approach than a broad rollout with no success criteria.
What happens if you skip this
The most common outcome of deploying Copilot into an ungoverned environment is that it surfaces information that surprises users — not because anything was stolen or breached, but because Copilot makes it easy to find things that were technically accessible but practically obscure.
A well-documented example: a staff member asks Copilot to find all documents related to a project they are working on, and Copilot returns board minutes, salary information, or acquisition planning documents that were never properly restricted. This is not a Copilot bug. It is the environment working exactly as configured.
The fix is not to turn off Copilot. The fix is to ensure permissions reflect intent before deployment.
Copilot does not create your permission problem. It reveals it. An environment where permissions have never been reviewed is an environment where Copilot will reliably surprise you.
Next step
Copilot Readiness Assessment
The Copilot Readiness Assessment works through all ten of these checks in your Microsoft 365 environment. You get a documented view of your current data governance, a prioritised remediation plan, and a deployment sequence that ensures Copilot is introduced into an environment that is ready for it.
Learn more