Cloud Security Statement

1. Purpose and summary

This statement describes the security posture of Concessa (the “App”), published on the Atlassian Marketplace by ITSM Ltd (company number 17339600). It is written to support your security review and to be shared with your risk, procurement and information security teams.

The single most important fact about this App’s security model is that it holds no data outside Atlassian. The App is built entirely on Atlassian Forge. We operate no servers, no databases and no hosting infrastructure for it. The App makes no outbound calls to systems we control. As a result, most of the questions a security review would normally ask about a vendor’s hosting environment are answered by Atlassian’s own controls, not ours.

At a glance

2. Architecture and hosting

2.1 The App is a Forge app. Its backend logic executes as serverless functions on compute operated by Atlassian; its user interface renders through Forge UI modules within the Atlassian product.

2.2 We do not provision, operate, patch or monitor any infrastructure for the App. Operating system patching, runtime patching, network security, physical security, capacity and availability of the underlying platform are Atlassian’s responsibility.

2.3 The App contains no Atlassian Connect modules and no externally hosted components.

2.4 Shared responsibility. Atlassian secures the platform. We are responsible for the App’s own code, its declared scopes, its data handling logic, its dependencies and its release process. You are responsible for administering user access within your Atlassian site, for the content your users place in it, and for deciding whether the App is appropriate for your data.

3. Data storage, encryption and residency

3.1 Storage. Everything the App keeps for its own use is written to Forge hosted storage. Specifically, six entities in the Forge Custom Entity Store — change records, approvals, freeze windows, CAB meetings, CAB actions and the audit trail — and two key-value entries per Jira project holding that project’s configuration (the agent roles bound to it, the issue types nominated as change records, the CAB schedule and standing agenda, and whether the project publishes to Jira, with who last changed that and when), plus one installation-wide entry recording where the daily reconciliation (section 5.2) has reached. Storage is automatically scoped per installation by the platform; the App cannot read another tenant’s stored data.

Apart from the comments described in section 5.1, publishing to Jira is the only thing the App writes outside Forge storage, and it is off unless a project administrator switches it on. When it is on, the App writes a Jira issue property, com.itsm-ltd.concessa.state, onto each change’s issue so that changes can be found with Jira search. What the App writes into it is the change’s governance status, risk level and change type, the dates of its planned window, the number of approvals outstanding, the time the change record was last updated and a format version number — no names, no account identifiers and no free text. Jira stores it inside your own site, alongside the issue it describes, subject to whatever data residency arrangements Atlassian applies to your Jira data. The App has no way to restrict who reads it: assume that anyone who can read the issue, and any other app installed on your site, can read it. Nor can the App stop anyone else who may write issue properties from changing it. It uses what it reads back only to decide whether to rewrite — what it writes always comes from its own record — and it rewrites the property the next time the change is updated from its own panel, or when the daily reconciliation finds that the property’s last-updated time no longer matches the App’s record. Until then, a Jira search can return a status the App did not write. Section 3.6 explains how the property is removed.

The App stores nothing Jira already holds a field for. A change record is a Jira issue; what the App adds is only the governance data Jira has no field for.

3.2 Encryption. Data in Forge hosted storage is encrypted at rest by Atlassian in line with Atlassian Cloud’s data encryption standards. Data in transit between your browser, the Atlassian product and the App’s functions is protected by TLS 1.2 or above, terminated by Atlassian. These are platform-provided controls; we do not implement or override them.

3.3 Secrets. The App holds no secrets, because it has nothing to authenticate to. Every call it makes is to Atlassian’s own APIs through the Forge runtime, which supplies authorisation itself. There is no API key, no database credential and no signing secret in the App, and no secret in source code, in the App manifest or in the Forge environment variable store.

3.4 Data residency. Forge hosted storage inherits the data residency configuration of the Atlassian product it is installed alongside. Where you have pinned your Jira data to a specific Atlassian region, in-scope App data is pinned to the same region and migrated with your product data if you relocate. Data residency is administered by Atlassian; the current list of supported regions is published by Atlassian.

