How to Restrict Department Data Access in Microsoft 365 Copilot

Official documentation checked October 14, 2026.

To stop employees in one department from accessing another department’s confidential information through Microsoft 365 Copilot, begin with access to the underlying content. There is no documented universal Copilot “Data boundaries” wizard that maps each department to allowed SharePoint sites, Teams channels and OneDrive folders.

A practical design combines correctly scoped source permissions with supported controls where needed. A restriction on discovering content and a restriction on opening it are different safeguards.

Define who should access each source

Copilot uses information available to the signed-in user under the applicable permissions. Microsoft’s architecture guidance makes source access central to grounding.

For a Finance example, identify the actual site, libraries, shared folders and relevant Teams resources. List the people who should read each one, including approved cross-department staff and service owners. Check direct grants, group membership and sharing links rather than assuming a site name defines its audience.

Use an ordinary non-Finance account to test whether it can open a representative confidential file directly. If it can, a Copilot prompt is not the first problem to solve. Have the content owner correct the unwanted access while preserving legitimate collaboration.

If department attributes drive group membership, validate the attributes and resulting membership before using that group for enforcement. A group named “Finance Copilot Boundary” creates no restriction by itself.

Apply SharePoint restricted access where appropriate

SharePoint Restricted Access Control can add an allowed-group requirement to site access. Check SharePoint Advanced Management prerequisites and obtain the appropriate administrative approval first.

1. In the SharePoint admin center, open Policies > Access control > Site-level access restriction and enable the feature if approved.
2. Under Sites > Active sites, select the intended site.
3. In Settings, edit Restricted site access, enable restriction to specified groups, add the approved groups and save.

Users need both ordinary content permission and membership in an allowed control group. Membership alone grants no content permission. Search and Copilot honor the restriction, subject to propagation. Private and shared channel sites require separate configuration; external shared-channel participants are not evaluated against this control and continue to depend on channel/site permissions. Review the full Restricted Access Control documentation before deployment.

This site control does not create a universal departmental boundary for every Teams message, mailbox and external connector. Treat those sources separately and test the intended outcome in each service.

Distinguish discovery, DLP and communication barriers

Restricted Content Discovery reduces broad discovery of SharePoint content. It does not revoke a user’s existing access and must not be substituted for a permission boundary.

For a separate requirement—allow people to read a sensitive file but exclude its content from supported Copilot processing—consider the applicable Purview DLP controls. Label-based exclusion can prevent content processing while the item still appears as a citation. Do not interpret a citation alone as evidence that the excluded content was used. The Copilot DLP location does not support administrative units, so do not promise department scoping through that mechanism.

If the business requirement is to prevent communication and collaboration between defined groups, review Microsoft Purview Information Barriers with the compliance team. This is a broader policy design, not a Copilot-only switch; supported two-way restrictions do not cover Exchange email communication.

Test allowed and denied cases before rollout

Create a small acceptance set: a Finance user with the required permissions, a non-Finance user who must be denied, and an approved cross-department collaborator. Test direct file access, relevant search and the specific Copilot experience separately.

Record source URLs, group membership, the effective policy, app and test time. Keep the prior configuration available for an authorized rollback. Allow the documented propagation interval for each control instead of assuming one fixed delay covers all services.

Finally, test an employee transfer and removal from the allowed group. An access design is not complete if it works only when users join. Review exceptions with source owners and keep a documented route for legitimate access requests rather than broadening permissions until a missing Copilot result appears.