Power BI Data Governance - Security and Compliance Setup

April 17, 2026•11 min read•Michael Ridland

Data governance in Power BI is one of those things that everyone agrees is important and almost nobody does properly from the start. We've been called into organisations where hundreds of reports exist across dozens of workspaces with no naming conventions, no access controls beyond "everyone can see everything," and no audit trail of who's accessing what.

Fixing governance after the fact is painful and expensive. Setting it up at the beginning is straightforward. If you're implementing Power BI or struggling with an existing environment that's grown out of control, here's how to get governance right.

Why Power BI Governance Matters for Australian Businesses

This isn't just about tidiness. For Australian organisations, there are specific reasons governance matters:

Privacy Act compliance. If your Power BI reports contain personal information (customer data, employee data, financial records), you have obligations under the Australian Privacy Act 1988 and the Australian Privacy Principles. Uncontrolled access to reports containing personal information is a compliance risk.

Industry-specific regulations. Financial services organisations have APRA obligations. Healthcare organisations have My Health Records Act requirements. Government agencies have information security frameworks (ISM, PSPF). Power BI governance needs to align with these requirements.

Data breach notification. Under the Notifiable Data Breaches scheme, if personal information in your Power BI environment is accessed by unauthorised users, you may have a mandatory notification obligation. Proper access controls and audit logging reduce this risk.

Practical reasons. Beyond compliance, ungoverned Power BI environments lead to conflicting numbers ("my report says revenue is $4.2M, yours says $3.8M"), wasted effort (20 people building variations of the same report), and lost trust in data.

The Governance Framework - Five Pillars

1. Workspace Organisation

Workspaces are the foundation of Power BI governance. Get the workspace structure wrong and everything else becomes harder.

What we recommend:

Workspace Type	Naming Convention	Purpose	Access
Production	`PRD - [Department] - [Area]`	Published reports for business users	Viewers: business users. Contributors: BI team
Development	`DEV - [Department] - [Area]`	Work-in-progress reports	BI team only
Sandbox	`SBX - [User/Team]`	Experimentation and learning	Individual users or small teams
Data	`DATA - [Domain]`	Shared datasets and dataflows	BI team manages, report builders consume

Key rules:

Business users should never see development workspaces
Production workspaces should have strict publishing controls
Sandbox workspaces should not connect to production data sources
Every workspace needs an owner and a documented purpose

Common mistake: Creating one workspace per report. This quickly becomes unmanageable. Organise by department or data domain instead.

2. Access Control and Row-Level Security

Access control operates at two levels in Power BI: who can access which workspaces/reports, and what data they can see within those reports.

Workspace-Level Access

Power BI workspace roles determine what users can do:

Role	Can View	Can Build	Can Publish	Can Manage
Admin	Yes	Yes	Yes	Yes
Member	Yes	Yes	Yes	No
Contributor	Yes	Yes	Yes (to this workspace)	No
Viewer	Yes	No	No	No

Best practice: Use Azure AD security groups, not individual user assignments. When someone leaves the organisation or changes roles, you update the group membership once rather than updating every workspace.

Example structure:

SG-PBI-Finance-Viewers - All finance report consumers
SG-PBI-Finance-Contributors - Finance BI team members
SG-PBI-Admin - Central BI governance team

Row-Level Security (RLS)

RLS controls which rows of data a user can see. This is essential when different users should see different subsets of data - regional managers seeing only their region, for instance.

Implementation approach:

Create a security table in your data model that maps users to their data scope
Define RLS roles in Power BI Desktop using DAX filters
Map Azure AD users/groups to RLS roles in the Power BI Service
Test thoroughly - validate that each role sees exactly what it should and nothing more

Example: For a national retail chain where state managers should only see their state's data:

A security table mapping user email to state code, with a DAX filter on the sales fact table: [StateCode] = LOOKUPVALUE(Security[StateCode], Security[UserEmail], USERPRINCIPALNAME())

