Toolkit

ISO 27001 and NIS2 control mapping for our three Atlassian apps

Written by Bartosz Stankiewicz, founder, Stanki Guild. Last updated 1 November 2026. We make all three apps on this page.

Read this first. This is not a certification and not a compliance claim. Stanki Guild holds no ISO 27001 certificate and no SOC 2 report, and the apps do not decide whether any control or legal duty is met. What this page does: for each ISO/IEC 27001:2022 Annex A control and each NIS2 Article 21(2) measure where one of our apps genuinely helps, it says what your auditor will want to see, which feature produces a record of it, which export holds that record, and what stays your job. Your auditor decides what is enough. Nothing here is legal advice.

The three apps are Approval Flow (Jira), Checklist Flow (Jira) and Attestation Flow (Confluence). All three run on Atlassian Forge and make no calls outside Atlassian. Production versions described: Approval Flow 3.0.0, Checklist Flow 3.1.1, Attestation Flow 3.1.0. Editions: Free works without a paid licence; Pro needs an active paid licence (a site with up to 10 users has one at 0 USD).

How to read the tables

"Supports" means the app produces a record of a step the control or measure is about. It never means the control is met. A tick in a checklist proves that someone ticked, not that the work was good.
Only features that exist in the production versions are listed. Anything we have not run live, or have not released, is left out.
Every row ends with what stays with you. For the larger gaps, read "What the apps do not cover".
Control numbers and titles are from a public source (links at the end). The wording of "what you need to show" is our own paraphrase of the topic, not text from the standard. Check it against your licensed copy.

The evidence the apps produce

These are the records the tables point to. Names are as they appear in the apps.

Approval Flow

Audit trail export (Free), per work item, CSV or JSON, from the panel. CSV columns: issue, seq, at, by, via, item, kind, action, text, signer, on_behalf_of, source, signed_at, reason, note, sig, from, to, committed, block_hash, meaning, record_hash. meaning and record_hash are filled on licensed sites. Extra columns appear only when the file has such rows: set_by, bulk_session, bulk_started, bulk_factors. The panel shows the chain head as "number:hash"; Check anchor tells you later whether that entry is still in the log unchanged.
Approval certificate (Pro), PDF per work item: status, whether the log verifies and its chain head, a Requirements table (who must sign, meaning, status, terms hash) and a Decisions table (UTC time, decision, signed by, on behalf of, meaning, comment or reason, PIN used, record hash, log block number and hash).
Approval health project page (Pro): work items waiting for sign-off, and a CSV with columns issue, requirement, status, required, approvals, min_approvals, approvers, rejections, created_by, due_at, overdue, override.
Evidence export (JQL) (Pro): every sign-off, rejection and change from the audit trail for the work items a JQL query finds, as CSV with the audit trail columns, optional date range, "Sign-offs only" filter; each work item's chain is verified as part of the export.
Audit evidence pack (Pro), PDF and CSV for 1 to 500 work items. CSV columns: work_item, summary, approval_status, approved, required, chain_verified, chain_blocks, chain_problems, chain_head_block, chain_head_sha256, checklist_flow_data, cf_dod_met, cf_open_required, cf_done, cf_total, cf_chain_head, decision_time_utc, requirement, decision, signed_by, signed_by_name, on_behalf_of, meaning, comment_or_reason, pin, record_sha256, log_block, log_block_sha256, sentence. One row per decision; a work item without decisions still gets a row.
Change log tab of Approval Flow settings: who changed which setting, CSV columns time_utc, actor_account_id, area, setting, old_value, new_value, via.
Approval status field and JQL (Free): "2/3 approved", "Approved" or "Rejected", searchable with approvalStatus, approvalApproved, approvalRequired, approvalPendingFor.

Checklist Flow

