An access audit for an automated report should answer four questions: who can change it, who can run it, who can see its data, and where its outputs can travel. Inventory every user, group, service account, role, subscription, export destination, and public or guest link; compare each grant with a documented need; remove or reduce unjustified access; then verify the report still works for the intended audience.
Map the complete access path
Start at the source systems. Record which account reads each database, file store, application, or API and what scope it has. Continue through the report workspace, semantic model, report definition, scheduler, email subscription, shared folder, embedded view, and export location. Include inherited group access, guest accounts, application identities, API keys, and backup administrators. Do not copy secrets into the audit; record the credential owner, storage location, rotation status, and granted scope instead.
Use least privilege as the test. NIST defines least privilege as restricting users or processes to the minimum authorizations and resources needed to perform their assigned function (NIST least-privilege glossary). For each grant, record the business purpose, owner, approval, start date, last use if available, and review date. An unexplained permission is a finding even if it has never caused a known incident.
Distinguish viewing from editing
Separate people who only need to consume the report from those who need to edit the model, alter refresh settings, share content, or administer the workspace. Product labels differ, so read the platform's role matrix rather than relying on names. In Power BI, for example, workspace roles include Admin, Member, Contributor, and Viewer; group membership can also affect effective access, and the highest assigned workspace role can prevail when a person belongs to several groups (Microsoft's workspace-role documentation).
Check data-level restrictions independently from workspace access. Microsoft documents that Power BI row-level security applies to users with the Viewer role, while Admin, Member, and Contributor roles have edit permission and are not restricted by RLS in the same way (Microsoft RLS documentation). This is a useful example of why an apparently convenient elevated role can bypass the data view intended for a consumer.
Review delivery and secondary copies
List subscriptions, distribution lists, external guests, scheduled exports, shared drives, chat integrations, and downloaded files. Confirm that recipients still need the report and that the delivery channel matches the data sensitivity. Check whether forwarded attachments or broadly shared folders create access outside the reporting platform. Verify expiration and ownership for temporary shares, and identify orphaned outputs whose original owner has left or changed roles.
Remediate carefully and verify
Prioritize public links, unknown owners, inactive accounts, unnecessary administrator rights, and service accounts with broad source access. Make one controlled change at a time, keep an approval and rollback record, and avoid disabling the only working owner before a replacement is confirmed. After each change, test as an administrator, ordinary viewer, restricted viewer, and unauthorized user. Confirm both the report page and exported or emailed output behave correctly.
Finish with an evidence table showing identity, access path, effective role, data scope, purpose, owner, decision, and verification. Schedule the next review based on sensitivity and staff turnover, and repeat it after major changes to the source, workspace, scheduler, or recipient list.
Sources
- Least Privilege - CSRC Glossary — National Institute of Standards and Technology
- Roles in workspaces in Power BI — Microsoft
- Row-level security with Power BI — Microsoft