Back to Blog

Power BI Org-Level Information Protection - Planning Sensitivity Labels Before You Need Them

October 14, 2026•8 min read•Michael Ridland

Here is a question I ask early in most Power BI governance conversations: if someone exported your payroll report to Excel right now and emailed it to their personal Gmail, would anything stop them? Would you even know?

For most Australian organisations the honest answer is no. The report sits in a workspace with sensible permissions, sure. But the moment data leaves Power BI as an Excel file, a PDF or a PowerPoint deck, those permissions are gone. With the Privacy Act reforms continuing to tighten obligations and boards asking much sharper questions after the big data breaches of the last few years, "we trust our staff" isn't a satisfying answer anymore.

Microsoft's Power BI implementation planning guidance has a section on organisation-level information protection that covers how to approach this properly. It's mostly about Microsoft Purview Information Protection and sensitivity labels, and how they extend into Power BI. I've worked through this with a fair few clients now, so here is my take on what matters and where people go wrong.

The key idea - this isn't a Power BI project

The single most important point in the guidance, and the one most often ignored, is that information protection is an organisation-level decision. Power BI is one consumer of it.

Sensitivity labels are defined once, in Microsoft Purview, by whoever owns compliance and security. The same labels apply to Word documents, Outlook emails, SharePoint sites, Teams and Power BI content. If the Power BI team goes off and invents their own labelling scheme, you end up with a label called "Confidential - Finance" in Power BI and "Restricted" in SharePoint, and users have no idea how they relate.

So the first job is finding out whether your organisation already has a label taxonomy. Quite often they do: someone in the security team set up labels for Office documents two years ago and the Power BI admins have never heard of it. Start there.

If nothing exists, you have a bigger conversation to have, and it needs your security, compliance, legal and records management people in the room. Not just the BI team.

Designing a label taxonomy people will actually use

The guidance talks about defining labels that reflect your data classification policy. In practice, the taxonomies that work are short. Something like:

  • Public
  • General (or Internal)
  • Confidential
  • Highly Confidential

You can add sub-labels (Confidential - All Employees, Confidential - Specific People) but every extra option increases the chance someone picks the wrong one or just picks whatever is at the top of the list.

One client in financial services started with 14 labels. Within three months, analytics on label usage showed almost everything was labelled either "General" or the very first confidential option, regardless of content. They cut it to five and accuracy went up noticeably. People will not read a decision tree every time they save a report.

If your organisation deals with government data, it may make sense to align with the Australian Government's Protective Security Policy Framework (PSPF) markings such as OFFICIAL, OFFICIAL: Sensitive and PROTECTED. That gives you a classification scheme people in that sector already recognise.

What labels actually do in Power BI

This is where expectations need managing. A sensitivity label applied to a Power BI report or semantic model does a few concrete things:

  • Shows visibly in the Power BI service so users know what they're looking at.
  • Travels with exports. When someone exports to Excel, PowerPoint or PDF, the file carries the label, and if the label has encryption configured, the file is protected. This is the big one.
  • Inherits downstream. If downstream inheritance is enabled, a label on a semantic model flows to reports and dashboards built on top of it.
  • Inherits from data sources. Some sources (Azure SQL, Azure Synapse and others) can pass their Purview labels into Power BI semantic models on refresh.
  • Feeds DLP and Defender. Labels become signals that data loss prevention policies and Microsoft Defender for Cloud Apps can act on.

What labels don't do inside the Power BI service itself is restrict who can open the report. Workspace roles, app audiences and row-level security still do that job. I've seen executives assume that labelling a report "Highly Confidential" means only senior staff can see it. It doesn't. The label tells people how to treat the content and protects it once it leaves the service. Access control is a separate layer, and you need both.

Label policies, defaults and mandatory labelling

Once labels exist, label policies decide who can use them and how. The guidance covers several settings that are worth thinking through carefully.

Default labels. You can set a default label so new Power BI content gets labelled automatically. I recommend this. "General" is a sensible default for most organisations. It means nothing ends up unlabelled, and people only need to make a conscious choice when content is more sensitive.

Mandatory labelling. You can force users to apply a label before they save or publish. It sounds good on paper. In practice, if you turn it on without a default label and without training, you get a flood of help desk tickets and everyone picks the least restrictive option to make the prompt go away. Turn it on after people understand the labels, not before.

Justification for downgrades. Requiring a reason when someone lowers a label from Highly Confidential to General is a light-touch control that creates an audit trail. Worth enabling.

Scoping. You can publish labels to specific groups. Useful when, for example, only HR should be able to apply an "HR - Restricted" label.

Encryption needs testing, and lots of it

Labels with encryption are where real protection happens, and also where most of the pain comes from.

When an encrypted label is applied and a user exports to Excel, that file can only be opened by people the label permits. Great. But we have seen:

  • External partners who suddenly can't open reports that were previously shared with them as PDFs
  • Automated processes that pick up exported files and choke on encrypted content
  • Users on older Office versions or unmanaged devices who can't open anything

None of these are reasons not to use encryption. They are reasons to pilot with a small group, test every export path you actually use, and talk to the people who receive exported content before you flip the switch for everyone.

Tenant settings to get right

In the Power BI admin portal there is a cluster of information protection tenant settings. The guidance walks through them. The ones I always discuss with clients:

  • Allow users to apply sensitivity labels for content. Off by default. You can enable it for a pilot security group first, which I'd recommend.
  • Apply sensitivity labels from data sources to their data in Power BI. Useful if your source systems are already labelled in Purview.
  • Automatically apply sensitivity labels to downstream content. Generally yes. Saves a lot of manual work and closes gaps.
  • Allow workspace admins to override automatically applied labels. Think about whether you trust workspace admins to make that call.
  • Restrict content with protected labels from being shared via link with everyone in your organisation. Strongly recommend turning this on.

Licensing, briefly

Sensitivity labels in Power BI need users to have an appropriate Microsoft Purview Information Protection licence, which typically comes with Microsoft 365 E3, E5 or the relevant add-ons. Some capabilities, like automatic labelling based on content and certain Defender for Cloud Apps controls, need E5-level licensing. Check your licensing before you promise features to stakeholders. I've had to walk back a project plan because the client assumed E3 covered things it didn't.

A rollout approach that works

Pulling this together, here is roughly the sequence we use:

  1. Confirm or design the organisation-wide label taxonomy with security and compliance.
  2. Check licensing and who is covered.
  3. Enable labelling in Power BI for a pilot group, with a default label and downstream inheritance on.
  4. Train the pilot group. Short, specific, with examples from your own reports.
  5. Test exports with encrypted labels across every path you use.
  6. Review label usage after a few weeks using the Purview and Power BI admin monitoring.
  7. Expand to everyone, then consider mandatory labelling and DLP policies.

It's not glamorous work. It does, though, turn "we trust our staff" into something you can actually explain to an auditor.

Where we fit

This sits right where our Power BI consulting and broader Microsoft security work overlap. We help clients design the label scheme, configure Purview and Power BI together, and run the pilot so the rollout doesn't create a support nightmare. If you're also looking at AI tools that will read this same data, like Copilot, getting labels right first matters even more, and our Microsoft AI consultants can talk you through why. Copilot respects labels and permissions, which is only helpful if the labels are accurate.

If you want help working out where your organisation stands, get in touch.

Microsoft's original guidance is here: Power BI implementation planning - Organisation-level information protection.