Security Keeps the Bad Guys Out. Compliance Stops the Good Guys Doing the Wrong Thing.

One of the biggest mistakes I see when talking to organisations about Microsoft 365 is that they treat security and compliance as the same thing.

They’re not.

In fact, I often explain it this way: security is largely about protecting your data from people who shouldn’t have access to it, while compliance is about making sure people who do have access don’t misuse it.

Both matter. Both are essential. But they solve completely different problems.

The Security Mindset

When most people think about protecting information, their mind immediately goes to external threats.

Hackers trying to steal credentials.

Phishing emails landing in inboxes.

Ransomware attempting to encrypt files.

Business email compromise targeting finance teams.

That’s the world of security. The goal is to prevent unauthorised access and stop attackers before they can do damage.

This is where tools like Microsoft Defender, Conditional Access, Entra ID, multifactor authentication and device management come into play. They create barriers around your data and make it harder for outsiders to gain access.

The challenge is that many organisations stop there.

They invest heavily in security controls, get comfortable that their tenant is well protected, and assume the job is done.

It isn’t.

Because once someone is legitimately inside the organisation, security has largely done its job.

That’s where compliance starts.

The Compliance Challenge

Imagine an employee has access to customer records as part of their daily role.

They’re not a hacker.

They’re not bypassing security controls.

They’re simply using information they have permission to access.

Now imagine they accidentally email a spreadsheet containing sensitive customer information to the wrong person.

Or upload confidential financial data to an unauthorised location.

Or paste company information into an AI tool that hasn’t been approved by the organisation.

Security didn’t fail here.

The employee had legitimate access.

The issue is what happened after access was granted.

That’s a compliance problem.

Compliance is about governing how information is used, shared, stored and protected after someone is authorised to see it.

Why Copilot Makes This More Important

The rise of Microsoft 365 Copilot makes this distinction even more critical.

Copilot operates using the permissions that already exist within your Microsoft 365 environment. If a user has access to information in SharePoint, OneDrive, Teams or Exchange Online, Copilot can help them work with that data.

That’s why I continually tell organisations that Copilot readiness isn’t just about licensing. It’s about information governance.

I’ve seen organisations excited about deploying Copilot only to discover that sensitive documents are stored in locations where far too many people have access. The problem isn’t Copilot. The problem is that existing permissions and governance weaknesses become much more visible once AI enters the picture.

If your data is overshared, Copilot can expose that reality very quickly.

Security and Compliance Need Equal Attention

The best organisations understand that security and compliance are two sides of the same coin.

Security asks:

“Who should be allowed in?”

Compliance asks:

“What should they be allowed to do once they’re inside?”

In Microsoft 365, that means combining strong security controls with technologies such as Microsoft Purview, sensitivity labels, data loss prevention policies, retention controls and information protection.

One protects the front door.

The other governs what happens in the rooms beyond it.

Ignore either one and you’re leaving your organisation exposed.

Final Thoughts

I think many businesses are still more comfortable talking about security than compliance because security threats are easier to visualise. We can picture a hacker attacking our systems.

What’s harder to visualise is an employee accidentally sharing the wrong file, retaining information for too long, or exposing sensitive data through everyday work practices.

Yet those risks can be just as damaging.

As AI becomes more deeply woven into Microsoft 365, the organisations that succeed won’t simply have the strongest security. They’ll also have the maturity to govern their information properly.

Security protects your organisation from outsiders.

Compliance protects your organisation from itself.

And increasingly, you need both.

The Login Screen Looks Simple. The Decision Behind It Is Not.

I worry that sign-in security is still treated like a mystery box in too many Microsoft 365 environments.

A user enters a password. Something happens behind the scenes. Maybe MFA appears. Maybe Conditional Access blocks the request. Maybe the sign-in works because the policy did not apply as expected. Then, when something goes wrong, the first question is usually, “Why did Microsoft let that happen?”

That is the wrong question.

The better question is: did we understand the path that sign-in actually took?

That is why I like simple visual tools such as the Microsoft 365 login simulator. Not because they replace proper testing in Entra. They do not. I like them because they make the invisible visible. They let people walk through authentication logic without starting inside a dense admin portal.

Authentication is where theory meets reality

Most businesses think they have secure login because they have MFA turned on. That is a start, but it is not the full story.

In the real world, sign-in decisions are messy. A user might be on a managed device, a personal laptop, or public Wi-Fi. They might be coming from a known location, a strange location, or through a service that does not behave like a normal browser session.

This is where Microsoft Entra ID, Conditional Access, MFA, device compliance and sign-in risk start to matter. They are not isolated controls. They are a decision chain.

For an MSP, that chain needs to be explainable.

I have sat in enough client conversations to know that saying “we enabled MFA” does not always land. A business owner wants to know what happens when an account is attacked. A help desk person wants to know whether the issue is identity, device, location, policy, licensing or behaviour.

A simulator gives you a conversation starter. It turns the abstract into something you can point at.

