Cloud Security Statement

AIMS-in-a-Box

• Effective date: 9 September 2026
• Last reviewed: 9 September 2026
• Version: 1.0
• Security contact: support@itsm-ltd.com

1. Purpose and summary

This statement describes the security posture of AIMS-in-a-Box (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.

The App is an ISO/IEC 42001 and EU AI Act readiness workspace for Jira Service Management. It keeps an AI system register, classifies systems against the EU AI Act, tracks ISO/IEC 42001 control gaps, records evidence as references, and generates governance documents from your own data.

At a glance

2. Architecture and hosting

2.1 The App is a Forge app running on the nodejs24.x runtime. Its backend logic executes as serverless functions on compute operated by Atlassian; its user interface renders through Forge UI Kit modules within Jira. One surface — the printable audit pack — is a Forge Custom UI resource, served by Atlassian from the App’s own bundle.

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 Forge 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 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, residency and retention

3.1 Storage. All data the App persists is written to Forge hosted storage — eight custom entities in the entity store, plus a single key-value record holding the organisation profile. Storage is automatically scoped per installation by the platform; the App cannot read another tenant’s stored data. The App has no other data store of any kind.

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, Jira 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. It declares no Forge environment variables and holds no entry in the Forge encrypted variable store. There are no secrets in source code, in the App manifest, or in any repository.

3.4 Data residency — what is in scope and what is not.

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

Atlassian requires each Marketplace Partner to publish what its app treats as in-scope and out-of-scope. For this App:

In scope for data residency — everything the App stores, all of it in Forge hosted storage:

Out of scope for data residency — because the App does not store it:

• Jira issue content, comments, attachments and project configuration. The App reads none of it and stores none of it.
• User display names and avatars in the ordinary case. These are retrieved from Jira at the point of display and not retained. The two exceptions, where a name is written into a permanent record, are identified in section 3.6 and are in scope as part of that record.
• The artefacts behind evidence links. The App stores the link; it never stores, fetches or holds the file (section 4.4).
• Support correspondence and licence records. Held in our own systems, not in the App. See section 10.
• Forge platform operational logs. Produced and retained by Atlassian under Atlassian’s own arrangements.

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 Retention, and what cannot be deleted.

App data is retained for as long as the App is installed. The App has no retention window, no scheduled purge and no bulk delete, and this is deliberate rather than an oversight.

The audit trail is append-only. There is no facility to edit or delete an individual audit entry — for anyone, including a Jira site administrator and including us. An audit entry records the acting user’s Atlassian account ID, and its summary line may contain text your users typed, such as the name of an AI system or an evidence title. Two records also store a user’s display name as text rather than resolving it at display time: access-grant events in the audit trail, and the named role holders inside a generated document snapshot.

This is the control the product exists to provide — an owner who can delete a line can erase the status change made the week before an audit — and it has a consequence you should understand before you install. Erasing an individual’s details from the audit trail is not possible on a per-entry basis; it is achieved by uninstalling the App, which removes all App data. The implications under data protection law are set out in section 12 of the Privacy Policy and sections 9 and 12 of the Data Processing Agreement.

Be precise about what the append-only guarantee rests on. It is a code convention, enforced by a single module being the only route into the audit store, a test that pins that module’s exported surface, and a CODEOWNERS entry that prevents the file changing without review. It is not a privilege withheld by the storage platform. That is a real guarantee, and it is worth describing accurately rather than claiming it holds “by construction”.

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

3.8 Growth. Nothing prunes the audit trail, and Forge storage is finite. We monitor this as the App is used at scale and will publish a retention position if a limit is approached. No customer data is discarded without notice.

4. Data egress

4.1 The App’s manifest declares no external egress permissions — no permissions.external block of any kind, and no Forge remotes. 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. There is no HTTP client library among the App’s dependencies.

4.2 No analytics, telemetry or error reporting. The App sends nothing anywhere. It has no analytics facility, no telemetry, no third-party tracking, no error reporter, and — unlike many Forge apps — it does not even record aggregated usage counts into its own storage. There is no metrics record among the data it stores.

For completeness, because “counts” appear on screen: two pages display totals such as the number of registered systems or the number of high-risk systems. These are calculated at the moment of reading from your own records, returned directly to the screen of the person who asked, and never stored, never aggregated over time, and never transmitted. They are a view of your data, not a measurement of your usage.

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.

We state this plainly because the App is a tool for governing your AI. It contains none of its own. Its classification and scoring engines are deterministic rules, written down and reviewable.

4.4 Evidence holds no bytes. Evidence in this App is a reference — a title, a description, an owner, a review date, an optional link, and the controls it covers. The App never stores an uploaded file, and never fetches the document behind a link. Links are validated on the parsed protocol and only http and https are accepted, so javascript:, data: and file: URLs are refused. A link is rendered for a person to click; following it takes them out of Jira to a location you control.

5. Permissions and least privilege

5.1 The App requests three OAuth 2.0 scopes and no others. These match the scopes justified on the Marketplace Privacy & Security tab. They are the classic Jira scopes — Atlassian’s own guidance is to declare classic scopes over their granular, Beta equivalents where both cover the same call, which is the case for every endpoint below.

5.2 How the App calls Jira. The App makes exactly four Jira REST calls, all of them read-only GET requests made as the acting user (asUser()), from a single module. It therefore cannot see anything the person using it could not see themselves.

• The App never uses asApp(). It holds no app-level authority over your Jira data at any point.
• The App makes no write call to Jira. It creates, edits, transitions and comments on nothing. It holds no write scope, so a write would be refused by the platform even if one were attempted.
• The App runs no background jobs. There is no scheduled trigger, no web trigger, no product event listener and no installation hook. Every line of code in the App runs only in response to a person opening one of its pages.

5.3 The App does not request, collect or store Atlassian passwords, API tokens or Personal Access Tokens. It uses no credentials of any kind.

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

5.5 Content Security Policy. The App’s manifest declares one CSP relaxation: content.styles: unsafe-inline. It is needed by the printable audit pack alone, whose tables carry per-column widths derived from the document being printed; those widths are data, so they are set as inline style attributes on <col> elements and cannot live in a stylesheet.

The relaxation covers styles only. There is no scripts entry and none will be added. The audit pack builds every node with createElement and textContent; innerHTML appears nowhere in it, so no markup or script contained in customer-authored text can reach the DOM. Everything else on that page is in a static stylesheet shipped with the App.

6. Access control — yours, and ours

6.1 Our access to your data

6.1.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. We cannot browse, query or export the contents of your Atlassian site or the App’s stored data.

6.1.2 The only way we see your data is if you send it to us — for example a screenshot or an exported document 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.1.3 Access to our own systems (source control, the Atlassian developer console, the 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.1.4 Personnel are subject to written confidentiality obligations and receive security awareness training annually.

6.2 How the App decides who sees what

This matters more for this App than for most, because it holds a single AI governance record for the whole Jira site. We describe the model in full rather than summarising it.

6.2.1 One AIMS per site. There is a single AI Management System per Jira site, not one per project.

6.2.2 Every endpoint is guarded. Every one of the App’s resolver endpoints is registered through a single guard with a required access level — view, edit, administer, or open. The level is fixed at registration and a handler cannot choose its own. A test pins the complete table of endpoints and levels, so changing the security boundary cannot happen quietly.

6.2.3 Authority always comes from the platform, never from the request. The account identifier comes from the Forge invocation context. Site administration and project administration come from Jira’s mypermissions response. The project a settings page acts on comes from the Forge extension context, never from the request body — so knowing a project key does not let anyone grant themselves access to it.

6.2.4 Who may grant access. A Jira site administrator administers the AIMS with no grant required. Beyond that, access is granted by Jira project administrators, who may issue one of two levels to a user: Read only or Contribute. Nobody can grant access to themselves.

6.2.5 A consequence you should weigh before installing. Because a grant is issued by any project administrator and the AIMS is site-wide, an administrator of any single project on your site can admit a person to the whole AI Management System. If the governance record is sensitive relative to how widely project administration is delegated on your site, review who holds it before you install. Every grant and revocation is written to the audit trail.

6.2.6 The honest architectural statement. Forge has no equivalent of database row-level security. App storage belongs to the App, so every read and write runs with the App’s own authority, and the separation between what one user may see and what another may see is enforced in the App’s code at the endpoint boundary — not by the storage platform. We say this plainly because a security statement claiming the storage layer enforces isolation would be false. The controls that make the boundary trustworthy are the ones in 6.2.2 and 6.2.3, together with the review requirements in section 7.

6.2.7 The interface predicts the boundary; it is not the boundary. Hiding a control from someone who may not use it is good manners. The refusal happens at the endpoint.

7. Secure development

7.1 Source code is held in a private repository. A CODEOWNERS file marks the security boundary (the access rules, the endpoint guard, the identity module and their tests), the storage schema, and the approved governance content, so that a change to any of them is routed for review.

7.2 Continuous integration. Every push to an integration branch and every pull request runs the checks below, and a failure in any of them fails the build. The dependency scan also runs weekly without a push, so an advisory published against a dependency nobody has changed still surfaces.

• Secret scanning with gitleaks, using the full upstream ruleset with no allowlist entries, over every file in the repository and every commit since the App was rebuilt on Atlassian Forge. The commits before that point belong to a retired predecessor product that shares the repository’s history; they were scanned in full once, on 10 September 2026, and nothing it reported was a credential.
• Static application security testing with Semgrep, using its published JavaScript, TypeScript, React and secrets rulesets.
• Dependency scanning of both the App’s and the website’s locked dependency trees against the published advisory database, failing on an advisory of any severity, in production and development dependencies alike.
• Manifest validation against the rules Atlassian’s own tooling applies before it will deploy an app.
• Linting (ESLint) and type checking (TypeScript in strict mode, with unchecked index access enabled), covering the application, its tests and the audit pack.
• The test suite with coverage thresholds enforced. The pure domain logic — the scoring, classification, catalogue and document engines — is gated at 100% of lines, functions and statements and 95% of branches. The codebase as a whole is gated at 90% and 85%.
• A build of the audit pack, so a release cannot ship a stale or missing bundle.
• Commit message linting on pull requests.

7.3 Dependencies. The App has six runtime dependencies: five Atlassian Forge packages and React. It ships no HTTP client, no database driver, no template engine and no document-generation library. Dependency updates are raised automatically each week by Dependabot across both the npm and GitHub Actions ecosystems. The Node.js runtime is pinned to version 24 consistently in the runtime manifest, the package manifest and the CI configuration, and is not end-of-life.

The dependency scan in 7.2 is the gate: it fails the build on any published advisory, at any severity, in either dependency tree, and a failure is resolved by upgrading or replacing the package rather than by relaxing the threshold. We review the weekly dependency pull requests and apply security updates ahead of feature work.

7.4 Input handling. All input is validated at the endpoint boundary before it reaches the domain logic, including length limits and protocol validation on customer-supplied links. Output is encoded by construction: the UI Kit surfaces are rendered by Atlassian’s own components, and the one Custom UI page builds every node with createElement and textContent rather than innerHTML.

7.5 The App is designed not to write personal data into application logs, in line with Atlassian’s mandatory security requirements for cloud apps. The App emits a single diagnostic log line, on the unexpected-error path only; ordinary refusals and validation failures do not reach it. The message returned to the user’s browser carries no internal detail.

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

7.7 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 Marketplace apps, measured from triage:

These figures reflect Atlassian’s published cloud-app timeframes. Atlassian revises its security requirements for cloud apps periodically — most recently in February 2026 — and where this statement describes an Atlassian policy, the Atlassian source is authoritative. We review these figures at each annual review of this statement.

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. We do not hold ISO/IEC 42001 certification either — a point worth making explicitly, given what this App is for.

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.

9.1 Runs on Atlassian. Atlassian applies the Runs on Atlassian badge automatically to apps that use only Atlassian-hosted compute and storage, declare no egress, and support data residency matching the host product. This App meets those conditions: it declares no external permissions, uses no remotes or Connect modules, and stores everything in Forge hosted storage. Where the badge appears on our Marketplace listing it has been applied by Atlassian on that basis; we do not apply for it and make no claim beyond the architecture described in sections 2 to 5.

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 application is built and operated in house; the providers that host it are listed above, both configured to United Kingdom regions.

No sub-processor other than Atlassian touches data held by the App. The other three exist only because support email has to arrive somewhere.

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

12.1 What this App is, and is not. AIMS-in-a-Box is a working aid for organising an AI management system. It does not certify compliance with ISO/IEC 42001 or the EU AI Act, it is not legal advice, and ITSM Ltd is not an accredited certification body, conformity assessment body or notified body. See section 9 of the End User Terms.

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 AIMS-in-a-Box.