Dr. Judith Nink works as the Data Protection Officer and Head of the Advocacy & Industry Relations Department at eyeo. She explains why companies should pay attention to GDPR compliant tools in times of corona and why the principle of privacy by design shouldn’t be underestimated.
Privacy by design – meaning taking privacy into account throughout the whole engineering process – is a concept that was developed 10 years ago by the former Information and Privacy Commissioner of Ontario, Ann Cavoukian.1 In 2018, when the GDPR was becoming effective, Privacy by Design was for the first time an enforceable concept in the European Union (EU) and for the member states of the European Economic Area (EEA). Violations can be punished with fines of up to EUR 10,000,000 or up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher.2
Nevertheless, the obligations of controllers3 to comply with the principle of privacy by design seem to be either falling under the radar of many companies or are just not as prominent as popular and visible obligations like information requirements or data processing agreements. The following will engage with why the principle of privacy by design shouldn’t be underestimated.
Most office-based companies have relaxed their home office rules. Some, like us at eyeo, have even changed their policy to ‘remote only’ during the current crisis. This means that even for remote-friendly companies, there is an increase in remote meetings.
For office people like me, video conferences have at least tripled. Some days, I spend all day in different video conferences. To make that work, get the most out of these meetings, support team building and help us focus, we are now using, in addition to our video conferencing tool, various remote facilitation tools. All of these tools are processing our employees’ personal data and – if used for meetings with externals – partner and/or service provider data. As not all of these tools are or can be hosted on our servers, we do not, by nature, have full control over the data processing handled by the providers of these tools.
The expansion of home office and the heavy use of facilitation tools leads to more data processing by third parties, leading to less control and therefore higher risks for data breaches. A prime example of this is the popular video conferencing tool Zoom. They became popular as they were and are providing, already before the crisis, features making remote meetings more convenient, even if – or maybe partially because (?) – default settings are not very privacy friendly and the design is neither explicitly privacy nor security focused. When the Corona crisis started, they became a very popular choice, but they also got more attention, not only from potential users and security & privacy experts but also from attackers.4 Hence, Zoom did not only allow greater privacy exposure in its default settings but has been a major security risk for Windows users, as it caused Windows to send a person’s Windows login name and their NTLM password hash, which can be cracked using free tools and reveal someone’s password.5 What this means for any (confidential) company information, like trade secrets, one could easily imagine.
… not the developer and/or the producer to implement privacy by design.6 Looking back at the initial concept of Ann Cavoukian, which requires privacy by design to be embedded into the design and architecture of IT systems (as well as business practices)7, there is quite a gap between the original concept and what has been implemented in the GDPR. This has been criticized by privacy experts, since the influence controllers have to comply with privacy by design in connection with proprietary third-party tools is quite limited.
Nevertheless, under GDPR it is one of the core responsibilities of a controller to “implement appropriate technical and organisational measures to ensure and to be able to demonstrate that [data] processing is performed in accordance with this Regulation” (GDPR Art. 24(1)). This pretty vague wording is defined in more detail by the requirements of considering privacy by design and implementing privacy by default (GDPR Art. 25). Accordingly, the controller is obliged to implement measures to meet these principles, such as “minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features”8.
There is no final catalogue on what the right measures are to comply with privacy by design. But the regulator expects measures to be ‘appropriate’. This means “taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing9” (privacy by design) and further “ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed10” (privacy by default).
As already said, the controller is usually not the developer of remote facilitation tools and most of the tools are proprietary software, not allowing code changes. Hence, the measures to ensure privacy by design are limited. But what the controller, meaning a company using such tools, can do to comply with this principle is select the tool and/or provider carefully.
The GDPR does not require selection of the most privacy-friendly tool but rather one which has implemented appropriate measures to protect personal data, “taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing” and providing you with the option to change/adapt default settings to protect personal data.
In a nutshell, even if developers and producers are not directly obligated by the privacy by design principle, they are indirectly duty-bound as the controller should choose only a tool which has already implemented sufficient technical measures to protect personal and to allow privacy-friendly default settings.
This may sound complicated but it actually is not. As the Data Protection Officer must be involved in new data processing procedures anyway (GDPR Art. 38(1)), this can be combined with the implementation of a tool review process. Such a review process can be – depending on the respective structure of a company – e.g., either conducted by a dedicated Security & Privacy team, as we have it at eyeo, or jointly by the legal and IT teams.
Among documentation and legal documents, the selection process of an appropriate provider/tool should always include some research on current and past vulnerabilities, data breaches and general values of a company towards privacy and security. Of course, this does not guarantee you hundred-percent safety, but it reduces the risks of exposing personal data and confidential information.
Resources:
1Cavoukian, Privacy by Design – The 7 Principles, January 2011, available at: https://iapp.org/media/pdf/resource_center/pbd_implement_7found_princip….
2GDPR Art. 83(4)a.
3GDPR Art. 4(7): “controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law”.
4https://www.windowscentral.com/zoom-vulnerability-can-leak-your-windows….
5https://www.windowscentral.com/zoom-vulnerability-can-leak-your-windows….
6GDPR Art. 25(1).
7Cavoukian, Privacy by Design – The 7 Principles, January 2011, available at: https://iapp.org/media/pdf/resource_center/pbd_implement_7found_princip…, 3rd principle.
8Recital 78 GDPR.
9GDPR Art. 25(1).
10 GDPR Art. 25(2).