The vendor adapters accept a list of serial numbers and take no other argument. There is no parameter on them for a device name, an issue key or an account id, so there is nothing to leak by mistake. A test in the repository inspects every outbound request the adapters make and fails if a body or a URL contains an account id, a display name, an email address, an issue key or a summary, or if the request goes anywhere but the three hosts below.
Every function runs on Atlassian Forge, and every byte the app stores sits there too. There is no server of ours anywhere in the picture. The app does not support Atlassian’s data residency pinning: it declares egress to three manufacturer hosts, and Atlassian treats an app that does so as ineligible, so its stored data is not guaranteed to move with your site’s region. A serial number sent to a manufacturer also leaves the region by design. See the table below before you decide which manufacturers to connect.
No analytics provider, no error-reporting service, no CDN, no bundled fonts, no licensing check. Nothing sits between your site and the app.
That is narrower than “no third parties”, and the difference matters. Atlassian is a sub-processor, because it hosts all of it. Three more — Google Ireland, Vercel and Supabase — carry our support correspondence, and never touch your app data. All four are named in Annex 3 of the DPA. The three manufacturers are recipients of a lookup rather than sub-processors, and the same annex says why.
This is the complete egress allowlist, declared in the app’s manifest and shown to you at install. Forge enforces it: a connection to any other host does not fail quietly; it cannot be opened at all.
| Host | Manufacturer | Receives | Processed in | Contacted |
|---|---|---|---|---|
apigtwb2c.us.dell.com | Dell Inc. | Dell service tags | United States | Only once Dell credentials are saved |
supportapi.lenovo.com | Lenovo Group Limited | Lenovo serial numbers | Not published by Lenovo; assume outside the UK and EEA | Only once Lenovo credentials are saved |
css.api.hp.com | HP Inc. | HP serial numbers | Not published by HP; assume outside the UK and EEA | Only once HP credentials are saved |
Dell publishes where it processes a warranty lookup. Lenovo and HP do not, and we will not state it on their behalf. We hold 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 a matter between you and that manufacturer. Treat every lookup as a transfer outside the UK and EEA unless the manufacturer has told you otherwise, and weigh that when deciding which to connect. Connect none, and none is contacted.
Where a device is assigned to a named person, its serial number can identify that person indirectly, and so can be personal data under UK and EU data protection law. We say so rather than arguing otherwise: the app declares its egress as in-scope end-user data in the manifest. The manifest offers two declarations, in scope or not, and the app makes the conservative one — which is exactly what costs it the badge below.
Every scope below buys a visible feature. There are no administration scopes. The app reads and writes your data as itself; the single call it makes as the signed-in user is the one that asks Jira whether that user holds the administer permission.
| Scope | What it buys |
|---|---|
read:jira-work | Read hardware tracked as Jira work items, and search for an expiry issue that already exists before raising another. |
write:jira-work | Write the warranty end date onto the field you mapped, and create expiry issues in the project you chose. |
read:cmdb-object:jira | Read hardware objects when your device source is Jira Service Management Assets. |
write:cmdb-object:jira | Write the warranty end date back onto an Assets object, and only into the mapped attribute. |
read:cmdb-schema:jira | List your object schemas on the settings page so you can choose one. |
read:cmdb-type:jira | List the object types in that schema, so field discovery has something to propose. |
read:cmdb-attribute:jira | Read attribute names during discovery, which is how the app suggests a mapping instead of creating one. |
read:servicedesk-request | Accompany the Assets scopes; Jira Service Management requires it for API access. |
storage:app | Hold the app’s own records inside Forge: one per device, a short run log, your settings and your encrypted credentials. |
read:jira-user is deliberately not requested. The app never resolves a user. The settings can hold an account id to assign expiry issues to, though no screen sets one yet, and no issue it creates sets a reporter. The five cmdb andservicedesk scopes are only exercised if you choose Assets as your device source.
One record per device — its id, key, name, serial, manufacturer, derived status, warranty end date, service level, ship date and when it was last synced. Plus your settings, a run log of the last 100 batches, and your encrypted credentials.
All of it inside Atlassian. The app declares its storage as user-generated content, which is what Forge asks for; that is a platform classification rather than a statement that none of it is personal data, and this page argues the opposite elsewhere.
The warranty end date, into the field you mapped, while write-back is on. And expiry issues, in the project you chose. That is the complete list.
The labels an expiry issue carries join your site’s shared label namespace, where they appear in label pickers. A per-device issue adds two; a digest issue adds one per device it lists — up to 201, being the app’s own label plus one for each of the 200 devices a digest can hold. It is the one side effect worth knowing in advance.
Manufacturer credentials go into Forge’s encrypted secret storage. The app reads them to authenticate; it returns them to nobody. No screen, log line, export or API response ever gives one back — not masked, not truncated, not at all. A credential you remove is deleted rather than deactivated.
No key, token, stack trace or raw upstream response body can reach a banner, a log line or an issue description. Every failure is mapped to a small set of admin-safe codes first, each of which names the failing thing and the fix.
The app stores no user profile of any kind. It resolves no user, sets no reporter, and keeps no record of who opened the dashboard. What personal data it touches is covered section by section in the privacy policy.
Exported values are escaped against formula injection, so a device name beginning with an equals sign stays a device name when somebody opens the file in a spreadsheet rather than becoming a formula that runs.
Because the app is not eligible for it, and saying so seemed better than implying a badge it cannot hold.
Runs on Atlassian requires an app to make no egress of in-scope end-user data at all. Warranty lookup is egress: a serial number goes to a manufacturer, and where a device is assigned to a person that serial can be personal data. The app could declare otherwise in its manifest and would then qualify. It does not, because the claim would be the wrong way round — the conservative reading is the honest one, and the badge is not worth the argument.
Everything the badge is meant to signal is still true and is checkable above: Forge-hosted compute and storage, no external service of ours, no analytics, and an egress allowlist of exactly three manufacturer hosts.
WarrantySync is a Forge app built for distribution through the Atlassian Marketplace, and will be subject to Atlassian’s app review before it is listed. It does not hold a SOC 2 or ISO 27001 certification of its own, and we do not imply one. Section 9 of the Cloud Security Statement sets out what that means in practice, including which of Atlassian’s certifications the underlying platform carries and which are therefore not ours to claim.
The app will not create a custom field, an Assets attribute or an object type in your site. If a mapping is missing it names what to create and offers to look again. A field the app invents is a field you are left with after the app is gone.
Uninstalling clears the app’s storage — settings, credentials, device records and counters. We have verified that; the deletion itself is Atlassian’s platform behaviour rather than something we can promise on their behalf, and the DPA puts it that way for the same reason. What remains is what was already yours: the dates on your devices and the issues already raised. Neither is deleted, because both are yours to keep or remove.
Every form control is programmatically labelled, every reason a control is unavailable is rendered as visible text rather than a tooltip a keyboard cannot reach, and the app follows your Jira theme in both light and dark appearance. The accessibility statement sets out what has been measured and, just as usefully, what has not.
Security questions, or a questionnaire you need completed, go to support@itsm-ltd.com. If you believe you have found a vulnerability, please write to the same address and say so in the subject line.
It installs with no credentials and counts your estate on the first run, so you know the size of the problem before anybody has to request API access. It is free, and there is no licence check to fail.
