Actor Risk Profile(2.6.9)

Every configuration change has an author, but not every event Jira sends names it. This visual shows you which accounts are responsible for the most admin-level events that do name one — and what types of actions they are taking. Each account carries the type Jira reports for it, so an app account making bulk changes can be read apart from a person doing planned administration.

This is the “who” view for permission drift. It shows which accounts, people's and apps' alike, trigger admin-level events, so a reviewer can set them against the accounts expected to administer Jira.

What you can conclude

• Does an account Jira reports as an app, near the top of this ranking, hold only the permissions its documented purpose needs?
• Does an account making many admin changes in a short period match planned administration work?
• Does an account with no recognized name or unclear purpose have an owner, and a reason to hold admin-level access?

How this chart works

Ranked horizontal bar chart showing which account IDs are responsible for the most permission-level events, with each bar broken down by event type (creation, update). A Destructive series is drawn only when an account shown on the chart has a removal (a deletion, a move to the trash or an archive) that names it. The events Jira sends for field, project and user-account changes, deletions among them, do not name the account that made them: they are not ranked here and add nothing to that series, and they are counted in the summary KPI. A user-account event names only the account it is about, which is never treated as the account that acted. Each account is labeled with its type as Jira reports it: person, app, customer, unknown when Jira returned no type, or erased.

Teams preparing a DORA or NIS2 review use this to see which accounts drive admin-level change.