Cloud Security Statement

1. Purpose and summary

This statement describes the security posture of WarrantySync (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 exactly one field ever leaves Atlassian’s infrastructure: a device serial number, sent to that device’s own manufacturer. The App is built entirely on Atlassian Forge. We operate no servers, no databases and no hosting infrastructure for it, and it makes no outbound call to any system we control. Its only external calls go to Dell, Lenovo and HP, to ask when a warranty ends, and they carry a serial number and nothing else. Most of the questions a security review would normally ask about a vendor’s hosting environment are therefore answered by Atlassian’s controls rather than ours; the questions that remain are about the egress boundary, and section 4 is written to answer them in detail.

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?	Yes — device serial numbers only, to three declared manufacturer hosts. Nothing else can. See section 4
Does any data reach systems you operate?	No. We host no part of the App and receive no customer data
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?	No. The App is not eligible for Atlassian’s data residency pinning, and serial numbers sent to a manufacturer leave your region — section 3.4
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.4
Is “Runs on Atlassian” claimed?	No, deliberately. See section 4.5
Sub-processors	Atlassian; plus our email and support systems for correspondence only. Manufacturers are independent controllers — section 10

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 Kit modules within Jira.

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 remote, no external endpoint and no web trigger, and it hosts no component of its own anywhere. There is deliberately no web trigger: an unauthenticated public URL is an attack surface the App has no use for. The absence of all four is asserted by an automated test that fails the build if any of them appears in the manifest.

2.4 The App uses Forge UI Kit and renders no custom HTML. It loads no external script, stylesheet, font, image or frame, and uses no content delivery network. Its manifest declares no client-side egress of any kind.

2.5 Shared responsibility. Atlassian secures the platform. We are responsible for the App’s own code, its declared scopes, its egress boundary, its data handling logic, its dependencies and its release process. You are responsible for administering user access within your Atlassian site, for deciding which manufacturers to connect and supplying the credentials, for the content your users place in your device records, 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 the custom entity store). Storage is automatically scoped per installation by the platform; the App cannot read another tenant’s stored data. The App uses no other store of any kind — its only runtime dependencies are Atlassian’s own Forge packages.

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. Calls to manufacturer APIs are made over TLS. These are platform-provided controls; we do not implement or override them.

3.3 Secrets. The manufacturer credentials your administrator enters — a Dell TechDirect client identifier and secret, a Lenovo Support API client identifier, an HP warranty API key — are held in the Forge encrypted secret store. They are write-only by construction: no resolver in the App returns a stored credential, and the settings page shows only whether a credential exists, when it was last tested and whether that test succeeded. The Dell OAuth access token the App obtains is held in the same store with a time-to-live of no more than 55 minutes. No secret is held in source code, in the App manifest, or in any repository.

3.4 Data residency. Forge hosted storage holds the App’s data within Atlassian’s infrastructure, but the App does not support Atlassian’s data residency pinning. The App declares outbound access to three manufacturer hosts as handling in-scope end-user data, and Atlassian treats an app that does so as ineligible for pinned status. Your App data is therefore not guaranteed to remain in, or to move with, a region you have pinned for your Atlassian product data. Serial numbers transmitted to a manufacturer also necessarily leave your region, because the manufacturer operates its warranty service at locations it determines; section 10 records those locations so far as they are known to us. We have not declared the manufacturer hosts as holding no in-scope data in order to obtain eligibility, because that would be untrue.

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 published platform deletion processes for Forge apps. We retain no copy. Section 12 of the Data Processing Agreement sets out what the App retains while it is installed, which is a function of its code rather than of the platform.

4. Data egress — the detail

This is the section a security reviewer should read first.

4.1 What is declared. The App’s manifest declares three external hosts, all backend-only:

