# Microsoft 365 Copilot Readiness Checklist

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

Microsoft 365 Copilot is switched on with a licence assignment, but a safe rollout is earned much earlier: in permissions, sensitivity labels, policies, and training. Copilot does not bypass your permissions. It respects them perfectly, and that is exactly the problem: it instantly surfaces everything each user technically has access to, including the finance site that was shared with "Everyone except external users" years ago and forgotten.

This checklist takes an IT, security, or governance team through seven readiness phases, from licensing prerequisites to post-deployment review, with formal go/no-go gates before the pilot and before broad rollout. Work through it and you will know, with evidence, whether your organisation is ready to enable Copilot.

---

## How to Use

1. Assign an overall owner (typically the IT director or CISO) and an executive sponsor for the rollout.
2. Work through Phases 1 to 5 in order. Phases may overlap in practice, but every item must be closed before the gate that depends on it.
3. For each item, tick the Done column, record where the evidence lives, and name an owner. Evidence is what makes this checklist audit-ready rather than a to-do list.
4. Hold a formal go/no-go review at Gate A (pilot launch) and Gate B (broad rollout). A single No-go pauses the launch until it is resolved or consciously waived in writing.
5. Phases 6 and 7 are recurring: run them on the stated cadence for as long as Copilot is deployed.
6. Copilot admin controls change frequently. Facts in this checklist were verified against Microsoft documentation in July 2026; confirm specifics on Microsoft Learn before relying on them.

---

## Roles and Responsibilities

Assign these roles before starting Phase 1. One person can hold more than one role in smaller organisations, but the rollout owner and the security reviewer should not be the same person.

| Role | Typical holder | Responsibility in this checklist |
|------|----------------|----------------------------------|
| Executive sponsor | CIO / COO | Owns the business case; chairs Gate A and Gate B reviews |
| Rollout owner | IT director / M365 lead | Drives the checklist day to day; owns Phases 1, 4, and 6 |
| Security reviewer | CISO / security lead | Owns Phases 2 and 3; holds veto at both gates |
| Data owners | Business unit leads | Sign off remediation decisions for their sites (item 2.12) |
| Privacy / legal | DPO / general counsel | Owns items 3.3, 3.4, 5.6; reviews the AUP amendment |
| Enablement lead | L&D / change manager | Owns Phase 5 training, communications, and acknowledgments |
| Helpdesk lead | Support manager | Owns the support model criterion at Gate B (B5) |

---

## Where Rollouts Usually Stall

Five patterns account for most delayed or abandoned Copilot deployments. Each maps to a phase of this checklist.

1. **The oversharing discovery.** A pilot user asks a routine question and receives content they should never have seen. The rollout freezes while permissions are audited under pressure. Prevented by Phase 2, done before enablement instead of after the incident.
2. **The invisible licence blockers.** Users are licensed but see no Copilot because their apps sit on the Semi-Annual Enterprise Channel, their mailbox is on-premises, or a proxy blocks WebSocket connections. Prevented by Phase 1.
3. **The ungoverned transcript.** Legal discovers months of Copilot prompts and responses with no retention decision, no audit trail review, and no eDiscovery test. Prevented by Phase 3.
4. **The enthusiast pilot.** A pilot of IT volunteers reports success, then the finance rollout surfaces every problem the pilot was never exposed to. Prevented by Phase 4 cohort design.
5. **The silent policy.** Users were never told what Copilot may and may not be used for, so each invents their own rules. Prevented by Phase 5.

---

## Phase 1: Prerequisites and Licensing