3.5 Backup and recovery. Atlassian Cloud backs up persistent storage for disaster recovery purposes. We hold no independent backup of your data and cannot restore data deleted through your Atlassian site or by uninstalling the App. Recovery objectives are those of the Atlassian platform; we do not offer separate RTO or RPO commitments.

3.6 Deletion. When the App is uninstalled, Forge app data is deleted by Atlassian under its platform deletion processes. We retain no copy.

The published status property described in section 3.1 is your Jira data rather than Forge app data, and the paragraph above does not cover it. The App removes it in two ways, and both work only while the App is installed:

• The daily reconciliation. Once publishing is switched off for a project, the App’s daily reconciliation removes the properties it wrote there. It examines a limited number of change records each day across every project set up in Concessa, including projects that still publish, so on a site with thousands of change records it can take weeks to reach them all.
• Remove published data. Once publishing is switched off and saved, a project administrator can remove the properties straight away, without waiting for the reconciliation, from the project’s Concessa settings page. It works while the page is open and reports how many issues it reached; press it again for any it could not. The App records who did so in the project’s audit trail before it removes anything.

Neither can reach an issue the App no longer holds a change record for, because both work from the App’s change records. The Forge platform gives the App no chance to act when it is uninstalled, so once the App is uninstalled it has no means of removing anything: before you uninstall, switch publishing off and press Remove published data in every project that has published. What the App wrote into a property left behind holds no personal data. Jira’s REST API has an operation for deleting it, DELETE /rest/api/3/issue/{issueIdOrKey}/properties/com.itsm-ltd.concessa.state, which Jira allows or refuses according to your site’s permissions.

3.7 The audit trail, and the two things it cannot do. Governance actions are recorded in an append-only, hash-chained trail, scoped per Jira project. Each entry carries a hash of the entry before it, computed over a canonical string whose field order is frozen, so an entry cannot be altered, removed or reordered without breaking verification for every entry that follows. One module in the codebase may write an entry; the entity has no update path and no delete path; and the entry is written before the change it describes, so a failure leaves a record of a change that did not happen rather than a change nobody recorded. Verification runs at export time, and the result travels with the export.

Two limits follow from this, and we would rather you heard them from us:

• Erasure of a chained field breaks verification from that entry forward. Which fields are chained, and what your options are, is set out in clause 9.4 of the Data Processing Agreement.
• There is no backup and no point-in-time recovery for App data beyond Atlassian’s own platform disaster recovery. We cannot restore an individual record. This is stated again in section 3.5 and in section 10 of the Support and Maintenance Description because it is the single most important operational limitation of the App.

4. Data egress

4.1 The App’s manifest declares no external egress permissions. The Forge platform blocks outbound network traffic to any domain not explicitly declared, and Atlassian reviews declared egress at app approval. Because the App declares none, it cannot transmit customer data to any destination outside Atlassian’s infrastructure.

4.2 This includes analytics, telemetry, error reporting and logging: none of these send customer data outside Atlassian’s platform. The App’s own diagnostic logs stay there, where we can read them for our own App (section 7.4). The App contains no analytics of any kind — no third-party tracker, no usage counter, and no store in which usage statistics could be accumulated. We have built nothing to tell us which of the App’s features you use. The nearest thing is the diagnostic logging described in section 7.4, which would show us, for our own App, whether an installation publishes to Jira and how many change records its daily reconciliation examined, published or removed.

4.3 No artificial intelligence or machine learning. The App contains no AI or machine learning features. It makes no calls to any large language model or inference service, whether Atlassian’s or a third party’s. Customer data is not used to develop, train, fine-tune or evaluate any model, by us or by anyone else. This is stated as a contractual undertaking in clause 4.4 of the Data Processing Agreement.

5. Permissions and least privilege

5.1 The App requests only the OAuth 2.0 scopes it needs. The scopes it requests are:

5.2 Acting as the user, and where the App acts as itself. Eleven of the sixteen different Jira calls the App makes run as the acting user (asUser()), including every comment, so for those the App cannot see or change anything the user could not see or change themselves. An issue they may not read simply does not appear.

