Organizations that adopt Microsoft Copilot must maintain compliance with ISO 27001, the international standard for information security management. The Statement of Applicability is a core document that lists which controls from Annex A apply to your system and how each control is implemented. Without a clear mapping, auditors cannot verify that Copilot meets the same security requirements as the rest of your Microsoft 365 environment. This article explains how to map Copilot-specific capabilities and data flows to the ISO 27001 Annex A controls, and it provides a reference table you can adapt for your own Statement of Applicability.
Key Takeaways: Mapping Copilot to ISO 27001 Controls
- ISO 27001 Annex A.8 — Asset management: Copilot processes data from Microsoft Graph, SharePoint, and Exchange; each data source must be inventoried and classified.
- ISO 27001 Annex A.9 — Access control: Copilot inherits user permissions from Microsoft Entra ID; enforce least privilege and Conditional Access policies.
- ISO 27001 Annex A.12 — Operations security: Copilot logs are available in the Microsoft 365 Purview compliance portal for monitoring and audit.
Understanding the ISO 27001 Statement of Applicability for Copilot
The ISO 27001 Statement of Applicability is a formal document that lists all controls from Annex A and states whether each control is applicable to your organization. For each applicable control, the SoA describes how the control is implemented and references the relevant policies or technical measures. When you add Microsoft Copilot to your Microsoft 365 tenant, the SoA must be updated to reflect how Copilot interacts with each control.
Copilot does not introduce a separate security boundary. It operates within the existing Microsoft 365 service boundary and inherits the same compliance certifications, including ISO 27001, ISO 27017, and ISO 27018. However, the way Copilot processes data — generating responses by grounding prompts on your tenant data — creates new considerations for controls related to data classification, access review, and audit logging.
What the SoA Must Capture for Copilot
Your updated SoA should cover three Copilot-specific areas:
- Data sources: Copilot can access Microsoft Graph, SharePoint sites, OneDrive files, Exchange mailboxes, Teams chats, and Viva Topics. Each source must be listed in the SoA under asset inventory.
- Permission model: Copilot only returns data that the user already has permission to view. The SoA must reference the role-based access control policies in Microsoft Entra ID.
- Logging and monitoring: Copilot interactions are logged in the Microsoft 365 audit log. The SoA must specify which audit events are collected and how long they are retained.
Steps to Create or Update the Copilot SoA Mapping
- Review the current SoA for Microsoft 365
Locate your existing ISO 27001 Statement of Applicability. Identify controls that already reference Microsoft 365 services such as Exchange Online, SharePoint Online, and Microsoft Entra ID. These controls form the baseline for Copilot mapping. - Identify Copilot data flows
Document every data source Copilot can access in your tenant. Use the Microsoft 365 admin center to review which SharePoint sites, OneDrive folders, and Exchange mailboxes are indexed. List each source in the asset inventory section of the SoA under control A.8.1. - Map access controls to Copilot
Copilot enforces the same permissions as the underlying service. Under control A.9.2, describe how user access to Copilot is governed by Conditional Access policies and Entra ID roles. Include the policy that blocks Copilot from returning data the user cannot normally see. - Update logging and monitoring controls
Under control A.12.4, specify that Copilot audit events are captured in the Microsoft 365 audit log. List the specific audit record types: CopilotInteraction, AIPDocumentOperation, and FileAccessed. State the retention period — 90 days by default, up to 10 years with a retention license. - Document supplier management for Copilot
Under control A.15.1, reference Microsoft’s ISO 27001 certification for the Microsoft 365 service. Add a note that Copilot does not introduce a new subcontractor; it runs on the same infrastructure as the core Microsoft 365 services. - Review encryption controls
Under control A.10.1, confirm that Copilot data in transit and at rest uses the same encryption as Microsoft 365 — TLS 1.2 for transit and BitLocker or Azure Storage encryption at rest. No additional encryption configuration is required for Copilot. - Conduct a gap analysis
Compare your updated SoA against the full Annex A control list. For controls where Copilot does not introduce change — for example, physical security under A.11 — mark them as unchanged. For controls that Copilot affects, update the implementation description and reference the relevant Microsoft documentation.
Common Pitfalls When Mapping Copilot to ISO 27001
Assuming Copilot Needs Separate Access Controls
Some organizations create new access control policies specifically for Copilot. This is unnecessary. Copilot uses the same permission model as SharePoint, OneDrive, and Exchange. If a user cannot read a file in SharePoint, Copilot cannot return that file in a response. Update your existing access control documentation to note that Copilot inherits these permissions.
Overlooking Audit Log Coverage
The default Microsoft 365 audit log captures Copilot interactions, but not all organizations enable the logging of all Copilot event types. Go to the Microsoft 365 Purview compliance portal and verify that the following audit records are turned on: CopilotInteraction, AIPDocumentOperation, and FileAccessed. If these are disabled, Copilot usage will not appear in your audit reports, and your SoA will be inaccurate.
Forgetting Data Residency Commitments
ISO 27001 control A.8.2 requires data classification and location tracking. Copilot processes prompts in the same geographic region as your Microsoft 365 tenant. If your organization has data residency requirements, confirm that the Copilot data processing region matches your approved locations. Use the Microsoft 365 admin center to check the data location setting under Settings > Org settings > Data location.
Copilot Controls vs Standard Microsoft 365 Controls: Key Differences for the SoA
| Annex A Control | Standard Microsoft 365 | With Copilot |
|---|---|---|
| A.8.1 Inventory of assets | Lists Exchange, SharePoint, OneDrive, Teams | Adds Copilot as a processing service; data sources remain the same |
| A.9.2 User access provisioning | Entra ID roles and group membership | Same; no new roles for Copilot |
| A.12.4 Logging and monitoring | Mailbox audit, SharePoint audit, sign-in logs | Adds CopilotInteraction and AIPDocumentOperation event types |
| A.13.1 Network security | TLS 1.2, firewall rules | No change; Copilot uses the same network endpoints |
| A.15.1 Supplier security | Microsoft ISO 27001 certification | Same certification; no new supplier |
This table shows that Copilot does not require new controls. It extends existing controls by adding data sources, audit events, and a processing service. Your SoA should reflect these extensions rather than creating separate entries.
After updating the SoA, schedule a review with your internal audit team. Confirm that the control descriptions match the actual Copilot configuration in your tenant. Keep a copy of the Microsoft 365 ISO 27001 certificate — available in the Service Trust Portal — as evidence for control A.15.1. For ongoing compliance, set a quarterly task to check for Copilot feature updates that might affect data handling, such as new data source connections or changes to the permission model.