Cloud Security Statement

1. Purpose and summary

This statement describes the security posture of Fulfilra (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. All data the App persists is written to Forge SQL — an Atlassian-hosted relational database that the platform provisions one per installation. Cross-tenant isolation is therefore structural: the database an invocation can reach contains only that installation’s data, so no other customer’s data is present to leak. Visibility between users within an installation (a requester sees their own requests; agents see the queue; internal notes never render to a requester) is enforced by the App’s own query logic on every read; it is an App-implemented control, not a platform guarantee, and it is covered by an automated test sweep in the App’s build pipeline.

3.2 Encryption. Data in the App’s Forge SQL database 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 credentials, tokens or secrets of its own. It authenticates to Jira solely through Forge-managed app identity, and it does not request, collect or store Atlassian passwords, API tokens or Personal Access Tokens. The App ships no secret in its source or its manifest, because it has none to hold. Secret scanning runs over the repository’s entire history on every push and pull request; any finding is triaged before the build passes, and a finding accepted as dead is recorded in the repository with the reason it was accepted and the date the credential was revoked.

3.4 Data residency. The App’s Forge SQL database inherits the data residency configuration of the Jira 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 stops the App writing them. An administrator can then remove the properties already written, from the App’s settings, without waiting; the App’s daily reconciliation removes any that remain. The Forge platform provides no uninstall hook, so once the App is uninstalled it has no means of removing them — remove them before you uninstall if you want them gone. Any that remain can be deleted from each issue directly; the App’s documentation gives the method. A property left behind contains a closed set of status words, dates and counts and no personal data.

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 to us or to a third party. The App records no analytics, telemetry or usage metrics of any kind, aggregated or otherwise. We use no third-party analytics or tracking. Because the App declares no egress and stores all data in Atlassian-hosted storage, it meets the criteria for Atlassian’s Runs on Atlassian designation.

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 Which identity calls Jira. A write that a person’s action causes is made as that person (asUser()) wherever Jira grants them the permission it needs, and as the App (asApp()) only where Jira does not. The choice is made per write, per project, from a /rest/api/3/mypermissions check asked as the acting user: issue creation against Create Issues, transitions against Transition Issues, comments against Add Comments, work log entries against Work On Issues, and the due date against Schedule Issues. Where the check says the person may not, the App performs the write under its own identity and records that it did so; nothing is silently attributed to somebody who could not have done it.

The fallback to App identity exists for one population. A requester who cannot browse the Jira project — the normal condition for a Jira Service Management portal customer, who holds no Jira licence — must still be able to raise a request that results in an issue, and that issue must keep following their request afterwards. Without the fallback, the request would succeed and its issue would stand still.

A second /rest/api/3/mypermissions check, also made as the acting user, decides whether the current user administers the site, so the App can never grant an administrative surface that Jira itself would not grant that user. A failed check denies, never grants. It is made on every invocation by a licensed user; it is skipped for an unlicensed portal caller, for whom asUser() is not permitted at all and the answer is therefore already known. Skipping can only withhold administrative access, never confer it.

Reads of Jira — the project list, issue types, status and resolution names, and a linked issue’s status — are made as the App, so that what a request shows does not vary with the reader’s own project permissions.

Background execution as the App is limited to: the install-time schema setup, the handlers for inbound Jira issue and comment events (which update linked request statuses and mirror public comments), an hourly retry of pending schema migrations, a daily sweep that deletes only unreachable partial-submission rows; a daily reconciliation of the status values described in 3.6, which, for each request with a linked Jira issue, reads back the value the App itself wrote on that issue and rewrites it while publishing is enabled, or removes it once publishing is off; and, where an administrator has switched them on, a daily reminder to approvers whose approvals have waited longer than the administrator’s chosen number of days, sent through Jira’s notification API and naming only the request reference. The event handlers read Jira in two narrow cases: where the event Jira delivered omits the status information the handler needs, it reads that issue’s status rather than discarding the event; and where a comment event names the comment’s author only by account ID, it reads that author’s display name, which is stored with the mirrored comment as the Privacy Policy describes. No background job transmits customer content anywhere, and none reads Jira content beyond the events Jira delivers, those two reads, and the reconciliation’s read of the App’s own status values.

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 and pull request and on a weekly schedule across the App’s package tree and the repository’s tooling tree, with Dependabot raising weekly update pull requests for each. The build fails on any high or critical finding in a dependency the App ships with; findings confined to development tooling are surfaced by the same scans and remediated through the weekly update cycle. 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, and any finding fails the build. Every payload the App accepts is validated against a declared schema before it is acted on, and every database statement is parameterised. The App renders no HTML of its own: its entire interface is built from Atlassian’s Forge UI Kit components, which Atlassian renders, so there is no template or markup layer in the App for an injected script to reach.

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:

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

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