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

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.

This version reflects Microsoft’s pages as checked on 2 November 2026. Microsoft’s requirements page notes that Microsoft 365 Copilot is now named Microsoft Copilot, so a Microsoft Copilot readiness assessment and a Microsoft 365 Copilot readiness assessment are the same exercise; this article says Copilot for both. Two other things have moved since the article first appeared in August: since July 2026 the Semi-Annual Enterprise Channel has received updates monthly, on the same basis as the Monthly Enterprise Channel, and the network check now includes copilot.cloud.microsoft.

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 needs an Exchange Online mailbox for anything that uses mail, calendar or meeting data, and it is not available in group mailboxes. Microsoft’s requirements page now says Copilot can also use content a user is permitted to access in archive, shared and delegate mailboxes, which earlier versions of the page excluded. So shared mailboxes should no longer remove part of the expected audience. Their content is now within Copilot’s reach for every licensed user who has access to them, and that belongs in the exposure review.

Guests and cross-tenant users are not licensed through your tenant. Joint ventures, recently acquired entities and long-running contractor populations are affected. Microsoft documents one narrow case running the other way: in a multitenant organisation, B2B members who hold Copilot licences can use Copilot in Teams meetings your organisation hosts, a setting that is on by default and does not extend to external or federated users (Microsoft’s Teams guidance).

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.

Devices still on an old Semi-Annual Enterprise Channel build do not carry Copilot. Since July 2026 Microsoft has been moving those devices to monthly updates itself, so the check is whether every device has installed Version 2606, and whether change control has accepted a monthly cadence it may never have agreed to, which is a governance conversation with a lead time of its own. Microsoft’s channel unification page notes that updated devices show as Monthly Enterprise Channel in the apps themselves, while some management tools and reports may still show the old channel name.

There is a commercial finding at this stage too. Copilot is included in Microsoft 365 E7, and available as an add-on to other eligible plans. The SharePoint Advanced Management features the rest of the assessment relies on, including the permission state reports, access reviews, restricted access control and Restricted Content Discovery, are included once a single user holds a Copilot licence. Microsoft Purview is the part that can cost extra: on an E3 base, automatic labelling and the DLP control that stops Copilot processing labelled files and emails need Microsoft 365 E5 or equivalent Information Protection licensing. A business case built on the Copilot seat price alone will understate what the safe deployment actually costs.

Most tenants we assess fail at least one of these before 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 mailbox finding we hit most often is delegation, and since Microsoft widened mailbox support it is an exposure question more than a blocker. 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. Run the Content Management Assessment and the site permissions report in SharePoint Advanced Management. The Content Management Assessment runs five reports across every site, from inactive and ownerless sites to broken inheritance, EEEU and permissive sharing links, in 2 to 72 hours depending on tenant size. The site permissions report, which Microsoft’s licensing page still lists among its permission state reports, is the baseline of how many people can reach each SharePoint and OneDrive site, item-level access included. It shows the 100 sites with the most permissioned users, exports up to 1 million, and its first run takes up to five days. This is the evidence base. Without it the conversation stays anecdotal.
2. Cross-reference those results with the data risk assessments in Microsoft Purview Data Security Posture Management, whose default assessment runs weekly on the 100 most used SharePoint sites. One view ranks sites by how many people can reach them, the other picks them by how much they are used. Two independent views of the same estate, and where they disagree is usually where the interesting findings are.
3. Apply Restricted Content Discovery to the sites still under review, so they drop out of organisation-wide search and Copilot while remediation is in progress. This is the control that lets a pilot start before the whole estate is clean. Older guidance recommends Restricted SharePoint Search here, but that feature is retiring and new enablement has been blocked since 31 July 2026.
4. Hide “everyone except external users” from the People Picker at tenant level, so nobody can grant it from now on, then run the special groups report to find the grants that already exist, starting with public group sites, which add it by default. 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.
5. Start an access review through SharePoint Advanced Management for every site found to be overshared, then apply restricted access control to business-critical sites.

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. It is also the work no licence substitutes for: what Purview can and cannot stop Copilot doing depends entirely on the permissions this list fixes.

How each of these controls behaves, what it needs and where it stops, including the gaps in OneDrive, is set out in Copilot data readiness: the controls that decide what it can surface. This article stays with what the assessment finds and what the business decides because of it.

Beyond broad site permissions, the most pervasive risk is broken inheritance: individual subfolders and documents carrying far wider permissions than the restricted site above them, granted years ago and never reviewed, including Specific people links sent to large groups.

That is the pattern a site permissions audit is built to expose: counting broken inheritance and sharing links per site so you know which sites need their item-level permissions cleaned up, because the pattern 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 the one most often skipped in rushed pilots, 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. There are two exceptions, and the first is WebSockets. Several Copilot integrations rely on full WSS connectivity from user devices to *.office.com, *.cloud.microsoft and copilot.cloud.microsoft, 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.

