Power BI Tenant-Level Security Planning - Decisions to Make Before You Scale

Here's a pattern we've seen more than once. An Australian organisation starts using Power BI in one team. It goes well. Within two years there are 600 users, 200 workspaces, a handful of guest users from partner firms, Publish to web is switched on (nobody remembers why), and the first time anyone looks seriously at tenant security is when the auditors or the cyber team ask an awkward question.

Fixing that after the fact is miserable. Every setting you tighten breaks something someone depends on. Tenant-level security planning is the boring work you do up front so that doesn't happen, or the remediation work you do once it already has.

Microsoft's guidance on tenant-level security planning is part of its broader implementation planning series. It's a solid checklist. What it doesn't tell you is which decisions tend to cause the most pain in practice, so that's what I'll focus on here.

What "tenant-level" means

Power BI and Fabric security works at several layers: tenant, capacity, workspace, item (reports, semantic models, lakehouses) and data (row-level and object-level security). Tenant-level decisions are the ones that apply across your entire organisation's Fabric environment. They're set by Fabric administrators in the admin portal, plus a few that live in Microsoft Entra ID and Microsoft Purview.

These decisions matter disproportionately because they set the boundaries everything else operates within. A workspace admin can't share a report externally if external sharing is off at the tenant. And a workspace admin can absolutely share with the whole internet via Publish to web if the tenant lets them.

Decision 1 - Your security group strategy

If I could get every organisation to do one thing, it would be this: never assign tenant settings, workspace roles or permissions to individual users. Use Entra ID security groups, always.

It sounds like admin hygiene, but it shapes everything. Most tenant settings can be enabled for the entire organisation, disabled, or enabled for specific security groups (with exceptions for other groups). The "specific security groups" option is where the real control lives. If you don't have sensible groups, you can't use it.

What we usually set up:

• Groups for tenant setting scoping. For example, a group for people allowed to create workspaces, one for people allowed to export to Excel or CSV, one for people allowed to share externally, one for people allowed to use Copilot features. These are permission groups, not team groups.
• Groups for workspace access, typically per workspace and role, or per business domain.
• A consistent naming convention. Something like PBI-Tenant-WorkspaceCreators or PBI-WS-Finance-Viewers. It sounds trivial. Six months later when you're trying to work out why someone in marketing can share externally, a clear name saves you an afternoon.
• Clear ownership. Each group needs an owner who approves membership. If every request goes to the IT service desk, they'll approve everything because they don't know any better.

The Microsoft guidance also points out that you'll need to decide whether group management sits with IT, the Power BI or Fabric centre of excellence, or the business. There's no single right answer, but there has to be an answer.

Decision 2 - Tenant settings, one by one

There are well over a hundred tenant settings in the Fabric admin portal now, and Microsoft adds more every few months. Most organisations leave them at defaults, and the defaults lean towards openness. That's fine for a trial. It's not fine at scale.

The ones we always review with clients:

Publish to web. This creates a public, unauthenticated link to a report. Anyone with the link can see the data, and links get indexed. We recommend disabling it, or restricting it to a tiny group with a documented approval process. We have found live Publish to web embeds of internal reports with customer data on more than one client tenant. It's the single highest-risk setting in Power BI.

Export and sharing settings. Export to Excel, export to CSV, export of underlying data, printing, copying visuals as images. Each one is a way data leaves the governed environment. Turning them all off creates a revolt, and people will just screenshot reports into email instead. Scoping them to groups is usually the right middle ground.

Workspace creation. If everyone can create workspaces, you'll have hundreds of them within a year, many abandoned. Restricting creation to a group, with a lightweight request process, keeps things manageable.

Guest and external user settings. Covered in more detail below.

Fabric item creation. Once Fabric is enabled, users can potentially create lakehouses, warehouses, notebooks and pipelines. That's a different risk profile from creating reports. Decide deliberately who gets it.

Copilot and AI features. Several settings govern whether Copilot is available and whether data can be processed outside your geographic region. For Australian organisations with data sovereignty concerns, this one needs a proper conversation, not a default.

