What teams are governing with

Ask what an IT team still does by hand in a Microsoft 365 tenant and the list gets shorter every year. Backups run on a schedule. Endpoint protection runs as a service. Patches deploy on a cycle. Each of those was somebody's manual job once, and none of them wait for a person to remember anymore.

Governance never made that transition. It's the one operational discipline in Microsoft 365 that most teams still run by hand, from reports someone has to think to pull, on a cadence someone has to maintain. And it isn't for lack of options. Software built to do this has been on the market for roughly as long as SharePoint has existed. Which is a strange result for a platform this mature.

96% of organizations are governing Microsoft 365 with built-in Microsoft tools, manual internal policies, or some mix of the two. Another 4% aren't addressing governance and security at all. That leaves six respondents out of 943—1%, rounded the same way the 2025 report rounded it—using something purpose-built. Six people is too small a group to profile, cross-tabulate, or draw any conclusion from beyond its size.

We asked the same question of a different sample last year and got the same answer. Last year we called it the 1% gap. A year later, after a year in which full Copilot deployment went from 29% to 56% AI governance survey, it's still 1%. The gap didn't close while the surface being governed got substantially larger and substantially more reachable.

What did move is the split above it. Reliance on built-in Microsoft tools grew six points, manual policies fell four, and the share not addressing governance at all fell from 5% to 4%, the only movement pointing anywhere good, and a small one. The year's activity was lateral. A few teams stopped ignoring the problem, and a larger group consolidated onto tooling they already owned.

Nothing here suggests indifference. It suggests a ceiling.

To be fair to the built-in tools

Built-in tools aren't bad tools. They're capable within the scenarios they were designed for. The challenge is that many were built to administer individual services, not to continuously govern a Microsoft 365 environment at the pace sprawl now accumulates. Microsoft's native capabilities can support continuous controls, but coverage, configuration, licensing and cross-tool visibility vary.

The real test is whether the combined control set gives your team the coverage, context and response time it needs. Which is where the discovery data comes back: finding a setting when you know where to look isn't the same as being alerted when it changes, or having a workspace with an anonymous sharing link left active since 2023 brought to your attention.

What's blocking governance improvement

The incidents are real, the workload is growing, and software built for this has been on the market for decades. So why hasn't the number moved? If a team knows it has a governance problem and hasn't bought anything to fix it, the usual assumptions are budget or expertise. We asked what would have the biggest impact on improving a team's Microsoft 365 governance and security, and unlike most questions in this survey, allowed one answer only.

Chapter 1 covered the top answer, better controls for AI agents and automations CH 1 Confidence ≠ control →. Set that aside and the rest of the ranking is a finding in itself. The largest remaining answer was executive buy-in to prioritize governance, at 20%. More budget for tooling or headcount finished last at 3%, with more internal expertise just above it at 6%. Everything in between—automated remediation, better tenant visibility, delegated reviews—is a request for capability rather than cash.

So the thing teams most want isn't money, and it isn't knowledge. It's for this to matter to someone above them.

That's easy to dismiss as managers wanting their bosses to care more. But the data doesn't support the dismissal. 97% of respondents are a manager, director or VP, and the demand for executive buy-in climbs with seniority rather than falling.

If this were just people passing blame upward, managers should name executive buy-in most often, since they have the most layers to point at. In this group they name it least. It's the VPs who name it almost twice as often.

The likeliest explanation is that governance loses on merit, every cycle, and the people who watch it lose know why. It has no deadline. It generates no revenue. Nothing fails visibly until something fails badly. Against an AI program with a slide deck, projected profits and a launch date, that's not a fair fight. That's why the ask isn't for money. Money wouldn't change the shape of the argument. A mandate would.

But waiting isn't a neutral position. Governance doesn't hold the level you left it at.

That changes what the 1% tooling number is measuring. A team that ran a cleanup two years ago and hasn't been back isn't sitting where they finished. They're somewhere below it, and nothing in the environment reports the drift. The number that stayed still was a number about purchasing. The thing it was meant to protect has been moving the whole time.

How teams rate their own governance

This chapter has been running on the IT operations survey. It's worth crossing to the AI governance study for a few questions, because it asked 851 IT leaders to grade their own governance, and asked separately about the specific controls they run, which means the summary and the specifics can be set side by side within the same sample.

Now hold that against what the same 851 people said elsewhere. 42% have fully centralized visibility into external sharing. 29% manage external sharing permissions through automated monitoring and policy enforcement. Both are well short of 63%.

The easy conclusion is overconfidence, like chapter 1. But look at what the five maturity options actually describe: highly automated, consistently enforced, mostly manual. Every one is a statement about how the process runs. None asks how much of the estate it runs across, a limit of the question we wrote, and also the harder thing to answer. A team can know precisely how disciplined its process is and still not know what sits outside it.

So we took the 318 respondents who picked the top rating and looked at what they'd told us elsewhere. Every difference runs in the direction you'd expect: this group reviews access more often, automates more of its sharing enforcement, and sees more of its estate than the sample average. The rating is sorting people correctly.

Visibility is where the gap is biggest. 57% of the self-rated most mature have a fully centralized view of external sharing activity, against 42% across the sample, which still leaves 43% of the most confident band without a complete view of who their tenant is sharing with. In the other two cross-tabs the margins are narrow: eight points ahead on monthly access reviews, effectively identical on quarterly, five points ahead on managing external sharing permissions. A majority of them, 51%, describe that work as a combination of automated tools and manual review rather than automated enforcement.

