Sensitivity labels on event reports so exports carry their classification out

An exhibitor account manager took a screenshot of the renewal risk page and pasted it into an email to a colleague at a partner agency. It held contracted values for eleven accounts and a risk score against each. The report itself was locked down properly. The image was a JPEG in an inbox with no controls on it whatsoever.

Sensitivity labels on reports address a narrower version of that problem and it is worth being precise about which version, because the marketing around information protection tends to overpromise. A label does nothing about a screenshot. What it does is make the classification travel with a file when data leaves the tool through a path the tool knows about.

The moment the file leaves the building

Most of the risk in an event reporting estate sits at export rather than at view.

Somebody exports the exhibitor universe to Excel to work on the phone list. Somebody downloads the post-show deck as PDF for a board pack. A finance analyst opens a live connection in a workbook so they can pivot the revenue figures the way they prefer. Each of those creates a copy that no longer sits behind the report's permissions.

Microsoft's documentation on sensitivity labels (Microsoft Learn, 2026) describes what a label does at that boundary: "When labeled data leaves Power BI, either via export to Excel, PowerPoint, PDF, or .pbix files, or via other supported export scenarios such as Analyze in Excel or live connection PivotTables in Excel, Power BI automatically applies the label to the exported file and protects it according to the label's file encryption settings."

So the exported workbook opens for people the label's encryption allows and refuses everybody else, including anybody the file gets forwarded to. That is the control, and it is a genuine one.

Four labels and what each one means here

Labels only work if the person applying one can pick without deliberating. Four is usually the right number for an exhibitions group, and the definitions should be written in the vocabulary of the business.

Public. Anything already published: the visitor numbers in the press release, the exhibitor list on the website, the floor plan.

Internal. The default for most reporting. Pacing, scan counts, operational dashboards. Sensitive to competitors, harmless inside the company.

Exhibitor confidential. Anything holding one exhibitor's commercial position: contracted value, discount, renewal risk, lead volume. The distinguishing test is whether a second exhibitor seeing it would be a breach of the first one's expectations.

Personal data. Registration records, badge scan detail, anything at attendee grain. The label is a classification and it carries no opinion about whether you were entitled to collect the data, which is a separate question handled in the lawful basis for badge scanning.

Applying them across an estate of 187 items, counting reports, dashboards, semantic models and dataflows, is not a week of work if you start from the model rather than the report. Label the semantic model and new reports built on it inherit the label automatically, which the documentation describes as inheritance upon creation and downstream inheritance. Label the twelve models first and most of the 187 resolve themselves.

Does a label stop anyone opening the report?

No, and this is the single most misunderstood part of the feature.

The documentation states it without hedging: "In the Power BI service, sensitivity labeling does not affect access to content. Access to content in the service is managed solely by Power BI permissions. While the labels are visible, any associated encryption settings (configured in the Microsoft Purview portal) aren't applied."

A report marked exhibitor confidential is exactly as reachable as it was before the label went on. Everyone who could open it can still open it. The label appears in the interface, in the workspace list, in lineage, in the mobile apps and in embedded views, and it changes nothing about permissions.

That means labelling is a complement to access control and never a substitute for it. If the wrong people can open the renewal page, the answer is the workspace and app membership described in workspace permissions for event teams, and the label is what protects the copy they take with them once the membership is right.

There is one asymmetry. In the desktop authoring tool, labels with encryption settings do affect access, so a protected PBIX will refuse to open for somebody without the rights. The same label behaves differently depending on which side of the service it is on.

Who applies the label, and when

Leaving application to the goodwill of report authors produces coverage somewhere around half, and the half that gets missed is the half built in a hurry the week before doors.

Two policy types close the gap and they behave differently enough to be worth choosing between. A default label policy applies a chosen label to unlabelled content automatically, which gets your whole estate off zero and sets a floor. A mandatory label policy requires a user to pick a label before they can save the item, which produces better classifications and a certain amount of complaint in the first fortnight.

I would run both, with internal as the default and mandatory turned on for the workspaces holding commercial and attendee data. The default catches everything nobody thought about. The mandatory policy forces a decision precisely where a wrong default would be expensive.

One behaviour to watch is the parent label. A label that acquires sublabels becomes a parent, and parent labels cannot be applied, are not inherited, escape mandatory policies, and cause export to fail on any item still carrying one. A taxonomy reorganisation in the compliance portal can therefore break exports in the reporting tool with no change on the reporting side at all, which is a conversation worth having with whoever owns the label set before they restructure it.

Changes to labels are recorded. Applying, changing or removing a label on a report, dashboard, semantic model or dataflow is written to the audit log, and permission to change or remove a label carrying encryption is restricted to authorised users. That combination gives you an answer when somebody asks who downgraded the exhibitor pricing model to internal in March.

What do you do about the CSV hole?

Here is the gap that decides whether the whole exercise is worth anything.

Labels and protection are not applied when data is exported to CSV, or through any other path the service does not support. A user who exports to Excel gets a classified, potentially encrypted file. The same user, one menu item away, exports to CSV and gets an unmarked plain text file containing the same rows.

Suppose exports from your tenant split 60 per cent to Excel and PDF and 40 per cent to CSV. The label covers three fifths of the traffic and the remaining two fifths walks out unmarked, and it is the two fifths favoured by anyone doing something they would rather not have tracked. The documentation notes that an administrator can block export from unsupported paths, which is the honest completion of the policy. Labelling without closing CSV is a control with a documented bypass.

Where a label genuinely cannot be applied, export fails rather than silently producing an unlabelled file. That behaviour is a feature, and it produces support tickets that look like bugs, so tell the team before you turn it on.

Making a label do more than describe

A classification that only describes is a starting point. The layer that acts on it is data loss prevention.

Microsoft's guidance on data loss prevention for Fabric and Power BI (Microsoft Purview documentation, 2026) describes policies that evaluate items against conditions including sensitivity labels and sensitive information types, and lists the actions available: notify the user through a policy tip, generate an alert for administrators, and restrict access to the item. Evaluation happens at publish, republish, on-demand refresh and scheduled refresh for semantic models.

For an event organiser the useful policy is narrow and specific. A model labelled personal data that a scan detects as holding a high count of email addresses raises a policy tip to the owner, and an alert if it lands in a workspace with external guests in it. That is a small policy, it fires rarely, and when it fires somebody should look.

Note the coverage limit before designing around it. The same documentation states that these policies are not supported for semantic models connecting through DirectQuery or a live connection, including mixed storage models. If your exhibitor universe is DirectQuery over the warehouse, the policy will never evaluate it.

Where this stops

Two limits matter enough to change how you plan.

The first is external delivery. The documentation states that information protection in Power BI "doesn't support B2B and multi-tenant scenarios". Anything you build for exhibitors reading their own numbers through a portal falls outside this feature, and the controls there are query-level rather than file-level, which is the isolation problem rather than a labelling problem.

The second is that a label is a statement about a whole item. A report holding one column of contracted value and forty columns of harmless operational detail gets classified by its most sensitive field, so the entire page becomes exhibitor confidential and the operations team who only need the harmless forty are now handling a restricted document. The way out is to stop the sensitive column reaching that audience at all, which is object level security and a different mechanism from classification.

Start by exporting your item list and adding one column: the most sensitive field each semantic model contains. Sort it, and you will find the models that need a label first, usually somewhere between eight and fifteen of them, and labelling those correctly does most of the work across the rest of the reporting estate through inheritance.