Confirm the technical floor first, so governance effort is not wasted on a deployment that cannot proceed.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 1.1 | Confirm every planned Copilot user holds an eligible base subscription (Microsoft 365 E3/E5/F1/F3, Business Basic/Standard/Premium, Office 365 E1/E3/E5/F3, or an eligible education or Teams plan) | Microsoft 365 Copilot is an add-on licence and cannot be assigned without a qualifying base plan | Licence report from the Microsoft 365 admin center | [OWNER] |
| [ ] | 1.2 | Secure budget approval for Copilot add-on licences (list price USD 30 per user per month at the time of writing; confirm current local pricing and commitment terms) | Copilot is one of the larger per-seat line items in the tenant; an unplanned true-up stalls rollouts mid-flight | Signed budget approval | [OWNER] |
| [ ] | 1.3 | Verify every planned user's primary mailbox is in Exchange Online | Mailbox grounding (email, calendar, contacts) is not supported for on-premises or hybrid mailboxes | Mailbox location report | [OWNER] |
| [ ] | 1.4 | Confirm all users authenticate with a Microsoft Entra ID account | Copilot requires Entra ID; unmanaged or legacy accounts cannot use it | Identity audit extract | [OWNER] |
| [ ] | 1.5 | Confirm OneDrive is provisioned for all planned users | Several Copilot experiences depend on a provisioned OneDrive to reference and save content | OneDrive provisioning report | [OWNER] |
| [ ] | 1.6 | Move Microsoft 365 Apps to Current Channel or Monthly Enterprise Channel for Copilot users | Copilot features are not delivered on the Semi-Annual Enterprise Channel; users on it will simply not see Copilot | Update channel policy export | [OWNER] |
| [ ] | 1.7 | Verify required network endpoints and WebSocket (WSS) connections are not blocked by proxies or firewalls | Copilot fails quietly behind restrictive proxies, generating support tickets that look like licensing faults | Network test results | [OWNER] |

---

## Phase 2: Data Governance Before Enablement

This is the phase that decides whether your rollout succeeds. Most stalled Copilot deployments stall here: the first pilot user asks an innocent question and gets back salary data, board papers, or an M&A folder that was always technically accessible and practically invisible. Fix permission sprawl before Copilot makes it searchable in plain English.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 2.1 | Run a tenant-wide permission and oversharing audit using SharePoint Advanced Management data access governance reports (SharePoint Advanced Management is included with the Microsoft 365 Copilot licence) | Copilot surfaces everything a user can technically reach, not what they were meant to reach; you cannot fix what you have not measured | Data access governance report, dated | [OWNER] |
| [ ] | 2.2 | Identify and remediate sites exposed to "Everyone except external users" or other organisation-wide groups | These sites are invisible in daily work but fully visible to Copilot retrieval | Remediation log per site | [OWNER] |
| [ ] | 2.3 | Clean up sharing-link hygiene: expire stale "Anyone" and organisation-wide links, set the default link type to "Specific people", and set link expiry policies | Old links grant standing access that Copilot honours long after everyone has forgotten they exist | Tenant sharing settings export | [OWNER] |
| [ ] | 2.4 | Review Microsoft Purview Data Security Posture Management (DSPM) oversharing assessments; the default assessment runs weekly across the top 100 SharePoint sites by usage | Gives a recurring, prioritised view of where sensitive data meets broad access | DSPM assessment report | [OWNER] |
| [ ] | 2.5 | Confirm the sensitivity label taxonomy is published and covers your most sensitive data categories (for example Confidential and Restricted) | Labels are the hook that Copilot-aware DLP and encryption controls attach to; unlabelled data is unprotectable by these controls | Label policy export | [OWNER] |
| [ ] | 2.6 | Auto-label sensitive legacy content at rest using Purview auto-labeling policies driven by sensitive information types | Manual labelling never catches up with years of accumulated files; automation closes the backlog | Auto-labeling policy and match report | [OWNER] |
| [ ] | 2.7 | Create and test a Purview DLP policy using the Microsoft 365 Copilot policy location so Copilot will not process or summarise content carrying your most sensitive labels | This is the direct "keep Copilot away from this" control; it is label-based, so items 2.5 and 2.6 must land first | DLP policy config plus test result | [OWNER] |
| [ ] | 2.8 | Verify that encrypted, labelled files behave as intended in Copilot: users without sufficient usage rights should not receive summaries of that content | Confirms encryption and usage rights actually hold under Copilot retrieval, not just in theory | Test script and screenshots | [OWNER] |
| [ ] | 2.9 | Decide, site by site, where to apply Restricted Content Discovery (RCD) to hide high-risk sites from Copilot and organisation-wide search while remediation is under way | RCD buys time but is temporary and not a security boundary. Note: Restricted SharePoint Search is retiring and new enablement is blocked from 31 July 2026; use RCD instead | RCD decision record per site | [OWNER] |
| [ ] | 2.10 | Apply Restricted Access Control to sites that should only ever be open to a named group | Enforces a hard ceiling on site access regardless of item-level sharing mistakes | Restricted access control config | [OWNER] |
| [ ] | 2.11 | Archive or delete redundant, obsolete, and trivial content: run ownerless-site policies and inactive-site archiving | Stale drafts and superseded policies degrade Copilot answer quality and widen the exposure surface | Site lifecycle report | [OWNER] |
| [ ] | 2.12 | Record governance decisions, residual risks, and data-owner sign-off for every remediated or restricted site | Gate reviews and future audits need a written trail, not a memory | Signed decision register | [OWNER] |

