Cloud Security Statement

1. Purpose and summary

This statement describes the security posture of ServiceAccord (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 keeps no store of its own. The App is built entirely on Atlassian Forge. Everything your users enter into its macros is saved by Confluence as part of the page on which the macro sits. The App requests no Atlassian permissions, calls no Atlassian or external API, and makes no outbound calls. We operate no servers, no databases and no hosting infrastructure for it. 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 providing three Confluence macros. Their user interface renders through Forge UI Kit within Confluence, in the user’s browser; viewing or editing a macro runs no server-side code. The App’s only server-side code is three export functions, which run as serverless functions on compute operated by Atlassian when a page is exported to PDF or Word and, as Atlassian documents, when an earlier page version is viewed in page history.

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, no remotes and no externally hosted components.

2.4 Shared responsibility. Atlassian secures the platform. We are responsible for the App’s own code, its declared permissions (of which there are none), its data handling logic, its dependencies and its release process. You are responsible for administering user access within your Atlassian site, for the permissions of the pages that contain the App’s macros, for the content your users place in them, and for deciding whether the App is appropriate for your data.

3. Data storage, encryption and residency

3.1 Storage. The App keeps no store of its own and does not use Forge hosted storage. Each macro’s content is saved as a single configuration value inside the Confluence page, by Confluence. It is therefore governed by the page’s permissions: anyone who can view the page can read the macro’s content, and anyone who can edit the page can change it. Macro content also appears in the page’s version history, in copies of the page, and in PDF or Word exports of it. The App does not opt its macro content into Confluence search indexing.

3.2 Encryption. Macro content is encrypted at rest by Atlassian as part of Confluence page storage, in line with Atlassian Cloud’s data encryption standards. Data in transit between your browser, Confluence 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, secrets or environment variables.

3.4 Data residency. Macro content is part of the Confluence page and so follows your Confluence data residency configuration, including any migration between regions. The export functions process content transiently on Forge compute in locations determined by Atlassian, and retain nothing. Data residency is administered by Atlassian; the current list of supported regions is published by Atlassian.

3.5 Backup and recovery. Macro content is backed up and versioned with the Confluence page, and earlier values can be recovered through Confluence page history. We hold no independent backup of your data and cannot restore data ourselves. Recovery objectives are those of the Atlassian platform; we do not offer separate RTO or RPO commitments.

3.6 Uninstallation. Uninstalling the App deletes nothing. Macro content remains in your pages; while the App is not installed, Confluence displays a placeholder in place of each of its macros. We hold no copy.

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 usage counts, analytics or telemetry of any kind, and we use no third-party analytics or tracking.

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 no OAuth 2.0 scopes. Its manifest declares an explicit empty scope list.

5.2 The App calls no Atlassian product API, either as the acting user (asUser()) or as the App (asApp()), and runs no scheduled, background or event-triggered jobs. It reads only the configuration of its own macro, which Confluence supplies to it, and the viewer’s locale, which it uses to format dates.

5.3 These properties are enforced by an automated test that runs on every change and fails the build if the manifest acquires a scope, an external permission, a remote or a trigger, or if the App’s source code calls a network, storage or product API.

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

5.5 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. The one exception is the App’s error logs, described in section 7.4.

6.2 The only other way we see your data is if you send it to us — for example a screenshot or exported page 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. Every pull request, and every push to the development, staging and main branches, runs automated checks, which also run daily: linting, strict TypeScript type-checking, the App’s unit tests, the automated test described in section 5.3, dependency vulnerability scanning, secret scanning across the repository’s full history, and static analysis. These checks do not deploy the App, and no automated system holds credentials that can deploy it.

7.2 The App’s direct runtime dependencies are Atlassian’s Forge libraries and React. We check the App’s runtime dependencies for known vulnerabilities before each production release, and the App does not ship with a runtime dependency carrying a known critical or high-severity vulnerability. The App runs on a supported Node.js runtime on Forge.

7.3 Static analysis (ESLint, Semgrep, and the TypeScript compiler in strict mode) runs on every change. All stored content enters the App through a single validation function that accepts any input and returns a valid record, and text is rendered through Atlassian UI Kit components, which do not interpret it as markup.

7.4 Logging. The App writes error messages only, never routine activity, and does not log macro content — with one narrow exception. Where a macro’s stored configuration is damaged and cannot be read, the error recorded may quote a short excerpt of it. When that happens during an export, the message reaches the App’s Forge logs, which are held by Atlassian and accessible to us through the Atlassian developer console. Atlassian provides a setting through which a site administrator can withdraw developers’ access to an app’s logs. We do not enable Forge front-end log capture, and we do not export the App’s logs outside Atlassian.

7.5 Development, staging and production Forge environments are separated. Deployments are made by an authorised person at ITSM Ltd using Atlassian’s Forge command-line tool. Our release procedure is that production releases are deployed from the main branch, after the checks in section 7.1 have passed on the commit being released and Atlassian’s Forge manifest linter has passed. Our production deployment script refuses to deploy unless the working copy has no uncommitted changes and is at the latest commit on the main branch, and it runs our automated checks before deploying. An emergency release from any other commit requires a stated reason and is recorded. The script does not prevent a deployment made without it, so the release procedure remains a control we operate rather than one the tooling alone enforces.

7.6 The App is reviewed by Atlassian as part of Marketplace listing 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 you, in the manner set out in clause 13.3 of the End User Terms, 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, and in which your data is stored, 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. Storage of macro content in Confluence is under your own agreement with Atlassian, not ours. 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://serviceaccord.itsm-ltd.com/legal/privacy-policy and the Data Processing Agreement at https://serviceaccord.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 in accordance with clause 13.3 of the End User Terms. No change applies retrospectively, and if you do not accept a change you may uninstall the App before it takes effect. 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 ServiceAccord.