Toolkit
Change control toolkit for Jira Service Management Standard
Written by Bartosz Stankiewicz, founder, Stanki Guild. Last updated 1 November 2026. We make all three apps on this page.
If your IT team runs changes through Jira Service Management Standard and an auditor wants proof that each change was checked, approved by someone other than the requester, and recorded, this page lays out the process step by step and says which of our three apps covers each step today. It also says where Atlassian's own tools stop on Standard, and what none of our apps do.
We make all three apps, so this is a vendor page. What we say about Atlassian comes from Atlassian's own pages, quoted and dated. What we say about our apps comes from our documentation and from the code of the production versions. Where we have not tried something, we say so.
Who it is for
#IT and operations teams that:
- run changes through Jira Service Management (Cloud) on the Standard plan, and
- have to show records for an audit, a customer's security questionnaire or a regulation: ISO 27001 change management evidence in Jira and NIS2 and change control in Jira cover what those ask for.
It is not for you if you are on Premium or Enterprise and the native change features already do what you need. Then buy nothing from us. It is also not the answer if you need a change calendar with freeze windows or automatic risk scoring: we do not have those (see the end of this page).
What Atlassian changed
#On Standard, the native change features moved up a plan. Atlassian's announcement, dated 29 October 2024, says "Advanced incident, problem, and change management capabilities will be moving out of Jira Service Management Free & Standard and into Premium & Enterprise." It also says "These changes will take effect on October 16, 2024." (the post carries a later date than the effective date; we report both as printed). Under Premium and Enterprise it lists, among others:
- "Change work category"
- "Change queues"
- "Change calendar"
- "Automated risk assessments"
The change management help page repeats it: "As of October 16, 2024, some capabilities of this feature are only available in Jira Service Management Premium and Enterprise." Note "some". We did not test which parts remain on Standard on a live site. Read the plan comparison for your own site before you decide.
Atlassian's pricing page, which we read on 1 November 2026, lists Standard at "$21.50 per agent / month" and Premium at "$55.28 per agent / month". We could not see which team size or billing setting the page was showing (it asked us to switch to annual billing to see Enterprise prices, so it was probably on monthly). Treat both as direction, not as a quote for your site. Under Premium the same page lists "Configure and automate approval workflows based on change type, AI-powered risk assessment, or CAB procedures."
Premium also brings other things, such as asset management and a 99.9% uptime SLA, according to the same announcement. If you want those, the comparison is not between Premium and three small apps, and Premium may be the right call. Our apps are priced per user on the Marketplace, Premium per agent; how many users your site counts for the Marketplace tier is shown on each listing, so work out both for your own site before comparing.
One more thing about the native route. Atlassian's tracker has a request that approval steps in Jira Service Management should not skip workflow validators: JSDCLOUD-6988, 493 votes, status "Gathering Interest" when we read it on 30 October 2026. If your process relies on a validator running when the native approval step moves a request, test that first. More in Jira approval step skips the workflow validator.
The process, step by step
#| Step | What an auditor wants to see | Covered today by |
|---|---|---|
| 1. Request | A change record with description, reason, risk and who asked | Jira Service Management request type and fields (native). Not one of our apps |
| 2. Required checks | A checklist of checks that must be done before the change moves on, and proof they were | Checklist Flow, with its blocking validator |
| 3. Approval | Named approvers, enough of them, not the requester, with a reason when someone rejects | Approval Flow |
| 4. CAB | A second, higher-level review for riskier changes | Approval Flow, as a later stage |
| 5. Implementation | Implementation and rollback checks done by the person who did the work | Checklist Flow |
| 6. Updated procedure acknowledged | Named people confirmed they read the new version of the runbook | Attestation Flow, in Confluence. Separate step, not linked to the change |
| 7. Evidence | Records that can be exported and checked later | Each app exports its own records. There is no combined pack |
1. Request
This is plain Jira Service Management: a request type for changes with the fields you need. On Standard you build it yourself, since the ready-made change work category is a Premium feature. We add nothing here. Fields to consider: what is changing, why, the systems affected, the risk, the planned date, the rollback plan and the requester.
2. Required checks
Checklist Flow puts a checklist on the work item. Items marked Required block a workflow transition until they are ticked or marked not applicable. You add the validator "Checklist Definition of Done" to the transition, for example from Approved to Implementing, and the checks become a gate. Typical items: test evidence attached, rollback plan written, affected teams told, backup taken. Every change to the checklist goes into a hash-chained history that no role can clear inside the app.
3. Approval
Approval Flow keeps a list of required sign-offs on the work item and blocks a transition with the validator "Approval sign-off required" until every Required one is in.
- You name the approvers per requirement (up to 20), and set how many of them must sign: a quorum from 1 to 10. Both are available on the free tier.
- Rejecting needs a reason. Requiring a comment on approval is a paid-edition setting.
- With separation of duties on, the person who created a requirement cannot approve it. A requirement added automatically (by a rule or a policy) also cannot be approved by the work item's reporter. So "the requester cannot approve their own change" holds when the requirements are added by a rule or policy, which is how we would set it up. If someone adds them by hand, the person who adds them is the one blocked.
- The decision, the person, the time and what it meant are recorded in a hash-chained audit trail. A PIN or authenticator code at signing and a signature meaning ("Approved", "Reviewed") are paid-edition settings.
Approval Flow runs its own gate beside Jira Service Management's native approval step. It does not replace that step and does not change its Approve and Decline buttons. We have not tested the two together on a Jira Service Management project.
4. CAB
We model a Change Advisory Board as a later stage: stage 1 is the technical approver, stage 2 is a quorum of named CAB members (for example 2 of 4). Stages run in order, 1 to 9. That records who approved and when. It does not run the meeting, keep minutes or plan a calendar. If you hold a CAB meeting, put the decision link in the work item.
5. Implementation
A second Checklist Flow gate on the transition to Closed: change done, rollback tested or not needed, monitoring checked, post-implementation review noted. Checklist Flow can also require, as one item, that Approval Flow's approvals are complete. In the code it reads Approval Flow's status and counts it only if it is verified: signed by Approval Flow for that work item and confirmed by Approval Flow's own read-only Approval status field. If the signature or the field does not match, the item does not count as met. This needs both apps on the site, and linked conditions are a paid-edition feature of Checklist Flow. We checked this in the code of Checklist Flow 3.1.1 and Approval Flow 3.0.0, the production versions.
6. Updated procedure acknowledged in Confluence
When a change alters a runbook or a procedure, the people who run it should confirm they have read the new version. Attestation Flow asks named people (or, in the paid edition, Confluence groups) to confirm a specific page version and asks again when the page changes. The receipt names the version and the person.
What it does not do: it does not know about your change. Nothing stops the change from closing while people have not yet confirmed. The link is a manual one: add a Checklist Flow item such as "Runbook version confirmed in Attestation Flow" and have the change owner tick it after looking at the report. That is a person's check, not an automatic one.
7. Evidence for the auditor
Each app keeps its own record and exports it. Approval Flow exports its audit trail as CSV and JSON on every edition; the approval certificate and the audit evidence pack (PDF and CSV, one to 500 work items picked by a JQL search) are paid-edition features. Checklist Flow exports its history, and the evidence export for a JQL search is paid. Attestation Flow exports a page's evidence as CSV and JSON, and the compliance report and evidence pack are paid.
That is three sets of files. We do not have one combined evidence pack across the three apps, and we have not claimed one. For a sampled change, you hand the auditor the work item, the Approval Flow export and the Checklist Flow export, and for the runbook the Attestation Flow export. Whether those records are enough is for you and your auditor to decide. Our apps do not make a process compliant with any standard.
For which ISO 27001 controls and NIS2 Article 21 measures each record relates to, and what stays your job, see the control mapping.
What we do not do
#- No change calendar, freeze windows or conflict detection. Premium has a change calendar.
- No automatic risk assessment and no CI/CD or deployment gating.
- No standard-change auto-approval and no link to a configuration database or Assets.
- No meeting, agenda or minutes for a CAB.
- No automatic link between a change and a runbook acknowledgement in Attestation Flow.
- No combined evidence pack across the three apps.
- Nobody approves inside Slack, Teams or e-mail. People are asked there, if you build the Automation rule, and decide signed in to Jira.
- The Jira mobile app does not show Forge apps (Atlassian issues FRGE-538 and FRGE-1492). People use the phone browser.
- We have not run this exact setup on a Jira Service Management Standard site with a change request type. Approval Flow's panel and validator work in Jira Service Management projects according to our documentation, and the customer portal view of approvals is a paid feature that we have not shown live with a portal-only customer. Try it in a trial before you rely on it.
- No claim of ISO 27001, NIS2, SOC 2 or any other compliance or certification. See Trust.
How to get all three
#Each app is its own Marketplace listing and is free, with every feature, for sites with up to 10 users:
Above 10 users each app is billed through the Marketplace at its own price: Checklist Flow $0.80, Approval Flow $0.90 and Attestation Flow $0.75 per user per month for users 1 to 100 (graduated above that; all bands on Pricing). At 50 users that is $400, $450 and $375 a year. Add the three you use.
There is no bundle price, and we promise none. The Marketplace has no bundle for Cloud apps: "Bundled promotions for cloud apps are not available." If your site has more than 10 users and you want to try all three, write to support@stankiguild.com and ask for a promotion code. It is on request.
You do not need all three. You can start with Approval Flow and Checklist Flow, which cover steps 2 to 5, and add Attestation Flow only if your procedures live in Confluence and someone has to prove they were read.
Common questions
#Do I need all three apps for change control?
No. Checklist Flow covers the required checks and Approval Flow covers approval and CAB stages. Attestation Flow is only for the step where people confirm they read an updated Confluence procedure.
Can the requester approve their own change?
Not when separation of duties is on and the sign-offs are added by a rule or policy: the person who created a requirement cannot approve it, and a requirement added automatically cannot be approved by the work item's reporter either. If someone adds the sign-offs by hand, that person is the one blocked, not necessarily the reporter.
Is there one evidence file for the whole change?
No. Each app exports its own records. We have not built a combined pack.
Is this cheaper than Jira Service Management Premium?
We do not know for your site. Premium is priced per agent and brings more than change management; our apps are priced per user and cover only part of it. Work out both with your own numbers.
Atlassian, Jira, Confluence and Jira Service Management are trademarks of Atlassian. Other product names are trademarks of their owners and are used only to identify those products. Stanki Guild is not affiliated with, endorsed or sponsored by Atlassian or by any vendor named on this page.