Microsoft 365 Copilot Data Security: A UK Business Guide to Controlling What Copilot Can See in 2026

Copilot data security is not a Copilot problem. It is a permissions problem that Copilot makes impossible to ignore. Microsoft 365 Copilot has no private index, no separate corpus and no special access rights — it reads the same Microsoft Graph the signed-in user can already read, and it returns what that user was always entitled to see. The uncomfortable part is that most UK organisations have never actually tested what their staff are entitled to see, because for fifteen years the only way to find out was to know a file existed, know roughly where it lived, and go looking for it. Copilot removes all three of those requirements. A finance assistant who types “what is the current senior leadership salary banding?” is not hacking anything. They are asking a question, and the answer arrives because a spreadsheet was shared to a Teams site that inherited a permission from a 2021 restructure that nobody has looked at since.

This guide is written for the UK business that is either partway through a Copilot pilot or has been asked by its board why the rollout is stalled. It leads with the oversharing risk because that is the risk that actually materialises, and because every other control — sensitivity labels, DLP, retention, auditing — is either useless or actively misleading if the underlying permission model is wrong. You will get a concrete way to size your own oversharing exposure before you buy another licence, then a working sequence for permission auditing, SharePoint site access reviews, Microsoft Purview sensitivity labels, Restricted Content Discovery, DLP policies scoped to Copilot, and the audit and retention obligations that follow Copilot interactions into eDiscovery. It also covers the parts that catch UK organisations specifically: UK GDPR and the ICO’s expectations around data protection impact assessments, the EU Data Boundary and where UK tenant data actually sits, and how Copilot governance interacts with Cyber Essentials and the NCSC’s guidance on secure AI adoption.

The framing throughout is deliberately unglamorous. Copilot governance is mostly information architecture work that organisations deferred for a decade, brought forward and given a deadline. That work is finite, it is measurable, and it is far cheaper to do before a wide rollout than after an employee screenshots something they should never have found.

What Copilot can actually see — the permission model in plain terms

Microsoft 365 Copilot grounds its answers in your tenant data through Microsoft Graph and the semantic index. When a user submits a prompt, the orchestrator runs a retrieval step against the content that user has permission to open, assembles the relevant fragments into context, sends that context to the large language model along with the prompt, and returns a grounded answer with citations. The retrieval step is security-trimmed. It respects SharePoint and OneDrive permissions, Exchange mailbox permissions, Teams membership and the access control lists on every individual item. There is no bypass, no service account with tenant-wide read, and no shadow copy of your data sitting outside your compliance boundary.

That is genuinely reassuring, and it is also exactly why the risk is what it is. Security trimming guarantees that Copilot will not show a user something they cannot access. It guarantees nothing about whether they should be able to access it. The two questions have always been different; Copilot is simply the first tool that makes the gap between them visible at conversational speed.

Three structural features of Microsoft 365 turn that gap into a practical problem. The first is permission inheritance: a document inherits from its folder, which inherits from its document library, which inherits from its site. A single broad grant at site level silently propagates to tens of thousands of items, and the person who made the grant was usually trying to unblock one colleague on one file. The second is the Everyone Except External Users claim — a built-in group that resolves to every licensed internal user in the tenant. It appears innocuous in a permissions dialog and it is functionally identical to publishing to the whole organisation. The third is sharing links. “Anyone with the link” and “People in your organisation with the link” both create real, durable access grants that do not appear in the site membership list where an administrator would think to look for them.

Layer on a decade of Teams sprawl — every team creating a SharePoint site, every private channel creating another, every project spinning up a site that outlives the project — and the typical UK mid-market tenant is carrying somewhere between several hundred and several thousand sites, of which a meaningful proportion have no identifiable owner still employed by the business. The semantic index does not care about any of that. It indexes what is accessible, and it does so competently.

Copilot data security by the numbers — what UK estates look like in practice

The figures below are the pattern we see repeatedly in UK tenant assessments of between 50 and 750 seats. They are indicative rather than statistical, and your own numbers will differ, but the shape is remarkably consistent: the problem is concentrated in a small number of very old, very broadly shared sites, and in sharing links nobody remembers creating.

The licence figure matters because it changes the economics of delay. At list price, a hundred Copilot licences is roughly £29,600 a year. If those licences sit unused for three months while a governance argument runs, the organisation has spent around £7,400 on nothing. That is usually more than the cost of doing the permissions work properly in the first place, which is the strongest practical argument for treating remediation as a precondition rather than a parallel workstream.

