Understanding Data Protection Impact Assessments

A Data Protection Impact Assessment (DPIA) is a type of risk assessment that is required if you’re processing personal data in certain risky ways. A DPIA is a highly beneficial tool for anyone considering a new product or project involving personal data.

A good DPIA will help you foresee and manage risk, improve efficiency by cutting unnecessary data collection, and show customers and regulators that you take data protection seriously.

This article explains what a DPIA is and when you must conduct one under the General Data Protection Regulation (GDPR). We’ll provide a step-by-step DPIA process with tips on conducting a DPIA that benefits your organisation, its customers, and other stakeholders.

What is a Data Protection Impact Assessment (DPIA)?

A DPIA is a documented process that helps you find and mitigate risks associated with personal data. 

When doing a DPIA, you will:

• Break down how and why you intend to process personal data and identify the types of data involved.
• Figure out the risks to people’s privacy and other rights.
• Find better ways of doing things that reduce or eliminate data protection risks.

You might have heard people use terms like “Privacy Impact Assessment (PIA)” and “Data Protection Assessment (DPA)” to describe this process. However, the term “DPIA” comes from the GDPR itself, which provides a set of rules for when and how to carry out the process.

The GDPR requires a DPIA before using personal data in certain risky ways. Each Data Protection Authority (DPA) in the UK, the EU, and the wider European Economic Area (EEA) also provides a list of activities for which a DPIA is required.

But as we’ll explain, a DPIA can be highly beneficial even if you don’t need to do one.

Key Components of a Data Protection Impact Assessment

There are many ways to conduct a DPIA, as long as you take certain steps to ensure you’re safely processing personal data. “Processing personal data” means using information that can identify individuals (“data subjects”).

According to Article 35 of the GDPR, a DPIA must include:

• A systematic description of: some text
  • The processing operations (what you’re planning to do with personal data).
  • The purposes of the processing (why you intend to collect or use personal data).
  • Where applicable, the legitimate interest you’re pursuing (how the project serves the interests of your organisation and other people).
• An assessment of necessity and proportionality (whether you need to process personal data to achieve your objective, and whether you’re processing the right amount of personal data in appropriate ways).
• An assessment of the risks to people’s rights and freedoms (the potential harm to people’s privacy and other rights)
• Measures to address the risks, including: some text
  • Safeguards
  • Security measures 
  • Mechanisms to ensure data protection and demonstrate GDPR compliance

In some cases, you might need to consult with the people affected by your project or your local Data Protection Authority (DPA).

We’ll break this all down into a step-by-step process below.

Example: Snap’s processing operations and purposes

Last year, Snap released My AI—a version of ChatGPT within Snapchat. 

The UK Information Commissioner’s Office (ICO) alleged that Snap had not conducted a proper DPIA for My AI and issued a preliminary GDPR sanction against the company. 

After Snap produced five successive versions of its DPIA, the ICO dropped the case. 

The ICO published a decision notice detailing how Snap’s DPIA improved over time, so we know the regulator’s views on how to get this process right.

For one thing, the ICO said early versions of Snap’s DPIA did not provide a sufficiently detailed “systematic description” of the “processing operations” and purposes. This relates to the first point outlined in the section above.

But by version five, this part of Snap’s DPIA met the GDPR’s requirements, for the following reasons:

• Snap systematically described how it used OpenAI’s ChatGPT technology to generate My AI’s outputs.
• Snap paid closer attention to the wider context of its product, including public concerns about generative AI.
• Snap provided statistics about Snapchat and My AI users to help identify risks, particularly risks involving children.
• Snap gave a detailed breakdown of its purposes for processing personal data via My AI, which included: some text
  • Providing a personalised experience,
  • Improving the service,
  • Delivering contextual ads,
  • Providing a safety and security-oriented feature.

Over the course of its five DPIAs, Snap assessed its product in greater detail, and mapped out how My AI could impact Snapchat users. Looking at the bigger picture helped Snap: 

• Identify previously unseen risks
• Implement appropriate safeguards
• Escape a GDPR fine

When is a DPIA Required Under GDPR?

Conducting a DPIA is mandatory in some circumstances. 

As part of a GDPR investigation, regulators can demand to see a copy of your DPIA. So it’s particularly important that you conduct a DPIA when required to do so.

Here are the four main sources that tell us when a DPIA is mandatory.

1. The GDPR’s “likely high risk” threshold

Sometimes, you have to decide for yourself if DPIA is required. 

According to Article 35 (1), you must conduct a DPIA if it’s likely that your use of personal data will result in a high risk to people’s “rights and freedoms”, including the rights to: 

• Privacy
• Data protection
• Other rights, such as freedom of expression and the right to work

When deciding whether you must do a DPIA, you should consider the “nature, scope, context, and purposes” of your intended activities. In other words: 

• What you’re doing
• How much personal data is involved
• What sorts of people might be affected
• Why you’re doing it

You’re more likely to need to do a DPIA if you’re using new technologies.

2. The GDPR’s specific high-risk activities

In addition to this “likely high risk” threshold, Article 35 (3) of the GDPR says you must conduct a DPIA if you’re:

