AI Governance Starts Before Copilot Does

Most AI conversations with business owners start in the wrong place. They ask whether Microsoft 365 Copilot is worth buying. I think the better question is whether the business is ready for what Copilot will reveal.

I have seen the same pattern often enough now. A client gets excited about Copilot in Outlook, Teams, Word and Excel. Someone wants meeting summaries. Someone else wants faster proposals. The owner wants staff to stop using random public AI tools with company data. All fair enough. But then we look underneath and find the real issue: years of loose permissions, old Teams, forgotten SharePoint sites, stale guests and no clear policy on what staff should or should not ask an AI system to do.

That is where AI governance starts.

Governance is not a document no one reads

A policy is useful, but only if it changes behaviour. If the policy says “use AI responsibly” and nothing else, it has failed before it starts.

For Copilot, I want plain rules. What data can be used? What data must not be used? When does a human need to review the answer? Who owns the final output? What happens if Copilot surfaces something the user did not expect to see?

That last question matters. Copilot does not need to break into your tenant to create a problem. If a user already has access to a file, Copilot may be able to use that file as part of an answer. The silent risk is not Copilot ignoring permissions. The risk is that the permissions were never cleaned up in the first place.

The technology follows the tenant

This is why I keep coming back to the Microsoft 365 basics. Entra ID, MFA, Conditional Access, SharePoint permissions, Teams lifecycle, Purview sensitivity labels and Data Loss Prevention are not side issues. They are the foundation.

If identity is weak, every AI answer sits on a weak account. If SharePoint is overshared, Copilot can make that oversharing easier to discover. If labels do not exist, users have no clear signal that a document is sensitive. If DLP is sitting in test mode forever, the business has a policy theatre problem, not a protection model.

I would rather see a small, controlled Copilot pilot in a tidy tenant than a broad deployment in a messy one. Start with a few users. Pick real scenarios. Meeting follow-ups in Teams. Draft replies in Outlook. Summaries from known SharePoint libraries. Then watch what happens. What worked? What surprised people? What data did Copilot find that no one expected?

Guardrails should be practical

The best guardrails are boring. That is a compliment.

Require MFA. Tighten external sharing. Review old guests. Publish simple sensitivity labels. Apply DLP where it matters. Use Restricted SharePoint Search where the content estate needs time to be cleaned up. Train users to verify answers before sending anything to a client. Make it normal to say, “Copilot drafted this, but I approved it.”

That is not anti-AI. That is responsible adoption.

The businesses that do this well will not be the ones with the flashiest prompts. They will be the ones that treat Copilot as part of their operating model. Policy, security, people and process all moving together.

My view is simple. Do not start with the licence. Start with the trust model. If you can trust the identity, the data, the permissions and the controls, then Copilot becomes much easier to use with confidence.

AI governance is not there to slow the business down. It is there so the business can move without pretending the risks are someone else’s problem.

The Report You Should Be Checking Every Month

I’ve lost count of how many times I’ve seen organisations proudly tell me they’ve automated patch management, only to discover they have no idea whether the updates actually made it to the devices.

Getting updates deployed is only half the job. Knowing what happened afterwards is where the real value lies.

That’s why I think one of the most overlooked additions to Windows Autopatch is its reporting capability. Microsoft has invested heavily in giving administrators visibility into both quality updates and feature updates, yet many people still seem to view Autopatch as a simple “set and forget” service. It isn’t. It’s a managed update service that still needs oversight. [learn.microsoft.com]

In my experience, the organisations that get the most value from Windows Autopatch are the ones that spend a few minutes each month reviewing the reports rather than assuming everything worked perfectly.

Compliance Is Not the Same as Configuration

When I speak with MSPs and SMBs, I often hear a variation of the same story.

“We’ve got update policies configured in Intune.”

That’s great, but having a policy isn’t proof that devices are patched.

A device can be powered off, have a failed update, miss a reboot, or simply stop checking in. The policy might be configured perfectly, yet the endpoint remains vulnerable. That distinction matters. In fact, it came up recently in a discussion about the importance of validating that updates have actually reached devices rather than relying on configuration alone.

Windows Autopatch reports help bridge that gap by showing what has actually happened on the endpoint rather than what should have happened.

Visibility at Multiple Levels

