Where your data is, and who can reach it
This page is written for the person who has to sign off on installing it. Every claim on it is meant to be checkable, and where something is a decision rather than a guarantee, it says so.
Zero external systems
Everything the app stores lives in Forge storage, inside your Atlassian tenancy. There is no database of ours, no payment provider, no mail provider, no analytics endpoint and no error-reporting service.
The app's manifest declares no external permissions at all. In Forge, an app that wants to call out has to declare where — so the absence of that block is not a promise, it is a constraint the platform enforces. A test in the codebase asserts the block stays absent, so adding one would fail the build before it could ship.
A consequence worth being clear about: we cannot see your data. Not for support, not for debugging, not with your permission — there is no mechanism. If you report a problem, we work from what you can see on your own screen.
What the app asks for
3 Jira scopes, and it uses all 3:
| Scope | What it is for |
|---|---|
read:jira-user | Turning account ids into names, and the person picker when somebody is granted access. |
read:jira-work | Asking Jira whether the person calling administers the site or a given project (this is how access is decided), reading a project's name and key so a grant record says which project it came from, and reading the key, project, status and resolution of a Jira issue linked to a control — always as the person looking, so they see only issues Jira already lets them see. |
storage:app | The app's own storage — the register, controls, evidence, the links between controls and Jira issues, documents, grants and the audit trail. |
It requests no write scope on Jira. It cannot create an issue, edit a project, or change a permission — it only ever reads.
That includes linking a control to a Jira issue. The link is a record in the app's own storage — the issue's id and key, who linked it and when (the audit entry also records the issue's project key) — and the issue itself is untouched: nothing is written to it, and unlinking removes only the app's record. The issue's status is never stored; it is read from Jira each time, as the person viewing, so someone who cannot see an issue in Jira sees only that it is not visible to them.
It stores no files
Evidence is a record of an artefact, not the artefact: a title, an owner, a review date, a description, an optional link, and the controls it covers. The review date cannot be in the future, and evidence falls due for review twelve months after it. Your policies stay in Confluence or wherever you already keep them, with the permissions and the retention they already have.
This was a decision rather than a limitation. An app holding your governance documents takes on retention, deletion, export and a data-protection conversation that a link does not.
Links are validated on the parsed protocol: http and https only,
so javascript:, data: and file: are refused rather
than rendered as something a colleague might click.
Who can reach what
Access is per person. Jira administrators administer the AIMS; everybody else holds access because a project administrator granted it, at Contribute or Read only. Until then they see an explanation and nothing else — not the register, not the controls, not even your organisation's name.
The boundary is enforced on the server, not by hiding buttons. Every operation in the app is registered with the level it requires, and that check runs before anything is read or written. A person with Read only who calls a write operation directly is refused, and there are tests that hold it to that.
The honest caveat: any project administrator on your site can admit anyone to the whole AI management system. The roles page states that in full, including what follows from it.
The audit trail cannot be edited
Control changes, classifications, evidence, links and unlinks between controls and Jira issues (with the reason given for each unlink), document generation and every grant and withdrawal of access go into one append-only feed. There is no update and no delete — not for contributors, not for your administrators, and not for us.
To be precise about what that rests on: Forge storage has no policy layer, so the guarantee is that the module writing the trail exposes only an append operation, a test pins its surface, and the file is under code ownership. That is a code convention, enforced in review and in CI. It is not the platform withholding the ability, and we would rather say that than let you assume otherwise.
Uninstalling
Uninstalling removes your site's access to the app. Atlassian keeps the app's data for 28 days and then deletes it; we hold no copy. If you reinstall and ask us within 21 days of uninstalling, we can ask Atlassian to reconnect your data to the new installation. After that it is gone, so save the documents you need first.
This page is the summary. The full document is the Cloud Security Statement, which is written in the shape a review asks for it and states plainly what we hold no certification for. The Data Processing Agreement carries the sub-processor list and the transfer terms.
Email support@itsm-ltd.com and we will answer specifics — including the parts that are decisions rather than guarantees. The 3 scopes above and the absence of external permissions are both visible in the app's manifest, which Atlassian shows you at install time.