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 services
No analytics, no error-reporting service, no CDN. Atlassian is the only provider in the app's data flow.
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, and checking that JQL's syntax when you save it (Jira returns a parse, never issue content). Reading the status of a linked issue for its badge, and its current key. Listing the projects you can browse so the app shows you only those services. Checking your Jira permissions before allowing an admin action. The daily job also reads, as the app, the current key of each linked issue and project so a link survives a move or a renamed project key, and, with publishing on, reads the status property back to decide whether to rewrite it. |
write:jira-work | Writing to the linked issue only — the app creates, edits and transitions no issues. Three things: the optional gate-decision comment, posted as you (leave the box unticked and it is never written); an early-life-support expiry notice, a comment posted as the app by the daily job; and, only if an administrator turns on Publishing to Jira, a status property on the issue, written as the app. |
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
- Reads made while you use the app run as the signed-in user, so the app can never surface issue data that Jira would not already show that person. The few reads that run as the app are listed below.
- 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.
What runs as the app, and why
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.
The same daily job posts the early-life-support reminder as the app, and reads the current key of each linked issue and project as the app, so a service still finds its issue after the issue moves, and its project after the project's key is renamed. It keeps only the key from Jira's answer, and if Jira cannot find an issue or project it changes nothing and never removes the link.
On-demand refreshes from the ELS tab run as the signed-in user, not as the app.
If an administrator turns on Publishing to Jira, the status property is also written as the app, because setting a property needs Jira's Edit Issues permission and the person saving a score or a gate decision may not have it. What it writes is a closed set of status words, dates, counts and the time the service's record last changed — no names, no account identifiers and no free text.
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 tosupport@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.
Pricing and trial details are on the Atlassian Marketplace listing.