Power BI Security Review
Row-level security in Power BI does not apply to workspace Admins, Members or Contributors, so they see every row. We test your workspace roles, RLS, embedded reports and sharing links. CREST-certified testers, fixed price from £3,280 for a 2-day single-tenant scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Power BI workspaces have four roles, Admin, Member, Contributor and Viewer, and Microsoft’s documentation confirms row-level security does not apply to Admins, Members or Contributors.
In Power BI, row-level security only protects one workspace role
Power BI applies row-level security through DAX filters defined on a semantic model, a static rule such as [Region] = “West” or a dynamic one built on USERPRINCIPALNAME(), USERNAME() or CUSTOMDATA() to filter data per person. Once that model sits in a workspace, the filter only reaches people holding the Viewer role: Microsoft’s documentation confirms that workspace members assigned Admin, Member or Contributor have edit permission on the semantic model and RLS doesn’t apply to them at all. We map every person’s actual workspace role against what an RLS rule was written to restrict, because the role, not the rule, decides whether it ever runs.
Hiding a table or column from a report isn’t a security boundary; object-level security is the setting on the semantic model that actually removes a table, column or its metadata from what a role can query, separately from any row-level filter. Where a report is embedded for your own customers under app-owns-data, the embedding application authenticates as a service principal, and Microsoft’s documentation states that USERPRINCIPALNAME() and USERNAME() then return the service principal’s application ID, or an empty string, rather than an end user’s identity, so per-user RLS has to be carried instead through the effective identity passed when the embed token is generated. We test whether that identity is actually set for every embedded viewer, and whether Microsoft’s own note that the Test as role feature doesn’t simulate embedded authentication has left a gap nobody checked before launch.
Beyond the semantic model, a handful of tenant-wide settings decide how far a report can travel: Publish to web can turn any report into a public embed code accessible with no authentication at all, a “people in your organisation” sharing link reaches everyone in the tenant by default, and Analyze in Excel or a raw data export can hand over rows a report’s visuals never showed. Gateway connections carry data source credentials across Power BI and the rest of the Power Platform, including Power Apps, and are managed independently of workspace roles, while sensitivity labels only enforce access within the same tenant and a narrow set of export formats. We review these settings alongside the workspace and semantic model layer, the same tenant-level review we run for Microsoft 365.
SCOPE
What we review in a Power BI tenant
Workspace roles: Admin, Member, Contributor and Viewer
Access to a Power BI workspace runs through one of four roles, Admin, Member, Contributor or Viewer, assigned to an individual or to a security group, Microsoft 365 group or distribution list, and someone in several groups gets the highest permission any of them grants. We test who actually holds each role against who the business meant to have edit or admin rights over the workspace.
Row-level security: DAX filter roles and who they restrict
RLS roles are DAX filters on a semantic model, from a static rule such as [Region] = “West” to a dynamic one built on USERPRINCIPALNAME(), USERNAME() or CUSTOMDATA(), but Microsoft’s documentation confirms the filter only reaches workspace members holding the Viewer role, since Admin, Member and Contributor all carry edit permission and RLS doesn’t apply to them. We test the actual workspace role behind every login RLS is meant to restrict, not the role the access request assumed.
Object-level security: what RLS never protects
Hiding a table, column or measure from a report view isn’t a security boundary, since Microsoft’s own guidance is clear that a hidden object can still be reached by anyone who queries the model directly; object-level security is the setting in the semantic model’s roles that actually removes a table or column, including its name, from what a role can see. We test whether anything marked “hidden” for a tidy report is actually protected by OLS, or just out of view.
Embedded reports: effective identity and the service principal
When a report is embedded for your own customers under app-owns-data, the embedding application authenticates as a service principal, and Microsoft’s documentation states that USERPRINCIPALNAME() and USERNAME() then return the service principal’s application ID, or an empty string, rather than an end user’s identity, so a dynamic RLS rule built on either function stops filtering per person. The fix is the effective identity object passed when the embed token is generated, and we test whether every embedded viewer actually gets a correctly scoped one rather than a shared or missing identity.
Publish to web: reports with no authentication at all
Publish to web turns a report into a public embed code that Microsoft’s own documentation says is accessible to anyone on the internet without authentication, and a tenant administrator has to explicitly enable the setting and choose whether the entire organisation or specific security groups can create one. We check whether the setting is restricted the way admins intended, and whether a public embed code is already live carrying more than the intended data.
Sharing links and “people in your organisation” access
The Send link dialog offers People in your organisation, where anyone in the tenant with the link can view but external or guest users cannot, alongside Specific people and People with existing access, each with its own Reshare and Build toggles, and Build extends to the underlying semantic model, not just the report. We test what a “people in your organisation” link actually grants once it leaves the person who created it, and whether Reshare or Build has quietly widened that further.
Export and download: Analyze in Excel and export data
Analyze in Excel and exporting a report’s underlying data both need Build permission on the semantic model for a Viewer, or at least a Contributor role in the workspace, and Microsoft’s documentation confirms a Viewer with Build permission is still restricted by any RLS rule on the model. We test what a Build grant or an export setting actually hands over once it’s live, including whether the tenant-level export controls match what a workspace is allowing.
Gateways and data source credentials
An on-premises data gateway carries the credentials Power BI, and the wider Power Platform including Power Apps, use to reach on-premises sources, and gateway permissions are managed separately from workspace roles entirely, so someone can lose their workspace access and keep a working gateway connection. We test who actually holds gateway admin rights and whose credentials a data source is really running on.
Tenant admin settings governing Power BI
Export and sharing, information protection and dozens of other settings sit in the admin portal’s tenant settings, each one able to apply to the whole organisation or be scoped to specific security groups, and the same admin portal governs Power Automate and the rest of the Power Platform alongside Power BI. We test what each relevant tenant setting currently allows against what your organisation intended, not just what a single workspace is configured to do.
Sensitivity labels: classification versus real enforcement
A sensitivity label needs its tenant setting turned on before users can apply Microsoft Purview Information Protection labels, and Microsoft’s own documentation is explicit that label-based access control is only enforced inside the tenant where it was applied, in Power BI Desktop files and in Excel, PowerPoint or PDF exports, not in cross-tenant sharing or any other export format such as CSV. We test whether a label on a report is actually restricting access the way its name implies, or only classifying it.
OUR PROCESS
Power BI Security Review: From Scope to Attestation
Workspace, Role and Tenant Mapping
We list every workspace in scope, the roles and RLS rules behind each semantic model, current tenant settings, and any gateway or embedding configuration.
Role, RLS and Sharing Testing
Each workspace is tested under every relevant role, RLS filters are tested against real logins, and we test every sharing link, Publish to web code and Analyze in Excel or export path we find.
Embedding, Gateway and Tenant Setting Testing
We test effective identity and service principal behaviour for any embedded report, review gateway credential ownership, and check tenant admin settings and sensitivity labels against what your organisation intended.
Reporting and Retest
Executive summary, technical report with CVSS scores and reproduction steps, a walkthrough call, free retest after remediation and an attestation letter.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Power BI pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Power BI Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Power BI For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Power BI Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need?
Admin access to the Power BI tenant settings, or at least workspace Admin access to every workspace in scope, plus a login for each workspace role you want RLS or OLS tested against. Read access to the tenant settings and gateway configuration isn’t required to start, but it speeds up confirming what we find.
Will you touch our live data?
We test read-only against production by default. Where proving an export, a sharing link or an embedded effective identity needs real records, we agree a specific dataset or test tenant with you first, and anything we create during testing is documented and removed afterwards.
Is this hosted on our infrastructure or Microsoft’s?
Power BI runs entirely on Microsoft’s infrastructure, so there’s nothing for you to host. The test is scoped to your workspaces, roles, semantic models, sharing settings and tenant configuration, not to Microsoft’s platform itself.
Does this cover the wider Microsoft Fabric platform?
No. This page is scoped to Power BI workspaces, semantic models, reports, RLS, OLS, sharing and embedding. The wider Fabric platform, including OneLake, data pipelines and notebooks, is covered on our Microsoft Fabric security review page.
What is out of scope?
Other tenants’ workspaces and data, Microsoft’s own infrastructure, denial-of-service testing, and the wider Fabric items outside Power BI are all out of scope here.
Is penetration testing our own Power BI tenant allowed under Microsoft’s rules?
Yes. Microsoft’s penetration testing rules of engagement for its cloud services permit testing your own tenant and the assets you’re authorised for, provided you don’t access data or systems you don’t own, don’t use credentials that aren’t yours, and don’t disrupt the service for other tenants, and we test inside those rules.
How long does a Power BI test take?
A single-tenant engagement covering a handful of workspaces and RLS roles typically runs to a 2-day scope. More workspaces, embedded scenarios or custom connectors extend it, and we confirm the exact day count once we’ve seen the tenant.
Do you need the source of any embedded application?
No, though if reports are embedded for your customers under app-owns-data, having the code that generates the embed token and effective identity available speeds up root-causing anything we find. A source code review is a separate service that pairs well with this one.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Power BI tenant
Row-level security in Power BI does not apply to workspace Admins, Members or Contributors, so they see every row. We test your workspace roles, RLS, embedded reports and sharing links. CREST-certified testers, fixed price from £3,280 for a 2-day single-tenant scope, quoted within 24 hours.
