GDPR, Schrems II and Atlassian Cloud — a practical guide for teams
EU organisations using Jira and Confluence must align vendor DPAs, international transfers, residency choices and app architecture. This article explains the building blocks — not legal advice.
Disclaimer. This article is general information for IT and compliance teams, not legal advice. Laws, regulator guidance and vendor contracts change — involve your DPO or counsel before making decisions.
Why this matters after Schrems II
The Schrems II judgment (CJEU, 2020) invalidated the EU–US Privacy Shield. Organisations must now assess whether US surveillance laws and government access create an unacceptable risk when personal data is processed in the US or by US providers, and whether supplementary measures under EDPB recommendations are sufficient. Atlassian publishes documentation on transfers, SCCs and safeguards — treat it as part of your transfer impact assessment (TIA), not a substitute for your own record.
Roles: controller vs processor
Typically your company is the controller for employee and customer data in Jira/Confluence. Atlassian acts as a processor under Art. 28 GDPR when you use Atlassian Cloud. Marketplace vendors are often sub-processors of Atlassian (Forge/Connect model) or separate controllers depending on architecture — read each vendor’s documentation and DPA schedule.
Data residency
Atlassian offers data residency options for certain products and regions. Residency reduces some transfer questions for data at rest in the chosen region, but does not automatically solve support access, sub-processors or backups in other regions. Verify in admin documentation which data classes are covered.
Data Processing Agreement (DPA)
Download Atlassian’s Data Processing Agreement and keep it in your Article 30 records of processing. Map processing purposes (ticketing, HR cases, customer projects) to legal bases (Art. 6 GDPR) and document retention. The DPA addresses processor obligations; your organisation remains responsible for lawfulness, transparency and data subject rights.
International transfers
If data leaves the EEA, you need a Chapter V GDPR mechanism (e.g. SCCs) plus, where required, a transfer impact assessment and supplementary measures. Atlassian’s trust materials describe their safeguards — integrate them into your TIA narrative and revisit when facts change.
Marketplace apps — common pitfall
Many incidents come from apps that mirror issue data to external databases, use tracking pixels, or run user code on non-Atlassian infrastructure. Each pattern can create a new transfer or a separate processing relationship. Prefer apps whose data plane stays on Atlassian-controlled infrastructure and whose privacy policy clearly states subprocessors and purposes.
MOY= Apps technical posture
Our public marketing site does not host your Jira/Confluence content. Our Forge-based apps are designed to execute within Atlassian’s platform boundaries; we do not operate a separate data store outside Atlassian for app runtime data as described in our marketplace listings and privacy materials. Your organisation must still complete its own DPIA/TIA because your instance configuration, fields and integrations are unique.
Checklist for your register of processing
- Product and URL, purposes, categories of data subjects and data.
- Legal bases and retention per data category.
- Sub-processors: Atlassian, marketplace vendors, support tools, analytics on the website.
- Transfer mechanisms and TIAs where applicable.
- Procedures for access, erasure, portability and breach notification.
Further reading (official / authoritative)
- Atlassian Trust & Security and DPA downloads (trust.atlassian.com).
- EDPB recommendations on supplementary measures (post–Schrems II).
- Your national supervisory authority guidance on cloud and employer monitoring.