Effective: 6 September 2026
Countersign ("the app") is published by Two Little Moons Consulting (ABN 49 732 400 198), of Penrith, NSW 2750, Australia, on the Atlassian Marketplace. Contact: support@twolittlemoons.com.
This policy explains what the app does with data. It matters more than most, because this app records who agreed to what, and when.
The app runs entirely on Atlassian's Forge platform, inside your own Jira site. It declares no external network access of any kind — no outbound fetch, no egress allow-list, no remote services. No data it holds is transmitted to us or to any third party, because there is nowhere for it to be transmitted to. We have no servers, no database and no copy of your data.
Read as you, with your own Jira permissions, on work items you can already see:
countersign-approvals) holding the approval status, the
account ids still to decide, the account ids that have approved, the current stage
name, the start and decision times, and counts. This is what makes approvals
searchable in ordinary JQL. It is written by the app and is visible to anyone who can
see the work item.The app never transitions, deletes or reassigns a work item, and never edits a field other than its own read-only one.
All of it is held in Atlassian's Forge storage, inside your site's own installation, in your site's data residency region. It is not aggregated across customers and it is not readable by us.
| What is stored | Why | Keyed by |
|---|---|---|
| Approval policies — stage names, approver rules (account ids, group ids, role ids, field ids), quorum rules and any per-person weights, signature settings, the statement approvers are asked to agree to, reminder and escalation settings, working-hours calendar and holiday dates | So the project approves work the way it decided | project |
| The approval record — an append-only log of every event: who started it, the policy as it stood at that moment, each stage opening with the account ids frozen onto its roster and why each person is on it, every decision with the account id, timestamp, comment and typed name, every delegation, reassignment, escalation, reminder, reset and cancellation | This is the audit trail. It is the product | work item + policy |
| A snapshot of the work item with each decision — its summary, status, type and assignee, plus any fields the project asked for, as they stood when that person decided | So "what exactly did you approve" is answerable months later | inside the record above |
| A typed signature — the name a person typed to sign off, and the statement they were shown | So a sign-off records intent, not just a click | inside the record above |
| A digest chain — a SHA-256 over each entry and the one before it | So an entry cannot be altered, removed or reordered without it showing | inside the record above |
| Out-of-office cover — an account id, the account id covering for them, and the dates | So an approval does not stall while somebody is on leave | account |
| In-app notices — the work item key and summary, the approval and stage name, and a short line of text | Forge apps cannot send email; this is one of the three ways you are told | account |
| Site settings — which field a site treats as its org chart, and whether people may set their own cover | Configuration | site |
| Operational bookkeeping — which work items in a project have an approval still waiting, which approvals exist on a work item, how far the hourly reminder job got, and which "this changed after it was approved" notices have already been sent | So reminders are not missed, not repeated, and cannot be starved by anyone outside the app | project / work item |
The app stores Atlassian account ids, and, as typed by the person themselves, the name they type to sign off. It stores comments people write with a decision, which are free text and could contain anything they choose to put there. It stores snapshots of work item fields, which are your own Jira content.
It does not store email addresses, IP addresses, browser fingerprints, usage analytics, or any identifier of its own. It sets no cookies beyond those Atlassian sets to run Jira. It does no profiling and no automated decision-making about people. The only automated decision it makes is the one you configured: whether an approval has met its quorum.
Nothing of yours, by design. We have no access to your site's Forge storage and no copy of it.
Forge writes application logs that we, as the app's publisher, can read. The app logs only its own diagnostics: the Jira REST path it called with the query string removed, the HTTP status, and the names of any fields Jira objected to. It deliberately does not log work item content, comment text, signatures, search queries or Jira's response bodies.
Approval records and their audit trails are retained for as long as the app is installed. Deleting an approval policy does not delete the approvals recorded under it — an audit trail that vanishes when somebody tidies a settings page is not an audit trail.
Uninstalling the app deletes everything. Atlassian removes a Forge app's storage when the app is uninstalled from a site; we hold no copy elsewhere, so nothing survives. The work item property and comments the app wrote to Jira remain in your Jira, because they are your Jira data — you can remove them like any other property or comment.
If you need a record removed while the app is installed, or a copy of what is held about a person, email support@twolittlemoons.com. Because everything lives in your own site, you can also extract it yourself: the audit trail exports to CSV from the work item.
None. The app uses Atlassian's Forge platform, which runs on Atlassian's infrastructure and is governed by Atlassian's own terms and privacy policy. There are no other processors, because the app makes no outbound connection to anywhere.
Material changes to this policy will be published here and noted in the app's release notes on the Atlassian Marketplace.
Two Little Moons Consulting (ABN 49 732 400 198) Penrith, NSW 2750, Australia support@twolittlemoons.com