Five calls run with app-level permissions (asApp()). Two are reads for the access check:

• GET /rest/api/3/project/{key}/role/{id} — reads which users and groups are in a project role.
• GET /rest/api/3/user/groups — reads the caller’s own group memberships.

The reason is the same for both: Jira requires project-administrator rights to read either, and the question being answered is whether this ordinary user is in the role that grants them access to the App. Asking as the user would fail for precisely the people the answer is about. The result is reduced to a single boolean before it leaves the access layer; it is never returned to a non-administrator. The one exception is the project settings page, which is itself administrator-gated and shows role member counts and group names — never account identifiers.

The other three act on the published status property, and are made only for publishing to Jira:

• PUT /rest/api/3/issue/{id}/properties/com.itsm-ltd.concessa.state — writes the status property.
• GET on the same property — reads it during the daily reconciliation.
• DELETE on the same property — removes it.

They run as the App for two reasons. Setting an issue property needs Jira’s Edit Issues permission, and a person who may update a change record in Concessa need not hold it; publishing as them would silently leave their changes out of Jira search. And the daily reconciliation runs with no user present. What bounds the writes is the project switch: nothing is written for a project whose administrator has not switched publishing on, and the App writes only the status values listed in section 3.1. The read is not bounded by the switch: the daily reconciliation reads the property in every project set up in Concessa, because that is how it finds a property to remove after publishing is switched off. It uses only the last-updated time, and only to decide whether to rewrite; what it writes always comes from its own record.

One scheduled job, and no other background work. The App’s manifest declares one scheduled trigger: a daily reconciliation that keeps published status properties in step with the App’s records and removes them once publishing is switched off. It declares no web trigger, no product-event handler and no other background job. Otherwise the App runs only when a user opens one of its three Jira surfaces or acts within them, or when a Jira search uses its search function, concessaInFreezeWindow. When Jira calls it, the App makes the function’s Jira calls as the user Jira identifies for the call, never as itself, and first checks that that user may browse the project. The App returns a search clause built from that project’s freeze windows — an answer about a project, not about any person — and Jira decides which issues each searcher sees. Jira does not call the function for every search that uses it. Atlassian documents that Jira keeps a function’s answer and reuses it for anyone’s search that passes the same project key, until the answer has gone unused for seven days. The browse check therefore runs for the person whose search led Jira to call the function, and not again for the people whose searches reuse its answer, whichever way the check went. What stops a searcher seeing an issue they could not otherwise find is Jira’s own permission check on the results, which applies to every search. The App does not control when Jira calls the function, or how long Jira keeps an answer. An answer Jira has kept does not follow changes to freeze windows. The App has no way to refresh it, so while Jira keeps serving an answer, a search that uses concessaInFreezeWindow can show a project’s freeze windows as they were when Jira last called the function, and a window declared or removed since is not reflected. The status published on each issue, which searches such as concessaStatus = "freeze_conflict" read, is not kept in this way and follows each change as it is saved.

5.3 The App does not request, collect or store Atlassian passwords, API tokens or Personal Access Tokens.

5.4 Any change that adds a scope requires your site administrator’s explicit approval before the new version is installed.

6. Access control and our access to your data

6.1 We have no routine technical means of accessing your data. The App exposes no administrative back door, no support console and no data export facility to us. What we can see of an installation is limited to what the Forge developer console shows us for our own App, including the logs described in section 7.4.

6.2 Beyond those logs, the only way we see your data is if you send it to us — for example a screenshot, log extract or exported record attached to a support email. We ask customers not to send more than is necessary to diagnose an issue, and we handle such material in accordance with our Privacy Policy.

6.3 Access to our own systems (source control, Atlassian developer console, support inbox) is restricted to named personnel, protected by multi-factor authentication, granted on a least-privilege basis, reviewed quarterly and revoked on the day a person leaves.

6.4 Personnel are subject to written confidentiality obligations and receive security awareness training annually.

7. Secure development

7.1 Source code is held in a private repository. The release branch is protected: it cannot be deleted or force-pushed, changes reach it only through a pull request, and the automated checks in section 7.2 and 7.3 must pass before one can be merged. ITSM Ltd is a single-person company, so no claim is made that a second person reviews each change — the gate is the pull request and the checks, not a second pair of eyes we do not have.

