Trust center
Security and privacy
How Customer Assets for JSM Portal handles your data — stated precisely, including the limits. The app reads Assets as the app, stores no credentials, sends nothing outside your Atlassian site, and keeps its data in Forge storage that follows your site’s data residency. For security questionnaires, this page and the linked documentation are the reference.
- No credentials stored
- No data egress
- Data residency follows your site
- Runs on Atlassian eligible
- Read-only Assets access
- No public endpoint
At a glance
- Atlassian Forge, Cloud onlyRuns on Forge (
nodejs24.x) inside your Atlassian Cloud site. Licensed through the Atlassian Marketplace. - No credentialsNo service account, no e-mail, no API token, no password. The app reads Assets as the app, with Forge app authentication.
- No data egressThe manifest declares no external endpoint and no remote. Every call goes through Forge to your own site’s Jira, JSM and Assets APIs.
- Data residency follows your siteAll app data is in Forge storage, which follows your site’s data residency location and moves with it (details).
- Runs on Atlassian eligibleForge reports the app as eligible for the Runs on Atlassian programme. Atlassian shows the badge once the listed version qualifies.
- Read-only Assets accessTwo read-only Assets scopes. The app’s only write to Jira is one optional Assets field on requests it originated.
- No vendor servers, no sub-processorsNo third party is involved. Data never leaves Atlassian infrastructure, and vi2va has no access to stored customer data.
- No public endpointThe app has no web trigger. Sync on demand is available only on the settings page.
- Minimal data in the browserCustomers’ browsers receive only the columns you chose, plus key, name, type and status category. Internal ids never leave the backend.
Data flow
A scheduled background sync reads Assets as the app and prepares each customer’s list; the portal only reads it. The portal never calls Assets at view time, and nothing in the flow leaves your Atlassian site.
- The hourly schedule — or Sync now on the settings page — queues a sync job.
- The sync consumer reads your own Assets REST API as the app: Forge app authentication, read-only. No service account, no API token, no external endpoint.
- It writes each customer’s list into Forge storage: a delta check every hour, a full reconciliation at least daily and on every Sync now.
- A portal customer opens My assets from the Help Center user menu.
- The resolver returns only that customer’s pre-computed list, keyed by the account id from the Forge context. No Assets call at view time.
- Administrators configure display, incident reporting and access; the settings page lists the object schemas and samples the columns as the app, too. Administer Jira is re-verified on the server for every settings action.
| Flow | From → to | Data | Protection |
|---|---|---|---|
| Sync | Sync consumer → your site’s own Assets REST API, as the app | Assets objects matching the configured schemas, owner attribute or AQL | Forge app authentication through a Forge product request; read-only (read:cmdb-object:jira); no credentials; no external endpoint |
| Settings page | Admin settings page → your site’s own Assets REST API, as the app | List of object schemas; attribute names found in a sample of the configured query, offered as columns | Administer Jira re-verified on the server; read-only (read:cmdb-schema:jira, read:cmdb-object:jira) |
| Cache write | Sync consumer → Forge storage | Per customer: all attributes the configured query returns for the customer’s objects, plus object id, key, type and status category | Stored per installation, keyed by account id; rewritten every sync |
| Audience check | Sync → Jira Service Management organisations | Account ids of members of the selected organisations | Only when the audience is restricted; re-resolved every sync, trusted for at most 24 hours; fail-closed |
| Account clean-up | Sync → Jira users | Account status | Deleted Atlassian accounts are detected whenever a sync fetches data, and their cached data is purged — at least daily |
| Portal view | Forge storage → the customer’s My assets window | The signed-in customer’s own list only, reduced to the configured columns plus key, name, type and status category; internal ids never leave the backend | Account id taken from the Forge context on the server; no identifier from the browser is trusted |
| Service desk choice | Jira Service Management → the customer’s window, as the user | Service desks the customer can raise requests in | Called with the customer’s own permissions |
| Assets field (optional) | Created-request trigger → the new request | One Assets object reference | Off by default; only requests carrying the app’s marker, configured request types, and an asset from the reporter’s own cached list; refuses on any ambiguity |
Stored data
All data is held in Forge storage of your installation. Nothing is stored outside it, and no credentials are stored at all.
| Data | Content | Personal data | Retention |
|---|---|---|---|
| Per-customer asset cache | All attributes the configured query (AQL) returns for the objects assigned to each customer, plus object id, key, type and status category — so changing the visible columns needs no re-sync. Only the configured columns plus key, name, type and status category are ever sent to the customer’s browser. | Account id as key; attribute values may include personal data if your Assets schema holds it (for example names or e-mail addresses) | Rewritten every sync; removed when the customer no longer owns assets, leaves the audience, or the account is deleted |
| User index (sharded) | Account ids that currently have a cache entry | Account ids | Maintained by every sync |
| Audience index | Account ids of members of the selected JSM organisations | Account ids | Re-resolved every sync; trusted for at most 24 hours |
| Configuration | Schemas, attribute, AQL, columns, projects, templates, audience | No | Until changed or uninstalled |
| Credentials | None. Earlier versions stored a service-account e-mail and API token in Forge secret storage; the current version deletes that secret automatically on the next sync and when the settings page is opened | — | Deleted on upgrade; nothing is stored any more |
| Sync status | Timestamps, counts, last error code | No | Overwritten on each run |
| Audit trail | Time, admin account id, action code, setting summary (counts only — never the AQL text). Upgraded installations may still show older entries for saved or deleted credentials (who and when only, never a secret) until they roll out of the trail | Admin account id | Last 50 entries |
| Sync staging | Temporary copies written during a sync run before they replace the live cache | Same as the asset cache | Removed or overwritten by the next run |
| Small technical caches | Workspace id, request-type field id, form check | No | Technical; replaced as needed |
Administrator names in the audit trail are read live, as the viewing administrator, when the settings page is opened. Names are not stored.
Deletion follows the Forge hosted-storage data lifecycle: data the app deletes, and all app storage on uninstall, is soft-deleted by Forge, can be relinked on request for 21 days, and is then deleted.
Scopes and why each is needed
The app requests eleven scopes. Each one maps to a specific function; all but storage:app and write:jira-work are read-only, and the only write to Jira is gated behind an administrator setting.
| Scope | Used for |
|---|---|
storage:app | Forge storage (cache, configuration, status, audit trail). Forge secret storage is only touched to delete the token earlier versions stored |
read:permission:jira | Server-side check that the caller has Administer Jira before any settings action |
read:servicedesk-request | Discover the Assets workspace id; list service desks, request types and request-type fields for configuration; list the service desks the calling customer can raise requests in (as the user) |
read:jira-user | Detect deleted Atlassian accounts during sync and purge their cached data; show administrator names in the audit trail |
read:organization:jira-service-management | List JSM organisations for the audience restriction |
read:organization.user:jira-service-management | Read organisation membership for the audience restriction |
read:user:jira | Required by the organisation-members endpoint alongside the scope above |
read:jira-work | Required by the created-request trigger; reads the new request’s reporter, description and request type |
write:jira-work | Set one Assets field on requests the app originated — only when an administrator enables it |
read:cmdb-object:jira | Read Assets objects as the app: the sync’s AQL object search and the column sample on the settings page (read-only) |
read:cmdb-schema:jira | List the Assets object schemas for the settings page (read-only) |
The two Assets scopes replace the service-account API token of earlier versions. Because they are new, an administrator approves the app update and its new permissions in Manage apps when upgrading from an earlier version; the new, token-free version takes effect only after that approval.
Egress, Runs on Atlassian and data residency
No external endpoint
The manifest declares no external endpoint (permissions.external) and no remote. Every call the app makes is a Forge product request to your own site — Jira, Jira Service Management and Assets (/jsm/assets/workspace/{id}/v1, read-only) — either as the app or as the calling user. No credentials are sent anywhere, because none exist.
No data is sent to vi2va, to any third party or to any server outside Atlassian. There are no sub-processors.
Runs on Atlassian: eligible
Runs on Atlassian is Atlassian’s programme for Forge apps that keep customer data on Atlassian infrastructure, without egress. Forge’s eligibility check reports this app as eligible for the programme.
Atlassian displays the Runs on Atlassian badge on the Marketplace listing once the listed version qualifies. Until the badge appears there, we call the app eligible, nothing more.
Atlassian documents that every persistent Forge hosted storage capability (Key-Value Store, Custom Entity Store, Forge SQL, Object Store) is data-residency-enabled, and that an app qualifies for the PINNED status when all in-scope End-User Data is stored exclusively in Forge hosted storage. Forge assumes remote storage only if an app declares an external fetch domain or a remote; this app declares neither.
The app’s data (Forge Key-Value Store) therefore lives in your site’s data residency location — Global, Australia, Canada, EU, Germany, India, Japan, Singapore, South Korea, Switzerland, United Kingdom or United States — and is migrated with the site when an administrator moves it. Source: Forge data residency (checked 2026-10-04).
That statement covers stored app data. Atlassian’s page does not address app logs, so we make no residency claim for logs (see Logging).
No credentials, nothing to connect
The app collects and stores no passwords, API tokens or other credentials. It reads Assets as the app, with Forge app authentication and two read-only Assets scopes — there is no service account, no e-mail address and no API token to enter, rotate or protect.
- Setup: install the app, approve its permissions, and choose what to show on the settings page.
- Status: a status tile shows whether the app can read Assets on your site. If it cannot, the settings page shows Assets is not reachable with the reason: the site has no Assets workspace, the app update has not been approved yet in Manage apps, or Assets is temporarily unreachable.
- Upgrade from an earlier version: earlier versions stored a service-account API token in Forge secret storage. The current version deletes it automatically on the next sync and when the settings page is opened. Nothing replaces it.
- Scope of access: the app can read the Assets data the app itself is permitted to read. Which objects are cached is limited by your schema selection, owner attribute and AQL; what customers see is limited by your column selection.
Security controls
Authorisation
- Every settings action re-verifies Administer Jira on the server. Placement on an admin page is not treated as authorisation.
- The portal resolver returns only the caller’s own cache, identified by the account id from the Forge context. No identifier from the browser is trusted for authorisation.
- The audience restriction is fail-closed: unknown or stale membership means nothing is shown.
- Licence check: features are blocked when the Marketplace licence is inactive.
Input validation
- Every payload is validated: numeric ids,
customfield_<n>field ids, length caps. - AQL injection guard for schema ids and attribute names.
- Duplicate detection and count limits for projects, columns and organisations.
Bounded write path
- The only write to Jira sets one Assets field, and only when an administrator enables it.
- Only requests carrying the app’s own marker, only configured request types, only an asset from the reporter’s own cached list.
- Refuses on any ambiguity.
No credentials, no egress
- No passwords, API tokens or other credentials are collected or stored; Assets is read with Forge app authentication.
- Read-only Assets access through two read-only scopes.
- No external endpoint, no remote. The token earlier versions stored is deleted automatically on upgrade.
Hardened Custom UI
- Same-origin bundles only; no inline scripts or styles; no relaxed content-security permissions.
- No
innerHTML: all text is rendered as text nodes. - Links leave the iframe through the Forge router.
Engineering and supply chain
- No web trigger — the app exposes no public endpoint.
- Dependency audit gate in continuous integration.
- CI on GitHub Actions and Bitbucket Pipelines: lint, unit tests, help-content sync and bundle staleness checks.
Logging
What the app logs
- Counts and reason codes
- Platform error messages; for a failed field write, the custom-field id and up to 200 characters of Jira’s error text
- The generated sync AQL (schema ids and owner attribute name) — never your AQL override
- For the Assets-field trigger: the request key and the asset key (for example “Asset ITTEST-1010 set on ITS-12”)
What the app never logs
- Account ids
- E-mail addresses
- Asset attribute values
- Credentials — the app has none that could be logged
Forge shares app logs with the app vendor by default, so vi2va can see the log lines described above. A site administrator can turn log sharing off. The logs are retained for 30 days. The data residency statement covers stored app data, not logs.
Privacy and GDPR
Personal data the app processes
- Atlassian account ids — as cache keys, in the user index and, when the audience is restricted, in the audience index.
- Asset attribute values returned by the configured query. Depending on your Assets schema these may include names or e-mail addresses.
- Administrator account ids — in the configuration audit trail (last 50 entries).
Data minimisation and retention
- The customer’s browser receives only the columns your administrator chose, plus key, name, type and status category; internal ids never leave the backend.
- Data is cached only for customers who own assets and belong to the audience. Restricting the audience to selected organisations reduces what is stored.
- The cache is rewritten on every sync. Entries are removed when a customer no longer owns assets, leaves the audience, or their Atlassian account is deleted.
- Data of deleted Atlassian accounts is detected and purged at least daily.
- On uninstall, Forge soft-deletes all app storage; it can be relinked on request for 21 days and is then deleted.
Vendor access and sub-processors
VI2VA GmbH has no access to the data the app stores and operates no servers for this app. There are no sub-processors. All processing happens on Atlassian Forge within your Atlassian Cloud site, and stored app data follows your site’s data residency location (see Egress & residency). Forge shares the app’s logs with vi2va by default (see Logging); a site administrator can turn this off.
Changes and deletion at the source
The app’s data is derived from your Assets data. When objects or ownership change in Assets, the next sync updates or removes the cached entries accordingly.
Roles and data processing agreement
You are the controller. VI2VA GmbH receives none of the data the app stores, so it is neither controller nor processor of that data; your processor for data held on the platform is Atlassian, under your agreement with Atlassian. A data processing agreement with us is therefore not required. The only output of the app we can see is its technical log (see Logging), which contains no personal data by design and which your site administrator can withhold from us. If your procurement file needs this stated in writing, ask through our support portal and we will confirm it.
Legal documents
- App privacy policy: Privacy policy (app)
- Licence terms: the standard Atlassian Marketplace end user agreement
- Privacy policy for this website: Privacy policy (website)
Limits and product boundaries
| Item | Limit |
|---|---|
| Incident projects | 25 |
| Object schemas | 50 |
| Displayed columns | 20 |
| JSM organisations | 50 |
| Accounts in the audience index | 4,000 |
| AQL | 2,000 characters |
| Summary template | 255 characters |
| Description template | 2,000 characters |
| Audit trail | 50 entries |
Boundaries, stated honestly
- Jira Service Management cannot prefill Assets object fields in the portal form. The optional trigger fills the field just after creation instead.
- The list of service desks is filtered by the customer’s own desk access. Unlicensed portal accounts cannot make that lookup and are offered all configured projects.
- Data is as fresh as the last sync: hourly, or on demand with Sync now.
- Each customer’s list is capped by the Forge storage value limit. If a list is capped, the customer is told.
- The app reads whatever Assets data the app itself is permitted to read; what it caches is limited by your schema selection, owner attribute and AQL.
- Assets requires Jira Service Management Premium or Enterprise. Without an Assets workspace the settings page says so and nothing is synced.
- When upgrading from an earlier version, the token-free version takes effect only after an administrator approves the new permissions.
Vulnerability disclosure
If you believe you have found a security vulnerability in Customer Assets for JSM Portal, please report it to us privately.
- Contact
- security@vi2va.de — please use this address rather than the public support channel.
- Please include
- Enough detail to reproduce the issue: a description, the steps to reproduce it, and the impact you observed.
- Please do not send
- API tokens, passwords or customer data. We will never ask for them.
- Response
- We will confirm receipt and keep you informed until the issue is resolved. Fixes follow the deadlines of Atlassian’s security bug fix policy for Marketplace apps: critical within 10 days, high within 4 weeks, medium within 12 weeks, low within 25 weeks.
- Good faith
- We will not pursue anyone who reports a finding in good faith.
Security incidents
If a security incident affects the app, we notify Atlassian within 24 hours of discovery, as Atlassian requires of Marketplace partners. Where customer data was compromised, we inform the affected customers without undue delay, and within 72 hours, so that you can meet your own obligations as controller.
Support
Raise a request in our support portal, or e-mail support@vi2va.de if you cannot reach it. Hours: Monday to Friday, business hours, Central European Time, excluding German public holidays. Target first response: within one business day.
Documentation
The product manual is published in a public Confluence space; no account is required.