Privacy and DPIA, a tough challenge
4 min leestijd
DPIA stands for ‘Data Protection Impact Assessment’ and is one of GDPR’s tougher challenges. When is there a DPIA really needed? How do you go about conducting a DPIA? And how to assess key elements as impact and the likelihood of incidents in an objective way? The Privacy Focus Group addressed these questions in two highly interactive sessions chaired by Jan Léonard, DPO at Orange Belgium.
Privacy and DPIA, a tough challenge
Article 35 of the General Data Protection Regulation (GDPR), which covers DPIAs, requires data controllers to “carry out an assessment of the impact of the envisaged processing operations on the protection of personal data, prior to the processing,” where that processing, and in particular the use of new technologies, is “likely to result in a high risk to the rights and freedoms of natural persons.” Any DPIA should at least assess (among other aspects) the risks to these rights, as well as the measures envisaged to address the risks.
It is about the data subject
This immediately raises questions about scope and when to do a DPIA. While an assessment may cover other domains, the primary focus must be the ‘data subject’, as this is the focus of the GDPR. Also, the decision whether or not to do a DPIA should be clearly documented (particularly if it is ‘no’), in order to answer queries by the Data Protection Authority (DPA). There are many elements that can trigger a DPIA: introducing a new technology (yes, AI was mentioned…), or a technology with known high risks (e.g., biometrics); changes in your record of processing activities; or simply a regular review after a certain period of time (e.g., every 6 months in case of a high risk, or else up to 2 to 3 years).
Step by step
Conducting a DPIA should involve applying a consistent method, whether a general method or one more specific for your kind of activities (guidelines are available, as are methodologies and frameworks – in these sessions a method developed by the telco operators was discussed). These steps include building a team (broad based, including business people as well as IT, with the Data Protection Officer/DPO as facilitator); defining the scope and why of the DPIA (justify the decisions!); involving external stakeholders (e.g., key external processors – not required but a good practice); up to having the DPO formulate an advice. This advice must include information on any remaining risks regarding compliancy with the GDPR.
Commitment required
Following on from this advice, there must be a formal approval at the management/executive level. This approval must include a commitment to investment resources and a plan for implantation of mitigation measures! In the event of an incident, there’d better be clear documentation of why elements of this advice were not implemented (depending on the risk appetite of the company). Obviously, the implementation of the measures needs to be monitored and controlled (and documented). Throughout all of these steps, there is one absolute must: document, document, document… and be prepared to communicate in full transparency with the DPA, when needed. Also, as the person responsible for the DPIA, always communicate in full transparency with the business and management side of the organization (including for example the risks to the company in the event of incidents).
IF no context, THEN no go
Early on in the DPIA (after the team has been formed), a step of the highest importance must be taken: define the context of the project/activity to be assessed! What kind of processing, what is the need for this processing (e.g., businesswise); which technology/ies are to be used and what are the risks; the ins and outs of the processes; the data map and where are the data; the parties involved and more. There needs to be a clear and complete view of everything involved in the project. This step may take the most time, but do not skimp on it, or on the number of people. Without the full context, don’t even proceed with the DPIA!
Towards an objective DPIA
At the start of the assessment phase of a ‘Data Protection Impact Assessment’ (DPIA), the main challenge is ‘how to assess the risks in an objective way’? This was the challenge discussed in the second DPIA-session of the Privacy Focus Group. All too often, risks are assessed on a… ‘gut feeling’ basis, which can hardly be called ‘objective’. This can even be problematic, if and when this assessment is challenged by third parties, such as the Data Protection Authority (DPA), in the event of an incident.
Go for a framework
In order to maximize objectivity, the use of a framework is advisable. In this session, the examples were based on the French CNIL impact framework, but other options exist (e.g., ENISA). The use of a framework helps to define specific risks for the data subject, as this is always the focus of an assessment. In addition, a framework provides a solid basis for your explanations (e.g., to the DPA) why you have made a specific assessment. Adapting the framework towards a more sector-oriented approach is possible.
Several starting points were discussed during the session, such as starting from the actual business activities/processes, or from the assets (and risks associated with these assets) used in the processes. The specific way in which a method and framework are applied can change throughout the years or be replaced by others. Therefore, periodic (or triggered) reviews may be advisable.
Basic advice: do use a method/framework and use it ‘as is.’
More need for objectivity
Defining risks is one aspect, but the potential impact of specific risks also needs to be assessed. What is the impact on one data subject, or on all of them? What is the result of a direct impact (e.g., address info is leaked)? What are possible indirect impacts (secondary consequences of a leak) and do you take responsibility for them? Clearly, different approaches are possible, but again, document your rationale. An even greater challenge is objectively to determine the likelihood of an incident/breach/problem etc. occurring. Many elements can be taken into account, in particular the frequency with which specific types of incidents occur (e.g., within the company, in the sector, etc.). Other aspects include changes to the security infrastructure (new tools, etc.), threat intelligence (e.g., new hacking tools, new vulnerabilities, etc.) and more. Also consider the ‘maturity’ of the company relating to privacy, security etc. (more maturity should mean less likelihood…).
Mitigation
The above considerations should provide an additional basis for deciding on the needed proactive security and mitigation actions. Decisions that must include confirmed investments/budgets and timelines for these actions! Other measures should include continued efforts raising awareness in the company about responsible and sensible use of personal data (e.g., teaching them that more data or ‘all the data you can get’ is not better, but rather a major threat). Put all of this in a risk mapping, to help the company see ‘where it is’, as a starting point for a better privacy posture.
Does this sound like two (or too) complex sessions on DPIA? A future session will ‘make it more practical’, based on a real use case.
