Entrazure
“We bought the licenses. Usage is flat and security is nervous.”
The conversation usually arrives in one of two shapes. Either a pilot group has had Copilot for a few months, most of them stopped using it after week three, and finance is asking what the renewal is buying. Or someone in security ran a test prompt, got back a document they had no business reading, and the rollout is now frozen.
Both are the same problem seen from different ends. Microsoft 365 Copilot answers from what the user can already open. In most tenants, that is far more than anyone believes. Ten years of SharePoint sites created for a project and never closed. Files shared with “everyone except external users” because it was faster than picking names. Team sites inherited from someone who left in 2021, with no owner and no review. None of that caused visible harm while finding anything required knowing where to look. Copilot removes that friction, in both directions.
So the tenant is not ready, adoption is being driven with training sessions that do not address why people stopped, and nobody has agreed what a successful deployment would even look like.
Why the usual answer fails
The usual answer is a change management program. Champions, lunch and learns, a prompt library, a monthly adoption dashboard counting active users. It is not wrong, it is second. It treats the problem as one of habit when the first constraint is a permission estate nobody has looked at, and the second is that the assistant is being pointed at content it cannot use well.
The second usual answer is the free readiness assessment, which in practice is a license sizing exercise with a maturity curve on slide four. It produces a number of seats and a recommendation to buy them. It does not produce a list of the sites where sharing links are open to the whole organization, and that list is the actual gating item.
The third failure is subtler and costs more. Teams enable Restricted SharePoint Search to contain the risk, ship the rollout behind it, and never take it off. The allowed list holds a handful of curated sites. Copilot answers accurately and uselessly, because the documents people actually work from are outside the fence. Usage drops, the pilot is declared a disappointment, and the conclusion drawn is that the technology is overpromised. The technology was fine. It was deployed inside a cage that was supposed to be temporary.
The last one is measurement. Adoption reported as seats assigned and monthly active users tells you nobody uninstalled it. It does not tell you whether the proposal drafting task that took four hours now takes ninety minutes. Without that figure, the renewal conversation is a matter of opinion, and opinion loses to budget pressure.
How we run a Copilot deployment
Audit before enablement. We inventory sharing links, permission inheritance breaks, ownerless sites, guest access and the content most likely to be surfaced first. The output is a ranked remediation list with an estimate against each item, not a maturity score. It is the same discipline that governs identity and access under a zero trust model, applied to the content layer instead of the network.
Remediate the top of the list, fence the rest. Overexposed sites are corrected, ownership is assigned with a review cycle, and sensitivity labels are applied through Microsoft Purview to the material that genuinely needs them. Restricted SharePoint Search goes on where remediation is still in flight, with a named exit date rather than as a permanent posture.
Pilot a cohort, not a department. Twenty to forty users chosen because their work is document-heavy and measurable. Two or three tasks per cohort with a baseline figure taken before enablement. Prompts and outcomes reviewed weekly, so the rollout learns from what people actually try rather than from what the prompt library assumed.
Decide what Copilot is not for. Some workflows belong in a custom build, and saying so early prevents a year of disappointment. Where the task needs orchestration, non-Microsoft data or a measured accuracy threshold, the right answer is a purpose-built agent, which is a different engagement with a different shape.
Set the governance that outlives us. Site lifecycle, label policy, guest review, external sharing defaults and the audit logging that shows what the assistant was asked and what it returned. In regulated environments this is where the deployment either passes review or stops, which is why we design it alongside the compliance architecture rather than after it. Clinical and patient-facing organizations get a stricter version again, described in our healthcare work.
The engagement that delivers it
Six weeks, structured so remediation and pilot run in parallel instead of in sequence. Week one is the tenant audit and the baseline measurements. Weeks two and three remediate the highest-exposure sites, apply labels and configure the temporary search fence. Weeks three to five run the pilot cohort with weekly review. Week six is the measurement report, the governance handover and the decision on scope for the wider rollout.
You keep the permission audit and its remediation backlog, the label and lifecycle policy as configuration, the measured before-and-after figures per task, and a written statement of what Copilot is approved for in your organization. Security architecture on the engagement is led by certified security architects, and the audit output is written to be readable by someone who will never open the admin center.
Where Copilot sits alongside custom AI work, both should run on a governed foundation rather than beside it. If the tenant is well managed but the Azure estate underneath is not, that gap shows up quickly, and an Azure landing zone is the usual correction. If you want to know who does this work and how we are structured across Canada and the United States, that is on the about page.
Questions we get
Can we just turn Copilot on and fix permissions later?
You can, and some organizations do it deliberately in a small, well-understood tenant. In an estate with ten years of SharePoint history it is how an internal incident starts. Copilot does not grant new access, it makes existing access usable, and the gap between what people can technically open and what anyone believes they can open is where the damage sits.
How long does the permission remediation take?
Six weeks for a mid-sized tenant, running in parallel with a pilot cohort rather than blocking it. Very large estates with heavy external sharing take longer, and we scope that after the audit rather than guessing before it.
Is Restricted SharePoint Search the answer?
It is a fence, not a fix. It limits organization-wide search to an allowed list of sites, which buys time while remediation runs. Left permanently in place it hides the problem and caps the value of the deployment, because the useful content is usually outside the allowed list. We use it as a temporary control with an exit date.
How do we know whether the rollout worked?
By measuring the workflow, not the license count. We agree two or three tasks per cohort with a before figure, then measure after eight weeks of use. Seats assigned is a procurement metric. Time returned on a named task is the one a CFO accepts at renewal.
Do we need sensitivity labels before Copilot?
You need them before Copilot is useful on anything confidential. Labels applied through Microsoft Purview let you keep Copilot away from restricted material without blocking the whole site, and they carry into the output the assistant generates. Labelling everything is not the goal; labelling what actually matters is.
Should this be Copilot or a custom agent?
Copilot when the task is drafting, summarizing and searching inside Microsoft 365. A custom agent when the workflow needs orchestration, non-Microsoft data or a measurable accuracy target. They are complementary, and choosing wrongly is expensive in both directions.