History export (Free), per work item, CSV, JSON or PDF, from More, History. The export states whether the chain verified and prints its chain head; pasting an earlier chain head and clicking Check tells you whether that block is unchanged. CSV columns: issue, seq, at, by, via, item, kind, action, text, from, to, committed, legacy, block_hash, hours_to_check.
Evidence export (Pro), the same columns for the work items a JQL query returns (on the DoD Health project page). Without the right to see people in reports, the person columns are empty.
Item states export (Pro), CSV columns issue, summary, checklist, section, text, state, required, needed, assignee, due, overdue, priority.
Release readiness (Pro), DoD Health project page, tab Release readiness, per fix version: No-go, Not known or Go, with a downloadable go / no-go PDF. "Not known" is shown, never Go, when work items are hidden from the viewer or the version has more than 200 work items.
Checklist export (Free), Markdown, CSV (section, text, checked, required, na, note, due, assignee, status, priority) or PDF: the checklist as it stands.
Settings log and permissions log (Apps menu, Checklist Flow logs): every change to roles, holders and every safeguard turned off, hash-chained; CSV columns time_utc, actor_account_id, area, setting, old_value, new_value.

Attestation Flow

Receipt: one per person per page version, write-once: account, page, version, time, name at signing, meaning of the signature, SHA-256 checksum of exactly that version.
Page evidence export (Free), CSV or JSON from the macro's Evidence section, with a chain check and Check anchor. CSV columns: pageId, seq, at, action, version, status, accountId, receipt_ts, quiz, change, summary, erased, commitment, block_hash, signer_name, meaning, signature, content_sha256, comment, source.
Compliance report (Pro, the name of the report in the app) for a space or all spaces: CSV, Excel and PDF with the same rows. Columns: pageId, pageTitle, spaceId, status, accountId, displayName, versionAcknowledged, latestVersion, reAckRequired, timestampUTC, dueDate, overdue, revision. Every receipt first, then every outstanding reader and unresolved group.
Per-user record (Pro), CSV: accountId, displayName, pageId, pageTitle, spaceId, status, version, latestVersion, renewal, timestampUTC, dueDate, overdue.
Training matrix (Pro), Excel or PDF, columns Person, Account ID, Page, Space, Required via, Status, Version, Acknowledged (UTC), Due.
Acknowledgement certificate (Pro), PDF per page version: every signature on the version (name, UTC time, version, meaning, PIN, content SHA-256, quiz score), approvals of the version, outstanding readers with due dates, unresolved groups, the log verdict and chain head.
Audit evidence pack (Pro), PDF for many pages (building stops after about 18 seconds and names the pages not reached; a pack over about 3 MB is refused).
Course completion certificate (Pro), PDF per person: per page the version, UTC time, meaning, PIN mark, content SHA-256.

All hash-chained logs detect changes; they do not prevent every change. Uninstalling an app deletes its stored data, so export what you need to keep, and archive the chain heads outside Atlassian.

ISO/IEC 27001:2022 Annex A

