Frequently Asked Questions
Answers to common questions about Microsoft 365 Copilot governance in financial services environments.
Disclaimer
This framework is provided for informational purposes only and does not constitute legal, regulatory, or compliance advice. See full disclaimer.
Copilot Permissions and Access
Does Copilot have elevated access to organizational data?
No. Microsoft 365 Copilot operates entirely within the calling user's existing Microsoft 365 permissions. Copilot does not have its own service account, does not bypass access controls, and cannot access content the user does not already have permission to view.
When a user asks Copilot a question, Copilot queries the Microsoft Graph using that user's identity and permissions. If the user cannot access a SharePoint site, Copilot cannot access it either. If the user does not have permission to view a document, Copilot will not surface content from that document.
The key governance risk is not that Copilot has elevated access, but that many organizations have broader permissions than they realize. Copilot makes existing permission gaps more visible through a phenomenon called "discovery amplification" — content that was technically accessible but practically undiscoverable via traditional search becomes easier to surface through natural language queries. This is why the Quick Start Guide begins with an oversharing assessment.
Relevant controls: Control 1.1 (Copilot Readiness Assessment), Control 1.2 (SharePoint Oversharing Detection), Control 1.14 (Item-Level Permission Scanning), Control 1.15 (Permissions Drift Detection)
Can I disable Copilot for specific users?
Yes. There are several approaches:
-
License-based control (recommended): Only assign Microsoft 365 Copilot licenses to approved users or groups. Users without a Copilot license cannot use Copilot features. Use group-based license assignment in Microsoft Entra to manage this at scale.
-
Per-app toggles: Disable Copilot in specific M365 applications (e.g., enable in Word and Outlook but disable in Teams meetings) via the M365 Admin Center.
-
Conditional Access: Create Entra ID Conditional Access policies to block Copilot access based on conditions (device compliance, location, user risk level).
-
Service plans: Within the Copilot license, individual service plans can be disabled to remove specific capabilities.
Recommended approach for FSI: Use group-based licensing with a phased rollout. Start with a pilot group, expand to low-risk use cases, then broaden as governance controls mature.
Relevant controls: Control 1.9 (License Planning), Control 4.1 (Copilot Admin Settings), Control 4.2 (Teams Meetings Governance)
Copilot Licensing and Access
What is the difference between Copilot Chat Basic and Premium?
Copilot Chat (Basic) is the free tier available to all Microsoft 365 users via the web (copilot.microsoft.com) and Outlook. It uses web data only and does not access organizational data through the Microsoft Graph.
Copilot Chat (Premium) requires a Microsoft 365 Copilot license and provides full access to organizational data via Microsoft Graph, priority access, and advanced features across all Microsoft 365 apps.
As of April 15, 2026, organizations with more than 2,000 users lose embedded Copilot Chat in Word, Excel, PowerPoint, and OneNote for unlicensed users. FSI organizations should review license allocation strategies and communicate access changes to affected users.
Relevant controls: Control 1.9 (License Planning), Control 4.1 (Copilot Admin Settings)
What is Edit with Copilot (Agent Mode) and does it require a license?
Edit with Copilot (formerly Agent Mode) is an iterative document creation experience in Word, Excel, and PowerPoint. It is available to all Microsoft 365 users regardless of Copilot license status. However, unlicensed users can only use web data sources — organizational data requires a paid Copilot license.
FSI organizations should review whether web-sourced content meets their governance and supervision requirements, particularly for client-facing document generation.
Relevant controls: Control 4.1 (Copilot Admin Settings), Control 1.12 (Training and Awareness Program)
Can users access third-party AI models through Copilot?
Microsoft has introduced support for third-party model providers including Anthropic Claude and xAI. Administrators can enable these models for specific users or groups via M365 Admin Center > Copilot > Settings > Other settings.
FSI organizations should evaluate the data handling, residency, and regulatory implications before enabling third-party models, as they may introduce additional data processing outside Microsoft's standard compliance boundary. Organizations should verify that third-party model usage aligns with their existing vendor risk management and data governance policies.
Relevant controls: Control 4.1 (Copilot Admin Settings), Control 2.6 (Web Search and Web Grounding Controls)
What is Copilot Tuning and what governance does it require?
Copilot Tuning (currently in preview) allows organizations to provide curated SharePoint document sets that Microsoft uses to create a tuned Copilot model reflecting institutional terminology, policies, and domain knowledge. Tuning is available only to eligible tenants with at least 5,000 Microsoft 365 Copilot licenses.
Key governance considerations:
- Tuning corpus review: Before including any documents in the tuning corpus, review them for sensitivity labels, DLP classification, and data-owner authorization. The tuning corpus becomes embedded in a model snapshot — data included in tuning may surface in responses to any user with access to the tuned Copilot experience.
- Model-risk documentation: Add the tuned model to the firm's model-risk inventory per Control 3.8 (Model Risk Management). Document the tuning corpus contents, approval chain, snapshot version, and intended user population.
- Snapshot governance: Tuned-model snapshots are point-in-time artifacts. Source document updates do not automatically propagate to the tuned model. Organizations should document snapshot refresh cadence and version history.
- Incident readiness: Prepare for tuning-specific incidents including inadvertent inclusion of restricted data in the training set, snapshot exposure to unintended user populations, and drift between the tuned model's knowledge and current organizational policy. See the AI Incident Response Playbook for tuning-specific incident procedures.
- License verification: Confirm tenant eligibility and review the Copilot Tuning preview terms before activation.
Relevant controls: Control 3.8 (Model Risk Management), Control 2.2 (Sensitivity Labels), Control 2.1 (DLP), Control 4.1 (Copilot Admin Settings)
Do Information Barriers apply to Copilot Pages and Notebooks?
No. Information Barriers are currently not supported for SharePoint Embedded content, which includes Copilot Pages and Copilot Notebooks. This is a significant consideration for FSI organizations with Chinese wall requirements.
Organizations should implement alternative controls such as restricting Copilot Pages creation for populations subject to information barriers. Use Microsoft 365 Cloud Policy to disable Copilot Pages and Notebooks for affected user groups.
Relevant controls: Control 2.4 (Information Barriers for Copilot), Control 4.1 (Copilot Admin Settings)
Data Storage and Privacy
Where is Copilot interaction data stored?
Microsoft 365 Copilot interaction data is stored within the Microsoft 365 compliance boundary:
| Data Type | Storage Location | Retention |
|---|---|---|
| Microsoft 365 Copilot Chat conversations | User's Exchange Online mailbox (hidden folder) | Subject to Exchange retention policies |
| Copilot in Teams chat | Teams chat storage (Azure-based) | Subject to Teams retention policies |
| Copilot in Teams meetings | Meeting transcript storage (Exchange/SharePoint) | Subject to meeting retention policies |
| Copilot in Outlook | Exchange Online (within the email context) | Subject to Exchange retention policies |
| Copilot in Word/Excel/PPT | No persistent storage of the Copilot interaction itself; generated content saved by user is stored in the document | Subject to SharePoint/OneDrive retention policies |
| Copilot Pages | User-owned SharePoint Embedded container | Subject to SharePoint retention policies and manual legal hold workflows |
| Audit logs (CopilotInteraction events) | Unified Audit Log | Subject to audit log retention policies (180 days standard, up to 10 years with Audit Premium) |
Data residency: Copilot interaction data is stored in the same geographic region as the user's Microsoft 365 data. Copilot processing (LLM inference) occurs within the Microsoft 365 service boundary and is subject to the same data processing commitments.
Relevant controls: Control 3.1 (Copilot Audit Logging), Control 3.2 (Retention Policies)
Does Copilot web search share organizational data externally?
When web search is enabled: Copilot may send search queries to Bing to retrieve additional grounding information. Microsoft states that these queries do not include the full user prompt or organizational data — they are derived search queries. However, the queries themselves could potentially reveal information about the user's intent.
FSI recommendation: Disable web search for Copilot in regulated environments. This is a Baseline governance recommendation in this framework for all FSI organizations. With web search disabled, Copilot responses are grounded exclusively in organizational data from the Microsoft Graph.
How to disable: M365 Admin Center > Copilot > Settings > Data access > Web search > Turn off.
Relevant controls: Control 2.6 (Web Search and Web Grounding Controls). See also: Copilot Admin Toggles
Auditing and Compliance
How do I audit Copilot usage?
Copilot usage can be audited through several mechanisms:
-
Unified Audit Log: Search for
CopilotInteractionevents in Microsoft Purview. These events capture when Copilot was invoked, the application context, and metadata about the interaction. Audit (Premium) provides higher-fidelity events including referenced content sources. -
Copilot Usage Reports: M365 Admin Center > Reports > Usage > Microsoft 365 Copilot. Provides aggregated usage metrics (active users, feature adoption) without individual interaction content.
-
DSPM for AI: Microsoft Purview > DSPM for AI provides a dashboard showing Copilot interaction volume, sensitive data exposure in Copilot interactions, and risk indicators.
-
Microsoft Sentinel: For enterprise-scale monitoring, stream Copilot audit data to Sentinel for correlation with other security events, custom analytics rules, and automated incident response.
-
Viva Insights Copilot Dashboard: Provides organizational-level Copilot adoption and productivity metrics for leadership reporting.
For regulatory record-keeping (FINRA 4511, SEC 17a-4): The Unified Audit Log with Audit (Premium) retention is the primary mechanism. Configure retention policies to meet your specific regulatory retention periods (typically 3-6 years).
Relevant controls: Control 3.1 (Copilot Audit Logging), Control 3.9 (AI Disclosure and Transparency), Control 4.6 (Copilot Analytics), Control 4.11 (Sentinel Integration)
What retention policies apply to Copilot interactions?
Copilot interaction data is subject to the same Microsoft Purview retention policies as the underlying M365 service:
| Copilot Context | Retention Governed By | Policy Location |
|---|---|---|
| Microsoft 365 Copilot Chat | Exchange Online Copilot retention policy | Purview > Data lifecycle management > Retention policies > Copilot |
| Teams chat | Teams chat retention policy | Purview > Data lifecycle management > Retention policies > Teams |
| Teams meetings | Teams meeting/transcript retention policy | Purview > Data lifecycle management > Retention policies > Teams |
| Outlook | Exchange Online retention policy | Purview > Data lifecycle management > Retention policies > Exchange |
| Copilot Pages | SharePoint retention policy | Purview > Data lifecycle management > Retention policies > All SharePoint Sites |
| Audit logs | Audit log retention policy | Purview > Audit > Audit retention policies |
FSI-specific considerations:
- FINRA 4511 requires certain records for 3-6 years
- SEC 17a-4 requires 3-6 years depending on record type
- Configure Purview retention policies with "Retain" actions for the required period
- Use "Retain and then delete" for data minimization after the retention period expires
- Audit (Premium) supports retention of audit log data for up to 10 years
Relevant controls: Control 3.2 (Retention Policies), Control 3.11 (Record Keeping)
Governance Features
How does DSPM for AI relate to Copilot governance?
DSPM for AI (Data Security Posture Management for AI) is a Microsoft Purview capability specifically designed to help organizations govern AI usage including Microsoft 365 Copilot. It provides:
-
Visibility: Dashboard showing how Copilot is being used across the organization, including interaction volume by app, user group, and time period.
-
Data risk assessment: Identifies when Copilot interactions involve sensitive data (based on sensitivity labels and sensitive information types), helping security teams understand data exposure patterns.
-
Policy recommendations: Suggests DLP policies, sensitivity labels, and other controls to improve Copilot data security posture.
-
Compliance monitoring: Ongoing monitoring that helps detect anomalous patterns in Copilot usage that may indicate data handling concerns.
DSPM for AI complements (does not replace) the broader governance controls in this framework. Think of it as a monitoring and assessment layer that helps you measure the effectiveness of your DLP, labeling, and access control implementations.
Requirements: Microsoft Purview Suite (formerly E5 Compliance) + Microsoft 365 Copilot license.
Relevant controls: Control 1.2 (SharePoint Oversharing Detection), Control 3.9 (AI Disclosure and Transparency)
What is the difference between FSI-CopilotGov and FSI-AgentGov?
These are companion frameworks that address different aspects of Microsoft 365 AI governance:
| Aspect | FSI-CopilotGov (this framework) | FSI-AgentGov |
|---|---|---|
| Subject | Microsoft 365 Copilot — the AI assistant embedded in M365 apps | Copilot Studio, Agent Builder, SharePoint agents, and custom AI agents |
| Scope | In-app AI assistance across 23+ M365 surfaces | Custom and declarative agent development, deployment, and lifecycle |
| Governance model | Baseline / Recommended / Regulated levels | Zone 1 (Personal) / Zone 2 (Team) / Zone 3 (Enterprise) agents |
| Key concepts | Semantic Index, Graph grounding, discovery amplification, label inheritance | Managed Environments, DLP connector policies, agent lifecycle, agent inventory |
| Controls | 63 controls across 4 lifecycle pillars | 71 controls across 4 governance domains (FSI-AgentGov) |
| Playbooks | 268 implementation playbooks | 284 implementation playbooks (FSI-AgentGov) |
| Repository | FSI-CopilotGov | FSI-AgentGov |
Overlap: Both frameworks address sensitivity labels, audit logging, DLP, and Conditional Access — but each provides guidance tailored to its specific scope. The frameworks are standalone with no cross-repo dependencies.
Which do you need?
- Deploying M365 Copilot (Word, Teams, Outlook, Microsoft 365 Copilot Chat, etc.)? Start with FSI-CopilotGov.
- Building custom agents in Copilot Studio or Agent Builder? Start with FSI-AgentGov.
- Doing both? Use both frameworks independently — they are designed to complement each other.
Common Concerns
Will Copilot generate inaccurate financial information?
Copilot, like all large language models, can generate inaccurate or "hallucinated" content. This is a known characteristic of LLMs, not a bug. The risk is particularly relevant in FSI contexts where inaccurate information in client communications, regulatory filings, or financial calculations could have material consequences.
Mitigations in this framework:
- Communication Compliance (Control 3.4): Flags Copilot-assisted communications for supervisory review before they reach clients
- FINRA 2210 review process (Control 3.5): Principal pre-approval requirements for Copilot-drafted retail communications
- Model Risk Management (Control 3.8): Documents Copilot in the model inventory with risk assessment and validation procedures
- Training and Awareness (Control 1.12): Educates users that Copilot output must be reviewed and validated before use in any business context
Key principle: Copilot is an assistant, not an autonomous agent. Users remain responsible for reviewing and validating all Copilot-generated content before using it in business contexts.
Can Copilot access data across information barriers?
No. Microsoft 365 Copilot respects Information Barrier (IB) policies configured in Microsoft Purview. If a user is in an IB segment that is blocked from communicating with another segment, Copilot will not surface content from the blocked segment's SharePoint sites, Teams channels, or other M365 data.
Important caveats:
- IB enforcement in Copilot depends on IB policies being properly configured and applied across all relevant M365 services (Teams, SharePoint, OneDrive)
- IB enforcement for Copilot extensibility features (plugins, Graph connectors, declarative agents) may have limitations — see the Copilot Surfaces Matrix for details
- IB policies should be tested with Copilot scenarios before relying on them for MNPI compliance
Relevant controls: Control 2.4 (Information Barriers for Copilot)
How do sensitivity labels interact with Copilot?
Sensitivity labels interact with Copilot in three key ways:
-
Label inheritance: When Copilot generates content based on one or more labeled source documents, the output inherits the highest sensitivity label. If Copilot references both an "Internal" document and a "Highly Confidential" document, the generated content receives the "Highly Confidential" label.
-
Encryption enforcement: If a sensitivity label includes encryption settings, Copilot respects those settings. Users who do not have decryption rights cannot use Copilot to access the encrypted content.
-
DLP integration: DLP policies can use sensitivity labels as conditions. For example, a DLP policy can block Copilot from processing "Highly Confidential" content in certain contexts.
FSI best practice: Implement mandatory labeling for at least Word, Excel, PowerPoint, and Outlook so that all content Copilot may reference has a classification. This provides a foundation for both label inheritance and DLP policy enforcement.
Relevant controls: Control 2.2 (Sensitivity Labels and Label Inheritance), Control 2.1 (DLP Policies)
Is Copilot compliant with my regulatory requirements?
Copilot is a technology tool — it is neither compliant nor non-compliant on its own. Your organization's configuration, policies, and governance practices determine whether your use of Copilot supports compliance with applicable regulations.
This framework provides controls and implementation guidance that help FSI organizations configure Copilot in ways that support compliance with FINRA, SEC, SOX, GLBA, OCC, CFPB, and FFIEC requirements. However:
- No single tool or configuration can guarantee regulatory compliance
- Regulatory requirements must be interpreted in the context of your specific business activities
- Implementation must be validated by your compliance and legal teams
- Ongoing monitoring and governance are required — compliance is not a one-time configuration
Starting point: Use the Regulatory Mappings to identify which controls are relevant to your regulatory obligations, then use the Implementation Checklist to track your progress.
What happens if Microsoft changes Copilot features?
Microsoft regularly updates Microsoft 365 Copilot with new features, changed behaviors, and updated admin controls. This is a governance risk that must be actively managed.
How to stay informed:
- Monitor the M365 Message Center (M365 Admin Center > Health > Message center) for Copilot-related announcements
- Subscribe to the Microsoft 365 Roadmap (https://www.microsoft.com/en-us/microsoft-365/roadmap) for upcoming features
- Review Microsoft Purview release notes for changes to compliance capabilities
- Participate in Microsoft FSI community calls for industry-specific guidance
Governance response: Control 4.12 (Change Management for Copilot Updates) provides a structured process for evaluating, testing, and approving Copilot feature changes in your environment.
Key risk: New Copilot features often default to "On." When Microsoft releases a new capability, it may be available to users before your governance team has evaluated it. The governance calendar (Control 4.12) should include regular review of Message Center notifications for Copilot-related changes.
Emerging AI Laws
How do state AI laws affect Copilot deployments in financial services?
Several US states have enacted or are advancing AI-specific legislation that may apply to FSI organizations using Microsoft 365 Copilot, particularly when Copilot outputs inform consequential decisions such as lending, underwriting, employment, or client recommendations.
Key state laws to monitor (as of mid-2026):
- Colorado AI Act (SB 24-205, amended SB 25B-004) — effective June 30, 2026. Requires risk management programs, impact assessments, and consumer notification for deployers of high-risk AI systems. See Colorado AI Act Readiness.
- Texas Responsible AI Governance Act (HB 1709) — effective September 1, 2025. Requires impact assessments and governance frameworks for high-risk AI deployments.
- Illinois AI Video Interview Act (820 ILCS 42) — in effect since 2020. Applies if Copilot assists with video interview analysis.
- Illinois HB 3773 (Employee AI Act) — enacted, effective January 1, 2026. Requires notice to employees and applicants when AI is used in employment decisions; mandates that employers using AI for employment purposes must test for disparate impact.
- California AB 2013 (AI Transparency Act) — enacted September 2024. Requires transparency disclosures for AI-generated content; SB 1047 (the broader Safe and Secure Innovation for Frontier AI Models Act) was vetoed by the governor in September 2024.
- New York City Local Law 144 — in effect since July 2023. Requires annual bias audits and public disclosure for automated employment decision tools used in New York City hiring.
- Utah Artificial Intelligence Policy Act (SB 149) — in effect since May 2024. Requires disclosure when AI is used in regulated consumer transactions.
Multi-state FSI organizations should map which state AI laws apply to each Copilot use case and implement a unified compliance approach that satisfies the most stringent requirements. See the State AI Laws Compliance Matrix for a detailed comparison.
Relevant controls: Control 3.8 (Model Risk Management), Control 3.9 (AI Disclosure and Transparency), Control 3.12 (Evidence Collection)
Does the EU AI Act apply to US financial institutions using Copilot?
The EU AI Act may have extraterritorial reach for US FSI organizations in specific scenarios:
- EU customers or employees: If a US institution uses Copilot to process data about EU data subjects (customers or employees located in the EU), certain transparency and risk-management obligations may apply.
- EU operations or subsidiaries: US-headquartered organizations with EU-regulated subsidiaries are directly subject to the EU AI Act through those entities.
- Output deployed in the EU: If Copilot-generated content (reports, analyses, recommendations) is used to make decisions affecting individuals in the EU, the Act's requirements for high-risk AI systems may be triggered.
While this framework focuses on US financial regulation, organizations with EU exposure should coordinate with EU legal counsel. Microsoft Purview is expanding AI data lineage tracking capabilities in response to EU AI Act requirements; these capabilities may also benefit US FSI audit readiness.
For DORA (Digital Operational Resilience Act) considerations, see Solution 13 in the FSI-CopilotGov-Solutions companion repository.
Relevant controls: Control 3.8 (Model Risk Management), Control 2.7 (Data Residency and Cross-Border Data Flow)
What happened to California SB 1047 and similar vetoed AI proposals?
California SB 1047 (Safe and Secure Innovation for Frontier AI Models Act) was vetoed by Governor Newsom in September 2024. The bill would have imposed safety testing and incident reporting obligations on developers of large AI models. While SB 1047 does not apply, California has enacted other AI-related legislation — notably AB 2013 (AI Transparency Act), which requires transparency disclosures for AI-generated content.
Other proposals have been introduced in multiple states (including New York's proposed AI accountability bills and similar measures in Connecticut, Maryland, and Virginia) but have not yet been enacted. FSI organizations should track these developments through their regulatory monitoring processes.
The State AI Laws Compliance Matrix tracks both enacted laws and significant vetoed or pending proposals.
Relevant controls: Control 3.9 (AI Disclosure and Transparency), Control 4.12 (Change Management — regulatory monitoring)
FSI Copilot Governance Framework v1.4.0 - April 2026