Microsoft Copilot Privacy Impact Assessment Template Guidance

Official documentation checked October 14, 2026.

A Copilot privacy impact assessment should describe the planned deployment and evaluate its risks, rather than repeat product assurances as verified facts. Whether a PIA or DPIA is legally required depends on the jurisdiction and processing. The structure below is an adaptable working template, not a Microsoft-issued form or an automatic compliance approval.

What a Privacy Impact Assessment Must Cover for Copilot

Begin by recording the screening decision and applicable law. For example, the UK ICO describes DPIA requirements for processing likely to create high risk and supplies a screening approach; its guidance currently notes review following the Data (Use and Access) Act. Use the ICO guidance for UK scope, not as a worldwide rule that all Copilot adoption requires a DPIA.

Define the intended tasks, affected people, personal information, sources, recipients, storage, processing, retention, safeguards, and potential harms. Microsoft’s privacy documentation and data architecture describe interaction records and multiple storage paths. Prompts and responses are not universally ephemeral.

The diagram should include conditional paths: user prompt to Copilot processing; permitted work sources or uploaded files; generated web queries where enabled; external agents or tools where used; response and stored interaction records. Show configured locations and retention separately. Do not draw an unconditional “Microsoft Graph only; no persistent data; no external services” flow.

Structure of the Copilot PIA Template

1. Assessment record: project owner, privacy reviewer, version, date, scope, applicable law, screening rationale, and approval status.
2. Purpose and necessity: concrete use cases, expected benefit, information needed, less intrusive alternatives, and prohibited uses.
3. People and information: employees, customers, students, or other groups; sensitive categories; source systems; uploads; prompts; outputs; transcripts; and metadata.
4. Product and account context: organizational Copilot or Copilot Chat, enabled app features, licenses, tenant, model-provider choices, agents, and tool credentials. Keep consumer accounts outside the approved scope unless separately assessed.
5. Data-flow map: collection, retrieval, processing, generated search queries, recipients, storage, and transfers. Mark unverified paths and the evidence needed to resolve them.
6. Access and safeguards: actual sharing, group membership, label usage rights, DLP, authentication, device policy, administrative roles, and negative access tests.
7. Retention and rights: effective interaction and audit retention, holds, deletion behavior, notices, applicable lawful basis or consent, access/correction routes, and human review where relevant.
8. Suppliers and locations: applicable contracts, processors and other recipients, geography commitments, exceptions, and external-service terms. Separate storage from inference and support access.
9. Risk and decision register: potential harm, likelihood, severity, existing measures, proposed measures, owner, evidence, residual risk, approval condition, and review trigger.
10. Incident and change management: escalation routes, evidence handling, applicable notification review, training, and events that require reassessment.

Completing the PIA Template: Step-by-Step Instructions

Follow a documented assessment process such as the ICO’s DPIA process, adapted to the applicable jurisdiction. The following is a practical evidence-gathering sequence:

1. Collect the approved project description, contracts, tenant inventory, intended account context, and current official product references. Identify assumptions explicitly.
2. Have administrators inspect relevant permissions, agents, provider choices, protection policies, and locations with read-only checks. A sensitive-information-type definition alone does not block processing; record the actual deployed rule and its scope.
3. Record interaction retention and holds using Purview retention guidance. Review audit separately through Copilot auditing documentation. Message identifiers or resource references in an activity record are not automatically the full text of every prompt, response, or underlying API call.
4. Use approved non-sensitive tests to validate important boundaries, including a user without source access. Do not enable broad permissions, disable protection, or export real personal information just to fill a template.
5. Assign mitigation owners and completion evidence. Obtain the organization’s required privacy, security, and legal reviews; consult the competent regulator before proceeding where applicable law requires it for unresolved high risk.

Common Mistakes When Completing the Copilot PIA

Copying an absolute residency promise: document the precise product, geography, feature, and provider commitment. Microsoft’s enterprise data protection page identifies separate web-query handling and current model-provider exceptions. A tenant boundary is not a guarantee that every operation happens in one country.

Confusing no training with no storage: organizational no-foundation-training commitments do not make interaction history, compliance copies, or audit records disappear. Check actual policies and deletion pathways.

Assuming every label blocks AI: record encryption rights and relevant DLP conditions, feature coverage, and test results. Do not assert that label names alone implement a universal exclusion.

Closing with unchecked residual risks: record open questions, the accountable decision, conditions, and review triggers. A six-month interval can be an organizational choice, not a universal legal deadline. Reassess when the purpose, information, recipients, providers, features, or processing changes.

Copilot PIA Data Flow Comparison

No tenant or PIA has been certified by this article. Complete the template with evidence from your deployment and the applicable legal framework; preserve unresolved facts rather than turning them into assurances.