The ownership figure is the one that surprises boards. Site ownership decays continuously through leavers, restructures and project closure, and nothing in Microsoft 365 forces the decay to be repaired. An unowned site cannot be reviewed, because access review in SharePoint routes requests to the site owner. Restoring ownership is therefore not administrative housekeeping; it is the prerequisite that makes every subsequent control operable.

Copilot readiness scoring — where most UK organisations actually sit

Use the grid below as a pre-flight self-assessment. Score honestly against what you can evidence today, not what policy says should be true. In most assessments the identity and endpoint rows come out well — UK businesses have generally done the Cyber Essentials work — and the information governance rows come out poorly, because nothing previously forced the issue. That asymmetry is the single most reliable predictor of a difficult Copilot rollout.

A useful rule when interpreting the grid: any row you cannot evidence with an export, a report or a screenshot within one working day should be scored high risk regardless of how confident the team feels. Copilot converts undocumented assumptions into retrievable answers, so the absence of evidence is itself the exposure. This is the same discipline that underpins a credible security programme generally, and it maps closely to the evidence-gathering approach we describe in our guide to Cyber Essentials certification for UK businesses.

Where the oversharing actually comes from — ranking the causes

When you decompose a real oversharing finding into its root cause, the distribution is not what most IT teams expect. Deliberate misconfiguration barely registers. Almost everything traces back to a person solving a legitimate short-term problem with the fastest tool the interface offered them. The chart below ranks the causes we most commonly attribute findings to during pre-Copilot assessments of UK tenants, by the share of findings each accounts for.

Read the top two bars together, because they are the same failure wearing different clothes. Both are the product of an interface that makes the broadest possible grant the easiest available action. A user who clicks Share and accepts the default has, in many tenants, just published to the entire organisation. They received no warning, the file did not visibly change, and the site membership list they might later be audited against does not mention them. Until Copilot arrived, the practical consequence was close to zero, because discoverability was near zero. That is precisely the assumption that has now been withdrawn.

The third bar — orphaned sites — deserves separate treatment because it compounds. A closed project leaves behind a site containing tender responses, pricing models, subcontractor rates and sometimes personal data about candidates or clients. Nobody deletes it, because nobody is sure they are allowed to. The membership list slowly fossilises around people who have moved on or left. Five years later the content is still fully indexed, still fully retrievable, and no longer governed by anyone. Site lifecycle management is therefore a Copilot control, not a storage-cost exercise.

The migrated file-share row is the one that most often blindsides organisations that consider themselves mature. A lift-and-shift from an on-premises file server to SharePoint preserves the folder structure faithfully and usually flattens or approximates the NTFS permissions, because a perfect mapping is rarely possible. Nested groups become direct grants, deny rules do not translate, and the “we will tidy it afterwards” phase never gets funded. If your tenant contains content migrated from a file server and you have not since audited it, assume the permissions are wrong until you can show otherwise. The same discipline we recommend when validating a restore also applies here: an untested assumption is not a control, a point we make at length in our guide to backup and restore testing for UK businesses.

Copilot data security — what the governance actually costs

Budget conversations about Copilot usually stop at the licence. That is the smallest and most predictable number in the exercise. The table below sets out the realistic cost components for a UK organisation of roughly 250 seats taking Copilot from pilot to controlled general availability, using published UK list prices where they exist and typical UK professional services rates where they do not. Prices are indicative at the time of writing and should be confirmed against your own agreement, because Microsoft licensing terms and bundling change frequently.

Two observations from that table are worth holding on to. First, the one-off governance work — remediation, labelling, DPIA — typically lands between £20,000 and £43,000 for an estate of this size, which is a quarter to a half of a single year of licence spend. Framed against the licence, it is proportionate. Framed as an unbudgeted surprise mid-project, it stalls the programme. Get it into the business case at the start.

Second, the E5 line is where most of the money is, and it is also the line most often assumed to be mandatory when it is not. Copilot itself does not require E5. What E5 brings is the fuller Purview toolset — particularly the more capable auto-labelling, insider risk management and the advanced audit retention that some regulated organisations need. Many UK businesses land on E3 plus targeted add-ons for the subset of users who genuinely need them, and reach an acceptable control position at a materially lower cost. Model both before committing, and be sceptical of any assessment that jumps straight to a tenant-wide E5 uplift without showing which specific controls justify it.