The quality update reporting in Windows Autopatch provides several different perspectives. There is a summary view that gives an organisational snapshot, a device-level status report that drills into individual machines, and a trending report that shows update progress over time. Microsoft states that these reports are designed to provide insight into readiness, update health, alerts, compliance, and update status trends over the previous 90 days. [learn.microsoft.com]

That combination is important.

A dashboard might tell you that 95% of devices are compliant. Useful information, certainly. But the remaining 5% are often where the interesting conversations happen.

Which devices failed?

Why are they behind?

Have they stopped checking in?

Do they belong to a key executive, a remote worker, or a critical system?

Those are the questions that reduce risk.

Better Conversations with Copilot

One area I think many organisations overlook is how these reports can work alongside Microsoft 365 Copilot.

Imagine exporting your Windows Autopatch status data into Excel and then asking Copilot questions such as:

Which devices have failed their latest quality update?
Summarise update issues by department.
Identify devices that haven’t checked in recently.
Explain the trend in update compliance over the last quarter.

Rather than manually analysing thousands of rows, Copilot can help surface patterns and priorities much faster. The update data becomes more than just a compliance report. It becomes a decision-making tool.

That’s where I see real value emerging. The reporting tells you what happened. Copilot helps you understand what you should do next.

Reports Help During Audits Too

Anyone who’s been through a security assessment, cyber insurance review, or customer audit knows that “we patch our systems” isn’t usually enough.

You’ll often be asked to demonstrate patch status, prove compliance, explain exceptions, and show evidence of remediation efforts.

The Windows Autopatch reporting framework provides exactly the sort of information auditors tend to request, including device status, readiness information, alerts, compliance data, and historical trends. The data can also be exported for further analysis and reporting. [learn.microsoft.com]

That means you’re not scrambling to produce evidence when someone asks the question.

The evidence is already there.

My Recommendation

If you’re already using Windows Autopatch, add a recurring monthly task to your calendar.

Open the reports.

Review the summary dashboard.

Look for failed devices.

Investigate alerts.

Check the trend lines.

Even better, use Copilot in Excel to help analyse the exported data and identify patterns you might otherwise miss.

Patching isn’t finished when Microsoft releases the update. Patching is finished when you can prove the update successfully reached the devices you’re responsible for.

Windows Autopatch helps automate deployment.

The reports tell you whether that automation is actually working.

One macOS login that finally uses Entra

Most MSPs treat the Macs in a client tenant like orphans. Enrol them in Intune, push a couple of profiles, tick the box, move on.

But the user still signs into that Mac with a local password. One nobody rotates, nobody recovers, and nobody can tie back to a real person. The Entra identity you spent all that effort hardening — MFA, Conditional Access, the lot — stops dead at the macOS login window.

That’s not managed. That’s two identities wearing the same hoodie.

Platform SSO closes the gap. And here’s the part that annoys me: it’s been sitting in your Intune licence the entire time.

What is Platform SSO, really?

It’s the thing that finally makes a Mac sign in with Entra ID the same way a Windows device does with Windows Hello for Business.

When you turn it on, the Mac gets joined to your Entra tenant and a hardware-bound certificate is locked to the device. From then on, the user’s Entra account is their login. Touch ID unlocks the machine. Apps and browsers get single sign-on off the back of it. No more re-typing the work password into every prompt.

You pick one of three flavours — Secure Enclave, smart card, or password. Microsoft recommends Secure Enclave, and so do I. It’s passwordless, phishing-resistant, and conceptually identical to Windows Hello for Business. The other two exist for edge cases.

Here’s the real win: it’s included with every Intune licensing plan. No add-on, no separate SKU. If you’ve got Business Premium, you already own this.

Step-by-Step: turning it on

Portal only. No scripts.

Check the prereqs first

Devices need macOS 13 or newer — push for macOS 14 Sonoma(opens in new window) for the cleanest experience. The Company Portal app must be version 5.2404.0 or later, because that’s what carries the SSO plug-in. And the user has to be allowed to join devices to Entra. Miss any of these and registration silently never happens.

Build the profile

In the Intune admin center, go to Devices > Manage devices > Configuration > Create > New policy. Platform: macOS. Profile type: Settings catalog.

Drop in the values

In the settings picker, expand Platform SSO and add the core settings:

Authentication Method   UserSecureEnclaveKey
Extension Identifier     com.microsoft.CompanyPortalMac.ssoextension
Team Identifier          UBF8T346G9
Registration token       {{DEVICEREGISTRATION}}

