Your Jira Remembers 180 Days. Your Auditor Asks About Two Years.

When I asked Martin Runge how well a typical Jira instance can answer "who changed this, when, and why", his answer started somewhere I did not expect. Not with permissions, not with logging coverage, but with a clock.

"Who and when are logged well, and higher Jira plans together with Atlassian Guard widen the coverage considerably. The catch is retention."

— Martin Runge, Head of Atlassian Practice at XALT

Three numbers follow from that, and between them they decide what your organization is able to prove.

The organization audit log keeps events for 180 days, and that limit cannot be changed. Automation logs stop at 90 days. The site audit log is configurable, and in Martin's experience customers land on one, three or six months.

None of that is hidden. All of it is documented. Almost nobody reads it until the week they need it.

Everyone assumes it is in the log

Ask a Jira admin how far back their audit trail goes and the answer is usually some version of "it is all in the audit log". That is true. For a while.

Nothing here is a failure. Nobody deleted anything, nobody misconfigured anything, no policy was ignored. The retention period simply ran out, on schedule, exactly as designed. The platform did its job.

The evidence is gone anyway.

The two clocks do not run together

Audits do not ask about moments. They ask about periods.

A reviewer running an ISO 27001 surveillance audit typically asks about the stretch since the last one. Teams preparing for a DORA or NIS2 review are usually asked how a control behaved across a whole reporting period, not on the day someone happened to look. And an internal investigation begins with an incident somebody noticed long after the change that caused it, which is what makes it an investigation rather than a ticket.

Every one of those questions arrives after the fact. That is not a flaw in how audits work, it is the definition of an audit. And it means the question reliably arrives later than the retention window reaches back.

So the uncomfortable version of the rule looks like this:

"Anything an auditor asks about beyond roughly six months has to have been exported before they asked."

— Martin Runge

That sentence reverses the usual order of operations. You cannot decide to produce evidence at the moment you need it. The decision has to have been made much earlier, by someone who was not under audit pressure and had no visible reason to act that day.

And then the "who" starts to fade

There is a second loss underneath the first one, and it is easier to miss.

"Changes made by automation rules or connected apps show up as the rule or the app, not the person behind it, so who quietly degrades in exactly the automated environments regulated customers are building."

— Martin Runge

Put both effects together and a mature Jira estate looks like this. The oldest evidence expires on a fixed schedule. A growing share of the newest evidence points at a rule instead of a person.

Neither is a defect. As Martin puts it, "Jira is built for speed and flexibility, which is close to the opposite of what an auditor wants." Jira records every one of these events; what it does not do natively is retain them past the window or aggregate them across projects and years. The gap is not between Jira and good engineering. It is between what the platform does out of the box and what a regulated organization has to be able to show.

And there is a third layer that no retention setting touches at all. Martin's sharpest sentence in the whole interview:

"Without mandatory comments and approval gates, a log proves that a change happened, not that it was authorized."

— Martin Runge

Even inside the window, a complete log answers who and when. It does not answer why.

"We export regularly"

This is the standard answer, and it is not wrong. It is just fragile in three specific ways.

It depends on someone remembering. A quarterly export is a recurring task competing with incidents, migrations and everything else on an admin's plate. Miss two quarters and you have a hole that cannot be backfilled, because the source is already gone.

A file is not an answer. Raw events become evidence only when someone can reconstruct a specific change, its actor and its timing under time pressure, possibly years later, possibly after the admin who set up the export has left.

The export becomes its own governance problem. That second copy now needs a retention policy, an access model and a storage location that satisfy the same rules you were trying to satisfy in the first place.

That third point deserves an honest note, because it applies to us too.

What changes when the history is continuous

MetaFrazo's Atlassian connector receives configuration and workflow events from Jira as they happen and writes them into MetaFrazo's own data plane, hosted in the European Union, where each organization's data is isolated from every other. The hosting region, the subprocessor list and the data-processing terms are published in full on our terms and policies pages.

So yes, that is a second copy of the record, and it should be called one rather than dressed up as something else. The difference is not that the copy disappears. The difference is that it is continuous rather than scheduled, that nobody has to remember to run it, that it is governed as a product rather than as a folder someone owns, and that the event history is append-only: it does not age out on a 180-day clock.

And it arrives in a shape built for the question an auditor actually asks (what changed, in which project, by which actor, and when) instead of arriving as a CSV somebody still has to turn into an answer.

Three reports on every Pro edition carry most of that work. They answer three different questions, and it is worth asking them in that order.

Which configuration events happened, and who triggered them? The Configuration Change Event Audit Log is the literal answer to "who changed this, and when": every configuration event in time order, with date, event type, project, issue key and the actor behind it, filterable by any of them.

Configuration Change Event Audit Log. Every configuration event in time order, with the actor who triggered it.

Which fields on the work itself keep moving? This one sits at a different grain. Instead of admin-level configuration, the Issue-Level Field Change Heatmap tracks daily change counts on the fields that decide accountability: who the work is assigned to, how urgent it was called, who reported it, what type it was filed as. Each cell is one field on one day, and the darker it is the more that field moved. Assignee churn is the one people recognize immediately; a reporter or project field that shifts after creation is the one worth a second look.

Issue-Level Field Change Heatmap. Which fields are being changed most frequently, and does the churn pattern point to planning instability?

Which part of the configuration is absorbing the change? Configuration Event Type Distribution groups the admin-level events by domain, so it is obvious whether a busy month was fields, field contexts, issue types, users or projects.

Configuration Event Type Distribution. Which part of the configuration is absorbing the change.

None of those three is an answer on its own. Together they are the difference between knowing that your estate changed and being able to say what changed, where, and at whose hand, on a date that fell outside the window the audit log still covers.

The two gaps Martin points at specifically have their own reports on the MetaFrazo Enterprise editions: Audit Trail Coverage by Event Type, which shows the proportion of events carrying a full changelog entry against those that do not, and Single-Actor Resolution Rate, which compares closures where the creator also closed the item against closures involving at least one other person. The second is not proof of authorization, but it is the closest thing the event stream holds to Martin's point about approval gates.

What this does not solve

MetaFrazo records from the day it is installed. It does not reconstruct history that Jira has already discarded.

That limitation is the entire argument of this article rather than a footnote to it. Whatever your organization cannot prove about the last two years, no product will recover. What is still open is where the record begins.

That boundary moves forward every single day. In six months, so will everything you did not capture today.

One thing you can do without any product

Open your site audit log settings and check what the retention period is actually set to. Then look up the reporting period of your next audit.

If the second number is larger than the first, you already know the size of the gap.

---

This article follows the interview with Martin Runge, Head of Atlassian Practice at XALT, in our series "5 Questions in the Atlassian Universe". Retention figures cited are Atlassian's published Cloud behavior as of September 2026. Worth re-checking against Atlassian's documentation before you quote them in a control description.

MetaFrazo is available on the Atlassian Marketplace, with a 30-day free trial on every edition.