How to Prove Who Had Access to Jira Last Quarter (When the Audit Log Only Goes Back 180 Days)

[#1]

In one minute: Jira answers "who has access right now?" well. It cannot answer "who had access on 31 March, and who signed off on it?" — because the audit log is an event stream, not a state history, and it only goes back 180 days. Below: exactly what native Jira gives you, the retention math that breaks the "just export the audit log" plan, a manual procedure you can run this quarter, three traps that make hand-rolled reviews quietly wrong, and the fields an attestation record needs.

If you've been through a SOC 2 or ISO 27001 audit, you've had some version of this conversation:

"Show me everyone who could access these Jira projects during the review period, who reviewed that list, and what changed since the previous review."

The first part feels answerable. The second and third are where most teams discover their evidence doesn't exist anymore.

Why "who has access?" and "who had access?" are different questions

This distinction is the whole problem, and it's worth being blunt about it.

Jira's admin screens give you current state: who is in this group now, what this scheme grants now. The audit log gives you events: a change happened, at a time, to a thing.

Neither one is a state history. To reconstruct "who could browse PROJ on 31 March" by replaying events, you would need two things: a known-good starting state, and a complete, untruncated event history from that point forward. Jira gives you neither. There is no stored snapshot of what the access set looked like on a given date.

So the honest framing for an access review is: if you didn't capture the state, it's gone. Not "hard to find" — gone. That's not a criticism of Jira; it's how event logs work everywhere. But it does mean your review process has to create the evidence, because nothing creates it for you.

What native Jira actually gives you

There's a fair amount here, and it's worth being precise rather than claiming nothing exists — an access review touches several surfaces, and each one stops somewhere specific.

Native surface	What it gives you	Where it stops
Project settings → People	Direct role members on one project	One project at a time; doesn't resolve who's inside a group that holds a role
admin.atlassian.com → user → View Jira project roles	One user's project roles across all projects	Roles are not access. Won't show access granted via group membership in a permission scheme, and can't tell you whether a role actually confers Browse Projects
Permission Helper	Whether one user has one permission on one project	A lookup, one query at a time — not an exportable report
Rovo /manage-jira-permissions	Conversational explanation and troubleshooting of a permission setup	Explains the current setup; not a dated, exportable evidence artifact
Permission schemes	Which permission maps to which role, group or user	Scheme-level; not resolved down to named people
Groups (admin directory)	Membership lists	No link to what that membership grants, in which project
Jira product audit log	Change events	Events, not state. Can't sort in-product
Organization audit log	Attributable org-level events	Requires Atlassian Guard Standard/Premium or Cloud Enterprise; without one, org-level logs store and display nothing

Effective access in a company-managed project is the join of all of these: project roles + group membership + permission scheme grants + admin roles that bypass the lot. No native screen performs that join across projects.

The reverse direction — "list every user who can access project X" — has no native report at all. The long-running request for the group half of this is JRACLOUD-71967 ("Group usage - List of project permission per group"), open since April 2019, Gathering Interest, with nearly 1,000 votes. In November 2024 an Atlassian Jira Cloud product manager commented that it would not be implemented within the following 12–18 months. That window has now passed.

The retention math that breaks "we'll just export the audit log"

This is the plan most teams land on, and it's worth running the numbers before you rely on it for a year.

Evidence source	Limit	What it means for a review
Organization audit log retention	180 days, and activities older than that are removed and can't be recovered	A Q1 review has no source evidence left by autumn
Organization audit log CSV export	up to 10,000 activities; the export does respect your search and filter settings	Busy orgs truncate — and the truncation is silent
Jira product audit log CSV export	up to 100,000 events; the export ignores the filters you set on screen and returns the most recent events regardless	You can't reliably export "just the permission changes"
Sorting	You can't sort the audit log in-product	Analysis happens in a spreadsheet, by hand
Free plan	No audit log at all if all your Jira Cloud apps are on Free	The evidence chain never starts
Typical SOC 2 observation window	~12 months	Structurally longer than the evidence window

That last row is the one to sit with. The retention period is shorter than the audit period. Retention is a flat 180 days across tiers — Atlassian Guard Premium's "extended audit logs" means broader activity coverage, not longer retention. The open request to change this is ACCESS-991 ("Increase audit log storage and export", Gathering Interest).

There's also an attribution wrinkle worth knowing: in the Jira product audit log, user-management changes don't always show which admin made the change — the author can appear as "JIRA" rather than a person. It's tracked in JRACLOUD-95188 (Reviewing) and JRACLOUD-94614 (Gathering Interest). These are low-vote tickets, so it's a niche gap rather than a widely-felt one — and Atlassian's noted workaround is the organization audit log, which does record the real actor. That requires Guard.

Running the review manually: a procedure you can actually follow

None of the above means you need a tool. It means you need to capture state deliberately, on a schedule. Here's the loop, and it's genuinely runnable by hand for a modest number of projects.

1. Freeze the scope by ID. List the projects in scope using their project IDs, not keys or names — keys and names get changed, IDs don't. Record the date and who defined the scope.
2. Capture the scheme → holder map. For each in-scope project, record which permission scheme applies and, for each permission that matters (start with Browse Projects and Administer Projects), which holders grant it: groups, project roles, individual users, application roles.
3. Resolve every holder to people. For each group holder, capture the current member list; for each project-role holder, capture the role's actors. Store accountIds, and keep display names as labels only.
4. Capture admin roles separately. Site, org and product admins bypass project-level permissions. A review that omits them is incomplete.
5. Store it as a dated artifact. One file per cycle, timestamped, with the scope definition attached. This file is your point-in-time snapshot — the thing native Jira never keeps for you.
6. Diff against last cycle's artifact on IDs. Every accountId or groupId present now but not before is an addition; the reverse is a removal.
7. Review, decide, sign off, and store the decision alongside the snapshot (fields below).

If you do exactly this once a quarter, you have a defensible review. The failure mode isn't that it's impossible — it's that steps 3, 5 and 6 are fiddly enough that they quietly drift, which brings us to the traps.

Three traps that make a hand-rolled review quietly wrong

Loudly broken is fine — you notice and fix it. These are the ones that produce a clean-looking spreadsheet that's wrong.

1. Diffing on names instead of IDs

If you diff two quarterly CSVs on display name or email, you will manufacture changes that never happened and hide ones that did. A display-name change, an email change during a domain migration, a group rename, or a project key change all read as "removed + added" — one person appears to have lost and gained access on the same day. Meanwhile a genuine change can hide behind a matching name.

Diff on accountId, group id, and project id. Render names purely as labels. This single decision is the difference between a review that holds up and one that generates noise your reviewers learn to ignore.

2. Indirect access through groups

Project settings → People is a dead end when access arrives via group → role → scheme. A review that lists only direct role members is materially incomplete, and this is the most common way a real access path gets missed.

Trace the full chain and record it, so a reviewer can see why someone has access, not just that they do:

User	via Group	which holds Role	in Scheme	granting	on Project
a.novak	jira-developers	Developers	Default software scheme	Browse Projects	PROJ (id 10042)

When a reviewer decides to revoke, the chain tells them where to act — removing the person from the project won't help if the access comes from a group.

3. Deleted and anonymized users make old evidence unreadable

This one surprises people. Under a right-to-erasure request, Atlassian anonymizes the account — display name, email and avatar are stripped. Any evidence artifact that resolves names by live lookup will retroactively lose them.

And the person most likely to be erased is a departed employee, which is precisely the account an auditor asks about.

Practical guidance: prefer deactivating over deleting where your policy allows, and capture the display name as it was at snapshot time as an immutable field of the evidence record — not as a lookup you re-run later. Your snapshot should still make sense after the underlying account is gone.

What an attestation record actually needs

"We did the review" is not evidence. A recurring finding in access-review practice is reviews performed without a documented sign-off. Whether you keep this in a spreadsheet, a Confluence page, or a tool, these are the fields that make it stand up:

• Scope reviewed — project and group IDs, not names
• Snapshot ID and snapshot timestamp — what exact state was reviewed
• Reviewer identity — the accountId of the person attesting
• Reviewer's authority — why this person is entitled to approve (project owner, system owner, manager)
• Decision per line — retain, revoke or escalate, one per access grant
• Justification for retains — especially for elevated or admin access
• Timestamp of the decision — per decision, not per cycle
• Remediation reference — the ticket where a revoke was actually carried out
• Immutability claim — append-only storage, or a hash, so the record can't be quietly edited later

For SOC 2, this is the material that speaks to CC6.1 (logical access), CC6.2 (provisioning) and CC6.3 (modification and removal); ISO 27001's access-control review asks for the same shape. The point isn't the framework mapping — it's that each of those criteria wants evidence over time, and the timestamped decision record is what supplies it.

Where this leaves you

If access review is a once-a-year event for a handful of projects, the manual loop above is entirely reasonable — capture state deliberately, diff on IDs, record sign-off, and keep the artifacts somewhere the 180-day clock can't reach.

If it's a recurring control across many projects, the parts that hurt are the ones you repeat: resolving groups to people every cycle, diffing correctly, and not losing history. Several Atlassian Marketplace apps automate that snapshot → diff → sign-off → export loop.

Full disclosure: I'm the developer behind one of them — Access Review & Audit Trail for Jira. It takes periodic snapshots of project, group and role permissions, diffs them on stable IDs, records timestamped reviewer sign-off, exports CSV/PDF, and keeps the history beyond the native retention window. I mention it because it's the exact problem described here — the manual procedure above works without it.

FAQ

How far back does the Jira audit log go?
Organization audit log activities are retained for 180 days; older activities are removed and can't be recovered. This is flat across plan tiers — no tier extends it.

Can I just export the audit log every quarter and keep the CSVs?
It helps, but mind the caps and the difference between the two exports. The organization export is capped at 10,000 activities and respects your filters; the Jira product export goes to 100,000 events but ignores the on-screen filters. And an event log still isn't a state snapshot — you'd be storing changes, not the access set itself.

Does Project settings → People show everyone who can access the project?
No. It shows direct role members. Access granted through group membership in a permission scheme won't appear there, and neither will admins whose global rights bypass the project.

Is there a native report of every project a user can access?
Partly. In admin.atlassian.com, a user's details include View Jira project roles, which lists that user's project roles across all projects — but roles aren't access, and it won't reflect group-derived permissions. The reverse direction (every user who can access project X) has no native report.

What does an auditor accept as sign-off?
A record tying a named reviewer to a specific reviewed state at a specific time, with per-item decisions and follow-up for anything revoked. See the field list above.

What happens to my evidence if a user is deleted?
Anonymization strips the display name and email. Capture the name as it was at snapshot time so the historical record stays readable, and prefer deactivating over deleting where policy allows.

Do I need Atlassian Guard for any of this?
For the organization audit log, yes — it requires Guard Standard/Premium or a Cloud Enterprise plan. The Jira product audit log is available on paid Jira plans without it.

How do you handle access reviews in Jira today — native exports, a script against the admin API, or an app? And has an auditor ever asked you for a period you could no longer reconstruct? Curious what's working for teams at different sizes.

[Cristian Quiroz Garcia]

I see this all the time: teams assume Jira's audit log is enough, only to realize too late that:

Reconstructing past state from 180 days of raw event logs is almost impossible.

Direct role lists completely miss group-derived access.

Diffing on display names instead of accountIds creates endless noise.

Your manual workflow is a great practical guide for teams without extra tools. Excellent write-up!