Microsoft 365 Copilot can be turned on in a few minutes: you buy licences, assign them to users, and a new button appears in Word, Outlook and Teams. That is exactly why it is risky. The technical part is the easiest, while everything that decides whether Copilot is useful or causes problems has to be done before it.
The most common scenario we see: a company enables Copilot for a few executives, one of them asks it to “summarise what we know about employee salaries,” and gets a detailed answer drawn from an Excel file that an HR manager uploaded three years ago to a shared SharePoint library open to the whole company. Copilot broke nothing. The file was accessible. Nobody just knew where to look before.
In this article we describe what to prepare before turning it on: access cleanup, data labelling, a pilot group and the scenarios you will use to measure value. It is not a long project, but it cannot be skipped.
Copilot sees what the user sees
The core principle to understand: Copilot has no access to data of its own. It acts on behalf of the user and uses Microsoft Graph to find the emails, files, chats and meetings that the user has permissions for. If an employee can open a file, Copilot can cite it. If they cannot, Copilot does not see it.
Two conclusions follow. First, Copilot does not create new security holes, it only exposes existing ones. Second, permission sprawl that lived unnoticed for years because nobody knew where to look becomes visible with a single question once Copilot is on. A search that used to be awkward is now a conversation in natural language.
So the first job is not Copilot, it is an access audit: who has access to what, and whether they should.
Access cleanup in SharePoint and OneDrive
In our experience, access problems in SharePoint build up over the years from a few sources: sites created “temporarily” with access for everyone; Teams teams whose membership was not updated when people changed roles; files shared with an “everyone in the organisation” link; OneDrive folders that a departing employee handed to a colleague together with everything in them.
What to check before enabling Copilot:
- SharePoint sites that the “Everyone” or “Everyone except external users” group can access. These are the first candidates for review.
- Files and folders shared at the organisation level through links. The SharePoint admin centre and Microsoft Purview have reports that show this.
- Owners of Teams teams and sites. Every site needs an active owner who is responsible for its members.
- Old sites with no activity for a year. It is better to archive them than to leave them.
- OneDrive folders with external sharing.
SharePoint Advanced Management and Microsoft Purview include tools that let you temporarily limit Copilot search to specific sites (Restricted SharePoint Search) while access is being fixed. It is a practical interim step if you want to start a pilot without spending months on an audit.
Sensitivity labels and data classification
Sensitivity labels in Microsoft Purview are the second layer after access. They mark documents and emails by sensitivity (public, internal, confidential, highly confidential) and can encrypt content and limit who sees it. Copilot respects labels: if a document is labelled so that the user cannot read it, Copilot will not use it in an answer, and if it does use labelled content, the answer inherits the highest label.
You do not need to label every file before Copilot. It is enough to define 3 to 4 labels the company understands; set a default label for new documents; automatically label documents in which national ID numbers, financial data or contract templates are detected; and manually label known sensitive libraries such as HR, finance and management.
This work is useful even without Copilot, and you will need it later if NIS2 or DORA applies to your company. Copilot just gives you the occasion to finally do it.
A pilot group, not the whole company at once
Copilot licences are assigned per user, so it is natural to start with a group. We recommend 10 to 20 people from different departments who:
- Work a lot with documents, email and meetings, so they will benefit most.
- Want to try it and are ready to share observations, not just complain.
- Represent different kinds of work: sales, finance, project management, leadership, administration.
One person in the group should be from IT or security, to test the access questions specifically: what Copilot finds that it should not. The pilot lasts 6 to 8 weeks. During that time the group meets for 30 minutes every two weeks to share what worked, what did not and which prompts they have learned.
Usage scenarios, not “just try it”
The biggest pilot mistake is handing out licences and saying “go ahead and use it.” Employees try it a couple of times, do not get an impressive result and go back to their usual work. Copilot needs concrete scenarios that match real work.
Examples that deliver results quickly in our experience:
- A Teams meeting summary with an action list, sent to attendees within five minutes of the meeting ending.
- Outlook: a summary of a long email thread and a draft reply when someone returns from holiday.
- Word: a proposal draft based on earlier proposals for the same customer segment.
- Excel: an explanation of a data table and formula suggestions for someone who is not an Excel expert.
- Copilot Chat: “what did my team decide about project X in the last two weeks,” answered from emails, chats and documents.
Assign each pilot member 2 to 3 scenarios based on their job. That gives you something to measure.
How to measure value
A Copilot licence is not cheap, so the decision to expand should rest on data, not impressions. The Microsoft 365 admin centre has a Copilot usage report: how many users are active, in which apps, how often. That is the first indicator. If half the pilot group is not using it after a month, the problem is in the scenarios or the training, not the tool.
The second indicator is the users’ own assessment by scenario. A simple form at the end of the pilot: which scenarios saved time, roughly how much per week, and which did not work and why. The third is the conclusion of the security lead on access questions. If during the pilot Copilot surfaced content the user should not have seen, that gets fixed before the rollout, not after.
Based on the results, departments where the benefit is clear get licences in a second wave. Departments where the benefit is unclear wait.
Copilot Studio agents: the next step
Once Copilot is working and access is clean, the next level is agents you build in Copilot Studio. These are no longer a general assistant but a solution tailored to a specific task: an agent that answers employee questions about internal policies from HR documents; an agent that logs helpdesk requests and checks their status; an agent that turns a customer email into an order in a business system through Power Automate.
Agents use the same access and labelling model, so everything you fixed while preparing for Copilot applies to them directly. We write more about how agents work and who they suit on the Microsoft 365 Copilot agents page.
Where to start
Preparing Copilot for a company of up to 200 employees takes anywhere from a few weeks to a couple of months in our experience, depending on the state of SharePoint.
- Review SharePoint and OneDrive access: sites open to everyone, organisation-level links, sites without owners.
- Define 3 to 4 sensitivity labels and label the known sensitive libraries. Turn on automatic labelling for personal and financial data.
- Put together a pilot group of 10 to 20 people and assign each 2 to 3 usage scenarios.
- Set the success metrics before the pilot, not after.
- After 6 to 8 weeks, make the expansion decision based on data.
If you want us to run the preparation and the pilot, our Microsoft 365 Copilot implementation service includes the access audit, label setup, pilot group training and measurement. And if access hygiene is a bigger problem than Copilot itself, we start by fixing Microsoft 365 security and only then move on.