The line that is easiest to underfund is ongoing governance. Access reviews, label coverage reporting and agent approvals are not a project with an end date; they are a recurring operational rhythm. Organisations that fund the one-off remediation but not the ongoing operation find their oversharing figures back at baseline within eighteen months, because the same interface defaults that created the problem are still there and still convenient.

The Copilot governance timeline — what a controlled rollout looks like

The sequence below is the one that holds up in practice for a UK organisation of 100 to 500 seats. It assumes you already have Microsoft 365, that identity and endpoint controls are broadly in order, and that you are starting Copilot governance from a standing start. The elapsed time is eight to twelve weeks. Compressing it is possible but almost always means deferring the sensitivity label work, which is the piece that produces the durable control rather than the one-off clean-up.

The two weeks most often cut are 4 to 6, the label design. The reasoning is always the same — the broad grants have been removed, the surprises have stopped, so the urgency evaporates. The problem is that permission clean-up is a snapshot and labelling is a control. Without labels, your protection decays at exactly the rate your staff create and share new content, which is to say continuously. If budget forces a choice, cut the pilot short rather than the labelling.

Two approaches to Copilot readiness — and which one holds

Most organisations end up choosing, explicitly or by default, between two strategies. The first is to constrain what Copilot can reach. The second is to fix what everyone can reach. They are not mutually exclusive, and the honest answer is that you will use both, but the balance you strike determines whether you are building a control or a workaround.

The case for the left-hand column is real and should not be dismissed. Restricted Content Discovery gives you a genuine, immediate reduction in exposure for a named set of sites, and it is reversible. If your board has asked for Copilot next month and the estate is in poor condition, this is how you say yes responsibly. The case against it as a destination is that it treats Copilot as the threat. It is not. A finance assistant who can open the salary spreadsheet directly is exposed whether or not Copilot exists; excluding the site from Copilot grounding leaves the underlying entitlement untouched and the file one search box away.

There is also a slow structural problem with the exclusion strategy. Every new site holding something sensitive has to be spotted and added to the exclusion list by a human who knows it exists. Miss one and it is fully in scope. Over-apply it and you have progressively excluded the content that made Copilot worth buying, at which point the organisation concludes the tool underdelivers and blames the vendor. The exclusion list is a tourniquet, and tourniquets are not treatment.

The right-hand column costs more at the start and pays back beyond Copilot entirely. Correct permissions and a working label taxonomy improve your position on subject access requests, on data breach containment, on insider risk, on offboarding and on every future AI tool your organisation adopts — and there will be more. It is the same logic that makes identity-centric access control worth the effort generally, which we set out in our guide to zero trust network access for UK businesses.

The Copilot readiness gauge — scoring your own tenant before rollout

The gauge below shows the median score we record when we first assess a UK mid-market tenant that has bought Copilot licences but not yet done governance work. It is deliberately sobering. The score is a composite across five weighted dimensions: permission hygiene, label coverage, oversight and audit, policy and training, and agent governance. A score below 50 does not mean you cannot deploy Copilot; it means a broad deployment will surface findings faster than you can remediate them, and the organisation will experience that as a security incident rather than a backlog.

Interpretation matters more than the number. Below 40, the correct action is to defer the wide rollout and run the remediation programme; a pilot of ten to twenty users in a deliberately narrow content scope is still worthwhile because it builds the internal case. Between 40 and 65, a controlled cohort rollout with Restricted Content Discovery applied to the sensitive sites is defensible while remediation runs in parallel. Above 65, you can widen with normal change control. Above 80, your constraint is adoption and training rather than security, which is a much better problem to have.

The reason the median sits so low is not incompetence. It is that every dimension in the score measures something that had no forcing function before. Nobody was ever asked to evidence label coverage. No auditor previously required a list of organisation-wide sharing links. The score is low because the questions are new, not because the organisations are careless — and that framing matters when you present it internally, because a governance programme that opens by blaming the IT team gets no cooperation from the people whose sites need reviewing.

Sensitivity labels and DLP — the controls that survive contact with reality

Permission remediation fixes yesterday. Sensitivity labels and data loss prevention are what stop the problem regenerating tomorrow. The mechanism is worth understanding precisely, because it is frequently described inaccurately in vendor material.

A Microsoft Purview sensitivity label is metadata attached to a file or email that can additionally apply encryption with a defined set of usage rights. When a label applies encryption, the rights are granular: view, edit, copy, print, forward and, critically for this discussion, EXTRACT. Microsoft 365 Copilot respects those rights. If a user does not hold the EXTRACT right on a labelled document, Copilot will not return its content to them, even though the retrieval layer found it and the user can open the file in Word. That is the single most useful technical fact in Copilot data security, and it is why labelling is a control while permission clean-up is a snapshot.