---

## Phase 3: Security Configuration

Configure logging, retention, and the controls that decide what Copilot can reach beyond your tenant.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 3.1 | Confirm Microsoft Purview Audit is enabled and verify that Copilot interaction events appear in the audit log by running a test interaction | Every prompt and response generates an audit record only if auditing is healthy; you cannot investigate what you did not log | Audit log extract showing the test event | [OWNER] |
| [ ] | 3.2 | Set audit retention to match your records schedule (Audit Standard keeps Copilot events for 180 days; Audit Premium keeps them 365 days by default, extendable up to 10 years) | Investigations and regulator requests often arrive after the default window has closed | Audit retention policy config | [OWNER] |
| [ ] | 3.3 | Apply a Purview retention policy to Copilot interactions (prompts and responses are stored in hidden folders in user mailboxes) and set deliberate retain or delete periods | Unmanaged Copilot transcripts accumulate indefinitely and become a liability in litigation and subject access requests | Retention policy config | [OWNER] |
| [ ] | 3.4 | Confirm eDiscovery can locate and export Copilot interactions; run a test case | Legal holds and investigations will need Copilot conversations; test the path before you need it | eDiscovery test case results | [OWNER] |
| [ ] | 3.5 | Set the web grounding posture deliberately: configure the "Allow web search in Copilot" policy (on, off, or on for defined groups) and document the rationale | Web grounding sends generated search queries outside the Microsoft 365 service boundary to Bing; that is a decision to make, not a default to inherit | Cloud Policy config plus decision record | [OWNER] |
| [ ] | 3.6 | If web grounding stays on, evaluate domain exclusions for web grounding and tell users about the Web content toggle | Narrows web grounding to sources you trust and gives users a visible control | Domain exclusion list | [OWNER] |
| [ ] | 3.7 | Review the optional connected experiences policy setting and confirm it matches your intent | If optional connected experiences are disabled, dependent Copilot features such as web search silently disappear, generating "Copilot is broken" tickets | Privacy policy settings export | [OWNER] |
| [ ] | 3.8 | Set the agent and extensibility baseline in the Copilot Control System (Microsoft 365 admin center): who may install, build, and share agents; block unreviewed agents and connectors | Agents extend Copilot's reach into new data and actions; ungoverned agents recreate the shadow AI problem inside your own tenant | Agent policy export | [OWNER] |
| [ ] | 3.9 | Feed Copilot audit events into your SIEM or monitoring platform and define alert scenarios (unusual interaction volume, DLP policy hits, spikes in access to sensitive sites) | Detection needs to be running before the pilot starts, not designed after the first incident | SIEM ingestion config and alert rules | [OWNER] |

---

## Phase 4: Pilot Design

A pilot exists to test governance and value under real conditions, not to reward enthusiasts.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 4.1 | Select a pilot cohort of roughly 50 to 300 users across real business functions (finance, HR, legal, sales, operations), weighted towards heavy document and email users | An IT-only pilot validates enthusiasm, not governance; the risky data lives in business teams | Cohort list with role mix | [OWNER] |
| [ ] | 4.2 | Exclude, or individually review, highly privileged accounts (tenant admins, service accounts, executives with broad delegated access) from the first wave | The more a user can access, the more any remaining oversharing gap is amplified through their Copilot results | Privileged account review record | [OWNER] |
| [ ] | 4.3 | Define success metrics and targets before launch: adoption (weekly active Copilot users), value (self-reported time saved, output quality), and safety (DLP hits, oversharing alerts, incidents) | Metrics defined after the fact always flatter the result | Metrics definition document | [OWNER] |
| [ ] | 4.4 | Capture a pre-pilot baseline for each metric | Without a baseline, the Gate B decision becomes opinion | Baseline measurement record | [OWNER] |
| [ ] | 4.5 | Stand up the feedback loop: a dedicated channel, a short recurring survey, office hours, and a named owner who triages weekly | Pilot feedback that nobody owns is pilot feedback that nobody reads | Feedback channel and triage log | [OWNER] |
| [ ] | 4.6 | Set the pilot duration and exit criteria in writing (commonly 4 to 8 weeks) | Open-ended pilots drift; a fixed window forces the go/no-go conversation | Pilot charter | [OWNER] |
| [ ] | 4.7 | Prepare the containment plan: exactly how you would pull a licence, restrict a site, or disable a feature within hours if the pilot surfaces an incident | Speed of containment, not absence of incidents, is what protects the rollout | Containment runbook | [OWNER] |

