Author: directorcia

Where Do Your Uploaded Documents Actually Go in Copilot Notebooks?

image

One of the questions I get asked most often about Microsoft 365 Copilot Notebooks is deceptively simple: when I upload a document into a notebook, where does it actually live? It’s a fair question. If you’re an MSP, an administrator, or anyone responsible for governance, “it’s in the cloud somewhere” isn’t a good enough answer. You need to know exactly where that data sits, who can reach it, and what compliance controls apply. The answer turns out to be more interesting than most people expect, and it hinges on a relatively new piece of the Microsoft 365 storage platform called SharePoint Embedded.

The short answer: SharePoint Embedded

When you upload a document into a Copilot Notebook, it does not land in your OneDrive, and it doesn’t go into a regular SharePoint site or document library that you can browse to. Instead, it’s stored in SharePoint Embedded — specifically inside a user-owned container.

Here’s the part that surprises people. Copilot Notebooks, Copilot Pages, and Loop’s “My workspace” all share the same single user-owned container per user. You don’t get a separate container for each. The first time you need any one of those experiences, Microsoft provisions one container and reuses it for all three. Even the container’s name depends on which app you opened first: it’s called “Pages” if you visited the Microsoft 365 Copilot app first, or “My workspace” (localised to your Loop language) if you opened Loop first.

There’s a governance wrinkle worth committing to memory: in the SharePoint admin center, in PowerShell, and in Purview audit data, this container’s application name always shows as “Loop” — even when it only holds Copilot Notebooks. There is no separate “Copilot Notebooks” application filter. So if you go hunting for Copilot content in your audit logs and only search for “Copilot”, you’ll come up empty. Look for Loop.

So what is SharePoint Embedded?

SharePoint Embedded is an API-only file and document management system built on the same proven Microsoft 365 storage platform that powers SharePoint and OneDrive. The key word is API-only. Unlike a normal SharePoint site, there’s no friendly web UI you can navigate to. When an application uses SharePoint Embedded, it creates a separate storage partition inside your Microsoft 365 tenant, and the documents in that partition are only accessible through Microsoft Graph APIs — and only to the owning application.

Within that partition, the application stores content in entities called File Storage Containers. Think of a container as an API-only document library: it can hold any file type, supports folders, versioning, search, and co-authoring, but it’s dedicated to and reachable by just the one app that owns it. That isolation is the whole point. The files your Copilot Notebook depends on are walled off from other applications, yet they still benefit from the full richness of the Office stack — you can open an uploaded Word or Excel file in Office for the web straight from the experience.

This is the same architecture Microsoft uses under the hood for Loop and Designer. Copilot Notebooks is simply another first-party consumer of the platform.

The detail that matters most: your data stays in your tenant

This is the line I always emphasise with clients. The storage partition that SharePoint Embedded creates lives inside your own Microsoft 365 tenant. Your uploaded documents do not leave your tenant boundary. That means everything your existing Microsoft Purview controls already do, they continue to do here:

  • eDiscovery — content is discoverable

  • Auditing — actions are logged (remember: under the “Loop” application name)

  • Data Loss Prevention (DLP)
  • Retention policies and sensitivity labels
  • Conditional access

So while the storage mechanism is new, the compliance posture is reassuringly familiar. The data is yours, it’s in your tenant, and your governance tooling applies.

Quotas, limits, and a billing nuance

Here’s a distinction that trips people up. The general, developer-facing SharePoint Embedded model bills storage separately through an Azure pay-as-you-go subscription, and that storage does not count against your SharePoint quota. But Microsoft’s first-party use of it for Copilot Pages and Copilot Notebooks works differently. Copilot Pages and Copilot Notebooks content counts against your organisation’s existing SharePoint storage quota — there’s no separate Azure bill for it. The user-owned container has a hard ceiling of 25 TB, which can’t be raised or lowered.

Lifecycle: tied to the user, with sharp edges

The container’s lifecycle is bound to its owner. Content is private by default, much like OneDrive — there’s no forced sharing. When the owning user’s account is deleted, the container is scheduled for deletion and follows the same lifecycle as OneDrive, including a manual handoff step at departure and the option to permanently reassign the container to a new owner.

One critical warning for anyone planning their data protection strategy: there is no end-user recycle bin for Copilot Notebooks. If a notebook is deleted, neither the user nor an administrator can recover it. That’s a meaningful gap compared to the recycle-bin safety net we take for granted in SharePoint and OneDrive, and it’s worth flagging to end users before they start relying on Notebooks for anything important.