Testing RLS: Power BI Desktop includes a "View as role" feature that lets you test each security role. Use it. We've caught numerous RLS configuration errors during testing that would have exposed data to the wrong people in production.

3. Data Classification and Sensitivity Labels

Microsoft Information Protection sensitivity labels can be applied to Power BI content - datasets, reports, and dashboards. These labels travel with the data, so if someone exports a report to Excel, the sensitivity label (and associated protections) follow.

Recommended label structure for Australian businesses:

Label	Applied To	Protections
Public	External-facing reports, published metrics	None (intentionally public)
Internal - General	Standard business reports	Prevent external sharing
Internal - Confidential	Financial data, HR data, strategic plans	Prevent external sharing, restrict download
Highly Confidential	Personal information, board materials, M&A data	Prevent sharing, restrict download, require encryption

How to set up:

Define sensitivity labels in the Microsoft 365 Compliance Centre
Enable sensitivity labels in Power BI admin settings
Set a default label policy (we recommend "Internal - General" as default)
Train users on when to apply which label
Monitor label usage through compliance reports

Why this matters: If a Power BI report containing customer personal information is exported to Excel and emailed to the wrong person, sensitivity labels can prevent that email from being sent (through Data Loss Prevention policies) or at minimum ensure the exported file is encrypted and access-controlled.

4. Audit and Monitoring

You can't govern what you can't see. Power BI provides several monitoring capabilities:

Activity Log

Power BI logs every user action - report views, data exports, sharing events, dataset refreshes, and more. These logs can be accessed via:

Power BI Admin Portal - Basic activity log viewing
Microsoft 365 Audit Log - Integration with broader M365 compliance monitoring
Power BI REST API - Programmatic access for custom monitoring solutions
Microsoft Fabric monitoring - If you're on Fabric, unified monitoring across the platform

What to monitor:

Event	Why It Matters	Recommended Action
Report exports	Data leaving the Power BI environment	Review weekly; alert on exports of confidential content
External sharing	Data shared outside the organisation	Alert immediately; review within 24 hours
Failed access attempts	Potential unauthorised access	Investigate pattern of failures
Large data downloads	Potential data exfiltration	Alert on downloads exceeding thresholds
Admin setting changes	Governance control modifications	Alert immediately; require change approval

Usage Metrics

Beyond security monitoring, usage metrics tell you which reports are being used and which aren't. This is governance too - unused reports clutter the environment and create maintenance overhead.

Our recommendation: Review usage metrics quarterly. Any report not accessed in 90 days should be archived or decommissioned. We've seen environments with 500+ reports where fewer than 100 are actually used.

5. Content Lifecycle Management

Reports and datasets need a lifecycle - creation, review, publication, maintenance, and retirement. Without this, your Power BI environment grows indefinitely.

Lifecycle stages:

Development - Report is built in a development workspace
Review - Report is reviewed by a data steward for accuracy, compliance, and adherence to standards
Certification - Approved reports receive a "Certified" endorsement in Power BI, signalling to users that the data is trustworthy
Production - Report is published to a production workspace
Maintenance - Regular checks that data is refreshing, calculations are accurate, and the report is still needed
Retirement - Report is archived when no longer needed

Deployment pipelines (available with Premium/Fabric capacity) automate the movement from development to test to production. We strongly recommend using them for any organisation with more than a handful of reports.

Setting Up Governance From Scratch - A Checklist

If you're starting fresh or cleaning up an existing environment, here's the order we recommend:

Week 1-2: Foundation

Define workspace naming conventions
Create Azure AD security groups for Power BI access
Configure Power BI tenant settings (admin portal)
Disable "publish to web" (unless you specifically need public embedding)
Restrict workspace creation to approved users
Enable audit logging

Week 3-4: Access Control

Reorganise workspaces according to naming convention
Assign security groups to workspaces (replace individual user assignments)
Implement row-level security where needed
Test all RLS roles
Document access control matrix

