Microsoft 365 Copilot Security Review: What to Check Before You Switch It On

Most organisations approach Microsoft 365 Copilot as a licensing decision. It is better treated as a data access decision. Copilot does not invent new permissions: Microsoft states that it only surfaces organisational content that the signed-in user already has at least view access to. The problem is that very few tenants have permissions anyone would defend in front of an auditor. Years of "share with everyone in the organisation" links, inherited site permissions and abandoned Teams sites were tolerable when finding a file required knowing it existed. Copilot removes that friction. A well-phrased question can now pull salary bands, board papers or disciplinary notes into a chat answer for anyone whose access was never cleaned up.

This guide sets out what a practical Copilot security review should cover before you widen a pilot. It is written for IT leads, data protection officers and security managers in UK organisations who need to show that the rollout was considered, not just enabled.

Why Copilot changes your risk without changing your permissions

Copilot grounds its answers in Microsoft Graph: mail, chats, meetings, OneDrive and SharePoint content that the user can reach. Security trimming still applies, so a user cannot retrieve a document they cannot open. What changes is discoverability and aggregation. Information that was technically accessible but practically hidden becomes one question away, and Copilot can combine fragments from several sources into a single summary that is more sensitive than any one of them.

That gives you three distinct risk categories to assess:

• Oversharing: content that is accessible to far more people than need it, which Copilot now makes easy to find.
• Manipulation: content that tries to steer Copilot's behaviour, for example hidden instructions in an inbound email or a shared document (indirect prompt injection, the top entry in the OWASP Top 10 for LLM Applications).
• Accountability: whether you can show who asked what, what was returned, and whether sensitive data left the boundaries you set.

Step 1: Find the oversharing before your users do

Start with the data, not the AI. The goal is a defensible map of where sensitive content lives and who can reach it.

• Organisation-wide sharing links. Report on files and folders shared via "people in your organisation" links, and on sites where the "Everyone except external users" group has been granted access. These are the most common source of Copilot surprises.
• Broken inheritance and orphaned sites. Teams and SharePoint sites whose owners have left, or whose permissions were broken years ago, rarely appear on anyone's risk register.
• High-value repositories. HR, finance, legal, board and M&A areas should be checked by name. Confirm membership, not just the presence of a security group.
• OneDrive sharing. Individual OneDrive accounts often contain exported reports and spreadsheets that duplicate restricted data.

Microsoft provides tooling to help here, including SharePoint Advanced Management reports and options to restrict which sites Copilot can draw on while you remediate. Use those controls as a temporary fence, not a substitute for fixing permissions. Restricting discovery hides the symptom; the underlying access still exists for search, sync and any other tool that uses the same permissions.

Step 2: Make sensitivity labels do real work

Many tenants have Microsoft Purview sensitivity labels configured but barely applied. For Copilot, labels matter because they travel with the content and can carry encryption and usage rights. Copilot respects those rights: if a label's encryption does not grant a user the right to extract content, Copilot cannot use it for that user.

A review should confirm:

• That a small, understandable label taxonomy exists (for example Public, Internal, Confidential, Highly Confidential).
• That default labelling is set for high-risk libraries, so new content is protected without relying on users.
• That Purview data loss prevention policies are configured for the Copilot location where your licensing supports it, so that highly sensitive labelled content is excluded from Copilot processing.
• That auto-labelling or classification has been tested against your real data types, such as National Insurance numbers, bank details and health information.

Step 3: Treat inbound content as untrusted input

Copilot reads emails, meeting transcripts and documents that may have been written by people outside your organisation. If that content contains instructions, a model may follow them. The NCSC has warned that, because current models do not separate instructions from data, prompt injection may never be fully mitigated in the way SQL injection can be, which is why controls must sit around the model, not only inside it.

For Microsoft 365 that means checking:

• Which Copilot agents and connectors are enabled, and whether any can take actions (send mail, create items, call external APIs) rather than just read.
• Who can build and publish agents in Copilot Studio, and whether those agents run with the maker's credentials or the user's.
• Whether external content sources, plugins and web grounding are enabled, and whether that is a deliberate decision.

