Setting up Microsoft 365 Copilot for GDPR compliance means configuring your tenant so that Copilot only reaches data it is allowed to reach, and so that you can prove that configuration. The license alone does not do this. Copilot inherits the settings of your Microsoft 365 environment, and in most environments those settings have never been reviewed for a tool that actively searches everything.
This post walks through the five settings that make the difference, with the places where you find them. It does not replace the fundamental questions before a rollout, which I covered in the 5 GDPR questions before deploying Copilot. But once those questions are answered, configuration is where you find out whether the answers actually reach the technology.
Why the default settings are not enough
Out of the box, Copilot searches everything the individual user can access: SharePoint, OneDrive, Exchange, Teams. It respects existing permissions, but it also exposes them mercilessly. Web search is enabled. Sensitivity labels only work if they exist and are enforced. Retention and logging run on whatever defaults your tenant has.
That is not a Microsoft flaw. Microsoft provides the tools; configuring them is the job of the controller, meaning your company. Which is exactly why the following five settings deserve to be reviewed one by one.
Setting 1: Restricted SharePoint Search as an immediate measure
The biggest practical risk with Copilot is oversharing: files that were shared too broadly over the years and that Copilot now happily works into its answers. Why that happens, and what a permissions audit does about it, is covered in the post on the oversharing problem.
A permissions audit takes time, though. For the transition period there is Restricted SharePoint Search: a tenant setting that limits organization-wide search, and with it Copilot’s search, to an allowed list of up to 100 reviewed SharePoint sites. Anything not on the list does not appear in Copilot answers (the user’s own files and content shared directly with them stay reachable).
You enable the setting via SharePoint PowerShell (Set-SPOTenantRestrictedSearchMode), and you maintain the allowed list there as well. Important: this is a bridge, not a permanent state. The restriction removes part of Copilot’s usefulness, because legitimate content becomes invisible too. The plan should be: enable restricted search, clean up permissions site by site, add reviewed sites to the list, and lift the restriction once the audit is done.
Setting 2: Sensitivity labels with encryption
Sensitivity labels are the setting that controls which content Copilot may process. Encryption is the decisive part: if a document carries a label with encryption and the user does not have the right to extract content from it, Copilot will not pull that content into its answers.
A label without encryption, by contrast, is initially just a marker. It helps with visibility and serves as an anchor for DLP rules (more on that in a moment), but on its own it does not stop Copilot.
Labels are created in the Microsoft Purview compliance center under Information Protection. For law firms, tax practices, and other regulated companies, a four-tier hierarchy has proven practical (Public, Internal, Confidential, Highly Confidential), with encryption from the Confidential tier upwards and auto-labeling rules for patterns like tax IDs and IBANs. The detailed label architecture for client data is in the Copilot guide for tax firms.
One honest caveat: labels are one protective layer, not the only one. There have been documented incidents where label protection did not hold. That is why permissions, labels, and DLP belong together, not as alternatives.
Setting 3: DLP policies for Copilot
Since 2025, Microsoft Purview DLP has had a dedicated policy location for Microsoft 365 Copilot. It lets you create a rule that excludes content with specific sensitivity labels from Copilot processing: Copilot will then not summarize those documents and will not use them as grounding for answers.
This is the right place for the “Copilot must never see this” category: special categories of data under Art. 9 GDPR, ongoing proceedings, M&A documents. The rule keys off the label, which is why setting 2 is the prerequisite. Without clean labels, the DLP rule has nothing to attach to.
You configure this in the Purview compliance center under Data Loss Prevention, as a new policy with the Microsoft 365 Copilot location. Afterwards, document the rule in your DPIA as a technical measure; that is exactly the kind of evidence a supervisory authority wants to see. What else belongs in that document is covered in the post on the contents of a Copilot DPIA.
Setting 4: Controlling web search
Copilot can enrich answers with a web search. When it does, search queries derived from the prompt are sent to Bing. Microsoft itself documents that these queries leave the Microsoft 365 service boundary: they are not covered by the Data Protection Addendum that governs the rest of your Microsoft 365 processing, but by separate terms. According to Microsoft, the queries are separated from user and tenant identifiers, but the contractual framework is a different one.
For a company without professional secrecy obligations, that may be acceptable after an assessment. For a law or tax firm, the clean option is usually to disable web search. You can do that centrally via the “Allow web search in Copilot” cloud policy in the Microsoft 365 Apps admin center. If you leave web search on, the assessment of that data flow belongs, documented, in your DPIA. What you cannot do is leave the question open.
Setting 5: Audit and retention of Copilot interactions
GDPR Art. 5(2) requires accountability. For Copilot that means: you should be able to demonstrate that and how the tool is used, and the interactions have to follow your retention rules.
Both are configuration. Copilot interactions appear in the Microsoft Purview audit log as their own activity type, provided auditing is enabled; verify that actively instead of assuming it. The prompts and responses themselves are stored in the user’s mailbox and can be governed through retention policies in Purview: you define how long Copilot interactions are kept and when they are deleted.
Without these two settings, you are running an AI tool whose use you can neither evidence nor handle according to your deletion concept. With them, you have two paragraphs of your DPIA that practically write themselves.
What settings do not solve
As important as these five points are, three things no tenant setting will fix:
The permissions audit. Restricted SharePoint Search bridges the gap; it does not replace the cleanup. As long as “All Employees” has access to client folders, the underlying problem remains.
The DPIA. The settings are the measures that go into the DPIA. The document itself, with the risk assessment and the DPO consultation, still has to be produced.
User behavior. Which data may go into prompts and which never should is not governed by any admin center policy, but by an AI acceptable use policy plus training.
The order that works
If you are introducing Copilot, or fixing an introduction that already happened, this order has proven itself:
- Enable Restricted SharePoint Search before the first licenses go live
- Start the permissions audit, site by site
- Build and roll out the label hierarchy, with encryption from Confidential upwards
- Point a Copilot DLP policy at the exclusion labels
- Decide on web search and document the decision
- Verify audit logging and retention, and carry both into the DPIA
After that you can loosen the search restriction step by step, because the real protective layers are in place.
Next step
Not sure where your tenant stands on these points? The free AI Compliance Check takes 2 minutes and gives you a first assessment of your Copilot readiness.
Jose Lugo is a CISSP-certified AI compliance consultant with M365 Endpoint Administrator certification. He advises companies in Germany on GDPR-compliant deployment of Microsoft 365 Copilot.