Copilot still depends on identity hygiene

Microsoft 365 Copilot does not remove the need for clean identity controls. If anything, it raises the stakes. When someone asks Copilot in Teams to summarise a channel, or uses Copilot in Word to draft from files in SharePoint, the experience depends on the access that user already has.

That means sign-in is not just a security event. It is the front door to organisational knowledge.

If a compromised account gets through that front door, the issue is no longer just email. It may include documents, chats, meetings and shared files. For an SMB, that is a business risk, not a technical footnote.

So when I look at a login simulation, I am thinking about what the user can reach after access is granted.

Use the simulator to teach judgement

The best use of a tool like this is not to frighten people. It is to build judgement.

Run through a few scenarios with a client or your own team. What should happen for a global administrator? What should happen for a user on an unmanaged device? What should happen for a login from a location the organisation never normally uses? Where does the policy catch the risk?

Then compare that ideal path with what your tenant is configured to do.

That gap is where the work is.

For MSPs, this is a better advisory conversation. You are not just selling another security setting. You are helping the client understand how identity, access and data exposure connect. That moves the discussion away from checkbox compliance and towards resilience.

My view is simple. If you cannot explain the sign-in path, you probably do not control it as well as you think.

The login screen looks simple. The decision behind it is anything but.

The simulator is here – https://directorcia.github.io/Office365/m365-login-sim.html

and the documentation is here – https://github.com/directorcia/Office365/wiki/M365-Sign%E2%80%90In-and-Conditional-Access-Flow-Simulator

Mail Security Is Easier to Understand When You Can See It

One of the recurring problems with Microsoft 365 mail security is that too many people treat it like a checklist. SPF. DKIM. DMARC. Spoof intelligence. Anti-phishing. Safe Links. Quarantine. Transport rules. Tick the boxes, move on, hope the tenant is safer than it was before.

I understand why that happens. Email security in Microsoft 365 has a lot of moving parts, and most of them are hidden until something goes wrong. A message lands in junk. A phishing email reaches a user. A legitimate invoice disappears into quarantine. Then everyone starts asking the same uncomfortable question: why did that happen?

That is why I like building simple simulation tools, like the one I just created here:

https://directorcia.github.io/Office365/m365-mail-security-sim.html

The value is not the button. It is the model.

The point of a mail security simulator is not to replace the Microsoft Defender portal. It is to help people build a clearer mental model before they start changing live settings.

When I work with SMBs and MSPs, I often see the same pattern. Someone knows one part of the stack very well, usually Exchange Online mail flow or DNS authentication, but they are less confident about how that choice affects the next decision. Enforcing DMARC sounds sensible. Tightening spoof handling sounds sensible. Adjusting user reporting sounds sensible. The problem is that sensible settings can still create poor outcomes if you do not understand how they interact.

A simulator gives you a low-risk way to explore that. Change the assumptions. Watch the likely outcome. Ask what would happen if the sender fails authentication, if the domain is aligned, if policy handling changes, or if the user has been trained to report suspicious mail through Outlook. You are not learning by breaking production. You are learning by testing the shape of the decision.

Copilot still needs clean security thinking.

This becomes even more important as Copilot becomes part of the working day. People are asking Copilot in Outlook to summarise long email threads, draft replies, and pull meaning from busy inboxes. That only works if the mailbox environment is trustworthy enough in the first place.

Copilot does not remove the need for Defender for Office 365, Exchange Online Protection, authentication alignment, or sensible quarantine handling. If anything, it raises the standard. The more value we expect people to get from their Microsoft 365 data, the more responsibility we have to make sure the signals around that data are well managed.

That is the message I want administrators and MSPs to take seriously. AI does not excuse messy security. It exposes it.

Training beats guessing.

Good security administration is not just knowing where the settings are. It is knowing what trade-offs you are making when you change them.

A tool like this can help an MSP have a better client conversation. Instead of saying, “we should improve your mail security,” you can show the client how different conditions affect message handling. Instead of turning a policy into an abstract recommendation, you can make the risk visible enough for a business owner to understand.

It also helps junior technicians. I would much rather see someone experiment with a simulation than make random changes inside the Defender portal because they found a setting that sounded important. Curiosity is good. Production tenants are a poor classroom.

Microsoft 365 security has become too important to be treated as a collection of isolated switches. Mail protection, user behaviour, reporting, policy tuning, and now Copilot readiness all sit together. If you cannot explain how the pieces connect, you are not really managing the system. You are just hoping the defaults are enough.

The next step for many organisations is not more noise, more dashboards, or more alerts. It is better understanding.

That starts by making the invisible parts of mail security visible enough to reason about.

You’ll find the simulation I just created here:

https://directorcia.github.io/Office365/m365-mail-security-sim.html

it’s free to use but I’d always appreciate any support you can provide around this and upcoming simulation projects via – https://ko-fi.com/ciaops.

Also, feel free to provide me any feedback on the simulation so I can continue to improve it for all.

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.