Before you start
- You need the Administer Jira global permission. To review group members you also need access to Atlassian Administration (
admin.atlassian.com). - Have a document or spreadsheet open to note each finding, where it is and what you decided.
Jira sites grow for years. Spaces get created, filters get shared with everyone, a contractor gets an admin role and keeps it. Nobody decides to leave the doors open; it accumulates. These checks find where it happened.
1. Permission schemes: who can see, change and delete
- Go to Settings (the gear icon) → Work items → Permission schemes. Note every scheme and which spaces use it.
- Open each scheme's permissions and read who holds the sensitive ones: seeing a space at all (the browse permission), administering it, editing, deleting and moving work items, and deleting other people's comments and attachments.
- Look for these holders. They are where most real exposure comes from:
| Holder, as Jira shows it | Who that is | How serious |
|---|---|---|
| Public | Anyone on the internet, without logging in | Fix first |
| Any logged in user | Everyone who can log in to the site | Check intent |
| Application access | Everyone with access to the Jira product | Check intent |
| Single user | One named person, whose access stays with them when they change teams | Tidy up |
| Group, Space roles | The normal way to grant access | Check members |
- For each hit, ask whether it is intended. Public on the browse permission of a space that is not meant to be public is the finding to fix first.
- Note schemes that no space uses. They are clutter, and a trap if someone attaches one to a new space later.
Example, illustrative: a scheme named "Default" grants the browse permission to Public and is used by 14 spaces. Every work item in those spaces can be read by anyone, without logging in.
2. Global permissions: who runs Jira
- Go to Settings → System → Global permissions.
- List every group and user that holds Administer Jira. These are the groups to review in step 3.
- Note who holds Share dashboards and filters. If it is everyone, expect many shared filters in step 5.
- Prefer groups over individual users here, so access ends when someone leaves a group.
3. Admin groups and inactive admins
- In Atlassian Administration, open Directory → Groups and open each group from step 2.
- Check every member: still with the company, still needs admin, account still active.
- Deactivated or suspended accounts sitting in an admin group are the quickest wins: remove them.
- Keep the admin group small and named. Fewer admins means fewer accounts that can open everything up.
4. Space roles
- Go to Settings → System → Space roles (formerly project roles). For each role, Manage Default Members shows who new spaces get by default. Changes there apply to new spaces only.
- For each important space, open Space settings and its people page (People in company-managed spaces, Access in team-managed ones). Compare who holds each role with who should.
- Look for roles held by very large groups, and for people who moved teams but kept their role.
- Most permission schemes grant access through roles, so one over-wide role quietly widens every permission that role holds.
5. Shared filters and dashboards
- Go to Settings → System → Filters to search the site's shared filters. Admins can change a filter's owner or delete it there.
- Go to Settings → System → Dashboards (under Shared items). The search shows each dashboard's owner and who it is shared with.
- Flag anything shared publicly (anyone on the web) or with every logged-in user.
- A shared filter only leaks if its JQL returns work items the audience should not see, so open each flagged one and read the query. Dashboard gadgets can show work item summaries too.
- Unshare or delete what nobody needs. If the owner has left, change the owner first.
6. Record it and repeat
Write down the date, what you found and what you changed. Repeat every quarter, or before each security audit (SOC 2, ISO 27001). The first pass is the easy part. The hard part is noticing next quarter what changed since the last one.
Automating it
If you would rather not repeat this by hand, Ledgerstone runs these checks for you. It flags permission scheme grants open to the public or to every logged-in user, filters and dashboards shared the same way, roles held by everyone with product access, and inactive accounts still in admin groups. Each finding is rated High or Medium, and a weekly run shows what changed.
- Read-only: read scopes only, so it cannot change your Jira.
- Nothing leaves Atlassian: it runs on Atlassian's Forge platform, with no outside servers.
- Free for sites up to 10 users; larger sites start with a 30-day free trial.
Try Ledgerstone free on the Atlassian Marketplace, read how it works, or write to support@monaidea.com.