Notice what’s missing? No password field. No certificate to mint. No on-prem ADFS box wheezing in a cupboard. The Mac proves who it is with a key baked into its own silicon.

Deploy Company Portal, then assign

Push the latest Company Portal as a required app — that’s what installs the plug-in. Then assign the policy. One catch that bites people: for devices with user affinity, assign to users, not device groups or filters. Get that wrong and Conditional Access can lock the user out of the very resources you were protecting.

Why this actually changes behaviour

The first time the policy lands, the user sees a “Registration required” notification. They click it, sign in with their Entra account, do MFA once, and it’s done.

That prompt trips up every first-timer. It looks like something broke. It didn’t. That’s the moment the device gets Entra-joined and the certificate binds. Tell your clients it’s coming and the support ticket never gets raised.

“Why does it still ask for my old Mac password after a reboot?”

Because FileVault uses the local password as the disk unlock key. So after a cold boot you enter it once — then Touch ID takes over for the rest of the session. That’s by design, not a half-finished feature. Worth saying out loud before a client assumes it’s flaky.

And if there’s still an on-prem domain in the picture, you can layer Kerberos SSO to on-premises Active Directory onto the same policy. The Mac quietly handles both worlds.

Get this in place and a client’s Mac stops being the weak identity in the room. Same MFA. Same Conditional Access. Same audit trail as every Windows device. One login, one identity, one set of rules.

If you’re rolling out Macs and not showing clients this, you’re handing them a managed device with an unmanaged front door.

Platform SSO isn’t there to make Mac logins prettier. It’s there to make the local password irrelevant.

The Security Feature Most Microsoft 365 Admins Ignore

One of the first things I do when looking at a Microsoft 365 environment is check what security is actually doing. Not what has been configured. Not what the Secure Score says. Not what someone remembers setting up six months ago. I want to see what is really happening right now.

That’s why I’m a big fan of the reporting options built into Microsoft Defender for Office 365.

Too many organisations spend time configuring Safe Links, Safe Attachments, anti-phishing policies and quarantine settings, then never look back. The assumption is that because the settings exist, they must be working. In reality, security is something you need to measure continuously, not configure once and forget. The Microsoft documentation highlights a range of Defender for Office 365 reports that provide visibility into how email protection is performing and what threats are being stopped before they reach users. View Defender for Office 365 reports [learn.microsoft.com]

Security Is About Evidence

I regularly see organisations investing in security tools but struggling to answer simple questions:

How much phishing is being blocked?
Are malicious attachments being detected?
How quickly is email being processed?
Are threats still arriving in user mailboxes?

The Defender reports help answer those questions.

The real value isn’t the graphs and dashboards. The value comes from having evidence. Security conversations change dramatically when you can point to data rather than assumptions.

Imagine sitting down with management and showing that thousands of malicious messages were blocked last month before users ever saw them. That’s a much stronger discussion than simply saying, “Our email security is working.”

It’s Not Just About Blocking Threats

One report that often catches my attention is mail latency. Security processing adds time to message delivery, particularly when attachments need deeper inspection. The report helps you understand whether protection measures are impacting mail flow. Mail latency report [learn.microsoft.com]

Another area worth reviewing is post-delivery activity. No security platform catches everything immediately. Sometimes a threat is identified after a message has already arrived in a mailbox. Defender’s automated remediation features can remove those messages automatically, but unless you’re reviewing reports, you may never know how often that’s happening. Post-delivery activities report [learn.microsoft.com]

This is an important lesson for any organisation using Microsoft 365. Security isn’t only about prevention. It’s also about detection and response.

Why This Matters More in the Age of Copilot

As organisations adopt Microsoft 365 Copilot, the quality and security of their Microsoft 365 environment becomes even more important.

Copilot works across Outlook, Teams, SharePoint and OneDrive. The more information available inside Microsoft 365, the more valuable Copilot becomes. However, that also means security teams need confidence that threats are being managed effectively.

I’ve seen organisations focus heavily on Copilot deployment while overlooking the visibility tools already sitting inside Microsoft Defender. Before chasing the next AI capability, make sure you understand what is happening inside your environment today.

A practical example might be reviewing a phishing campaign shown in Defender reports and then using Microsoft 365 Copilot in Excel to analyse trends over time or prepare management summaries from the collected data. That’s a real-world workflow that combines security visibility with AI assistance.

