Privacy Policy
This policy explains what data the AccessRadar app for Jira Cloud processes, where it lives, why, and what you can do about it.
Last updated: 2026-10-09 · Version 1.0
Summary
- AccessRadar is a Forge app that Runs on Atlassian. All app data is stored in Atlassian's Forge hosted storage (Forge SQL and Key-Value Store), and it follows your Jira site's data residency.
- AccessRadar makes no calls to servers outside Atlassian, and Radrly receives none of your Jira data.
- Atlassian is the only sub-processor (hosting). No external AI or LLM service is used.
- The app is read-only toward Jira: it never modifies issues, users, groups or permission schemes.
- Radrly acts as a data processor for the personal data in the app, and your organisation is the controller.
Who we are
AccessRadar is developed and operated by Radrly Sp. z o.o., a company established in Poland (“Radrly”, “we”). Registered office: ul. Tarczyńska 68, 05-831 Krakowiany, Poland. KRS 0001215510, NIP 5342706013, REGON 543658680.
This policy covers the AccessRadar app. “Customer” means the organisation that installs AccessRadar on its Jira Cloud site. “Users” means the people in the Customer's Jira site.
Data we process
AccessRadar processes only the data needed to resolve effective access, take snapshots, run reviews and produce exports.
| Data | Examples | Purpose |
|---|---|---|
| Atlassian account IDs | IDs of users and app accounts that hold roles, group membership or grants | Attribute access and review sign-off to the right person |
| User display names | Names shown next to people in explore and review views | Make reviews readable for admins and auditors |
| Group and role data | Group IDs and names, project role IDs and actors, application roles | Resolve the path of access |
| Permission scheme data | Scheme IDs, holders and permissions; project-to-scheme mapping | Explain why a person has access |
| Snapshot and review records | Resolved access rows, change diffs, SHA-256 hashes, reviewer account IDs | Access reviews and audit evidence |
| Export artefacts | CSV/PDF content generated for download | SOC 2 / ISO 27001 evidence packages |
Email addresses are not stored as a primary identifier. The app does not store issue content, worklogs, comments, descriptions or attachments.
We do not use this data for advertising, profiling or sale, and we do not combine it with other data.
Where data is stored
All AccessRadar data is stored in Atlassian Forge hosted storage: Forge SQL and the Forge Key-Value Store, on Atlassian's infrastructure. AccessRadar stores no End-User Data outside Atlassian products and services, and does not process it outside Atlassian or the user's browser.
Data residency. Forge SQL and Key-Value Store support data residency. The app's data is kept in the location chosen for your Jira site and moves with it if you migrate between residency locations. Radrly does not run any servers that hold your data.
No egress, no sub-processors
AccessRadar declares no remote hosts, uses no Forge Remote and no Connect, and does not call external APIs. It exposes no public REST API of its own.
We do not share End-User Data with third parties. Atlassian provides the hosting platform (Forge and Jira) under its own terms and, for GDPR purposes, is a sub-processor. Other than Atlassian, we use no sub-processors.
AI
AccessRadar does not call any external AI or LLM service. Access resolution and risk indicators are deterministic calculations inside Forge.
Permissions (scopes)
Jira asks you to approve the following kinds of scopes when the app is installed. No write or manage scopes are requested.
| Scope family | Why AccessRadar needs it |
|---|---|
Project and catalogue read:* | List projects and related metadata so schemes and roles can be mapped. |
read:permission-scheme:jira, read:permission:jira | Read permission schemes and grants. |
read:project-role:jira, read:group:jira, read:user:jira, read:application-role:jira | Resolve who holds access and through which path. |
report:personal-data | Report stored Atlassian account IDs to Atlassian's personal data reporting API daily and erase or anonymise them when Atlassian reports an account closed or updated. |
See Security for the full scope discussion, including app-user group membership and optional impersonation for collection fallback.
Retention and deletion
- While installed: snapshots and reviews are kept for as long as the app is installed, so that history and evidence remain available.
- In-app deletion: as data-control features ship, admins will be able to delete AccessRadar data in the app. Until then, uninstall removes the app's data under Atlassian's Forge retention rules.
- After uninstall: the Forge platform soft-deletes the app's data and destroys it at the end of the retention period described in Atlassian's SOC 2 report. A reinstall within 21 days can be relinked to the old data. This period is set by Atlassian. Radrly itself keeps no copy.
- Personal data reporting: once a day the app reports stored Atlassian account IDs to Atlassian's personal data reporting API. If Atlassian reports an account as closed or updated, AccessRadar erases or anonymises that person's identifiers on remaining rows.
Logs
The app writes operational status and error messages to the Forge developer console. Logs stay in Atlassian's environment and are not sent to Radrly.
GDPR
Roles. For the personal data in AccessRadar (account IDs, display names, group membership and role assignments reflected in snapshots and reviews), the Customer is the controller and Radrly is a processor acting on the Customer's documented instructions. A Data Processing Agreement is available.
Legal basis. The Customer decides the legal basis for reviewing access of its personnel (for example legitimate interests or compliance with legal obligations). Radrly does not decide the purposes of the processing.
Your rights. If you are a person whose data is in a Customer's AccessRadar, you have rights of access, rectification, erasure, restriction, portability and objection under the GDPR. Please contact the organisation that runs your Jira site first. We will support the Customer in answering such requests. You also have the right to complain to a supervisory authority (in Poland: the President of the Personal Data Protection Office, UODO).
Security. See Security.
International transfers
Radrly does not transfer data itself. Data is hosted by Atlassian in the location set by the Customer's data residency choice, and Atlassian's own transfer mechanisms apply.
CCPA
Radrly does not sell personal information. Radrly is an EU company; any California consumer personal information processed through the app is handled only within Atlassian's platform under Atlassian's terms.
This website
This site is static. It uses no cookies, no analytics, no trackers and no third-party scripts, fonts or CDNs. Our web server keeps standard access logs (IP address, time, requested page) for security and operations. The logs are rotated daily and kept for 14 days.
Changes
We will update this page when the app's data handling changes and show the date of the latest update at the top. For material changes we will notify customers, for example through Atlassian Marketplace.
Contact
Privacy questions and data requests: marcin@radrly.com. Security contact: marcin@radrly.com. We have not appointed a Data Protection Officer; privacy questions go to the contact above.