Host	Manufacturer	Purpose
apigtwb2c.us.dell.com	Dell Inc.	OAuth token exchange, then warranty lookup by service tag
supportapi.lenovo.com	Lenovo Group Limited	Warranty lookup by serial
css.api.hp.com	HP Inc.	Warranty lookup by serial

The Forge platform blocks outbound traffic to any host not on that list, and Atlassian reviews declared egress at app approval. All three are declared in scope for end-user data, because a serial identifies a device in your estate and, where that device is assigned to a person, may itself be personal data. We declared that deliberately rather than take the more flattering option; section 4.5 explains what it costs us.

4.2 What is sent. A device serial number, and the credential you supplied for that manufacturer. Nothing else. Specifically, no device name, no user, no Atlassian account identifier, no issue key, no issue content and no configuration value can reach a manufacturer.

This is a structural property, not a policy. The manufacturer adapters accept an array of serial numbers and nothing else; there is no parameter through which anything further could be passed. An automated architecture test asserts that the set of hosts in the manifest and the set of adapters in the code correspond in both directions, and fails the build if they diverge — so a new host cannot be added without an adapter, and an adapter cannot call a host that was never declared and reviewed.

Your credential goes only to the party that issued it: the Dell client identifier and secret are sent to Dell at token exchange, the Lenovo client identifier as a header to Lenovo, the HP key as a bearer token to HP.

4.3 When it is sent. Only for a manufacturer you have connected. A manufacturer for which no credential is stored is never contacted — the App skips it and records the device as not synced. Before you connect anything, the App runs in pre-scan mode, which counts your estate and makes no external call at all. Lookups are batched, paced against a configurable per-minute budget, and run once per day at an hour you choose.

4.4 No telemetry, and no artificial intelligence. The App sends nothing to us. It contains no analytics, no beacon, no error reporting, no crash reporting and no third-party SDK of any kind; it writes no application logs of its own. It contains no AI or machine learning feature and makes no call 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 a contractual undertaking in clause 4.5 of the Data Processing Agreement. Our only feedback mechanism is a mailto: link in the App’s footer, which composes an email you choose whether to send.

4.5 “Runs on Atlassian” is deliberately not claimed. That badge requires an app to make no non-analytics egress, and warranty lookup is egress. We could have declared our hosts out of scope for end-user data and become eligible; we did not, because a serial number sent to a third party is exactly the kind of disclosure the declaration exists to surface. Saying so plainly seemed better than implying a certification the App cannot hold. If Atlassian later ships a mediated-egress mechanism, we will revisit it.

5. Permissions and least privilege

5.1 The App requests nine OAuth 2.0 scopes:

Scope	Why it is needed
read:jira-work	Reads the Jira issues that represent hardware when the Jira-issues source is in use — searching them by JQL, and reading the mapped serial, model and warranty fields. Also reads project, issue type, priority and field metadata so the settings page can offer real choices rather than free-text identifiers, and reads existing App-created issues by label to avoid raising a duplicate
write:jira-work	Writes exactly two things: the warranty end date into the single field you map, and the expiry issues the App raises. It sets no reporter, adds no comment, and creates no custom field
read:cmdb-object:jira	Reads JSM Assets objects when the Assets source is in use — the device records themselves, retrieved by AQL and by identifier
write:cmdb-object:jira	Writes the warranty end date back into the single Assets attribute you map. Nothing else is written to Assets
read:cmdb-schema:jira	Lists Assets object schemas so the settings page can offer them for selection during mapping
read:cmdb-type:jira	Lists the object types within the chosen schema, for the same reason
read:cmdb-attribute:jira	Reads the attribute definitions of the chosen object type, so serial, model and warranty attributes can be mapped by name and the App can tell you what is missing instead of failing silently
read:servicedesk-request	Used for one call only: retrieving the Assets workspace identifier, to detect whether Assets is available on this site. No service desk request is read
storage:app	Stores the App’s own records — device state, sync log, settings and encrypted manufacturer credentials — in Forge hosted storage

