Security and trust

How Roleprint for Jira handles your data: where it runs, what it reads and keeps, for how long, and how to check its evidence.

Summary

Runs on Atlassian
Roleprint is a Forge app. Its code runs in Atlassian's cloud and its data stays in Atlassian-hosted storage.
No data leaves your Jira site
Roleprint declares no outside connections, and Forge blocks any connection an app has not declared. Nothing is sent outside Atlassian.
Admin-only, read-only in Jira
Only Jira administrators can open Roleprint. It reads Jira and never writes to it.
Built on Forge
There is no Roleprint server. The admin page, the scheduled jobs and the storage all run on Forge.

Architecture

Roleprint's admin page is a Custom UI page inside Jira's settings. Behind it, Forge functions read Jira through its REST API with the scopes listed below, and a scheduled job takes the daily snapshot. Results are kept in Forge SQL and the Forge key-value store, both hosted by Atlassian. Roleprint runs no servers of its own and calls no external service.

Atlassian cloud

Jira Cloud

Your site: projects, permission schemes, roles, groups, users, audit log

Roleprint on Forge

Admin page, scheduled jobs, Forge SQL and key-value storage

Everything stays inside Atlassian's cloud. Nothing goes to a server outside it.

Data handled

What Roleprint reads

  • Projects, permission schemes, project roles and who holds each role
  • Groups and their members
  • Users, and whether each account is active
  • The Jira audit log
  • For the Configuration pages: custom fields, work types, workflows, statuses, schemes and components
  • Only when an administrator asks, on an account's page: the filters and dashboards the account owns and a count of its open work items

What Roleprint stores

  • Snapshots of permissions, roles, groups and users. A user is kept as account ID, display name, account type, whether the account is active, whether it is a guest, and the domain of its email address.
  • Findings, access reviews, decisions and sign-offs
  • Evidence packs and their SHA-256 hashes
  • Configuration scan results
  • Jira audit log entries, stored as Jira returns them: the author's account ID, the IP address Jira records and the changed values, which can include names and email addresses
  • A log of administrator actions in Roleprint, such as saving settings, starting a re-scan or an export, with the administrator's account ID

What Roleprint does not store

  • Passwords, API tokens or any other credentials
  • The content of work items: summaries, descriptions, comments and attachments
  • The filter and dashboard lists from an ownership check: they are shown on the page and not saved

Logs

Roleprint writes operational logs to Atlassian's Forge logging, such as error messages, account IDs, group names and project keys. Klarwick may read them to find and fix problems.

Configuration limits: usage against Jira's limits with severity
Configuration, Limits tab on the demo site: counts read from your site's configuration, kept with the scan that read them.

Scopes

Roleprint asks for four scopes. None of them is used to change anything in Jira.

ScopeWhy Roleprint needs itUsed to write?
read:jira-workProjects, permission schemes, project roles and configuration; the filters and dashboards for an ownership check.No
read:jira-userUsers, and whether each account is active.No
manage:jira-configurationJira requires it to list group members (/group/member) and to read the audit log (/auditing/record). Roleprint never uses it to write.No
storage:appThe app's own Forge storage, for snapshots, findings and reviews.No

Access control

Roleprint's page sits in Jira's settings, which only Jira administrators can open. The server checks again on every request: it confirms that the caller is in a group that holds Jira's Administer permission and refuses everyone else. The answer is kept for five minutes, so an administrator whose rights are removed loses access within five minutes, or up to an hour while Jira's API quota is used up: during that time an administrator verified in the last hour keeps access.

Retention

Every snapshot is kept for 35 days, then one per week up to 395 days. A snapshot that never finished is removed after a day. Closed reviews and their evidence packs stay with their hash, whatever happens to the snapshots. Audit log entries are kept for 395 days. Configuration scans are kept for 90 days, and the newest finished scan is always kept. The log of administrator actions is kept until the app is uninstalled. When the app is uninstalled, Atlassian deletes its storage after 28 days.

These periods are fixed. There is no setting to change them.

Evidence integrity

When you close an access review, Roleprint builds the review's CSV from the review's own records and stores its SHA-256. The hash is shown on the closed review, printed on the CSV's last line and repeated in the PDF. Every later download must produce the same bytes; if it does not, the app refuses to offer the file.

To check a copy, hash everything above the CSV's last line and compare the result with the hash on that line and on the closed review:

sed '$d' roleprint-access-review-<id>.csv | shasum -a 256

On Linux, sha256sum in place of shasum -a 256 gives the same result.

Compliance

Roleprint produces evidence that supports SOX/ITGC, ISO 27001 and SOC 2 audits. It does not certify compliance; your auditor does.

Klarwick, the vendor behind Roleprint, does not have a SOC 2 report or an ISO 27001 certificate of its own yet.

Reporting a vulnerability

Report a vulnerability to security@roleprint.app with what you found and how to reproduce it. Please test only against a Jira site you own, and give us time to fix the issue before you publish it.