“Who has access to this report?” is probably the question most often asked by Power BI administrators, and the hardest one to answer quickly. Between workspace roles, individual sharing of reports and apps, row-level security (RLS) and access inherited through Microsoft 365 or Microsoft Entra ID groups, the surface to audit is wide and fragmented.
This guide details a complete method for carrying out this audit properly.
Step 1: Identify the four access layers to audit
Workspace roles
Each Power BI workspace defines four standard roles: Admin, Member, Contributor and Viewer. The Admin can change everything, including deleting the workspace itself. An audit must systematically list who holds the Admin role on each workspace, as this is the highest level of risk.
Direct sharing
Regardless of the workspace role, a report or app can be shared individually with specific users, internal or sometimes external (B2B guests).
These ad hoc shares are the main source of “forgotten” access: granted for a temporary need, they are rarely revoked once that need has gone.
Row-level security (RLS)
Defined in the semantic model, RLS filters the data visible according to the profile of the connected user (for example, a sales rep only sees data for their region). An audit must check not only that RLS exists, but that it has been properly tested for each defined role: a misconfigured RLS can let unintended data through.
Inheritance through Microsoft 365 / Microsoft Entra ID groups
Many Power BI permissions are not granted individually but through membership of a Microsoft 365 group. This inheritance is invisible from the Power BI interface itself: you need to cross-reference the data with Microsoft Entra ID to understand a given user’s actual access.
Step 2: Use the available native tools
The Power BI administration portal (Admin Portal) lets you view workspace roles one by one, along with some tenant settings related to external sharing. The Power BI REST API, through the Admin endpoints (notably those related to workspaces, workspace users and artifacts), makes it possible to extract this information more systematically, but requires development to be usable across the whole organization, and does not provide a consolidated view combining roles, shares, RLS and group inheritance.
Step 3: Spot common blind spots
| Blind spot | Why it poses a risk | How to detect it |
|---|---|---|
| Orphaned service accounts | Retain Admin permissions after a project ends | Cross-check the list of workspace Admins against active employee accounts in HR records |
| Forgotten direct sharing permissions | Granted to an external consultant and never revoked | List all individual sharing permissions for each report across all workspaces |
| Overly broad M365 groups | Dozens of people can access a sensitive report without this being explicitly visible | Cross-check group membership against the workspaces associated with each group |
| Insufficiently tested RLS | Risk of data exposure depending on the signed-in user’s profile | Test each RLS role using the “View As Role” feature |
| Workspace roles that bypass RLS | RLS only applies to Viewers: Admins, Members and Contributors can see all data | Check that users who only need to consume sensitive data have the Viewer role only |
| Active external guests | B2B access remains active after a collaboration ends | Filter for external users in access logs |
Step 4: Document and repeat the audit
An access audit is only valuable if it is repeated regularly (ideally every quarter, or at each significant organizational change) and documented so it can be presented during a compliance review (GDPR, nFADP, ISO 27001, banking or healthcare sector standards). Doing this audit manually, workspace by workspace, quickly becomes unmanageable beyond a few dozen workspaces.
Towards a consolidated, continuous view. The ultimate goal is not just to be able to respond to an annual audit from time to time, but to have a permanent 360° view of permissions, able to immediately detect abnormal access (for example a new Admin added to a sensitive workspace) rather than discovering it six months later at the next review. This continuity fundamentally changes the security posture: you move from reactive control to proactive monitoring.
Frequently asked questions
How long does a complete manual Power BI access audit take?
For a tenant of around fifty workspaces, a rigorous manual audit covering all four access layers generally takes from several days to several
weeks, depending on team availability and the complexity of the RLS in place.
Is RLS enough to secure sensitive data?
No, RLS filters the display of data within a report, but it does not replace access control on the report itself. A user without access to the
report has no data to filter anyway; RLS and workspace roles are complementary, not interchangeable.
How should external users (guests) be handled?
Guest access should be reviewed specifically and more frequently, because it often escapes standard HR account deactivation processes. An
audit should always isolate and separately review the list of active external accounts.
This access audit is directly linked to the second signal described in “Power BI governance: 7 signs your environment is slipping out of control“. See also “Power BI inventory” for the artifact base needed for an exhaustive audit.
