09 Sep 2019
Session Block—Privacy Engineering 11:40 - 12:00

More than 20 years before the General Data Protection Regulation (GDPR), Recital 46 of the Directive 95/46 already highlighted the importance of adopting a proactive approach vis-à-vis data protection requirements. Article 24(1) GDPR now requires controllers to 'implement appropriate technical and organisational measures to ensure and demonstrate compliance with the Regulation', while Article 25(1) GDPR compels them to do so 'both at the time of the determination of the means for processing and at the time of the processing itself' (Data Protection by Design (DPbD)). This requires controllers to (i) perform a comprehensive analysis of the risks posed by their processing operations for data subjects' rights and freedoms, (ii) implement appropriate technical and organisational mitigation strategies into their systems to ensure compliance with the requirements stemming from the Regulation, (iii) demonstrate a certain degree of accountability for the assessment performed and the measures implemented and (iv) ensure the consistency and relevance of the trade-offs made during the design phase throughout the entire personal data processing lifecycle.

Operationalising those provisions requires a close collaboration between software engineers and legal experts. This is illustrated by a large body of knowledge in the fields of: (i) legal requirements engineering, (ii) privacy goals and strategies and (iii) hybrid risks assessment methodologies – be it technically-oriented Data Protection Impact Assessment (DPIA) or privacy-focussed threat modelling methods. There is, however, a significant gap between those practices and the strict requirements stemming from the GDPR. This can be attributed to several factors. First, software engineers – who are tasked with the elicitation and implementation of technical countermeasures – and lawyers – in charge of interpreting and substantiating data protection rules – do not operate on the basis of a common conceptual framework. Second, no methodology currently supports the performance of an exhaustive DPIA while being fully integrated in the traditional software development lifecycle. Third, most existing risks assessment methodologies only propose a limited, field-specific catalogue of countermeasures. Lastly, current privacy engineering methods barely support architectural knowledge management, i.e. the extraction and maintenance of detailed documentation concerning the design decisions and their underlying rationale. Building on the progress made on the PRiSE project so far, the following presentation aims at highlighting those gaps and suggesting ways forward to achieve meaningful, in-depth compliance with Art. 25(1) GDPR.

Outline of the presentation

  1. General introduction to DPbD under the GDPR (Artt. 24(1) and 25(1) GDPR)

    a.The four components of DPbD (literal reading of Artt. 24(1) and 25(1) GDPR)
    b. Interdisciplinarity as a sine qua non (focus on law and software engineering)

  2. Brief overview of previous attempts at reconciling law and software engineering

    a. Legal requirements engineering + gap analysis
    b. Privacy goals and strategy + gap analysis
    c. Hybrid risks assessment methodologies + gap analysis

  3. Presentation of the approach adopted in the PRiSE project
    a. Outlining a common conceptual framework for both disciplines
    b. Developing a legally- and technically-sound methodology for DPbD

    i. Building an architectural viewpoint for DPbD
    ii. Drafting a catalogue of data protection risks and mitigation strategies
    iii. Fostering accountability through architectural knowledge management

Speakers
KU Leuven CiTiP - imec
Doctoral Researcher

Discussions


Discussion not started yet.