Power BI Governance in the Enterprise: Simplifying Policies, Security, and Compliance

Introduction
Power BI is now part of Microsoft Fabric. Tenant settings live in the Fabric admin portal, and the tenant-level role is called Fabric Administrator (formerly Power BI administrator). That matters for governance: decisions you make for Power BI increasingly apply to other Fabric items in the same workspaces.

Good governance balances two goals. Business users need self-service analytics; the organization needs control over data quality, security and compliance. This article focuses on the operating model – the policies and routines that keep that balance. For a deeper technical walkthrough of row-level security, workspace roles and tenant settings, see our guide to Power BI report security and governance frameworks.

Governance Policies: Clear Guidelines Over Rigid Rules

A governance policy is only useful if people can follow it and you can check it. Keep it short, tailor it to your industry and risk appetite, and avoid copying a generic template. Most enterprise policies need to cover six areas:

• Sharing and distribution. Who may share content, by which method (apps, links, direct access) and with whom. Decide whether external sharing through Microsoft Entra B2B is allowed and for which groups, and whether Publish to web is allowed at all.
• Export. Which export formats are permitted (Excel, CSV, PDF, PowerPoint, .pbix download) and for which groups. Each format is a separate tenant setting.
• Workspaces and lifecycle. Who may create workspaces, how they are named, who owns them, and when unused content is retired. Many organizations also rule out personal workspaces (My workspace) for production content.
• Endorsement. What it takes for a semantic model or report to be marked Promoted or Certified, and who may certify. Certification rights are controlled by a tenant setting scoped to security groups.
• Roles and responsibilities. Who administers the tenant and capacities, who owns each workspace, and who is accountable for data quality and labeling (see Role Management below).
• Regulatory requirements. Which laws and standards apply to which data, agreed with your legal and privacy teams before content is built, not after.

A practical way to keep the policy honest is to pair every rule with the place it is enforced. If a rule has no setting, permission or review behind it, it is a recommendation, not a control.

Policy decision	Where it is enforced
Only the BI team may publish to production workspaces	Workspace roles (Admin, Member, Contributor) assigned to Entra security groups
No public reports	Tenant setting: Publish to web (disabled, or limited to a reviewed group)
No CSV exports of sensitive data	Tenant setting: Export to .csv, scoped by security group; sensitivity labels do not protect CSV files
Confidential data stays encrypted after export	Sensitivity labels with encryption, applied to semantic models and reports
External partners only through named guests	Tenant settings for Entra B2B guest access and invitations
Only stewards may certify content	Tenant setting: Certification, scoped to a stewards group

Review the policy on a fixed schedule and whenever Microsoft changes a relevant feature. A small governance group – typically the Fabric administrator, a security representative, a data owner from the business and someone from compliance – can own those reviews. The aim is guardrails that let teams work without reaching for workarounds.

Security Best Practices: Layered Protection

Power BI security works in layers: identity, workspace and item permissions, data-model security, information protection and monitoring. No single layer is sufficient. The principle of least privilege runs through all of them.

Identity and access. Power BI authenticates users through Microsoft Entra ID. Require multi-factor authentication and use Conditional Access policies to limit access by device compliance, location or sign-in risk. Assign permissions to Entra security groups rather than individuals, so joiners and leavers are handled in one place. One caveat for offboarding: disabling a user in Entra ID blocks their access but does not remove their Power BI access records until the account is permanently deleted.

Row-level and object-level security. Row-level security (RLS) filters which rows a user sees; object-level security (OLS) hides whole tables or columns, including their metadata. Both are defined as roles in the semantic model – RLS in Power BI Desktop, OLS through the TMDL view or external tools such as Tabular Editor – and members are assigned in the service. The critical rule: RLS and OLS apply only to users with the Viewer role or item-level read access. Workspace Admins, Members and Contributors can edit the model, so they see all data. Practical points:

• Use dynamic RLS with USERPRINCIPALNAME() and a user-mapping table instead of one static role per region.
• Validate roles with Test as role, but test external guests and embedded scenarios with real accounts – the feature uses your own identity.
• Microsoft 365 groups cannot be added to RLS roles, and service principals cannot be RLS role members.
• Security groups that contain B2B guests may not resolve correctly for RLS; Microsoft recommends adding guests directly by email or using dynamic RLS.
• Some features (for example Quick insights and Smart narrative) are not supported on models that use OLS.

