Guide · Jira

Is a Slack approval valid audit evidence? What to record in Jira instead

Approval Flow for Jira 3.0.0 is the production version (30 October 2026). Last updated 1 November 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

An auditor picks a few sampled changes or access requests and asks one thing for each: who approved this, and when? Some of the answers are a Slack message. People describe this situation in forums, for example in a r/soc2 thread from April 2026 where several approvals in a sample of eight had only happened in Slack. This guide is for the person who has to fix the habit, not just the sample.

The short answer: we cannot tell you what your auditor accepts, and no page we read says that Slack approvals are valid or invalid. What we can say is what a sampled item has to show (who, what, when, and that it came before the work) and where Jira can hold that. A Slack message can answer part of it. The rest may be missing, and the message is not attached to the work item the auditor is looking at.

What a record of an approval has to answer

For one sampled item, the questions are the same each time:

Who approved it, as a named person and not as "the team"?
When, with a date and a time?
What exactly did they approve? The request as it stood then, not as it reads now.
Was it before the work started?
Could anyone have changed the record afterwards, and would you know?

A Slack message can show a name and a time. Whether it shows the rest depends on how the message was written, and on how long your workspace keeps messages and who can delete them. We have not checked Slack's retention rules and do not state them here; ask your Slack admin. The other practical problem is where it lives: the auditor opens the Jira work item and finds nothing about the approval.

What Jira gives you natively

1. A decision field on the transition. In a company-managed project, add an "Approved by" user field and a transition screen that shows it, then attach the Field Required validator to the transition you want guarded. Atlassian's knowledge-base steps: open Project settings, then Workflows, edit the workflow, select the transition, add a validator, choose the Field Required validator and the field, then publish. Atlassian describes the idea as "we'll set a validation where a field must have a value before changing from Status A to Status B". The limit: the field says who is listed, not who agreed. Whoever has permission to edit the work item can type any name into it.

2. The History view. Atlassian describes the History filter in the Activity section as "Updates on a work item, like when someone edits a field, moves the work item through its workflow, and more." If the approver field is filled in or the status changed, a History entry exists. Open a real work item on your own site and check that each entry shows the person and the time; this guide does not rely on that.

3. Comments. A comment saying "approved" is the most common Jira record, and the weakest. Atlassian's permission page says "The Edit all comments permission allows users to edit comments or internal notes added by anyone." and "The Delete all comments permission allows users to remove comments (including customer comments!) and internal notes from work items." Look at who holds those two permissions in your permission schemes before you treat comments as evidence.

4. The audit log is the wrong place. It is where administrators look for configuration changes, and Atlassian is plain about its scope: "The audit log isn't intended to record all activity in Jira." It also says "The audit log isn't available if all of your Jira Cloud apps are on the Free plan." Do not expect a work item's approval to show up there.

5. Native approvals. They exist on the top plans. Atlassian's support page says "The approvals feature is only available on Premium editions in Jira". Which plans of which product include approvals is in Which Jira and Confluence plans include approvals.

Moving the habit out of Slack

You do not have to stop using Slack. Stop deciding in it. The request goes to the channel with a link to the Jira work item, and the person approves in the work item. Jira Automation can post the link for you; a worked example is in Jira approvals in Slack, Microsoft Teams and e-mail.

Three small rules help whichever route you choose:

The approval is recorded before the transition into the work stage, so the order is visible.
If someone approved in Slack anyway, a person copies the decision into the work item at once, with a link to the message, and says in the comment that it is a copy.
The sample the auditor will ask for is a saved JQL filter, so you can pull it in minutes and not rebuild it from chat history.

What this does not fix: an approval that already happened only in Slack stays an approval that happened in Slack. You can attach the message to the work item, and an auditor may or may not take it. We would not backfill a record to look like it was made at the time.

How our app helps

Approval Flow is our app, so weigh this section accordingly. It adds a list of required sign-offs to a Jira work item, with named approvers, and a workflow validator ("Approval sign-off required") that blocks the transition until every Required sign-off is in. Each sign-off records the signed-in person and the time, and a rejection needs a reason. Decisions go into a hash-chained audit trail that you can export as CSV or JSON, and a later check tells you whether an earlier entry is still in the log unchanged. Rules: with separation of duties on, the person who added a requirement cannot approve it.

The limits matter more than the features here. It cannot approve inside Slack, Teams or e-mail: people are asked there and decide signed in to Jira. Old approvals can be imported from a CSV, but they are shown as "Imported, not verified by Approval Flow" and never count as a sign-off, so it does not turn a Slack history into evidence. A hash chain makes a change visible; it does not stop one, so keep the chain head from an export in your own archive. And it helps produce evidence for an audit but does not decide whether a control is satisfied; that is for you and your auditor. It is not a legally binding electronic signature.

Free for up to 10 users with every feature, then from USD 0.90 per user per month for the first 100 users. See the documentation and the Approval Flow listing on the Atlassian Marketplace.

What we have not checked

We did not test the native steps above on a Jira Free site for this guide; they are taken from Atlassian's pages, read on 30 October 2026. We have not looked at how any auditor treats Slack evidence, and none of this is advice on SOC 2 or any other standard. For the change-record side of the same question, see ISO 27001 change management evidence in Jira.

Common questions

Are Slack approvals valid audit evidence?

That is for your auditor to say, and we found no source that decides it. A Slack message can show a name and a time but sits outside the work item and may not show what was approved or whether it came before the work. Ask your auditor which fields they want for a sample, then record those in Jira.

What should I record in Jira instead of a Slack message?

Who approved (a named person), when, what was approved, and that it happened before the work started. The most reliable way in Jira is a decision that is made in the work item and gates a workflow transition, with its history.

Can a Jira comment serve as an approval record?

It can, but it is weak. Atlassian's permission page says people with the Edit all comments or Delete all comments permission can change or remove comments by anyone, so check who holds them.

Does Jira's audit log record approvals?

No. Atlassian says the audit log is not intended to record all activity in Jira; it records configuration changes.