Control	What you need to show (our paraphrase)	App and feature	Evidence it produces	Stays your job
5.1 Policies for information security	Policies exist, were approved by management, were published, and staff were told. Changes are reviewed and re-communicated.	Attestation Flow: named required readers per policy page, receipts bound to the page version, readers asked again after every edit (Free). Pro adds "Approve each version before readers are asked" with named approvers, any order or in order, separation of duties, revision labels (Rev 01 or Rev A), "What changed since version N" for readers, Confluence groups as readers. Approval Flow: sign-off on the policy review work item (Free).	Page evidence CSV (`version`, `signer_name`, `meaning`, `content_sha256`, `comment` for approvals); Compliance report (`versionAcknowledged`, `latestVersion`, `reAckRequired`, `revision`); acknowledgement certificate (approvals of the version listed). Approval Flow audit trail for the review ticket.	Writing the policy. Who counts as "management" and who approves. Reaching people who have no Confluence access (the apps only ask accounts that can open the page). Scheduling the policy review.
5.3 Segregation of duties	Conflicting duties are separated so one person cannot, alone, request and approve.	Approval Flow separation of duties (Free): the requirement's author cannot approve, and neither can whoever last changed who may sign; the only approver of a gating requirement cannot perform the transition; one person counts once per requirement, also through a substitute. Quorum of distinct approvers and sequential stages (Free). Attestation Flow approval of versions has the same rule (Pro). Checklist Flow "Relax a control" permission: weakening a Required item needs it, held by project administrators by default (Free shows the roles read-only; changing them is Pro).	Approval audit trail (`by`, `signer`, `set_by`, `kind`, `action`); certificate Decisions table; the validator message when a transition is refused. Checklist Flow permissions log and Approval Flow Change log show who may relax controls and every change to that.	Deciding which duties conflict. Jira and Confluence permission schemes. Jira administrators always hold the app administrator role and can change workflows: restrict and review those accounts. In Free, everyone who can open a work item can edit and tick its checklist; the history records who did it, it does not stop it.
5.4 Management responsibilities	Management requires staff to follow the policies and can show it follows up.	Attestation Flow Compliance report (Pro): outstanding and overdue readers per policy, escalation of overdue acknowledgements and reminder comments (Pro). In Free, the box on the page shows "x/y acknowledged" and the page evidence export lists who has and has not. Approval Flow: named manager sign-offs (Free).	Compliance report (`status` including OUTSTANDING, `dueDate`, `overdue`); training matrix; page evidence CSV.	Management actually acting on the list: the app shows who is outstanding, it does not show that anyone was spoken to. Disciplinary and escalation rules.
5.15 Access control and 5.18 Access rights	Access is granted only on a recorded request and approval by the resource owner, and removed when no longer needed.	Not an access control. A customer-built process: Approval Flow sign-off by the resource owner on an access request work item, with the workflow blocked until it is in (Free); approvers from a user field or groups (Pro). Checklist Flow joiner, mover and leaver checklist with Required items such as "access removed" (Free).	Approval audit trail and certificate for the request; Approval status field; Checklist history CSV (`item`, `action`, `by`, `at`). Evidence export or Audit evidence pack for all requests in a period (Pro).	Granting and removing access itself (identity provider, Atlassian admin, other systems). Periodic access reviews: the apps have no recertification feature. Proving that access in other tools matches the ticket.
5.19 Information security in supplier relationships and 5.22 Monitoring, review and change management of supplier services	Suppliers are assessed and approved before use, reviewed on a schedule, and changes in their services are handled.	A customer-built process: supplier onboarding and renewal work items with a Checklist Flow checklist (for example questionnaire received, contract clauses reviewed, owner named) and an Approval Flow sign-off (Free). Staff acknowledgement of a supplier-conduct policy in Attestation Flow.	Checklist history CSV; Approval audit trail; Evidence export for all supplier tickets (Pro).	The supplier register, the assessment itself, contract terms, and reviewing the supplier's own evidence. The apps hold no supplier data.
5.24 Incident management planning and preparation, 5.26 Response to information security incidents and 5.27 Learning from information security incidents	A defined incident process exists, staff know it, incidents are handled and reviewed to learn from them.	Attestation Flow acknowledgement of the incident response runbook (Free; a policy pack for an incident response runbook is a starting point). Checklist Flow response checklist on the incident work item with Required items (contained, evidence preserved, stakeholders told), blocking closure (Free). Approval Flow sign-off on the post-incident review (Free).	Page evidence CSV for the runbook version; Checklist history CSV with `hours_to_check` on checked rows; Approval audit trail.	Detecting incidents, classifying them, the incident record itself, regulator and customer notification and its deadlines, root-cause work.
5.36 Compliance with policies, rules and standards for information security	Staff and systems follow the policies; adherence is reviewed.	Attestation Flow shows that people confirmed the current policy version (Compliance report, Pro; page evidence export, Free). Checklist Flow and Approval Flow show that a defined step was recorded on each work item (DoD Health, Pro, lists open Required items).	Compliance report; DoD Health report; Item states export; Approval health CSV.	Checking that behaviour matches the policy, technical checks of systems, internal audit, corrective action. A confirmation of reading is not proof of following.
5.37 Documented operating procedures	Procedures are documented, current, available to those who need them, and changes are controlled.	Attestation Flow on the procedure or runbook page: readers confirm each version, "What changed since version N" (Pro), approval of each version (Pro). Checklist Flow: the procedure as a template with Required steps; five library templates in Free (including Release readiness, Code review, Bug fix verification), more in Pro.	Page evidence CSV; certificate; Checklist history per run of the procedure (the executed instance, with who ticked each step and when).	Writing and maintaining the procedure, keeping it correct, access to the page for the people who need it.
6.3 Information security awareness, education and training	Staff receive awareness and training appropriate to their role, on a regular basis, with a record.	Attestation Flow: read-and-understood receipts per policy (Free). Pro: questions before confirming (up to 10 per page, pass mark), minimum reading time, re-acknowledgement window of 30 to 730 days, courses of up to 50 pages with a completion certificate, training matrix.	Training matrix (Excel, PDF); per-user record CSV (`status`, `version`, `renewal`, `timestampUTC`, `dueDate`); course completion certificate; page evidence CSV `quiz` column (questions asked, answered correctly).	The training content and skills beyond reading a page (phishing exercises, role-specific training, external courses). Staff without Confluence access. Policy pack quiz answers are the same on every site that uses a pack: change them if the quiz must really test readers. We have not shown quizzes, reading time or courses live on our public demo; test them on your site first.
8.25 Secure development life cycle, 8.28 Secure coding and 8.29 Security testing in development and acceptance	Development follows a defined secure life cycle: reviews, secure coding practice, security testing before acceptance.	Checklist Flow: Definition of Done, code review and bug fix verification checklists with Required items (such as "peer review done", "security tests passed"), blocking the Done transition (Free). Approval Flow: a Security review sign-off before release (the sample policy has one), by someone other than the author (Free). Release readiness go / no-go per fix version (Pro).	Checklist history CSV; Item states export; go / no-go PDF; Approval audit trail and certificate. The Approval evidence pack CSV carries `cf_dod_met`, `cf_open_required`, `cf_done`, `cf_total` and `cf_chain_head` next to the approval, so one row shows both.	The development practices, the code review, the tests and their tools (SAST, DAST, dependency scans), and their results. The apps record that a person confirmed the step; they do not run or check it. An app cannot block the release of a Jira version (an Atlassian limit), so gate the transition of the work item.
8.32 Change management	Changes to systems follow a defined process: assessed, approved, tested, recorded.	Approval Flow validator on the change transition (Free): required sign-offs, named approvers, quorum, stages (CAB), requester cannot approve (separation of duties). Checklist Flow validator (Free): required items such as test evidence, rollback plan, communication, post-implementation review. Pro makes the gate harder to skip: policy auto-apply by issue type, approval rules and transition gates, "block when the checklist is missing", auto-apply template by work type, due dates and reminders. Release readiness (Pro).	Approval audit trail, certificate, Approval health CSV, Evidence export (JQL) and Audit evidence pack for a period (Pro); Checklist history CSV, Evidence export, Item states export, go / no-go PDF (Pro). Approval status field in JQL to list changes that are not approved.	The change policy: classes of change, risk assessment, emergency changes, who sits on the CAB. Changes made outside Jira (cloud consoles, infrastructure as code, direct access). Who may edit workflows. In Free, a work item with no requirements or no checklist is never blocked, so a change that nobody set up passes the gate; Pro auto-apply, rules and "block when missing" close most of that, and a JQL check for changes without an approval covers the rest.