Copilot also propagates labels. When it generates a response grounded in labelled content, the resulting artefact inherits the most restrictive label among its sources. A summary drawn from three documents, one of which is labelled Confidential, comes out labelled Confidential. That inheritance is what prevents Copilot becoming a laundering mechanism for protected content, and it is a strong argument for labelling the source rather than trying to police the output.

Three practical rules make label programmes work in UK organisations. Keep the taxonomy to five labels or fewer — Public, Internal, Confidential, Highly Confidential and one regulated category is enough for almost everyone, and every additional label measurably reduces the accuracy with which staff apply them. Second, run auto-labelling in simulation mode for at least two weeks before enforcing, and read every false positive; a rule that catches National Insurance numbers will also catch the reference format your finance system uses for supplier IDs, and discovering that after enforcement is expensive. Third, apply container labels to Teams and SharePoint sites as well as file labels, because the container label governs the default for everything created inside it, and defaults are what actually determine coverage at scale.

DLP for Copilot is the complementary control. A DLP policy scoped to the Microsoft 365 Copilot location can prevent content carrying a given sensitivity label from being used to ground a response at all. This is subtly different from the EXTRACT mechanism: EXTRACT is a per-user rights check, whereas the DLP policy is a blanket statement that this class of content is not available to the assistant regardless of who is asking. Use it for the categories where the answer is always no — typically legal advice under privilege, live M&A material, and HR case files — and rely on labels plus permissions for everything else.

The two rows to look at hardest are container labels at 17% and auto-labelling in enforcement at 14%. Those are the rows that determine whether your protection scales with your content or stays frozen at whatever you manually labelled during the project. Manual labelling has a well-documented ceiling: staff apply labels correctly when the choice is obvious and they are not in a hurry, which describes a minority of real working moments. Automation and container defaults are what move coverage from the twenties into the eighties.

The audit row at 46% is the one that becomes urgent the first time something goes wrong. Purview Audit records Copilot interaction events, and Copilot prompts and responses are retained in a hidden folder in the user’s mailbox, which makes them discoverable through eDiscovery and subject to your retention policies. If you have never confirmed that audit is enabled with adequate retention, you may find that the evidence you need to investigate an incident aged out before you knew you needed it. Confirm retention against your regulatory requirement, not against the default.

UK GDPR, the ICO and where your Copilot data actually lives

Copilot governance in the UK carries obligations that sit outside the Microsoft admin centre entirely. Getting these right is usually straightforward, but they need to be done deliberately rather than assumed.

Start with the data protection impact assessment. Under UK GDPR, a DPIA is required where processing is likely to result in a high risk to the rights and freedoms of individuals, and the ICO’s own guidance identifies the use of innovative technology and large-scale processing of personal data as indicators that push you towards one. A tenant-wide Copilot deployment across an organisation’s email, documents and Teams conversations meets those indicators comfortably for most businesses. The practical answer is to complete a DPIA regardless of whether you conclude it was strictly mandatory, because the cost of writing one is a few days and the cost of not having one when the ICO asks is considerably higher. Document what personal data Copilot can reach, the lawful basis for the processing, what you have done about data minimisation, and how a data subject access request will be handled now that prompts and responses form part of the record.

That last point deserves emphasis because it is routinely missed. Copilot prompts and responses are stored in the user mailbox and are discoverable. A subject access request from an employee can therefore reach Copilot interactions that mention them, and a litigation hold will capture them. Your DSAR process and your retention schedule both need updating to reflect that new category of record. If your retention policy says mailbox content is kept for seven years, you have just committed to keeping seven years of Copilot conversations; if it says twelve months, you have committed to losing your incident evidence after twelve months. Neither is wrong, but the decision should be made rather than inherited.

On data residency: Microsoft 365 Copilot processing for UK and European customers is covered by the EU Data Boundary commitments, and Microsoft states that Copilot does not use your tenant data to train the underlying foundation models. Your prompts and grounding data remain within the Microsoft 365 service boundary and inside your existing compliance commitments. UK organisations with tenants provisioned in the United Kingdom should confirm their own configuration rather than relying on a general statement, particularly if they have Advanced Data Residency or specific contractual commitments to public sector or regulated customers. Ask Microsoft or your partner for the current documentation and attach it to the DPIA rather than paraphrasing it.

