Copilot for Microsoft 365 needs a tidy tenant more than new licences

Since Copilot for Microsoft 365 opened up to businesses of any size, the questions have been piling up, and I keep seeing the same pattern. The 300-seat minimum is gone and Copilot can now be added to Microsoft 365 Business Standard or Premium, so many companies are suddenly busy with licensing details. It's as if ticking a box in a spreadsheet makes you ready for AI. My recent projects tell a different story. The hard work happens inside your tenant, well before users ever see the Copilot button.

Microsoft dropped the 300-seat minimum for Copilot this week

As of January 15, small and mid-sized businesses can get Copilot for Microsoft 365. It's available as a per-user add-on to Business Standard or Business Premium, and the 300-user threshold no longer applies. That feels like a green light, but the mechanics haven't changed. Copilot reads data in SharePoint, OneDrive, Exchange and Teams through Microsoft Graph, and it always does so as the signed-in user. It has no special powers. It shows whatever the user could already reach, which is sometimes more than they realise.

And that's where the cracks appear. In a lot of the tenants I review, I find SharePoint sites shared with "Everyone except external users", sharing links still active from projects that ended years ago, and public teams that have turned into dumping grounds. Copilot doesn't create new risks. It exposes the old ones. If lax permissions let a user open sensitive or outdated material, Copilot will reflect that immediately. So before anyone gets carried away by the AI hype, there's housekeeping to do.

The real work happens in permissions, sharing and sensitivity labels

If you want Copilot for Microsoft 365 to deliver anything useful, I strongly recommend taking a hard look at permissions and sharing settings first. These are the steps I usually go through:

• Review SharePoint and Teams permissions for overly broad access
• Audit sharing links and remove old, unused ones
• Check how sensitivity labels are used and enforced
• Set sensible sharing defaults for new sites
• Limit or monitor public Teams

Sensitivity labels deserve particular attention. They govern how Copilot can work with confidential data (see the Copilot privacy documentation), but they only help if they're applied consistently. Without a clear policy and a proper implementation, Copilot may surface confidential files just because nobody set the label. If you want more on access control, my post on Conditional Access in Entra ID covers some related best practices.

Practical tip: To see where content is overshared, open the SharePoint admin center → Reports → Data access governance and check the sharing links reports ("Anyone" links, "People in your organization" links, externally shared files). You'll need a SharePoint Advanced Management license for these (data access governance reports). If you don't have one, go to Sites → Active sites. The "External sharing" column shows the setting for each site, and once you select a site you can restrict it under Settings → External file sharing.

A solid baseline and a pilot group come before the rollout

Copilot for Microsoft 365 has a few technical requirements. Users need current Microsoft 365 Apps (ideally Current Channel), an active OneDrive and the new Teams and Outlook clients. In practice I run into outdated Office installs all the time, along with hybrid environments that were never fully migrated and edge cases nobody thought about. If you roll out Copilot without this baseline, people will be disappointed. I always advise starting with a pilot group of IT-savvy users. Let them find the quirks and roadblocks before you plan a broader rollout.

The diagram below shows how Copilot works entirely within the limits of existing permissions:

flowchart TD
  User["User with Copilot licence"] --> App["M365 app (e.g. Word, Teams)"]
  App --> Copilot["Copilot"]
  Copilot --> Graph["Microsoft Graph"]
  Graph --> Resource["Data (SharePoint, OneDrive, Teams)"]
  Resource -->|"Permitted data"| Copilot
  Copilot --> App

Figure: Copilot only reaches data the user is already allowed to see, so any oversharing in the tenant becomes visible.

Copilot gives no magic answers, so expectations need managing

In many organisations the expectations for Copilot for Microsoft 365 are enormous, and I often end up delivering the reality check. Copilot is a strong assistant for research and first drafts, but its output is only as good as your data and the user's permissions. If your files and Teams are a mess, Copilot won't tidy them up or somehow find "the right" content.

To make the rollout work, set expectations early, demonstrate a few small use cases that clearly add value, and be open about what Copilot can and can't do. SMBs in particular are unsure how AI will change their daily work, and they tend to underestimate how much background effort it takes before Copilot becomes genuinely useful.

I see Copilot as a wake-up call for governance

To me, Copilot for Microsoft 365 is not only about AI at work. It also pushes organisations towards better data governance. With the lower licensing bar, plenty of companies will be tempted to dive straight in, and those who haven't cleaned up their tenant may get some unpleasant surprises. If you're serious about Copilot, now is the moment to put time into fixing permissions, tightening sharing and enforcing sensitivity labels. Then Copilot has a chance to boost productivity instead of adding risk.