Your sensitivity labels aren’t doing anything

Most clients I work with have sensitivity labels deployed. They’ll show me the dropdown in Word — Confidential, Internal, General, Public — and say, “We set that up during the M365 rollout.”

Fair enough. But when I ask how much of the content in SharePoint and OneDrive is actually labelled, the answer is almost always a pause. And then: “Not sure, to be honest.”

Which means almost nothing.

Users don’t apply labels manually. Not because they’re careless — but because asking someone to classify a document before they can save it is friction, and people route around friction every single time. If your labelling strategy depends on the human hitting that dropdown, it’s not a strategy. It’s wishful thinking.

That’s not a training problem. That’s a deployment gap.

What is auto-labelling, really?

There are two very different things living under this name, and mixing them up is exactly where most tenants stall.

The first is client-side auto-labelling. This is built into the sensitivity label itself — when a user opens a document or composes an email, the Office app scans the content and either suggests a label or quietly applies one. It’s useful. But it only fires when someone has a file open.

The second — and the one I want you to focus on — is service-side auto-labelling. This is a separate auto-labelling policy you create in Microsoft Purview. It runs in the background, continuously scanning SharePoint, OneDrive, and Exchange. No user involvement. Files sitting in SharePoint from two years ago? Scanned. Emails passing through Exchange right now? Scanned.

The labels go on whether the user ever touched the file or not.

Labels that apply themselves. That’s the actual goal.

Step-by-Step: Creating a service-side auto-labelling policy

One prerequisite: sensitivity labels must exist and be published before you create auto-labelling policies. If they’re not set up yet, start there.

Then, in the Microsoft Purview portal:

Open Information Protection > Policies > Auto-labelling policies

Sign in to purview.microsoft.com. Navigate to Solutions → Information Protection → Policies → Auto-labelling policies, then select + Create auto-labelling policy.

Choose a template or go Custom

Microsoft provides templates for common data types — financial data, personal data by region (there’s an Australian one), health records. Start with a template to see the shape of a policy, or go Custom if you want full control over which sensitive information types trigger the label.

Name the policy and pick the label

Give it a name that tells a story: “Confidential – Tax File Numbers – SharePoint” is more useful than “Auto-label policy 1.” Then select which sensitivity label gets applied on a match.

Select your locations

Pick SharePoint, OneDrive, Exchange, or all three. Scope to specific sites or users, or leave it at All. Start narrow — one site or department — until you’ve seen the simulation results.

Write the rule

This is the substance of the policy. Here’s a simple example:

If content contains:
  Sensitive info type: Tax file number (Australia)
  Confidence level: High
  Instance count: 1 or more
→ Apply label: Confidential

Notice what’s missing? A user making a decision.

Run simulation first — always

Before the policy applies a single label, run it in simulation mode. Purview crawls the selected locations and shows you a matched-files list without changing anything. Review it. Look for false positives. Check the count. When you’re satisfied, activate the policy.

Why this actually changes behaviour

Once service-side auto-labelling is running, you stop being dependent on user habits to build label coverage.

Here’s the real win: every downstream control that references sensitivity labels now has something to reference. DLP policies that trigger on Confidential content have labelled files to fire on. Conditional Access policies that restrict access by label context have something to evaluate. And Copilot respects sensitivity labels when deciding what to surface in responses — which means your Copilot governance story only works if the labels are actually on the files.

Before: “We set up sensitivity labels in the rollout.”

After: “We have auto-labelling policies running across SharePoint and Exchange, and the Purview dashboard shows 87% of our content is classified.”

One of those answers a cyber insurance question. The other is a checkbox nobody can verify.

The Purview data classification dashboard shows label coverage across your whole tenant. After a few days with auto-labelling running, watch that coverage number move. That’s the metric that matters when an auditor or an insurer asks how sensitive data is classified and protected.

My recommendation? Start with one workload, one sensitive info type, one site. Run simulation. Check the results. Turn it on. Then expand.

The platform knows how to classify. You just have to let it.

Sensitivity labels without auto-labelling are just a menu no one orders from. Turn on the scanner, let Purview do the work your users never will, and then show your clients the dashboard.

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.