On the security frameworks: the NCSC has published guidance on the secure use of AI systems that maps cleanly onto this work — understand what the system can access, control the inputs, monitor the outputs, and maintain the ability to audit. Cyber Essentials does not currently have a Copilot-specific control, but the access control and user account management requirements are exactly the controls that a Copilot oversharing finding tends to expose. If you are heading for certification or recertification, doing the Copilot permissions work first makes the assessment easier rather than harder. For regulated firms, the FCA’s expectations around operational resilience and outsourcing apply to Copilot as they would to any material change in how the firm processes information; the change should go through your normal governance route rather than being treated as a productivity tool rollout.

One further UK-specific point on third-party and custom agents. Copilot Studio and declarative agents let business users build assistants over specific data sources, and those agents can be shared. An agent is a new access path with its own configuration, and in many tenants business users can create one without involving IT. Establish an approval route before that becomes a habit. The relevant question for each agent is simple — what can it read, who can use it, and who is accountable for it — and it is much easier to ask that question at agent number three than at agent number ninety.

Adoption and control together — what good looks like at twelve months

The measure that matters at the end of a Copilot governance programme is not how much you locked down. It is how much of the estate is genuinely usable by the assistant while remaining correctly protected. Organisations that over-restrict end up with an expensive tool that answers “I could not find anything relevant” and a user base that quietly stops opening it. The donut below shows the share of tenant content that is both correctly labelled and correctly permissioned — and therefore safely available for grounding — that a well-run programme typically reaches around a year in.

Getting from the low twenties to the low eighties is almost entirely a function of automation rather than effort. Container labels set the default for new content, auto-labelling policies catch the sensitive categories, and the remaining gap is the long tail of legacy material that nobody has touched in years. That tail is where the archive decision matters: content that has not been opened in five years and has no retention obligation attached to it is usually better deleted than labelled, and deleting it improves both your security position and your Copilot answer quality at the same time.

The remaining 18% divides into three groups. Roughly half is legitimately restricted content that should stay outside Copilot grounding — privileged legal advice, live transaction material, HR investigations. A further chunk is content in formats or systems Copilot does not index well, which is a data architecture question rather than a security one. The small remainder is genuine backlog, and the honest position is that most organisations never reach zero backlog and do not need to. What they need is to know the size of the backlog and to be able to show it shrinking.

A real-world example — what a pilot actually surfaces

A 210-person professional services firm in the West Midlands bought 40 Copilot licences and deployed them to a cross-departmental pilot group without any prior permissions work, on the reasonable basis that a pilot is small and reversible. Within the first fortnight the pilot produced eleven separate reports of Copilot returning something the user did not expect to be able to see. None involved a security control failing. Every single one was a permission that had been correct at the time it was granted and had never been revisited.

Three findings accounted for most of the concern. A partner-level remuneration model had been uploaded to a general management SharePoint site in 2022 for a single meeting and never removed, on a site that had picked up Everyone Except External Users during an unrelated intranet project. A folder of employee occupational health referrals sat in an HR site whose permissions had been broken at folder level to grant a departed HR coordinator access, with inheritance never restored. And a set of client fee proposals, including rates the firm considered commercially sensitive, were reachable through an organisation-wide sharing link created by a junior colleague trying to get a document reviewed quickly during a deadline.

The remediation took nineteen working days. Ownership was reassigned across 340 sites, Everyone Except External Users was removed from 26 of them, roughly 1,400 organisation-wide sharing links older than 180 days were expired, and Restricted Content Discovery was applied to the HR, finance and partnership sites while a five-label sensitivity taxonomy was designed and rolled out. The pilot resumed in week four and the firm widened to 140 licences by the end of the quarter. Notably, the occupational health finding triggered a separate and entirely justified conversation with the firm’s data protection lead about special category data handling that had nothing to do with Copilot at all.

We spent the first week furious with Microsoft. By the end of the second week it was obvious that Copilot had not done anything except answer questions honestly, and that every one of those files had been sitting there readable by 200 people for years. The tool did not create the risk. It just stopped us being able to pretend the risk was not there.

The generalisable lesson is about sequencing rather than tooling. The firm did the right work in the end, but it did it under pressure, with an anxious executive committee and a pilot group that had already seen things it should not have seen. Running the same nineteen days of remediation before the pilot would have cost the same money and produced none of the alarm. That is the entire argument for treating Copilot data security as a precondition, and it is the same argument for testing your defences on your own schedule rather than an attacker’s, which we make in our guide to how often UK businesses should run penetration tests.

