Cloud Security Statement

1. Purpose and summary

This statement describes the security posture of ImproveDesk (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.

There is one way the contents of your register can reach anywhere else, and it happens only if you choose it. Where a Jira administrator allows email digests for your site (section 4.4), Jira’s own email service sends a summary of a project’s register to the people that project’s administrator names. The email is then held by the recipients’ email provider, wherever your organisation’s email is hosted. By default it carries counts and improvement references only. The App itself still makes no outbound call.

At a glance

Question	Answer
Where does the App run?	Atlassian Forge — Atlassian-operated serverless compute
Where is customer data stored?	Forge hosted storage, inside Atlassian’s cloud
Does data leave Atlassian’s infrastructure?	Not by any call the App makes: it declares no external egress domains. If a Jira administrator allows email digests, Jira’s own email delivers a register summary to the recipients chosen — counts and references by default, titles only if the administrator chooses. Off by default. See section 4.4
Do you host any part of the App?	No
Can your staff read customer data?	No, not through the App. See section 6
Is data encrypted?	Yes, in transit and at rest, by the Atlassian platform
Is data residency supported?	Yes, inherited from the host Atlassian product
Are you SOC 2 / ISO 27001 certified?	No — we are not. Atlassian’s infrastructure is. See section 9
Does the App use AI or machine learning?	No. See section 4.3
Sub-processors	Atlassian; plus our email and support systems for correspondence only

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. Its modules are Jira pages — including a site settings page, opened from Configure on the App’s entry in Manage apps, where a Jira administrator decides whether email digests are allowed — an issue panel, a Jira dashboard gadget, two scheduled functions (a daily attention sweep, which also sends email digests where they are allowed and switched on, and a weekly KPI snapshot), and an event handler subscribed to Jira issue-updated and issue-deleted events, which it uses to tidy links to deleted issues and to record issue resolutions in the App’s audit trail. The dashboard gadget shows one project’s register figures, and shows them to a person viewing the dashboard only if that person can browse the project, checked as that person each time the gadget is displayed. The project a dashboard gadget is set to is chosen by whoever can edit the dashboard and is stored by Jira as part of the dashboard, not by the App. Anyone who can view the dashboard can therefore learn which project it is set to, even where they cannot browse that project and are shown none of its figures.

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. All data the App persists is written to Forge hosted storage (the key-value store and entity store). Storage is automatically scoped per installation by the platform; the App cannot read another tenant’s stored data.

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 uses no credentials, API keys or secrets of its own: it authenticates to Atlassian APIs solely through the Forge platform’s managed authentication. Were a secret ever required, it would be held in the Forge encrypted environment variable store. No secrets are held in source code, in the App manifest, or in any repository.

3.4 Data residency. Forge hosted storage inherits the data residency configuration of the Atlassian product it is installed alongside. Where you have pinned 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.

Where an administrator has enabled publishing to Jira, the App also writes status values onto Jira issues as entity properties. Those are your Jira data rather than Forge app data, and the sentence above does not cover them. Turning publishing off removes the properties the App wrote. The Forge platform provides no uninstall hook, so once the App is uninstalled it has no means of removing them: turn publishing off before uninstalling if you want them removed. A property left behind contains a closed set of status words, dates and counts and no personal data, and you can remove it yourself at any time — the App’s documentation gives the method.

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. This is a statement about the App’s own network traffic. Where a Jira administrator allows email digests, the App asks Jira to send an email through Jira’s own mail service (section 4.4), and that email travels to the recipients’ mail servers as any other Jira notification does.

4.2 This includes analytics, telemetry, error reporting and logging: none of these send customer data to us or to a third party. The App records no analytics, telemetry or usage tracking of any kind, first-party or third-party. The weekly KPI snapshots it stores are aggregate register figures for the customer’s own dashboard trend line, held in Forge hosted storage and visible only to the customer; they are not usage analytics for us and we cannot see them.

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.

4.4 Email digests. The App can have Jira email a project’s attention digest — how many improvements are overdue, stale, due for review or without an owner — to people a project administrator names. It is off unless two people turn it on. A Jira administrator must allow email digests for the site, on the App’s site settings page; a project administrator must then switch them on for the project and name up to ten recipients, and may also send each improvement owner their own items. Turning the site setting off takes effect from the next daily run; an email Jira has already queued is not recalled.

The Jira administrator also decides what a digest may contain: counts and improvement references only (the default), or counts, references and improvement titles. A digest never contains benefit figures, names or account identifiers.

The App asks Jira to send each email separately, to one person, from an issue in the project that the project administrator chooses, and asks Jira to deliver it only to someone who can browse that project. Nothing is written to that issue. Before each send the App checks that the issue is still in the same project, and sends nothing if it has moved. The App records whether Jira accepted each email; it cannot see whether an email was delivered or read.

Your organisation can also keep the App away from particular projects altogether with Atlassian data security policies, which block apps from the projects they name.

5. Permissions and least privilege

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

Scope	Why it is needed
storage:app	Stores all App data in Atlassian-hosted Forge storage (the improvement register, the append-only audit trail, comments, per-project configuration — including, where email digests are used, the account IDs of up to ten recipients — a per-project record of the latest email digest, the site settings, weekly KPI snapshots and the scheduled-run log). The App has no external data store. Where email digests are allowed, the email itself is delivered by Jira to the recipients’ mailboxes (section 4.4).
read:jira-work	Reads the Jira issues a user links to an improvement — summary, status, issue type and assignee for the linked-issue badges and the issue panel (POST /rest/api/3/search/jql, keyed to specific issue keys) — and lists the project’s issue types (GET /rest/api/3/project/{key}) so a user can choose the type of a delivery issue. Before a link is stored, the issue is read once (GET /rest/api/3/issue/{key}?fields=project) to confirm it belongs to the same Jira project and is visible to the user making the link. Also used for the /rest/api/3/mypermissions check that decides whether the current user may browse the project or administer it. Where publishing is switched on, the App also reads back the status record it wrote to an issue (GET /rest/api/3/issue/{id}/properties/{key}), so its daily reconciliation can tell whether the record is still correct. What comes back decides only whether to rewrite it; the content written is always rebuilt from the App’s own register. Where a project sends email digests, the issue the digest is sent from is read once, as the project administrator choosing it, to confirm it belongs to the project; and before each send the App reads that issue’s project as the App (GET /rest/api/3/issue/{id}?fields=project), sending nothing if the issue has moved. Once per daily run in which a digest is sent, the App also reads the site’s address (GET /rest/api/3/serverInfo) so the email can link back to the project.
write:jira-work	Writes three things. First, a Jira delivery issue created from an improvement, when a user asks for one, posted as that user (POST /rest/api/3/issue). Second, where a project administrator has switched publishing on, a small status record on each linked issue, stored as a Jira issue entity property under the key com.itsm-ltd.improvedesk.state (PUT/DELETE /rest/api/3/issue/{id}/properties/{key}). Third, where a Jira administrator has allowed email digests and a project administrator has switched them on, an email notification queued through Jira from one issue in the project (POST /rest/api/3/issue/{id}/notify), one per recipient. This writes nothing to that issue. The App does not edit an issue’s fields, comment on an issue or transition an issue.
read:jira-user	Resolves Jira account IDs stored on improvements to display names and avatars, so owners, sponsors, comment authors and audit-trail actors are shown by name rather than as an opaque ID (read-only GET /rest/api/3/user/bulk); and finds people who can browse the project by name, for choosing an owner or sponsor (read-only GET /rest/api/3/user/viewissue/search). Both are made as the signed-in user, so Jira’s own rules decide who can be found. Only account ID, display name and avatar URL are read; only the account ID of the person chosen is stored, on the improvement, and the search text is never logged.

5.2 The App calls Atlassian product APIs as the acting user (asUser()) for everything a person asks it to do — reading and linking issues, creating a delivery issue, resolving names and choosing the issue an email digest is sent from — so for those actions the App can see and change nothing the signed-in user could not see or change themselves.

There are two exceptions, each confined to one module, and each exists for the same reason: the daily job runs on a schedule, with no signed-in user to act as.

Publishing. Where a project administrator has switched publishing on, the App writes, reads back and removes its own status record on linked Jira issues as the App itself (asApp()), and — for a link made before the App recorded Jira’s issue IDs — reads the linked issue’s project to resolve its ID. These calls reach nothing but the App’s own entity property on issues the register already links, and those issues’ project.

Email digests. Where a Jira administrator has allowed email digests and a project administrator has switched them on, the App asks Jira, as the App, to email the digest (section 4.4), reads which project the digest’s issue belongs to before each send, and reads the site’s address.

Beyond the project each reads, neither reads or writes an issue field, a comment or any Jira configuration. This boundary is enforced by an automated check over the whole source tree, run on every push, including every commit of every pull request, which fails the build if an app-level call appears in any file other than those two modules, or if the email digest’s module names any Jira endpoint other than the three above.

The App’s other scheduled job — the weekly KPI snapshot — calls no Jira APIs at all. For a project that has switched on neither publishing nor email digests, the daily job’s only Jira calls remove the App’s own status record from the issues that project’s improvements link, so that nothing published earlier is left behind; where nothing was ever published, they change nothing. It makes no email digest call at all while a Jira administrator has not allowed them.

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.

6.2 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 with branch protection and mandatory peer review before merge to the release branch.

7.2 Dependencies are scanned automatically for known vulnerabilities using npm audit in GitHub Actions, which runs on every push, including every commit of every pull request, and on a weekly schedule across both the App’s backend and its front-end package trees, with Dependabot raising weekly update pull requests for each. The build fails on any high or critical finding. The App does not ship with dependencies carrying known critical or high-severity vulnerabilities, and does not use end-of-life Node.js runtimes.

7.3 Static analysis and secret scanning run in the build pipeline. All input is validated and output encoded to guard against injection and cross-site scripting.

7.4 The App is designed not to write personal data into application logs, in line with Atlassian’s mandatory security requirements for cloud apps.

7.5 Development, staging and production Forge environments are separated. Production releases are made only from the protected branch.

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:

Severity (CVSS v3)	Target
Critical (9.0–10.0)	10 days
High (7.0–8.9)	4 weeks
Medium (4.0–6.9)	12 weeks
Low (0.1–3.9)	25 weeks

These are Atlassian’s published cloud-app timeframes, and we apply them. 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 promptly and in any event within 24 hours through Atlassian’s app security incident management process, and keep Atlassian updated at least every six hours until the incident is remediated, as Atlassian’s App Security Incident Management Guidelines require.

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

Sub-processor	Purpose	Data involved	Location
Atlassian	Hosting, compute, storage; Marketplace licensing; Jira Service Management, our support tool	All App data; and support correspondence held in our Jira Service Management	Per your data residency setting
Google Ireland Limited (Google Workspace)	Support email	Support correspondence only	Ireland / EEA

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. Our support tool is Atlassian’s Jira Service Management, so Atlassian, listed above, holds support correspondence alongside Google.

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://improvedesk.itsm-ltd.com/legal/privacy-policy and the Data Processing Agreement at https://improvedesk.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 ImproveDesk.