Data Processing Agreement

1. Parties and scope

This Data Processing Agreement (“DPA”) is between the Customer (the “Controller”) and Radrly Sp. z o.o., Poland (the “Processor”; registered office: ul. Tarczyńska 68, 05-831 Krakowiany, Poland; KRS 0001215510, NIP 5342706013, REGON 543658680). It forms part of the End User License Agreement and applies to personal data that the Processor processes on the Controller's behalf through the AccessRadar app for Jira Cloud. Terms such as “personal data”, “processing” and “supervisory authority” have the meaning given in Regulation (EU) 2016/679 (GDPR). This DPA sets out the Article 28 GDPR terms between the parties.

2. Subject matter, duration and nature

• Subject matter: providing AccessRadar, which reads Jira access configuration, resolves effective access, takes snapshots and supports access reviews and exports.
• Duration: for as long as the Controller has the app installed, plus the retention period described in section 9.
• Nature and purpose: reading Jira data inside Atlassian Forge, resolving access, storing snapshots and reviews in Forge hosted storage, and showing them to authorised users.
• Infrastructure: the app runs only on Atlassian Forge (Runs on Atlassian). It declares no remote hosts, uses no Forge Remote or Connect, and makes no egress to servers outside Atlassian. No processing of Controller data takes place on Radrly-operated servers.

3. Data and data subjects

• Data subjects: the Controller's employees, contractors and other Jira users whose accounts, group membership, roles or grants appear in AccessRadar snapshots and reviews.
• Categories of personal data:
  • Atlassian account IDs;
  • user display names;
  • group membership and project / application role assignments;
  • permission-scheme holder references that identify people or groups;
  • review sign-off metadata (reviewer account ID, timestamps, SHA-256 hash);
  • export artefacts that contain the above.
• Special categories: none intended. The Controller should not enter special-category data in the app.

4. Instructions

The Processor processes personal data only on the Controller's documented instructions, which are these terms, the Controller's configuration of the app, and the Controller's use of the app's features. If the Processor believes an instruction infringes data protection law, it will inform the Controller. Processing is also allowed where required by EU or Polish law, in which case the Processor will inform the Controller beforehand where legally permitted.

5. Confidentiality and personnel

The Processor ensures that people authorised to process personal data are bound by confidentiality obligations. As the app runs on Atlassian Forge and has no code path that sends Controller data to Radrly, Radrly staff have no routine access to Controller data.

6. Security

The Processor implements appropriate technical and organisational measures under Article 32 GDPR, described in Annex II and on the Security page. In short: data is stored in Atlassian Forge hosted storage (encrypted at rest by Atlassian), the app has no external egress, access in the app requires Jira administer permission, and the app is read-only toward Jira.

7. Sub-processors

The only sub-processor is Atlassian (Atlassian Pty Ltd and affiliates), which hosts Forge and Jira Cloud. The Controller gives general authorisation for the sub-processors in Annex III. The Processor will inform the Controller of intended changes so that it can object. The Processor imposes data protection obligations on sub-processors and remains responsible for them. Other than Atlassian, Radrly uses no sub-processors for AccessRadar.

8. Assistance, personal data breaches and audits

• Data subject rights: the Processor will help the Controller to respond to data subject requests, taking into account the nature of the processing.
• Personal data reporting API: the Processor supports Atlassian's Marketplace personal data reporting requirements for the app, so that Controllers can obtain reporting on personal data processed by AccessRadar through the applicable Atlassian channels.
• Breach notification: the Processor will notify the Controller without undue delay, and in any event within 48 hours after becoming aware of a personal data breach affecting the Controller's data, with the information available to it.
• Other assistance: with security, impact assessments and prior consultation, to the extent reasonably required.
• Audits: the Processor makes available the information needed to show compliance and allows reasonable audits, which may be satisfied by documentation, Atlassian's published compliance reports, or a written questionnaire.

9. Return and deletion

The Controller can export review and snapshot data as CSV/PDF before deletion. After uninstall, the Forge platform soft-deletes the app's data and destroys it at the end of the retention period in Atlassian's SOC 2 report (a reinstall within 21 days can be relinked to the old data). The Processor keeps no copies, unless law requires otherwise.

10. International transfers

The Processor does not transfer personal data itself. All AccessRadar data is stored in Forge SQL and the Forge Key-Value Store (KVS) under the Controller's Atlassian data residency choice for the Jira site. Any transfers by Atlassian are governed by Atlassian's own transfer mechanisms and agreements with the Controller, including where applicable the EU Standard Contractual Clauses (SCCs) and related transfer tools published by Atlassian.

11. Liability, term and law

Liability under this DPA is subject to the limitations in the End User License Agreement, to the extent the law allows. This DPA lasts as long as the Processor processes personal data for the Controller. It is governed by the laws of Poland, and disputes under it are subject to the competent courts in Warsaw, Poland. If this DPA and the EULA conflict on personal data, this DPA prevails.

Annex II – Technical and organisational measures

• Hosting on Atlassian Forge (Runs on Atlassian). Encryption at rest and in transit provided by Atlassian.
• Storage in Forge SQL and Forge KVS, following the Controller's Jira data residency.
• No egress: the app makes no calls to remote hosts, uses no Forge Remote or Connect, and has no public API of its own.
• Read-only scopes toward Jira; no write or manage scopes.
• Data minimisation: account IDs as the primary user identifier; no issue content, worklogs or comments stored.
• Admin-only access to the app UI; resolver-side permission checks.
• Least-privilege Forge scopes (see Privacy Policy).
• Automated checks (formatting, linting, type checking, unit tests, Forge lint) before every production deployment; vulnerability reporting process (see Security).

Annex III – Sub-processors

No other sub-processors.

Contact

Privacy and DPA questions: marcin@radrly.com.