Why this matters

Copilot Notebooks feel lightweight and personal, but underneath sits real enterprise-grade storage that you already know how to govern — just wearing a new name. Knowing it’s SharePoint Embedded, that it surfaces as “Loop” in your admin tools, that it counts against SharePoint quota, and that it has no recycle bin turns “somewhere in the cloud” into something you can actually manage.

Copilot Notebooks storage & governance

SharePoint Embedded platform

The MSP Skills Gap Nobody Is Talking About Yet

image

I had a conversation with an MSP owner last week that has been rattling around in my head ever since. He was telling me, proudly, about how his team had just finished a big project hardening a client’s endpoint stack. Patching, EDR, conditional access, the lot. Then almost as an afterthought he mentioned the same client had quietly turned on Copilot for sixty users and was already building their first agent in Copilot Studio. He had no plan for any of it. No policy, no review process, no clear idea who in his team would actually own it. And here is the uncomfortable part. He is not unusual. He is the rule.

The growth in AI agents inside SMB environments is going to be the steepest curve we have seen in years, and most MSPs are walking into it carrying the wrong toolkit. The skills that built a successful managed services business over the last decade are not the skills that will keep customers safe and productive over the next one. That gap is widening every week, and very few MSP owners I speak to have noticed.

Agents are not endpoints

For twenty years MSPs have been organised around things. Devices, servers, mailboxes, firewalls. You patch them, monitor them, back them up, replace them. The whole MSP operating model — RMM, PSA, ticketing, SLAs — assumes a world of static assets that misbehave in fairly predictable ways.

An AI agent is none of those things. It is not an endpoint. It does not sit still. It reads documents in SharePoint, drafts replies in Outlook, pulls data from line-of-business systems, and acts on behalf of a user across surfaces the MSP has never had to think about as a single connected thing. When a Copilot agent fetches the wrong document and pastes confidential numbers into an external chat, no RMM alert is going to fire. The questions are different too. Not “is it patched?” but “what did it do today, and why?” That is a governance and behaviour problem, not an infrastructure one.

The new skill set is governance, data and prompts

Managing agents well leans on a set of muscles most MSPs have never had to build. Understanding identity scope in Entra so an agent cannot reach data it has no business touching. Configuring sensitivity labels and DLP in Purview so a chatty agent does not quietly become a leak. Reviewing prompt design and grounding sources in Copilot Studio before an agent is let near real users. Watching audit logs in the Microsoft 365 admin centre for patterns of agent behaviour that look off.

This is closer to the work of a data steward or a security analyst than a traditional systems engineer. It is slower, more interpretive, and more about judgement than ticket throughput. It rewards curiosity and writing skills as much as PowerShell. The MSP business model has not been built for that kind of work, and the hiring pipeline certainly has not.

The retraining window is now

Here is the bit that worries me. Customers are going to assume their MSP has this covered. They will turn on Copilot, build agents in Copilot Studio, plug them into their CRM, and look across the table expecting the same calm competence they get for backups. When something goes wrong — a leaked document, an agent that quietly emails the wrong list, a workflow that has drifted off purpose — they will ring their MSP. And most will not be able to help.

The MSPs that get ahead of this will start small and start now. Pick one client, one agent, and learn it end to end. Read the audit logs. Write the policy. Build the review cadence. The technical hardening skills will still matter. They are just no longer enough on their own.

Your clients are building AI agents right now. Nobody’s watching.

image

A client rings you. “One of the team built a little AI helper that answers questions from our SharePoint. It’s started giving odd answers. Can you take a look?”

So you go looking. There’s no record of it. No owner listed. No idea what data it reaches into. And while you’re in there, you find eleven more — built by people who left months ago, quietly wired up to who-knows-what.

That’s not innovation. That’s debt.

Here’s what nobody mentions when an SMB switches Copilot on: everyone in that tenant can already build agents. Not eventually. Today. The moment Copilot Studio and Agent Builder light up, every staff member can spin up an AI agent, point it at company data, and share it around.

And by default, all of it lands in one place — the default Power Platform environment — which you can’t delete and can’t fully lock down.

Notice what’s missing? Any decision about who’s allowed, what they can touch, or who cleans up afterwards.

What is agent lifecycle governance, really?

Strip the jargon and it’s three decisions you make before the agents arrive: where they’re allowed to live, what data they’re allowed to touch, and who’s on the hook when one misbehaves.

