Guidelines to Data Protection Impact Assessment

Data Protection Impact Assessment (DPIA) is a useful tool that can help organizations to understand the risks related to processed data. DPIA helps to find the right balance and proportions, identify risks, assess the necessity and proportionality and generally help with risk management.

Due to the European General Data Protection Regulation, DPIA is the mandatory tool for demonstrating compliance. Want to demonstrate GDPR compliance? Show your DPIA report. But DPIA is not merely a report and it is definitely not a checklist-type one-shot exercise. DPIA is a process. This process typically should begin when the “subject project” is started - in its design phase. In this way, DPIA supports Privacy by Design approach. By the way, being DPIA-enabled also helps to avoid GDPR fines - up to €10M (or 2% total worldwide annual turnover). In this sense, DPIA shows compliance. But DPIA should be understood even beyond that.

Previously I analyzed the initial version of DPIA guidelines (here). Working Party 29 has just approved their final DPIA Guidelines (link). The differences in the final Guidelines are not striking (rather, indicative).

But what may come to you as a surprise is that these Guidelines may not actually be final! Those final ones should be released by the new European Data Protection Board, which will be formed in May 2018. This is motivated by the need of having a consistent DPIA interpretation by European countries.

In this post, I provide a brief analysis of the guidelines.

What is risk?

Risk can be understood as an assessment of unwanted event arising. To put it in simple terms, risk-assessment is focusing on the analysis of consequences of potential events happening. Typically, risk-analysis will have to consider severity and likelihood of threats and vulnerabilities.

The important caveat here is that GDPR risk relates to individuals, not systems (as opposed to information security risk-assessments; this has been a frequent point of confusion). The risk-based approach must be performed from the point of view of end-users, individuals, employees, citizens, etc.

DPIA is not only about privacy!

DPIA is basically about “rights and freedom” of individuals. Although the primary item for study here is of course privacy, other aspects often need to be considered, such as freedom of speech, thought, movement; prohibition of discrimination, and other fundamental rights.

Throughout this year many people tried to argue that DPIA is not about privacy.

List of likely items requiring a DPIA

Below I repeat some of the points from my previous post (they reflect the ones in WP29 Guidelines).

• If two “items” from the list below “are involved” - DPIA is needed.
• If none or merely a single one is involved, it might not trigger the need for a DPIA.
• However, sometimes even one item is sufficient to to warrant the need for a DPIA.

This is a non-exhaustive list

How to be on the safe side? Write down the basis for your decision to justify why a DPIA has not been carried. Rest assured that this justification will be reviewed and your choices will be assessed.

Now, the list:

• Profiling is in use. Example: a bank that screens its customers against a credit reference database, a biotechnology company offering direct-to-consumer genetic testing to assess and predict the disease/health risks, or building behavioral or marketing profiles based on navigation on websites.
• Automated-decision making with legal or similar significant effect. Example: when processing leads to the potential exclusion or discrimination of individuals. Processing with little or no effect on individuals does not match these specific criteria.
• Systematic surveillance. Processing used to observe, monitor or control data subjects.
• Sensitive data. Including GDPR Article 9, such as information about individuals’ political opinions, as well as personal data relating to criminal convictions or offenses. Examples: a general hospital keeping patients’ medical records. Other sensitive private data of note: electronic communication data [ePrivacy regulation is also taking care of these], location data, financial data.
• Large-scale data processing. WP29 is not sure what does “large-scale” mean, but suggests the following criteria: the number of data subjects concerned, the volume of data and/or the range of different data items being processed [is it high-dimensional data? This means that “Big Data” processing always falls into a DPIA category], the duration processing, the geographical extent [this WP29 guideline is very ambiguous]
• Linked databases - in other words, data aggregation. Example: two datasets merged in one, that could “exceed the reasonable expectations of the user”. This point specifically touches data merging and also possibly advertising technologies such as cross-device tracking, or cookie syncing, even.
• Data concerning vulnerable data subjects, especially when power imbalance arises, e.g. employee-employer, where consent may be vague, data of children, mentally ill, asylum seekers, elderly, patients. This point refers to the broad sense of “power imbalance”.