Left out on purpose because the apps do not help in any real way: 5.2, 5.9, 5.35, 6.5, 8.24, 8.26 and 8.27 (see "What the apps do not cover").

NIS2 Article 21(2)

Source text: Directive (EU) 2022/2555, Official Journal, https://eur-lex.europa.eu/eli/dir/2022/2555/oj . The text below was read from the Publications Office copy of the same act (https://publications.europa.eu/resource/celex/32022L2555) because the EUR-Lex page does not serve its text to scripts. Article 21(2), lead-in:

The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following:

The points we map, quoted exactly:

(a) "policies on risk analysis and information system security;"
(b) "incident handling;"
(d) "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;"
(e) "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;"
(f) "policies and procedures to assess the effectiveness of cybersecurity risk-management measures;"
(g) "basic cyber hygiene practices and cybersecurity training;"
(i) "human resources security, access control policies and asset management;"

Article 21(2) point	What you need to show (our paraphrase)	App and feature	Evidence it produces	Stays your job
(a) policies on risk analysis and information system security	Written policies exist, were approved, and the people they apply to have seen the current version. A risk analysis was done and signed off.	Attestation Flow: policy pages with required readers, version-bound receipts, re-acknowledgement after edits (Free); approval of each version before readers are asked (Pro). Approval Flow: sign-off by named owners on the risk assessment work item (Free).	Page evidence CSV; Compliance report and certificate (Pro); Approval audit trail and certificate.	The risk analysis method and its content, the risk register, the policy text. The apps record approval and acknowledgement, not the quality of the analysis.
(b) incident handling	A defined incident process, trained staff, handled incidents with a record, review afterwards.	Same as ISO 5.24, 5.26, 5.27: runbook acknowledgement (Attestation Flow), response checklist with Required items (Checklist Flow), post-incident review sign-off (Approval Flow).	Checklist history (`hours_to_check` on checked rows shows the time from the item being created to the tick); Approval audit trail; page evidence CSV for the runbook.	Detection, triage, the early warning within 24 hours and the notification within 72 hours that Article 23 asks for, communication to authorities and customers. The apps have no incident register and do not notify anyone outside Atlassian.
(d) supply chain security	Direct suppliers and service providers are assessed and approved, and the assessment is recorded and repeated.	A customer-built process on supplier work items: Checklist Flow checklist of assessment steps and Approval Flow sign-off (Free); Evidence export for all supplier tickets (Pro).	Checklist history CSV; Approval audit trail; Evidence export (JQL) or Audit evidence pack for the set of supplier tickets.	The supplier register, the assessment criteria (including the points Article 21(3) names), contract clauses, monitoring suppliers. The apps record that your process ran; they hold no supplier data and assess nothing.
(e) security in acquisition, development and maintenance, including vulnerability handling	New systems and changes are assessed for security before going live; vulnerabilities are handled and fixed in a controlled way.	Same as ISO 8.25, 8.28, 8.29, 8.32: change gates with approval and checklists, Definition of Done, Bug fix verification and Release readiness checklists.	Approval audit trail and evidence pack; Checklist history, Item states export, go / no-go PDF (Pro).	Vulnerability scanning, triage and disclosure handling, the secure development practices, the tests. The apps do not import scanner results.
(f) policies and procedures to assess the effectiveness of measures	You assess, on a schedule, whether the measures work, and keep the record and the follow-up.	Narrow help only: the review is a recurring work item with a Required checklist and an Approval Flow sign-off by the reviewer (Free). Process figures: Approval health and DoD Health (Pro), the Approvals overview and Definition of Done health gadgets (Pro).	Approval audit trail for the review; Checklist history; Approval health CSV (`status`, `overdue`); Compliance report (open and overdue acknowledgements).	Everything that decides effectiveness: tests, audits, metrics of the security measures. These reports measure whether your process steps were done on time, not whether your security works.
(g) basic cyber hygiene practices and cybersecurity training	Staff learn and confirm basic practices, regularly; records of who and when.	Attestation Flow: acceptable use and hygiene policies with receipts per version (Free); questions before confirming, re-acknowledgement window of 30 to 730 days, courses, training matrix (Pro). Checklist Flow: onboarding checklist for new starters (Free).	Training matrix; per-user record CSV; Compliance report; course completion certificate; page evidence CSV.	The training content, role-specific and management training, the practice itself (updates, passwords, backups). Staff and contractors without Confluence accounts.
(i) human resources security, access control policies and asset management	Joiners and leavers are handled in a defined way, access is approved and removed, staff accepted the rules. Assets are known.	Checklist Flow joiner, mover and leaver checklists with Required items, blocking the HR or IT ticket from closing (Free). Approval Flow approval of access requests by the resource owner (Free). Attestation Flow acknowledgement of the access control and acceptable use policies.	Checklist history CSV; Approval audit trail; Compliance report and page evidence CSV.	The access control policy and its technical enforcement, identity management, access reviews, background checks and HR processes. Asset management: not covered at all.