Sharing and distribution. Distribute content to consumers through Power BI apps, using audiences to show different reports to different groups. Power BI has no anonymous sharing link; the only route to an unauthenticated public report is Publish to web, which should be disabled or tightly limited and its embed codes reviewed. Administrators can also stop users from creating links that grant access to everyone in the organization. For external partners, use Entra B2B guests, keep their content in dedicated workspaces, and review guest access regularly. Note that sensitivity labels and their protection do not support B2B and multi-tenant scenarios.

Encryption. Data at rest in the Power BI service is encrypted by default with Microsoft-managed keys, and traffic to the service is encrypted in transit. Organizations that must control their own keys can use bring your own key (BYOK) with Azure Key Vault on capacity-based workspaces. BYOK has limits worth knowing before you promise it to auditors: it covers semantic models imported from Power BI Desktop, not push or streaming semantic models or uploaded Excel and CSV files; it requires a 4096-bit RSA key; and once introduced to a tenant it cannot be disabled. Encrypt the source systems too, and use an on-premises data gateway for on-premises sources.

Export controls. Exports are where governed data most often leaves governance. Set each export tenant setting (Excel, CSV, PDF and PowerPoint, .pbix download, live-connected Excel) for the groups that need it rather than all-or-nothing. Where blocking downloads on unmanaged devices matters, Microsoft Defender for Cloud Apps session policies can do that for Power BI, using Conditional Access App Control (requires Microsoft Entra ID P1 or higher).

Balance. Overly strict controls push people to screenshots and copy-paste, which no setting can audit. Prefer narrow restrictions on the most sensitive content to blanket bans, and ask users regularly where controls get in their way.

Role Management: Defining Responsibilities and Access

Governance fails when everyone is an admin and no one is accountable. Define organizational roles first, then map them to the permissions Power BI offers.

• Fabric administrator. A Microsoft Entra role (formerly Power BI administrator) that manages tenant settings in the Fabric admin portal, reads the activity log and supports audits. Keep the number of holders small.
• Capacity administrators. Manage Fabric or Premium capacities: which workspaces run where, capacity-level settings and performance.
• Security and compliance team. Owns sensitivity labels, DLP policies and audit search in Microsoft Purview, which sit outside the Fabric admin portal.
• Workspace owners and content creators. Build and publish semantic models and reports, follow modeling and naming standards, and request certification.
• Data owners and stewards. Decide who should see which data, approve certification and labeling, and own data quality for a domain.
• Consumers. View and interact with reports through apps or the Viewer role, and handle exported data according to policy.

Workspace roles then enforce those responsibilities. The table summarizes the differences that matter most for governance.

Workspace role	Can do	Governance implication
Admin	Everything, including updating or deleting the workspace and changing anyone’s role	Limit to a few named owners per workspace
Member	Add users with lower permissions, publish and update apps, share items and allow resharing	Not a consumer role: Members can widen access
Contributor	Create, edit and delete content; schedule refreshes; update the app only if an Admin allows it	Typical role for report developers
Viewer	View and interact with content	The only workspace role to which RLS and OLS apply

Give consumers access through apps or the Viewer role, not Member or Contributor; otherwise RLS will not filter their data. If Viewers need Analyze in Excel or underlying-data export, grant Build permission on the specific semantic model – RLS still applies to them.

Licensing shapes these choices. In a workspace on shared capacity, every user needs a Power BI Pro or Premium Per User license. Free users can view content only when the workspace runs on a capacity that supports it. Microsoft is retiring Power BI Premium per-capacity (P) SKUs at the end of each customer’s agreement term in favor of Fabric (F) SKUs, so check your capacity plan when you design distribution.

Review role assignments on a fixed schedule (for example, quarterly) and whenever someone changes jobs. Group-based access makes this a membership review rather than a workspace-by-workspace hunt.

Auditing and Monitoring: Knowing What Actually Happens

Policies and roles describe what should happen; audit data shows what did. Power BI exposes user activity through two related sources, and their different retention periods shape how you design monitoring.

• Microsoft Purview audit log. Power BI and Fabric activities appear in the unified audit log, searchable in the Microsoft Purview portal by users with the Audit Logs role. With Audit (Standard), records are retained for 180 days; Audit (Premium) adds retention policies of up to one year, and up to ten years with an add-on license.
• Power BI activity log. Fabric administrators can retrieve activity events through the admin REST API or the Get-PowerBIActivityEvent PowerShell cmdlet. Only the last 30 days are available, so organizations that want trend analysis or long-term evidence typically extract it daily into their own storage.

Both sources record events such as report views, exports, shares, workspace changes and sensitivity label changes. They do not cover everything relevant to governance: sign-in failures and risky sign-ins live in Microsoft Entra ID logs, and refresh failures are visible in refresh history and capacity monitoring.