Also look at delegation. Some tenant settings can be overridden at the capacity, domain or workspace level. That's useful for letting a mature team do more without opening it up for everyone, but it adds complexity. Document what you've delegated and why.

Decision 3 - External users and B2B sharing

Most organisations need to share some content with people outside the organisation: auditors, partners, contractors, franchisees. Power BI supports this through Entra ID B2B guest users, and more recently through external data sharing between Fabric tenants.

Questions to settle up front:

• Can guests be invited by anyone, or only by specific roles?
• Can guests see content in the same way as members, or with restrictions?
• Can guests edit and manage content, or only view?
• How do guest accounts get reviewed and removed? Entra ID access reviews work well here.

The failure we see most is the forgotten guest. A consultant who did a project three years ago still has access to a workspace full of commercial data. Nobody removed them because nobody owns the process. Set up quarterly access reviews for guests from the start.

Decision 4 - Data residency

This one is specific to where you are. Your Fabric tenant has a home region, set when the tenant was created, and for most Australian organisations that's Australia East or Australia Southeast. Semantic models and Fabric data are stored in that region by default.

If you're on a Fabric or Premium capacity, you can create capacities in other regions (multi-geo), which matters for organisations with operations in New Zealand, Asia or elsewhere with their own residency requirements. It also matters in the other direction: if someone in the business spins up a capacity in a US region for a proof of concept, your data might be sitting overseas without anyone noticing.

For government agencies, healthcare and financial services clients, residency is often non-negotiable. Check where your tenant's home region actually is (it's shown in the Help and Support "About Power BI" dialog) before assuming. We've had at least one client discover their tenant was homed in the US because of how an Office 365 trial was originally set up years earlier.

Decision 5 - Information protection and DLP

Microsoft Purview sensitivity labels work across Power BI and Fabric. You can label semantic models and reports, labels flow downstream to content built on them, and they follow data when it's exported to Excel, PowerPoint or PDF. Data loss prevention policies can detect sensitive information types in semantic models and alert or restrict.

This is genuinely good functionality. It's also one of the areas where the implementation is fiddly. Labels need to exist in Purview first, the Power BI integration needs to be switched on in tenant settings, and you need to decide whether labelling is mandatory, whether default labels apply, and how inheritance works. If your organisation already uses sensitivity labels in Microsoft 365, extend that taxonomy rather than inventing a new one for Power BI.

My honest view is that most mid-sized organisations should start with a mandatory label on semantic models only, and get that working before trying to do everything at once.

Decision 6 - Network and access controls

Two more things worth a look, especially for regulated industries.

Conditional access in Entra ID applies to Power BI the same as other Microsoft 365 apps. Requiring compliant devices or blocking access from certain locations is often already in place for Microsoft 365 and just needs to cover Power BI too.

Private links let you restrict access to your Fabric tenant to your private network. They're powerful, but they come with real functional trade-offs (some features don't work, and access from outside the network becomes harder). We only recommend them where there's a clear regulatory driver.

Auditing - so you can prove it

All of this planning is only as good as your ability to see whether it's being followed. The activity log records sharing, exports, Publish to web usage, guest invitations and tenant setting changes. Extract it, store it, and review it. If a tenant setting gets changed, you want to know who did it and when, not find out months later.

Where to start

If your tenant has grown without much planning, don't try to fix everything in one go. In priority order: audit and restrict Publish to web, set up security groups for the most sensitive tenant settings, review guest users, confirm your data residency, and start extracting the activity log. That's a few weeks of work and it addresses most of the real risk.

Tenant security is also becoming more important as AI arrives in the platform. Copilot and data agents can only see what users can see, so loose permissions now mean an AI that can surface data to the wrong people later. That's a theme we see across all our Microsoft AI consulting work.

If you'd like a second pair of eyes on your tenant settings, or help planning security before a larger rollout, our Power BI consultants and Microsoft Fabric consultants do this kind of review regularly for Australian organisations.