How are you handling Jira audit log retention beyond 180 days?

Question

The audit log retention cap is 180 days and as far as I can tell there's no way to extend it. For anyone who needs to answer questions further back than that (compliance evidence, "who had access to this project last quarter", proving a permission change happened), what are you actually doing?

A few approaches I'm aware of, none of them great:

* Polling `/rest/api/3/auditing/record` on a schedule and dumping it somewhere yourself
* Exporting to a SIEM, though the export is capped at 10,000 activities
* A backup app, which covers restore but not really "who did what when"
* Accepting the 180 days and telling auditors that's the limit

Curious which of these people have landed on, and whether anyone has found something that handles permission and group membership changes specifically. Those only seem to exist in the audit log, so once the 180 days rolls off there's nothing left.

Also interested in whether this comes up for people in practice, or whether 180 days is fine for most teams.

SPHIOR · Answer

The first thing worth untangling here is that "180 days" belongs to only one of two different audit logs, and mixing them up is what makes this question hard to answer.

The organization-level log (admin.atlassian.com > Insights > Audit log) is the one fixed at 180 days. It needs Atlassian Guard or an Enterprise plan, its API is /v1/orgs/{orgId}/events, and its export is capped at 10,000 activities — emailed to you, with a download link that expires after one day.

The product-level Jira log (Jira > Settings > System > Audit log) is a different thing. Retention there is configurable, it only needs one Jira product on a paid plan, its API is GET /rest/api/3/auditing/record, and CSV export goes up to 100,000 events. So if 180 days is your constraint, check whether the data you actually need is in the product log, where the window is yours to set.

Two traps worth knowing before you rely on either:

The CSV export keeps the NEWEST events when you exceed the cap. On a busy instance that means the oldest events silently fall off the end while you wait to run it. Export early in an audit, not late.

If you script this, the only OAuth scope in Current state is manage:jira-configuration. The read-only read:audit-log:jira is still Beta — so today, read-only access to an audit log means granting admin-grade configuration rights.

And the uncomfortable part: none of this is retroactive. Whatever approach you land on, it only starts covering you from the day you turn it on, which is usually months before anyone asks. That is the actual argument for doing something now rather than when the request arrives.

Disclosure: I build a Jira app in this space, so I've read these docs more than is healthy. Nothing to pitch here — the two logs being conflated is just the single most common thing I see go wrong with this question.

Benyamin_ggasgl · Answer

Hi @Ari

Same situation here, talked to a few admins doing basically what Evgenii/Germán/Tomislav described. REST polling into their own store, dedup on event ID, rebuilding group history from periodic snapshots. Works, but it's a real chunk of infra to build and maintain for something that's really just "don't let Atlassian delete this."

On your question: I checked the two marketplace apps that mention audit logs. Witness only covers configuration changes (workflows, schemes, fields), not user or access stuff. Event Journal anonymizes the user field, which makes it pretty useless for an auditor who needs to know who did what. Neither one answers "who had access to what, and when did that change" past 180 days, which is exactly what a SOC2 or ISO27001 reviewer asks for.

I'm actually looking at building something for this. Just a narrow tool that keeps the user/group/access history past the 180 day cap, tied to real identities, exportable for an audit. Curious what would actually make something like that worth paying for vs just running your own poll and store pipeline yourself. Happy to DM if that's easier.

Kind regards
Benyamin

Ari_tf58x4 · Answer

For those regulated clients, what would have to be true for them to buy an app rather than keep polling?