Sensitivity labels and auto-labelling: put a name on your data

Most people meet sensitivity labels the wrong way.

They see encryption and Purview and compliance in the same sentence and decide it’s an enterprise problem. Something for banks. Something that needs E5, a consultant, and six months.

So they leave the whole thing switched off.

Then a client emails a payroll spreadsheet to the wrong “David” in the address book, and it becomes very much their problem.

Here’s what I want you to understand. A sensitivity label isn’t a lock. It’s a name tag you put on information so Microsoft 365 knows how to treat it — and most of the value shows up before you’ve encrypted a single file.

What are sensitivity labels, really?

A sensitivity label is a tag that travels with the content. Apply Confidential to a Word doc and that label rides along into SharePoint, OneDrive, Teams, and the email it’s attached to — even off your tenant, if you allow it.

What the label does is up to you. It can simply mark the document with a header, footer, or watermark. It can show a visual classification users notice. Or it can go further and encrypt the file so only the right people open it.

That range is the bit people miss. You don’t have to start with encryption. You can start with classification — and classification on its own changes how people handle a file.

Step-by-Step: build your first label

Everything lives in the Microsoft Purview portal at purview.microsoft.com, under Information Protection. Microsoft seeds new tenants with a default set, but build and publish your own so the names actually mean something to your client.

Turn on labels for files

Before a label will stick to documents in SharePoint and OneDrive, go to Settings > Information Protection and turn on co-authoring for files with sensitivity labels. Skip this and your labels won’t apply to files at rest. It catches everyone once.

Create the label

Under Information Protection > Sensitivity labels, select Create a label. Give it a name your users will understand, not a compliance codeword. Set the scope to Files and emails.

Decide what it does

Now choose protection. Content marking — a header, footer, or watermark — is the gentle option. Access control with encryption is the heavy one. For your first label, pick marking. You can add teeth later.

Publish it

A label nobody can see does nothing. Create a label policy, add your label, and publish it to a group of users. Now it shows up under the Sensitivity button in Word, Excel, PowerPoint, and Outlook.

That’s a working label. Manual, user-applied, and included with the sensitivity-label entitlement most of your Business Premium clients already hold.

Step-by-Step: let the tenant do the labelling

Manual labels rely on people remembering. People don’t. So the next step is auto-labelling — and this is where the licensing line sits, so be straight with clients.

Pick your method

There are two. Client-side auto-labelling prompts or applies a label while someone edits a document in Office. Service-side auto-labelling policies scan content already sitting in SharePoint and OneDrive, plus mail moving through Exchange, with no user involved at all.

Run it in simulation first

This is the setting that saves you. An auto-labelling policy runs in simulation mode — it shows you exactly what would get labelled across the tenant without touching a thing. My recommendation? Always simulate, read the matches, fix your conditions, then turn it on.

Mind the licence

Auto-labelling — both flavours — needs the E5-tier Information Protection entitlement, not the base Business Premium one. Manual labels are included. Automatic ones aren’t. Don’t promise a client auto-labelling on a licence that doesn’t carry it.

“So do I need encryption on everything?” No. Most of my labels never encrypt anything. They classify. Encryption is reserved for the one or two labels that genuinely need it.

Here’s a starter taxonomy worth copying:

Personal
Public
General
Confidential
Highly Confidential

Notice what’s missing? Encryption — on four of the five. The top label might lock files down. The rest just name the sensitivity so people, and the tenant, treat them accordingly. Classification first, control second.

Why this actually changes behaviour

A labelled file behaves differently. DLP policies can key off the label. Auto-labelling can find the credit-card numbers your user forgot were buried in an old quote. And both SharePoint and Copilot respect the access a label enforces — which matters more every month.

But the quiet win is human. When someone clicks Confidential and a watermark appears, they slow down. They think before they forward. The label is doing the teaching.

Set it up once. It keeps working while everyone’s asleep.

Sensitivity labels aren’t there to make compliance harder. They’re there to make a careless mistake hard to make by accident.

If you’re rolling out Microsoft 365 and your clients’ data still has no name on it — that’s the gap. Put a name on it.