Stop Flying Blind

One of the biggest mistakes I see in small and medium businesses is treating security as a set-and-forget exercise. Security policies get deployed, everyone feels confident, and then nobody checks whether the controls are actually delivering the expected outcome.

The Defender for Office 365 reports provide the missing feedback loop.

If you’re already paying for Microsoft Defender for Office 365 through licences such as Microsoft 365 Business Premium, E5 or Defender for Office 365 plans, these reports are often sitting there waiting to be used. Defender for Office 365 reports [learn.microsoft.com]

My recommendation is simple. Schedule time every month to review the data. Look at what is being blocked, what is slipping through, and how protection is performing over time. Trends are often more important than individual incidents.

Security isn’t about having controls. It’s about knowing whether those controls are working.

And in my experience, the organisations that regularly review their security reports are almost always in a stronger position than those that don’t.

If You’re Worried About Security, Should You Even Be Doing AI?

The people most concerned about AI security are often the people who should be using AI first.

That sounds backwards, but hear me out.

I still meet organisations that have effectively banned AI because someone raised concerns about data leakage, privacy, compliance or intellectual property protection.

Meanwhile, staff are already using AI on personal devices, free online tools and consumer accounts completely outside corporate visibility.

That’s not security.

That’s avoidance.

The better question isn’t whether you should use AI.

The real question is whether you’re prepared to manage it properly.

What is AI security, really?

Many people think AI security is about stopping users from accessing AI tools.

I think that’s an outdated view.

AI security is about controlling how organisational data is accessed, processed and governed when AI becomes part of everyday work.

Notice what’s missing?

The AI itself.

The same principles we’ve applied to email, file sharing, Teams, SharePoint and mobile devices now apply to AI. Identity matters. Permissions matter. Data classification matters. Monitoring matters.

The organisations that already have these foundations in place are often much better positioned for AI adoption than they realise.

“Isn’t this just another technology that introduces risk?”

Every technology introduces risk.

Email introduced risk.

Cloud services introduced risk.

Mobile devices introduced risk.

The objective has never been to eliminate risk. The objective has always been to manage it.

Step-by-Step: Preparing Microsoft 365 for AI

Review Your Permissions

Open:

Microsoft 365 Admin Centre > Reports > Usage

and

SharePoint Admin Centre > Active Sites

Look for locations that contain sensitive information and identify who has access.

AI doesn’t magically create new permissions.

It simply makes existing permissions more visible and more useful.

If everyone can access everything today, AI will expose that problem faster.

Check Sharing Settings

Open:

SharePoint Admin Centre > Policies > Sharing

Review whether users can create anonymous sharing links or share broadly outside the organisation.

Many organisations discover their biggest security exposure has nothing to do with AI.

It’s uncontrolled sharing.

Microsoft provides useful guidance in its documentation on https://learn.microsoft.com/sharepoint/modern-experience-sharing-permissionsSharePoint sharing and permissions.

Classify Important Data

Open:

Microsoft Purview Portal > Information Protection

Apply sensitivity labels to important content.

Start simple.

Financial information.

Client information.

HR records.

Commercial agreements.

You don’t need a hundred labels.

You need a handful that people will actually use.

Microsoft provides detailed guidance on https://learn.microsoft.com/purview/sensitivity-labelssensitivity labels.

Configure Data Protection

Open:

Microsoft Purview Portal > Data Loss Prevention

Create policies that prevent sensitive information being shared incorrectly.

Think of this as putting guard rails around the business rather than trying to control every individual action.

A good starting point is Microsoft’s guidance on https://learn.microsoft.com/purview/dlp-learn-about-dlpData Loss Prevention.

Monitor and Improve

Open:

Microsoft Purview Portal > Audit

Review activity regularly.

Look at what users are doing.

Look at sharing behaviour.

Look at data movement.

Security isn’t a project.

It’s an ongoing discipline.

Why this actually changes behaviour

This is where I think many organisations miss the opportunity.

AI doesn’t just increase productivity.

It exposes operational weaknesses.

If permissions are messy, AI highlights it.

If data governance is weak, AI highlights it.

If information is scattered everywhere with no ownership, AI highlights it.

That’s a good thing.

For years, many businesses have accumulated technical debt around information management because users could only find information if they knew exactly where to look.

AI changes that equation.

Suddenly information becomes discoverable.

Suddenly forgotten files become valuable.

