Nothing leaves your Atlassian site
The whole app — interface, business logic, scheduled jobs and storage — runs on Atlassian Forge. There is no server of ours anywhere in the picture.
No egress, at all
The app declares no remote services and no external fetch permissions. There is no code path that can send your data anywhere, because the platform will not permit the network call.
Forge-hosted compute & storage
Records live in Atlassian's own storage, isolated per installation by the platform, and inherit the data residency of the host product.
No third-party processors
No analytics, no error-reporting service, no CDN, no sub-processors. There is nobody else in the data flow to assess.
Four scopes, and what each one is for
Every scope maps to a feature you can point at in the interface. There are no administrative scopes.
| Scope | Why it is needed |
|---|---|
storage:app | Storing the app's own records — services, templates, assessments, gate decisions, plans, tasks, ELS records and incident snapshots. |
read:jira-work | Counting incidents for the ELS trend with your JQL, reading the status of a linked issue for its badge, and checking your Jira permissions before allowing an admin action. |
write:jira-work | One feature only: posting the optional gate-decision comment on the linked request. Leave the box unticked and this is never used. |
read:jira-user | The user picker for task owners. Returns account ID, display name and avatar — nothing else. |
What is stored, and what is not
- Stored: the app's own transition records — service metadata, template definitions, scores and notes you type, gate decisions, plan tasks, exit criteria and daily incident counts.
- Personal data: Atlassian account IDs, plus display names captured at the moment of a gate decision or sign-off, because an audit trail that says "someone" is worthless.
- Not stored: email addresses, external identifiers, or any issue content. Incident trends store counts, never issue data.
- Not stored: credentials or secrets of any kind — the app authenticates through Forge and holds no keys.
Reads run as you
- Jira reads are made as the signed-in user, so the app can never surface issue data that Jira would not already show that person.
- Administrative actions re-check your Jira permissions server-side at the time of the action — the interface hiding a button is never the control.
- CSV exports neutralise spreadsheet formula injection and escape properly, so an exported field cannot execute in Excel.
- Issue keys and other free-text inputs are validated server-side against a strict format before they are stored or used.
One disclosure worth reading
The daily incident-trend job runs your saved JQL as the app rather than as a person, because a scheduled job has no signed-in user and the trend should not break when someone changes team.
That means the aggregate counts in an ELS trend can include issues the person configuring the query cannot see individually. The app stores and displays counts only — never issue keys, summaries or any other issue content. If that matters in your environment, scope the JQL to a project your team can already see.
On-demand refreshes from the ELS tab run as the signed-in user, not as the app.
Designed for the badge
The app is built to satisfy the Runs on Atlassian criteria — Forge-hosted compute and storage, and no data egress. Check the Marketplace listing for the current certification status, which Atlassian awards independently.
Sending your security questionnaire is welcome — write to support@itsm-ltd.com and we will complete it.
Pass the security review on the first pass
No servers to assess, no processors to list, no data leaving your tenancy.
Free for small teams · 30-day evaluation on every paid tier