High-Risk Issue Forensic Event Timeline(3.3.10)

When an issue has a high risk score, you need to understand why. This forensic timeline shows every significant event in an issue's lifecycle — creation, status changes, priority changes, assignee changes — in chronological order, so you can see exactly how a ticket accumulated its risk profile and what interventions were made (or missed) along the way.

For compliance audits, this is the record that demonstrates due diligence on high-risk issues.

What you can conclude

• A long gap with no events in the middle of the timeline is the most common contributor to high risk scores — the issue was abandoned for a period.
• Multiple priority changes in a short window indicate poor initial scoping or external pressure driving reactive triage.
• A clean, progressive timeline (create → assign → progress → close) with no reversals is the target state — absence of this pattern explains the high score.

How this chart works

Chronological audit table showing all significant events for one issue: creation date, status transitions, priority changes, and assignee changes. The panel opens on the highest-scoring issue in the current project scope; the issue key filter, populated from the scored issues in the Composite Risk Score Ranking, selects another. It shows one issue at a time by design — a chronological interleaving of thousands of unrelated issues is not a forensic record of any of them.

What the timeline does and does not contain

Four event categories make up the whole timeline: Issue created, Status change, Priority change and Assignee change. Each carries its own color, so a run of one category is visible at a glance.

A reopen is not a separate category here. It appears as a status change whose From value is a state your team treats as finished and whose To value is not, so read the From and To columns rather than looking for a reopen row. Comments and worklog entries are not timeline rows at all: an issue with a long discussion and no workflow movement draws as a gap on this timeline, and that gap is the finding rather than missing data.

A status change can also carry the same value in From and To. That is a real event — the same status re-applied, not two statuses sharing a name — and it is shown as Status re-applied rather than removed, because an audit trail with events taken out of it is no longer an audit trail. It is rare in everyday Jira and is worth a question only where it repeats on one issue.

In an assignee change, a person whose Atlassian account has been erased is shown as "erased account" in From or To; Unassigned still means nobody owned the issue.