Common Copilot data security mistakes to avoid

The failures below are the ones that recur across UK deployments. None of them are exotic. Most are the result of treating Copilot as a software rollout rather than an information governance change, and all of them are cheaper to avoid than to unwind.

• Treating Copilot as the threat. Excluding sites from grounding while leaving the underlying entitlement intact means the exposure is unchanged for anyone who knows where to look. It converts a governance problem into a search problem and calls it solved. Use exclusion as a holding control with an explicit end date, never as the destination.
• Buying licences before assessing the estate. Licence spend starts on day one; readiness takes weeks. Organisations that provision first end up either deploying into a poor control position or paying for idle licences while the argument runs. Assess first, buy in phases that match the rollout cohorts.
• Designing a fifteen-label taxonomy. Every additional sensitivity label reduces the accuracy with which staff apply them, and a label applied incorrectly is worse than no label because it creates false confidence. Five labels or fewer, with clear plain-English descriptions and a default, will outperform an elegant taxonomy that nobody uses correctly.
• Enforcing auto-labelling without simulation. Pattern-matching rules generate false positives against real business data in ways nobody predicts from a design document. Enforcing straight away encrypts content that should not be encrypted, generates a support queue, and burns the credibility of the whole programme in the first week. Simulate for at least two weeks and read the results.
• Ignoring sharing links because they are not in the membership list. Organisation-wide and anonymous links are real, durable grants that do not show up where administrators instinctively look. A site can pass a membership review and still be readable by everyone. Audit links separately, set expiry, and change the tenant default so the next link is scoped narrowly.
• Leaving agent creation ungoverned. Copilot Studio and declarative agents are new access paths that business users can create and share. Without an approval route you accumulate agents nobody owns, reading data nobody approved, long before anyone notices. Establish the route while the count is small.
• Forgetting that prompts are records. Copilot interactions are retained, discoverable and subject to retention policy and subject access requests. Teams that never update the retention schedule either keep far more than they intended or lose the evidence they need for an investigation. Decide deliberately.
• Funding the project and not the operation. Permissions decay continuously through leavers, restructures and new projects. Without a recurring rhythm of access reviews and label coverage reporting, an estate remediated in the spring is measurably back towards baseline by the following year. Budget the ongoing 0.2–0.5 FTE or the managed equivalent.

The Copilot data security checklist — twelve points before you widen the rollout

Work through this in order. Each item should produce an artefact — an export, a report, a signed document — because the artefacts are what make the position defensible to an auditor, an insurer or a client’s procurement team. If an item cannot produce an artefact, it is not yet done.

1. Produce a full site inventory. Every SharePoint and Teams site, with owner, size, last activity date, external sharing setting and sensitivity label. This is your baseline and every later measurement is a delta against it.
2. Assign an owner to every site. A current employee, named individually rather than a shared mailbox. Sites that no department will adopt go to archive or deletion with a documented decision.
3. Export and review every broad grant. Every site granting access to Everyone Except External Users, All Company or any tenant-wide group. Remove each one that was not a deliberate, recorded decision.
4. Inventory and expire sharing links. Anonymous and organisation-wide links, sorted by age. Expire anything past an agreed threshold and set a default expiry so the problem does not regenerate.
5. Change the tenant sharing defaults. Make the default link type “specific people”. This one setting prevents more future oversharing than any amount of remediation fixes past oversharing.
6. Identify and protect the crown jewels. Payroll, HR case files, board papers, transaction material, privileged legal advice. Apply Restricted Content Discovery as an immediate control and record it as temporary.
7. Run the DSPM for AI assessments. Microsoft Purview’s Data Security Posture Management for AI gives you a first read on unlabelled sensitive content and on how Copilot is being used. Run it before rollout and again after.
8. Publish a sensitivity label taxonomy. Five labels or fewer, with encryption and usage rights defined for the protected tiers, published to a pilot group first and then tenant-wide with a sensible default.
9. Apply container labels to sites and Teams. Container labels govern the default for everything created inside them, which is what moves coverage from manual effort to structural protection.
10. Run auto-labelling in simulation, then enforce. Minimum two weeks of simulation, every false positive reviewed, rules tuned, then enforcement on the highest-value categories first.
11. Scope a DLP policy to Microsoft 365 Copilot. Block grounding on the label tiers where the answer is always no. Test it with a real prompt from a real user before declaring it live.
12. Confirm audit, retention, DPIA and policy. Purview Audit capturing Copilot events with retention matching your regulatory requirement, the retention schedule updated for Copilot interactions, a signed DPIA, an acceptable use policy that names AI assistants, and an approval route for new agents.