The Compliance Conversation You’re Avoiding Will Eventually Find You

I had a chat recently with a business owner who runs a tidy operation — about fifteen staff, healthy margins, the sort of place that quietly does well without ever making noise. Halfway through, I asked how they were tracking on privacy and security obligations. The answer was a laugh and a wave of the hand. “Mate, we’re too small for anyone to care about that.”

I’ve heard that line more times than I can count. And I understand why people say it. When you’re flat out keeping the lights on, compliance feels like a problem reserved for the big end of town — banks, hospitals, listed companies with legal departments. The trouble is, that comfortable assumption is quietly expiring, and most small businesses haven’t noticed.

The rules are walking towards you, not away

For years, smaller organisations sat below the threshold of most privacy regulation. That gap is closing. Governments around the world are tightening data protection laws and shrinking the carve-outs that used to let small businesses off the hook. Here in Australia, the conversation about extending privacy obligations to organisations that were previously exempt has been building for a while, and it isn’t going to reverse.

So the question isn’t whether regulation reaches your business. It’s whether you’ll be ready when it does, or scrambling because you assumed it never would.

What strikes me is how avoidable the scramble is. A lot of what compliance asks for is simply knowing what data you hold, where it lives, who can touch it, and what happens if it walks out the door. If you’re running Microsoft 365, you already have the tools to answer those questions. Microsoft Purview can show you where sensitive information sits across your tenant and flag where it’s being shared in ways it shouldn’t be. That’s not a future purchase. For most small businesses, it’s sitting in a licence you already pay for and have never switched on.

Cyber insurance is doing the regulating for now

Here’s the part that catches people off guard. While the laws are still catching up, your insurer has already arrived. The renewal questionnaire for cyber insurance has become a de facto compliance audit, and it’s getting longer every year.

Do you enforce multi-factor authentication? Do you have email filtering? Are backups tested? Who has administrator access? I’ve watched owners stare at these forms with genuine surprise, because nobody warned them that a policy renewal would turn into a security interrogation. And the consequences are real — answer loosely, suffer an incident, and you may find the claim contested because the controls you ticked weren’t actually in place.

This is where I tell people to stop treating the questionnaire as paperwork and start treating it as a checklist worth acting on. Turn on MFA through Entra. Tighten who holds admin rights. Confirm your data is actually backed up, not just assumed to be. None of this is exotic. It’s the same hygiene the regulators will eventually demand, so you may as well do it now while an insurer is the one asking.

Where to start when it feels like too much

The reason this conversation gets avoided is that it feels enormous — like you’d need to stop everything and become a compliance expert overnight. You don’t. You need to start, and starting is smaller than you think.

This is one of those tasks where I’ve found Copilot genuinely useful. Ask it in Word to draft a plain-English data handling policy based on what your business actually does, then refine it. Ask Copilot to summarise the key obligations from a privacy guidance document you’ve been meaning to read for six months. Use it to turn that intimidating insurance questionnaire into a list of specific actions, each owned by someone, tracked in Planner. Suddenly the mountain is a series of steps, and steps are doable.

The point isn’t to achieve perfect compliance by Friday. It’s to be able to show, honestly, that you’ve thought about this and you’re doing something — because “we’re too small to matter” is not a defence that ages well.

The compliance conversation you’re avoiding doesn’t disappear when you ignore it. It just waits, and it tends to introduce itself at the worst possible moment — mid-breach, mid-claim, mid-audit. Far better to have the conversation now, on your own terms, with a coffee in hand and nothing actually on fire. That’s a much nicer way to meet it.

Intune compliance policies + Conditional Access integration

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

DLP and Sensitivity Labels for SMBs: A Practical Copilot Readiness Playbook

Most SMB data protection projects fail for one reason: teams optimize the label taxonomy before fixing access control. That creates a “labeled mess” instead of a governed environment. In practical terms, a “Confidential” label cannot compensate for a SharePoint site still shared with broad legacy permissions.

A safer and faster implementation sequence is: Permissions cleanup -> Sensitivity labels -> DLP tuning -> Copilot enablement. This order aligns with real-world Copilot risk patterns, where oversharing is usually the primary exposure pathway.