• Engaged in “systematic and extensive profiling” with significant effects. This might include activities like credit rating, surveillance, or some forms of behavioural advertising.
• Processing large amounts of “special category data” (including information about people’s ethnicity, health, or political opinions) or data about criminal offences.
• Systematically monitoring a publicly accessible area on a large scale, such as via CCTV.

3. European Data Protection Board (EDPB) guidance

The European Data Protection Board (EDPB) has adopted guidance that states when a DPIA is likely required, including the following (among others):

• Evaluation and scoring. This means using technology to make predictions about people, including their performance at work, economic situation, health, personal interests, reliability, behaviour, location, or movements.
• Matching or combining datasets: For example, using two sets of data—  deriving from two different activities or two different organisations—in a way that people might not expect.
• Preventing access to services: For example, where a bank uses credit reference data to decide whether to offer a customer a loan.

There are several more scenarios listed in the guidance, so read it if you’re unsure whether you need to do a DPIA.

4. Regulators’ lists of high-risk activities

Finally, each Data Protection Authority (DPA) publishes a list of activities requiring a DPIA in their jurisdiction. 

For example, here are some of the activities that require a DPIA according to the Irish Data Protection Commission (DPC):

• The large-scale use of personal data for reasons other than those for which it was originally collected.
• Systematically “monitoring, tracking or observing individuals’ location or behaviour.”
• Obtaining personal data from third-party sources (unless you are able to meet the GDPR’s transparency requirements in doing so).

Step-by-Step Guide to Conducting a DPIA

As noted, there’s no “one way” to conduct a DPIA. But here’s an overview of what you should include, with some tips on how to complete each step.

Step 1: Reason for the DPIA

First, you should record why you are conducting a DPIA—likely for one of the following reasons:

• Article 35 (1): Your project is “highly likely” to post a “high risk” to people’s rights and freedoms
• Article 35 (3) (a): Systematic and extensive profiling
• Article 35 (3) (b): Special category data or criminal offence data
• Article 35 (3) (c): Monitoring a public place
• Your project requires a DPIA according to EDPB guidance
• Your project involves a high risk activity as designated by your Data Protection Authority
• None of the above

See “When is a DPIA Required Under GDPR?” above for more detail on these conditions.

Step 2: Describing the processing

Step 2 of the DPIA is where you explain what you intend to do with personal data. 

The GDPR requires you to consider the naure, scope, context, and purposes of the processing. Beyond this, it’s up to you how much detail you include. 

Most DPIAs address the following points:

Remember, it’s up to you how you structure your DPIA, as long as you meet the GDPR’s requirements.

Step 3: Seeking the views of individuals

The GDPR says you must “seek the views of data subjects” where appropriate. Many organisations skip this step, but it can be a good way to identify risks. 

You could also consult with subject matter experts, processors handling data on your behalf, or other teams within your organisation.

If you’re planning to take this optional step, you should document:

• Who you plan to consult
• What you plan to ask them
• (After the consultation) What they said, and whether this impacts your project

If you’re not planning to take this optional step, you should explain why you do not consider it appropriate.

Step 4: Assessing necessity and proportionality

The GDPR says your DPIA must include “an assessment of the necessity and proportionality of the processing operation in relation to the purposes.”

This step is your opportunity to explore the following questions:

• Why do you need to process personal data to achieve your purposes?
• What’s your lawful basis under Article 6 of the GDPR?
• If you’re processing special category data, which condition under Article 9 of the GDPR applies?
• Could you achieve the same or similar outcomes:some text
  • With less data?
  • With data about fewer individuals?
  • With data of a less sensitive nature?
• How can you ensure that the data is only used for its intended purpose?
• Will you be able to give data subjects the relevant transparency information under Article 13 or 14 of the GDPR? If so, how? If not, do you have a valid reason?
• What mechanisms do you have in place to ensure people can excercise their data subject rights?

Step 5: Identifying risks

Now it’s time to ask: What could go wrong? 

Consider the risks to people’s “rights and freedoms”—not just privacy and data protection, but, if relevant, freedom of expression, access to essential services, and other rights.

You can rate the risks in terms of: 

• Likelihood (how likely the risk is to occur)
• Severity (how severe the damage would be if the risk occurred)
• Overall risk (based on an average of likelihood and severity)

Some organisations plot these factors on a matrix and derive an initial risk score. This matrix might look something like this:

A matrix like this can help you derive an initial risk rating, which might change at Step 6 once you’ve applied mitigating measures.

Case study: Snap

The ICO’s Snap decision reveals how the company identified the risks associated with its My AI chatbot.

In the first four versions of its DPIA, Snap reportedly did not address the risks of processing special category data. 

In the fifth version of its DPIA, Snap stated that processing such data was “highly likely” as it ultimately could not control whether users gave the chatbot information about their health, philosophical beliefs, ethnicity, etc.

Beyond asking users not to share this type of type with My AI, there was little Snap could do to mitigate this risk. But even the fact that Snap had assessed the risk was enough for the ICO. This assessment was one of the reasons the regulator decided not to issue a GDPR fine.