Week 5-6: Classification and Monitoring

Set up sensitivity labels
Apply default label policy
Configure Data Loss Prevention rules for Power BI exports
Set up monitoring alerts for high-risk activities
Create a governance dashboard (yes, use Power BI to govern Power BI)

Week 7-8: Process and Training

Document the content lifecycle process
Define certification criteria for reports
Train the BI team on governance procedures
Brief business users on sensitivity labels and sharing policies
Schedule quarterly governance reviews

Governance for Regulated Industries

Financial Services (APRA-Regulated)

Australian financial services organisations under APRA supervision need to address:

CPS 234 (Information Security): Power BI environments must be included in your information security framework. Access controls, monitoring, and incident response must cover BI assets.
CPS 230 (Operational Risk): If Power BI is used for material risk reporting, its availability and accuracy become operational risk considerations.
Data sovereignty: Ensure Power BI data is stored in Australian Azure regions. Configure geo settings in the Power BI admin portal.

Government (ISM/PSPF)

Australian government agencies using Power BI should:

Align sensitivity labels with the Protective Security Policy Framework (PSPF) classifications: OFFICIAL, OFFICIAL:Sensitive, PROTECTED
Configure data residency for Australian Azure regions only
Enable conditional access to restrict Power BI access to managed devices and compliant networks
Implement mandatory MFA for all Power BI users

Healthcare

Organisations handling health information should:

Apply heightened sensitivity labels to any report containing patient or health data
Restrict export capabilities for health data reports
Enable detailed audit logging for compliance with health records legislation
Implement device-based conditional access to prevent access from personal devices

Microsoft Fabric and Governance

If you're using or planning to use Microsoft Fabric, governance extends beyond Power BI into the unified data platform.

Fabric adds several governance capabilities:

Domains: Organise Fabric items by business domain (Finance, Sales, Operations) with domain-level governance policies
Endorsement: Certify and promote trusted datasets across the organisation
Data lineage: Visual tracking of data flow from source to report
Purview integration: Connect to Microsoft Purview for organisation-wide data governance including data catalogue, classification, and lineage across all data stores (not just Power BI)

For organisations building a modern data platform, Fabric's governance features are a significant advantage over standalone Power BI governance.

Common Governance Failures We've Seen

"Everyone Is an Admin"

We've walked into organisations where 50+ people had admin access to the Power BI tenant. Admin access allows changing tenant-wide settings, viewing all content, and modifying security controls. This should be limited to 2-3 people maximum.

No Dataset Certification

Without certification, users can't tell which datasets are official and which are someone's experimental copy. The result is conflicting numbers and lost trust. Implement certification and train users to look for the certified badge.

Export Controls Disabled

By default, Power BI allows users to export data to Excel, CSV, and other formats. If you have sensitive data in Power BI and no export controls, your governance boundary is essentially nonexistent - anyone who can view a report can extract the underlying data.

No Refresh Monitoring

Datasets that fail to refresh silently show stale data. We've seen organisations making decisions based on reports that hadn't refreshed in weeks because nobody was monitoring refresh failures. Set up alerts for refresh failures - Power BI supports this natively.

Getting Governance Right with Team 400

We're Power BI consultants and Microsoft specialists who build governance into every implementation, not as an afterthought.

Our governance engagements typically include:

Governance assessment of your current Power BI environment
Framework design aligned with your industry regulations and internal policies
Technical implementation of RLS, sensitivity labels, monitoring, and lifecycle management
Policy documentation that your compliance and risk teams can review
Training for your BI team and business users

We work with organisations across Australia, including those in regulated industries where governance isn't optional - it's a regulatory requirement.

Whether you're setting up Power BI governance from scratch or cleaning up an environment that's grown beyond control, talk to our team. We'll assess your current state and give you a practical plan.

Explore our AI consulting services, Microsoft Fabric expertise, or our full services page to see how we help Australian businesses get data right.