Anastasiya Kazakova , Public Affairs Manager
Igor Kumagin , Senior Project Manager
Approaching the end of the year, we couldn’t help but applaud the efforts taken by the European Data Protection Board (EDPB) in publishing its Guidelines on Data Protection by Design and by Default (DPbDD), which have been updated after the public consultation with industry and the technical community (you may find the first version here).
We at Kaspersky took part in the consultation and shared some observations to strengthen consistency with Article 25 of the General Data Protection Regulation (GDPR), as well as provide greater clarity on practical steps which organizations need to take for implementing the GDPR principles and achieving the DPbDD.
Having shared our comments on January 16, 2020 (and of course having no clue as to what the year 2020 would hold!), we are happy to see significant improvements in the final document as a result of the feedback from industry, non-for-profit associations, and individuals.
Below we provide a summary of how the text has changed.
Data protection by Design and by Default (DPbDD): is it a single concept or two separate concepts?
The 2019 draft of the Guidelines discusses the concept of the DPbDD in two separate sections (2.1. and 2.2.), and we noted that it should remain a single, uniform concept, as per the definition expressed in Article 25 and Recital 78 of the GDPR. In the final document we see the additional comment clarifying that the DPbDD is ‘complementary concepts, which mutually reinforce each other. Data subjects will benefit more from data protection by default if data protection by design is concurrently implemented – and vice versa’.
It is difficult to say whether the EDBP’s explanation and our initial understanding are different: if by-design and by-default elements are complementary by nature, it neither contradicts, nor supports the proposal to keep the DPbDD as a single and uniform concept.
However, we are not sure whether data protection by default can precede to data protection by design. In our view, security is designed first and then it is enhanced to ‘by-default’ mode to grant higher security and assurance. What is more, we note that both ‘design and default elements’ are kept together and not differentiated in section 3 (so it is difficult to say what elements listed under each principle should be considered as ‘default’ or as ‘design’).
Nonetheless, we note that in the final guidelines the EDPB provides its view on the DPbDD, which was missing in the first version.
Practical guidance to implement principles as prescribed by the GDPR
The 2019 draft states that ‘in all stages of design of the processing activities, including tenders, outsourcing, development, support, maintenance, testing, storage, deletion, etc., the controller must take into account and consider the various elements of DPbDD […]’.
Our understanding is that principles and security measures (technical and organizational ones) should be separated in the guidelines for greater structural and methodological consistency. We read Section 3 as the section with practical steps for controllers to implement data protection principles, and in this regard, to us, the inclusion of certain principles – such as the principle of fairness or the principle of transparency – seems counterintuitive: the draft guidelines explain each principle with detailed key design and default elements, but do not give practical instruction to data controllers on implementing the principles, and each element is read here as an improvement order or direction for a desired action, but not as a practical guide.
Therefore, our recommendation was to frame principles as a separate section to convey them as intentions that establish the mind-set for controllers for implementing data protection by design and by default.
The updated document provides a new sentence: ‘In all stages of design of the processing activities, including procurement, tenders, outsourcing, development, support, maintenance, testing, storage, deletion, etc., the controller should take into account and consider the various elements of DPbDD which will be illustrated by examples in this chapter in the context of implementation of the principles. Controllers need to implement the principles to achieve DPbDD. These principles include: transparency, lawfulness, fairness, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability. These principles are outlined in Article 5 and Recital 39 of the GDPR’.
We applaud the EDPB’s efforts in providing greater clarity on how the guidelines in section 3 should be interpreted by controllers in implementing principles through particular technical and organizational measures. At the same time, the EDPB keeps principles and elements together, and some elements are read as an improvement order or direction for a desired action, but not as a practical guide to implement the principle.
Lack of clarity about ‘technology providers’ has been avoided
In the Executive Summary (Scope) of the 2019 document and thereinafter, the draft guidelines introduce a definition of technology providers, which are not directly addressed in Article 25 of the GDPR, but are recognized as key enablers for the DPbDD. The fact that the GDPR does not mention this definition, inevitably leads to methodological ambiguity and inconsistency as the guidelines recognize them as additional ‘key enablers for DPbDD’ (paragraph 85) – distinguishing them from both processors and controllers – but at the same time the document does not clearly define who is to be implied under these providers or how different their legal status, obligations or roles are from those of processors and controllers.
In the updated Guidelines we do not see the notion of ‘technology providers’: the document keeps the notion of ‘producers of the products’ in line with Recital 78 of the GDPR.
Once again, we applaud the EDPB’s decision to maintain consistency in definitions and terminology between guidelines and the GDPR, and thus to remove the notion of ‘technology providers’, which are not mentioned or defined in the Regulation.
Clarification of the ‘state of the art’ organizational measures for controllers
Paragraph 21 in the 2019 draft mentions a ‘state of the art’ criterion, which applies not only to technological measures, but also to organizational ones. Lack of adequate organizational measures can lower or even completely undermine the effectiveness of a chosen technology. As a comment, we deemed it necessary to clarify in the draft guidelines which ‘adequate organizational measures’ are implied here.
The updated Guidelines add clarity on what can be considered as the ‘state of the art’ technological and organizational measures, and say that ‘examples of organizational measures can be adoption of internal policies; up-to date training on technology, security and data protection; and IT security governance and management policies’. We believe this is a great improvement to enable effective implementation of the Guidelines.