Suddenly people start asking questions about why certain information is available to everyone.

Those are all governance conversations that should have happened years ago.

AI isn’t creating new security problems as much as it’s revealing existing ones.

That’s an important distinction.

Visibility drives accountability.

The organisations seeing the best outcomes are not necessarily the ones with the biggest security budgets.

They’re the ones with the best operational habits.

Permissions are reviewed.

Data is classified.

Sharing is controlled.

Access is monitored.

Those practices were valuable before AI.

They’re even more valuable now.

Copilot doesn’t invent information. It works with what you’ve already allowed people to access.

That’s one reason I encourage organisations to start their AI journey even when they have concerns.

The process often becomes a catalyst for improving overall security.

If you’re not showing clients this, you’re leaving value on the table.

Many SMBs have spent years investing in Microsoft 365 security controls they barely use.

AI provides a practical reason to finally turn those investments into operational practices.

Here’s the real win.

The organisations that approach AI through a security lens often end up improving both.

They strengthen governance, improve data quality, reduce risk and gain productivity at the same time.

Not because AI solved the problem.

Because AI forced them to look at the problem.

Security shouldn’t stop your AI journey.

Security should shape it.

When done properly, AI isn’t the risk.

The absence of governance is the risk.

Before You Buy Microsoft 365 Copilot, Clean Up Your Tenant First

One of the biggest mistakes I continue to see with Microsoft 365 Copilot is treating the licence purchase as the project.

It’s not.

The licence is the easy part. The hard part is making sure the information Copilot can access is actually worth finding.

Copilot doesn’t create information. It exposes what already exists.

If your tenant is messy, overshared and unmanaged, Copilot simply helps users find the mess faster.

What is Microsoft 365 Copilot readiness, really?

Most people think readiness is about licences, supported apps and technical prerequisites.

That’s not readiness. That’s procurement.

Real readiness means asking whether your Microsoft 365 environment contains information that is organised, secured and governed well enough for AI to work across it. Microsoft talks about defining your strategy, protecting sensitive data and checking readiness before rollout in its Microsoft 365 Copilot rollout guidance.

Copilot works across the data users already have access to. That should make every MSP pause.

Because if users already have access to content they shouldn’t, Copilot won’t politely ignore it. It will work with the permissions you’ve given it.

Step-by-Step: Review your tenant before assigning licences

Audit SharePoint permissions

Start with SharePoint.

This is where a lot of the Copilot value lives, and it’s also where many of the surprises hide.

Review high-value sites, external sharing, broad groups, anonymous links and old project workspaces. Microsoft has specific guidance around building a secure and governed data foundation for Copilot, including oversharing remediation and guardrails.

Notice what’s missing?

Most SMB tenants have never had a proper SharePoint permissions review.

Review OneDrive ownership

Every OneDrive is effectively a knowledge repository.

Look for departed staff, abandoned content, sensitive folders and business-critical files that only one person controls.

Copilot won’t know whether that file belongs in a managed SharePoint library instead. It will simply see information the user can access.

Clean up Teams sprawl

Open the Teams admin centre and look at inactive teams, duplicated teams and channels nobody owns.

If humans can’t tell which Team contains the source of truth, don’t expect Copilot to magically understand your operating model.

“We thought Copilot was giving bad answers.”

In many cases, the tenant was giving bad data.

Review sensitivity labels

If you use Microsoft Purview, check whether sensitivity labels exist, whether they’re published to the right users and whether people understand them.

Sensitivity labels are not decoration. They classify and can protect organisational data across Microsoft 365, as Microsoft explains in its sensitivity labels documentation.

Keep labels simple.

A label nobody understands is just another button nobody presses.

Check retention and stale content

Old content is not harmless just because storage is cheap.

Review retention policies, old libraries, archived Teams and documents that should no longer be active reference material.

Copilot can make stale content visible again.

That’s not intelligence. That’s exposure.

Validate identity and device controls

Before assigning Copilot licences, review MFA, Conditional Access, privileged accounts and device compliance.

This is where SMBs often underinvest.

They buy the AI licence, but the tenant still has weak identity hygiene and unmanaged devices.

That’s backwards.

Decide how you’ll measure usage

Don’t wait until renewal time to ask whether Copilot is working.

Set expectations early. The Microsoft 365 admin centre includes a Microsoft 365 Copilot usage report for adoption and usage metrics.

