Data protection impact assessments explained

If you do business with EU citizens, data protection impact assessments need to be part of your compliance strategy. The EU GDPR requires you to conduct a DPIA any time you plan to do processing that puts personal information at risk. Here’s how to conduct a DPIA that meets GDPR requirements. 

What is a data protection impact assessment?

Collecting or processing personal data always poses a degree of risk. Organizations can inadvertently expose the data to misuse, violate an individual’s privacy rights, or use the data in a way the individual isn’t comfortable with. This risk is especially high when an organization is implementing a new technology, processing data in a different way than before, or using data for a new purpose.

A data protection impact assessment is a process to make sure a data processing activity meets GDPR standards by identifying and mitigating risks to personal data and data subjects. In a DPIA, your organization documents the risks, proposes solutions, and plans any necessary changes to make the project acceptable under the GDPR.

DPIA vs PIA

DPIAs are a specific subtype of privacy impact assessment, mandated by the GDPR.

DPIAs are different from other PIAs because they’re specifically for identifying and mitigating risks to personal data and data rights, as defined by EU law.

Organizations may use PIAs for other purposes, such as to comply with other regulations, as a way to achieve privacy-by-design goals, or as part of a continuous improvement process. In fact, some type of PIA should be performed every time something significant changes in your data infrastructure or methodology, including:

• Product launches
• Changes in the way a system processes data
• Significant software updates
• Expansion to a new country or region
• Collecting a new type of data

However, not every situation that requires a PIA will warrant a DPIA.

What is required for a DPIA under the GDPR?

Article 35 of the GDPR requires businesses to conduct a DPIA when “a type of processing, in particular, using new technologies… is likely to result in a high risk to the rights or freedoms of natural persons.

The DPIA must contain the following components:

A complete description of your processing operation

This should include the purpose of processing, and your lawful basis for processing. The GDPR has six lawful bases for processing:

• Legitimate interest: This is the most common standard for processing activities. A legitimate interest is something the data subject would expect you to do with their information. For example, if they sign up for an account using their name and a password, they’d expect you to hold onto that data, and use it to verify their identity when they log in. 

• Consent: The subject has given their consent for you to process their personal data for a particular purpose. Keep in mind, the GDPR has a narrow definition of “consent.” To qualify as consent, the subject’s affirmation must be clear, freely given and easy to withdraw.

• Contractual obligation: The processing activity is necessary to fulfill a contract with the data subject. This can also apply if you’ve been asked to provide a quote or perform some other preliminary task by a prospective client or business partner.

• Vital interest: Necessary to save a life. Unless you provide emergency services, you aren’t likely to use this one.

• Public interest: This basis applies if you must process the data to perform a task “in the public interest or as part of “official authority.” This typically is used in applications designed to exercise an official government function or serve judicial authority. 

An assessment of your processing operation

The GDPR sees your processing operation as a potential restriction of fundamental rights, such as the right to privacy, or the right to have your data protected. For the operation to be legal, it must meet the legal standard of “necessity and proportionality.”

Necessary, in this context, means you can’t accomplish the goal without it. It also must be proportional, balancing the rights of the data subjects with your legitimate interest or other lawful basis.

Essentially, you need to show that you can accomplish your goal while impinging as little as possible on the rights of your users.

The risks your processing poses to EU rights and freedoms

Your DPIA must contain an in-depth examination of the risks your processing poses to the rights and freedoms of European citizens. According to Recital 75 of the GDPR your DPIA should cover anything that “could lead to physical, material or non-material damage.” This should include:

• Security risks, such as identity theft, fraud, loss of confidentiality and financial loss
• Discrimination
• Loss of control over personal data
• Revealing personal identity factors, such as:
  • Physical and biological data (e.g. genetic data and health status)
  • Biographical information (e.g. criminal convictions, sex life, trade union membership)
  • Demographics (e.g. race and ethnicity)
  • Beliefs (e.g. political opinions, philosophical beliefs, religion)

A plan to address or mitigate the risks