### Pilot Metrics Worksheet

Complete this worksheet as part of items 4.3 and 4.4. The example rows show the level of specificity that makes Gate B decidable.

| Metric | Category | Baseline | Target | Source |
|--------|----------|----------|--------|--------|
| Weekly active Copilot users (% of cohort) | Adoption | n/a | [e.g. 60% by week 4] | Copilot Dashboard |
| Self-reported hours saved per user per week | Value | 0 | [e.g. 2 hours] | Fortnightly survey |
| Users who would be disappointed to lose Copilot | Value | n/a | [e.g. 50%] | Exit survey |
| DLP policy hits from Copilot interactions | Safety | 0 | [Triage 100% within 2 business days] | Purview DLP reports |
| Oversharing alerts on pilot-touched sites | Safety | [From Phase 2 audit] | [No new high-risk sites] | DSPM / SAM reports |
| Copilot-related security incidents (P1/P2) | Safety | 0 | [Zero unresolved at Gate B] | Incident register |
| [Add your own] | | | | |

---

## Phase 5: Policy and People

Controls stop working where people have not been told what good looks like.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 5.1 | Amend the AI acceptable use policy to name Microsoft 365 Copilot explicitly: approved scope, prohibited uses, data handling rules, and the duty to verify outputs | A generic AI policy that never mentions Copilot gives users no answer to "am I allowed to use this for that?" | Updated AUP, version-controlled | [OWNER] |
| [ ] | 5.2 | Publish acceptable-prompt guidance with worked examples: what is fine, what needs care (colleague personal data, undisclosed financials, legal matters), what is prohibited | Users follow examples far more reliably than principles | Published guidance page | [OWNER] |
| [ ] | 5.3 | Deliver training before licence assignment: Copilot basics plus data classification, labels, and how to report a concern | Training after enablement means the riskiest usage happens in the least informed weeks | Training completion report | [OWNER] |
| [ ] | 5.4 | Capture a signed training and policy acknowledgment for every user before their licence is assigned | Acknowledgment converts "we told them" into evidence | Acknowledgment register | [OWNER] |
| [ ] | 5.5 | Brief the managers of pilot teams on expectations, feedback duties, and the escalation path | Managers set the local norms that decide whether policy is followed | Briefing record | [OWNER] |
| [ ] | 5.6 | Update privacy notices and consult employee representatives or works councils where required by local law | In several jurisdictions, deploying AI that processes employee data without consultation is itself a compliance failure | Consultation record | [OWNER] |
| [ ] | 5.7 | Set the human oversight rule in writing: Copilot output is a draft, and a named person remains accountable for anything that leaves the organisation | Prevents the quiet slide from "Copilot helped" to "Copilot decided" | Policy clause reference | [OWNER] |
| [ ] | 5.8 | Run the launch communication plan: announcement, FAQ, where to get help, and how to report a concern | A rollout users hear about from rumour starts with distrust it never recovers from | Comms pack | [OWNER] |

---

## Go/No-Go Gate A: Pilot Launch

Hold a formal review with the executive sponsor, IT, security, and legal. Every criterion must be Go. Record the decision.

