Copilot & AI

What a Copilot readiness assessment checks, and why most tenants fail it

August 7, 2026

Our article on why most enterprises cannot show Copilot ROI ended with a recommendation: do not buy another seat until a permissions audit has been run and acted on. The obvious next question is what that audit actually involves, and how long it takes.

A Copilot readiness assessment answers three questions, in this order. Can Copilot technically run for these users. What will it surface on day one that it should not. And will the network let it work at all. Most organisations assume the first is the hard part. It is the easiest of the three, and the one that takes an afternoon.

This is what each stage checks, drawn from Microsoft’s own deployment guidance rather than from a vendor pitch.

Stage one: the licence and tenant blockers

These are binary. Either the prerequisite is met or Copilot does not work for that user, and no amount of enablement fixes it. A readiness assessment catches them before licences are ordered rather than after.

Copilot only works on primary mailboxes hosted on Exchange Online. It is not available on archive mailboxes, group mailboxes, or shared and delegate mailboxes a user has access to. In organisations where a function works largely out of shared mailboxes, and service desks and finance teams frequently do, this removes a chunk of the expected audience before anyone writes a prompt.

Cross-tenant users and guests cannot be assigned Copilot licences. Joint ventures, recently acquired entities and long-running contractor populations are affected.

Device-based licensing for Microsoft 365 Apps for enterprise excludes Copilot. Shared-device estates in manufacturing, retail and healthcare are usually the ones caught here.

The Semi-Annual Enterprise Channel does not carry Copilot. Copilot is available on every other update channel, but organisations that deliberately stayed on the slowest channel for change-control reasons have to change that policy first, which is a governance conversation with a lead time of its own.

There is a commercial finding at this stage too. Microsoft 365 Copilot is now included in the Microsoft 365 E7 plan, and available as an add-on to other plans. Several of the controls the rest of the assessment depends on, including Microsoft Purview and SharePoint Advanced Management, are separately licensed. A business case built on the Copilot seat price alone will understate what the safe deployment actually costs.

Across the tenants we assess, more than nine in ten fail at least one of these before any remediation starts. That is not a criticism of those organisations. The prerequisites are unrelated to each other, several are historical decisions nobody revisits, and none of them surface until somebody looks.

The one we hit most often is mailbox delegation. Organisations attempt to assign Copilot licences directly to shared mailboxes, which does not work, or they discover unmapped delegation rules that would let Copilot query ticketing and support history nobody intended to expose. Service desks and shared inbox accounts are where this concentrates, and they are also the teams most often nominated for the first cohort.

Stage two: the oversharing exposure

This is the assessment. Everything else is scaffolding around it.

Copilot inherits the permissions that already exist. It does not widen access, and that is exactly the problem. Before Copilot, a sensitive file four folders deep was protected by the fact that nobody was going to find it. Copilot removes that protection in an afternoon, and the first person to notice is rarely someone in IT.

Microsoft’s own deployment guidance is unusually specific about the sequence, and it is worth following rather than improvising.

  1. Export the top 100 most used sites from the SharePoint admin center, and run the SharePoint Advanced Management permission state report against them. This is the evidence base. Without it the conversation stays anecdotal.
  2. Cross-reference those results with the Microsoft Purview Data Security Posture Management oversharing posture assessment. Two independent views of the same estate, and where they disagree is usually where the interesting findings are.
  3. Disable “everyone except external users” at tenant level, and turn on Purview audit for Copilot interaction activity. The EEEU setting is the single most common route by which content becomes readable by the entire organisation without anyone intending it.
  4. Start an access review through SharePoint Advanced Management for every site found to be overshared, then apply restricted access control to business-critical sites.
  5. Consider restricted SharePoint search to limit what is discoverable while remediation is in progress. This is the control that lets a pilot start before the whole estate is clean.

The output is a remediation list in priority order. It is not glamorous work and it does not demo well, which is precisely why it gets skipped.

Beyond broad site permissions, the most pervasive risk is broken inheritance created by years of ad-hoc “People in your organization” sharing links, where individual subfolders and documents sit wide open to internal search while hiding beneath an otherwise restricted top-level site structure.

That is the pattern the permission state report is best at exposing, because it is invisible from the site level. A site can be correctly locked down and still contain a folder that everyone in the company can read.

