What we hold, and what we cannot

Zero external systems

Concessa is an Atlassian Forge app that declares no external permissions. Forge refuses an outbound call to any host not declared in the app’s manifest, so this is enforced by the platform rather than promised by us. Two further gates back it up in our own codebase: outbound calls are banned by lint, and by a static analysis rule that runs on every change.

The practical consequences:

• No external database. Governance data lives in Forge storage, inside your own Atlassian site.
• No mail transport. Notifications are Jira’s, under your own scheme.
• No analytics, telemetry or error tracking. Not disabled by configuration — impossible by construction.
• No CDN, fonts or third-party scripts in the app interface. It is Atlassian’s own components.
• No subprocessor other than Atlassian, whom you have already assessed, because you are running Jira.

What the app stores

Inside your Atlassian site, keyed to your Jira issues:

• Governance data — a summary of the change, its risk, change type, impacted service, planned window and governance status.
• Approvals — the Atlassian account ID and display name of the person asked, their role, decision and any comment.
• Freeze windows — name, dates, reason, who created them.
• The audit chain — for every action: what happened, when, and who did it.

The personal data in that list is Atlassian account IDs, display names, and whatever people write in the free-text fields — the summary of a change, an approval comment, a freeze window’s reason and an override’s reason. That is the whole of it. No email addresses, no passwords, no IP addresses.

Those free-text fields are the only place a person can put something the app did not ask for, so they are worth naming rather than glossing. They are written by agents and administrators in your own site, stored in your own site, and reproduced verbatim in the evidence export — which is the point of them, and the reason the audit trail cannot quietly drop one.

Where it lives

Wherever your Atlassian site is hosted — a region you chose with Atlassian, which we cannot override, move or copy elsewhere. Data residency is inherited from your site rather than decided by us.

What we can see

Very little, and only what Atlassian’s developer console shows us for our own app. There is no operator console, no support impersonation and no query path into customer data. The app writes log statements in one area only — publishing to Jira and its search function — and they carry issue identifiers, project keys, counts, status codes and error text, but no account identifier and no display name. If you need us to look at anything else, you show it to us.

Publishing status to Jira

Off by default for every project. When a project administrator switches it on, the app writes one property on each change issue holding its status, risk level, change type, planned dates, the number of approvals outstanding, the time it was last updated and a format version. Anyone who can browse the issue, and every app installed on your site, can read it. It holds no free text, no names and nothing from the audit chain. Switching it off removes what was published.

Permissions the app asks for

Most calls the app makes are made as the signed-in user, comments included, so Jira’s own permissions apply underneath ours and nobody can see through the app what they could not see in Jira. Five are made as the app itself. Two are reads for the access check — project role membership, and a user’s group membership — because those need rights an ordinary agent does not have, and the answer is about that very agent. The app returns only the resulting yes or no.

The other three act on the published status property and are made only where publishing is switched on: writing it, reading it back during the daily reconciliation, and removing it. They run as the app because setting an issue property needs Jira’s Edit Issues permission, which someone who may update a change in Concessa need not hold, and because the reconciliation runs with nobody present. What bounds the writes is the project switch. The reconciliation does read the property in every project set up in Concessa, since that is how it finds one to remove after publishing is switched off; it uses only the last-updated time, and only to decide whether to rewrite.

The audit chain

Each entry carries a SHA-256 hash over its own contents and the hash of the entry before it, from a genesis value derived from the project. Verification recomputes the chain and detects an altered entry, a re-pointed entry, and a removed one.

Backups

Forge storage offers app developers no backup, snapshot or point-in-time recovery. Atlassian protects the platform for their own continuity; that is not a restore path we can invoke for one installation.

Your change records are Jira issues and are covered by Jira’s own protection. For the governance metadata and audit chain, the recovery mechanism available to you is the evidence export — portable, self-verifying and readable without the app. Taking one periodically is worth building into your routine, and we would rather say so plainly than let you discover it during an incident.

Questions from a security review

Send them to support@itsm-ltd.com. Atlassian’s own attestations for the platform — SOC 2, ISO 27001 and the rest — are published in the Atlassian Trust Center and cover the infrastructure this app runs on.