Security & compliance

Written for the people who sign off on the app rather than use it: security review, data protection and procurement. Every answer here follows from how the app is built.

The short version

Question	Answer
Where does the app run?	Entirely on the Atlassian Forge platform, inside your Atlassian tenant. There is no vendor-operated infrastructure in the path.
Does any data leave Atlassian?	No. The app declares no external endpoints and makes no external network calls. There is nothing to allow-list.
Are there sub-processors?	None. No third party receives any data, because no data is sent anywhere.
Does the app hold privileges of its own?	No. Every call runs as the administrator using it. There is no service account and no mode that escalates.
Can it reach data the operator could not?	No. Jira applies its normal per-project authorization to every call.
Is there a background process?	One: a weekly personal-data report Atlassian requires of apps storing personal data. It reads only the app’s own storage.
Runs on Atlassian?	The app is eligible for Atlassian’s Runs on Atlassian programme, as a consequence of the answers above.

Data residency

Data residency questions are usually about where a vendor’s servers are. Admin Ops has none. It reads and writes your Jira through Atlassian’s own APIs, from inside Atlassian’s infrastructure, and stores its small record in Forge storage in the same place. The data never moves, so there is no transfer to assess and no region to choose: your Atlassian site’s data residency configuration governs it, exactly as it governs the rest of Jira.

What is stored

The app records account IDs rather than people. The exceptions are declared, not discovered.

Data	Personal data?	Retention
Audit log: job type, actor and target account IDs, object IDs, counts, timestamps, outcomes	Account IDs are pseudonymous identifiers	50 most recent runs
Object names in the audit log (filters, dashboards, schemes, fields, groups, projects, screens)	Possibly. Names are written by your users, so a filter called “Sick leave – A. Meier” is stored as that string	50 most recent runs
E-mail addresses of a customer import, in that run’s entry	Yes, deliberately: a rejected row has no account to point at	50 most recent runs
Access policy: account ID and role of each named administrator	Yes. Nothing is stored while access is unrestricted (the default)	Until you change it
Pinned bulk preview: a JQL string and the issue IDs it resolved to	No	Single use, 10 minutes

No issue content, secrets or tokens are stored at any point, and no personal data is written to diagnostic logs. Uninstalling the app deletes all of it.

Permissions (Forge scopes)

The app requests fifteen scopes. Twelve are granular; three are broad, because Jira offers nothing narrower for those endpoints. Each is listed with the reason.

Scope	Why it is needed
`read:jira-work`	Search filters, dashboards and issues by JQL; read filter sharing and custom field usage.
`write:jira-work`	Reassign filter and dashboard ownership; run previewed and confirmed bulk issue operations; delete or unshare filters.
`read:jira-user`	Resolve and validate users in the owner and target pickers.
`read:group:jira`	List a user’s group memberships and group sizes, and guard against removing the last administrator.
`write:group:jira`	Remove a departing user from groups. Granular on purpose: no manage scope is requested for this write.
`read:permission:jira`	Verify on every backend call that the caller holds Administer Jira.
`read:permission-scheme:jira`	Read permission schemes for the read-only audit and for consolidation previews.
`read:board-scope:jira-software`	Find the boards built on a filter, so a board’s filter is never recommended for deletion.
`read:project:jira`	Required by that board endpoint, and to name projects in usage reports.
`manage:jira-project`broad	Every screens endpoint requires it, including reading one; also assigning a permission scheme during consolidation.
`manage:jira-configuration`broad	Reading a custom field’s contexts, issue type screen schemes, notification schemes, and moving a field to the trash.
`manage:servicedesk-customer`broad	Jira Service Management exposes organizations and customers only behind this scope.
`read:servicedesk-request`	List the service desks for the customer and organization reports.
`storage:app`	Forge storage for the audit log, the access policy and the short-lived preview set.
`report:personal-data`	The weekly report of stored account IDs that Atlassian requires, so closed accounts can be erased.

The broad scopes grant more than the app uses. The mitigation is structural: every call runs as the calling administrator, every request re-verifies Administer Jira, and every change is previewed, confirmed and recorded.

Controls reviewers ask about

Control	Implementation
Authorization on every request	Each backend call re-verifies Administer Jira. Placement on an admin page is not treated as authorization.
Privilege escalation	Not possible: writes run as the calling user, never as the app.
Separation of duties	An in-app policy assigns auditor, operator or owner to named administrators, enforced on the server. It can only narrow what Jira already permits.
Forged requests	Mutations re-derive their targets from Jira at execution time rather than trusting what the browser sent.
Destructive mistakes	Preview, confirm, execute, with a typed word and a named object list for anything irreversible.
Acting on stale data	Bulk issue runs act on a pinned, single-use, ten-minute set resolved by the preview.
Incomplete information	Where a partial answer would be dangerous, the operation is blocked rather than attempted.
Licence enforcement	Checked on the server for every operation that writes. A build test fails if a writing resolver skips it.
Self-lockout	You cannot remove yourself from the Jira administrators group or save a policy that removes your own ownership.

What we do not claim

No certification is claimed here. If your process requires a specific attestation, ask us and you will get a straight answer about what does and does not exist.
The app is not a compliance archive. Its log keeps the 50 most recent runs. For long-term evidence, use Jira’s own audit log, where every change the app makes also appears.
The app is not an approval workflow. There is no second-person sign-off inside it.

Reporting a security concern

Raise a request in our support portal and say in the subject that it is a security report, or e-mail support@vi2va.de. Please never include API tokens, passwords or other secrets; we will never ask for them.

Start by seeing what your instance is carrying around

The read-only audits work even without a licence. Nothing changes until you decide it should.

Get it on the Marketplace Documentation