That matters because licence assignment is not adoption.

A user having Copilot and a user changing the way they work are two different things.

Why this actually changes behaviour

Here’s the real win.

A Copilot readiness review improves the tenant even before you assign the first paid licence.

Permissions get cleaned up.

Teams become easier to navigate.

Content ownership improves.

Old information gets archived.

Security conversations become practical instead of theoretical.

Copilot doesn’t get tired. Use that.

But don’t ask it to compensate for years of neglected governance.

The best Copilot deployments I’ve seen don’t start with a licence order. They start with a conversation about data, access and outcomes.

My recommendation?

Treat Copilot readiness as an MSP service, not a pre-sales checklist.

If you’re not showing clients what Copilot might expose before they pay for it, you’re leaving value on the table.

Microsoft 365 Copilot isn’t there to fix a messy tenant.

It’s there to make a well-run tenant dramatically more useful.

Entra ID Password Protection + Smart Lockout

People still obsess over password complexity.

Twelve characters. Special symbols. Rotation every 90 days.

And yet accounts still get compromised.

That’s because attackers don’t guess random passwords anymore. They guess human passwords.

That’s not a complexity problem. That’s a behaviour problem.

So instead of arguing about password rules, I push clients to focus on two things they already have in Microsoft 365:

Password Protection and Smart Lockout.

Quietly running. Often ignored. Rarely tuned.

Here’s what actually matters.

What is Entra ID Password Protection + Smart Lockout, really?

It’s not a password policy.

It’s a filter and a shield.

Password Protection stops users from choosing bad passwords in the first place.

It uses a global banned password list driven by Microsoft telemetry and blocks weak or common passwords automatically—no configuration required. [learn.microsoft.com]

On top of that, you can add your own banned terms. Company names. Locations. Products. The obvious stuff attackers try first.

Then there’s Smart Lockout.

This is what most people misunderstand.

It’s not “lock the account after X attempts”.

That’s old thinking.

Smart Lockout can distinguish between a real user fat-fingering a password and an attacker trying thousands of guesses. [learn.microsoft.com]

Same identity. Different treatment.

Attackers get blocked quickly.

Real users keep working.

That’s not a nicer lockout policy.

That’s a signal-driven control.

“But we already have account lockout on-prem.”

Exactly.

And that’s the problem.

Step-by-Step: Tune Password Protection and Smart Lockout

Portal only. No scripts. No excuses.

1. Open Password Protection settings

Go to:

Entra admin centre
→ Protection
→ Authentication methods
→ Password protection

This is the only place you need.

2. Add a custom banned password list

Add terms like:

Company name variations
Internal product names
Common abbreviations
Location names

These get evaluated alongside the global list and block weak variants automatically. [learn.microsoft.com]

Not just exact matches.

Variants.

That’s the key.

3. Review Smart Lockout threshold

Default is:

Around 10 failed attempts before lockout [learn.microsoft.com]

Most SMBs never touch this.

My recommendation?

Lower it slightly only if you understand user behaviour.

Too low and you create support tickets.

Too high and you give attackers room to work.

You’re not tuning numbers.

You’re tuning friction.

4. Set lockout duration

Default starts short (around a minute) and increases with repeated attempts. [learn.microsoft.com]

That’s deliberate.

Short for users.

Painful for attackers.

If you override this, be careful.

Long lockouts punish users.

Short lockouts reward attackers.

5. Leave Smart Lockout on (always)

Important:

Smart Lockout is already enabled.

There’s nothing to “turn on”.

There’s only:

Leaving it alone
Or breaking it

6. Pair it with MFA (properly)

Password protection is not enough.

Microsoft is very clear on that.

Use it alongside MFA and Conditional Access. [learn.microsoft.com]

Otherwise you’re just slowing attackers down.

Not stopping them.

Why this actually changes behaviour

This is the part most MSPs miss.

These features don’t just block attacks.

They retrain users.

Bad password?

Rejected.

Repeated guessing?

Blocked.

Users learn quickly what works and what doesn’t.

No training session required.

No PDF sent out.

No awareness campaign.

The system corrects behaviour in real time.

“We’ll just educate users instead.”

You can.

Or you can enforce it once and let the platform do it forever.

Ask once. Enforce always.

Here’s the real win:

Fewer compromised accounts
Fewer lockout tickets
Fewer “why is this happening?” calls

And importantly:

Better outcomes with less effort

