GOVERNANCE · April 14, 2026 · 6 min read

What’s new in Copilot Readiness (April 2026)

We shipped a meaningful update to the Copilot Readiness Assessment this week. The headline is speed — full six-module scans now run 60–70% faster on a typical mid-market tenant — but the substance is new finding types in Purview and SharePoint, plus a per-site parallelism model that changes how the SharePoint Permissions module behaves at scale. This post explains what changed and why.

60–70% faster via cross-module deduplication

The assessment makes a lot of Graph calls. The Purview module enumerates DLP policies, sensitivity labels, and information-protection endpoints. The Identity module walks Conditional Access policies, directory roles, and application grants. The SharePoint Permissions module hits /sites, then /sites/{id}/permissions, then sharing links per site.

What we noticed in the profiler: we were hitting the same endpoints across multiple modules. The SharePoint module needed the list of sites. The Teams module needed the list of sites (for Teams-connected site detection). The OneDrive module needed the /users enumeration. The Identity module also needed /users for MFA registration state. Each module was fetching its own copy.

The fix was a request cache scoped to a single scan run, keyed on the normalised Graph URL. The first module to request /users?$select=id,userPrincipalName,assignedLicenses pays the API cost; every subsequent module asking for the same URL pulls from the in-memory cache and pays zero.

On a tenant with 1,200 users and 40 active SharePoint sites, full-scan wall time dropped from about 5m30s to about 1m50s. The ratio holds on larger tenants too — the cache becomes more valuable as the tenant grows because the absolute redundancy grows. Zero Graph calls were removed from the scan logic; they were just stopped from happening twice.

No caching across scan runs — that would defeat the point of a readiness snapshot. The cache is per-run and discarded when the scan finishes. Every scan still reflects live Graph state.

Per-site scan parallelism

The SharePoint Permissions module used to walk the top 30 active sites serially. For most mid-market tenants that was fine — 30 sites at roughly 2 seconds per site is a minute. For larger tenants where we have quietly bumped the cap past 30, and for tenants with deeply nested sharing-link footprints, the serial walk became the long pole.

The scanner now runs per-site analysis in parallel with a concurrency limit of 6 by default. Each site is a self-contained unit of work: list items, enumerate sharing links, compute the Anyone-link footprint, compute the per-permission-level count, and emit findings. Because the work is IO-bound on Graph, 6-way concurrency lands close to 6x speedup on the module without overwhelming tenant-side throttling.

We respect the Retry-After header on 429s, so if Microsoft is pushing back, we back off. You cannot configure concurrency yourself — it is tuned per-tenant based on the 429 response rate of the first few sites. If your tenant is throttle-heavy, the scanner quietly pulls concurrency down; if it is healthy, it runs at 6.

New finding types

Three new findings landed in this release. All three are live in the default scan; no configuration needed.

PUR-014: Copilot-aware DLP policy has no block action

A follow-up to the flagship PUR-001 (does any DLP policy include the Microsoft365Copilot workload). We found tenants that had correctly added the Copilot workload to an existing policy — but the policy only had an audit action, not a block. The policy was technically scoped to Copilot, and it was technically active, but Copilot responses were being logged rather than prevented.

PUR-014 walks each DLP policy that includes Microsoft365Copilot in its workloads array and checks the rule actions. If the only action is AuditSeverity with no BlockAccess equivalent, the finding fires at Must Do Before Full Rollout. The evidence block includes the policy ID and the rule names so Purview admins can fix it in place.

SPO-019: Large sites with active guests and Anyone-links

A compound finding. Individually, “site with many external guests” and “site with many Anyone-links” are both flagged by existing findings. When they co-occur on the same site with more than 1,000 items, the site is a high-magnitude oversharing risk and gets its own finding at Must Do Before Copilot priority.

This one came from a customer report: a tenant had dozens of sites over each individual threshold and the risk triage was getting lost in the noise. SPO-019 surfaces the sites where both dimensions are active on the same surface — which is where a Copilot response to “summarise our client list” is most likely to go wrong.

IDN-008: Application grant with high-risk delegated scope

Identity-side addition. The scanner now samples OAuth application grants (via /oauth2PermissionGrants) and flags any delegated grant to a non-Microsoft app with a scope from a short list of high-impact ones: Mail.ReadWrite, Files.ReadWrite.All, Sites.FullControl.All, Directory.ReadWrite.All. Those are the grants that let a third-party SaaS tool read (or rewrite) the same content Copilot would.

Finding fires at Must Do Before Full Rollout. Evidence includes the app display name, the client ID, and the specific scope granted. The finding is deliberately broad; we expect some of these grants to be legitimate (a DLP tool, a backup product) and the user to triage them. The point is that they get surfaced, not silently swallowed.

What did not change

A couple of things worth stating explicitly, because customers sometimes ask:

The 14 read-only Graph scopes are unchanged. No new scopes were added. The scanner still requests exactly the same consent set, so existing service-principal configurations do not need to be updated.
The scoring formula is unchanged. The new findings participate in the existing weighted model (SharePoint and Purview at 2x). The 1.0–4.0 composite still means the same thing. Your tenant’s score may move because PUR-014, SPO-019, or IDN-008 picked up something that previously went unflagged — that is the intent — but the scale is comparable run-to-run.
Read-only is still enforced at the client level. The write-guard on the Graph client predates this release and remains in place. Any non-GET verb raises before the request leaves the process.

How to take advantage

Nothing to configure. If you already have a Copilot Readiness assessment in your workspace, your next run uses the new scanner. Free Snapshot users see the speed improvement and the new findings in their module scorecards. Single Assessment and Bundle customers see the new findings with full evidence and the usual exports.

If you have not run one yet, start at app.migrationfox.com/governance. A full six-module scan on a typical 500–2,000-user tenant now takes about two to three minutes end to end.