This example shows the benefits of conducting a comprehensive and wide-reaching risk assessment as part of your DPIA.

Step 6: Mitigating risks

Now you’ve identified potential problems, it’s time to think of solutions.

For each risk you identified in Step 4, consider whether you can mitigate it or eliminate it. Appropriate controls might include:

• Access controls
• Encryption
• Data minimisation
• Staff training
• Contractual provisions
• Turning off targeting advertising
• Anonymisation or pseudonymisation 

Note that some of these mitgations go beyond data security—which, after all, is just one of many data protection considerations.

Once you’ve applied mitigations to a risk, you can reassess its likelihood and severity. This process could bring a “high” risk down to “medium” or “low” risk, and so on.

Step 7: Prior consultation

By now, you’ll have identified the risks associated with your project and applied mitigations. Hopefully, you’ll end up with a set of low-to-medium-level risks that are acceptable on balance.

If you still have risks you consider “high” at the end of your DPIA, you’ll have to contact your Data Protection Authority (DPA) for advice.

Article 36 (3) of the GDPR lists the information you must provide your DPA:

• A list of the controllers, joint controllers, and processors involved in your project, with their respective responsibilities (if applicable)
• The purposes (reasons for) and means (methods of) the processing
• The measures and safeguards to protect people’s rights and freedoms
• Contact details for your Data Protection Officer (DPO) (if you have one)
• A copy of your DPIA
• Any other information requested by the DPA

If the DPA believes your project risks violating the GDPR, they’ll offer you some written advice within eight weeks (with a possible six-week extension).

Case study: Austrian transport company

In Austria, a transport company conducted a DPIA concerning its plans to record traffic passing over a bridge. At the end of the process, the company found it could not mitigate certain risks around providing transparency information to drivers. 

The company contacted the Austrian DPA under the GDPR’s “prior consultation” rules. But the regulator said the company had taken sufficient steps to mitigate the relevant risks and gave the project the “green light.”

It’s sometimes better to consult with a DPA if you’re unsure whether your project should go ahead. They can provide useful advice on how to better mitigate data protection risks—-and they might be able to reassure you that you’re on the right track.

Tools and Templates for Conducting DPIAs

Besides the resources we’ve linked to throughout this article, here are some templates to help you conduct your DPIA:

• The UK ICO’s sample DPIA template
• Google’s template DPIAs for Google Cloud and Google Workspace
• The European Data Protection Supervisor’s (EDPS) Necessity Toolkit (useful for Step 4, above)

Frequently Asked Questions About DPIAs

What do I do if I'm planning to use AI in my product or organisation?

If you’re developing a product that uses AI—or implementing an AI product in your organisation—you likely need to conduct a DPIA

Among other regulators, the UK’s ICO says:

“In the vast majority of cases, the use of AI will involve a type of processing likely to result in a high risk to individuals’ rights and freedoms, and will therefore trigger the legal requirement for you to undertake a DPIA.”

Conducting a DPIA will help ensure you use or develop of AI in a safe and responsible way.

What are the penalties for not conducting a DPIA?

Failing to conduct a DPIA, or failing to consult with your Data Protection Authority (DPA) if necessary, can lead to a fine of up to €10 million or 2% of annual global turnover (whichever is higher).

Can a DPIA be conducted retrospectively?

No, a DPIA should be conducted “prior to the processing”—before your project gets started.

Who should be involved in conducting a DPIA?

When conducting your DPIA, you should speak to anyone is involved in your project and—ideally—the data subjects affected by it.

• Your Data Protection Officer (DPO) 
• Controllers and processors
• Your organisation’s cyber security team
• Your organisation’s legal or compliance team

You might also need to speak to your Data Protection Authority (DPA) (see Step 7 on “prior consultation”, above).

How often should a DPIA be reviewed?

There’s no rule for how often a DPIA should be reviewed. If something changes in your project, you might need to update and re-run your DPIA. Otherwise, you could set a regular period for reviewing your organisation’s DPIAs.

Best Practices for Conducting Effective DPIAs

Here are five tips for getting the most of the DPIA process:

1. Make it meaningful. A DPIA is not a tick-box exercise—it’s your chance to avoid risk, protection people’s rights, and improve your project. You’re more likely to benefit from a DPIA if you take the process seriously.

2. Think broadly: Even if a risk seems very unlikely to occur, it’s worth noting down. A DPIA is your chance to anticipate the worst-case scenario as a hypothetical so it does not become a reality.

3. Involve other people: Even if you choose not to consult data subjects (see Step 3, above), you should speak to everyone you need to, inside or outside of your organisation. Ask questions and get a comprehensive understanding of the project.

4. Involve your DPO: If your organisation has a DPO, you must involve them in the DPIA process. It’s probably not appropriate for your DPO to do the DPIA themselves, but you should ask their advice throughout the process, and have them review your final draft.
5. ‍Revisit your DPIA: A DPIA is a “living document”—keep yours on file and revisit it periodically. You might find it’s out of date or that certain recommendations have not been acted upon.