The Category Error to Avoid

The common debate in SMB projects is “How many labels should we deploy?” (for example, 4 vs 8 vs 12). That is the wrong first question. The first technical question is: “Are current permissions precise enough for labels to have security meaning?”

If broad groups, stale sharing links, and inherited permissions still expose sensitive locations, adding more labels mostly increases administrative overhead and user confusion. Copilot does not create this condition, but it can reveal it quickly by making discoverable content easier to surface through natural language prompts.

Reference Architecture for SMB Tenants

Use a minimal, repeatable baseline that can be implemented and operated by small IT teams.

1. Permissions Layer (Foundational)

Identify and remove broad default access patterns (for example, “Everyone except external users” where inappropriate).
Review high-risk SharePoint and Teams locations first: HR, Finance, Leadership, M&A, Legal, payroll artifacts.
Remove stale members from privileged Microsoft 365 groups and Teams.
Expire or revoke old anonymous or org-wide links where business value no longer exists.
Document approved sharing patterns by site type (departmental, project, external collaboration).

2. Label Layer (Classification)

Start with a compact taxonomy, then expand only with evidence.

Public – content approved for unrestricted internal and external use.
Internal – default business content for internal sharing.
Confidential – restricted business-sensitive data.
Highly Confidential (optional) – strongest controls, often encryption-backed.

Keep label names plain and user-comprehensible. If users cannot predict where a label applies, adoption and accuracy collapse.

3. DLP Layer (Policy Enforcement)

Deploy DLP in audit mode first (recommended: 60 days).
Prioritize high-confidence detections first (payment card data, national identifiers, banking information).
Monitor policy hits weekly and triage false positives with business owners.
Move to staged enforcement with user notifications before hard blocking where possible.

4. Copilot Layer (Consumption)

Enable Copilot only after oversharing findings are remediated to an agreed threshold. Treat Copilot enablement as a controlled release with explicit go/no-go criteria, not a licensing event.

Why Copilot Changes the Risk Visibility Model

Traditional oversharing could remain hidden for years because users had to know exactly where to look. Copilot lowers search friction by translating intent into broad retrieval across accessible content. This can expose latent permission mistakes quickly.

Oversharing is best treated as an access-control debt problem, not a labeling deficiency.

In practical operations, Copilot acts like a continuous discovery mechanism for permissions debt. If the tenant is clean, Copilot is productive. If not, Copilot surfaces the debt immediately.

60-Day Implementation Runbook

Phase 0 (Week 0): Scope and Governance

Define data protection owner, security owner, and business escalation path.
Agree target controls and business exceptions process.
Set Copilot readiness criteria before technical work begins.

Phase 1 (Weeks 1-2): Permissions Remediation

Run oversharing assessment on SharePoint and Teams-connected sites.
Rank findings by impact: executive, financial, personal data, contractual data.
Remediate critical sites first and verify effective permissions after each change.
Capture exception approvals where broad sharing must remain.

Phase 2 (Weeks 2-3): Label Deployment

Publish 3-4 labels to a pilot user group.
Validate user understanding with short examples and FAQ guidance.
Adjust label descriptions and policy tooltips based on pilot confusion points.

Phase 3 (Weeks 3-8): DLP Audit Mode

Enable DLP in monitor-only mode.
Collect incidents and tune detection thresholds/rules weekly.
Present day-30 report to stakeholders with false-positive and true-positive analysis.
Issue day-45 enforcement impact notice to users and managers.

Phase 4 (Week 9+): Staged Enforcement and Copilot Rollout

Turn on enforcement for highest-confidence policies first.
Enable Copilot for low-risk pilot cohort.
Review user prompts/incidents for unintended access outcomes.
Expand rollout only when no critical oversharing regressions are detected.

Operational Metrics That Matter

Track leading indicators, not just policy counts.

Permissions hygiene: number of high-risk overshared sites before vs after remediation.
Classification adoption: percentage of newly created docs with valid user-applied labels.
DLP quality: true-positive to false-positive ratio per policy.
Readiness confidence: unresolved critical findings at Copilot go-live.
User impact: helpdesk tickets per 100 users post-enforcement.

