Where your data is, and who can reach it

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:

It requests no write scope on Jira. It cannot create an issue, edit a project, or change a permission — it only ever reads.

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. 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, 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. What happens to the stored data on uninstall is a question we will answer from observed behaviour rather than from documentation, and until we have observed it this page will not claim anything.