You need to propose measures to eliminate or mitigate your risks. This can include security measures, changes to your project plans, and any other controls necessary to limit risks.

Article 35 also instructs controllers to “seek the views of data subjects or their representatives on the intended processing” where appropriate. This can be a good way to ensure you’re respecting your users’ rights, interests, and expectations.

Finally, keep track of the risks and conditions outlined in your DPIA. If the risks change or there are new risks that emerge, review your DPIA to ensure you’re still giving subjects adequate protection.

When should you conduct a DPIA?

The general rule is that you should conduct a DPIA any time a process “is likely to result in a high risk to the rights and freedoms of natural persons.”

DPIAs should be performed before data processing occurs, which generally means early in the product life cycle. However, DPIAs also need to be performed when you make a change to a system that potentially creates new risks. So if you’re updating a product in a way that uses new data types or changes how you process data, you should perform a DPIA before you roll out the update.

Keep in mind that a DPIA can cover multiple products if they use “a set of similar processing operations that present similar high risks.” For example, let’s say your company operates multiple brands. You create a customer loyalty program for Brand X and perform a DPIA before you roll it out. If you decide to build a very similar program for Brand Y, you probably don’t need to perform another DPIA, provided you’re not introducing any additional risk or burdens for customers.

Here are the criteria that indicate you need a DPIA, according to the Article 29 Data Protection Working Party, the French data authority, CNIL, and other EU authorities:

Evaluation or scoring

Any system that profiles subjects or makes predictions based on personal data is a good candidate for a DPIA. This includes credit screening, background checks, genetic testing, and behavioral marketing applications that profile consumers.

Automated decision-making with legal or other significant effects

If your system is deciding whether to approve a loan, screening job candidates, or performing some other task with a significant effect on the subject’s life or opportunities, you should perform a DPIA.

Systematic monitoring

Any processing “used to observe, monitor or control data subjects” requires a DPIA. This would obviously include law enforcement or security applications analyzing the personal data or communication of subjects. Monitoring publicly accessible areas also counts as systematic monitoring. So if you’re using facial recognition or other AI to analyze the behavior of passersby, you need a DPIA.

Sensitive or highly personal data

Processing health data, race and ethnicity, political, religious, and philosophical beliefs, uniquely identifying biometric data, criminal history, or other highly personal data requires a DPIA. This includes hospital applications that record medical records, and applications keeping track of criminal offenses.

You should also consider data that creates other sorts of risks for individuals. Even if a type of data isn’t inherently personal, it may be sensitive because it creates risks for a subject’s rights and freedoms. This includes financial data, because it creates a risk of fraud. Location data is also sensitive, because it can interfere with a subject’s freedom of movement and anonymity.

Large scale data processing

When you process the data of many different subjects simultaneously, it often poses significant risks. Data subjects may have less opportunity to exercise their rights individually, the application may bring up new risks you haven’t accounted for before, and the sheer volume of data may itself be a cause for concern. Whether you’re analyzing web traffic across a major node, looking for trends in anonymized biometric data, or implementing some novel, large-scale technology, perform a DPIA.

This does not apply if you simply scale up an existing technology. For example, if you provide software as a service for physicians or attorneys, you don’t need to perform a new DPIA when your user base grows beyond a certain level. Each of your clients are using it for individual patients, not as a large-scale technology.

Matching or combining datasets

If you’re combining multiple datasets, there’s a good chance you’ll be able to use information in a way that the individual didn’t intend when they provided the data for one set or another. That requires a DPIA.

Data concerning vulnerable data subjects

A data subject is considered vulnerable when there is an “increased power imbalance between the data subject and the data controller.” This imbalance makes it more difficult for the subject to exercise their rights or withdraw consent, so a DPIA is used to ensure those rights are respected.

Vulnerable subjects include:

• Children
• Employees
• Mentally ill people
• Asylum seekers
• The elderly
• Patients

For example, if your software logs the work habits of employees or evaluates the history and claims of asylum seekers, you should perform a DPIA.