Microsoft hands you three levers for exactly that.

Environments are the containers agents live in. Data policies decide which connectors an agent can talk to. Maker controls decide who’s even allowed to build in the first place.

Get those three right and the eleven mystery agents never happen. Get them wrong and you’re the one explaining to a client why their customer list ended up somewhere it shouldn’t.

This isn’t about saying no to AI. It’s about drawing the lines once, so everyone can say yes safely.

Step-by-Step: putting guardrails up before the sprawl

You don’t need a six-month project. You need an afternoon in the Power Platform admin centre.

Lock down who can create environments

Tenant settings first. Stop every user being able to spin up new environments on a whim. Restrict environment creation to admins, so a new space is a decision — not an accident.

Treat the default environment as hostile

You can’t delete it, so assume the worst will land there. This is where ungoverned agents breed. Keep nothing sensitive in it, and route anything serious somewhere else.

Give real agents a real home

For anything a client actually depends on, follow the dev-test-prod pattern Microsoft recommends: build in a development environment, validate in test, publish to production. Lock each one to an Entra security group so only the right people get in. Build in production and you’re editing live, in front of users, with no safety net.

Set a data loss prevention policy

This is the big one. In the admin centre, create a data policy and sort your connectors into groups:

Business     — SharePoint, Dataverse, Outlook, Teams
Non-Business — everything else, by default
Blocked      — public HTTP, personal email, social, FTP

An agent can’t combine data across the Business and Non-Business groups. So a bot reading your client’s SharePoint physically cannot also push that data to some random web endpoint.

Notice what’s missing? You didn’t write a line of code. You drew a line, and the platform enforces it for every agent, forever.

Turn on Managed Environments where it counts

For your production spaces, switch on Managed Environments. That gets you sharing limits, weekly usage insights, and an actual record of what’s being built — the visibility that turns “eleven mystery agents” into a list you can read on a Monday morning.

Why this actually changes behaviour

Most MSPs treat this as a clean-up job. Something you’ll get to after the agents pile up.

Wrong order. Governance is cheap before the sprawl and brutal afterwards. Every agent you let breed in the default environment is one you’ll eventually have to find, decode, and either rescue or retire — usually under pressure, usually after the person who built it has gone.

“But my clients are tiny — three agents, not three hundred.” Sure. Govern the three now and the thirtieth looks after itself. Skip it, and you’ll meet the thirtieth as an incident.

Here’s the real win. When the guardrails go up first, makers still build. They just build inside lines you drew. Innovation doesn’t stop — it stops being a liability.

And for you as the MSP, that’s a conversation worth having. “We make sure your team’s AI agents are governed, owned and safe” is a service. A monthly line item. Not a favour you do at 11pm when one breaks.

Copilot agents don’t get tired, and they don’t ask permission. Govern them like staff, not like features.

My recommendation? Do the afternoon in the admin centre before your client’s first agent — not after their twelfth.

Agent governance isn’t there to slow your clients down. It’s there to make sure the thing someone built on Tuesday isn’t the thing you’re explaining to their lawyer on Friday.

The Invisible Business

image

I had a conversation recently with a business owner who told me they were “flat out.” Every week was packed. The team was busy. Revenue was coming in. But when I asked a simple question — what’s actually driving your growth right now? — the room went quiet.

Not because they didn’t care. Because they genuinely didn’t know.

This is more common than most people want to admit. You can run a business for years, keep the lights on, even grow a bit, all without really understanding which activities are pulling their weight and which ones are just filling the calendar. And the longer you go without that clarity, the harder it gets to make good decisions about where to invest next.

Busy Is Not the Same as Productive

There’s a comfortable illusion in being busy. If the inbox is full and the meetings are back-to-back, it feels like progress. But activity isn’t the same as impact. I’ve seen businesses pour hours into client work that barely breaks even while ignoring a service line that customers are quietly asking for. The information was there — buried in emails, mentioned in meeting notes, sitting in a spreadsheet nobody opened twice.

The problem isn’t a lack of data. Most businesses running Microsoft 365 are swimming in it. Every email thread, every Teams conversation, every shared document carries a signal about what matters and what doesn’t. The problem is that nobody’s stepping back to read the pattern.

Your Business Already Knows — You Just Haven’t Asked

This is where I think Copilot changes the equation in a way that actually matters. Not because it does the work for you, but because it helps you see what’s already happening inside your own organisation.