7.2 Dependencies are scanned automatically for known vulnerabilities using npm audit, wrapped in a gate that runs in GitHub Actions on every pull request into the release branch, on every push to it, and on a nightly schedule. The production dependency tree and the development tree are audited separately, so a build-tool advisory is never confused with one that reaches your data. The build fails on any high or critical finding in either tree. The App does not ship with dependencies carrying known critical or high-severity vulnerabilities, and does not use end-of-life Node.js runtimes.

An advisory that genuinely cannot be remediated — because it sits inside a dependency whose own lockfile we cannot reach, for instance — is not silenced. It is recorded in a version-controlled exception register with the advisory, a written reason, a named owner and an expiry date, and an expired exception fails the build. The register is reviewed at each release. We would rather carry a visible, dated exception than a green build that means nothing.

7.3 Static analysis and secret scanning run in the build pipeline on every pull request into the release branch, on every push to it, and nightly. Alongside the standard rule sets, we maintain three custom static-analysis rules specific to this App’s security model, each of which fails the build: audit entries may be appended only through the single service permitted to write them; no code may mutate or delete an audit entry; and no code may introduce an outbound network call, in any form, anywhere in the App. The third of these is what stops the guarantee in section 4 being eroded by a well-meaning change.

Every resolver validates its payload against a schema at the boundary, and output is encoded to guard against injection and cross-site scripting.

7.4 The App writes log statements in one area only: publishing to Jira and its search function. Every other part of the App — the governance panel, approvals, freeze windows, the change calendar, the CAB workbench and the evidence export — contains no logging call. The publishing lines exist so that we can tell a publication that failed, or a search the App refused to answer, from one that simply had nothing to do. They carry issue identifiers, project keys, counts, HTTP status codes from Jira and error text, and they are built to carry no account identifier and no display name, in line with Atlassian’s mandatory security requirements for cloud apps. The daily reconciliation writes one line of counts every day, whether or not any project publishes. The search function’s lines can also record text the person searching typed: when the function refuses to answer, the project key it was given; and when it cannot find its argument at all, the first 200 characters of the request Jira sent it. A further caveat, stated for completeness: where a call to Jira fails, the error the platform surfaces includes up to 300 characters of Jira’s own response body, which for a failed issue read could include issue field content. All of this is visible to us only through the Forge developer console for our own app, and only for the installation that produced it.

7.5 Development, staging and production Forge environments are separated. There is no automated deployment: no workflow or build service holds a credential that can deploy the App. Releases are made by the single person who operates this service, from an authorised workstation, with the Atlassian Forge CLI and one deployment credential that can reach all three environments.

A production release is made through a release script that refuses unless the working tree is clean and the commit being released is the tip of the protected release branch. A commit reaches that branch only after the checks in sections 7.2 and 7.3 have passed (section 7.1), so those checks have run on every commit released to production — at the point it was merged rather than at the point it was deployed. Development and staging releases are not guarded in this way.

One exception, stated because it is real rather than hypothetical. For an emergency release, the branch check can be overridden. The override demands a written reason, displays it before the release proceeds, and our release procedure requires it to be recorded in our release log; a release made that way is the one case in which the previous paragraph is not true of the code released. Separately, Atlassian requires certain changes — a new permission scope, an egress permission, or enabling Marketplace licensing — to be acknowledged as a major version before the platform will accept them. That acknowledgement is given by the same person, knowingly, at release, and is never automatic.

7.6 The App participates in Atlassian Ecoscanner, Atlassian’s automated security scanning of Marketplace apps, and undergoes Atlassian’s app and partner security review as part of listing and version approval.

8. Vulnerability management and incident response

8.1 Reporting a vulnerability. Report suspected vulnerabilities to support@itsm-ltd.com. We acknowledge reports within 2 business days and will keep you informed of progress. We ask that you allow us a reasonable period to remediate before public disclosure, and we will not pursue researchers acting in good faith.

