Power BI Security Audit for Existing Tenants

What does a Power BI security audit cover?

Most organizations stand up Power BI quickly. Pro licenses get bought, workspaces get created, a few dashboards go live, and within two years the tenant is full of reports nobody fully maps anymore. Permissions accrete. Service principals stay long after the project that needed them. Sensitivity labels are configured but never applied. A few reports get marked "Publish to Web" for an executive demo and quietly stay public. None of this is malicious, it's the default consequence of fast adoption. A formal security audit is how you find it before an external assessor, a customer questionnaire, or a regulator does.

Request a Power BI security audit today: Request a Quote from Petronella Technology Group, Inc.

The top 15 Power BI misconfigurations we find on audit

These are the fifteen findings Petronella Technology Group, Inc. produces most often when auditing existing Power BI tenants. The severity tags reflect both the likelihood of data exposure and the difficulty an external assessor will have accepting a compensating control. Every finding maps to at least one of NIST 800-171 r3, the HIPAA Security Rule, SOC 2 Trust Services Criteria, and ISO 27001 Annex A.

1. Publish to Web enabled Critical The "Publish to web" tenant setting renders a report to a public URL with no Microsoft Entra ID authentication. Per Microsoft, this feature is intended only for genuinely public data, anything else is a likely confidentiality breach. We find it enabled in roughly two of three tenants we audit, often because a single executive needed an external embed years ago.
2. Broad RLS roles with admin bypass Critical Power BI Service administrators and workspace administrators bypass Row-Level Security by default. When the same person who maintains content also has the admin role, the practical effect is that RLS protects only end users, not the people most likely to export data. Microsoft's published guidance on RLS explicitly calls out the admin bypass, and assessors treat this as a finding when admin and authoring duties are not separated.
3. Service principal sprawl High Microsoft Entra service principals accumulate as embedded apps, CI/CD pipelines, automation, and one-off integrations come online. We routinely find tenants with dozens of active service principals, half of which haven't authenticated in 90+ days, several with workspace Admin or Member rights that the original project never needed. Each one is a long-lived non-human identity that needs ownership, rotation, and review.
4. No sensitivity labels applied High Microsoft Information Protection sensitivity labels, Confidential, Internal, CUI, ePHI, propagate to exports, downstream Excel files, and Purview DLP policy enforcement. If labels are not applied to datasets and reports, none of the downstream protections fire. We commonly see tenants where labels are configured but coverage is under 10%, which means the controls technically exist but aren't actually doing work.
5. External sharing wide open High "Allow Microsoft Entra B2B guest users to access Power BI" and "Share content with external users" tenant settings often default to the entire organization. The right configuration is almost always a small allowlist of partner domains, with guest reviews enforced through Microsoft Entra ID Governance access reviews. Over-broad external sharing is one of the top findings in any partner-data scenario.
6. No audit log forwarding to SIEM High Power BI's native Activity Log retains 30 days. The Microsoft 365 Unified Audit Log retains 90 days to 10 years depending on license. CMMC and most government baselines require at least one year. HIPAA requires six. Without forwarding to Microsoft Sentinel or another SIEM, you cannot reconstruct an incident more than a few weeks old, and you cannot answer "who exported that report" past the retention horizon.
7. Weak MFA enforcement High Microsoft Entra Conditional Access policies that allow SMS or voice-call MFA, or that exempt service accounts and break-glass identities without compensating control, are routine findings. Microsoft's identity guidance has moved firmly to phishing-resistant MFA (FIDO2 keys, Windows Hello, certificate-based) for any privileged Power BI role. Audit assessors increasingly expect to see the upgrade plan.
8. Unpatched on-prem data gateways High Power BI on-premises data gateways are the bridge between your internal data sources and the Power BI service. Microsoft ships monthly gateway updates and supports each version for six months. We find production gateways three to nine months out of support, often on Windows Server hosts that are themselves behind on patches. That bridge is one of the highest-value attack surfaces in the whole stack.
9. Hardcoded credentials in Power Query or DAX High Credentials, connection strings, and API tokens occasionally appear directly inside Power Query M code or in calculated columns. Once a PBIX file is exported or copied to a developer laptop, those secrets travel with it. Best practice is to use parameterized connections, Microsoft Entra service principals with certificate authentication, or Azure Key Vault, never inline strings.
10. No Deployment Pipelines (manual prod pushes) Medium Without Deployment Pipelines (a Power BI Premium / Fabric capability), promotion from Dev to Test to Prod happens by re-publishing PBIX files directly into the Prod workspace. There is no separation of duties, no change history, and no rollback. SOC 2 CC8.1 and CMMC 3.4 both expect a change-management control that the manual workflow cannot satisfy.
11. Broad workspace administrators Medium Workspace Admin and Member roles are routinely handed out so users can "just get the report to publish." Admin role bypasses RLS. Member role allows publish, share, and re-share. Both should be a small, named set per workspace, with Viewer or Contributor used for everyone else. We routinely find five-person workspaces with eight Admins.
12. No data refresh monitoring Medium Power BI dataset refreshes fail silently from the consumer's perspective, the report still loads, just with yesterday's (or last quarter's) data. Without alerting on refresh failures and stale-data monitors, leadership ends up making decisions on stale numbers. Microsoft documents both API-based monitoring (refresh history) and Power BI Admin dataset health reports; few tenants enable either.
13. Unsecured legacy embed tokens Medium Embed-for-customer and embed-for-organization patterns sometimes still use legacy embed tokens issued without an effective identity claim, or with effective identities that do not match RLS roles. Audit those flows for token TTL, identity scoping, and that RLS roles are being passed correctly. Microsoft's published embed samples have changed multiple times; older implementations need a review.
14. No periodic access reviews Medium Workspace and dataset access typically accretes, joiners get added, leavers rarely get removed, and movers keep the union of both roles. Microsoft Entra ID Governance access reviews can be scheduled quarterly against Power BI workspaces. Without them, you cannot demonstrate ongoing entitlement validation to an auditor (SOC 2 CC6.3, ISO A.5.16).
15. Copilot access to restricted data Medium Copilot in Power BI inherits the calling user's permissions, so it does not by itself escalate access, but it lowers the friction to aggregate sensitive information and paste it elsewhere. Microsoft Purview Data Loss Prevention policies can scope Copilot away from data with restricted sensitivity labels. In greenfield Copilot deployments, that scoping is rarely set, and the resulting risk surface is genuinely new.

Citation note: Each item above maps to one or more Microsoft Learn references on Power BI security planning, Row-Level Security, sensitivity labels, gateway lifecycle, service principal authentication, and Copilot governance. Petronella Technology Group, Inc. cites Microsoft's official documentation in every audit deliverable so findings hold up under external scrutiny.

Ready to find these in your own tenant? Request a Quote

Row-Level Security deep dive: static vs dynamic, admin bypass, and how to test

Static vs dynamic RLS

Static RLS hardcodes the filter inside the role itself, for example, a role named "East" whose DAX filter is [Region] = "East". Static is simple, easy to audit, and appropriate when the role-to-data mapping rarely changes. The downside: you maintain it inside Power BI Desktop, and every territory reassignment requires a developer to edit the PBIX, republish, and re-test.

Dynamic RLS reads the calling user's identity through DAX USERPRINCIPALNAME() and joins it against a user-to-territory mapping table inside the model. Re-territory-ing a sales rep is a single row update in the source system. Dynamic RLS is the right default for any organization that reassigns territories, hires, or restructures more than once a year.

Common RLS pitfalls

The admin-bypass problem

Power BI Service administrators and workspace administrators bypass RLS by design. Microsoft's published guidance on Row-Level Security explicitly calls this out: RLS is intended for end-user access to content already published. It is not a substitute for least-privilege admin role assignment.

Practical mitigations Petronella Technology Group, Inc. recommends:

• Segregate workspace admin duty from content authoring. The admin should not be a person who routinely exports data.
• Use Microsoft Entra Privileged Identity Management to require just-in-time activation of workspace admin roles, with a short TTL and an approver.
• Forward every admin-level Power BI activity to a SIEM with alerting on bypass impressions.
• In CMMC and HIPAA environments, document the admin bypass and the compensating control in your System Security Plan.

Testing RLS without exposing real user accounts

Petronella Technology Group, Inc. uses Power BI Desktop's View as Role feature and the Power BI Service's View as feature with synthetic test identities mapped through the same dynamic RLS pattern as production. For each role, we test: a representative user with full row visibility for that role, a boundary user (last row of the assignment), a user with no assignment (expected: zero rows), and a user assigned to multiple roles (expected: union of both). The test output is a sign-off matrix the report owner approves before deploy.

Need an independent review of your RLS implementation? Request a Quote

Object-Level Security: hiding sensitive columns and tables

Object-Level Security (OLS) is the layer that hides entire tables or specific columns from defined roles, even from the field list. RLS filters which rows a user can see. OLS removes columns and tables the user is not allowed to know exist.

OLS increases semantic model complexity and adds a maintenance surface. It is the right choice when row-level filtering is not sufficient, when the existence of a column or table is itself sensitive. Petronella Technology Group, Inc. recommends OLS for HR, finance, executive compensation, M&A, legal-hold, and any model containing protected health information columns that should be invisible outside the clinical role.

Sensitivity labels (MIP) and Microsoft Purview integration

Microsoft Information Protection sensitivity labels are the connective tissue between Power BI, Microsoft 365, and Microsoft Purview Data Loss Prevention. A label applied to a Power BI dataset propagates with the data into Excel and PDF exports, surfaces in Outlook, gets enforced by DLP policies, and shows up in Microsoft Purview compliance reporting.

A working label taxonomy for regulated organizations

Why labels alone aren't enough

A label is metadata. It only protects data if downstream systems enforce it. The Petronella Technology Group, Inc. audit verifies four enforcement points:

• Coverage: What percentage of datasets, reports, and dashboards carry a label? Below 80%, the controls are theatre.
• Inheritance: Are labels inherited from source data (Power BI dataset → Excel export → email attachment), or do they drop at each handoff?
• DLP enforcement: Do Microsoft Purview DLP policies actually block paste, attachment, or external chat of labeled content? Or are they in audit-only mode?
• Copilot scoping: Is Copilot in Power BI blocked from accessing restricted-label datasets? This is opt-in policy, not default.

Service principal certificate authentication (not secrets)

When automated processes, refreshes, embedded analytics, CI/CD pipelines, custom apps, connect to Power BI, the right identity is a Microsoft Entra service principal rather than a user account. Service principals don't break when the original developer leaves. They don't require MFA prompts that automation can't satisfy. They scope to exactly the permissions an automated process needs.

The wrong way to authenticate a service principal is with a client secret, a long string that ends up in source control, deployment scripts, environment files, and developer laptops. Microsoft Entra supports both methods, but for any production service principal, Petronella Technology Group, Inc. recommends certificate-based authentication:

• Issue a certificate from your internal CA or Azure Key Vault.
• Upload the public key to the Microsoft Entra app registration.
• Store the private key in Azure Key Vault, a Windows certificate store on the application host, or a hardware-backed store on a managed identity host.
• Rotate annually (or per policy). Track issue / expiry in your existing PKI lifecycle.
• Audit Power BI workspaces quarterly for service principals whose owner has left the organization, whose project has wound down, or whose last sign-in is more than 90 days old.

The audit deliverable for this section is a full service principal inventory across the tenant: name, owner, application registration, workspace assignment, role, authentication method, certificate expiry, and last-used timestamp. Most clients are surprised by how many of their service principals fail the "still has an owner" test alone.

Audit log retention: SIEM forwarding for 1+ year (6+ years for HIPAA)

Audit log retention is where Power BI security audits most often run into hard regulatory deadlines. Microsoft's native retention is short:

The fix is forwarding. Petronella Technology Group, Inc. configures Power BI audit events into Microsoft Sentinel or our own managed Petronella Extended Detection and Response (XDR) for long-term retention, alerting, and correlation with the rest of the Microsoft 365 audit stream. Forwarding gives you a single pane for "who exported what" queries six years deep, satisfies HIPAA §164.316(b)(2), satisfies CMMC AU controls, and stays well clear of the Microsoft 365 retention edge cases.

Power BI audit events worth alerting on

• ExportReport, ExportDataset, ExportArtifact, outbound data movement, prime forensic signal.
• UpdateTenantSetting, any change to Publish to Web, external sharing, or admin tenant settings should fire.
• AddWorkspaceAdmin, UpdateWorkspaceAccess, privilege escalation events.
• ServicePrincipalCreated, ServicePrincipalCredentialAdded, new automation identity, new long-lived credential.
• UpdateDataSensitivityLabel, somebody downgraded a label. Investigate.
• CreateGroup, UpdateGatewayPermission, gateway access changes.

Quick-win remediations: must-fix vs hour-saver

Not every finding deserves the same urgency. Petronella Technology Group, Inc. delivers an effort/severity matrix alongside the findings list so leadership can sequence work pragmatically. The table below is the canonical first wave of remediations we run for nearly every audit client.

The must-fix wave is usually a single sprint. The hour-saver wave folds into ongoing managed Power BI governance through Petronella Technology Group, Inc.

Engagement model: Health Check (lead magnet) → Audit (anchor)

Petronella Technology Group, Inc. offers two engagement depths so you can match cost and rigor to your actual risk posture. Both are fixed-fee. Both end with a written deliverable signed by a Petronella consultant.

Both engagements are fixed-fee, payable 100% at contract execution. The Health Check often runs first as a discovery call, with the Audit scoped immediately on the back of it.

Pairs well with vCISO, ComplianceArmor®, and Petronella XDR

A Power BI security audit rarely lives alone. Petronella Technology Group, Inc. typically pairs it with one or more of the following ongoing services so the wins from the audit don't quietly regress in the next two quarters.

If you arrived at this page because Power BI was the urgent question, fine. But CMMC, HIPAA, SOC 2, and the everyday Microsoft Entra hygiene questions all sit upstream of the audit, and ignoring them is the most common reason an audit's findings come back unchanged a year later. The cross-sell isn't a sales hook. It's how we keep the work from going stale.

Related Petronella Technology Group, Inc. services

Power BI security audit FAQ

About the author

Craig Petronella

CMMC-RP · Cisco CCNA · CWNE · Digital Forensic Examiner (License 604180-DFE) · Amazon #1 Best-Selling Author of 14+ cybersecurity books

Craig is the founding principal of Petronella Technology Group, Inc., a Raleigh, NC cybersecurity and compliance firm operating since 2002. As a state-licensed Digital Forensic Examiner (License 604180-DFE) and CMMC Registered Practitioner, Craig has led incident response, compliance program build, and forensic investigations across DoD supply chain, healthcare, financial services, and professional services clients.

The Petronella Technology Group, Inc. team includes four CMMC-RP staff, Craig Petronella, Blake Rea, Justin Summers, and Jonathan Wood, operating under Registered Provider Organization #1449 through The Cyber AB. The firm is BBB A+ accredited and has been a North Carolina cybersecurity partner since 2002.

Author of "How Hackers Can Crush Your Business," "How HIPAA Can Crush Your Medical Practice," "The Ultimate Guide to CMMC," and 11+ additional titles. Amazon author page.