Copilot Governance for Business: Policy, Oversight and Controls

What Copilot governance covers

1. 01

   Data governance

   What data can Copilot access? Who has access to what, and is that access appropriate? This is the data permission problem - Copilot queries your Microsoft 365 content using the permissions of the user who is asking. If your SharePoint permissions are overly permissive, Copilot will surface content that was not intended to be broadly accessible. Data governance for Copilot means completing a permissions review, deploying sensitivity labels, and restricting Copilot access to content classified as confidential or above.

2. 02

   Usage governance

   How should employees use Copilot? What is acceptable, what is not, and what are the risks employees need to understand? This requires an acceptable use policy - not a lengthy legal document, but a clear statement of what Copilot can and cannot be used for, what outputs require human review before use, and what categories of information should not be entered into Copilot prompts.

3. 03

   Agent governance

   Who can build Copilot Studio agents? What data sources can agents access? How are agents reviewed before being shared with others in the organisation? Copilot Studio enables any licensed user to build agents that can query data sources, take actions, and be shared with colleagues or external users. Without governance controls, agents become an uncontrolled data access and sharing mechanism.

The acceptable use policy: what it needs to cover

• Permitted uses: what Copilot can be used for in your organisation - drafting documents, summarising meetings, generating first drafts, analysing data. Be specific about the work contexts where Copilot is approved.
• Restricted uses: categories of work where Copilot should not be used without additional review. Examples: drafting external legal communications, generating financial advice, creating content that will be attributed to a named person without their review, processing sensitive customer data in a context where the data should not leave the organisation.
• Output review requirements: Copilot outputs require human review before use in any context where accuracy is material. The policy should state explicitly that Copilot outputs are not to be treated as authoritative without verification.
• Prompt hygiene: employees should not enter customer personal information, confidential client data, or sensitive personal details into Copilot prompts unless they have verified that the data is appropriately handled within Microsoft's compliance boundary.
• Reporting: what to do if an employee notices Copilot surfacing content that should not be accessible to them, or producing outputs that appear to breach confidentiality.

Agent governance: the controls you need before Copilot Studio is used

1. 01

   Decide who can create agents

   The default Copilot Studio setting allows any licensed user to create agents. For most organisations, agent creation should be restricted to IT administrators or a named group of approved builders. This is configured in the Microsoft 365 admin centre under Copilot Studio settings.

2. 02

   Define what data sources agents can access

   Agents can be configured to access SharePoint libraries, external APIs, databases, and other connectors. Establish a policy that specifies which data sources require approval before an agent can connect to them. At minimum: agents should not connect to HR data, financial records, or customer PII without a formal review.

3. 03

   Establish a review process before agents are shared

   Any agent that will be shared with users beyond its creator should be reviewed by IT before publication. The review should check: what data does this agent access, who will it be shared with, and is the data access appropriate for that audience? Document the review and the approval.

4. 04

   Restrict external sharing of agents

   Copilot Studio agents can be shared externally - with customers, partners, or published as a public-facing bot. External sharing of agents requires explicit approval and should not be available to general users by default.

The technical prerequisites that governance depends on

• SharePoint permissions reviewed and tightened - if all SharePoint sites are accessible to all users, your governance policy cannot prevent Copilot from surfacing anything to anyone
• Sensitivity labels deployed - at minimum for confidential and highly confidential content - with Copilot access restrictions configured on the highest classification labels
• Microsoft Purview AI hub configured - provides visibility into Copilot usage, what content is being accessed, and whether it is being used appropriately
• DLP policies extended to Copilot - Microsoft Purview DLP can be configured to prevent sensitive information from being included in Copilot responses
• Guest access reviewed - external guest users with active SharePoint access can use Copilot to query content they have permissions to access; ensure guest access reflects current business relationships

The governance decisions that must be made before deployment

Pre-deployment decisions checklist

• Which employee roles will receive Copilot licences, and in what sequence?
• What categories of content are classified as confidential and should be restricted from Copilot access?
• What is the acceptable use policy for Copilot, and who has approved it?
• Who can build Copilot Studio agents, and what is the review process before an agent is shared?
• What is the incident response process if Copilot surfaces information it should not have access to?
• How will Copilot usage be monitored, and who is responsible for reviewing the Microsoft Purview AI hub reports?