| # | Gate criterion | Standard to meet | Go / No-go | Evidence |
|---|----------------|------------------|------------|----------|
| A1 | Prerequisites | All Phase 1 items closed for every pilot user | [GO / NO-GO] | [LINK] |
| A2 | Oversharing remediation | Phase 2 audit complete; every high-risk site remediated or restricted (RCD or Restricted Access Control) | [GO / NO-GO] | [LINK] |
| A3 | Labels and DLP | Sensitivity labels published; the Copilot DLP policy active and verified with a test file | [GO / NO-GO] | [LINK] |
| A4 | Audit and retention | Test Copilot interaction visible in the audit log; retention policy applied | [GO / NO-GO] | [LINK] |
| A5 | Policy and training | AUP amended; all pilot users trained with signed acknowledgments | [GO / NO-GO] | [LINK] |
| A6 | Metrics and feedback | Success metrics, baseline, and feedback loop in place | [GO / NO-GO] | [LINK] |
| A7 | Incident readiness | Containment runbook documented; incident contact and on-call owner named | [GO / NO-GO] | [LINK] |

**Gate A decision:** [GO / NO-GO] · **Date:** [DATE] · **Approved by:** [NAME / ROLE]

### Worked example: a No-go done well

A 2,000-person professional services firm reaches Gate A with A1, A3, A4, A5, A6, and A7 at Go. A2 is No-go: the data access governance report still shows 14 sites open to "Everyone except external users", including two HR sites. The review does not debate whether the pilot cohort would "probably not" query HR content. It records a No-go, applies Restricted Content Discovery to the 14 sites the same week, remediates permissions on the two HR sites first, and reconvenes Gate A twelve days later with evidence attached. The pilot starts late and clean. The alternative version of this story, where the gate is waved through, usually ends with the pilot suspended by an incident in week two, a longer delay, and a harder conversation.

> Run the pilot for the agreed window. Triage feedback weekly, log every DLP hit and oversharing alert, and keep the containment runbook within reach.

---

## Go/No-Go Gate B: Broad Rollout

Repeat the formal review at the end of the pilot. Every criterion must be Go before licences scale beyond the pilot cohort.

| # | Gate criterion | Standard to meet | Go / No-go | Evidence |
|---|----------------|------------------|------------|----------|
| B1 | Pilot outcomes | Success metrics met, or shortfalls consciously accepted in writing with rationale | [GO / NO-GO] | [LINK] |
| B2 | Security record | No unresolved Copilot-related P1/P2 incidents; all DLP and oversharing alerts triaged to closure | [GO / NO-GO] | [LINK] |
| B3 | Governance posture | Latest DSPM oversharing assessment reviewed; no new high-risk sites left unremediated or unrestricted | [GO / NO-GO] | [LINK] |
| B4 | Scaled enablement | Training and acknowledgment scheduled for every rollout wave | [GO / NO-GO] | [LINK] |
| B5 | Support model | Helpdesk briefed; FAQ live; prompt guidance published | [GO / NO-GO] | [LINK] |
| B6 | Budget and licensing | Licences and budget approved for the full rollout population | [GO / NO-GO] | [LINK] |
| B7 | Agent posture | Agent and extensibility controls reviewed against pilot learnings | [GO / NO-GO] | [LINK] |

**Gate B decision:** [GO / NO-GO] · **Date:** [DATE] · **Approved by:** [NAME / ROLE]

---

## Phase 6: Rollout and Monitoring

Broad rollout is a sequence of small launches, each with the same discipline as the pilot.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 6.1 | Plan staged waves (by department or region), each with a checkpoint review before the next wave begins | Staging preserves the option to pause with a limited blast radius | Wave plan with dates | [OWNER] |
| [ ] | 6.2 | Repeat the data-access review for each wave's user population before assigning licences | Every new cohort brings new permission edge cases the pilot never touched | Per-wave access review record | [OWNER] |
| [ ] | 6.3 | Monitor adoption through the Copilot Dashboard and usage reports; flag stalled or dormant licences for coaching or reclamation | Paying for unused seats is the quietest way a Copilot business case dies | Monthly usage report | [OWNER] |
| [ ] | 6.4 | Keep oversharing monitoring running: weekly DSPM assessments, SharePoint Advanced Management reports, and DLP hit review | Permission sprawl regrows continuously; a one-off cleanup decays within months | Monitoring cadence log | [OWNER] |
| [ ] | 6.5 | Review Copilot audit activity on a defined cadence for anomalies (odd hours, unusual volumes, repeated probing of sensitive topics) | Insider misuse of Copilot looks like normal usage until someone actually reads the logs | Audit review notes | [OWNER] |
| [ ] | 6.6 | Review newly created or shared agents against the approval baseline every month | Agent sprawl is the next oversharing problem, arriving while you are still fixing the first one | Agent inventory review | [OWNER] |
| [ ] | 6.7 | Keep the incident path warm: named contact, tested containment steps, and a link to your AI incident response playbook | An untested escalation path fails precisely when it is needed | Tabletop exercise record | [OWNER] |
| [ ] | 6.8 | Report monthly to the AI governance committee: adoption, incidents, exceptions, and remediation progress | Sustained executive visibility is what keeps governance funded after the launch excitement fades | Monthly report | [OWNER] |

