Power BI Tenant-Level Auditing - What to Capture and Why It Matters

A CFO asked me a simple question last year: "Who has seen the board pack before it went to the board?" The organisation had Power BI Premium, a few hundred users, and a governance policy document that ran to 30 pages. Nobody could answer the question. The activity data that would have answered it had been available the whole time, but it only goes back 30 days, and nobody had ever saved any of it.

That's the problem tenant-level auditing solves. It's not glamorous. It's mostly about extracting logs on a schedule and putting them somewhere you can query. But when a regulator, an auditor or your own executive team asks who did what with your data, it's the difference between an answer and a shrug.

Microsoft's Power BI implementation planning guidance has a whole article on tenant-level auditing. It's long and thorough, and I'd encourage Power BI administrators to read it. This post is my take on the parts that matter most, based on what we've seen at Australian organisations.

Tenant-level versus report-level auditing

Microsoft splits auditing and monitoring into a few layers. Report-level and data-level auditing are what individual content creators care about: is my report slow, is my model refreshing, how many people use this thing. Tenant-level auditing is the administrator's view across everything. Every workspace, every user, every activity.

At the tenant level you're trying to answer questions like:

• Who is using Power BI, and how much?
• What content exists, who owns it, and is it being used?
• Who shared what, with whom, and was it shared outside the organisation?
• Who exported data, and to where?
• What changed in tenant settings, and who changed them?
• Are we getting value from our licences and capacity?

These are governance questions, security questions and cost questions all mixed together, which is part of why they so often go unanswered. Nobody owns all three.

The data sources you actually need

There are a handful of places this data comes from, and the guidance covers each of them. Here's how I think about them.

The Power BI activity log

This is the core. Every view, export, share, refresh, edit and settings change generates an event. You get it through the Power BI REST API (the Get Activity Events admin endpoint) or the Get-PowerBIActivityEvent PowerShell cmdlet.

The important limit: it keeps 30 days of history. If you're not extracting it regularly and storing it yourself, you lose it. This is the single most common gap we find. Organisations assume the data is there, and when they go looking, it only covers the last month.

The activity log only requires the Fabric administrator role (or a service principal with the right permissions), which makes it easier to automate than the unified audit log.

The Microsoft Purview unified audit log

Power BI events also flow into the Microsoft 365 unified audit log in Purview. Retention there depends on your licensing, typically 180 days by default, longer with audit premium licences. The upside is that you can correlate Power BI activity with other Microsoft 365 activity, like a user downloading a file from SharePoint right after exporting a report. The downside is that access requires broader permissions than just being a Power BI admin, and security teams are often (rightly) reluctant to hand those out.

For most clients we recommend extracting from the Power BI activity log for your analytics, and letting your security team use Purview for investigations. They're complementary, not either-or.

Tenant inventory via the scanner API

Activity tells you what people did. Inventory tells you what exists. The metadata scanning APIs (GetModifiedWorkspaces, PostWorkspaceInfo, GetScanStatus, GetScanResult) give you a full picture of workspaces, reports, semantic models, dataflows, data sources, endorsement status, sensitivity labels and more.

Joining inventory to activity is where the real value shows up. "These 400 reports haven't been viewed in 90 days" is an inventory-plus-activity question. So is "these semantic models are certified but nobody uses them".

Users, groups and licences

Microsoft Graph gives you user details, group memberships and licence assignments. Without it, your activity log is a list of email addresses. With it, you can report by department, location and licence type, and you can spot people holding Pro licences who haven't opened Power BI since 2024.

Tenant settings and capacity metrics

Tenant settings changes are captured in the activity log, but it's worth keeping a periodic snapshot of the full settings too. Capacity metrics come from the Fabric Capacity Metrics app, which is fine for spot checks but painful for long-term trend analysis.

Building the pipeline

The architecture we typically build is fairly simple:

1. A scheduled job (Azure Function, Fabric notebook or Data Factory pipeline) runs daily with a service principal.
2. It pulls the previous day's activity events, a scan of modified workspaces, and user and licence data from Graph.
3. Raw JSON lands in a data lake (OneLake if you're on Fabric, otherwise ADLS Gen2).
4. A second step flattens it into tables you can query.
5. A semantic model and a set of admin reports sit on top.

A few lessons from doing this more than once:

Keep the raw data. Store the raw JSON exactly as returned before you reshape it. The activity schema changes as Microsoft adds new activity types and properties. If you only keep your flattened version, you'll lose fields you didn't know you needed until an auditor asks for them.

Extract by UTC day, and handle continuation tokens properly. The activity events API requires start and end times within the same UTC day and pages results with continuation tokens. Get this wrong and you'll silently drop events. Remember that a UTC day in Sydney starts at 10 or 11am local time depending on daylight saving, which matters when someone asks about "yesterday".

Use a service principal, not a person. Same advice I give about everything else in Power BI. A pipeline tied to an individual's credentials breaks when they change roles.

Secure the audit data itself. This dataset contains who looked at what, including sensitive HR and financial reports. It should have tighter access than most of the content it describes. We've seen audit reports published to a workspace half the BI team could access, which rather defeats the purpose.

What to do with the data

Collecting logs doesn't help if nobody looks at them. The reports we find most useful:

• Adoption trends. Active users by week, by department. Helps you see whether training worked and where to focus next.
• Stale content. Reports and models with no views in 90 days. Candidates for archiving, which cuts clutter and makes search usable.
• External sharing and publish-to-web. Anything shared outside the tenant, and any publish-to-web embed codes. The publish-to-web one in particular should be near zero, and every instance should have a known owner and a reason.
• Export activity. Exports to Excel, CSV and PowerPoint, especially from content labelled as confidential. This is where data actually leaves the platform.
• Tenant settings changes. Who changed what. This should be a short list and every entry should be expected.
• Licence optimisation. Pro and PPU licences with no activity. This one pays for the whole project at many organisations.

The honest bit

A few things are still rough.

The activity log is detailed but not always consistent. Some activity types have fields that others don't, property names drift, and new Fabric item types keep showing up with their own events. Expect to maintain your flattening logic, not write it once.

The 30-day retention is too short and I don't see Microsoft changing it soon. Treat extraction as mandatory from day one.

And the tooling is still largely do-it-yourself. There are community solutions and Microsoft samples, and they're a decent starting point, but most organisations end up customising heavily. Fabric has made this easier, since notebooks and lakehouses are a natural fit, but you're still building a small data product.

For Australian organisations with regulatory obligations, and I'm thinking of anyone under APRA's CPS 234, healthcare providers, and government agencies working to the Protective Security Policy Framework, this isn't optional. Being able to show who accessed sensitive information is part of the job. For everyone else, it's still one of the better investments in a Power BI program, because it turns governance from a policy document into something you can measure.

If you're setting this up, our Power BI consultants have built these pipelines for organisations of various sizes, and our Microsoft Fabric consultants can help if you want the audit data landing in OneLake alongside your other analytics. For regulated sectors, we've also covered some of the specific considerations in our work on AI for financial services.

Start with the activity log extraction. Everything else can come later, but the logs you don't capture today are gone in 30 days.

Reference: Power BI implementation planning - Tenant-level auditing - Microsoft Learn