An auditor asks who could access a Jira project last March. Can you answer?

[#1]

An auditor asks something that sounds simple: show me everyone who could access the Payments project on March 3rd. If that date is more than about six months back, Jira only shows access as it is right now, never as it was. The audit log retains roughly 180 days, then the event is gone.

Raising that cap is a long-standing open request: JRACLOUD-68267 has been gathering votes for years, about 226 and counting. And access is rarely direct: a user sits in a group, the group holds a project role, the role grants access, so answering who could reach a project on a given day means replaying change events and expanding every group as it was then.

You can build the evidence yourself: on a schedule, enumerate projects, read each role's actors, expand groups to effective users, store each day's matrix keyed by date, and diff each run against the last. It works, but you now operate a scheduled pipeline with rate-limit handling, per-project failure isolation, retention, and pruning, forever, and a missed week is an unanswerable week.

Disclosure: I work for Katabarwa Labs, and we build a small app for exactly this gap, so treat it as one option among whatever you evaluate.

Access Snapshot & Drift takes that daily snapshot for you: every project's roles, group grants, and effective users (groups fully expanded), stored under its date and retained by default around 400 days, well past the native cap. Pick any retained date and read its access matrix back verbatim, review each run's drift (users and groups added or removed per role) as a delta instead of a re-audit, and export any date to audit-ready CSV. It runs on a Forge scheduled trigger inside your own tenant, so nothing leaves your instance, and the snapshot and reporting path is read-only.

Listing, if it helps: Access Snapshot & Drift. If the snapshot or export shape is not quite what your audit needs, tell us and we will build it.