Data Security and Privacy Statement
Service Project Standards for JSM, published by Matify. Last updated: 18 September 2026.
Overview
Service Project Standards for JSM lets a Jira administrator capture a standard from a
reference service project, compares every assigned service project against it, scores each one, logs
what changed between scans, manages time-limited exceptions, and exports audit evidence. This statement
describes exactly what the app reads, what it writes, what it keeps and where that data lives.
The short version: the app is read-only against your Jira configuration, runs entirely on Atlassian's
own platform, stores only Atlassian account ids and a compact form of your service project configuration,
and sends nothing anywhere else.
Hosting and architecture
The app is built on Atlassian Forge. Its code runs on Atlassian-hosted compute
(nodejs24.x, arm64) and its data lives in Atlassian-hosted storage inside your
site's own region. There is no Matify server, no external database, no queue outside Atlassian's own
Forge events, and no third-party service in the request path.
There is no external data egress of any kind: no analytics, no error reporting service, no content
delivery network, no remote fonts. The manifest declares no permissions.external block, and
every outbound call in the source code goes through Atlassian's own product-fetch API, which can only
reach the installed site's own API gateway.
Data the app processes
| Data | Read | Stored | Why |
|---|
| Request types, form fields (incl. hidden/preset), request type groups | Yes | Yes, in a captured standard, and per-scan snapshots | The product's core comparison object |
| Queues (name, JQL, columns) | Yes | Yes | Queue drift detection |
| Workflow / issue type / issue type screen / permission / notification scheme content | Yes | As a content hash and short summary, not the full scheme body | Scheme-content comparison that survives a per-project generated scheme without a false deviation |
| Screens, tabs and screen fields | Yes (full scan) | Yes | Screen-layout comparison |
| Project roles and components | Yes | Yes | Comparison |
| Project role members | Only if an admin turns on role-membership comparison (off by default) | Only if enabled | Opt-in comparison |
| Atlassian account ids (project lead, standard creator, scan actor, exception owner/creator, attestation owner) | Yes | Yes | Attribution and rendering "who" in the interface |
| Findings, change log, exceptions, attestations | — | Yes | The product's own generated output and audit trail |
| Issue content of any kind | No | No | The app holds no issue-content scope |
| Email addresses, display names, profile data | No | No | The app resolves display names for rendering only, in the browser, and never stores them |
| SLA config, automation rules, portal settings, customer permissions, JSM Forms fields, issue security scheme | No | No | No least-privilege read API exists for these; see the in-product Coverage tab |
Personal data
The app stores Atlassian account ids. They identify a person, so the app treats them
as personal data and implements Atlassian's personal data reporting API: Atlassian can ask which account
ids the app holds, and can instruct the app to erase them. On erasure the app replaces the id with a
tombstone value on the record that named it — an exception, an attestation or a standard — and marks the
record accordingly. It never deletes the record itself, because the record is the audit trail of a
decision that remains valid regardless of who made it.
No other personal data is stored. The app holds no email addresses, no display names, no profile
information and no issue content.
Data storage, retention and deletion
- Where: Forge hosted storage (8 custom entities and the key-value store), pinned to
the region of the Jira site the app is installed on.
- Retention: change log entries are kept for 12 months by default (configurable
3–24 months) and pruned automatically after every scan. Scan snapshots keep the newest 4 scans per
project by default (configurable 2–12), older ones deleted automatically after every scan. Standards,
findings, exceptions and attestations are kept until an administrator deletes them.
- Deletion: administrators can delete standards, exceptions, attestations and project
assignments at any time, and "Delete all app data" — which requires typing a confirmation phrase, checked
on the server — removes everything the app stores.
- On uninstall: Forge removes the app's storage automatically. The app never creates,
edits or deletes anything in your Jira or JSM configuration at any time, so nothing in your site changes
as a result of uninstalling.
Tenant isolation
Forge storage is scoped to a single installation. The app holds no cross-site cache and no shared
identifier. Data from one Jira site is never readable from another.
Data residency
The app uses only Atlassian-hosted storage and therefore follows the data residency of the Jira site
it is installed on.
Permissions the app requests, and why
32 scopes in total: 30 granular read: scopes plus storage:app and
report:personal-data. Zero write scopes, zero manage:* scopes, zero
issue-content scopes.
Why more scopes than the obvious minimum
Jira enforces its granular scope list cumulatively: several endpoints this app calls
answered 401 scope does not match until identity and presentation scopes that appear
alongside the primary scope in Jira's own API specification were added, even though those endpoints
return project configuration, not user profiles. This was measured against a live site, not assumed —
see the full endpoint table in the app's Scope Justifications document.
| Scope group | What it is for |
|---|
| Project and configuration reads (18 scopes) | Project metadata, roles, components, workflow/issue-type/screen/permission/notification schemes, screens and fields |
| Identity reads, required cumulatively (4 scopes) | read:user:jira, read:group:jira, read:application-role:jira, read:avatar:jira — required by Jira's own scope enforcement on the configuration endpoints above; never used to look up a person |
| JSM object reads (3 scopes) | Service desks, request types and fields, queues — the objects the product exists to compare |
| Platform (2 scopes) | storage:app for the app's own data; report:personal-data to report stored account ids to Atlassian and honour erasure |
The app does not request permission to write to Jira, to manage Jira configuration, to
read issue content, or to read customer/portal data.
What the app deliberately does not do
- It never creates, edits or deletes a project, request type, field, queue, scheme, screen, role or
component. Its entire write surface is its own Forge storage.
- It never acts as one of your users for a product read: every comparison read runs under the app's own
identity (
asApp), which is what lets an unattended nightly scan work at all. The one
exception is asking Jira what the calling person may do, which is asked as that person precisely
because it is a question about them, not about the app.
- It never silently reports an area it cannot verify as matching. Every area outside its documented
coverage is labelled as such, in the product and in every exported evidence pack.
Logging
The app writes structured operational logs to Forge: event names, account ids where an action needs
attribution, area/status/severity codes, and durations. The logger uses an allow-list on field names, not
a deny-list on values, so any field not explicitly known to hold a safe identifier or code — including
every field an administrator can type free text into (exception reasons, standard names, queue JQL,
request-type help text) — is written as redacted, never verbatim.
Security practices
- Least privilege: every scope maps to an endpoint the app actually calls, verified live against a real
Jira Service Management site.
- Every administrative action is checked against Jira's own permission system in the backend, by asking
Jira directly on every call, never by trusting the interface or a cached flag.
- All input from the browser is validated and length-bounded on the server before use.
- CSV exports neutralise formula-injection characters on every cell; the HTML evidence export escapes
every interpolated value.
- The app holds no credentials, API tokens or secrets of its own. All Jira traffic uses Atlassian's own
authenticated product API.
- Findings and the change log are an append-style audit record: a finding is marked fixed when it stops
deviating, never silently deleted by a rescan.
Subprocessors
None. The app uses no third-party service at runtime.
Contact
Security or privacy questions, including vulnerability reports: mira.maty@web.de.
Please report suspected vulnerabilities privately to that address rather than in a public issue.
Related documents