Count how many of the three each of them actually holds—fully centralized visibility, monthly access reviews, automated sharing enforcement—and the band splits almost in half. 8% hold all three. 36% hold two. 34% hold one. 22% hold none.

For the 44% holding two or three, the earlier finding stands: they have a real process, and what separates them from everyone else is mostly that they can see more of what it covers. The rating is accurate and the gap is a perimeter.

The other 56% hold one or none. That isn't a narrower perimeter, it's a thinner process. Set the bar at quarterly reviews instead of monthly and the split moves to 65/35, but the shape doesn't change: a substantial share of the most confident band is using the language of automation without much of it underneath. Which is worth naming plainly, because the two groups need different things. A team with a strong process and limited reach needs visibility. A team describing automation it doesn't have needs the automation.

The three-capability split and the top-band cross-tabs above were derived from the respondent-level survey data rather than read off a published summary. AI governance survey

External sharing: links, guests, and the workspaces nobody owns

Stale access and oversharing were two of the four most common incidents. This section is about where they come from. Three controls account for most of it: who can create anonymous links, whether guest accounts get reviewed, and what happens to a workspace once nobody needs it. None of the three fails suddenly. All three accumulate quietly.

Anonymous sharing links

70% of organizations allow anonymous links across the whole tenant. A quarter allow them with nothing set to make them expire. Every one of those links is a door that stays open until somebody actively closes it, and by design nobody has to be signed in to walk through.

Cross that against the incident data and the gap is one of the widest in the study.

The gradient runs in one direction across all four bands: 43% of organizations that block anonymous links reported an incident last year, against 89% of those that allow them tenant-wide with no expiry. Stale access is where the ratio is largest: it runs from 9% at the blocked end to 52% at the open end, close to a sixfold difference, where the overall incident rate roughly doubles. That ordering makes mechanical sense as well as statistical sense. An anonymous link with no expiration isn't a route to stale access. It is stale access—a credential that works indefinitely, held by someone who never had to sign in.

The more useful detail is where in the gradient the jumps happen, because they aren't the same size. Blocked to site-restricted costs 21 points. Site-restricted to tenant-wide costs 18. Dropping expiry on top of that costs 7. The first two are about where links can be created at all; the third is about how long they survive once made.

We split the sample 18 ways to test this: by organization size, by how teams discover problems, by how much self-service they allow, and by country. The step from site-restricted to tenant-wide pointed the same way in every slice where both bases were large enough to report: 17 of 18, with France and Japan having no reportable site-restricted base either way. The expiry step didn't hold up the same way. It reversed in two slices, which is roughly what you'd expect from chance when the underlying effect is only 7 points wide.

So restricting where links can be created is associated with lower incident rates in every population we tested. Setting an expiry is associated with lower rates on average, but the effect is small enough that we can't find it reliably in smaller groups. That ordering is the reverse of what most organizations have actually done. The single most common configuration in the data—45% of respondents, more than any other—is links allowed tenant-wide with an expiry policy attached. It's the responsible-looking version of the permissive option: free, one switch, and it only ever applies going forward. On these numbers it's the smaller half of the fix.

What this doesn't prove

None of this makes the relationship causal. A tenant setting isn't randomly assigned, and organizations that restrict anonymous links differ from those that don't in ways this survey doesn't capture.

One counter-explanation is worth walking through, because it runs in the finding's favour rather than against it. Suppose the causation is backwards. Teams that suffered an oversharing incident responded by locking their link policy down. Those teams would then appear in the blocked and site-restricted bands with an incident on record, raising the rate in precisely the bands where it's lowest. The gradient would look shallower than the truth, not steeper. We can't test that directly; nothing in either survey asks when a policy was set versus when an incident happened. But it means the 46-point spread is more likely to understate the relationship than to exaggerate it.

What the data can't settle is whether blocking outright is the right endpoint.

Only 8% block tenant-wide, and this study has no way to test whether the other 92% are making a mistake or a trade-off.

Guest access reviews

Anonymous links let someone in without an account. Guest accounts are the opposite: a named identity, created on purpose, with a person attached to it. Which ought to make them easier to keep track of. 38% of organizations had a former employee or external partner keep access longer than they should have, and guest accounts are the mechanism for the second half of that.

Two thirds of organizations review guest access on a schedule, which is genuinely better than the folklore suggests. But what it buys is smaller than you'd hope. Organizations with a regular review reported stale access 38% of the time. Organizations reviewing ad hoc reported it 44% of the time. A six-point difference.

A third either review ad hoc or not at all, and the two smallest groups are the familiar ones. The 43 organizations with no process report stale access at 23%, and the 24 who don't know report it at 4%. That's the second and third time in this chapter that the teams doing least have reported least, and it means what it meant the first time. Both bases are far below the n<75 threshold, and both are far more likely to be a visibility artifact than a safety record.

Split the review question by link policy, though, and the difference between regular and ad hoc reviewers gets genuinely useful. Where anonymous links are confined to specific sites, review cadence makes no measurable difference: 20% against 21%. Where links are open across the tenant, it's worth 10 to 12 points: 41% against 51% with an expiry set, 51% against 63% without one.

So the process works in proportion to what the configuration lets through. That's useful in both directions. If your link policy is tight, a quarterly guest review is probably enough. If it isn't, no review cadence available in this data gets you below 51%.

Bases for the split above: 122/62, 269/138, 174/51. The blocked-tenant band had too few ad hoc reviewers to compare, and the 62 and 51 cells are directional. IT operations survey

Links and guests are the two controls in this chapter that don't need a budget line, an owner, or a mandate. They need a decision.