Every Jira admin eventually gets the same email. An auditor, a new CISO, or a manager after an outage asks some version of:
"Who changed this permission scheme, when, and what did it look like before?"
The Jira audit log is the right place to start. It is also, in my experience, the place where most people stop — either because they find what they need and move on, or because they hit a limit they did not know existed and assume they were looking in the wrong place.
This post is an attempt to write down exactly where that line is, using Atlassian's own documentation rather than folklore. I build a Marketplace app in this space, so treat the last section accordingly — but the first four sections are what I wish someone had written for me.
First: there are two audit logs, and they are not the same
This causes more confusion than any other single thing here.
Product-level (Jira) audit log:
- Where: Jira → Settings → System → Audit log
- Retention: configurable
- Requires: at least one Jira product on a paid plan
- API: GET /rest/api/3/auditing/record
- CSV export cap: 100,000 events
Organization-level audit log:
- Where: admin.atlassian.com → Insights → Audit log
- Retention: 180 days, fixed
- Requires: Atlassian Guard subscription, or at least one Enterprise plan
- API: GET /v1/orgs/{orgId}/events
- CSV export cap: 10,000 activities
They have different coverage, different retention, different plan gates and different APIs. If someone tells you "the audit log keeps 180 days", they are talking about the organization-level one. If someone tells you it can export 100,000 rows, they mean the product-level one. Both are right, about different things.
One coverage difference worth knowing: issue security scheme changes appear in the organization-level activity catalogue but not in the product-level event table.
What the product-level audit log actually records
Atlassian publishes a complete table of captured events. For configuration work, the relevant categories are:
- Permission changes — scheme created, copied, removed, edited, assigned to a project, unassigned; permission added to or removed from a scheme; global permission added to or removed from a group.
- Workflow changes — scheme created, copied, removed, edited, assigned, unassigned; workflow created, copied, removed, renamed; workflow draft published; status created, status updated.
- Screen changes — screen created, copied, edited, deleted; field added to or removed from a screen; tab added, updated, removed.
- Custom field changes — created, updated, trashed, restored, deleted; scheme added to or removed from a project.
- Field configuration changes — created, edited, deleted, copied; per-field hide/show, required/optional, description changes.
- Plus: project ("space") changes, notification schemes, issue type ("work type") schemes, screen schemes, sprints, plans, and work item deletions.
It also records users being added to or removed from projects, groups and roles.
That is a genuinely useful list, and it is more than most people expect. If your question is "was this scheme edited in the last month, and roughly when", the audit log answers it.
Where it stops
Four limits, all documented by Atlassian.
- It is explicitly not a complete record. Atlassian's own scope statement:
"The audit log isn't intended to record all activity in Jira. The audit log is intended to record configuration changes that can impact users and spaces."
That is a reasonable design decision, not a defect. But it means "not in the audit log" does not mean "did not happen".
- The author can be missing. There is a documented known issue:
"There's a known work item which prevents the Author field from displaying the username for changes that were made in the user management pages in Jira Cloud apps (including changes to users, groups, and application access)."
So for exactly the events an access review cares about — user created, user added to group — the who may be blank.
- Before/after values are, at best, per-field strings. The REST API schema does define them:
changedFrom — The value of the field before the change.
changedTo — The value of the field after the change.
fieldName — The name of the field changed.
Two caveats. Both fields are typed as plain string — this is a scalar pair per field, not a structured diff of a configuration object. You will not reconstruct a full workflow definition or a permission scheme document from it. And which event categories actually populate these fields is not documented — the only official example in the API spec is a user's email address changing. If you rely on this, test it on your own instance rather than trusting the schema. The end-user documentation never mentions before/after values at all.
- Coverage changed in August 2024. From the docs:
"We released some improvements to the audit log in August 2024. Some events may not be visible in your audit log if they occurred before this update."
If you are asked for twelve months of history and part of that window predates the improvements, be careful about what you promise.
There is also no sorting in the UI — Atlassian's suggested workaround is to export to CSV and sort there.
Two things people get wrong about plans
The Free plan has no audit log at all. Not a shorter one — none. The API is explicit about the gate being site-wide rather than per-product:
"Returned if: … all Jira products are on free plans. Audit logs are available when at least one Jira product is on a paid plan."
So one paid Jira product unlocks it for the site. Viewing it also needs the Administer Jira global permission.
Retention is configurable, but the range is not documented. The docs only say "Select your retention period e.g. 6 months". If you find a "10 million records" figure while searching, check the page — that guidance is Data Center, not Cloud. Go and look at the actual dropdown on your own instance before you promise an auditor a retention window.
Getting the data out
Product-level, from the docs:
"You can export up to 100,000 events as a CSV file. If you have more than 100,000 events, the newest events are included in the export."
Note that the export ignores any filter you applied in the UI — you get everything up to the cap. The organization-level export is much tighter: up to 10,000 activities from the past 180 days, emailed to you, and the download link expires after one day.
Via API, the endpoint is GET /rest/api/3/auditing/record. It takes offset, limit, from, to and a filter that matches against summary, category, event source, object name and — usefully — changedValues.changedFrom and changedValues.changedTo. Permission required is Administer Jira. Worth knowing for anyone scripting this: the only OAuth scope in "Current" state is the admin-grade manage:jira-configuration. The read-only granular scope read:audit-log:jira is still marked Beta.
A practical approach with no extra tooling
If an auditor asks for configuration change evidence and you want to answer with what you already have:
- Check your retention setting first, before promising a window. Settings → System → Audit log.
- Export to CSV early in the audit, not late. The export is capped and keeps the newest events — so a busy instance silently loses the oldest ones as you wait.
- Export both logs if you have access to both. They cover different things.
- Be explicit about the author gap. If user-management events show no author, say so in your evidence pack rather than letting the auditor discover it. Auditors are far more comfortable with a documented limitation than with a surprise.
- Treat pre-August-2024 events as unreliable rather than absent — and say which is which.
That genuinely covers a lot of audits. If it covers yours, you do not need anything else, and I would rather you kept your budget.
Where it doesn't reach
The gap that remains, after all of the above, is a specific one: the audit log tells you that something changed, and mostly when and by whom. It does not give you a reliable structured before-and-after of the object itself, it does not retain indefinitely, and it does not tell you what else depends on the thing you are about to change.
That gap is why I built Sphior Ledger — it snapshots configuration on a schedule and diffs it field by field, so the before/after is reconstructed from the objects themselves rather than from event metadata. It runs entirely on Forge with no external egress, which matters if the tool is itself going into an audit.
But if the native log answers your question, use the native log. Most of this post is about making sure you know whether it does.
Sources: Atlassian's audit activities documentation, the Jira Cloud platform OpenAPI specification, the organization audit log documentation, and the Jira Cloud plan comparison.
https://support.atlassian.com/jira-cloud-administration/docs/audit-activities-in-jira-applications/
https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-audit-records/
https://support.atlassian.com/security-and-access-policies/docs/view-audit-log-activities/
https://support.atlassian.com/security-and-access-policies/docs/audit-log-activities-database/
https://support.atlassian.com/security-and-access-policies/docs/export-audit-logs/
https://support.atlassian.com/jira-cloud-administration/docs/explore-jira-cloud-plans/