Think about it practically. You can open Excel, point Copilot at your last twelve months of client revenue, and ask it to show you which accounts grew, which ones shrank, and where the margin actually sits. That’s a conversation you can have in five minutes that most business owners never get around to having at all.

Or take something even simpler. Ask Copilot in Outlook to summarise what a particular client has been emailing about over the past quarter. Patterns emerge quickly — repeated questions, unmet needs, opportunities you’ve been walking past every day without noticing them.

In Teams, after a string of internal meetings, you can ask Copilot what decisions were made and what follow-ups were assigned. Not because you weren’t paying attention, but because the sheer volume of conversations makes it nearly impossible to hold the full picture in your head. Most of us don’t have a visibility problem. We have an attention bandwidth problem. The data is there. We just need a better way to surface it.

Clarity Before Growth

I’ve come to believe that the single biggest barrier to scaling a small business isn’t capital, or people, or even time. It’s visibility. If you can’t see where value is being created — and where it’s leaking — you end up scaling the wrong things. More staff on a service that doesn’t pay. More marketing for an offer nobody’s responding to. More meetings about problems that aren’t the real problem.

The businesses I see growing well right now aren’t necessarily working harder. They’re just clearer on what deserves their attention. And increasingly, that clarity comes from asking better questions of the tools they already have open on their screen every morning.

You don’t need a business intelligence platform or a consulting engagement to start. You need the habit of asking — regularly, specifically — what’s working and what isn’t. Copilot won’t run your business for you. But it will hold up a mirror. And sometimes, that’s exactly the thing you’ve been missing.

Where Your Hours Go: A Calendar Lesson Worth Borrowing

image

I’ve been thinking a lot about calendars lately — mine in particular. There’s a quiet truth most of us would rather not admit: we aren’t running our calendars, our calendars are running us. Show me a fortnight of someone’s diary and I can usually tell you, with uncomfortable accuracy, what they actually care about. The hours don’t lie.

So I opened Outlook last Saturday morning and had a long, honest look at my own.

The Calendar Is the Confession

Most weeks of mine look fine on the surface. Meetings stacked tidily, deliverables ticking along, inbox manageable. But I tried something different this time — I colour-coded a fortnight of activities. Green for what energises me. Red for what drains me. The picture changed quickly. Most of the red was email triage, status check-ins that should have been a paragraph in a chat, and busywork dressed up as “real work”. I’d been treating execution time and thinking time as the same currency. They aren’t, and the account that pays out on each is very different.

The shift I’m trying to make is at an identity level. Stop measuring myself on output volume and start measuring myself on the quality of the decisions I make. A clear head making one good call beats a frantic day producing eight average ones. The problem is your calendar has to actually let you do that — and most calendars don’t.

Where Copilot Earns Its Seat

This is where Microsoft 365 Copilot has genuinely changed something in my week. Not in a flashy way — in a quietly structural way. The red activities on my audit, the energy-drain ones, are exactly the tasks Copilot is now doing for me.

Outlook is the obvious one. Copilot drafts replies, summarises long threads, and pulls out the actual ask buried six paragraphs deep. The hour I used to lose to inbox every morning is now closer to fifteen minutes. In Teams, Copilot recaps the meetings I couldn’t attend in plain prose, with decisions and action items separated — so I don’t have to sit through the recording at 1.5x speed pretending it’s productive. In Word and PowerPoint, the first draft writes itself from a few prompts, and I edit instead of starting from a blank page. In Excel, the analysis I used to wait on someone else for is now a conversation I have with the spreadsheet.

The principle behind all of this is simple. Pay someone, or something, to take low-value work off your plate so you can spend more hours on what only you can do. Copilot is the cheapest, most consistent assistant most of us will ever have. It doesn’t call in sick. It doesn’t need handover notes. And it’s already sitting inside the apps you use every day.

Design the Week First

The bit of this I’m trying hardest to apply is the simplest one. Schedule the personal commitments before the work ones. Block the gym session, the family dinner, the thinking time — then let work fit around what’s already there. It feels backwards the first time you do it, and right by the end of the week.

I’m watching my own calendar more carefully now. Not for gaps to fill, but for patterns I’d rather not repeat. If Copilot can hand me back ten hours a week of red-zone work, the question stops being “how do I find time” and becomes “what am I going to do with the time I’ve reclaimed”. That second question, I think, is the one worth answering well.

