The 4-layer Power BI Enterprise Security architecture
Power BI security for the most sensitive enterprise data is not a single feature toggle — it is a 4-layer integrated architecture. EPC Group designs against all four layers from day one.
Power BI Enterprise Security for Sensitive Data
EPC Group · Power BI Services · 2026
Enterprise Power BI security architecture — Row-Level Security + Object-Level Security at scale, Microsoft Purview sensitivity labels, conditional access, audit logging, Microsoft Sentinel SOC integration, regulated-industry compliance, tenant isolation for classified + ITAR + IL5/IL6 + healthcare PHI + financial-services sensitive data.
Published June 25, 2026 · Updated continuously
Last updated by Errin O'Connor, Founder & Chief AI Architect, EPC Group
EPC Group designs Power BI enterprise security architectures for the most sensitive enterprise data — healthcare PHI, financial services trading + risk data, federal classified + CUI + ITAR-controlled technical data, trade-secret IP. The architecture spans 4 integrated layers: Row-Level Security (RLS) + Object-Level Security (OLS) at enterprise scale (1M+ users, 100B+ rows, 50+ business unit boundaries); Microsoft Purview Information Protection sensitivity labels + DLP propagated end-to-end through OneLake → Fabric semantic models → Power BI reports → exported files; Microsoft Entra Conditional Access + Privileged Identity Management for device-compliance + MFA + session controls + just-in-time admin elevation; Microsoft Sentinel SOC integration with custom KQL detection rules + SOAR runbooks for anomaly response. Compliance-native for HIPAA + HITRUST + NYDFS Part 500 + FedRAMP + DoD IL5/IL6 + CMMC 2.0 + Illinois BIPA + GDPR. High-touch, senior-architect-led delivery without junior consultants learning on the engagement.
EPC Group designs Power BI security for sensitive data with 4 integrated layers: RLS + OLS at enterprise scale, Microsoft Purview sensitivity labels + DLP, Conditional Access + Entra PIM, Microsoft Sentinel SOC integration. Compliance-native HIPAA + NYDFS + FedRAMP + IL5/IL6 + CMMC + BIPA + GDPR. Senior-architect-led delivery. 3-week Assessment + 12-16 week Implementation + ongoing Cloud Orchestrator retainer.
Key Facts
- Row-Level Security (RLS) + Object-Level Security (OLS) at 1M+ users + 100B+ row fact tables + 50+ business unit boundaries
- Microsoft Purview Information Protection sensitivity labels propagated OneLake → Fabric → Power BI semantic model → report → exported PDF/Excel/PowerPoint files
- Microsoft Entra Conditional Access + Privileged Identity Management + Microsoft Intune device compliance + session controls
- Microsoft Sentinel SOC integration + custom KQL detection rules + SOAR runbooks for automated anomaly response
- Compliance-native for HIPAA + HITRUST + NYDFS Part 500 + SEC Rule 17a-4 + SOX + FedRAMP + DoD IL5/IL6 + CMMC 2.0 + Illinois BIPA + GDPR + Washington MHMDA + California CCPA + CPRA + CMIA
- Tenant isolation patterns for classified + ITAR + IL5/IL6 + trade-secret data — dedicated GCC High / DoD tenant + dedicated Premium capacity + Azure Government + PAW + air-gapped backup
- Documented engagement experience: FRBNY TARP eDiscovery + Vivek Kundra federal IT advisory + National Archives + U.S. intelligence community + multi-hospital health systems + derivatives + futures + HFT operators
- High-touch senior-architect-led delivery — 3-week Assessment + 12-16 week Implementation + ongoing Cloud Orchestrator Practice retainer with monthly security health checks + quarterly Sentinel rule tuning + business-hours IR
Row-Level Security (RLS) + Object-Level Security (OLS) at scale
EPC Group designs RLS + OLS at enterprise scale (1M+ users, 100B+ row fact tables, 50+ business unit boundaries) using DAX-based dynamic RLS + role-mapping tables + Microsoft Entra ID security group integration. OLS hides specific tables/columns from user-by-user perspectives without breaking semantic model design. Composite-model RLS patterns for Direct Lake + Import + DirectQuery hybrid architectures. Documented enterprise outcomes: 100% data-classification boundary enforcement across 1B+ row semantic models without performance regression.
Microsoft stack
DAX dynamic RLS + role-mapping tables + Entra ID security groups + OLS via Tabular Editor + composite-model patterns
Microsoft Purview sensitivity labels + DLP
EPC Group implements Microsoft Purview Information Protection sensitivity labels propagated end-to-end: OneLake → Fabric semantic model → Power BI dataset → Power BI report → exported PDF/Excel/PowerPoint files. Labels carry encryption + access restriction + watermark + content marking throughout the Power BI export lifecycle. DLP policies prevent labeled-Confidential data from being exported via unauthorized channels (personal email, Dropbox, USB). Documented enterprise outcomes: >85% sensitivity-label coverage on in-scope analytical data within first 6 months.
Microsoft stack
Microsoft Purview Information Protection + Sensitivity Labels + DLP policies + Microsoft Defender for Cloud Apps + Endpoint DLP
Conditional access + Entra PIM + privileged identity
EPC Group designs conditional access policies aligned to Power BI usage: device-compliance enforcement (only managed Intune devices can access Power BI Premium workspaces with sensitive labels), location restrictions (block access from sanctioned-country IPs), session controls (limit download/print for high-sensitivity reports), MFA-on-every-session for tier-1 financial + healthcare workspaces. Microsoft Entra Privileged Identity Management (PIM) for Power BI Admin + Capacity Admin + Workspace Admin roles requires just-in-time elevation + manager approval + time-bound + activity logging.
Microsoft stack
Microsoft Entra Conditional Access + Entra PIM + Defender for Cloud Apps session controls + Microsoft Intune device compliance
Audit logging + Microsoft Sentinel SOC integration
EPC Group integrates Power BI audit logs into Microsoft Sentinel via the Power BI Activity Log connector + Office 365 unified audit log. Custom Sentinel analytics rules detect anomalies: unusual export volume by user, off-hours admin elevation, large dataset downloads, RLS bypass attempts, sensitive-label dataset access from unmanaged devices. Integration with Microsoft Defender XDR for cross-domain correlation (Power BI export → email leak → endpoint compromise chain). Sentinel SOAR runbooks auto-respond to detected anomalies (force re-authentication, suspend account, isolate device, notify SOC analyst).
Microsoft stack
Microsoft Sentinel + Power BI Activity Log connector + Defender XDR + custom KQL detection rules + SOAR runbooks
Row-level security and advanced security in Power BI: what each control does
Row-level security and advanced security in Power BI are four separate controls. EPC Group designs them together because each covers a gap the others leave.
| Control | What it does (per Microsoft Learn) | Watch for |
|---|---|---|
| Row-level security (RLS) | Restricts which rows of a semantic model a user sees, through DAX filters in roles | Applies only to workspace Viewers, not Admins, Members or Contributors |
| Object-level security (OLS) | Hides whole tables or columns, including their metadata, from report viewers | Also applies only to Viewers |
| Microsoft Purview sensitivity labels | Classify content and travel with supported exports (Excel, PowerPoint, PDF, .pbix) with the label's encryption | Labels do not control access inside the Power BI service; .csv exports carry no label |
| Workspace roles | Admin, Member, Contributor and Viewer | Because RLS and OLS stop at Viewer, who gets a higher role is itself a security decision |
EPC Group tests every role with a real user account in each persona before release. Sources: row-level security, object-level security, sensitivity labels in Power BI (Microsoft Learn, accessed 2026-11-07).
Power BI RLS implementation, object-level security and secure embedded analytics
Power BI row-level security consulting at EPC Group follows the workflow Microsoft documents: roles and their DAX filter rules are defined in Power BI Desktop, the model is published, members are assigned to roles on the semantic model in the Power BI service (not in Desktop), and each role is checked with Test as role. Most enterprise models use dynamic RLS: one role filters a user-mapping table with USERPRINCIPALNAME(), so a single definition serves every user. Two limits shape the design. Microsoft 365 groups can't be added to RLS roles (security, distribution and mail-enabled groups can), and Test as role uses your own identity for dynamic rules, so dynamic RLS is also tested with real user accounts.
Power BI object-level security hides whole tables or columns, including their names and metadata, from report viewers; for them it is as if the objects don't exist. OLS is defined in the same model roles, in TMDL view in Power BI Desktop or in an external tool such as Tabular Editor, by setting the object's metadata permission to None. RLS and OLS can't be combined from different roles: a user who belongs to such a combination gets an error at query time, so the role matrix is designed before either is written.
Secure embedded analytics depends on the embedding model. In embed for your customers (app owns data), app users need no Power BI license and the app signs in with a service principal or a master user; RLS and OLS come from the effective identity in the embed token (user name, roles and semantic model), and role assignments made in the Power BI service don't apply. If a service principal sends no identity, token generation fails; a master user without one gets all the data. In embed for your organization (user owns data), every user needs a Power BI license and signs in with Microsoft Entra ID. A service principal needs two tenant settings turned on by a Power BI admin and Member or Admin access to the workspace, and Microsoft recommends certificates rather than secrets. Production embedding requires a capacity (A, EM, P or F SKU); Microsoft is retiring the Power BI Premium per-capacity (P) SKUs and recommends Fabric F SKUs instead.
Sources (Microsoft Learn, accessed 2026-11-07): row-level security, object-level security, combining OLS and RLS, embedded analytics, RLS in embedded content, embedding with a service principal, embedded capacity, P SKU retirement notice.
Related EPC Group services
- Power BI consulting — 1,500+ enterprise implementations
- Power BI Accelerators — Health Check + CoE + Performance + Migration
- Enterprise Azure Analytics Platform — 8-layer architecture
- Microsoft 365 + Azure Backup & DR
- AI Governance — Microsoft Purview + Defender XDR + Sentinel
- Governed AI on Microsoft Framework
- Federal Government Microsoft Consulting
- EPC Group facts — source-linked credentials
Frequently asked questions
What does Power BI row-level security consulting cover, and where does object-level security fit?
Row-level security filters rows for workspace Viewers only, not for Admins, Members or Contributors, and Build permission does not bypass it; roles are written in Power BI Desktop and members are assigned in the service, a user in several roles gets the combined access, and Microsoft 365 groups and service principals cannot be role members. Power BI object-level security hides tables and columns from Viewers as if they did not exist; it is defined in TMDL view or Tabular Editor, and row-level and object-level security from different roles for the same user raise an error at query time. On Direct Lake, RLS defined at the SQL analytics endpoint makes queries fall back to DirectQuery, so EPC Group decides where each rule lives before the model ships (Microsoft Learn, accessed 2026-11-07).
How do you secure embedded Power BI analytics for customers?
In embed for your customers (app owns data), the embed token carries an effective identity (user name, roles and semantic model), and that identity drives RLS and OLS; role assignments in the Power BI service do not apply. A service principal that sends no identity cannot get a token, while a master user without one sees all the data. Production embedding needs an A, EM, P or F capacity, and Microsoft recommends Fabric F SKUs as the P SKUs retire (Microsoft Learn, accessed 2026-11-07).
What does row-level security and advanced security in Power BI cover?
Row-level security (RLS) filters rows with DAX rules in roles, object-level security (OLS) hides whole tables or columns, and Microsoft Purview sensitivity labels classify content and protect supported exports. RLS and OLS apply only to workspace Viewers, so workspace role assignment is part of the security design (Microsoft Learn, accessed 2026-11-07).
How does EPC Group handle Row-Level Security at enterprise scale (1M+ users, 100B+ rows)?
Dynamic RLS using DAX USERNAME() or USERPRINCIPALNAME() functions joined to role-mapping tables sourced from Microsoft Entra ID security groups. Role-mapping tables are refreshed daily from HR + identity sources. For multi-dimensional security (user × region × business unit × product line), composite role-mapping tables with sparse joins to fact tables. For 100B+ row fact tables, RLS predicate pushdown to source (Azure Synapse Dedicated SQL Pool, Fabric Warehouse, Azure SQL) ensures security filtering happens at source not in Power BI engine — avoiding the performance penalty of in-engine row filtering on massive tables. Documented enterprise outcomes: sub-second query performance on 100B+ row fact tables with 1M+ concurrent users and 50+ business-unit RLS boundaries.
What is the difference between Row-Level Security (RLS) and Object-Level Security (OLS) in Power BI?
RLS filters ROWS in fact tables based on user role — user A sees only their region's sales, user B sees only their department's expenses. OLS hides entire TABLES or COLUMNS from specific users — user A cannot see the Compensation table at all, user B cannot see the Profit_Margin column. RLS is configured via DAX expressions in Power BI Desktop + service. OLS is defined in the same model roles, in TMDL view in Power BI Desktop or in an external tool such as Tabular Editor (Microsoft Learn, accessed 2026-11-07). EPC Group designs both in tandem: OLS hides sensitive tables/columns from users who should not even know they exist, RLS filters remaining data based on user role.
How does Microsoft Purview sensitivity labeling work with Power BI?
When a Microsoft Purview Information Protection sensitivity label (e.g., "Confidential - Financial") is applied to a Power BI semantic model or report, the label propagates downstream: (1) Power BI Desktop shows the label in title bar; (2) Power BI Service displays the label badge on reports + dashboards; (3) Exports to Excel, PowerPoint, PDF and .pbix inherit the label with its encryption settings, and .csv exports carry no label (Microsoft Learn, accessed 2026-11-07); (4) Files opened on managed devices honor the label's permissions (e.g., "do not forward", "do not print", "expire after 30 days"); (5) Microsoft Defender for Cloud Apps + Microsoft Sentinel can detect attempts to bypass label restrictions. EPC Group typically deploys label hierarchy: Public / Internal / Confidential / Highly Confidential / Restricted, with sub-labels for specific regulatory regimes (HIPAA-PHI, PCI-DSS-Cardholder, ITAR-Controlled, CMMC-CUI).
How does EPC Group secure Power BI for HIPAA-protected health information (PHI)?
Compliance-native architecture: (1) HIPAA BAA-aligned Power BI Premium capacity in Azure Government or Microsoft 365 GCC tenant depending on covered entity vs business associate scope; (2) Microsoft Purview sensitivity label "Confidential - HIPAA PHI" applied to all semantic models containing PHI; (3) DLP policies block PHI export via unauthorized channels; (4) Conditional access requires managed Intune devices + MFA for PHI workspace access; (5) Audit logging integrated to Microsoft Sentinel for 7-year retention (HIPAA requires 6 years for documentation); (6) RLS enforces minimum-necessary access principle by patient/encounter/provider; (7) De-identified analytics workspace separated from PHI workspace for research use cases. Documented engagement experience: multi-hospital health systems including ambient documentation governance + clinical decision support model risk management programs.
How does EPC Group secure Power BI for NYDFS Part 500 + financial services?
NYDFS 23 NYCRR Part 500 (and 2023/2024 amendments) require covered financial institutions to implement specific cybersecurity controls including MFA + encryption + vulnerability management + third-party risk + board-level reporting + 72-hour incident notification. EPC Group ships Power BI deployments aligned to the EPC NYDFS Part 500 reference architecture for NY-licensed banks + insurers + investment advisers: (1) Microsoft Defender XDR + Microsoft Sentinel for SIEM/SOAR meeting NYDFS Part 500.6 logging; (2) Entra PIM with manager approval for all Power BI Admin elevations meeting Part 500.7 access controls; (3) Microsoft Purview Records Management meeting Part 500.13 records retention + SEC Rule 17a-4 WORM; (4) Annual CISO certification support documentation; (5) Third-party AI service provider risk assessment for Copilot for Power BI integration.
What is EPC Group's pattern for Power BI tenant isolation when handling extremely sensitive data?
For classified, ITAR-controlled, federal IL5/IL6, or trade-secret-level data, EPC Group designs tenant isolation patterns: (1) Dedicated Microsoft 365 GCC High or DoD tenant separate from commercial M365 tenant; (2) Dedicated Power BI Premium capacity isolated from other workloads with no cross-capacity sharing; (3) Dedicated Azure Government region for compute + storage; (4) Dedicated Microsoft Entra ID tenant with no B2B trust to commercial tenant; (5) Privileged Access Workstation (PAW) requirements for all admin operations; (6) Air-gapped backup architecture separate from operational backup; (7) Documented cross-domain transfer (CDT) procedures for any data movement between classified and unclassified tiers. Documented engagement experience: U.S. intelligence community + Federal Reserve Bank of New York TARP eDiscovery + Vivek Kundra federal IT advisory + National Archives + DoD aerospace suppliers.
How does EPC Group integrate Power BI security with Microsoft Sentinel SOC?
Power BI Activity Log + Office 365 unified audit log streamed to Microsoft Sentinel via Azure Log Analytics. Custom KQL detection rules surface security-relevant patterns: (1) Anomalous export volume per user (statistical baseline + spike detection); (2) Off-hours admin elevation attempts; (3) Large dataset downloads to unmanaged devices; (4) RLS bypass attempts (user attempting to access workspace they lack role for); (5) Sensitive-label dataset accessed from non-compliant device; (6) Service principal authentication anomalies. Detected anomalies trigger Sentinel SOAR runbooks: force re-authentication, suspend account, isolate device via Microsoft Defender for Endpoint, notify SOC analyst with full investigation context. EPC Group provides the deployed Sentinel content + the documented investigation runbooks.
What is EPC Group's delivery model for Power BI Enterprise Security engagements?
High-touch, senior-architect-led delivery without junior consultants learning on the engagement. Typical engagement: 3-week Power BI Security Assessment (fixed fee), then 12-16 week Implementation + Tenant Hardening (fixed fee, scoped by tenant and regulatory environment), then ongoing Microsoft Cloud Orchestrator Practice retainer covering monthly security health checks + quarterly Sentinel rule tuning + incident response during business hours (Central). Named EPC senior architect responsible end-to-end. Compliance-native — HIPAA + NYDFS + FedRAMP + CMMC 2.0 baked into Phase 1, not retrofit after audit findings.
Ready to secure your Power BI for sensitive data?
Reach EPC Group for a one-hour Power BI Security call with a senior architect. We'll review your tenant + workspace posture, identify the highest-risk gaps, and outline the fixed-fee 3-week Assessment scope.
Related reading
- Microsoft Fabric May 2026: Power Query Get Data, Copilot Tooling Format, and the Enterprise Migration Playbook
- Power BI May 2026 Feature Summary: New Power Query Get Data + Card States
- Power BI Pro vs Premium Per User: Which License Do You Need?
- Power BI Refresh Architecture: Why Your Reports Break Every Monday Morning
- How to Organize 200+ Power BI Reports Into an Intuitive Navigation Structure
- Microsoft 365 Security Assessment Checklist (2026)
- Microsoft Power Automate Enterprise Guide (2026)
- Can EPC Group build an end-to-end Azure data warehouse or Fabric lakehouse and Power BI reporting solution?
- Fixed-Fee Microsoft 365 Security Accelerator Programs (2026)
- Power Platform Enterprise Governance (2026)
Documented and anonymized engagements
Named engagements come first; anonymized summaries follow under the anonymized-engagement rule — the client is not named and every statement is EPC-reported. Documents behind named engagements are in the Evidence Center.
- Town of Prosper, Texas — Power BI data project (2024)Town of Prosper, Texas · 2024 · Contracted
- Smarter Balanced (University of California, Santa Cruz) — Power BI consulting and development with Power BI Embedded (2023)Smarter Balanced (University of California, Santa Cruz) · 2023 · Contracted
- Haskell (The Haskell Company) — Power BI Report Server to Power BI Service migration (2019)Haskell (The Haskell Company) · 2019 · Contracted — countersigned
- Power BI Weld QA/QC and Fabric: Industrial Contractor (2026)Anonymized engagement summary · Industrial construction contractor · 2026
- Azure Data Warehouse and Power BI: Medical Devices (2025)Anonymized engagement summary · Medical device manufacturer · 2025
- Data Warehouse and Partner Power BI: Healthcare (2025)Anonymized engagement summary · Healthcare services company working with partner clinics · 2025
- Power BI and Copilot Training: Truck Dealer Group (2023–25)Anonymized engagement summary · Commercial truck dealership group · 2023–2025Engagement phase: Power BI support (2023 to 2024) and a Copilot for Power BI training curriculum (2025); the number of people trained is not reported
- Urgent Power BI Model Fix: Healthcare Technology (2025)Anonymized engagement summary · Healthcare technology company · 2025
More engagements: Power BI Tax Reporting on MySQL: Tax Services Firm (2024) · Power BI Ops Dashboard: Transit District (2023) · Power BI Report Server Refresh Fix: Agribusiness (2021) · Power BI, Data Warehouse and External Reports: Gaming (2021) · SAP Reports to Power BI in 90 Days: Aerospace (2021) · Power BI Governance Strategy: Global Insurer (2020) · Power BI on HR System Data: Construction Contractor (2020) · Power BI POC, Governance and Roadmap: Electronics (2020) · Power BI Assessment and Integration: Pharmacy (2019) · Power BI Proof of Concept: Global Technology Company (2019) · Power BI Best-Practice Review and Training: Insurer (2018) · Power BI Analytics Platform: State Government · Power BI Enterprise Deployment: Financial Institution