A SOC 2 or ISO audit lands, or an incident review kicks off, and the first request is always the same: show us the audit trail. Auditors routinely ask for a year or more of history. Jira Cloud's audit log, though, is capped: older records age out after roughly 180 days, and once they are gone they are gone. By the time an incident review starts, the records that matter have often already aged out. Longer audit-log retention is a recurring, long-open request on the Jira issue tracker, with roughly 350 combined votes across related asks.
Why Jira Cloud cannot do this out of the box
- The audit log is capped. Jira surfaces recent audit records, but older records age out (around 180 days) and are permanently gone. There is no built-in long-term archive.
- The gap only shows up when it hurts. Everything looks fine day to day, then an access review or a SOC 2 / ISO audit asks for twelve months of evidence the platform no longer has.
- You cannot backfill. The records live only in the audit log. Once the retention window rolls past an event, no export, admin setting, or support ticket brings it back.
The DIY approach: sync the audit log into your own store before it ages out
The durable fix is to copy audit records out of the rolling window and into storage you control, while they are still available:
- Run a scheduled job that reads the Jira auditing REST API
(
GET /rest/api/3/auditing/record, paginated) on a regular cadence. - Keep a cursor (the timestamp or id of the last record you stored) so each run only pulls new records since the previous one.
- Dedupe by record id when appending, so overlapping runs never double-store an event.
- When compliance asks, flatten the store to CSV: one row per record with the id, timestamp, author, summary, category, object item, and changed values.
- In Jira, find the native log under Settings → System → Audit log to spot-check that your sync is keeping up.
The catch is discipline: the job has to run reliably every 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 usually means standing up infrastructure outside Jira and getting that past your own security review.
A ready-made option: Compliance Log Vault
Compliance Log Vault is that pattern packaged. A daily scheduled sync pulls new audit records and appends them incrementally into an in-tenant vault, deduping by id so nothing is ever stored twice. The vault only grows, so your evidence trail keeps building safely past the platform cap. An admin page lets you browse retained records newest-first, see retention stats (counts by day and by category, plus the full retained span), and export the entire vault as audit-ready CSV in one click. It is read-only and least-privilege: just audit-log read and user read scopes, and it changes nothing in Jira.
Key facts
- Native retention: Jira Cloud audit records age out after about 180 days, with no built-in archive.
- What auditors ask for: typically a year or more of history for SOC 2 / ISO evidence and incident reviews.
- Durable fix: a scheduled incremental sync into your own store, deduped by record id, exported as CSV on demand.
- Least privilege: the whole pattern needs only read access to the audit log and user directory; nothing in Jira is modified.
Related reading: Azure has the same problem with its Activity Log: how to capture who created a resource before the log ages out.
Written by the team at Katabarwa Labs. We build small, single-purpose Azure tools that run entirely inside your own tenant. Questions: abaho@llmgraph.ai.