Sensitive reports rarely leak because of one bad setting. They usually leak through a stack of small permissions that no one checked closely enough.

If you need to audit Power BI access for sensitive reports, start with the workspace role, then review report sharing, app access, dataset permissions, row-level security, and audit logs. That gives you a clear view of who can reach the report, how they got there, and whether they used that access.

The process changes a little based on your role and tenant settings. A Power BI admin, a workspace admin, and a compliance reviewer won’t all use the same screens, but they should all end up with the same evidence.

Table of contents

• What to review first
• Audit the workspace roles and owners
• Check report sharing, app access, and dataset permissions
• Use audit logs to confirm who actually did what
• A simple workflow you can repeat every month
• Conclusion
• FAQs

What to review first

Start with the access chain, not the report itself. In Power BI, a user might reach a sensitive report through a workspace role, a share link, an app audience, a semantic model permission, or row-level security. Microsoft’s overview of Power BI workspaces in Microsoft Learn is a good reference for how those pieces fit together.

A quick review works best when you separate access into layers. That keeps you from missing the one setting that matters.

Access layer	What to check	Evidence to keep
Workspace roles	Admins, members, contributors, viewers, and group-based access	Role export, owner list
Report sharing	Direct shares, share links, external recipients	Share settings, link list
App access	App audiences and who can view the published app	App audience list
Dataset permissions	Build access and semantic model permissions	Dataset permission list
Row-level security	Role mapping and test-user results	RLS mapping, test notes
Audit logs	Views, shares, exports, downloads, and link creation	Saved search or export

That table is the core of the review. If any row is missing, the report is not fully audited.

Audit the workspace roles and owners

Workspace roles are the first place to check because they often explain everything else. If someone is a workspace admin or member, they may have far more reach than a report owner expects.

Open the workspace and review every person and security group. Pay close attention to broad groups, old project teams, and accounts that should have been removed after a role change. Also check whether the workspace has more than one owner. Multiple owners are fine when they are current and documented. They are a problem when nobody can explain why they still have access.

If your tenant uses stricter controls, some changes may sit in the admin portal instead of the workspace screen. In that case, the audit should include tenant settings as well as workspace membership. If you are the Fabric or Power BI admin, you can look at the broader controls. If you are a workspace admin, you may need to document what you can see and ask the tenant admin for the rest.

Use this short checklist when you review roles:

• Confirm who owns the workspace today.
• Check whether access comes from a group or a direct assignment.
• Remove former employees and stale contractors.
• Flag anyone with admin rights who does not need them.
• Save the before-and-after role list.

A clean role list does not mean the report is safe, but it does tell you where to look next.

Check report sharing, app access, and dataset permissions

A sensitive report can look locked down in the workspace and still be reachable somewhere else. That is why you need to check report sharing, app access, and dataset permissions as separate items.

First, look at the report’s sharing page. Review both the direct access list and any share links. Those are not the same thing. A user may not appear in the main list and still get in through a shared link. Also check whether external sharing is allowed for that workspace.

Next, review the app audience if the report is published through an app. A user can have no workspace role at all and still see the report through the app. That is common in business-facing dashboards, so it needs to be part of the audit every time.

Then move to the dataset or semantic model. Build permission is easy to miss, but it matters. A user with build access may create content on top of the sensitive data, even if they cannot edit the report itself. If row-level security is in place, check the role membership and test the report as a user in each key role.

Keep evidence for all of it:

• The report share list and link settings.
• The app audience and distribution list.
• The dataset or semantic model permission list.
• The row-level security role mapping.
• Test results for at least the highest-risk roles.

Use audit logs to confirm who actually did what

Configuration tells you who could access a report. Audit logs tell you who tried, viewed, shared, or exported it.

If your organization uses Microsoft Purview auditing, make sure Power BI activity is turned on and searchable. Microsoft’s Power BI activity log guide in Microsoft Learn is the right starting point for admins who need to analyze log data. Search by user, workspace, report name, and date range. Focus on actions like viewed report, shared dashboard, created share link, exported data, and downloaded data.

A clean permission list does not prove low exposure. Audit logs show use, not just entitlement.

That matters when the access review and the log do not match. Maybe a user no longer appears in the workspace, but they opened the report last week through a link. Maybe a report is supposed to stay internal, yet the log shows external sharing. The log gives you the proof.

If the audit trail is new, remember that logs can take time to appear after auditing is enabled. Plan the review with that delay in mind.

A simple workflow you can repeat every month

A repeatable workflow keeps the review from turning into a one-time scramble. Use the same steps for each sensitive workspace.

1. List the sensitive workspaces and the reports inside them.
2. Export the workspace role list and confirm the owners.
3. Review report shares, app audiences, dataset permissions, and RLS roles.
4. Search the audit log for recent views, shares, exports, and link creation.
5. Remove excess access and record the reason for each change.
6. Save the evidence package with the date, reviewer, and workspace name.

For high-risk reports, run this monthly. For stable internal reports, quarterly may be enough, as long as nothing changed in the tenant or workspace.

Keep a small evidence set every time:

• Workspace role export.
• Report sharing and link details.
• App audience list.
• Dataset permission list.
• RLS role mapping and test results.
• Audit log search results.
• Remediation notes.

If your team still handles this review by hand, Book a Discovery Call with Bud Consulting and compare notes on a cleaner process.

Conclusion

The safest way to audit Power BI workspace access is to treat it like a chain, not a single setting. Workspace roles, report shares, app access, dataset permissions, row-level security, and audit logs all tell part of the story.

When those pieces line up, you can explain who had access, how they got it, and whether they used it. That is the difference between a quick check and a review you can defend.

FAQs

Who should audit Power BI workspace access?

A Power BI admin, Fabric admin, governance lead, or workspace owner can do the review. For sensitive reports, the best result usually comes from a joint review between the report owner and the security or compliance team.

What evidence should I save during an access review?

Save the workspace role list, app audience list, report sharing details, dataset permissions, row-level security mapping, and the audit log results. Keep a short note for every change you make.

How does row-level security fit into the audit?

Row-level security limits what data a user sees after access is granted. It does not replace workspace access, app access, or dataset permissions, so you still need to review all of them.

How often should I review sensitive Power BI reports?

Monthly is a good target for high-risk reports. Quarterly is usually fine for lower-risk internal reports, but you should review again after role changes, reorganizations, or tenant setting updates.

Can I audit access without admin rights?

Yes, to a point. A workspace admin can review workspace roles and sharing, but tenant-wide logs and some settings may require Power BI or Microsoft 365 admin rights.