Deliberately not requested: read:jira-user. The App never resolves a user. The optional default assignee for expiry issues is an account identifier your administrator supplies, and no issue the App creates sets a reporter. If a user picker is ever added, that scope will be added with it and not before, and adding it will require your administrator’s approval.

5.2 The App calls Atlassian APIs as the app, not as the acting user. This is the opposite of the more common pattern and we state it plainly because a reviewer will ask.

The App’s core function is a scheduled background sync: it runs once a day at an hour you configure, with no user present, across your whole estate. There is no acting user to impersonate, so Jira and Assets calls are made with app-level permissions. The single exception runs the other way: the check that decides whether the current person may change configuration is made as that person, against Jira’s own permissions endpoint, and it runs server-side on every configuration write rather than once at page load.

Two consequences follow, and you should factor both into your review:

• The App’s stored device records are not filtered by the permissions of the person viewing them. Anyone who can open the App’s dashboard can see the device list, the buckets and the CSV export for the whole estate, including serial numbers and device names, regardless of whether they could see the underlying Jira issues or Assets objects.
• Configuration — mapping, credentials, warranty rules and issue settings — is restricted to Jira site administrators, enforced server-side.

If the estate-wide visibility above is not appropriate for your site, restrict who can access the App through your Jira application access settings.

5.3 The App does not request, collect or store Atlassian passwords, API tokens or Personal Access Tokens. It does store the third-party manufacturer credentials your administrator enters, as described in section 3.3.

5.4 Any change that adds a scope, or adds a manufacturer host, 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. It transmits nothing 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 Dependency management. Dependencies are audited automatically in GitHub Actions on every pull request, every change to the main branch, and weekly, using npm audit configured to fail the build at any severity — low, moderate, high or critical. That is a deliberately zero-tolerance gate: a failure means an advisory to triage, not a threshold to raise. The weekly run means an advisory published against an unchanged dependency is still caught. Dependabot proposes dependency updates weekly and updates to the pipeline’s own actions monthly, and proposes no version until it has been public for seven days. The pipeline’s third-party actions are pinned to exact commits and its scanner image to an exact digest. The App’s runtime dependency tree is exclusively Atlassian’s own Forge packages, and the development tree is small. The Forge CLI is deliberately not a project dependency and is not installed in any build, test or scanning job, because its transitive tree carries a substantial number of published advisories with no upstream fix; the only thing those jobs need from it is manifest validation, which Atlassian’s manifest package provides at the same version with a clean audit. It is installed only on the workstation from which an authorised person deploys the App, globally and at a pinned version, because publishing a Forge app has no alternative to the CLI; so the CLI never enters the App’s own dependency tree, and the zero-tolerance audit above still runs against a clean tree. The App does not ship with dependencies carrying known vulnerabilities and does not use end-of-life Node.js runtimes.

7.3 Automated gates. The same pipeline runs, on every pull request and every change to the main branch, a strict TypeScript type-check, the full automated test suite against an enforced code-coverage threshold, manifest validation using Atlassian’s own rule engine, static analysis of the source using Semgrep’s JavaScript, TypeScript, React and secrets rulesets, and a secret scan of the repository’s entire history using gitleaks. Both scans fail the build on any finding, and the secret scan redacts what it finds so that a detected secret is not repeated in the build log. Among those tests are structural tests that fail the build if an architectural guarantee in this statement is broken — the egress allowlist diverging from the adapters, a platform import appearing outside the platform layer, a browser bundle importing a Node module, or a prohibited manifest module appearing.

7.4 All input is validated and output encoded. The CSV export neutralises spreadsheet formula injection. Error handling is governed by a fixed taxonomy: no credential, token, stack trace or raw upstream response body may reach an interface, a log line or an issue description, and upstream responses are never echoed.

7.5 The App writes no application logs of its own, so it cannot write personal data into logs, consistent with Atlassian’s mandatory security requirements for cloud apps.

