So far, few have really “dared” to conduct a Data Protection Impact Assessment (DPIA) in accordance with Art. 35 of the GDPR. Thus, you can rarely find information about it (at least really good information).
We have dealt intensively with the topic of the Data Protection Impact Assessment. Therefore, I want to summarize the insights, procedures and recommendations in a compact and understandable way in this article.
There is no such thing as “the one”, the right or wrong approach to conducting a data protection impact assessment. In addition to the GDPR, there is even an international ISO standard on the subject. ISO/IEC 29134 (Guideline for privacy Impact assessment) provides a set of rules for this purpose.
For our readers and customers, I want to present a solution which meets the legal requirements, but which on the other hand is also practical and feasible.
Digression on risk management
Before we go into detail about DPIA, it is essential to understand the basic pillars of risk analysis. Indeed, the privacy impact assessment is nothing more than a risk assessment. Therefore, I would like to briefly go into the basics at this point. For a detailed description, see our blog article about performing a risk analysisis.
Definition of risk
In the definition of risk, I follow the common standard, which can also be found in the ISO 31000 standard. A risk is defined as follows:
risk = damage x probability of occurence
An important requirement when conducting risk assessments — whether DPIA, hazard assessment, medical or other risks — is the systematic approach as well as reproducibility.
That is, if two people with the same knowledge were to assess the same risk, they would have to come to the same conclusion. With the above definition of harm and probability of occurrence, this becomes difficult. People who evaluate risks therefore need to be given some guidance.
As a rule, one uses classes to evaluate damage and probability of occurrence. In turn, these classes must be described very clearly. For a detailed example, see our article about risk analysis.
Preceding definitions for privacy impact assessment
As just mentioned, you need to consider how to specifically define harm and likelihood of occurrence before setting out to capture possible risk scenarios.
I tried to orientate myself on the case study DPIA of the State Office for Data Protection in Bavaria .
However, I am not quite happy with that. The probabilities of occurrence are not very concrete. Moreover, the possible damage categories, damage and cause are lumped together. In my understanding, the unauthorized removal of pseudonymization does not constitute harm, but rather a cause that can lead to harm (e.g., discrimination, identity theft…). For this reason, while I try to follow the recommendations of the State Office for Data Protection and the DPIA, I adapt them slightly in one place or another.
IMPORTANT! The following classes of loss and occurrence probabilities are purely illustrative. Check if they make sense to you at all and adjust the definitions.
Categories of damage
For the most part, I find the specifications from the State Office for Data Protection very good – so I adopt them here. The list is expandable, but it provides a good start.
- discrimination
- identity theft
- danger to life
- existential risk
- financial damage
- reputational damage
- exposure
- loss of job
- disclosure of secret
- social disadvantages
- economic disadvantages
- …. other damage categories possible
Definition of damage classes
However, in order for us to evaluate when a damage is low or high for the affected person, we need other criteria. Of course, you can classify these criteria differently. Just consider this as an implementation proposal and adapt it to your needs – as already mentioned above.
| low | manageable | substantial | high | |
| discrimination | discrimination against the affected person in a part of his life (e.g. job by colleagues) | discrimination against the affected person in the entire living environment | ||
| identity theft | identity theft | |||
| danger to life | danger to life | |||
| existence endangerment | existential endangerment | |||
| financial damage | within a monthly salary | within several months’ salary | within the framework of an annual salary | loss of all personal financial assets (incl. real estate, etc.) |
| damage to reputation | damage to the reputation of the person concerned in one area of his life (e.g. professional) | damage to the reputation of the person concerned in the entire living environment | ||
| exposure | exposure of the affected person in a part of his life (e.g. professional) | exposure of the affected person in the entire living environment. | ||
| loss of job | loss of job | |||
| disclosure of secrets | disclosure of secrets affects a part of the person’s life. | disclosure of secrets affects the entire life of the affected person | ||
| social or economic disadvantages | no or very low impact in daily life | effects are noticeable for the affected person and lead to small restrictions/disadvantages | effects have disadvantages for the affected person in daily life. | effects have big disadvantages for the person concerned and possibly for his personal environment (e.g. family) |
Definition of occurence probabilities
Here, I name the classes low to very high – as is usually the case in risk analysis. You are, of course, free to name them as you wish.
| Occurence probability | Estimate for the future | Looking into the past |
|---|---|---|
| low | Incident will occur in 6 years or later at the earliest | Incident has never occurred or occurred more than 6 years ago |
| medium | Incident will occur in the next 4-6 years | Incident has occurred in the last 4-6 years |
| high | Incident will occur in the next 1-3 years | Incident has occurred in the last 1-3 years |
| very high | Incident will occur in the next year | Incident has occurred in the last year |
Definition of risk classes
The risk is derived from the class of damage and the class for the probability of occurrence. In order to be able to calculate a risk value, we store a mathematical value for each class. You can determine this value as you wish, so it can just as well be 10, 15, 20 or 100, 200, 300. The only important criteria is that we are able to easily calculate the risk.
When is a risk involved?
It is important to define when a risk is really a risk before performing the DPIA. It should be clear what risk needs to be addressed. In our example, we define that risks up to value 3 are automatically accepted. This means for example that risks with a low level of damage and a maximum of a high probability of occurrence are accepted (see graphic below).
We classify risks with values between 4 and 8 as medium risks which require risk treatment. All high risks with a value greater than 8 require mandatory treatment.
For more basics on risk treatment, read our blog post on risk analysis.
Ok, enough with the groundwork. Let us finally start with the actual data protection impact assessment.
Starting point procedure directory
Before the topic of DPIA is even brought up, first and foremost a procedure must be described in the record of processing activitites. The better your documentation in the procedure description, the more work you save when performing the DPIA.
Overlap of procedure directory and DPIA
Article 35 (7) lit. a GDPR requires a systematic description of the intended processing operations, the purpose and, where applicable, the legitimate interests pursued by the controller.
Article 35 (7) lit. b GDPR adds to the requirement an assessment of the necessity and proportionality of the processing operations in relation to the purpose.
The experienced creator of a manual of procedures will be pleased: “Great, we’ve already described all this in the processing directory.”
Well, the assessment of necessity and proportionality may not be described in such detail, but that can still be individually added to the purpose description, should a DPIA be required.
Departure from the procedure directory to the DPIA
Since it is our goal to avoid redundant (i.e. duplicate) data with the DPIA, we link the directory of procedures to the DPIA right away. That is, in the attached Excel template, the data protection impact assessment is a separate spreadsheet in the procedure directory.
How is the “threshold” determined at which a data protection impact assessment becomes necessary in the first place?
From my point of view, this is actually the most difficult question. After several discussions with experts and the authority, my proposal is now based on two steps.
Threshold analysis for privacy impact assessment
Threshold analysis 1st step – harm
So far, we have described the procedure in the procedure directory and documented it as well as possible. At this point, we are now dealing with the potential damage in the procedure directory that could possibly exist for the data subjects.
All we are really interested in here (with regard to the DPIA) is whether the procedure poses a high risk to the rights and freedoms of natural persons.
The potential damage must be high and so must the probability of occurrence. This combination now results in a high risk for the data subject corresponding to a high harm and a high probability of occurrence.
With regard to the pattern at the end of this article, you have to consider whether a high harm for the affected person is possible at all. In the pattern, I still distinguish between a “substantial” damage and a “high” damage. Here I borrow from the damage classes described above.
If you are potentially considering a high or substantial damage, it is necessary to also think about the probability of occurrence. If the probability of occurrence is low, there is also, as we know, no high risk. In the pattern again the mentioned classes for the probability of occurrence are available.
So now you have determined whether there is a high risk to the rights and freedoms of data subjects. If yes, we go to the 2nd step of the threshold analysis. If no, we have added an important piece of information to the procedure and can thus justify at any time why we have not carried out a data protection impact assessment.
Threshold analysis 2nd step – Further assessment criteria for the necessity of a privacy impact assessment
Recital 91 lists in great detail when a DPIA must be conducted. We have already met the first requirement at this point: that it must be a high risk to the data subject.
Further evaluation criteria can be divided into four main points.
- Special features during processing
- processing of a large amount of personal data
- processing involves or may involve a large number of individuals
- use of new technology on a large scale
- processing makes it difficult for data subjects to exercise their rights
- processing makes it difficult or impossible for the data subject to use a service or perform a contract
- processing of data of vulnerable individuals
- Automated decision making in relation to natural persons
- by systematic and in-depth assessment of personal aspects of natural persons on the basis of profiling of personal data
- by processing special categories of personal data
- by processing biometric data
- by processing data on criminal convictions and offences and related security measures
- Surveillance of areas
- wide-area surveillance of publicly accesible areas (by means of optoelectronic devices)
- Assessment of the supervisory authority
- Competent supervisory authority has published the procedure on the DPIA blacklist
If you can answer “yes” or “applies” to at least one of these four items, I recommend that you conduct a data privacy impact assessment.
Point 4 “Blacklist of the supervisory authority” alone does not represent (according to a telephone statement of the Bavarian supervisory authority) a compelling condition for the execution of a data protection impact assessment. This must always be preceded by a high risk for the data subjects. But this is the case now, because otherwise you would not have gone to the 2nd step of DSFA relevance.
Advantage of this 2-level threshold analysis
What I like about this 2-step solution — without self-praise — is the traceability and the systematic approach throughout. Every procedure – no matter how trivial – is subjected to risk assessment in terms of high risk. This eliminates the need for “manual” pre-selection without a comprehensible and documented decision. The same evaluation rules apply to every procedure.
To save effort, one only goes to the 2nd step of the threshold analysis if one can prove a high risk in the procedure directory. For all other procedures, the assessment for the necessity of a data protection impact assessment is omitted.
Performing a privacy risk assessment with template
As mentioned at the beginning, the DPIA is a detailed risk analysis. Actually a nice thing once you get comfortable with risk analysis. I’m a fan of it, anyway.
In the following, I describe what I consider to be useful information for a good risk analysis.
The following procedures are based on ISO 31000 and are also found in ISO 27001.
When it comes to DPIA, things can get complex in terms of content. Plan a team to identify, analyze and assess the risks. You should not do this on your own. The result can only be of high quality if you request the necessary expert input from all the departments involved.
Information from the procedure directory
As explained above, we take the contents one-to-one from the procedure directory. Adjustments are made directly in the procedure directory, if necessary.
Notes on the excel template:
For the Excel template in the appendix, this means that you access the contents of the procedure with the following command:
=procedure directory!D3
D3 in this case stands for column D3. If the procedure is in a line further down, replace the 3 with the corresponding line number. In column D you will find the procedure name, in column E the description, in column F the legality. The groups of persons can be found in column I and the data categories in column.
At the outset, a privacy impact assessment is likely to have more than one risk scenario being assessed. Therefore, subsequent fields must be completed for each scenario.
But what exactly is a risk scenario?
A simple question, but in practice it is not so trivial to answer. A risk scenario is composed of several pieces of information. It is not only about the scenario itself, i.e. the incident (e.g. earthquake), but also about what this incident can ultimately trigger.
But more in detail about this in the following paragraphs.
Description of a possible incident
What is the worst case scenario that could happen? For example, the failure of the IT system which stored personal data. This is the incident or as we would say according to ITIL, the incident or security incident.
From my experience in performing risk analysis, many stop at this point. However, in my view, that is not yet a risk. It only becomes a risk with the statement, “…leads to.”
Description of the damage
Alone the failure of an IT system does not necessarily entail damage. Let’s compare it to the failure of an IT system for payroll. An outage would not be a problem for most companies 15 days a month. Damage only occurs when it goes down on the exact other days when the HR department wants to run payroll.
That is, in order to make a loss at all tangible, I recommend that you think about the “…leads to”. What might the failure of the IT system lead to? What harm might it cause to the person affected? If we consider a hospital, then a failure of the IT system would lead to perhaps not being able to properly care for patients.
Cause of occurence
This is information you don’t find in many risk analyses. However, I consider it very important and helpful for understanding the scenario and for possible actions.
But what is the cause / reason / vulnerability? What causes the incident to occur in the first place? If we look again at the failure of the IT system, we quickly come to the conclusion that a failure of the IT system can have many reasons. It may be because the power in the data center has failed. But it can just as easily be a technical defect in the server. Each of these reasons probably needs to be addressed with different measures. For our data protection impact assessment in Excel, this means we copy this scenario (IT system failure) into a new row as many times as necessary until we have identified all causes.
Damage assessment
Only with the specific description of what the potential incident could actually lead to can the damage also be quantified. Let’s look again at the hospital whose IT system fails and patient care is affected as a result. Patient care would then be the potential harm to be assessed.
The hospital is a good example. Certainly, an IT system is not introduced without first considering basic protections around availability, confidentiality, and integrity. That is, in most cases, there are already measures in place that take effect to reduce the damage or the potential probability of occurrence. You should, of course, include these existing measures in your assessment of the damage.
We defined damage classes quite exemplarily even before the DSFA was carried out. We now refer to these.
In our table, life hazard is marked with a “high” damage. We want to adopt that as well then.
Probability of occurence
The assessment of the probability of occurrence usually refers to the cause, which fortunately we have considered explicitly. However, this also means that each cause may have a different probability of occurrence. Determining this probability of occurrence is a bit like looking into a crystal ball. Sometimes it can be helpful for the evaluation to look at recent events.
As with damage assessment, existing protective measures should be included in the assessment for probability of occurrence. A highly available system distributed across two locally separated data centers obviously mitigates the probability of occurrence of a complete IT service failure.
We set the probability of occurrence of a power failure leading to IT system failure to “medium”. There is a redundant power supply in two separate circuits that minimizes the failure.
Additional data for privacy impact assessment
Ok, now we could already calculate the risk. We have assessed the harm and thought about the probability of occurrence. The Article 35 of the GDPR additionally wants to know if there are rules of conduct according to Article 40 and if so, if they are respected. I think in most cases there are no rules of conduct approved by the authorities yet. Therefore, this point is probably omitted for most of them. For the sake of completeness, however, I would like to mention it and include it in the sample.
In the end, implemented rules of conduct are nothing more than protective measures. Thus either the potential damage or the probability of occurrence is reduced. Therefore, indirectly, this value should actually be reflected in the evaluation.
My sample in the appendix still contains two fields “confidentiality / integrity” and “availability”. This even goes already in the direction of ISO 27001, but also helps to classify the risk scenario. Nevertheless, it is rather “nice to have” in the first step.
More importantly, I would like to mention that for an availability risk, you specify in the scenario description how long the outage you are evaluating lasts. The maximum possible damage depends strongly on the downtime duration. You may even need to look at a failure scenario with different downtimes more often.
Risk score
Finally, we have all the data together. Since we worked exactly and did our preliminary work well, the risk is now determined quasi-automatically using the risk matrix. According to the damage class and the selected probability of occurrence, we get a value for the risk.
In our example from the figure, substantial potential damage and a high probability of occurrence result in a “red” risk, which we defined as high.
Risk handling in privacy impact assessment
So that means we need to do a risk treatment for this scenario. Again, just to recap what can a risk treatment looks like see blog post risk analysis.
- Minimize: By either reducing the potential harm or the probability of occurrence through additional measures
- Eliminate: Avoiding the occurrence of the scenario completely
- Transfer: Transferring the risk to someone else (e.g., insurance companies). I have my doubts whether this makes sense in the processing of personal data, however. But for the sake of completeness, I mention this risk handling option here. In terms of personal data and the person behind it, you have to weigh very carefully whether the transfer of the risk protects the data subject.
- Accept: Works in general risk management, but not in DPIA. Recitals 90 and 94 of the GDPR only address minimizing and mitigating.
- The 5th variant “Ignore”, which a student suggested to me in the lecture, I mention once, but “ignore” it 🙂
Let’s go back to the hospital example above. The outcome was high risk (substantial harm, high probability of occurrence).
Now it is time to look at additional protective measures. Perhaps an emergency generator could be useful as an additional protective measure. A measure that one does not afford “on the side”. It’s about cost, it’s about human resources, and most importantly, it’s about reducing risk.
For this reason, it must be re-evaluated whether the proposed action will mitigate the risk at all. It may be that it changes the harm or the probability of occurrence. Both are possible. To the extent possible, I recommend that you think about measures BEFORE you discuss the result of the privacy impact assessment with management.
Release of the privacy impact assessment
Management is always responsible for the processing of personal data. For this reason, it is inevitable that you discuss the results with the management. Since you have already thought about possible additional protective measures in advance, you can also address these at the same time. Obtain approval or at least clarify further steps. This will give you concrete guidelines for action. Do not forget to document the results with management. You can also add this to the Excel sample of the DPIA. That way, you have all essential information in one place.
Implementing risk treatment suggestions
You have now clarified how to proceed. Implement the measures. Don’t forget to check if the measures are as effective as you expect them to be. So test the measures and document your results.
Privacy impact assessment report
You can often read about a privacy impact assessment report form. After all the points have been dealt with and without thinking twice, you go to the text program and write everything down again – just in a different form.
I find this completely excessive and a waste of time and resources. The format of this report is specified nowhere. The documentation that we have now produced is systematic, consistent and complete. Thus, from my point of view, the only thing that happens with this approach are mistakes. You write content twice, have redundancies, and every time you make a change in the source, you also have to adjust the text report. Missing something happens faster than you think.
Where I completely agree with you is when preparing the results for management. But this is not equivalent to a report in text form either, but a compact presentation on one or two pages. In my understanding, this is not the same as a report for the data protection impact assessment. But rather a compact management summary.
In summary: Work clean and meticulously in the procedure directory and the DPIA and save redundant typing for a textual report.
Notification to the authority in case of a privacy impact assessment
Do you have to forward every privacy impact assessment to the authority? No. You only need to contact the authority if you identify high risks in the DPIA and cannot minimize or eliminate them through appropriate measures.
Good news, right? I am sure that in most cases you can reduce high risks by taking appropriate measures. Now it pays off again that you did not perform the DPIA on your own, but instead involved a team from the beginning.
Is privacy assessment a one-time thing?
Like any risk analysis, privacy impact assessment is an iterative process.
Let’s start from the beginning. In data protection management, you basically have the task of regularly reviewing your procedures. Are the procedures you describe still correct? Are the same applications still being used and the same resources still required? You need to ask yourself these questions on a regular basis.
You know where this is going now. Your process, which previously required a DPIA, now also needs to be audited again. Have the framework conditions changed? Do the risks still exist? Due to changes in the processes or in the technology used, this may mean that the risks in the data protection impact assessment also change.
For this reason, I strongly recommend that you review the DPIA on a regular basis. I’m sure you’ll notice that I don’t give a firm date here. Does the review have to be annual, quarterly, or every five years? There are no specific requirements here.
I would start with an annual review of risks. Depending on how agile your process is, you can either shorten the cycle or extend it with good justification.
Exclusion from privacy impact assessment
Interestingly, there is even an exclusion from the DPIA. The GDPR defines that for doctors and lawyers a DPIA is not mandatory.
An excerpt from recital 91 reflects the following:
“… The processing of personal data should not be considered as substantial where the processing concerns personal data of patients or clients and is carried out by an individual doctor, other health professional or lawyer. 5In these cases, a data protection impact assessment should not be mandatory.”
But the restriction should be read carefully. As always, the devil, or in this case the DPIA, is in the details. As usual, we are very happy to offer our support. My team and I are happy to help you with DPIA or in general with data protection and information security.
As a conclusion: Your experience
You probably already know. Now I’d like to hear from you about how you fared in conducting a privacy impact assessment. What have been the biggest hurdles that have kept you from doing a DPIA so far?
Was this description helpful to you? Tell us in the comments.
Sample privacy impact assessment in Excel
As promised, with this post you will receive a free sample in Excel for a privacy impact assessment. In addition, you will also receive the threshold analysis as an Excel file to determine the DPIA relevance.
Here you can download the templates:
FAQs on DPIA
What is a data protection impact assessment?
A DPIA is a tool that goes beyond the procedure directory. It is used to describe and assess risks to the rights and freedom of natural persons.
The data protection impact assessment must also consider the mitigation measures to minimize risks.
When must a DPIA be performed?
- If your procedure involves a high risk to the rights and freedoms of natural persons.
- In particular, when using new technologies that are likely to result in a high risk for the data subject.
- The DPIA must be performed prior to the start of the processing activity.
- The state offices have published blacklists. These are suggestions, but they must be examined separately. A DPIA does not necessarily have to be performed for the processes listed there.
- The decisive factor is whether there is a high risk for the data subject.
- We therefore propose a two-stage assessment:
1. brief analysis during the procedure
2. if high damage possible, then further risk assessment
What is the procedure for performing DPIA?
The process is not to be seen as a one-time thing. A DPIA must be performed on a regular basis. It may well be that over time, individual parameters change.
Generally, the process of a data protection impact assessment is divided into four steps:
- preparation (describe procedures, assemble DPIA team)
- execution (record and assess risks)
- implementation (implement decided measures)
- review (regular, e.g. annual review of DPIA)
Can the DPIA be performed as part of risk management?
We recommend that you do not think of it as a separate tool. Integrate the privacy impact assessment into an existing risk management framework. However, be sure to consider the specific requirements of the DPIA.
You should define damage criteria and probabilities of occurrence globally for the company. Here you should not have different values for DPIA and the rest of risk management. A “high” damage should result in the same understanding in the company in all cases.