How to Conduct a Data Protection Impact Assessment

A Data Protection Impact Assessment, or DPIA, helps organisations to identify data protection-related risks when processing data for a new project or purpose. DPIAs are an important part of an organisation’s legal obligations and show that they are taking a proactive approach to data protection.

What is a DPIA?

A DPIA is a tool that can help organisations identify and minimise risks that can arise from their data processing activities. This is part of the accountability principle of the GDPR, and the production of a well-thought-out and researched DPIA is evidence that an organisation is trying to comply with data protection laws. The production of a DPIA at the conceptual stage of a project can also help ensure that data protection is built into projects from an early stage, thus complying with the principle of ‘data protection by design and by default’, more commonly referred to as ‘Privacy By Design’. 

The goal of a DPIA is not to eliminate all risk, as this is virtually impossible, but to assess the level of risk associated with the proposed processing activity to determine if the benefits of processing the data, when weighed against the cost of mitigation, are cost-effective and viable. 

All organisations should do a DPIA before beginning any new project that involves processing personal data that may pose a ‘high risk’ to the fundamental rights and freedoms of individuals. If they are confident that a DPIA is not required, they should document their reasons for not carrying out a DPIA.  

What is ‘High-Risk’ Data Processing?

The GDPR does not give specific definitions or examples of ‘high-risk’ data processing but instead directs organisations to consider how their processing could cause harm to the individuals involved.

The UK GDPR states that DPIAs should consider the “risks to the rights and freedoms of natural persons” – Article 35, Recital 75, UK GDPR. It does not define what a risk is in this context, but does give the following examples:

• Discrimination.
• Identity theft or fraud.
• Financial loss.
• Damage to reputation.
• Loss of confidentiality of personal data protected by professional secrecy.
• Unauthorised reversal of pseudonymisation.
• Significant economic or social disadvantage.

For me, one glaring omission from this list is any potential risk to life, for example, in safeguarding matters. 

A new project that involves ‘high-risk’ data processing requires a DPIA before any processing commences. As per Article 35(3), some types of processing will always require a DPIA, including:

1. Systematic and extensive profiling with significant effects.
2. Large-scale use of special category data as defined in Article 9 of the GDPR.
3. Systematic monitoring of a public area on a large scale.

The Article 29 Working Party (A29WP), the predecessor to the European Data Protection Board (EDPB), provided the following guidelines that can indicate high-risk processing:

• Evaluation or scoring.
• Automated decision-making with legal or similar significant effects.
• Systematic monitoring.
• Sensitive data or data of a highly personal nature.
• Data is processed on a large scale.
• Matching or combining datasets.
• Data concerning vulnerable data subjects
  NB. Employees are included within the definition of ‘vulnerable’.
• Innovative use of applying new technological or organisational solutions.
• Preventing data subjects from exercising a right or using a service or contract.

The ICO, as directed by Article 35(4) of the UK GDPR, has also produced the following list of circumstances that require a DPIA:

1. Innovative technology: processing involving the use of innovative technologies or the novel application of existing technologies (including AI). 
2. Denial of service: Decisions about an individual’s access to a product, service, opportunity or benefit that is based to any extent on automated decision-making (including profiling) or involves the processing of special category data.
3. Large-scale profiling: any profiling of individuals on a large scale.
4. Biometrics: any processing of biometric data. 
5. Genetic data: any processing of genetic data other than that processed by an individual GP or health professional for the provision of health care directly to the data subject. 
6. Data matching: Combining, comparing or matching personal data obtained from multiple sources.
7. Invisible processing: processing of personal data that has not been obtained directly from the data subject in circumstances where the controller considers that compliance with Article 14 would prove impossible or involve disproportionate effort.
   NB. Article 14 states that if data is not obtained directly from the Data Subject, then providing it would not take disproportionate effort, and the Controller should notify the Data Subject with details of the processing within one month.