NIS2 Article 21(2) also lists (c) business continuity, (h) cryptography and (j) multi-factor authentication and secured communications. The apps do not help with these and the table leaves them out. Article 20(2), which asks for training of the members of management bodies, is outside Article 21(2); the same acknowledgement and training records can serve it, with the same limits as point (g).

What the apps do not cover

Whether anything is met or accepted by a regulator. No certificate, no SOC 2 report, no 21 CFR Part 11 or other regulatory claim. The records are evidence of what people confirmed and decided, not a ruling.
The management system. Scope, risk assessment and treatment, the Statement of Applicability, internal audit, management review, corrective action: all yours. Clauses 4 to 10 of ISO 27001 are not mapped here.
Technical controls. Access control enforcement, cryptography (ISO 8.24, NIS2 (h)), multi-factor authentication ((j)), logging and monitoring, vulnerability management, backup and recovery ((c)), network security, endpoint security. The apps run on Atlassian and add no technical safeguard to your own systems.
Asset management and supplier data. There is no asset register and no supplier register. ISO 5.9 and NIS2 (i) asset management are outside, and so is any supplier assessment beyond a ticket you build yourself ((d)).
Access recertification. No periodic access review feature.
Incident register and notification. No incident record, no authority or customer notification, no deadline tracking.
Proof that the work was done. A tick, a sign-off or an acknowledgement is a person's statement. The apps cannot check a scan, a test run or a review. An AI agent cannot approve or acknowledge anything in these apps.
Work outside Jira and Confluence. A gate protects only the transitions that go through the validator. Changes in a cloud console, a repository or a database are not seen. Phone apps do not show Forge apps (use the phone browser).
People without accounts. Required readers and approvers need Atlassian accounts that can open the item. A named reader who is deactivated stays outstanding.
Retention. The apps keep their data while installed. Uninstalling deletes it. The Confluence reminder and escalation comments are normal comments and stay until you delete them.
Not shown live, so not relied on above: periodic review of policy pages, break-glass override, the AI agent approval gate and the Rovo agent policy tools, customer portal approval by a portal-only customer, and the authenticator-code option for signing. If you use any of them, test it on your site first.
Known display limits. PDF reports lose accents on letters such as the Polish ones (CSV and Excel keep the exact text). A content checksum that no longer matches means the stored content changed or Confluence re-saved the version; it is not proof of tampering.