Copilot data security at a glance

The summary below condenses the whole guide into the facts most often needed in a board paper, a supplier questionnaire or an internal business case. Verify the licensing and product figures against your own agreement and current Microsoft documentation before quoting them externally, since Microsoft revises both regularly.

How Cloudswitched approaches Microsoft 365 Copilot governance

Cloudswitched works with UK businesses on the part of Copilot that sits underneath the licence: understanding what the assistant can currently reach, remediating the permissions and sharing configuration that put it there, and standing up the labelling, DLP and audit controls that keep the position stable once the project team has moved on. That work is deliberately evidence-led — a measured baseline, a remediation backlog with named owners, and a re-measurement you can put in front of a board, an insurer or a client’s procurement team.

The same team supports the surrounding Microsoft 365 estate, because that is usually where the findings lead: identity and conditional access, email security, backup and recovery, and the information architecture decisions that determine whether the next AI tool is a two-week rollout or another twelve-week governance programme. Whether you are pre-purchase, mid-pilot or trying to unstick a stalled deployment, the starting point is the same — establish what Copilot can see today, then decide deliberately what it should see tomorrow.

Frequently Asked Questions

Can Microsoft 365 Copilot access files I do not have permission to open?

No. Copilot retrieval is security-trimmed against the signed-in user’s existing permissions across SharePoint, OneDrive, Exchange and Teams. It has no service account with tenant-wide read and no separate index that bypasses access control lists. The reason Copilot data security is a live concern is not that it exceeds permissions, but that it makes existing permissions visible in a way search never did. If Copilot returns something surprising, the correct interpretation is that the user was already entitled to open that file and simply did not know it existed. That makes every Copilot surprise a permissions defect to be logged and fixed, rather than a product fault to be raised with the vendor.

What is oversharing risk in Copilot, and how do I measure it?

Oversharing risk is the gap between what your staff are technically entitled to access and what you intended them to access. Measure it in three ways. First, count sites granting access to Everyone Except External Users or any tenant-wide group. Second, inventory anonymous and organisation-wide sharing links, sorted by age, since these are real grants that do not appear in site membership. Third, run the Data Security Posture Management for AI assessments in Microsoft Purview to identify unlabelled sensitive content sitting in broadly accessible locations. Those three numbers give you a defensible baseline before rollout and a way to demonstrate improvement afterwards. A controlled pilot with deliberately probing prompts, run under documented authorisation, will find the rest.

Do sensitivity labels actually stop Copilot from using a document?

Yes, when the label applies encryption. Microsoft Purview sensitivity labels can enforce granular usage rights, and Copilot respects the EXTRACT right specifically. A user who lacks EXTRACT on a labelled document will not receive its content in a Copilot response, even if the retrieval layer located it and even if they can open the file directly in the desktop application. Labels also propagate: content Copilot generates from labelled sources inherits the most restrictive label among them. A marking-only label with no encryption does not restrict Copilot — it is a visual classification. If you want a label to act as a control rather than a signal, it must apply encryption with defined usage rights.

What is Restricted Content Discovery and when should I use it?

Restricted Content Discovery is a SharePoint site-level setting that excludes a site’s content from Copilot grounding and from organisation-wide search, without changing who can open the files directly. It is fast to apply, reversible, and it does not disrupt the people who legitimately work in the site. Use it as an immediate holding control on your most sensitive sites — payroll, HR case files, board papers, live transaction material — while the permissions and labelling work runs. Do not use it as your permanent answer. It suppresses the Copilot symptom while leaving the underlying entitlement intact, so record it in the risk register as a compensating and temporary control with the permission defect kept open until genuinely resolved.

Are my Copilot prompts and responses stored, and can they be discovered?

Yes to both. Copilot interactions are retained in a hidden folder within the user’s Exchange mailbox. That means they fall under your Microsoft Purview retention policies, they are captured by litigation holds, they can be searched through eDiscovery, and they can be caught by a subject access request from an employee whose name appears in a prompt or response. Two practical consequences follow. Update your retention schedule deliberately, because whatever applies to mailbox content now applies to Copilot conversations. And update your DSAR handling process, since Copilot interactions are a new category of record that your existing search procedures probably do not cover.

Does Microsoft use our tenant data to train its AI models?

