How Long Does Power BI Keep Audit Logs? The Real Retention Numbers

How long does Power BI keep audit logs?

It depends which log you mean. The Power BI activity log API provides up to 28 days of history. Power BI events flowing into the Microsoft Purview audit log are generally retained for 180 days by default, with longer retention available on higher licensing tiers. Beyond those windows, the only way to hold usage and audit history for the years an auditor or regulator actually asks about is to continuously extract and store it yourself, or to run a governance tool that does it for you.

Either way, the platform’s defaults fall far short of the years an audit actually looks across, and that gap surprises more of our clients than almost anything else about the platform, and it has a way of surfacing at the worst possible moment, mid-audit, mid-investigation, or the week after a breach scare.

What is actually in the Power BI activity log?

The activity log records the events that answer the questions boards and auditors ask. Who viewed a report and when. Who exported data, and from which workspace. Who shared content, and with whom. Who changed permissions, created workspaces, deleted datasets or deployed new versions. It also records the operational signals that matter for running the estate: refreshes, gateway activity and licence usage.

In other words, the activity log is your audit trail, your usage evidence and your security record in one stream. Which is exactly why these default windows are a problem. The questions this data answers are usually asked months or years after the event.

Why are the default retention windows a problem in practice?

Because every serious use of audit data looks backwards further than a month:

• Audits and compliance reviews. Australian regulated industries typically need to evidence access and usage over one to seven years. The 28-day activity log window cannot evidence a quarter, and even the 180-day Purview default cannot evidence a full financial year.
• Breach investigations. When something goes wrong, the first questions are who had access to the data, who actually touched it, and what did they do with it, did they export it? If the event happened six weeks ago, the activity log API alone can no longer answer, and beyond six months even the Purview default has moved on.
• Usage-based decisions. Access reviews, licence right-sizing and capacity cleanup all depend on usage patterns over months. Russell gives the everyday example: you cannot review whether someone’s access level matches their actual behaviour “over the last 45 days” from the activity log alone, and you cannot review a full year on the default Purview window.
• The new-executive test. A new CDO arrives and asks how many reports exist, how often they refresh and who uses them. We have watched admin teams spend three or four days manually assembling half an answer, because the history simply is not there.

The pattern in the field is consistent: organisations assume the platform is keeping this history for them, and discover otherwise only when they need it. By definition, that discovery comes too late.

How do you extend Power BI audit log retention?

There are three approaches, and they are additive rather than competing.

1. Microsoft Purview auditing. Power BI events captured in the Purview audit log are retained for 180 days by default, with extended retention available at higher licensing tiers. If you have the licensing, make sure it is active, there is no reason not to. It buys you roughly six months of history and keeps you inside the Microsoft toolset. What it does not do is hold the multi-year history audits require, or turn raw events into anything readable.
2. Roll your own extraction. Technically capable teams sometimes script against the Power BI and Fabric APIs, pulling activity data into their own storage before the window closes. It works, until it does not. Russell has seen the lifecycle repeatedly: “Some customers write their own PowerShell scripts to extract the information, but over time those scripts break, because Microsoft changes the way things work behind the scenes.” The script’s author eventually changes roles or leaves, and the organisation discovers its audit trail quietly stopped collecting eight months ago.
3. Purpose-built governance tooling. A tool like Power BI Sentinel connects to the tenant and collects activity data continuously from day one, holding it for as long as you need, with the added difference that the data lands as an enriched, modelled dataset inside your own environment rather than a pile of raw JSON. It also keeps collecting through Microsoft’s API changes, because maintaining that plumbing is the vendor’s job rather than a side project of your best engineer. We have written a full explainer on what Sentinel is and how it works.

The honest framing our consultants give clients: Purview extends the window, Sentinel removes it. For most enterprise estates the answer is both, which is consistent with how we advise on Purview generally.

Where does the retained audit data live?

A question that matters increasingly in Australian organisations: if a third-party tool is collecting your audit history, where does that history go?

For Sentinel deployments the answer is reassuring on two fronts. The service runs an Australian instance, so the service itself operates onshore. More importantly, the architecture is metadata-driven: your report data and your audit history land in a SQL database inside your own environment. The usage model Sentinel builds belongs to you, sitting in your estate, available for your own reporting, or to feed your machine learning and AI initiatives. Data sovereignty questions from risk teams tend to end quickly once that architecture is on the table.

Who needs to own this?

Retention rarely has an owner, which is precisely how it stays broken. In most organisations the accountability splits three ways. Heads of Data Governance and compliance leads own the requirement, they are the ones who will be asked to evidence access and usage when the audit or the incident arrives, and the growth of that job title across Australian enterprises reflects how real the requirement has become. BI managers and platform owners own the mechanism, deciding how activity data gets captured, extended and stored. And the CIO or CDO owns the exposure, because a retention gap is invisible right up until it appears in an incident report with their name on the distribution list.

The practical move is to make the current retention window an explicit, written decision rather than an inherited default. “We retain the defaults because nobody chose otherwise” does not survive contact with an auditor. “We retain seven years, here is where it lives and here is who can query it” ends the conversation.

What should you do this week?

Retention is the rare governance problem where acting early costs almost nothing and acting late is impossible, an audit trail cannot be built retroactively. The practical sequence:

1. Check what you are currently keeping. Confirm whether Purview auditing is active and what your effective retention window is today. Many estates are running on the raw defaults without anyone having decided that.
2. Start collecting before you decide anything else. Whether via Purview, extraction or tooling, get history accumulating now. Every week of delay is a week of evidence you will never recover.
3. Define your required window. Match retention to your regulatory and internal audit obligations, not to a product default.
4. Make the history usable. Raw events satisfy nobody. Decide how access reviews, licence reviews and audit responses will actually consume the data, which is where modelled, enriched history earns its keep.

We covered what a complete audit capability looks like across access, usage, change and lineage in our guide to compliance monitoring for Power BI at scale.

Frequently asked questions

How long does Power BI keep audit logs by default?

The Power BI activity log API provides up to 28 days of history. Power BI events captured in the Microsoft Purview audit log are generally retained for 180 days by default. Longer retention requires higher licensing tiers, exporting the data to your own storage, or governance tooling.

Does Microsoft Purview extend Power BI audit log retention?

Yes. Power BI events in the Purview audit log are retained for 180 days by default, with longer retention available on higher licensing tiers. It extends the window significantly but, at default settings, still falls short of the multi-year history that audits and investigations commonly require.

Can I export Power BI audit logs myself?

Yes, via the Power BI and Fabric APIs, and some teams script this with PowerShell. The risk is durability: Microsoft changes APIs over time, scripts break silently, and the internal expert who built them eventually moves on. Treat self-built extraction as a stopgap rather than an audit-grade solution.

How does Power BI Sentinel handle audit data retention?

Sentinel collects activity data continuously from installation and retains it for as long as you need. The data is enriched, modelled and stored in a SQL database within your own environment, so the history belongs to you and can feed your own reporting, analytics or AI.

Does Power BI audit data leave Australia with Sentinel?

Sentinel operates an Australian instance, and its architecture is metadata-based: your audit history and report data are stored in your own SQL database inside your estate rather than in the vendor’s cloud.

Russell is Group Consulting Director at MIP, where he has spent 16 years helping Australian organisations build and govern their data platforms. If you do not know what your current retention window is, that is the first question worth answering, talk to us.