How to hand this to your auditor

Give the auditor this page and your own scoping first. Say which controls and which Article 21(2) points you rely on these apps for, in your Statement of Applicability or equivalent. Use the "Stays your job" column as your own list of what you must still evidence.
Fix the period and the population. Decide the audit window and the set of work items or pages (a JQL query, a space). Write the query into your evidence note so the auditor can re-run it.
Export, do not screenshot. Take the exports named above: audit trail CSV or Evidence export or Audit evidence pack (Approval Flow), History export or Evidence export (Checklist Flow), page evidence CSV, Compliance report and training matrix (Attestation Flow). Name each file with date, query and who exported it. Exports show only what the person exporting may see in Jira or Confluence, so export with an account that can see the whole population, and read the notes about hidden items.
Record the chain heads. Each export prints a chain head ("number:hash", or block number and hash). Keep them in your own archive outside Atlassian. Later, Check anchor (Approval Flow, Attestation Flow) or Check (Checklist Flow) tells you whether that entry is still in the log unchanged. Without an archived head, a rewrite by someone with direct storage access would not show.
Let the auditor test the gate. Walk the auditor through one change or policy end to end on your site: the blocked transition with its message, the sign-off, the receipt, the export row. Show the workflow where the validator sits, the Permissions tab and the settings or change log (who may relax a control or change a setting). Sampling a few items is the usual approach; the JQL fields (approvalStatus, dodMet) help you list the exceptions yourself.
Say what the records are. Tell the auditor that a sign-off, a tick and an acknowledgement are records of what people confirmed, bound to a time and a version, in a log that shows alteration, and that the judgement whether this meets a control is the auditor's.
Keep what you need. Export before you uninstall, and keep exports as long as your retention rule for the related documents.

Sources

ISO/IEC 27001:2022 Annex A control numbers and titles, as listed by a public source: https://www.dataguard.com/iso-27001/annex-a/ (read 2026-11-01). The standard text is paywalled, so the descriptions on this page are our paraphrase. That source writes 5.37 as "Documented Operating Procedures Standards for Information Security"; we use the shorter title "Documented operating procedures", so check it against your copy. The standard itself: https://www.iso.org/standard/82875.html
Directive (EU) 2022/2555 (NIS2), Article 21(2) quoted above: https://eur-lex.europa.eu/eli/dir/2022/2555/oj . Also Article 21(3), Article 23 and Article 20(2) for the notes.
Our apps, as documented for production: Approval Flow https://marketplace.atlassian.com/apps/1065963381 , Checklist Flow https://marketplace.atlassian.com/apps/1351950778 , Attestation Flow https://marketplace.atlassian.com/apps/3229049169 . Documentation: /docs/approval-flow/, /docs/checklist-flow/, /docs/attestation-flow/. Trust page: /trust/.

Last checked 1 November 2026.

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.