What is a DPIA?

In detail

• What is a DPIA?
• Why are DPIAs important?
• How are DPIAs used?
• What kind of 'risk' do they assess?

What is a DPIA?

A DPIA is a process designed to help you systematically analyse, identify and minimise the data protection risks of a project or plan. It is a key part of your accountability obligations under the UK GDPR, and when done properly helps you assess and demonstrate how you comply with all of your data protection obligations.

It does not have to eradicate all risk, but should help you minimise and determine whether or not the level of risk is acceptable in the circumstances, taking into account the benefits of what you want to achieve.

DPIAs are designed to be a flexible and scalable tool that you can apply to a wide range of sectors and projects. Conducting a DPIA does not have to be complex or time-consuming in every case, but there must be a level of rigour in proportion to the privacy risks arising.

There is no definitive DPIA template that you must follow. You can use our suggested template if you wish, or you may want to develop your own template and process to suit your particular needs, using this guidance as a starting point.

Why are DPIAs important?

DPIAs are an essential part of your accountability obligations. Conducting a DPIA is a legal requirement for any type of processing, including certain specified types of processing that are likely to result in a high risk to the rights and freedoms of individuals. Under UK GDPR, failure to carry out a DPIA when required may leave you open to enforcement action, including a fine of up to £8.7 million, or 2% global annual turnover if higher.

By considering the risks related to your intended processing before you begin, you also support compliance with another general obligation under UK GDPR: data protection by design and default.

Article 25 is clear that:

“the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures… and … integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.”

In general, consistent use of DPIAs increases the awareness of privacy and data protection issues within your organisation. It also ensures that all relevant staff involved in designing projects think about privacy at the early stages and adopt a ‘data protection by design’ approach.

A DPIA also brings broader compliance benefits, as it can be an effective way to assess and demonstrate your compliance with all data protection principles and obligations.

However, DPIAs are not just a compliance exercise. An effective DPIA allows you to identify and fix problems at an early stage, bringing broader benefits for both individuals and your organisation.

It can reassure individuals that you are protecting their interests and have reduced any negative impact on them as much as you can. In some cases the consultation process for a DPIA gives them a chance to have some say in the way their information is used. Conducting and publishing a DPIA can also improve transparency and make it easier for individuals to understand how and why you are using their information

In turn, this can create potential benefits for your reputation and relationships with individuals. Conducting a DPIA can help you to build trust and engagement with the people using your services, and improve your understanding of their needs, concerns and expectations.

There can also be financial benefits. Identifying a problem early on generally means a simpler and less costly solution, as well as avoiding potential reputational damage later on. A DPIA can also reduce the ongoing costs of a project by minimising the amount of information you collect where possible, and devising more straightforward processes for staff.

How are DPIAs used?

A DPIA can cover a single processing operation, or a group of similar processing operations. You may even be able to rely on an existing DPIA if it covered a similar processing operation with similar risks. A group of controllers can also do a joint DPIA for a group project or industry-wide initiative.       

For new technologies, you may be able to use a DPIA done by the product developer to inform your own DPIA on your implementation plans.

You can use an effective DPIA throughout the development and implementation of a project or proposal, embedded into existing project management or other organisational processes.

For new projects, DPIAs are a vital part of data protection by design. They build in data protection compliance at an early stage, when there is most scope for influencing how the proposal is developed and implemented.

However, it’s important to remember that DPIAs are also relevant if you are planning to make changes to an existing system. In this case you must ensure that you do the DPIA at a point when there is a realistic opportunity to influence those plans. Recital 84 of the UK GDPR is clear that:

“the outcome of the assessment should be taken into account when determining the appropriate measures to be taken in order to demonstrate that the processing of personal data complies with this Regulation.”

In other words, a DPIA is not simply a rubber stamp or a technicality as part of a sign-off process. It’s vital to integrate the outcomes of your DPIA back into your project plan.

You should not view a DPIA as a one-off exercise to file away. A DPIA is a ‘living’ process to help you manage and review the risks of the processing and the measures you’ve put in place on an ongoing basis. You need to keep it under review and reassess if anything changes.

In particular, if you make any significant changes to how or why you process personal data, or to the amount of data you collect, you need to show that your DPIA assesses any new risks. An external change to the wider context of the processing should also prompt you to review your DPIA. For example, if a new security flaw is identified, new technology is made available, or a new public concern is raised over the type of processing you do or the vulnerability of a particular group of data subjects.

What kind of ‘risk’ do they assess?

There is no explicit definition of ‘risk’ in the UK GDPR, but the various provisions on DPIAs make clear that this is about the risks to individuals’ interests. Article 35 says that a DPIA must consider “risks to the rights and freedoms of natural persons”. This includes risks to privacy and data protection rights, but also effects on other fundamental rights and interests.

The key provision here is Recital 75, which links risk to the concept of potential harm or damage to individuals:

“The risk to the rights and freedoms of natural persons, of varying likelihood and severity, may result from data processing which could lead to physical, material or non-material damage, in particular: where the processing may give rise to discrimination, identity theft or fraud, financial loss, damage to the reputation, loss of confidentiality of personal data protected by professional secrecy, unauthorised reversal of pseudonymisation, or any other significant economic or social disadvantage; where data subjects might be deprived of their rights and freedoms or prevented from exercising control over their personal data…”

The focus is therefore on any potential harm to individuals. However, the risk-based approach is not just about actual damage and should also look at the possibility for more intangible harm. It includes any “significant economic or social disadvantage”.         

The impact on society as a whole may also be a relevant risk factor. For example, it may be a significant risk if your intended processing leads to a loss of public trust.

A DPIA must assess the level of risk, and in particular whether it is ‘high risk’. The UK GDPR is clear that assessing the level of risk involves looking at both the likelihood and the severity of the potential harm.

For more guidance on what this all means in practice, see the section on how to carry out a DPIA.