8. Tracking: processing which involves tracking an individual’s geolocation or behaviour, including but not limited to the online environment. 
9. Targeting of children or other vulnerable individuals: the use of the personal data of children or other vulnerable individuals for marketing purposes, profiling or other automated decision-making, or if you intend to offer online services directly to children.
10. Risk of physical harm: where the processing is of such a nature that a personal data breach could jeopardise the [physical] health or safety of individuals.

Source: ICO

How to Conduct a DPIA

It is therefore very likely that, according to the above criteria, a lot of data processing activities could be considered high risk. The good news is that performing a DPIA need not be an overly complex or intimidating process – they are a useful tool that can be scaled up or down depending on the complexity of the project and the amount of personal data involved.

The ICO provides a sample DPIA template that could be a good start for creating your own DPIA, as well as the criteria for an acceptable DPIA. At GHC, we have modified and enhanced the ICO’s DPIA template, and if you get in touch, we would be happy to share a copy with you. 

Here are some key steps you should take when creating your own DPIA:

1. Firstly, define very carefully the purpose of the data processing. 
2. Then, walk through the data protection principles, i.e.
   – Define the lawful basis for processing the data as per the UK GDPR.
   – Identify how you will inform individuals about the processing.
   – Define how much data will be collected, how it will be collected and stored, how you will ensure you do not collect too much, how you will ensure that the data is accurate, for how long the data will be retained, and what security measures you will undertake to protect said data. 
3. What is your relationship with the data subject? This step can help identify any power imbalances that could affect consent from the individuals involved.
4. Consult with the data subjects involved unless you have a good reason for not doing so. 
5. Identify and assess any potential risks that the processing may cause according to the lists above.
6. List ways that you can reduce or eliminate the risks identified in step 5. Following the data minimisation principle, think about how you could reduce the amount of data collected or stored, and consider anonymising or pseudonymising the data where possible.
7. Conclude your DPIA by listing the measures you will take to mitigate any risks and the risks that remain present after taking these measures. If your processing will still result in a high risk to the individuals involved, but you feel that your reasons for processing make it worth that risk, consult with the ICO before continuing with the processing.
8. Where will our data physically be stored? Will it be processed by any third parties, and if so, what due diligence is required and are agreements in place?
9. Are any other assessments required? Such as a legitimate interest assessment (LIA) or transfer risk assessment (TRA)?

You should incorporate the DPIA’s findings into your whole project, monitoring the data processing during the project to make sure the DPIA is still relevant and the risk reduction is applied effectively. It could be that during the project, you encounter new potential risks which should be added to an updated DPIA.

The DPIA is performed just on the processing activity – correct?

No, usually data processing will involve some form of data sharing, be that internally or externally. If you are engaging a third-party processor, for example, a file hosting company, you would perform due diligence on the company to ensure that they are GDPR compliant, and then a DPIA on the processing activity. Some companies will offer more than one service, e.g. Microsoft. They offer Outlook, OneDrive, SharePoint, Teams, MS Dynamics and hundreds of other applications. You may decide to perform small, distinct DPIAs on each service, especially if it is a stand-alone product such as MS Dynamics. However, you may choose to review a range of products on one DPIA. You just have to make the scope of the DPIA very clear to the reader.

Ongoing reviews

Once completed, a DPIA is not just filed and forgotten; it must be periodically reviewed to ensure no changes to processing (referred to as ‘function creep’) have taken place, and a review must take place if you intend to change any fundamental elements of the data processing activity.

If you are unsure of the risks involved in a new project or you need help creating your DPIA, please get in touch with us here at Griffin House Consultancy. We have over 25 years of experience with data protection consulting, training, auditing and compliance – click here to contact us.

Author: Mike Martin LLM

Mike is an information governance specialist and one of the founding Directors of the Griffin House Consultancy, a leading specialist data protection and information governance consultancy firm that supports hundreds of clients annually with their training, consulting and auditing requirements.