Retention Policies vs Retention Labels: The One Rule That Governs Both

image

Most Microsoft 365 tenants I look at have both retention policies and retention labels configured. Usually set up by different people at different times, with something like “applied for legal” in the ticket notes. Nobody documented which one wins.

That’s a governance problem. When your client’s solicitor asks why a document that should have been kept for seven years was deleted after three, “we had both configured” isn’t an answer.

Here’s what cuts through all of it: preserve always beats delete.

If any retention setting — policy or label — says retain, the content stays. A delete-only cleanup policy cannot overrule a retain policy. That’s the first principle of retention in Microsoft Purview, and it’s the one rule worth tattooing on your brain before you touch anything else.

What a retention policy does and what a label does, really

A retention policy is a net cast over an entire location. All Exchange mailboxes. All SharePoint sites. All Teams messages. You configure it once and it runs silently in the background. Users don’t see it and can’t override it.

A retention label is a tag applied to a specific item — a document, a folder, an email thread. Item-level control, which means exceptions. A label can be applied manually by a user, or automatically via content inspection rules.

They’re not competing tools. They’re two layers of the same system.

Microsoft’s overview puts it plainly: use a policy when everything in a location should be treated the same, use a label when you need item-level exceptions. Most mature tenants use both — a policy as the floor, labels as the ceiling.

Step-by-Step: Creating and publishing a retention label

Setting up a retention policy is straightforward: Purview portal > Solutions > Data Lifecycle Management > Policies > Retention policies > New. Labels take a few more steps because you create them first, then publish them separately.

Open the Purview portal and navigate to Labels

Go to Solutions > Data Lifecycle Management > Labels and select Create a label.

Name it and set the retention action

Give it a meaningful name — Contracts – Retain 7 Years is better than Label 3. Set the retention period and what happens at the end: retain only, delete after retention, or retain then delete. If the item needs to be declared a record, tick that here — it adds immutability.

Publish via a label policy

Labels don’t apply themselves. Go to Label policies > Publish labels, choose your label, and set the locations (SharePoint, OneDrive, Exchange). This makes the label available for users to apply manually in those apps.

Set up auto-apply

For most SMB clients, relying on users to apply labels manually doesn’t work. They won’t. Back in Label policies, choose Auto-apply a label, set your content condition — keywords, sensitive information types, or a trainable classifier — select the label, and let Purview do the tagging.

Allow up to seven days for labels to propagate to SharePoint and OneDrive. Don’t test immediately and assume it’s broken.

What actually happens when a policy and a label disagree

Say you have an org-wide Exchange retention policy that keeps email for three years and then deletes. And a specific retention label on a contract thread that says retain for seven years.

Which wins?

The label wins. Because it specifies the longer retention period (Principle 2: longest retention wins), and because a label is explicit — a deliberate decision about a specific item, not a blanket setting over a location (Principle 3: explicit beats implicit).

The old thinking: “We have a seven-year legal hold… somewhere. I think.”
The new reality: You can show exactly which items carry which label, when they expire, and prove it via the Purview content explorer.

A delete-only policy can only affect content that has no retain setting at all. It cannot shorten a label’s retention period. It cannot override a retain policy. Preserve always wins.

The MSP angle: adaptive scopes

Adaptive scopes are the part of retention most MSPs haven’t touched — and they make multi-tenant governance dramatically simpler.

Instead of pointing a policy at a static list of sites or mailboxes, you write a query. The scope dynamically targets whoever matches it, updated daily. A client with Finance retaining for ten years and Sales retaining for five no longer needs two separately maintained group memberships. You build two adaptive scopes off the Department attribute in Entra ID, and the policy follows the org chart automatically.

My recommendation? Start with an org-wide retention policy as your baseline. Add labels for the high-value exceptions — contracts, HR records, anything with a different period or a record declaration. Then look at adaptive scopes when you’re ready to stop maintaining static lists across every client tenant.

If you’re not showing clients that their data governance is this deliberate and this auditable, you’re leaving a genuine service conversation on the table.

Retention policies set the floor. Retention labels set the ceiling. Preserve always wins.

CIA Brief 20260627

image

Security & Threat Intelligence
Microsoft Product Updates & Announcements
Cloud & AI
Sustainability

After hours

When a cyber attack took 100 hospitals offline – https://www.youtube.com/watch?v=WxY6aLRVgcI

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Your sensitivity labels aren’t doing anything

image

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.