Guide · Jira

Checklist history and audit in Jira: who checked what, and when

Checklist Flow for Jira 3.1.1 is the production version (1 November 2026). Last updated 29 October 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

The sprint closed, the release shipped, the audit is in six months. Now someone asks: who checked "security review passed" on that change request, and when? Did anyone uncheck it later? Was an item deleted?

In plain Jira that question usually has no good answer. This guide explains why, what to look for in a checklist app, and what a checklist audit trail that holds up looks like.

Why plain Jira has no checklist history

Jira has no checklist object. The closest native feature, action items ([] checkboxes in the description), is text inside a rich-text field:

Checking one changes the description. The work item history records a change to the description, not which item changed, by whom, or in which direction, unless someone compares the before and after text by hand.
Anyone who can edit the work item can check, uncheck, add or delete items. There is no per-item permission.
JQL cannot search action items, so "show me done work items with unchecked steps" is not possible.

Native checkboxes are a good personal to-do list, not a record. If your process (a quality gate, a release checklist, a compliance step) may ever need to answer "prove it", text in a description is the wrong place for it.

The minimum: an event log

Checklist apps keep the checklist in their own storage, and the better ones log every event: item added, checked, unchecked, deleted, by whom and when. When you evaluate one, ask:

Is every state change logged with the person and the time?
Can an administrator clear or rewrite the log? Some apps have a "clear history" action. For a to-do list that is convenient; for an audit trail it defeats the purpose.
Can you export it, and does the export stand on its own (who, what, when, item text) without the app?
Is it the same record for everyone, whatever their role?
What happens on uninstall? An app's data lives while the app is installed, and uninstalling an app typically deletes it. For any app, the export is your long-term archive.

The stronger standard: tamper evidence

An event log answers "what happened inside the app". An auditor may also ask "could someone have changed the log afterwards?". There are two different threats:

Inside the app: a role with an action that clears or edits history. The defence is simply not to ship such an action.
Underneath the app: someone with direct access to the app's storage rewriting records consistently. A plain log cannot detect this. A hash chain can, if you keep an anchor: each record's fingerprint covers the record and the fingerprint before it, so changing an old record breaks every later fingerprint, and a fingerprint you saved outside the app (for example in an export you filed) pins the chain at that point.

The honest limit of any hash chain: if nobody kept an earlier anchor, a complete and consistent rewrite by someone with storage access cannot be detected. Keep the exports.

What to do with the history

File an export at every milestone. Sprint close, release, quarter end: export the history and store it with the release records. That file is both your audit evidence and your anchor.
Search by state, not by memory. If the app writes checklist state to JQL fields, you can find drift now; the history explains it later.
Review breaches on a schedule. A saved filter for work items that reached Done with the checklist unmet turns the audit from archaeology into a weekly glance.

Worked example

A release work item has a 12-item readiness checklist, 6 items required. Three weeks after the release, a regression is traced to a skipped backup step.

Action items in the description: the work item history shows description edits by four people. Working out who checked "backup taken", and whether it was unchecked and rechecked on release morning, means comparing description versions by hand.
An app with an event log: the history lists exactly that sequence with names and times, and it can be exported.
An app with a hash chain: in addition, the export filed on release day carries a chain head, and checking it against today's history shows that nothing recorded up to that point has been rewritten.

How our app helps

Checklist Flow is our app. Every checklist change (items added, checked, unchecked, marked N/A, made Required, edited, moved and removed, plus notes, due dates, assignees and the title) is recorded with who, what and when. The history is append-only: there is no action in the app, for any role, that clears or edits it. The one exception is personal data: when a person is erased or Atlassian reports an account as closed, their account ID is replaced in the history, and that redaction is itself recorded so the chain still verifies.

Each history block carries its own SHA-256 hash and the hash of the block before it. The panel exports a work item's history as CSV or JSON and shows the chain head to keep; the JSON contains the raw blocks and the hashing recipe, so the chain can be recomputed without our code. Pasting an earlier chain head and clicking Check tells you whether that block is still in the history exactly as recorded. With a paid licence, the Evidence export on the DoD Health page collects the history of every work item a JQL query returns, with each chain checked. Uninstalling the app deletes its data, history included, so the exports are the archive.

The history, its export and the chain check work in every edition. Checklist Flow is free for up to 10 users with every feature, then from USD 0.80 per user per month for the first 100 users. See the documentation, the checklist templates and the comparison with other checklist apps.

Common questions

Can I see who checked an item in plain Jira?

Not directly. Checking an action item edits the description, and the work item history shows a description change rather than the item, the person and the direction as a separate event.

Can an administrator erase the checklist history in Checklist Flow?

No role can clear or rewrite the history from inside the app, Jira administrators included. The exceptions are personal data erasure, which replaces a person's account ID and records that it did so, and uninstalling the app, which deletes all of its data.

What is a hash chain, in one sentence?

Each history record's fingerprint is computed over the record and the previous fingerprint, so changing any old record breaks every fingerprint after it.

How long is the history kept?

In Checklist Flow, for as long as the app is installed, in every edition. The retention question that matters is yours: export at milestones and file the exports with your project or compliance records.