---

## Phase 7: Post-Deployment Review

Run the first review 90 days after broad rollout, then at least annually.

| Done | # | Checklist item | Why it matters | Evidence | Owner |
|------|---|----------------|----------------|----------|-------|
| [ ] | 7.1 | Hold a formal review covering adoption, incidents, value delivered, and cost against the original business case | Closes the loop with the executive sponsor and grounds the next investment decision | Review minutes | [OWNER] |
| [ ] | 7.2 | Re-run the permission and oversharing assessment and compare against the pre-deployment baseline | Proves whether governance is holding or eroding under real usage | Comparison report | [OWNER] |
| [ ] | 7.3 | Tune sensitivity labels and DLP policies using real hit data: false positives, gaps, and newly sensitive locations | Policies tuned on live traffic protect better and annoy less | Policy change log | [OWNER] |
| [ ] | 7.4 | Retire temporary restrictions (RCD) from sites whose permissions are now verified | Leaving temporary controls in place degrades Copilot answers and hides unfinished remediation | RCD retirement record | [OWNER] |
| [ ] | 7.5 | Refresh training and prompt guidance with lessons from real incidents and real wins | Guidance grounded in your own examples outperforms generic content | Updated training pack | [OWNER] |
| [ ] | 7.6 | Present outcomes and next-step decisions (agents, extensibility, additional workloads) to the executive sponsor | Copilot governance is a programme, not a project; the next phase needs an explicit mandate | Decision record | [OWNER] |

---

## Exception and Waiver Register

Record every consciously accepted gap here. An empty register at Gate B is either excellent preparation or a sign that gaps are being absorbed informally; the review should confirm which.

| # | Item waived | Risk accepted | Compensating control | Approved by | Review date |
|---|-------------|---------------|----------------------|-------------|-------------|
| 1 | [e.g. 2.11 stale-content archive incomplete for one region] | [Outdated content may surface in answers] | [RCD applied to affected sites until archive completes] | [NAME / ROLE] | [DATE] |
| 2 | | | | | |
| 3 | | | | | |

---

## Reference: Key Microsoft Controls for Copilot Readiness

| Control | Where to configure | What it does |
|---------|--------------------|--------------|
| DLP policy, Microsoft 365 Copilot location | Microsoft Purview portal | Prevents Copilot from processing or summarising content carrying selected sensitivity labels |
| Restricted Content Discovery (RCD) | SharePoint Advanced Management | Hides a site's content from organisation-wide search and Copilot while permissions are fixed (temporary, not a security boundary) |
| Restricted Access Control | SharePoint Advanced Management | Restricts site access to a named group regardless of item-level sharing |
| Data access governance reports | SharePoint Advanced Management | Finds sites with broad access (such as "Everyone except external users") and heavy sharing activity |
| Oversharing risk assessments | Microsoft Purview DSPM | Recurring weekly assessment of the top 100 SharePoint sites by usage, flagging oversharing risk |
| Copilot interaction auditing | Microsoft Purview Audit | Records every Copilot interaction; 180 days on Audit Standard, 365 days on Audit Premium (extendable to 10 years) |
| Retention for Copilot interactions | Microsoft Purview Data Lifecycle Management | Retains or deletes stored Copilot prompts and responses held in user mailboxes |
| Allow web search in Copilot | Cloud Policy service / Copilot Control System | Turns web grounding on or off per group; domain exclusions narrow which web sources are used |
| Agent management | Copilot Control System, Microsoft 365 admin center | Approves, blocks, and assigns agents and connectors across the tenant |

---

*Product behaviour, licensing, and admin controls described here were verified against Microsoft documentation in July 2026 and change frequently. Confirm specifics on Microsoft Learn before relying on them. This checklist is general guidance, not legal advice.*

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*