The Copilot Readiness Checklist Nobody Runs

Every Microsoft partner has a Copilot readiness offering. Most involve a workshop, a maturity assessment, and a roadmap. Very few involve someone actually looking at your environment and telling you what’s broken.

So organisations go live with Copilot for M365 against environments nobody has evaluated for what Copilot actually does. Copilot reads your data and hands it to authenticated users in natural language. If the data environment has governance problems, Copilot makes those problems reachable in ways they never were before.

Here’s what an honest readiness check looks like.

Are your sensitivity labels actually applied?

Most readiness assessments get this one wrong. They ask whether sensitivity labels have been configured. Configuration and application are different things. You can have a complete labelling taxonomy, well-designed policies, and a training rollout that reached ninety percent of users, and still have a SharePoint environment where most documents carry no label, because nobody required one at upload.

The real check: run a Content Explorer report in Microsoft Purview and look at what percentage of your SharePoint content is labelled. In most environments I’ve seen, it’s below fifty percent. Often well below.

Unlabelled content is unclassified content. Copilot will access it, process it, and return it in responses. The label that would have restricted or flagged sensitive material elsewhere simply isn’t there. Copilot doesn’t know the content should have been classified. Nobody told it.

Can Copilot return things it should not?

SharePoint oversharing predates Copilot by many years. Most large environments have libraries where permissions were set broadly because broad was easier than granular. Sites the whole company can read because no one defined an audience at creation. Legacy content whose “open” permissions model made sense in 2015 and was never revisited.

Pre-Copilot, this was a governance issue you could live with. Users didn’t navigate to content they didn’t know existed. Technically accessible, practically obscure.

Copilot ends the obscurity. Its responses are bounded by SharePoint permissions, so it won’t show users content they lack access to. But where permissions are broader than they should be, Copilot will happily surface content the user can access and was never meant to see. Accessible-but-obscure becomes findable.

The check is a permissions audit of the content Copilot will index. It doesn’t need to cover everything. Start with the highest-sensitivity libraries and any site where permissions defaulted to broad.

Are your DLP policies current?

DLP was designed for explicit, human-initiated data movement. Someone emails a document externally. Someone uploads a file to personal cloud storage. The policy detects the action and responds.

Copilot introduces a different movement. A user asks for a summary of a sensitive document. Copilot produces one containing sensitive information. The user pastes the summary into an email and hits send. The original document never left SharePoint, and the DLP policy protecting it may not recognise the summary as the same sensitive content.

Not hypothetical. It’s a real gap, and it requires DLP policies that reach AI-generated outputs. Most reach only the source documents. Microsoft has added AI-specific DLP capabilities to Purview. Most organisations haven’t configured them, because they weren’t part of the original DLP deployment.

Is your SharePoint information architecture fit for purpose?

Copilot is only as useful as the content it retrieves. Well-defined content types, populated metadata, and consistent naming give it enough signal to return relevant, accurate results. Flat folders full of files named “Final v3 rev2.docx” give it noise.

This one isn’t a blocker. You can deploy Copilot into a badly structured environment; the deployment won’t fail, users will just find the tool unreliable and adoption will stall. Whether that’s acceptable is a business decision. The readiness check’s job is to make it an explicit one: this is the quality of content Copilot will work with, and this is what to realistically expect from the outputs.

Is Power Platform in scope?

Most Copilot readiness assessments cover M365: SharePoint, Teams, Exchange. Power Platform governance gets treated as a separate conversation. It shouldn’t be.

Copilot agents can trigger Power Automate flows, and Power Platform’s Copilot-native features extend the reach of existing automations. An ungoverned Power Platform environment already has flows moving data in undocumented ways. Let Copilot interact with those flows and the governance gap widens.

The check should include a basic inventory of what runs in the environments Copilot will touch. Not a full sprawl audit. At minimum: identify the flows that move sensitive data, and verify they have real ownership, documentation, and DLP coverage.

What to do with the results

A real readiness check will almost certainly produce a fix-it list. The right response isn’t deferring deployment until a full remediation project finishes. Scope the initial rollout to the parts of the environment that are ready, define what’s needed to expand, and sequence that work alongside a controlled rollout.

Copilot deployed into a clean, well-governed environment with proper DLP and labelling is a genuine productivity tool. Copilot deployed into an environment nobody has ever audited is a liability that compounds with every new user. The readiness check tells you which one you’re about to ship.