Power BI Security - A Practical Overview for Australian Businesses

The scariest thing about a Power BI report is not that it breaks. It is that it works perfectly and shows the wrong person the right data. A sales rep who can see every region's numbers instead of their own. A contractor who can open a dashboard with the full payroll on it. A partner organisation that gets a link to a report and, three clicks later, is looking at data that was never meant to leave the building. None of that throws an error. It all looks like the system doing its job.

Power BI has a genuinely capable security model. The problem is that it has several layers, they interact in ways that are not obvious, and the defaults are permissive enough that it is easy to build something that leaks without realising. Microsoft's Power BI security planning overview lays out the framework in detail. I want to give you the consultant's version: what the layers actually are, where the traps sit, and what we check first when a client is nervous about who can see what.

The layers, and why there are so many of them

Power BI security is not one setting. It is a stack, and each layer answers a different question.

At the top is the tenant. This is where an administrator decides what the whole organisation can and cannot do. Can people share externally? Can they publish to the web? Can they export data? These settings apply across everyone and they are the blunt instrument. Get them wrong and no amount of careful work further down saves you, because a single tenant setting like "publish to web" left on can turn an internal report into a public one.

Below that is the workspace. A workspace is the container where reports and datasets live while they are being built and managed. Access to a workspace is controlled by roles, and the role you give someone decides whether they can view, contribute, edit, or administer everything inside it. This is the layer people most often get lazy with, handing out Member or Admin because it is quicker than working out what someone actually needs.

Then there is item-level sharing. Once a report is built, you can share the specific report or the app that packages it with a wider audience who never touch the workspace. This is how most consumers get their reports, and it is the right way to do it, because it separates the people building from the people reading.

At the bottom, inside the data itself, sits row-level security. This is the layer that decides which rows of data a given user can see within a single report. Same report, same visuals, but the Queensland manager sees Queensland and the Victorian manager sees Victoria. Get this layer right and one report safely serves an entire organisation. Get it wrong and everyone sees everything.

The reason there are so many layers is that they answer genuinely different questions, from "what can the org do" down to "which rows can this one person see". They also stack. A permissive tenant setting can undo careful row-level security. Row-level security means nothing if the workspace roles hand someone edit access to the model. You have to think about all of them together, which is exactly why people get it wrong.

Row-level security, where most of the real work is

Row-level security, or RLS, is the layer that does the heavy lifting for most businesses, and it is the one that most rewards care. The idea is simple. You define roles in the data model, write a rule for each that filters the data, and map users to roles. When a user opens the report, they only see rows that pass their filter.

In practice there are two flavours. Static RLS bakes the filter into the role, which is fine when you have a handful of fixed groups. Dynamic RLS uses a function that reads the logged-in user's identity and filters accordingly, usually by joining to a security table that maps each user to the regions, business units, or accounts they are allowed to see. Dynamic is more work to set up and it scales far better, because you manage access by updating a table rather than editing the model every time someone changes territory.

The mistakes we see are consistent. People test RLS as themselves, an admin who bypasses it, and never actually verify it as a restricted user, so they never notice it is not filtering. People forget that RLS filters rows but not columns, so a role that should not see salaries can still see the salary column, just for fewer people. People build the security table once and never maintain it, so it drifts out of date and someone who moved teams still sees their old region. And people forget that RLS only applies when the model enforces it, so a user with edit access to the workspace can simply open the model and see the lot.

Getting RLS right, and just as importantly testing it properly with the view-as feature and a real restricted account, is a big part of what our Power BI consultants do when a client wants one report to safely serve people who should each see a different slice.

The mistakes that quietly leak data

Beyond RLS, a handful of specific missteps show up again and again.

Over-permissive workspace roles are the classic. Someone needs to see a report, so they get added as a Member of the workspace, which also lets them edit the model, republish it, and see the raw data behind every visual. They only wanted to look at a chart. Use item and app sharing for consumers, and keep workspace roles for the people actually building. Viewer is a role too, and it is the right one far more often than it gets used.

Publish to web is the one that keeps security teams up at night. It generates a public link that anyone on the internet can open, with no authentication at all. It is a legitimate feature for genuinely public data, and it has been the cause of more than one accidental disclosure when someone used it to "quickly share" an internal report. If your organisation does not have a real need for it, turn it off at the tenant level and remove the temptation entirely.

Export and download settings are the sideways leak. You can lock a report down beautifully and then let anyone export the underlying data to Excel, at which point your careful RLS is irrelevant because the data is now sitting in someone's downloads folder with no security on it at all. Decide deliberately who can export, rather than leaving it on by default.

External sharing is where things get properly risky. Sharing with people outside your organisation is possible and sometimes necessary, but it needs to be governed through the tenant settings and, ideally, guest access managed properly in Entra ID. Ad-hoc external sharing with no oversight is how data ends up somewhere you cannot get it back from.

Security is a design decision, not a switch you flip at the end

The single biggest lesson from doing this across a lot of organisations is that security has to be designed in from the start, not bolted on when the report is finished. If you build a model without thinking about who sees which rows, retrofitting RLS afterwards is painful, because the model was not built to support it. If you scatter reports across workspaces with no plan for roles, tidying it up later means untangling access one item at a time.

The organisations that get this right treat it as an architecture question. How are workspaces structured to match how teams actually work? What is the standard for who gets which role? Is RLS designed into the model from day one, driven by a maintained security table? Are the risky tenant settings, publish to web, uncontrolled export, open external sharing, turned off unless there is a real reason for them? These are decisions to make once, deliberately, and then apply consistently, and they sit squarely inside the broader governance work we do around business intelligence.

There is also an AI angle that makes all of this more urgent, not less. As Copilot and natural-language features get bolted onto Power BI, more people are querying the data through channels that surface it fast and phrase the answers confidently. Copilot respects row-level security, which is exactly right, and it also means your security had better actually be correct, because now more people are hitting the data through a tool that makes it easy. If your RLS was quietly broken, an AI layer on top will help someone find that out in a hurry.

Where to start

If you already have Power BI in production and you are not completely sure who can see what, the honest first step is an audit. Check the tenant settings for the obvious risks. Review who has which workspace roles. Test your RLS as a genuinely restricted user, not as an admin. Look at whether export and external sharing are on when they should not be. It is not glamorous work, and it is a great deal cheaper than the alternative of finding out the hard way.

If you want that done properly, or you are building something new and want the security designed in rather than added later, that is exactly the kind of work we do. Have a look at our services or get in touch and we will give you a straight read on where your Power BI setup stands.

For the full framework and current recommendations, Microsoft's Power BI security planning overview is the reference worth reading properly rather than skimming.