Common Failure Modes and Corrective Actions

Failure Mode 1: Label Proliferation

Symptom: taxonomy grows to 8-40 labels with low usage consistency.
Correction: reduce to behaviorally distinct labels users can apply accurately.

Failure Mode 2: Permanent Audit Mode

Symptom: policies remain non-enforcing for months or years.
Correction: define enforcement date at project kickoff and publish milestone reports.

Failure Mode 3: Copilot Before Cleanup

Symptom: sensitive content appears in valid-but-unexpected prompt responses.
Correction: block rollout until critical permissions findings are remediated and re-tested.

Practical MSP Packaging

The most successful SMB engagements package this work as Copilot Readiness and Data Access Hardening, not as a one-time “label deployment” project.

Deliverable 1: Oversharing assessment and remediation log
Deliverable 2: Compact label taxonomy and end-user guidance
Deliverable 3: DLP audit report at day 30 and day 60
Deliverable 4: Copilot go-live risk sign-off
Deliverable 5: Quarterly policy and permissions review cadence

Key Data Points to Use with Clients

Purview Suite for Business Premium add-on was announced at $10/user/month (September 2025).
Combined Defender + Purview Suites for Business Premium add-on was listed at $15/user/month.
Working SMB implementations commonly succeed with 3-4 labels, not large taxonomies.
A 60-day DLP audit window is a common practical baseline before enforcement.
Published incidents show that Copilot oversharing exposure typically traces back to legacy permissions.

Conclusion

For SMB tenants, the winning strategy is not maximum policy complexity. It is disciplined sequencing and operational follow-through. Start with permissions. Add a minimal label model. Run DLP in time-boxed audit mode. Enforce in stages. Then enable Copilot.

If you remember one line, use this: Clean access first, classify second, enforce third, accelerate last.

DSPM: The End of Guessing About Your Sensitive Data

Most Microsoft 365 tenants I walk into are flying blind on data.

The sensitivity labels exist. A couple of DLP policies exist. Someone once turned on Insider Risk Management because a consultant said so. And then nothing. Nobody knows what’s working, what’s exposed, or which sensitive files are sitting wide open in a SharePoint site shared with half the planet.

That’s not a security posture. That’s a guess.

The tool that finally ends the guessing is Microsoft Purview Data Security Posture Management. If you’ve got E5 or the Purview Suite and you’re not showing this to your clients, you’re leaving value on the table.

What is DSPM, really?

DSPM is the dashboard that tells you, in plain English, where your sensitive data is sitting unprotected and which users are handling it carelessly. It pulls signals from the tools you already pay for — DLP, Information Protection, Insider Risk Management, Adaptive Protection — and stitches them into one view.

The clever bit is the correlation. Before DSPM, you’d open five different blades, cross-reference three different reports, and still miss half of it. Now the findings and recommendations land on one page, with a one-click path to spin up the matching policy.

That’s not a report. That’s a to-do list with context.

Step-by-Step: turning DSPM on

Portal only. Stay in the GUI — easier for you, easier to hand off to the next admin.

Open the Purview portal

Sign in to the Microsoft Purview portal as a member of the Data Security Management role group, an Insider Risk Admin, or a Compliance Administrator. Global Admin works too, but please don’t use it if you can help it.

Open the DSPM solution

From the home page, go to Solutions → Data Security Posture Management → Overview.

Turn on analytics

On the Overview page, click Turn on analytics. That one switch also enables DLP analytics and Insider Risk analytics behind the scenes if they aren’t already on. One click, three switches. The full checklist is in the Get started with DSPM article.

Wait

Yes, really. The automated scan across your tenant can take up to three days on anything larger than a handful of users. Walk away. Brew a coffee. Come back on Thursday.

Review the recommendations

Back on the DSPM dashboard, open Recommendations. Each one tells you what was found, why it matters, and offers a one-click path to create the DLP or Insider Risk policy that fixes it. You don’t start from a blank policy screen anymore — you start from your tenant’s real gaps.

Track trends over time

