Quick Answer: How Do I Make Power BI Compliant?
Compliance in Power BI is 20 percent platform and 80 percent configuration. Microsoft operates Power BI and Fabric under SOC 1, SOC 2 Type II, ISO 27001, ISO 27018, HIPAA (via BAA), FedRAMP Moderate (commercial) and FedRAMP High (GCC High), PCI DSS, and more. What your auditor will actually test is the customer-configurable layer on top of that: tenant settings, workspace governance, row-level security, sensitivity labels, audit logging, DLP, and Copilot posture.
The fastest path to a clean audit is a five-phase rollout: governance baseline, platform hardening, semantic model controls, monitoring, and operational cadence. Most enterprises finish the first three phases in 8 to 12 weeks and run the last two continuously. This pillar gives you the full control matrix, the evidence list, the RLS patterns, and the decision framework that makes Power BI defensible to HIPAA, SOC 2, FedRAMP, GLBA, and ITAR auditors.
Every control in this guide maps to a specific Power BI feature or a specific external system (Purview, Entra ID, Sentinel, Azure Key Vault). If you cannot map a control to a configuration, your auditor will flag it. Use this page as the master index; follow the three linked industry briefs for healthcare HIPAA dashboards, financial services SOC 2 / SOX, and government FedRAMP / ITAR deployments for the specifics of each vertical.
What This Pillar Covers
1. The 2026 Compliance Landscape for Power BI
Analytics platforms are no longer optional compliance surfaces. Any enterprise deploying Power BI or Microsoft Fabric in 2026 will almost certainly ingest data that falls under at least one regulatory framework: HIPAA for healthcare, SOC 2 for SaaS vendors, FedRAMP and CMMC for federal workloads, GLBA and SOX for financial services, GDPR and UK DPA for EU and UK customer data, ITAR and EAR for defense data, and industry-specific rules such as FINRA, SEC 17a-4, and the NYDFS Cybersecurity Regulation for regulated financial firms.
Power BI sits at the center of this landscape because it aggregates data. A single semantic model may join data from EHRs, general ledgers, CRM, HRIS, and operational databases. The aggregation itself creates a higher-risk asset than any individual source. Auditors treat Power BI workspaces as in-scope for whatever the highest-classification data contained within them requires, and most enterprises inherit that highest classification by default.
Three shifts in the 2026 regulatory environment change how you must design Power BI deployments:
- AI-specific controls. The EU AI Act, the NIST AI Risk Management Framework, and several state-level AI laws now apply to Copilot and Fabric AI outputs. Logging prompts, labeling AI-generated narratives, and restricting AI access to sensitive models are new auditable controls.
- Data sovereignty enforcement. Regulators in the EU, UK, Canada, Australia, and India now actively test for cross-border data flows. Power BI tenant home region, Fabric capacity region, and gateway VM location must all align with the sovereignty regime that governs the data in your semantic models.
- Continuous-audit expectations. SOC 2 Type II, ISO 27001:2022, and PCI DSS 4.0 all lean toward continuous monitoring rather than point-in-time testing. Power BI audit log retention, SIEM integration, and automated evidence collection are now baseline expectations rather than optional enhancements.
The consequence for Power BI owners is that a compliance program that worked in 2022 — essentially tenant setup plus workspace governance plus periodic screenshots — is no longer sufficient. The 2026 bar is a documented control matrix, automated evidence, and an incident-response process that includes Power BI audit events as a first-class signal.
2. The Power BI Compliance Control Matrix
The control matrix below maps common regulatory controls to the Power BI, Fabric, or external Microsoft feature that satisfies them. Use it as the starting point for your customer responsibility matrix. Every row should produce a specific evidence artifact during an audit.
| Control Area | HIPAA | SOC 2 | FedRAMP Moderate | GLBA / SOX | ITAR | Power BI / Fabric Control |
|---|---|---|---|---|---|---|
| Access authorization | 164.308(a)(4) | CC6.1 | AC-2, AC-3 | GLBA Safeguards | 120.17 | Entra ID groups, workspace roles, RLS, OLS |
| Encryption at rest | 164.312(a)(2)(iv) | CC6.7 | SC-28 | SOX ITGC | 126.1 | AES-256 default; BYOK via Azure Key Vault |
| Encryption in transit | 164.312(e)(2)(ii) | CC6.7 | SC-8, SC-13 | SOX ITGC | 126.1 | TLS 1.2+; gateway TLS; VNet integration |
| Audit logging | 164.312(b) | CC7.2 | AU-2, AU-3, AU-6 | GLBA / SOX 404 | 120.10 | Purview unified audit + SIEM export |
| Data classification | 164.308(a)(1) | CC3.2 | RA-2 | GLBA Safeguards | 120.17 | Purview sensitivity labels on datasets |
| Data loss prevention | 164.308(a)(5) | CC6.6 | SI-4 | GLBA 501(b) | 120.17 | Purview DLP for Power BI; export restrictions |
| Change management | 164.308(a)(8) | CC8.1 | CM-3 | SOX 404 | 120.10 | Deployment pipelines, git, PBIP, approvals |
| Incident response | 164.308(a)(6) | CC7.3 | IR-4 | NYDFS 500.16 | 120.10 | Sentinel analytics on Power BI audit logs |
| Backup and recovery | 164.308(a)(7) | A1.2 | CP-9 | SOX 404 | n/a | PBIP git, Fabric lakehouse snapshots |
| AI and Copilot governance | 164.308(a)(1) | CC9.1 | RA-5 | NYDFS 500.11 | 120.17 | Copilot tenant controls, Purview Copilot audit |
Print this matrix for your first control-mapping workshop. Assign an owner to every row, and require each owner to produce the evidence artifact before the first audit cycle. The matrix is intentionally compact — your internal version should include evidence locations, responsible team, automation status, and last-tested date for each cell.
3. Tenant Architecture: Commercial vs GCC vs GCC High vs Azure Government
Tenant choice is the single most consequential compliance decision in a Power BI deployment and is nearly impossible to reverse after data has been ingested. Choose the tenant before any other control work begins.
Microsoft 365 Commercial + Azure Commercial
The default Microsoft cloud. Supports HIPAA (with BAA), SOC 2 Type II, ISO 27001, ISO 27018, GDPR, UK DPA, PCI DSS, and FedRAMP Moderate for most customer data classifications. Power BI Pro, Power BI Premium, and Fabric F SKUs are all available. Use this tenant for HIPAA, SOC 2, GLBA, and most GDPR workloads. Do not use it for Controlled Unclassified Information (CUI), ITAR data, or FedRAMP High workloads.
Microsoft 365 GCC
A commercial-grade cloud with US-only data center residency, designed for US state and local government and for federal workloads that do not require FedRAMP High. Power BI and Fabric are available in GCC. Use GCC when you need data residency and background-screened Microsoft personnel but do not require the full FedRAMP High authorization boundary.
Microsoft 365 GCC High
FedRAMP High authorized, DoD Impact Level 4 (IL4) compliant, and suitable for ITAR and Controlled Unclassified Information (CUI). GCC High is a separate tenant — not a configuration of commercial — with its own identity boundary, licensing catalog, and feature parity lag. Power BI and Fabric are available in GCC High, but not every commercial feature ships simultaneously. Validate Copilot, certain connectors, and preview workloads before committing. Use GCC High for defense contractors, ITAR-regulated manufacturers, and federal agencies requiring FedRAMP High.
DoD Impact Level 5 (IL5)
The highest classification commonly deployed for sensitive DoD mission data. Requires an Azure Government DoD tenant and specific Power BI IL5 availability. Most enterprises consuming this tier are DoD components or major defense primes. Feature set is a subset of commercial and IL5 authorization lag is common for new Fabric workloads.
Sovereign Clouds (EU Data Boundary, China, Germany)
For regulated non-US data sovereignty needs, choose the EU Data Boundary (guarantees EU-only data residency for eligible Microsoft 365 services, including Power BI), Azure China (operated by 21Vianet), or Germany’s previously-separate cloud (now sunset; Germany residency is handled through the EU Data Boundary). These are one-way decisions: once a tenant is provisioned in the EU Data Boundary, you cannot move back to a global-routed tenant without a full migration.
For additional Fabric capacity pricing context across these tenants, see our Fabric capacity cost optimization playbook, which covers how pause/resume economics change in GCC and GCC High environments.
4. RLS, OLS, and Minimum-Necessary Access
HIPAA’s minimum-necessary standard, SOC 2’s CC6.1 logical access control, and FedRAMP’s AC-2 / AC-3 all require that a user see only the data they are authorized to see. In Power BI, the primary mechanisms for achieving this are row-level security (RLS), object-level security (OLS), and workspace-role governance.
Dynamic RLS with USERPRINCIPALNAME()
Dynamic RLS is the default pattern for regulated deployments. A single role uses a USERPRINCIPALNAME() function to filter fact tables based on the signed-in user’s Entra ID identity, joined to a mapping table maintained in your source system or a Fabric lakehouse. This keeps role maintenance out of the semantic model and inside a governed source, which satisfies auditor expectations for documented, change-controlled access rules.
Static RLS for Small Regulated Audiences
Static RLS assigns Entra ID groups directly to roles inside the model. It is easier to implement but harder to audit when group membership changes. Use static RLS only for small, stable audiences (for example, executive dashboards with fewer than 10 viewers) and only when group membership changes are logged in Entra ID audit logs that you can correlate during an investigation.
Object-Level Security
OLS restricts access to individual tables or columns inside a semantic model. It is the right control when the existence of a field (not just its value) is sensitive — for example, a column indicating a patient’s HIV status, or a column showing an M&A target name. OLS does not have a visual affordance in Power BI Desktop for end users, so it is usually combined with RLS on the same model.
Source-Side Dynamic Data Masking
For the highest-risk fields (SSN, full account numbers, date of birth), dynamic data masking (DDM) at the source database is a defense-in-depth layer that survives a mis-configured semantic model. Azure SQL, SQL Server, Snowflake, and Databricks all support DDM. Pair DDM with RLS so that unmasking is itself a role-based permission and cannot be granted ad hoc through Power BI.
The reference architecture for a HIPAA semantic model looks like this: Entra ID group membership is sourced from HR through SCIM; an access-mapping table in the source database joins user principal names to patient-population scopes; dynamic RLS on the fact table filters rows by that scope; OLS hides high-sensitivity columns from non-clinical users; and DDM at the source masks the raw PHI from any user who lacks UNMASK permission. Every layer is independently testable and independently evidentiable.
For more on the RLS mechanics themselves, see our Power BI row-level security complete guide and the RLS vs OLS comparison.
5. Purview, Sensitivity Labels, and DLP
Microsoft Purview is the control plane that ties Power BI to your broader data classification program. In regulated environments, the Purview integration is not optional — it is the mechanism by which sensitivity labels, DLP, and audit evidence actually flow.
Sensitivity Label Taxonomy
Publish a Purview sensitivity label taxonomy with, at minimum: Public, Internal, Confidential, Highly Confidential — Regulated. Regulated should be a parent label with sub-labels such as PHI, PCI, CUI, ITAR. Apply labels to Power BI datasets, reports, dashboards, and paginated reports. Labels propagate to exported PBIX, PDF, and Excel files, so data that leaves Power BI retains classification context.
DLP Policies for Power BI
Purview DLP policies scoped to Power BI can detect sensitive information types in report content and trigger actions: show a policy tip, notify a compliance team, block export, or block sharing outside the organization. Baseline DLP coverage for a regulated tenant includes SSN, financial account number, HIPAA identifiers, and any custom identifiers for your industry (MRN, claim number, policy number).
Purview Data Map Integration
Register Fabric and Power BI in Microsoft Purview Data Map to pull lineage from source systems through dataflows, semantic models, and reports. Lineage is central to HIPAA breach investigations and to SOX ITGC change management. For additional context, see our Purview data lineage governance guide.
6. Audit Logging and Evidence Collection
Regulated Power BI programs do three things with audit logs: retain them long enough to satisfy the framework, export them to a SIEM for real-time detection, and automate evidence collection for annual audits.
Retention
Purview unified audit retains events for 90 days (E3) or 180 days (E5) by default. HIPAA requires six years. SOC 2 is typically one year for the audit period plus a small tail. FedRAMP is three years. The practical approach is to enable Purview Audit (Premium) for up to ten years of native retention, or to export audit events continuously to Azure Log Analytics, Microsoft Sentinel, Splunk, or another SIEM with a retention policy that matches your longest framework.
SIEM Integration
Stream Power BI activity logs to Microsoft Sentinel through the Office 365 connector. Build analytic rules for patterns such as: mass-download events, sharing to external users, privilege escalation within a workspace, or first-time export from a regulated workspace. Treat Sentinel alerts on Power BI activity the same way you treat Entra ID alerts — first-class signals in your incident response runbooks.
Automated Evidence Collection
Use the Power BI REST API and Microsoft Graph to pull workspace membership, capacity assignments, dataset RLS roles, and sensitivity label coverage on a scheduled cadence. Store snapshots in a dedicated “audit” lakehouse so that auditors can sample any point in the audit period without requiring on-demand tenant access. This single investment cuts audit preparation from weeks to days for most SOC 2 Type II programs.
7. Copilot and Fabric AI Under Regulation
Power BI Copilot and Fabric AI introduce new governance surfaces that did not exist before 2024. In a regulated deployment, Copilot is configured, not assumed. The posture you adopt depends on the framework and the data classification.
HIPAA and Copilot
Copilot is BAA-eligible inside the commercial Microsoft 365 cloud and does not use customer data to train foundation models. Restrict Copilot to specific workspaces, apply sensitivity labels to semantic models used with Copilot, and enable Purview Copilot audit so that every prompt and response is logged for six-year retention. Do not allow Copilot to answer free-text queries against unclassified models.
FedRAMP / ITAR and Copilot
Copilot availability in GCC High and Azure Government tenants is more limited than in commercial and varies by workload. Validate the exact Copilot SKU and workload availability before enabling. For ITAR data in particular, confirm that the Copilot language model endpoint is inside the GCC High authorization boundary.
SOC 2 and Copilot
Auditors will ask for: the Copilot tenant policy, the list of Copilot-enabled workspaces, the Copilot activity log, and your AI acceptable-use policy. Treat AI acceptable use as a formal policy signed by the analyst population, not a blog post.
8. Compliance Decision Framework
Use this five-question framework at the start of every regulated Power BI deployment.
- What is the highest data classification this workspace will contain? The highest classification dictates the tenant (commercial, GCC, GCC High, DoD) and the full control set.
- What frameworks apply, and which is the binding one? Most enterprises face multiple frameworks; design to the strictest, not to the average.
- Where will audit log evidence live, and for how long? If you cannot answer this in one sentence, stop and build the logging pipeline before onboarding workloads.
- Who is the accountable owner for each control? Every row in the control matrix needs a named owner. Shared ownership is no ownership.
- What is our Copilot posture? Enabled, disabled, or partial. Document the decision before any user asks.
For industry-specific playbooks that apply this framework, see our three supporting briefs:
- Power BI for healthcare: HIPAA dashboards and PHI protection
- Power BI for financial services: SOC 2, SOX, and GLBA compliance
- Power BI for government: FedRAMP and ITAR deployment
For related governance depth, see Microsoft Purview data lineage governance, deployment pipelines and CI/CD, gateway architecture for large enterprises, and the Fabric licensing decision framework.
9. Frequently Asked Questions
Is Power BI HIPAA compliant out of the box?
No service is HIPAA compliant by default. Power BI becomes HIPAA eligible only when it is deployed inside a Microsoft 365 or Azure tenant that is covered by an active Business Associate Agreement (BAA) with Microsoft, and when the tenant-level controls, workspace permissions, sensitivity labels, and audit logging are configured to meet the HIPAA Security Rule. Protected Health Information (PHI) flowing through Power BI datasets, reports, or dataflows must be protected with least-privilege access, encryption at rest and in transit, row-level security where appropriate, and audit trails retained for at least six years.
Does Microsoft sign a BAA for Power BI?
Yes. Microsoft offers a BAA that explicitly covers Power BI and Microsoft Fabric as part of the Microsoft Online Services covered services list. The BAA must be accepted by the covered entity before PHI is ingested into Power BI. Verify that the Microsoft Product Terms version referenced by your contract still lists Power BI and Fabric as HIPAA-eligible services. Plugins, third-party connectors, and previews are not automatically BAA-covered and must be evaluated individually.
Can I put Power BI through a SOC 2 Type II audit?
Power BI itself does not undergo your SOC 2 audit, but the way you configure it does. Microsoft operates Power BI and Fabric under its own SOC 1 and SOC 2 Type II attestations, and the reports are available through the Microsoft Service Trust Portal. Your organizational SOC 2 audit assesses the customer-configurable controls on top of the platform: workspace role assignments, row-level security design, dataset refresh secrets handling, Purview integration, audit log retention, DLP policies for exported data, and capacity administration change management. Treat Power BI as an inherited control and document the customer responsibility matrix in your control narratives.
Do I need Power BI for US Government (GCC or GCC High) for FedRAMP?
For FedRAMP Moderate workloads, Power BI Pro or Premium in the commercial Microsoft 365 tenant can be used when the FedRAMP Moderate authorization boundary is sufficient for your data classification. For FedRAMP High, ITAR, or DoD IL4 and IL5 workloads, you must use Power BI in GCC High or Azure Government, which have their own authorization packages. Do not move Controlled Unclassified Information (CUI) or ITAR data through commercial Power BI. The tenant choice is a prerequisite, not a tuning decision, and cannot be reversed easily once content has been ingested.
Does row-level security satisfy HIPAA minimum-necessary requirements?
Row-level security (RLS) is an important tool for minimum-necessary access, but it is not sufficient on its own. HIPAA requires administrative, physical, and technical safeguards working together. RLS handles the technical safeguard of least-privilege data access at the row level inside a semantic model, but it must be paired with workspace role governance so that only the right users can edit the model, Purview sensitivity labels so that exported content remains protected, and auditing so that you can demonstrate who saw what. RLS by itself will not pass a HIPAA audit if the workspace is overshared or if audit logs are incomplete.
How long must Power BI audit logs be retained for HIPAA and SOC 2?
HIPAA requires retention of audit logs for a minimum of six years from the date of creation or the date the record was last in effect, whichever is later. SOC 2 does not prescribe a duration, but most organizations retain between one and seven years depending on their control narrative. Power BI activity logs flow through the Microsoft Purview unified audit log, which by default retains data for 90 or 180 days depending on license. For HIPAA, configure Purview Audit (Premium) or export Power BI audit events to a SIEM such as Microsoft Sentinel, Splunk, or Azure Log Analytics with a six-year retention policy. Retention inside Power BI alone is never sufficient.
What encryption does Power BI use for regulated data?
Power BI encrypts data at rest using Microsoft-managed keys with AES-256 by default, and in transit using TLS 1.2 or higher. For regulated workloads that require customer control of keys, Power BI Premium and Fabric support Bring Your Own Key (BYOK) through Azure Key Vault, allowing you to rotate and revoke the keys used to encrypt semantic models and certain workloads. BYOK is usually required for FedRAMP High and CMMC Level 2 and above, and is recommended (though not strictly required) for HIPAA and PCI DSS environments. Note that BYOK does not encrypt every data surface uniformly; review the Microsoft documentation for covered artifacts before relying on BYOK alone.
Can Fabric store PHI and CUI side by side safely?
Only with explicit architectural separation. The safer pattern is to provision separate Fabric capacities and workspaces for PHI versus CUI, each aligned to the correct authorization boundary (commercial tenant + BAA for PHI, GCC High tenant for CUI). Even within a single authorization boundary, use separate workspaces with distinct sensitivity labels, RLS rules, and capacity admins to prevent lateral access. Storing PHI and CUI in the same workspace or the same Lakehouse significantly increases audit complexity and breach blast radius. Most enterprise programs split regulated workloads into dedicated Fabric capacities.
Is Power BI Copilot safe for HIPAA and SOC 2 environments?
Power BI Copilot, when operated inside a BAA-covered tenant, does not send your data to a third party and does not use customer data to train foundation models. Microsoft provides customer data protection commitments in the Product Terms. However, Copilot introduces new governance surfaces: prompt logs, natural-language query outputs that may surface PHI, and Copilot-generated narratives that may include sensitive fields. For HIPAA environments, restrict Copilot to specific workspaces, classify semantic models with sensitivity labels, enable Purview Copilot audit logs, and train analysts on prompt hygiene. For FedRAMP High and ITAR, validate Copilot availability in your specific cloud (GCC High) before enabling it.
How do I handle data sovereignty for Power BI in regulated industries?
Power BI is provisioned in a specific Microsoft 365 home region and data generally remains in that region, with documented exceptions for certain features (e.g., Azure AD telemetry, global admin services). For EU GDPR, select an EU home region. For US federal workloads, use GCC High or DoD tenants. For Canadian PIPEDA, UK DPA, or Australian Privacy Act obligations, select the regional data centers. Fabric capacity region should match the home region for most use cases. Multinationals with content in multiple jurisdictions should use separate tenants or Fabric multi-geo capabilities rather than relying on a single global tenant.
What is the fastest path to a compliant Power BI deployment?
Follow a five-phase sequence: (1) Governance baseline — confirm BAA, choose tenant type, write the customer responsibility matrix, and define sensitivity label taxonomy. (2) Platform hardening — enable Purview audit, tenant settings lock-down, workspace creation restrictions, and export blocking. (3) Semantic model controls — RLS, OLS, certified datasets, dynamic data masking at source. (4) Monitoring — activity log export to SIEM, DLP for Power BI, Copilot audit. (5) Operational cadence — quarterly access reviews, annual RLS validation, control evidence collection for audits. Most enterprises complete phases 1-3 in 8 to 12 weeks and phases 4-5 as ongoing operations.
Does exporting a Power BI report to Excel bypass RLS?
Export to Excel does not bypass RLS at the time of export — the exported data reflects the filtered rows the user was entitled to see. However, the exported file then sits outside Power BI and outside any RLS boundary, which creates a secondary risk. Apply Purview sensitivity labels to Power BI artifacts so that labels flow with exported files; enable DLP policies in Power BI to block export for highly sensitive workspaces; and configure tenant settings to restrict "Export to Excel" and "Analyze in Excel" for regulated workspaces. For HIPAA and ITAR workloads, most programs disable raw-data export entirely for non-certified users.
How do I evidence Power BI controls to an external auditor?
Build an evidence package mapped to your control framework. Typical evidence includes: BAA acceptance letter, tenant settings export, workspace permission export from Power BI Admin API or Graph, capacity admin list, Purview audit log samples for the audit period, RLS role definitions and test-user results, sensitivity label policy definitions, DLP policy definitions, Copilot activity samples, and screenshots of the Microsoft Service Trust Portal SOC 2 report. Automate evidence collection through the Power BI REST API, Microsoft Graph, and Azure Policy where possible. Manual screenshots are acceptable but slow; most mature programs automate 70 percent of evidence within 12 months.
Do I still need an external SOC 2 auditor if Microsoft is already SOC 2 attested?
Yes. Microsoft SOC 2 attestations cover the platform Microsoft operates. Your SOC 2 report covers the controls you operate on top of the platform, including how you configure Power BI, manage access, respond to incidents, and handle customer data. Auditors will ask for the Microsoft SOC 2 report (from the Service Trust Portal) as evidence of inherited controls, and then audit your customer-configurable controls separately. Carve-out versus inclusive subservice organization treatment is a decision you make with your auditor. Either way, you cannot inherit Microsoft's SOC 2 as your own.
What compliance pitfalls are most common in Power BI deployments?
The five most common pitfalls are: (1) enabling Copilot or external sharing tenant-wide before governance is ready; (2) relying on workspace role "Member" as a security boundary when the role actually grants broad edit rights; (3) leaving Power BI activity logs at default 90-day retention for a HIPAA environment; (4) failing to apply sensitivity labels at the dataset level, which breaks DLP downstream; and (5) using a single Fabric capacity for both PHI and general analytics, which complicates scoping during audits. Addressing these five items alone eliminates most audit findings.
Ready to Transform Your Data Strategy?
Get a free consultation to discuss how Power BI and Microsoft Fabric can drive insights and growth for your organization.