The second exception is the address itself. Microsoft’s requirements page says the primary address for the Copilot app is changing to copilot.cloud.microsoft, asks for all of *.cloud.microsoft on allow lists, and is explicit: “Microsoft doesn’t support allowing only selected Microsoft 365 application URLs within the *.cloud.microsoft domain.” An estate that blocks copilot.cloud.microsoft to keep personal Microsoft accounts out also blocks the Copilot app, and Microsoft points to tenant restrictions as the targeted alternative. The same page links a connectivity test for the Copilot app that checks the domain.

Three 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. Copilot Chat checks the links in its answers with Safe Links before opening them, which needs third-party cookies for *.safelinks.protection.outlook.com; where a managed browser policy blocks them, users see an “Unable to verify link” message and the link does not open. 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 Microsoft’s own readiness tools answer

Microsoft publishes several tools that answer parts of a Copilot readiness assessment, and its adoption guide for IT admins recommends one of them, the Copilot Optimization Assessment, before deployment. Most cover part of one of the three questions above.

Two points follow. The readiness report is the fastest way to count the stage one population, because it counts licences and update channels for you, but the metrics Microsoft lists for it say nothing about mailboxes, guest accounts or device-based licensing, so those still need checking by hand. And none of these tools produces the third list below, the sequence: which findings must be fixed before the first cohort and which can be fixed alongside it. That is a judgement about the business rather than a report on the tenant.

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.

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 usage report in the Microsoft 365 admin center give adoption figures without building anything custom. Survey sentiment needs more: results from Viva Pulse, Viva Glint or an uploaded file, and at least 50 Copilot licences or 50 Viva Insights licences. The value of the assessment is that it tells you what those numbers will mean. We have set out separately what Copilot adoption figures actually count, and when they start to mean anything.

How long it takes

For a mid-sized tenant, the technical work is days rather than weeks. The prerequisites check is an afternoon. Microsoft allows up to five days for the first site permissions report and four days for the first Purview data risk assessment results, so allow up to a week for the native reports to populate. 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.

One sequencing detail follows from Microsoft’s licensing. Unless the tenant already has SharePoint Advanced Management another way, through the Plan 1 add-on or Microsoft 365 E7, its reports arrive with the first Copilot licence assigned to any user, provided the tenant has one of the base subscriptions Microsoft lists, and the first site permissions report then takes up to five days. One assigned licence, not the full order, is enough to start the SharePoint Advanced Management reports.

We would not recommend running a pilot in parallel with an unfinished oversharing remediation unless Restricted Content Discovery is in place on the sites still being reviewed. It is the one control that lets both happen at once without exposing the estate while it is being cleaned. Two cautions: it does not change permissions, so it hides content rather than protecting it, and on a site with more than 500,000 items it can take more than a week to take effect, so apply it before the pilot date rather than on it.

Microsoft’s Restricted Content Discovery page adds two points for the pilot plan. A restricted site also loses its AI entry points, such as the Copilot button, AI actions menus and Create pages with AI, so pilot users whose daily work sits in a restricted site will see less of Copilot there. And Microsoft designs it as “a temporary governance control”; its blueprint ends the remediation stage with “Remove interim Copilot protections once access and permissions are remediated”.

No rollout plan should rely on Restricted Content Discovery without a dated removal plan.

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 audited site permissions and broken inheritance below the site level, talk to our team. That audit 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. Microsoft’s own tools each cover part of it: the Copilot readiness report counts which users are technically eligible, the Content Management Assessment and Purview’s data risk assessments examine the data, and Microsoft’s connectivity test checks the cloud.microsoft domain that the Copilot app uses.

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? Often, but not for the reason usually given. SharePoint Advanced Management’s oversharing controls are included once one user holds a Copilot licence. On an E3 base, the Purview controls that automatically label content and stop Copilot processing labelled files and emails need Microsoft 365 E5 or equivalent Information Protection licensing. 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 guests and cross-tenant users, who are not licensed through your tenant, device-based licensing, and devices on the Semi-Annual Enterprise Channel that have not yet installed Version 2606, the update that moves them to the monthly cadence. Anything that uses mail, calendar or meeting data also needs an Exchange Online mailbox, and Copilot is not available in group mailboxes.

Can we start a pilot before oversharing is fully remediated? Yes, if Restricted Content Discovery is applied to the sites still under review, so they are removed from organisation-wide search and Copilot while the remediation runs. Starting without it is how programmes lose credibility in week one.

Manish Kumar

Senior Business Intelligence Architect with 22 years of experience designing enterprise analytics and data platforms. Focus areas include Power BI, real-time analytics, and large-scale BI architecture across the Microsoft data stack.