Stage three: the network checks nobody runs

This stage is skipped almost universally, and it produces the failures that get blamed on the product.

Copilot experiences use the same endpoints as Microsoft 365 apps, so a tenant with a healthy Microsoft 365 estate is mostly fine. The exception is WebSockets. Several Copilot integrations rely on full WSS connectivity from user devices to *.cloud.microsoft and *.office.com, and three common network configurations break it:

  • the network perimeter blocks the WSS protocol outright
  • network devices perform TLS inspection on the connection
  • proxy servers enforce aggressive connection timeouts

Any of the three produces application failures that look like a broken product rather than a broken proxy rule. On the network side, active SSL inspection and decryption, or WebSocket traffic blocked at the enterprise proxy, is the primary technical failure we see. Neither is a misconfiguration. Both are deliberate security controls doing what they were installed to do, which is why nobody thinks to check them before a Copilot rollout.

Two smaller items belong in the same check. Copilot in Word, Excel and PowerPoint on the web requires third-party cookies to be enabled, which collides with hardened browser policies. And the Office Feature Updates task has to be allowed to run on its normal schedule and reach its network resources, because core Copilot experiences in Word, PowerPoint, Excel and OneNote depend on it.

What the output should look like

A readiness assessment that ends in a slide saying “you are 70% ready” has not done its job. The deliverable should be three lists.

ListWhat it containsWho acts
BlockersPrerequisites that stop Copilot working for a named population, with the size of that populationLicensing and identity
ExposureSites and libraries where Copilot would surface content it should not, ranked by riskSharePoint and security
SequenceWhat has to be fixed before the first cohort, and what can be fixed alongsideProgramme owner

The third list is the one that determines whether the programme lands. Remediating everything before starting is a year of work that never begins. Remediating nothing and starting anyway spends the goodwill the programme needs. The assessment exists to draw the line between them.

Once deployment starts, the measurement side is already provided: the Copilot Dashboard in Viva Insights and the Copilot readiness and usage reports in the Microsoft 365 admin center give adoption and sentiment without building anything custom. The value of the assessment is that it tells you what those numbers will mean.

How long it takes

For a mid-sized tenant, the technical work is days rather than weeks. The prerequisites check is an afternoon. The permission state report and DSPM cross-reference take a few days including the time reports take to generate. The network checks are a morning with someone who owns the proxy.

What extends the timeline is remediation, not assessment, and that depends entirely on what the report finds. This is the argument for running the assessment before the licence order rather than after: the finding changes the sequencing, and sequencing is the only variable you still control once the seats are live.

We would not recommend running a pilot in parallel with an unfinished oversharing remediation unless restricted SharePoint search is in place first. It is the one control that lets both happen at once without exposing the estate while it is being cleaned.

Where to start

Start with the exposure question, because it is the one with consequences that cannot be undone. A licence prerequisite discovered late costs money. A salary review surfaced to the wrong person costs the programme.

Veratas runs Copilot readiness and AI enablement assessments, and the Microsoft Purview governance work that most of them turn out to require.

If you have Copilot licences live and no one has run the permission state report, talk to our team. That report is the fastest way to find out what your tenant is currently willing to tell people.

Frequently asked questions

What does a Copilot readiness assessment actually check? Three things: whether licence and tenant prerequisites are met for the intended users, what sensitive content Copilot would surface to whom on day one, and whether the network supports the connections Copilot relies on.

How long does a Copilot readiness assessment take? For a mid-sized tenant the assessment itself is days rather than weeks. Remediation of what it finds is the variable, and it depends on how much oversharing exists.

Do we need extra licences beyond Copilot? Usually. Microsoft Purview and SharePoint Advanced Management are separately licensed, and the readiness and remediation work depends on both. A business case built on the Copilot seat price alone will be short.

Why would Copilot not work for some of our users? The common causes are shared, delegate or archive mailboxes rather than primary mailboxes on Exchange Online, guest and cross-tenant accounts, device-based licensing, and tenants still on the Semi-Annual Enterprise Channel.

Can we start a pilot before oversharing is fully remediated? Yes, if restricted SharePoint search is in place to limit what is discoverable while the remediation runs. Starting without it is how programmes lose credibility in week one.