Power BI Data Governance - Security and Compliance Setup
If you're reading this, you're probably in one of two camps. Either you've just inherited a Power BI tenant that has grown organically for three years and you need to put some governance around it before something breaks, or you're standing up Power BI properly for the first time and want to avoid that mess in eighteen months. Either way, the conversation is the same.
Power BI governance is not glamorous work. It does not produce a beautiful dashboard you can show to the CFO. What it does produce is the answer to "who has access to that customer data?" being something other than "we have no idea." For Australian businesses dealing with Privacy Act amendments, sector-specific regulations (APRA CPS 234, Privacy Act for federal contractors, state-level health data rules), and an audit landscape that is steadily tightening, that answer matters.
This is what good Power BI governance looks like in 2026, based on the setups we've built and inherited across Australian organisations of all sizes.
What "Governance" Actually Means in Power BI
People throw the word governance around so loosely that it stops meaning anything. In a Power BI context, we use it to cover six concrete things:
- Tenant settings - what people can and cannot do at the platform level
- Workspace strategy - how content is organised, named and owned
- Access control - who can see what data, including row-level security
- Data protection - sensitivity labels, encryption, DLP
- Audit and monitoring - who did what, when, and how you know
- Lifecycle management - how content moves from dev to test to production
You can do parts one through six in any order, but if you skip any of them you have gaps. Most organisations we walk into have done one and two reasonably well, three patchily, and four through six not at all.
Step One - Tenant Settings That Need Locking Down
Before you do anything else in Power BI governance, the Fabric admin portal needs a proper review. This is often a fifteen-minute job that pays back enormously.
The settings that almost always need attention in tenants we audit:
Export to Excel and Export to CSV - by default, anyone who can see a report can export the underlying data. For organisations dealing with personal information or commercially sensitive data, this is a problem. Restrict these to security groups, not "the entire organisation."
Publish to web - this is the setting that has caused more accidental data leaks than any other in Power BI's history. If "anyone in the organisation" has this on, turn it off today, then have a separate conversation about who actually needs it.
Share to external users - guests in your tenant inherit some default access. Either lock this down to specific guest security groups or, if your business genuinely doesn't share Power BI content externally, disable it entirely.
Developer mode and embed tokens - if you're not doing embedded analytics, you don't need these enabled. Many tenants we look at have them on from a long-forgotten project.
Service principals - these need to be allowed for ALM and automation, but only for specific security groups. Wide-open service principal access is a back door.
A proper tenant settings review for a mid-market Australian organisation takes us about half a day, including documenting what was changed and why. Larger tenants can take two to three days if there are complex existing usage patterns to protect.
Step Two - Workspace Architecture That Holds Up
The single biggest governance lever you have in Power BI is workspace strategy. Get this right and access control becomes manageable. Get it wrong and you'll be chasing leakage for years.
The pattern we use for most Australian clients:
Domain-aligned workspaces. One workspace per business function (Finance, HR, Sales, Operations, etc.), plus a small number of cross-functional workspaces for executive content. Resist the temptation to create a workspace per team - that way lies hundreds of workspaces and no one knowing where anything lives.
Dev / Test / Prod separation. Each domain workspace should have a development workspace where work happens, a test workspace where it's UAT'd, and a production workspace that end users actually use. Deployment pipelines move content between them. If you're not using deployment pipelines yet, this is your sign.
Named owners. Every workspace needs at least two named human owners, not "IT" or "the data team." Owners are responsible for content quality and access requests in their workspace.
Naming conventions. [Domain]-[Environment]-[Purpose] is a fine convention. So "Finance-Prod-Reporting" or "Sales-Dev-Pipeline". This sounds basic but the number of tenants we walk into with "test workspace 2" and "Bob's stuff" as workspace names is genuinely high.
Step Three - Row-Level Security Done Properly
Row-level security (RLS) is where most organisations get tripped up because it is harder to do well than it looks. The DAX is straightforward. The data model and operational implications are not.
A few hard-won lessons:
Dynamic RLS is almost always the right choice. Static RLS roles, where you hard-code values into the role filter, do not scale. The moment you have more than five role configurations, you're managing a maintenance problem. Use dynamic RLS where the user's identity (via USERPRINCIPALNAME()) filters against a security mapping table.
Build the security table from the source of truth. That source is usually your HR system or your Azure AD security groups. Do not build it from a spreadsheet. We've seen one too many "Power BI security spreadsheet that nobody updates" situations.
Test with actual users. Power BI Desktop's "view as role" feature lets you test, but you must also test in the service with real user accounts. Tenant-level settings, license types, and group memberships behave differently in service than in Desktop.
Document the role logic. RLS without documentation is a time bomb. When the person who built it leaves, nobody else will dare touch it.
Object-level security (OLS) is the often-forgotten partner. RLS controls rows. OLS controls whether someone can even see that a measure or column exists. For financial reporting and HR data, OLS is essential.
A reasonable RLS implementation for a mid-sized Australian business is somewhere in the range of $8,000 to $25,000 AUD of consulting work if done from scratch, depending on data model complexity and how many security profiles need to exist.
Step Four - Sensitivity Labels and Microsoft Purview Integration
This is the area where we see the biggest gap between what's possible and what's actually implemented in Australian organisations.
Sensitivity labels (from Microsoft Purview) let you tag a dataset, report, or dashboard with a classification - Public, Internal, Confidential, Highly Confidential - and have that classification flow with the data. If someone exports a report tagged "Confidential" to Excel, the Excel file inherits the label. If they email it, the email service treats it accordingly.
For Australian businesses dealing with Privacy Act obligations, this is genuinely useful. It is also under-used. The reasons we usually hear:
- "We don't have a Purview license" - increasingly false; most M365 E3/E5 customers do
- "Our classification scheme is too complex" - then simplify it; four labels is plenty
- "It will slow people down" - in practice, after the initial labelling exercise, no
- "We tried before and it didn't work" - usually true, but the experience in 2026 is better
Standing up Purview integration for Power BI is typically a three to six week project for a mid-market client, covering scheme design, label creation, policy configuration, default labelling rules, end-user comms and training. Costs land in the $20,000 to $50,000 AUD range depending on complexity and how much M365 work travels with it.
Step Five - Audit, Monitoring and the Activity Log
If you cannot answer "who accessed this report in the last month?" then your governance is incomplete. The Power BI activity log (now part of the Fabric admin centre) captures the answer, but you need to ingest and store it somewhere usable.
The patterns we see working:
Activity log to Log Analytics. Stream Power BI activity events directly to Azure Log Analytics. Retain for at least 90 days, ideally 12 months. Build queries for the common questions: who exported what, which reports are unused, which datasets are growing fastest.
Monitoring dashboards. Build a Power BI report on top of the activity log itself. Yes, the irony is not lost on us. It's still the right answer.
Alerts on suspicious activity. Mass export, unusual access patterns, repeated access denial - these should generate alerts. Microsoft Sentinel or Defender for Cloud Apps can do this; so can a basic Logic App if budget is tight.
Workspace health metrics. Number of reports, number of unused reports, dataset refresh failure rates, average refresh duration. Treat workspaces like products and report on their health.
Step Six - Lifecycle Management and Source Control
Power BI development without source control is something we still see surprisingly often in 2026. The Fabric Git integration features have matured enough that there is no longer any excuse for it.
What good looks like:
- Every workspace connected to an Azure DevOps or GitHub repository
- PBIP format (Power BI Project files) instead of opaque PBIX where possible
- Pull requests for changes to production datasets and reports
- Deployment pipelines moving content between dev, test, prod
- Automated tests for key calculations (yes, you can do this now with Tabular Editor scripts in CI)
This is the area where the biggest 2026 improvements have landed in Fabric, and most clients we see have not yet caught up. Worth the investment.
Australian Compliance Considerations
A short list of the things we specifically need to think about for Australian Power BI deployments:
Data residency. Power BI services run from various regions. For Australian organisations subject to data residency requirements (government, some financial services, some health), you need to confirm your tenant is provisioned in Australia East or Australia Southeast. Check this; do not assume.
Privacy Act 2024 amendments. The amendments expanded breach notification and gave the OAIC more teeth. Your Power BI audit setup needs to be able to support a breach investigation - which means activity log retention of at least 12 months, and the ability to identify quickly what data a compromised account had access to.
Sector-specific. APRA CPS 234 applies to APRA-regulated entities and explicitly requires information security capability. Power BI is in scope. State-level health data rules in NSW, VIC and QLD have their own implications for health-related reporting environments.
Records management. For government bodies and contractors, retention and disposal schedules apply to Power BI artefacts as much as any other record. Most tenants we see do not have these implemented.
A Realistic Governance Implementation Plan
For an Australian organisation starting from a typical "ungoverned" Power BI state, here is what we'd suggest as a phased plan:
| Phase | Duration | Approx Cost (AUD) | Outcome |
|---|---|---|---|
| Audit and tenant lock-down | 1-2 weeks | $8,000 - $18,000 | Tenant settings reviewed, immediate risks closed |
| Workspace restructure | 3-6 weeks | $20,000 - $45,000 | Domain workspaces, named owners, naming convention |
| RLS and access control | 4-8 weeks | $15,000 - $40,000 | Dynamic RLS, OLS where needed, group-based access |
| Sensitivity labels and DLP | 3-6 weeks | $20,000 - $50,000 | Purview integration, label scheme, defaults |
| Audit and monitoring | 2-4 weeks | $12,000 - $25,000 | Activity log streaming, alerting, monitoring dashboards |
| Lifecycle and source control | 3-6 weeks | $20,000 - $40,000 | Git integration, PBIP, deployment pipelines |
End to end, a proper Power BI governance setup for a mid-sized Australian business runs $95,000 to $220,000 AUD over a three to six month timeline. That sounds like a lot until you've seen what an un-governed tenant costs when something goes wrong.
When to Engage a Consultant
Power BI governance is one of those areas where consulting help genuinely pays off, because most of the work is once-off. You're not paying us to build dashboards on an ongoing basis; you're paying us to set the foundation that your internal team operates on for the next several years.
Where we add the most value:
- Tenant settings audits and lock-down
- Workspace architecture design
- RLS and OLS implementation, especially with complex Azure AD group structures
- Purview integration for sensitivity labels
- Activity log ingestion patterns
- Training and hand-over to internal Power BI champions
If you have a strong internal Power BI team already, you may only need consulting help on the harder bits (RLS, Purview, ALM). If you're starting from scratch, an end-to-end engagement is usually better value than piecemeal work.
Where Team 400 Fits In
We've been doing Power BI work for Australian organisations since the platform was a side feature of Excel, and we've cleaned up enough ungoverned tenants to know exactly what good looks like. The thing we hear from clients after a governance engagement is some variation of "I wish we'd done this two years ago." That is a fair summary of where most organisations land.
If you're ready to have a proper conversation about your Power BI governance position, our Power BI consultants can do an honest audit of where you are and what it would take to get where you should be. For broader data platform work that pulls in Fabric and Data Factory, see our Microsoft Fabric consultants and Microsoft Data Factory consultants pages.
Want to talk through a specific situation? Get in touch or have a look at our broader Microsoft AI consulting work.