7.6 Release control. 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; no automated system holds a deployment credential. Our release command runs the type-check, the automated test suite with its coverage threshold, manifest validation and the dependency audit described in 7.2 and 7.3 against the code being released, and deploys nothing if any of them fails. Production releases are made only from the tip of the protected release branch: the production release command refuses to run from a working copy with uncommitted changes, or from any commit other than the current tip of that branch as read from the source repository. An emergency release from another commit requires a stated reason and is recorded in our release log. These are procedural controls enforced by our release tooling; Atlassian’s command-line tool does not itself prevent a deployment made outside them.

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 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. 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 Manufacturer incidents. An incident within a manufacturer’s own systems is that manufacturer’s to notify to you under your agreement with it. If we become aware of one, we will tell you what we know and, where the risk warrants it, we will disable the affected manufacturer in a released version of the App. If you need to cut off a manufacturer immediately, clearing its credential in the App’s settings stops all contact with it at once.

8.6 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.7 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. They do not extend to the manufacturers, whose own certifications are a matter between you and them.

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 and manufacturer recipients

Sub-processors — parties processing data on our behalf:

Sub-processor	Purpose	Data involved	Location
Atlassian	Hosting, compute, storage; Marketplace distribution	All App data	Atlassian Forge hosting; the App does not support data residency pinning (section 3.4)
Google Ireland Limited (Google Workspace)	Support email	Support correspondence only	Ireland / EEA
Vercel Inc.	Application hosting for our support application	Support correspondence only	United Kingdom region
Supabase Inc.	Database and storage for our support application	Support correspondence only	United Kingdom region

Manufacturer recipients — independent controllers, contacted only if you have connected them:

Manufacturer	Endpoint	Data received	Location
Dell Inc.	apigtwb2c.us.dell.com	Device serial numbers; your Dell TechDirect credential	United States
Lenovo Group Limited	supportapi.lenovo.com	Device serial numbers; your Lenovo client identifier	Not published by them; a matter between you and them under your own agreement — assume outside the UK and EEA
HP Inc.	css.api.hp.com	Device serial numbers; your HP API key	Not published by them; a matter between you and them under your own agreement — assume outside the UK and EEA

Dell publishes the region for its warranty service. Lenovo and HP do not publish one for theirs, and we cannot state it on their behalf. We have no contract with any of the three: you obtain the credential and you hold the agreement, so where a manufacturer processes what it receives is governed by your relationship with that manufacturer rather than by us. Treat every manufacturer lookup as a transfer outside the UK and EEA unless that manufacturer has told you otherwise, and take it into account when deciding which manufacturers to connect. Connect none and none is contacted.

A manufacturer is not our sub-processor. You obtain the credential, you hold the agreement with that manufacturer, and it determines its own purposes for what it receives; clause 2.5 of the Data Processing Agreement explains the reasoning, and it matters practically — we have no contract with Dell, Lenovo or HP through which we could impose obligations on them or audit them for you.

Annex 3 of the Data Processing Agreement is the authoritative list for both tables. We give 30 days’ notice of changes to sub-processors, under clause 7.2 of that agreement. A new manufacturer requires a new version of the App, which Atlassian re-reviews and which your administrator approves. Our support application is built and operated in house; the providers that host it are listed above, both configured to United Kingdom regions.

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. Warranty lookups additionally depend on the manufacturers’ own APIs, which we neither operate nor control. 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://warranty.itsm-ltd.com/legal/privacy-policy and the Data Processing Agreement at https://warranty.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, as recorded in section 5.4 of the Support and Maintenance Description.

This statement is reviewed at least annually and whenever the App’s architecture materially changes — in particular, whenever a manufacturer is added or removed. 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 WarrantySync.

This document names the app WarrantySync; it appears in Jira, and everywhere else on this site, as WarrantySync. They are the same product. Previous versions are available on request from support@itsm-ltd.com.