What to watch. Rather than reading every log line, decide which events signal real risk and alert on those:

• exports of labeled or high-volume data, especially to CSV, which carries no label protection;
• sharing with external users and new Publish to web embed codes;
• removal or downgrade of sensitivity labels;
• unusual bursts of sharing or exporting by a single user;
• new workspaces holding sensitive data without an owner or label.

Alerting tools. Microsoft Defender for Cloud Apps includes two built-in Power BI detections – suspicious sharing of a sensitive report with an unfamiliar external email, and mass sharing of reports in one session – plus custom activity policies, for example an alert when one user removes labels from many reports in a short time. Microsoft Sentinel offers a Power BI data connector that ingests audit events through the Office 365 Management Activity API, so you can correlate Power BI activity with other security signals. For adoption and usage trends, Fabric administrators also get the admin monitoring workspace.

Regular reviews. Automated alerts catch single events; scheduled reviews catch patterns. One workable cadence is a short monthly review of new workspaces, external shares, embed codes and unlabeled models, and a quarterly review of roles, tenant settings and policy. Adjust frequency to your risk level.

Audit data as compliance evidence. Audit records help you show who accessed or exported which content and when, which supports investigations and internal controls. They are evidence of activity, not proof of compliance, and only as good as their retention. Agree with compliance teams how long Power BI activity must be kept and where.

Data Classification and Protection: Knowing Your Data

Classification means sorting data by sensitivity so each level gets proportionate protection. In Power BI, the vehicle for classification is sensitivity labels from Microsoft Purview Information Protection. Labels are defined in the Microsoft Purview portal and can be applied to semantic models, reports, dashboards, dataflows and paginated reports, as well as to .pbix files in Power BI Desktop.

A classification scheme. Many organizations use four levels. Treat the example below as a starting point; your labels and their protection settings must match your own data and legal obligations.

• Public: information approved for public release. No restrictions.
• Internal: routine operational data. Internal sharing only.
• Confidential: customer data, unreleased financials, product plans. Restricted access; labels with encryption so exported files stay protected.
• Highly confidential: health data, special-category personal data, trade secrets. Access on a need-to-know basis via RLS/OLS and narrow groups; export limited by tenant settings; download controls via Defender for Cloud Apps where needed.

What a label does – and does not do. This is the most misunderstood part of Power BI information protection:

Where the content is	Effect of a label with encryption settings
In the Power BI service	Label is visible; access is still governed only by Power BI permissions
In Power BI Desktop (.pbix)	Encryption applies: users without sufficient usage rights cannot open the file
Exported to Excel, PDF, PowerPoint (as image), .pbix, or via Analyze in Excel	Label and its encryption are applied to the file; who can open it depends on the label’s settings, not on Power BI permissions
Exported to CSV or other unsupported paths	No label and no protection

Two further details matter in practice. Exported files do not get headers, footers or watermarks from Power BI; content marking appears only in some cases when the file is opened in Office apps. And if a label cannot be applied during export, the export fails rather than producing an unprotected file.

Making labeling scale. New reports inherit the label of the semantic model they are built on, and downstream inheritance can push a label from a model to content built on it. Semantic models can also inherit labels from supported sources (currently Azure SQL Database and Azure Synapse Analytics). Default and mandatory label policies reduce unlabeled content, and admin APIs let administrators set or remove labels in bulk. Labeling at the semantic model level is therefore usually the most efficient approach.

Requirements and limits. Applying or viewing labels requires an Azure Information Protection Premium P1 or P2 license (available standalone or in Microsoft licensing suites), and users who apply labels in Power BI also need Pro or Premium Per User. Labels must be enabled in tenant settings. Power BI does not support labels of the Do Not Forward or user-defined types, or HYOK.

Data loss prevention. Microsoft Purview DLP policies can scan semantic models (and Fabric items such as lakehouses and warehouses) for sensitive information types or sensitivity labels. When a policy matches, it can show a policy tip to data owners, raise an alert for administrators, and – currently in preview – restrict access to the item. DLP does not block individual exports or require manager approval. It applies only to workspaces on Fabric or Premium capacity, evaluates semantic models on publish and refresh, and does not support DirectQuery, live connection or mixed-mode models. DLP evaluation also consumes capacity.

Training. Labels only work if creators choose the right one. Publish a short, organization-specific guide to what each label means, and use the custom help link in the label menu to point to it.

Compliance: Aligning Power BI with GDPR, HIPAA, and Beyond

