How do you prepare change management evidence from Jira for auditors (ISO 27001 / SOC 2 / DORA)?

Hi @Nicoleta Mircea ,

If you are open to using apps available on Atlassian Marketplace, I recommend trying Issue History for Jira (Work Item History) from the SaaSJet team.

This app is used by many companies in highly regulated industries that need to prepare for internal or external audits such as ISO 27001, SOC 2, and HIPAA. 

It lets you generate reports with the complete Jira work item history using flexible filters in minutes, including:

• Status transitions with exact timestamps
• Field changes (before/after values)
• User activity (who changed what and when)
• Comments and edit history
• Assignee, priority, sprint, and other workflow changes
• Deleted work items

You can easily export the reports to Excel or CSV, or access the data via the API. 

Using the app, you can save hours per month needed for passing the audits. 

Also, I think that this article may be interesting for you: How to Generate Jira History Reports for Audit, Security and Compliance

Hi @Nicoleta Mircea ,

Hi @Nicoleta Mircea,
The tools mentioned above cover the extraction side well (issue history, time-in-status, exports). Let me take your second question instead, since I think it's the harder and more important one: what a pack needs to be accepted, not just complete.
In my experience the packs that sail through aren't the ones with the most detail per change — they're the ones that prove the control operated across the whole population, consistently. That usually means:

A reproducible sample definition — the exact JQL that defines both the population and your sample, saved and re-runnable, so the auditor can see the 20 changes weren't hand-picked. e.g. project = ABC AND status changed during ("2026/01/01","2026/03/31").
Per-change trail — status transitions with timestamps and the actor, the approval, field before/after, and (for DORA especially) the link from the change to the actual deployment/PR.
Sequencing, not just presence — proof the approval happened before implementation, and that approver ≠ implementer where segregation of duties applies. Auditors check order, not just that the fields exist.
Integrity — data exported from the system of record, not screenshots, which auditors trust less because they can be edited.
A one-line control mapping — each artifact tied to the control it satisfies, so the auditor doesn't have to infer it.

The piece that's easy to miss: the exceptions matter as much as the clean changes. The fastest-accepted packs I've seen also show you looked for the changes that skipped a step and can account for them — e.g. items that reached Done without ever passing through an approval status. That's a second saved filter, roughly project = ABC AND resolved during ("2026/01/01","2026/03/31") AND NOT (status WAS "Approved") (swap in your real status names). Running that before the audit turns "days of screenshots" into a short, defensible story — and it's usually what makes auditors trust the rest of the pack.

I'm on the marketing side at Everview (execution intelligence over Jira + GitHub). I'm deliberately not pitching it — audit-evidence packaging isn't what it's for — but "what deviated from the expected path" is the lens we look at Jira data through, so I wanted to share that rather than another app link.

Hope it's useful, and good luck with the audit.

Hi @Nicoleta Mircea 

Native Jira keeps the raw material (each issue's History tab, status transitions, and who changed what), and you can pin down the audit sample reproducibly with a saved JQL filter, for example `project = ABC AND status changed during ("2026/01/01", "2026/03/31")`. What it won't do is package that into a clean, repeatable evidence pack, so the per-issue History plus CSV export is exactly the manual, days-long process you described.

For an auditor-ready pack, the pieces that tend to matter are: the sample scoped by a saved filter, status transitions with timestamps and the actor, approvals, field before/after values, and everything exportable so it can be attached to the audit. Having that as a saved, re-runnable view is what turns "days of screenshots" into a button.

If you're open to a Marketplace app, JXL for Jira can cover a good part of that. You build a sheet scoped to the audit sample, add columns for status, assignee, and approvers, plus history-based columns like Time in status, Number of status changes, and Date of status change, then export the whole thing to Excel or CSV in one go.

Disclosure: I'm part of the team behind JXL.

Best regards,
Danylo

Hi @Nicoleta Mircea !

Pulling audit evidence together by hand is indeed painful, and you're right that it eats up days. Auditors usually want to see that each change followed a consistent, documented process.

Native Jira keeps the history and transitions, but it won't package them into a clean evidence pack. One practical option is our solution, Smart Checklist for Jira. You can attach a standard compliance checklist to every change, so each ticket shows the same required steps. Think approvals, testing sign-off, rollback plan, and reviewer feedback.

Smart Checklist also has a dedicated Smart Checklist History tab inside the issue's Activity section (it’s separate from Jira’s native work item History). It logs every checklist event with a timestamp and the user who made the change. You can see who added or removed items, changed item statuses, applied a template, and more. That gives you a repeatable, per-issue audit trail instead of ad-hoc exports.

Here's what this can look like on a change ticket:

You can also make key steps mandatory, so the work item can't move forward until approvals are done. That consistency is usually what auditors care about most.

I hope this helps!

Hi @Nicoleta Mircea ,

I hope you're doing well.

Many of our customers generate these reports at the release level rather than the individual work item level. This provides a complete audit trail of the release, including workflow stages, approvals, timestamps, and the time spent in each status.

We follow the same approach for our own internal reporting, having maintained SOC 2 compliance for the past two years.

If you use Jira Releases (Fix Versions) to group work items and manage your deliveries, our Release Management app can help. It provides cross-project release management and the release-level reporting required for audit, compliance, and governance purposes.

Please let me know if you'd like to see how this works in practice.

Cheers,

Yuri