An access audit should answer three questions: who can enter the workspace, what each person can see or change, and why that access is still needed. Start with the product's current user, group, role, and guest lists. Compare them with an owner-approved roster, then test a small set of representative accounts instead of assuming that a role name proves the effective result.
Build a current access inventory
Export or record every active user, external collaborator, group, project role, site administrator, automation account, and connected application. Include the business owner for each account, the projects it can reach, its effective role, and a review date. Flag shared sign-ins, former workers, dormant accounts, unknown email domains, and accounts with no named owner.
For Jira, access is layered. Atlassian explains that permission schemes can grant actions to groups, roles, or individuals for a project, while the Browse Project permission determines whether a user can view that project's work items. That means a site-level account list is not enough; the review also needs project membership and the permission scheme attached to each project. See Atlassian's permissions overview.
Compare duties with effective permissions
Write down the smallest set of actions each role actually needs: view work, create or edit items, assign work, manage members, change workflows, administer integrations, export data, or delete records. Compare that list with what the software currently grants. A contributor who only updates assigned tasks should not automatically inherit project administration. A temporary vendor should have an end date and access only to the relevant workspace.
CISA's hardening guidance recommends removing unnecessary accounts, reviewing accounts periodically, and applying least privilege so an account has only the permissions needed for its work. Use that principle as the decision rule, but make changes through the software's supported controls rather than deleting accounts while evidence is still being gathered. See CISA's guidance.
Review the change trail
Check the administrative audit log for additions to groups or projects, role changes, permission edits, new integrations, and unexpected deletions. Atlassian says the Jira audit log records users being added to or removed from projects, groups, or roles, as well as changes to user permissions. The same documentation notes that the log is meant for configuration changes rather than every user action, so absence from that log is not proof that nothing happened. See Jira audit activities.
Match important changes to an approved request, ticket, or owner decision. Record the timestamp, actor, affected account, old role, new role, and reason. Preserve an export or dated review sheet before changing high-impact access so the result can be checked later.
Test before closing the review
Use test accounts or safe impersonation features, if the product supports them, to verify a few critical paths: a viewer cannot edit; a contributor cannot administer; a project administrator cannot reach unrelated projects; and a removed collaborator can no longer sign in. Do not test by sharing a real person's password.
After corrections, re-run the inventory and have the workspace owner approve exceptions. Keep a short record of removed accounts, reduced privileges, unresolved items, and the next review date. The audit is complete only when the account list, project-level access, effective abilities, and change evidence agree.
Sources
- JIRA Permissions General Overview — Atlassian, Sept. 25, 2025
- Audit activities in Jira — Atlassian
- Enhanced Visibility and Hardening Guidance for Communications Infrastructure — Cybersecurity and Infrastructure Security Agency