No. Microsoft states that Microsoft 365 Copilot does not use customer tenant data to train the underlying foundation models. Prompts, grounding data and responses remain within the Microsoft 365 service boundary and are covered by the same contractual commitments as the rest of your subscription, including the EU Data Boundary commitments relevant to UK and European customers. For a DPIA or a supplier assurance questionnaire, do not paraphrase this from a blog post — obtain the current Microsoft documentation and product terms through your partner or account team and attach them to the assessment, because the wording is what an auditor will want to see and Microsoft updates it periodically.

Do we need Microsoft 365 E5 to deploy Copilot securely?

No. Microsoft 365 Copilot is an add-on that runs on E3 as well as E5. What E5 provides is the fuller Microsoft Purview toolset — more capable auto-labelling, insider risk management, communication compliance and extended audit retention. Many UK organisations reach an acceptable control position on E3 plus targeted add-ons applied to the subset of users who genuinely need them, at materially lower cost than a tenant-wide E5 uplift. Model both options and require any proposal that jumps straight to E5 to name the specific controls that justify it. The permissions and sharing remediation that removes most of your risk requires no licence uplift at all.

How long does Copilot governance take before we can roll out widely?

For a UK organisation of 100 to 500 seats starting from a standing start, plan on eight to twelve weeks: a week of discovery, a week of ownership repair, a week removing broad grants and expiring sharing links, two to three weeks designing and piloting sensitivity labels, a week on DLP, audit and the DPIA, and two to three weeks of controlled pilot plus remediation of what the pilot finds. Larger or older estates, particularly those carrying permissions migrated from an on-premises file server, run longer. You can compress the schedule by starting a narrow pilot after week three, but resist compressing the labelling work, since that is the control that keeps the position stable over time.

What does a Copilot readiness programme cost a UK business?

For a 250-seat estate, the one-off governance work typically lands between £20,000 and £43,000 — permissions and oversharing remediation at £9,000 to £22,500, sensitivity label design and rollout at £7,200 to £13,500, and DPIA, policy and training at £3,600 to £7,200. Ongoing governance runs 0.2 to 0.5 FTE or £12,000 to £30,000 a year as a managed service. Set that against roughly £74,100 a year in licences at UK list price for 250 seats, and the governance work is a quarter to a half of one year of licence spend. Budget it at the start rather than discovering it mid-project.

How do we govern Copilot Studio agents and custom agents?

Treat every agent as a new access path with three questions attached: what data can it read, who is permitted to use it, and who is accountable for it by name. Establish an approval route before agent creation becomes widespread, because retrofitting governance across ninety agents is far harder than applying it to the first three. Constrain which users can create and publish agents, require the data sources to be declared, and review agents on the same cycle as site access reviews. Agents inherit the permissions of the user or the connection they run under, so an agent built over a broadly shared site carries exactly the oversharing exposure of that site — the permissions work underneath remains the real control.

Does Copilot affect our Cyber Essentials certification or UK GDPR position?

Cyber Essentials has no Copilot-specific control, but its access control and user account management requirements cover exactly the ground a Copilot oversharing finding exposes, so doing the permissions work first makes certification easier rather than harder. On UK GDPR, the material obligations are a data protection impact assessment for most tenant-wide deployments, a documented lawful basis, evidence of data minimisation, and updated processes for subject access requests and retention now that Copilot interactions are discoverable records. For regulated firms, route the change through your normal governance process rather than treating it as a routine productivity rollout.

What is the single most valuable change we can make this week?

Change the tenant default sharing link type to “specific people”. It takes minutes, requires no project, and it stops the largest single source of future oversharing at the point of creation rather than remediating it years later. Pair it with a default expiry on any organisation-wide and anonymous links, and communicate the change before you make it so the people whose workflow it alters are not surprised. Everything else in this guide is remediation of the past; this one setting is the cheapest available control over the future, and organisations that skip it find their oversharing figures back at baseline within eighteen months of a successful clean-up.

Related reading

Copilot governance sits inside a wider Microsoft 365 and security posture. These guides cover the adjacent decisions most often raised during a readiness assessment.

• Microsoft 365 Email Security: Defending Against Phishing and BEC — a UK Guide
• Zero Trust Network Access (ZTNA): A UK Business Guide
• Cyber Essentials Certification: A Step-by-Step Guide for UK Businesses
• Backup and Restore Testing: Proving Your Recovery Actually Works
• Penetration Testing Frequency: How Often UK Businesses Should Test