Privacy in the Atlassian Cloud

Atlassian has made many improvements in terms of data protection. In this article we summarize the current situation and point out possible stumbling blocks from a technical point of view.

Since the end of the EU-U.S. Privacy Shield, Atlassian has based the protection of personal data according to European standards on the so-called standard contractual clauses. Customers who wish to make use of these clauses can obtain and sign the corresponding agreement here. The list of subcontracted data processors commissioned by Atlassian is also published here. Atlassian thus implements the requirements of the European Data Protection Basic Regulation DSGVO, insofar as this can be solved by a private company at short notice. We recommend signing the standard contract clauses in any case.

However, Computerworld rightly noted that the reasoning of the European Court of Justice is not directly attributable to shortcomings in the agreement itself, and therefore this at least partially calls into question the use of standard contractual clauses. At least vis-à-vis providers of Internet services and telecommunications providers from the USA, because these companies are subject to laws which, according to the EU Court of Justice, are not compatible with the fundamental rights of the EU. For example, providers of Internet services are subject to the Foreign Intelligence Surveillance Act (FISA), which grants the US secret services extensive rights to access data. It is therefore not clear how a private contract with the standard contractual clauses should provide better protection against data access by US secret services than the EU-U.S. Privacy Shield could. For even better protection, it may therefore make sense to rely additionally, where possible, on the few exceptions under Art. 49 DPA, in particular the declaration of consent. In some, though not all cases, this should be feasible. For further information on the legal side, we refer you to appropriately specialised lawyers.

Data residency

Atlassian is currently hosted in the AWS regions of the United States (East and West), Germany, Ireland, Singapore and Australia. It is not possible today to directly control where the data is stored. According to the documentation, Atlassian decides in which region the data is stored based on the frequency of access. User data is also stored centrally in the USA, regardless of which data region is used. Some relevant extensions are planned. Specifically, an early access program of the so-called Enterprise Plan is currently underway, which will then also enable data residence management features.

When considering the issue of data residency, however, it is important to note that the EU data protection basic regulation not only specifies where data are stored, but also where they are processed. Art. 4 DSGVO also states that the term data processing includes any inspection, modification, transfer or storage of personal data. Accordingly, the choice of data storage in the EU is in principle irrelevant in itself if the processing continues to be carried out thereafter by, for example, support staff from other countries.

If data processing is therefore to be restricted to a certain region in accordance with the DSGVO, it is accordingly not sufficient to simply transfer the data to this region for technical reasons. Only when all data processing is also carried out within this region or regions considered to be equivalent does Data Residency take effect from the point of view of data protection. However, data residency naturally has various other advantages, such as better network latency.

Marketplace Apps

Most Atlassian products can be functionally enhanced with apps. Third-party software vendors have the opportunity to extend Atlassian products for additional use cases. In our experience, most customers have a handful of additional apps in use within weeks of going live, as they provide even better support for their use cases. The available apps can be browsed in the Atlassian Marketplace. It is important to know that the vast majority of these apps are not offered by Atlassian but by third party vendors. In the Marketplace the providers are named accordingly.

A special technical feature of the Atlassian Cloud is that these apps are not directly integrated into the respective application as additional program code, as is the case with the Atlassian Server and Data Center deployment models. This means that these programs are not operated by Atlassian, but by the corresponding third-party manufacturer. The latter operates the corresponding app independently at a location of its choice. The app communicates with the corresponding Atlassian product via the Atlassian Connect interface. In order to be able to provide their services, these apps usually have extensive access to the customer data stored at Atlassian. This data is passed on, as otherwise it would not be possible to fulfil the contract.

It is important to note that when using an Atlassian Connect app, the customer is the direct contractual partner of the corresponding third-party software manufacturers and must assume their role as a responsible party in accordance with the DSGVO. Atlassian is not responsible for compliance with data protection at third-party software manufacturers, but will only forward the necessary data via the interface for processing on behalf of the customer. Accordingly, the customer must check compliance with the DSGVO separately for each third-party software manufacturer. It should be noted that many apps are provided by manufacturers who have their headquarters or a branch in countries such as Russia, the Philippines or the Ukraine. Or of course the USA. In addition to data protection, such data transfers are of course also potentially relevant for the protection of intellectual property.

Atlassian has recognized this problem and launched Atlassian Forge as a solution, for which Atlassian will then provide the operational infrastructure. From a data protection point of view, this will make the landscape somewhat more manageable, as the separate IT infrastructure providers as subcontractors of the third-party manufacturers will no longer be required. Whether the DSGVO compliance check or contracts with third-party manufacturers can then be dropped will depend on whether they can continue to have access to the customer data that is then stored by Atlassian. In the special case of European app vendors, data potentially stored in the EU will also have to be exported to the USA, which means that previously assured conformity will no longer be required. Atlassian Forge is currently in a beta program, so not all mechanisms are described in detail yet.

Experience shows that the contracts with Atlassian for the basic product (e.g. Confluence or Jira) are carefully checked by the customers, but when apps are added later on, there is often no legal check of the contracts with these third party manufacturers. We therefore recommend, especially in the case of the Atlassian Cloud, an inventory and review of contracts with app manufacturers where this has not yet been done. Where necessary and possible, DSGVO-compliant contracts should be concluded with these third party manufacturers.

--

linkyard is a Gold Atlassian Solution Partner based in Switzerland and offers a full service around the products. Besides product knowledge linkyard also offers proven know-how in the areas of management, project management (lean/agile and classic), security, compliance, risk management, requirements engineer or software architecture. linkyard also specializes in technically demanding integrations and customers with particularly high demands on information security and data protection. The information security management system of linkyard is certified according to ISO/IEC 27001:2013.