Group Impact Audit for Jira Guide
Guide

What the app checks, what it exports, and where the boundaries are.

Use this guide to understand what the app scans, how severity works, what evidence can be exported, and which Jira surfaces are still intentionally out of scope at launch.

Getting started

  1. Install the app from Atlassian Marketplace when the public listing is live.
  2. Open the app and enter the exact Jira group name you want to evaluate.
  3. Run a read-only scan to collect references from supported Jira configuration surfaces.
  4. Review findings, severity, blockers, and readiness before making any Jira cleanup change.
  5. Save the run, compare it to history or a clean baseline, and export the evidence pack if another reviewer needs proof.

What is in scope

  • Project roles
  • Permission schemes
  • History and baselines
  • Diff and comparison workflows
  • Evidence export and verification
  • Policy rules, exceptions, and admin safety controls
Supported outputs

Evidence is a normal part of the workflow.

The app is built around reviewable outputs, not just transient UI state.

Area What it tells the reviewer
Project roles Where the group still appears in role assignments that may affect project-level access.
Permission schemes Which permissions still reference the group and how severe those references are.
History and baselines What changed between scans, whether a baseline was clean, and how risk moved over time.
Evidence export Whether the result can be handed off as a reviewable pack instead of an informal screenshot.
Severity

Deterministic and versioned.

The same underlying state should produce the same evidence shape and the same severity mapping.

Severity Typical meaning Launch examples
Critical References tied to the highest-risk administrative access. ADMINISTER, SYSTEM_ADMIN
High Strong admin or project control that should usually block cleanup until reviewed. PROJECT_ADMIN, admin-like role names, MANAGE_SPRINTS_PERMISSION
Medium Operational impact that still matters but is less likely to be tenant-wide. EDIT_ISSUES, ASSIGN_ISSUES, most non-admin role references
Low Lower-risk references that still belong in evidence and cleanup review. BROWSE_PROJECTS, VIEW_DEV_TOOLS

Exported artifacts

  • Evidence ZIP pack
  • Evidence CSV
  • Evidence report PDF
  • Manifest JSON
  • History and audit CSV outputs

What stays out of scope

  • Workflows, filters, dashboards, issue security schemes, notification schemes, automation rules, and app-specific permissions
  • Direct remediation of Jira permissions or groups
  • Anything that would mutate Jira state during review