Innovative use or new technology

New technology — or new applications of existing technology — can have unanticipated consequences. As the Article 29 working group explains, “the use of such technology can involve novel forms of data collection and usage, possibly with a high risk to individuals’ rights and freedoms.”

According to the group, combining fingerprint scanning and facial recognition as a form of access control fits into this category, as do some internet of things technologies. But nearly any new technology or new application that collects or processes personal data would fit in this category. Performing a DPIA will help you anticipate the risks and meet the regulatory requirements.

Preventing data subjects from exercising rights or using services

Technology meant to restrict access or deny services to subjects requires a DPIA. For example, if a bank is building a program to screen loan applicants based on credit scores, they should perform a DPIA first.

Data transfer outside the European Union

If you’re working with private data belonging to EU citizens, you’re required to protect it to EU standards, no matter where you take it. But many other countries don’t share the same strong data privacy laws that the EU upholds. If you’re transferring data to a country where, for example, the law doesn’t protect users from indiscriminate government surveillance, you need to conduct a DPIA to determine whether you can provide adequate data protection. If you can’t, you may need to add extra controls or process the data within the EU to ensure you’re abiding by the GDPR.

Any other high risk processing

This is not meant to be an exhaustive list. There may be technologies or applications that don’t fit neatly into any of the categories above, but still impinge on the rights of EU data subjects. When in doubt, perform a DPIA.

Examples of projects that require a DPIA

CNIL, the French data protection authority, released a list of example projects that would require a DPIA. As you’ll see, it’s common for projects to meet multiple DPIA criteria at once. Keep in mind that this isn’t a complete list — just examples to help you recognize when to perform a DPIA.

Type of data processing

• Healthcare data processing
• Processing genetic data of patients, children, employees, or other vulnerable groups
• Profiling job candidates or other subjects for human resource management
• Processing data to monitor employee activity
• Processing data for health alerts or alert management
• Processing data for professional alerts or alert management
• Processing health data to establish a data warehouse
• Screening subjects in a way that may exclude them from a contract or lead to job termination
• Processing data on contractual breaches identified by another party, in an application which may exclude people from a contract or suspend contract benefits
• Using external data sources for profiling
• Processing biometric data to identify people, including vulnerable subjects
• Examining social housing applications, and managing housing
• Data processing to provide social and/or medical support
• Processing location information on a large scale

DPIA criteria

• Sensitive dataVulnerable subjects
• Sensitive dataVulnerable subjects
• Evaluation or scoringVulnerable subjects
• Vulnerable subjects Systematic monitoring
• Vulnerable subiectsEvaluation or scoringSensitive data
• Vulnerable subjectsEvaluation or scoring Sensitive data
• Sensitive dataVulnerable subjects
• Evaluation or scoringCombining datasets
• Combining datasetsAutomated decision-making with
  significant effect
• Evaluation or scoringCombining datasets
• Sensitive dataVulnerable subjects
• Sensitive dataEvaluation or scoring
• Sensitive dataEvaluation or scoring Vulnerable subjects
• Sensitive dataLarge scale data processing

How to perform a DPIA

Record how the project uses information

Whenever you start a new project, log the way it collects and uses personal data. Some questions to answer are:

• What data does this project collect?
• How is the data used?
• What is the purpose of collecting the data?
• What is my lawful basis for processing?
• How long is the data retained, and how is it deleted?
• Who will have access to the data, and how is that access controlled?
• Does the project generate other types of data, such as profiles?

If the project is an update to an existing product (e.g. a software update), identify any changes.

Identify assessment needs

Now that you’ve recorded your data practices, you can screen the project for needed assessments. If it meets any of the criteria above, and you haven’t conducted a DPIA for a project with the same risks, you should conduct a DPIA.

Document risks

Every time you use personal data, there’s risk. Some risks may be minor enough to not require remediation, others will require small changes or disclosures, and occasionally, some will require major changes to the project. At this point, your goal isn’t to evaluate the significance of the risks — just to get them all down. What could go wrong, and how could it affect data subjects?