Use the Analytics and Reports tabs in client reviews. A trend line of risky activity going down beats any invoice justification I’ve ever tried to write.

Why this actually changes behaviour

“Are we protected?”

That’s the question every SMB owner asks. Most of us have been answering with vibes. Good vibes, educated vibes, but vibes.

DSPM changes the answer. You can point at a number. You can point at a recommendation you actioned last month and the unprotected file count that dropped because of it. You can show, not tell.

For MSPs, that’s a QBR slide that sells itself. For internal IT, it’s the evidence you need when the CFO asks what the Microsoft Purview licence is actually doing for the business.

And if Copilot is already in the tenant — which, let’s be honest, it increasingly is — then DSPM for AI is your next stop. Same lens, pointed at what people are pasting into Copilot prompts and what’s flowing back out.

Copilot doesn’t slow down. Neither does your data sprawl. Use something that keeps up.

DSPM isn’t there to create more work. It’s there to stop the guessing.

Are We Copilot‑Ready?

A practical readiness checklist for SMBs using Microsoft 365

Purpose:
Microsoft 365 Copilot works only within the permissions, data, and policies you already have. This checklist helps confirm whether your tenant is ready—or whether Copilot will simply surface problems faster.

You don’t need to score 100%. You do need to know where the risks are.

1️ Identity & Access (Foundation)

✅ We have Entra ID (Azure AD) accounts for all staff
✅ Multi‑factor authentication (MFA) is enforced for all users
✅ Admin roles are limited and reviewed periodically
✅ Former employees and guest users are removed promptly
✅ Conditional Access is in place for risky sign‑ins or devices

If “No” appears here:
Copilot will still work—but with higher security risk.

2️ Licensing Reality Check

✅ We understand the difference between:

Copilot Chat (Basic)
Microsoft 365 Copilot (Paid / Premium)

✅ We know which roles actually need Copilot licences
✅ We are not assuming “everyone gets it for free”
✅ Business Premium (or E3/E5) is in place for users handling sensitive data

If unclear:
Expect confusion, helpdesk tickets, and poor adoption.

3️ SharePoint & OneDrive Permissions (The Big One)

✅ SharePoint sites have clear owners
✅ Access is based on need, not convenience
✅ “Everyone” or “Anyone with the link” sharing is controlled
✅ Old project sites are archived or cleaned up
✅ We’re comfortable with Copilot summarising what users can access

Reality check:
Copilot doesn’t break permissions—it makes them obvious.

4️ Sensitivity Labels & Data Classification

✅ Sensitivity labels exist (even if only a few)
✅ Labels are applied to key documents and libraries
✅ Staff understand “Public vs Confidential” at a basic level
✅ We know Copilot respects sensitivity labels
✅ We are aware auto‑labelling may change labels automatically

Minimum viable setup:
Public / Internal / Confidential is often enough to start.

5️ Data Loss Prevention (DLP) Basics

✅ DLP is enabled for email and files
✅ Alerts or user warnings exist for sensitive data sharing
✅ We accept that Copilot follows the same DLP rules
✅ IT monitors DLP incidents (not just blocks them)

Without DLP:
Copilot can still answer—but may summarise data you’d rather it didn’t.

6️ Devices & Work Locations

✅ Devices are managed (Intune or equivalent)
✅ We know which devices are corporate vs personal
✅ Business data access is restricted on unknown or unmanaged devices
✅ Staff regularly work from approved locations

Why this matters:
Copilot uses the same trust signals as Outlook, Teams, and SharePoint.

7 Governance & Change Management

✅ Someone owns Copilot decisions (not “everyone”)
✅ We have user guidance for:

What Copilot is
What Copilot is not ✅ Staff know they remain responsible for final output
✅ We are prepared to say “not yet” to some AI use cases

Copilot readiness is organisational, not just technical.

8 Helpdesk & User Expectations

✅ Helpdesk knows Copilot behaviour changed in April 2026
✅ We can explain “why Copilot looks different now”
✅ We know where Copilot is expected to work (and where it won’t)
✅ We’ve set expectations around quality, limitations, and review

Silence here = frustration later.