8.2 Remediation targets. We remediate confirmed vulnerabilities in accordance with Atlassian’s Security Bug Fix Policy for cloud apps, measured from triage:

These are Atlassian’s published cloud-app timeframes, which Atlassian has stated become enforceable from 1 September 2026. We apply them now. Verify the current policy at Atlassian’s Security Bug Fix Policy page before relying on these figures.

8.3 Incident notification to Atlassian. On discovering or being notified of a security incident affecting the App, we notify Atlassian within 48 hours through Atlassian’s app security incident management process, as required by the Marketplace Partner Agreement.

8.4 Incident notification to you. Where an incident affects your data, we will notify the technical contact on your licence without undue delay and in any event within 72 hours of becoming aware, with the information available at the time, and will provide updates as the investigation progresses. Where we act as processor, we will assist you in meeting your own regulatory notification obligations.

8.5 Patch delivery. Because the App is Forge-only, minor and patch releases propagate automatically across installations without administrator action, so security fixes reach all customers shortly after we deploy them.

8.6 We maintain at least one named security contact registered with Atlassian, as required for Marketplace partners.

9. Certifications — an honest statement

We hold no independent security certification. ITSM Ltd is not certified to SOC 2, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, PCI DSS or any comparable standard, and we do not claim to be.

What we can accurately say is this: the infrastructure on which the App runs is Atlassian’s, and Atlassian holds those certifications for its cloud platform, including SOC 2 Type II, SOC 3, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, ISO/IEC 27701, PCI DSS and CSA STAR, together with FedRAMP authorisation for its Government cloud. Because the App stores no customer data outside Atlassian’s infrastructure, the controls covered by those certifications apply to the environment holding your data.

You can verify Atlassian’s certifications and obtain reports directly from Atlassian at atlassian.com/trust and customertrust.atlassian.com. We are not able to supply Atlassian’s audit reports on Atlassian’s behalf.

10. Sub-processors

There are two, and one of them is the platform you are already running. We operate no support portal, no ticketing system, no analytics service and no hosting of our own; support is conducted by email. Annex 3 of the Data Processing Agreement is the authoritative sub-processor list, giving full legal entity and location for each; this table is a summary of it. We give 30 days’ notice of changes, under clause 7.2 of that agreement.

11. Business continuity

11.1 Availability of the App depends on the Atlassian Cloud and the Forge platform, and continuity and disaster recovery for that platform are provided by Atlassian. We give no uptime commitment; see section 10 of the Support and Maintenance Description.

11.2 Our own continuity arrangements cover source code (held in a replicated cloud repository with an offline copy retained), release credentials and support access, so that we can continue to release and support the App from an alternative location.

11.3 We commit to maintaining the App actively, including publishing at least one version update within every 18-month period, in line with Atlassian’s requirements for maintained Marketplace apps.

12. Compliance

• UK GDPR and Data Protection Act 2018 — see the Privacy Policy at https://concessa.itsm-ltd.com/legal/privacy-policy and the Data Processing Agreement at https://concessa.itsm-ltd.com/legal/data-processing-agreement.
• ICO registration — registered with the Information Commissioner’s Office under number ZC207852.
• Atlassian Marketplace — we comply with the Marketplace Partner Agreement, the Atlassian Developer Terms and Atlassian’s mandatory security requirements for cloud apps.

13. Contact and updates

Security questions, questionnaires and vulnerability reports: support@itsm-ltd.com. We aim to respond to security questionnaires within 5 business days, consistent with the P4 target in the Support and Maintenance Description.

This statement is reviewed at least annually and whenever the App’s architecture materially changes. Where a change materially reduces the security commitments described here, we will give at least 30 days’ notice to the technical contact on your licence, and the change will not apply retrospectively or reduce our obligations during your then-current Subscription Term. Atlassian’s requirements, certifications and remediation timeframes change over time; where this statement describes an Atlassian control or policy, the Atlassian source is authoritative.

---

Published in accordance with the Atlassian Marketplace Partner Agreement. Read alongside the Privacy Policy, End User Terms and Support and Maintenance Description for Concessa.