Here are some types of risks to consider.

Data is compromised:

• Data is leaked internally due to lax security controls.
• Data is leaked by a partner.
• Data is compromised by a malicious actor.
• Devices with the personal data on it are lost or stolen, giving a third party access.

Your practices harm data subjects:

• You fail to adequately explain how you’re using data, and subjects find your processing intrusive.
• You combine datasets or synthesize new data, giving you much more information than subjects anticipated.
• You combine datasets, making it possible to identify individuals from data that was supposed to be anonymized.
• You request too much data, making the process seem intrusive, and breaking data minimization requirements.
• You collect unnecessary data, or retain data longer than necessary.
• The information you make available causes financial harm to subjects.
• Your data collection or processing puts undue burdens on vulnerable subjects.

You put your company at risk:

• Your company is subject to audits, fines, or prosecution for breaking GDPR rules.
• Your company is sued by partners or consumers for a data breach.
• Data breaches harm your company’s reputation.
• You identify privacy issues late in the development cycle, requiring costly remediation.
• Poor data management leads to data bloat, non-compliance, poor data utilization, or other issues.

Find data protection solutions

Working with personal data always involves some degree of risk, but the GDPR requires you to limit that risk so that it’s proportionate to the project. Data protection solutions will help decrease both the likelihood and the severity of risks, bringing them in line with GDPR requirements.

Keep careful track of which risk or risks each data protection solution addresses, how it mitigates it, and to what degree the risk is mitigated. Some examples of data protection solutions include:

Limiting information:

• Collecting fewer types of sensitive information
• Shortening retention periods for personal data
• Anonymizing personal data

Limiting or altering the project:

• Moving data processing within the EU
• Removing a high-risk module from the project

Empowering users

• Ensuring users fully understand your data practices and risks
• Providing options for data users to disclose less information
• Providing an online tool for users to contact your organization with questions

Improving controls

• Regularly auditing your IT security
• Implementing end-to-end encryption, strict access control, or other security measures
• Building data handling protocols
• Implementing strict data training and screening for people with access to sensitive data
• Strictly screening external data processors
• Rigorously testing your data anonymization controls to ensure data subjects can’t be re-identified

Once you’ve decided on controls, account for your remaining risks. Document what risks you have decided to accept, and make sure they’re necessary and proportionate.

Produce a report

Creating a final DPIA report isn’t legally mandated, but it is a good idea. Reviewing your DPIA process and reporting on the key findings will help ensure you haven’t missed any important details and make it easier to implement whatever controls you’ve added.

Provide a high level summary of the process, then drill down to address details, such as:

• What was the project plan prior to the DPIA?
• What are the goals of the project?
• Why did you perform a DPIA?
• What were the main risks you identified?
• What steps or changes did you introduce to mitigate risks
• Are there any significant risks that remain?
• What is the revised project?
• What are the action items for preceding with the project?

This is a good opportunity to take another look at the whole project, and ensure you’ve mitigated the risks enough to proceed. If the risks are too high, you may decide to cancel the project, or make changes to its scope or goals.

Consult the data protection commissioner

If the project is unfeasible, it’s time to get outside help from the data commissioner. Consult the data commissioner if:

• There are risks you can’t manage
• Risk remains high, despite your data protection solutions
• You’re uncertain whether you’ve met GDPR standards

However, if you’ve mitigated personal data risks in line with GDPR requirements, you do not have to consult with the commissioner.

Apply the DPIA

Now it’s time to put any controls or changes you’ve made into effect. You’ll need to assign stakeholders to implement the changes and send the project back for a final review once they’ve been completed.

Keep in mind that projects evolve over time. There may be changing goals and priorities, along with new risks in the future. Make sure to revisit projects whenever a significant change occurs that could affect the risk profile. For example, if you update software, add a new module, or change your data collection policies, you should review the project again. Not every change will require a new DPIA (or a revision to the DPIA), but the only way to know for sure is to check in.