Your Jira audit log is quietly deleting your compliance evidence

Here is a fun conversation to have mid-audit: the auditor asks for twelve months of Jira audit history, and you discover the platform only kept about six.

Jira Cloud's audit log is capped. Older records age out after roughly 180 days, and once they are gone, they are gone. No export, no admin setting, no support ticket brings them back. SOC 2 and ISO auditors routinely ask for a year or more of history, and incident reviews have a habit of starting well after the records that matter have already rolled off. This is not an obscure complaint either: longer audit-log retention is a recurring, long-open request on the Jira issue tracker, with roughly 350 combined votes across related asks.

The problem in one sentence

The audit log is a rolling window, and your compliance obligations are longer than the window.

Day to day you never notice, because the recent records are all there. The gap only shows up at the worst possible moment: an access review, a security incident, or an auditor with a checklist.

The DIY fix: get the records out before they age out

The durable pattern is to copy audit records into storage you control while they still exist:

1. Run a scheduled job that reads the Jira auditing REST API (GET /rest/api/3/auditing/record, paginated).
2. Keep a cursor (timestamp or id of the last stored record) so each run only pulls what is new.
3. Dedupe by record id when appending, so overlapping runs never double-store an event.
4. When compliance asks, flatten everything to CSV: one row per record with the id, timestamp, author, summary, category, object item, and changed values.

This works. The catch is that it has to run reliably every single day, forever. Miss a stretch longer than the retention window and that slice of your evidence trail is unrecoverable. You also have to host the store and the scheduler somewhere, which means new infrastructure outside Jira, and now that infrastructure has to pass your own security review too.

The packaged version

I built Compliance Log Vault to be exactly that pattern, minus the infrastructure. It is an Atlassian Forge app, so everything (the daily scheduled sync, the storage, the export) runs on Atlassian's own serverless platform inside your Jira Cloud tenant. No external servers, no data egress, eligible for the Runs on Atlassian trust badge.

What it does:

• Daily incremental sync of new audit records into an in-tenant vault, deduped by id so nothing is ever stored twice.
• Long-term retention past the ~180-day cap; the vault only grows.
• An admin page to browse retained records newest-first, plus retention stats: counts by day, counts by category, and the full retained span.
• One-click, audit-ready CSV export of the whole vault.

It is read-only and least-privilege by design: just audit-log read and user read scopes. It appends records into its own Forge storage and changes nothing in Jira.

If you want the longer written-up version of the DIY approach, I go into more detail in the full article on our site.

Either way, the takeaway is the same: if your compliance horizon is longer than 180 days, start syncing your Jira audit log out of the rolling window now, because you cannot backfill later.