What to do if not being sure

The list above is indeed non-exhaustive. You’re not sure if you should conduct a DPIA? Even if it’s not required, it is recommended. Since it is a useful tool that shows compliance and that risk-based approach has been carried, WP29 recommends carrying it even on a
good-practice basis.

What elements should my DPIA have?

See my previous post. I’ll also cite a neat footnote from the Guidelines: “risks have to be identified, analyzed, estimated, evaluated, treated (e.g. mitigated...), and reviewed regularly. Controllers cannot escape their responsibility by covering risks under insurance policies“

Sounds about right. And this point is really helpful: insurance is not a way to account for Failing to follow GDPR risk assessment. This indication is helpful both to organizations and potential insurers (increases the risks on both sides).

What is the target of a DPIA?

DPIAs are conducted for processes, systems, products, software, hardware. Deployment context is also very important. Even if a product vendor has a DPIA, often additional one must be conducted during the actual deployment (although vendor-provided DPIA would be helpful), considering environmental factors, size of populations, etc.

Do I need to conduct DPIA for current systems?

DPIA is required for systems deployed after GDPR comes into force. But beware! DPIAs must be reviewed and updated on a regular basis. Just because a system has been deployed in April 2018 does not mean it will be "immune" to GDPR/DPIA requirements.

Furthermore, it is simply a good practice to evaluate DPIAs on a continual basis (hence, it’s a process).

Why the need to update a DPIA? It’s about environment changes

• technologies change
• new vulnerabilities arise
• se context changes
• data subject change
• social norms change

Updating a DPIA on a continuous basis is also a good practice (otherwise, DPIAs are invalid)

How to carry out a DPIA?

Use appropriate methodologies. Organisations are free to choose those that suit their needs best. But those methodologies must fulfill all the requirements. It's best if they demonstrate recommendations, chosen strategies, and generally provide answers to questions "what", "how", "why". Some DPIAs are about strong technical approach.

Who is involved?

DPIAs can either be conducted by in-house teams or with the help of outside consultants. Depending on the needs - some projects are big, complex and bring broad risks. Additionally, if a Data Protection Officer is appointed, his responsibility will be ensuring that DPIA recommendations are respected in practice. DPO also provides advice.

Organisations are additionally often expected to conduct public consultations, such as focus-groups test or other similar. The results must be included in a formal DPIA. If the consultations indicate that specific types of processing are not justified (or not proportional),
but the organization still chooses to go ahead with their initial plan - a justification must be
provided.

Additionally, it’s recommended to ask for advice of external, independent experts (such as privacy experts, researchers, security experts, sociologists, ethicists, etc.)

Should a DPIA be published?

WP29 is not indicating that making a DPIA public is mandatory. However, it does say that going public would help to build trust in end-users.

I often say the same. Publishing DPIA is definitely a good practice and an internal part of many DPIA methodologies. If a DPIA cannot be published in full (i.e. if some parts are sensitive), it can still be processed in a way that some of its parts could be made public. Sometimes even a descriptive summary is helpful.

However, organizations should make sure that the publicly communicated conclusions are
not different than the ones indicated by the actual DPIA.

Summary

In some places, people could be familiar with a different name than Data Protection Impact Assessment. For instance, in the UK a similar process is known as Privacy Impact Assessment; in France - Etude d’impact sur la Vie Privée. These are different names for apparently (now) a consistent process, DPIA; a paradigm and approach to data privacy. In many places in Europe, this process is much less known. Hence, it will be interesting to see how those countries will adapt to the new regime.

DPIA approach is required in the European Union - meaning that systems processing data of people being in Europe are automatically encompassed by GDPR.

DPIA is not a one-time exercise. It is a process. DPIAs are not check-list exercises and are not merely reports. DPIAs can provide actionable reviews and advice on the design of systems.