Power BI Security: A Practical UK Guide for 2026

Power BI security is one of those topics that only really matters when something goes wrong, at which point it matters a great deal. The good news is that it is not complicated once the vocabulary is clear. This guide walks through the layers that matter in a UK business, in plain terms, and covers the mistakes we see most often when we audit an existing tenant.

The layers of Power BI security

There are five layers that combine to decide who sees what in Power BI. Getting all five right is the whole job.

• Tenant settings, controlled centrally by an Entra ID admin. These decide which features are on, who can publish to web and who can share externally.
• Workspace roles. Admin, member, contributor and viewer. These decide who can build, publish and see content within a workspace.
• App permissions. The audience layer on top of an app, which is how most business users are given access to a set of reports.
• Dataset security. Row level security and object level security on the semantic model itself.
• Data source security, back to the source system. Not strictly Power BI, but always in scope for an audit.

Row level security done properly

Row level security, usually abbreviated to RLS, is the mechanism that lets a single report show different rows to different users. A sales manager sees only their region. A cost centre owner sees only their cost centre. It is the layer that most Power BI deployments get wrong, and where the interesting mistakes live.

The right pattern is dynamic RLS driven by a security table in the model. That table maps user principal names to the values they are allowed to see, and a single DAX filter compares USERPRINCIPALNAME to the current row. Nothing more clever than that. The wrong pattern is a filter on a visual or a bookmark, or a role per named person, both of which fall over the moment the business changes shape.

Test RLS the same way every time. Publish, use view as role for each defined role, log in as at least one test account from outside the build team, and confirm the row counts match what the source system would return for that user. Anything less is pretend testing.

Object level security

Object level security hides an entire column or table from a user. Salary is the obvious example. HR needs to see it, line managers must not, everyone else definitely must not. Object level security is set at the model, not the report, so it holds even if a user opens the dataset in Excel.

This layer is under used. Many Power BI tenants achieve the same effect by hiding columns from the report, which stops the value being visible in that specific visual but leaves it available for anyone who connects to the dataset. That is not security.

Workspaces and apps

Workspaces are the build container. Apps are the distribution container. In a healthy tenant, business users almost never see a workspace. They see an app, which was built and published from a workspace by a small number of named people. Workspace roles should be tight, and every app should have an owner and an audience defined in Entra ID groups, never in personal email addresses.

Sensitivity labels

Microsoft sensitivity labels flow through Power BI and follow the content into Excel exports and email attachments. Applied properly, they give an audit team the trail they need without the end user having to do anything. Applied badly, they turn into a pop up nobody reads. The trick is a small set of labels, sensible default label at the tenant level, and a rule that any dataset containing personal or financial data has to carry a label before it can be published.

Common mistakes we audit out

• RLS implemented in slicer defaults rather than in the model.
• Publish to web left on at the tenant level. This creates anonymous public URLs and is almost always a mistake.
• Workspace membership by named user rather than Entra ID group, which turns leaver management into a manual scavenger hunt.
• Sensitive columns hidden in reports but still exposed on the dataset.
• Direct query connections to source systems using a shared service account, with no user context passed through.
• Sensitivity labels not enforced. Users can save reports with no label and share them freely.

How we approach a Power BI security review

On a Power BI audit we check every layer above and grade them red, amber or green. The output is a short written report with the fixes ranked by risk. Most tenants come out with three or four amber items and one red one. The red item is nearly always publish to web or broken RLS.

If you want the wider picture, our data governance consulting page covers how Power BI security fits into the broader governance framework, and Power BI consultancy covers ongoing build and support work.

Frequently asked questions