That’s the bit most people overlook.

Notice what’s missing?

No password complexity discussion.

No rotation debates.

No “special characters required”.

Because those don’t solve the real problem.

Attackers aren’t brute-forcing randomly anymore.

They’re spraying expected passwords across thousands of accounts.

Password Protection removes the obvious targets.

Smart Lockout kills the attack path.

Different layers.

Same outcome.

Passwords aren’t going away.

But weak passwords should.

And repeated guessing definitely should.

Password Protection isn’t there to make passwords stronger.

It’s there to make bad passwords impossible.

Before You Buy the Copilot Licence, Do This First

Everyone wants to know what Copilot can do. Almost nobody asks what Copilot will find.

That’s the question that actually matters. Copilot doesn’t create new access — it works entirely within your existing Microsoft 365 permissions. It can only surface what a user is already allowed to see.

Sounds safe. It’s not. Not if your SharePoint environment looks like most tenants I’ve walked through.

Sites shared with “Anyone with the link” since 2021. Files in folders with permissions no one’s reviewed in years. Ownerless sites stuffed with content nobody knows exists. When your finance manager asks Copilot to “summarise what we know about Project X,” it’ll pull from everything she can already access — including documents she’d have had to know to search for directly.

That’s not a Copilot problem. That’s the data governance problem you already had, just made visible.

My recommendation? Run the readiness assessment before you assign a single licence.

What is the Copilot Readiness Assessment, really?

Most people think readiness means “do you have the right licence and update channel.” The Copilot Readiness Report in the Microsoft 365 admin centre does tell you that — which users are technically eligible, which devices are on the right update channel, who your best pilot candidates are.

That’s the easy half.

The hard half is whether your data is in a state that Copilot should be let near. That check lives in a completely different place, and most readiness guides skip it entirely.

Notice what’s missing? Almost every “Copilot readiness checklist” you’ll find online focuses on licence eligibility. The data side is where the actual risk sits.

Step-by-Step: Running a Proper Readiness Check

Open the M365 Copilot Readiness Report

Go to the Microsoft 365 admin centre. In the left nav, select Reports > Usage, then choose Microsoft 365 Copilot and open the Copilot report. Click the Readiness tab.

You’ll see prerequisite licence counts, update channel eligibility, and a user table flagging suggested Copilot candidates. Export the list. It gives you a concrete starting point for a pilot conversation with your client.

Check for Oversharing in SharePoint

Open the SharePoint admin centre. Go to Reports > Data Access Governance. This is where you find the oversharing risk — sites with “Anyone” sharing links active, files broadly accessible across the tenant, high-member-count sites with no clear owner.

Work through the data access governance reports. Anything flagged here is content Copilot can reach on behalf of any user who has permission.

By default, SharePoint sharing is set to the most permissive option. Most tenants have never changed it.

Run the Content Management Assessment

Still in the SharePoint admin centre, go to Advanced Management > Content Management Assessment and select Start assessment. This surfaces inactive sites, ownerless sites, and sites that haven’t been attested by anyone recently.

SharePoint admin centre
  > Advanced Management
    > Content Management Assessment
      > Start assessment

Rerun it every 30 days. This isn’t a one-time exercise. It’s a recurring conversation starter with every client who has Copilot.

Review Your Sensitivity Labels

Open the Microsoft Purview compliance portal > Information protection > Labels. Check whether labels are deployed and whether content users will ask Copilot about is actually labelled.

Sensitivity labels travel with content. Copilot honours them at response time — it won’t surface content a user doesn’t have decrypt rights for. No labels means no enforceable control over what ends up in a Copilot response.

They’re not a Copilot feature. They’re the floor you build on.

Why This Actually Changes Behaviour

Here’s the real win.

Running this before you sell the licence gives you a different kind of client conversation. Not “here’s what Copilot can do” — but “here’s what your data looks like right now, and here’s what we need to fix before Copilot is safe to use.” That’s a trusted adviser conversation, not a licence upsell.

Microsoft’s Secure & Governed Data Foundation blueprint organises this into three pillars: remediate oversharing, set up guardrails, meet regulations. It’s worth reading before your next client review. Print it. Take it in.

If you’re not showing clients this work before you enable Copilot, you’re not protecting them — you’re just adding a powerful AI to a mess.

Copilot doesn’t create oversharing. It reveals it. Fix the foundation first, then turn on the power.