Where you are building agents that act on business systems, a structured test is worth the effort. Our article on what an LLM and agent red team actually tests explains how indirect injection and tool misuse are assessed in practice.

Step 4: Decide what you will log, and who will look at it

Copilot interactions can be captured in Microsoft Purview Audit, and Purview offers AI-focused posture reporting. Logging is only useful if someone owns it. A review should agree:

• Which events are retained, for how long, and where (Purview, Microsoft Sentinel or another SIEM).
• Which patterns warrant investigation, such as repeated queries for restricted terms or sudden use by dormant accounts.
• How Copilot use is covered in your data protection documentation, including your records of processing and, where the processing is likely to result in high risk, a data protection impact assessment as the ICO expects.

If you already forward Microsoft 365 logs into a SIEM, our guide to controlling Microsoft Sentinel ingestion costs covers how to keep high-value audit data without paying to index noise.

Step 5: Put policy and people around the technology

Technical controls fail quietly when users do not understand them. Before broad rollout, publish a short acceptable use statement covering what may be pasted into Copilot, how outputs should be checked before they are relied on, and how to report a worrying answer. Pair it with your approach to other AI tools, because staff who cannot use an approved tool for a task tend to reach for an unapproved one. Our article on finding and governing shadow AI covers that side of the problem.

If you are working towards ISO/IEC 42001, Copilot is a good first system to bring into your AI management system scope. The impact assessment, roles and monitoring you define here are directly reusable. See our ISO 42001 readiness guide for how that fits together.

What a good review produces

A Copilot security review should not end with a slide that says "medium risk". It should leave you with:

• A list of overshared locations, ranked by sensitivity, with named owners and remediation actions.
• A labelling and DLP configuration you have actually tested with Copilot.
• A record of which agents, connectors and plugins are enabled and why.
• Logging and monitoring decisions written down, with an owner.
• A rollout plan that widens access in stages as each group's data is cleaned up.

That evidence also helps with customer due diligence. Enterprise buyers increasingly ask suppliers how they govern AI use, and "we reviewed permissions before enabling Copilot, here is the record" is a far stronger answer than a policy document alone. Where you need that evidence to stay current, PyraLink Prove can collect Microsoft 365 configuration evidence through read-only access so the picture does not go stale after the review.

How Pyralink helps

PyraLink™ Prove keeps read-only evidence of the Microsoft 365 and cloud configuration your AI rollout depends on.

Frequently asked questions

Does Microsoft 365 Copilot give users access to files they could not open before?

No. Microsoft states that Copilot only uses content the signed-in user already has permission to view. The risk is that existing permissions are often far broader than intended, and Copilot makes that content much easier to find and summarise.

What is the biggest security risk when rolling out Copilot?

For most organisations it is oversharing: SharePoint sites, Teams and OneDrive files shared with the whole organisation or with groups that are larger than necessary. Fixing permissions and applying sensitivity labels addresses most of it.

Can sensitivity labels stop Copilot using a document?

Labels that apply encryption and usage rights are respected by Copilot. If a user does not have the right to extract content under the label, Copilot cannot use that content for them. Purview DLP can also be configured to exclude highly sensitive labelled content from Copilot where licensing supports it.

Do we need a DPIA for Microsoft 365 Copilot?

The ICO expects a data protection impact assessment where processing is likely to result in a high risk to individuals. Many organisations conclude that a Copilot rollout touching HR, customer or health data meets that threshold. Take advice specific to your use.

How long does a Copilot security review take?

It depends on the scope you agree internally. Remediation time depends on how much oversharing is found and how many sites need to be cleaned up.

Sources: Microsoft Learn: Data, privacy and security for Microsoft 365 Copilot; OWASP GenAI Security Project: LLM01 Prompt Injection; NCSC blog: Prompt injection is not SQL injection (it may be worse); NCSC: AI and cyber security, what you need to know; ICO: Data protection impact assessments; DSIT: AI Cyber Security Code of Practice.