What security measures does the GDPR recommend to protect data?
The GDPR prescribes that controller and processor must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including for instance the pseudonymization and encryption of personal data, Moreover, the GDPR highlights the principles of Data Protection by Design, which means organizations must develop data protection processes and products with privacy in mind from the ground up, and Data Protection by Default which ensures that only personal data that are necessary for each specific purpose of the processing are processed.
How does pseudonymization protect data?
Pseudonymization is a novel concept in data protection, encouraged by the GDPR. It is a technique of processing personal data so that it can no longer be attributed to a specific individual without the use of additional information, which must be kept separately and be subject to technical and organizational measures to ensure non-attribution. Pseudonymous data, together with other security measures such as encryption, reduces the likelihood of identifying individuals, for example in case of a data breach or leak. Pseudonymised information is still considered personal data, but the use of pseudonymisation is encouraged, since it is, among of, a technique which may satisfy requirements to implement “data protection by design and by default”; and it may contribute to meeting the GDPR’s data security obligations.
What is the difference between encrypted data and anonymous data?
While encryption is one of the “appropriate technical and organizational measures” to protect data according to Article 32 GDPR, anonymous data is any data that does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. In other words, encryption relates to security of personal data whilst anonymization refers to permanent de-identification. The GDPR applies to encrypted data but it does not apply to anonymized data.
Is properly end-to-end encrypted data still personal data?
Data controller’s end-to-end encrypted documents, such as a spreadsheet with employee details stored with Tresorit, may contain personal data. As the data controller has the encryption key to decrypt the files, they can re-identify the person the data belongs to. However, from the perspective of the end-to-end encrypted and in particular for data processors like Tresorit, this spreadsheet does not contain any personal data because Tresorit, as service provider, does not have the decryption keys to the files, thus is unable to re-identify the persons. Because of this, using end-to-end encrypted service providers may contribute to the security of processing operation done by controllers, as well as to providers acting as data processors on behalf of them. For example, if encryption algorithm is particularly strong, data controllers will likely be exempted from notifying a personal data breach to the supervisory authority and communicating it to the affected data subjects pursuant to Articles 33 and 34 GDPR.
How does encryption help with protecting data and compliance?
Encryption is underlined as an example of “appropriate technical and organisational measures” and an appropriate safeguard to protect data. The GDPR states that if the controller has implemented encryption to its personal data, in case of personal data breach, affected personal data are likely be unintelligible to any person who is not authorised to access it. Hence, such data breach is unlikely to result in a risk to the rights and freedoms of affected natural persons. The result is that the controller may not be required to communicate the data breach to affected data subjects, pursuant to Article 34 GDPR. All in all, encryption reduces the risks of processing data in the cloud, as it reasonably makes re-identification of leaked personal data impossible with reasonable measures. The more the encryption algorithm is strong, the more it may reduce the liability of data controllers.
Does the GDPR differentiate between different methods of encryption?
The GDPR refers to encryption in several provisions; however, it does not specifically indicate which algorithm (e.g., AES 256bit) and its application (e.g., at-rest, in-transit, or end-to-end). While it does not explicitly talks about encryption methods, the way encryption keys are stored is an important to decide whether re-identification of encrypted data is possible with reasonable efforts. With in-transit & at-rest encryption, the cloud provider has access to the encryption keys, while with end-to-end encryption, the keys are stored at the user only. Because of this, in case of a data breach, re-identification of end-to-end encrypted data with reasonable efforts is infeasible. This way, end-to-end encryption with client-side key management represents a stronger protection for the personal data.
What are the advantages of using end-to-end encrypted cloud services?
If a data controller uses an end-to-end encrypted service as processor, the related personal data ‘stays within their company walls’. Therefore, end-to-end encryption has substantial advantages that helps controllers better protect data, making compliance process easier and cost effective. The data controller will result in compliance with Article 32 GDPR. Secondly, if a strong encryption mechanism is implemented and the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons, the data controller will likely be exempted from notifying the data breach to the supervisory authority and communicating it to the affected data subjects pursuant to Articles 33 and 34 GDPR. Moreover, except the duties of assistance to the controller pursuant to Article 28 GDPR, the processor will likely fall out of the audit scope in case the controller is audited, making compliance and audit process simpler for the controller.
How does the GDPR affect organizations who store and share personal data with cloud-based services?
The GDPR’s aim is to protect personal data at all stages of data processing. The GDPR identifies two different entities that both have obligations: data controllers and data processors. A controller is the entity that determines the purposes, conditions and means of the processing of personal data. For example, educational and research private and public institutions, healthcare services, or any business that manages the personal data of their employees and customers. A data processor is an entity which processes personal data on behalf of the controller, such as a cloud provider (for example a Software-as-a-Service like CRM software).
Are data controllers responsible for their data managed by data processors?
Yes, data controllers are responsible to protect personal data whenever they use third-party services (data processors) to manage data in the cloud, and therefore should use services that provide the highest protection. With the GDPR, all data processing must have a lawful basis, such as explicit consent from the persons (“data subject”). Data controllers must further process data with third-party processors by protecting data in a compatible way with the original legal basis and applying safeguards like encryption.
What kind of personal data does Tresorit process on your behalf?
Because of our client-side encryption, we cannot access our users’ encrypted content and we cannot use encrypted information to identify any individual. Accordingly, under the GDPR, such content is not deemed to be personal data from our perspective. However, when providing our services, we process certain non-encrypted data including personal data relating to the users administered by our users (e.g. such as user names, email addresses, file activities and login-in attempts). With respect to such limited data, we act as a data processor. Our DPA covers this very limited personal data we have on our customers, while the data in customers’ files fall outside the DPA’s scope.
Who should execute a DPA with Tresorit?
You need to execute our DPA if you have a business subscription with us and the GDPR applies to you. The latter question is something that has to be assessed on a case by case basis, with the involvement of a legal counsel. However, if you run a business and use Tresoirt for business purposes, and you, your partners or employees are located in the EU, it is very likely that you are subject to the GDPR.
How to execute a DPA with Tresorit?
You need to be a Subscription Owner to be able to access billing details and initiate the DPA-signing process. The below guide shall walk you through all the steps of the process.
Does it matter that Tresorit is a Swiss company, as Switzerland is not a member of the EU?
Tresorit falls under Swiss jurisdiction. Switzerland was granted a data protection adequacy status by the European Commission, in order to ensure the free flow of personal data from the EU into Switzerland and vice versa. The Swiss data protection authorities are now working on updating the Swiss data protection regulation to maintain this adequacy with the GDPR.
Personal data stored in Tresorit may be transferred outside the place of establishment of the data controller to countries of the European Union or to countries outside the European Union.
Specifically, files uploaded into Tresorit are stored in Microsoft Azure servers located in the European Union (i.e., in Ireland and the Netherlands).
Tresorit uses services performed by third parties not located in the European Union for the purpose of customer invoicing, support, etc. All third parties engaged by Tresorit: a) are established in a country that received an adequacy decision from the European Commission; or b) have signed Standard Contractual Clauses provided for by the European Commission.
In all the above cases, transfers of personal data are and will be made by Tresorit only in compliance with the provisions set forth by the EU Regulation 2016/679 (General Data Protection Regulation, “GDPR”).