Compliance in Power BI is a shared responsibility. Microsoft operates the service, undergoes independent audits and offers contractual commitments; your organization decides what data goes into Power BI, who can see it, and how long it is kept. Configuring Power BI well supports compliance; it does not by itself make you compliant. The guidance below is not legal advice – involve your legal and privacy teams.

Microsoft’s side. Audit reports and certifications for Microsoft cloud services, such as ISO/IEC 27001 and SOC reports, are available in the Microsoft Service Trust Portal. Some frameworks are not certifications at all. GDPR is a regulation that you, as data controller, must comply with. For HIPAA, Microsoft states that there is no HHS-approved certification. Instead, Microsoft offers a Business Associate Agreement (BAA), available by default through its Data Protection Addendum to covered entities and business associates, and Power BI is listed among in-scope services. Microsoft is explicit that having a BAA does not on its own achieve HIPAA compliance.

GDPR in practice.

• Know where personal data is. Use sensitivity labels to mark models with personal data, and consider scanning your Fabric tenant (including Power BI) with the Microsoft Purview Data Map to inventory items and lineage.
• Minimize. Bring only the personal data a report needs; pseudonymize or aggregate upstream where you can, and protect remaining identifiers with RLS and OLS.
• Decide on data location deliberately. Content is stored in your tenant’s home region by default; Multi-Geo lets capacity-based workspaces store data in other regions, though some metadata stays in the home region. Whether a given location meets your obligations is a question for your privacy counsel.
• Prepare for data subject requests. Imported semantic models hold copies of source data. Your process should identify which models contain a person’s data and make sure corrections or deletions in the source reach Power BI at the next refresh.
• Keep evidence. Document the controls above and retain audit data for as long as your accountability obligations require.

HIPAA in practice. Confirm the BAA covers your Power BI use; restrict protected health information to the minimum necessary with RLS and OLS; label models containing PHI and limit exports; disable Publish to web for those workspaces; retain audit records according to your policies; and include Power BI in your periodic risk assessments.

Other frameworks. For SOX, focus on change control and access to reports that feed financial statements – for example deployment pipelines and restricted Contributor rights. For PCI DSS, keep cardholder data out of Power BI wherever possible. US public-sector organizations can use Power BI for US Government (GCC, GCC High, DoD); check the specific authorizations for your environment in the Service Trust Portal. Microsoft Purview Compliance Manager provides assessment templates to track controls across Microsoft services.

Summary of Power BI Governance Controls for Major Compliance Frameworks

Framework	What it asks of you (summary)	Power BI and Microsoft capabilities that can support it	What stays your responsibility
GDPR	Lawful, minimal and secure processing of personal data; data subject rights; accountability	Sensitivity labels, RLS/OLS, audit log, Purview Data Map, Multi-Geo	Legal basis, minimization, DSR process, transfer assessments, documentation
HIPAA	Safeguards for PHI; BAAs with business associates	BAA via the Microsoft DPA; encryption; RLS/OLS; audit log; labels	Minimum-necessary access design, risk analysis, workforce training, incident response
SOX	Reliable internal control over financial reporting	Workspace roles, deployment pipelines, audit log	Control design, change management, evidence for auditors
PCI DSS	Protection of cardholder data	Tenant export settings, labels, DLP detection	Keeping cardholder data out of scope where possible

Compliance is continuous. Regulations change and so do Power BI features, so review your settings and policy at least yearly and after significant product changes.

A Practical Starting Checklist

1. Inventory workspaces, semantic models and owners; flag those holding personal or regulated data.
2. Review export and sharing tenant settings; scope each to security groups; restrict Publish to web.
3. Move consumers to apps or the Viewer role; remove unnecessary Admin and Member assignments.
4. Enable sensitivity labels, label key semantic models, and turn on inheritance and a default or mandatory label policy.
5. Start extracting the activity log daily and confirm Purview audit retention meets your requirements.
6. Configure alerts for external sharing, label removal and unusual export activity.
7. Agree a review cadence and owners with security and compliance.
8. Document all of the above in a short governance policy that maps each rule to its control.

Not sure where your tenant stands? Our Power BI health check and audit reviews tenant settings, workspace roles and RLS configurations, and our data governance services extend the same approach beyond Power BI.

Conclusion

Power BI governance is less about adding restrictions than about making deliberate choices and checking they hold. Clear policies tied to enforceable controls, least-privilege roles, well-understood labels, and audit data kept long enough to be useful let self-service analytics grow without losing control. The platform provides strong building blocks; compliance still depends on how your organization uses them.