Data Protection Compliant in the Atlassian Cloud
It’s already been long established that the Atlassian Server is coming to an end: For about a year now, Atlassian has not offered any new Server-Licenses, Down- or Upgrades are no longer possible and support for them is ending in less than two years. What is left is Data Center Products or the Atlassian Cloud. Companies that do not want to run their own machinery for a Data-Center solution, have to move to the Cloud. But, how was it again with the data protection and cloud providers outside of the EU?
An expert on data and information protection, he explains what to look out for in terms of data protection.
He is a data protection officer and advisor for companies and enterprise groups located in Germany. In addition, he teaches data protection in the master's degree programme in Business Informatics at the Rheinische Fachhochschule Cologne.
Data Protection Requirements
The obligations for companies when handling personal data are set out in various laws such as the EU General Data Protection Regulation (DS-GVO) or the Federal Data Protection Act (BDSG).
Personal data is information that can be assigned to a natural person. At this point, "natural person" means a living, already born human being. Dead and unborn people are not legally included (they are protected under other laws).
The "person" - whose data we are talking about here - must be "identified or identifiable". That is, this person is not an indeterminable individual or any other being that we assume might be human. Rather, this person is known or it is possible with a certain amount of effort to find this individual.
How much "effort" must be made so that a person is considered identifiable is often disputed. In daily practice, it would probably be sufficient if a person could be identified through data files, looking into IT systems, asking colleagues or another department, searching public directories (e.g. telephone book, internet) or taking legal action (e.g. by filing a criminal complaint).
Examples of typical types of personal data in a Jira or Confluence system:
- Contact and core data of users (e.g. names, email addresses, function).
- Individual access data
- Communication data (e.g. chat)
- Activities of the logged-in users within the respective Atlassian application
- Public or private IP addresses of accessing client systems in log files, possibly also of non-logged-in users
- If applicable, further personal data in stored documents
To dispel a rumor: data of people in a professional environment, for example professional contact data on a business card, is just as personal data as it is private contact data. At this point, it makes no legal difference whether it is private or business data. What is decisive here is the personal reference.
In data protection, trade and business secrets are only considered if they themselves contain personal data. However, the business-related secret character is not taken into account. However, requirements for the protection of trade and business secrets may exist on this side of data protection through other laws or also contracts with business partners.
Data protection is about personal data. The use of modern business applications is practically impossible without personal data simply because of the existence of user administrations, electronic communication and technical log files. Some examples of typical personal files in Jira or Confluence can be found in the text box "Personal data".
When introducing and operating an Atlassian solution, the legal and, if applicable, customer-contractual requirements of data protection must be taken into account - just as with any other modern business application. The most basic requirements exist regardless of whether an Atlassian solution is operated on-premise or in the Cloud.
Accountability of those responsible
The company responsible for the respective data is in charge of complying with the legal requirements. The responsible company must be able to adequately demonstrate compliance ("accountability") with the legal requirements in data protection. If a company itself acts as a service provider on behalf of another responsible client, then accountability obligations also exist towards this client. Those who already regularly work for other responsible companies are familiar with the long questionnaires, documentation of technical and organizational measures and order processing contracts that have to be answered by their clients. We will cover more of this in a moment.
Discussions over data protection and Cloud usage.
Entry into the Cloud requires further data protection that must be fulfilled and proven. The two presumably biggest requirements are the subject of many current discussions about the limits and permissibility of using the Cloud.
How does the “order processing” model work at Atlassian?
When using Atlassian Cloud, classic order processing, as described above, is used. Atlassian provides each customer (client) with the commissioned software products in their own virtual environment, separate from other clients, as an operational software-as-a-service solution. This also includes all necessary operational framework conditions, starting from the maintenance and expansion of required hardware, to the maintenance of the server infrastructure, to individual customer support in the event of technical problems or questions.
Atlassian is bound by instructions
Direct contact with the client's company data should not exist and if so, exceptionally. Under normal operation, data storage, backups and other protective measures can take place without Atlassian employees taking note of specific company data. Direct contact with the company data should only take place if the client explicitly requests this, e.g. in the case of a support request regarding a specific problem with the client's user administration. Only then is this contact necessary and also desired. Atlassian undertakes an order processing agreement to process client's data only in accordance with the client’s binding instructions. The instructions framework is defined in the Cloud contract and the included service descriptions. The instruction options that are obligatory for data protection, such as the return or deletion of the company data, are required to be in order processing contracts.
Protection of company data and compliance with standards
In the context of order processing, it must be ensured that the Cloud provider takes appropriate technical and organizational measures to fulfill its contractual obligations on the one hand and to ensure the protection of IT systems and data on the other.
Atlassian has aligned its technical and organizational measures with the international standards ISO/IEC 27001 and ISO/IEC 27018 and is regularly audited and certified in this regard by independent bodies. The company makes the current certificates available for download on its website for testing and documentation purposes.
ISO/IEC 27001 is a standard for an information security management system that aims to ensure the protection of IT systems and data in a measurable verifiable system. ISO/IEC 27018 expands this standard to include the topic of personal data in the Cloud.
Atlassian offers extensive documentation detailing the measures they take concerning security, data protection and compliance on its website, Trust Center. This detailed documentation, but also self-representation, is now common practice and can also be found with the large cloud providers such as Amazon AWS or Microsoft. The official ISO certificates as well as the detailed information on the topic of IT security will certainly be of particular interest for the initial audits of future clients.
Compliance with the standards mentioned here is generally an essential prerequisite for entry into a Cloud solution. And this is where a notable difference becomes apparent in the level of protection companies' self-operated infrastructure provides. The server in one's own business premises feels quite secure; however, according to ISO/IEC 27018 it is rarely audited. On the other hand, the infrastructure of Cloud providers is regularly audited and certified.
Subcontractors of Atlassian
Order processing also includes a look into the back end of the Cloud provider: to the subcontractors used by the Cloud provider.
Atlassian uses Amazon AWS, one of the major global Cloud providers, for a significant part of the Atlassian Cloud infrastructure. The level of security expected by the above standards continues with Amazon AWS. Independent certifications to ISO/IEC 27001, 27018 and other standards are also available here.
Additionally, Atlassian uses other service providers for certain IT services (including email and telecommunications) as well as for customer and product services. Atlassian publishes all subcontractors it uses on its website, and clients can also be informed of any changes via RSS feeds.
Atlassian contractually guarantees to publish changes at least 14 days in advance and grants clients a right to object; in the event of an objection, an individual clarification process is offered. If the client and Atlassian do not find an amicable solution with regard to the use of a new subcontractor, the client has an extraordinary right to terminate.
Solutions of this kind are now considered standard among Cloud providers. Of course, a Cloud provider cannot ask each of its clients individually for permission when a new subcontractor is brought in. However, this solution is intended to provide the client with appropriate transparency and a certain degree of control, which is customary in the industry.
What do companies have to bear in mind when dealing with non-EU countries?
1. EU Commission determines adequacy
The European Commission can issue so-called ‘adequacy decisions’ for countries outside the EU. This certifies that these countries have an adequate level of data protection. If such a decision exists for a non-EU country, European companies may export data to this country.
Currently, such decisions exist for the following countries: Andorra, Argentina, Canada, Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea (South Korea), Switzerland, Uruguay and the United Kingdom.
2. Transfer Impact Assessment (TIA)
For all other non-EU countries, companies that want to use services in connection with personal data in these countries must first conduct an assessment of the legal and data protection situation and the effects of a data export non-EU country and the purpose of the export as well as the need for protection of the data to be exported should be considered and evaluated. Where there are high risks, additional effective protective measures must be taken. Where this is not sufficient, a waiver of this export should be put to the test.
The European Data Protection Authority (EDSA) offers a detailed guide on this topic.
3. standard contractual clauses
For all non-EU countries for which there is no adequacy decision, but for which there is an implemented TIA and, if applicable, additional data protection measures, a further contractual agreement is necessary.
The European Commission has provided contract templates in which data exporter and data importer enter into supplementary agreements on data protection. Unlike an order processing contract, these address the specific circumstances of transferring data to a non-EU country.
The contract templates can be downloaded free of charge from the European Commission's website.
What does Atlassian offer to non-EU countries?
Atlassian enables clients to choose a so-called data residence. Here, the client can specify the geographical storage location of their data in the Atlassian Cloud. There is a choice of locations in the USA, the EU and Australia. However, this specification of a data residence is only available for certain product areas, but is to be further expanded. Atlassian maintains a roadmap for this on its website.
Atlassian does not currently offer a pure EU solution.
1. Adequacy decision of the EU Commission
Atlassian is currently a company in Australia with significant operations in the US. There is currently no European Commission adequacy decision for Australia and the US.
2 Transfer Impact Assessment (TIA)
TIA means looking at what data is transferred to which country, for what purpose, and what risks might exist. The aim is to reduce or eliminate these risks with appropriate measures.
Certainly, such a plan of action is likely to become more challenging if a hospital wants to store its patient records in a Confluence instance in the Atlassian Cloud. However, such plans might not necessarily correspond to Atlassian's typical target group.
Documentation and assistance for the implementation of a TIA are published on the Atlassian website. The explanation on the legal assessment of non-EU countries is particularly interesting.
In addition, Atlassian offers a regularly updated transparency report, which discloses how many requests are made to Atlassian by government institutions and what kind of data Atlassian has actually released. This enables a better assessment in the context of the risk assessment of a TIA.
3. standard contractual clauses
Atlassian has additionally equipped its order processing contract with the required standard contractual clauses of the European Commission. Here, the specific details for the use of Atlassian products have already been made.
The contract for order processing, including the standard data protection clauses, is enclosed in the Cloud contract and is thus agreed together with the Cloud contract. A separate closure is not necessary.
1 cf. lawfulness of processing Art. 5 (1) lit a DS-GVO
2 cf. purpose limitation Art. 5 para. 1 lit. b DS-GVO
3 cf. necessity and data minimisation Art. 5 para. 1 lit. c DS-GVO
4 For the definition of terms in the law, see Art. 4 No. 7 DS-GVO
5 cf. accountability in data protection Art. 5 para. 2 DS-GVO
6 cf. commissioned processing Art. 28 DS-GVO
7 Obligation to follow instructions pursuant to Art. 28 Para. 3 lit. a DS-GVO
8 Deletion and return according to Art. 28 Para. 3 lit. g DS-GVO
9 See "Guarantees of the Processor" Art. 28 (1) of the GDPR and "Technical and Organisational Measures" Art. 28 (3) (c), (e) of the GDPR in conjunction with Art. 32 of the GDPR.
10 Art. 44 ff DS-GVO
11 cf. information on export to a third country Art. 13 para. 1 lit. f DS-GVO
The information in this article is provided for information purposes only. It does not constitute legal advice. In particular, they are not intended to and cannot replace legal advice that takes into account the specifics of the individual case. Insofar as we report on cases, in particular court decisions, their results must not be used to infer a necessarily similar outcome in other cases. We endeavor to select all information provided with care and to update or supplement it as necessary. Nevertheless, we cannot guarantee that the information in this text is up-to-date, complete and correct.