GDPR Data Protection Impact Assessment

How vulnerable are your data processes to attacks or misuse? Are they putting your data subjects at risk of having their rights violated? The European Commission wants to know.

A Data Protection Impact Assessment (DPIA) is a systematic method of assessing and documenting relevant data processing activities in order to answer those questions. It determines the risks of your activities and identify opportunities to mitigate or eliminate those risks so that everyone is safer.

Article 35 of the GDPR mandates that data controllers conduct a DPIA in certain circumstances. Failing to produce evidence of conducting a DPIA when called upon could lead to huge fines.

What is a DPIA, when do you need it, and how should you conduct one? Keep reading to learn more and see examples of GDPR-compliant DPIA forms.

Data Controllers, Data Processors and DPIA's

While the DPIA requirement only applies to data controllers and not data processors, it's important to note the difference between these two roles and how one party can technically be both.

A data controller is the party responsible for deciding what personal data will be collected and exactly what will be done with that data. The data processor is the party that carries out the wishes of the data controller and processes the data as per the controller's instructions.

However, data processors can be data controllers. For example, consider a company like Mailchimp that operates by processing email address data for other companies. In this relationship, Mailchimp is the data processor for the companies who rely on it to process the email addresses the companies collect. The companies are the data controllers.

But Mailchimp can be a data controller in regard to the information it collects from its own employees and its clients. For example, it will surely have payroll information for its employees which includes protected personal data. The email addresses it collects from companies interested in working with Mailchimp are considered personal data that Mailchimp is the data controller of. Thus, in certain circumstances where Mailchimp is the data controller, it may need to conduct a DPIA.

When is a DPIA Needed?

When exactly do you need to conduct a DPIA?

According to the GDPR

The GDPR requires a DPIA to happen before processing any data when the processing activity "is likely to result in a high risk to the rights and freedoms of natural persons."

Legislators didn't provide an exhaustive list of examples of when this might happen. However, a few of the examples listed in Article 35 (3) include:

• "A systematic monitoring of a publicly accessible area on a large scale"
• "Processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offenses referred to in Article 10"
• "A systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person"

According to Supervisory Authorities

GDPR Article 35(4) and (5) says that:

"The supervisory authority shall establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment pursuant to paragraph 1. The supervisory authority shall communicate those lists to the Board referred to in Article 68."

"The supervisory authority may also establish and make a public a list of the kind of processing operations for which no data protection impact assessment is required. The supervisory authority shall communicate those lists to the board."

In other words, you should check with your supervisory authority to see whether your processing activity falls under its guidelines.

According to the Article 29 Working Party

If you want more detailed guidelines, check out the opinions and recommendations of the Article 29 Working Party.

The Article 29 Working Party is a group of data protection authority representatives. They put together a list of guidelines that should trigger a DPIA and published it for public consultation.

According to the Article 29 Working Party, issues associated with "high risk" include data processes that include or involve:

• Systematic monitoring
• Profiling or predicting
• Automated decision making
• Sensitive data
• Large-scale data processing
• Vulnerable data subjects
• New technologies or innovations
• International data transfers (data moved outside the EU)
• Limiting or preventing data subjects from using a service, fulfilling a contract, or exercising their data rights

Do I Need a DPIA for Existing Processes?

The DPIA requirement came into play with the GDPR. Thus, only processing operations that went live after May 25th, 2018 require a DPIA.

However, the Article 29 Working Party believes that you should carry out a DPIA for any high-risk operations, even if you began them years ago.

The recommendation comes back to the understanding that a DPIA is a good business practice but it also reassures you that you have little to no risk of non-compliance.

The GDPR Data Protection Impact Assessment (DPIA)

Any time you collect, store, or use data, you put the data at risk simply by exposing it.

This doesn't mean that data processing is inherently bad. It means that by putting the data out there, you open it up to potential threats that wouldn't exist if you had never collected it in the first place.

Because you profit from data collection and processing, it's up to you to do what you can to protect data subjects.

Today, organizations use a Data Protection Impact Assessment to protect both data subjects and their company.

Data Protection Impact Assessments (DPIA) use a systematic process to identify the risks associated with any data-related project. By identifying the risks that a new process could carry, you can mitigate the likelihood or potential damage of these events for your organization and the data subjects you work with.

Using a DPIA before implementing a new practice allows you to engage in a process known as "data protection by design" and "data protection by default," both of which are explicitly required by Article 25 of the GDPR.

Data protection by design is a concept that refers to building data privacy features and technologies directly in your project from the very beginning. By doing so, you not only comply with the law, but you save your organization time and money by mitigating or even preventing costly data breaches.

Examples of data protection by design include the use of encryption or pseudonymization to protect data users' identities and privacy. Building this concept into your products also:

• Encourages customer confidence and trust
• Protects users' data protection rights
• Reduces data protection risks
• Lowers the cost of integrating safeguards by building them into the early stage product

Data protection by default refers to applying appropriate technical and organizational measures to ensure that, by default, you're only processing personal data that's necessary for each specific purpose of processing."

By default means that you should ensure that you provide the greatest amount of privacy protection as a standard. It refers to not only technical data protection but also to processes like limiting the amount of data you process to only the minimum amount required, or only storing the data for as long as you actually need it.

Who Participates in a DPIA?

The designated team nominated by the Data Controller bears the responsibility for carrying out and documenting the DPIA.

Even if you outsource the process, the Data Controller remains responsible.

Additionally, you'll need to consult your Data Protection Officer (DPO), if you have one. The DPO's advice is part of the entire DPIA process.

What to Include in a GDPR Data Protection Impact Assessment

If you have spent some time familiarizing yourself with the GDPR, you'll notice that it makes plenty of rules but doesn't provide a step-by-step outline for how to meet those obligations.

Because data processing practices differ so greatly in nature and scope, there's no prescriptive remedy. Although a baseline is offered, how you meet those obligations needs to be true for your data processing practices - not someone else's.

The same is true of the DPIA. The full minimum terms of a GDPR Data Protection Impact Assessment are outlined in Article 35 of the GDPR.

Section 7 of Article 35 says that the assessment must include at least the following:

1. "A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
2. An assessment of the necessity and proportionality of the processing operations in relation to the purposes;
3. An assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; and
4. The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned"

We can break the assessment into four distinct parts:

1. Description of the processing
2. Assessment of necessity and proportionality
3. Identify and assess risks
4. Measures used to reduce and eliminate risks in #3

Describe Your Processing Activities

Before you begin your DPIA, you should have already completed an audit or inventory of all your data processing systems. You'll need the results to complete the first step of your DPIA.

If you haven't yet audited your activities, the first section of the DPIA can be a jumping off point for doing so. However, we recommend a full audit to include all data processing activities, even those that don't require a DPIA before beginning.

A description of your processing activities requires you to provide a full description of how the processing works including the nature of it. Some important questions to ask include:

• How do you collect, process, store, and eliminate data?
• Where do you intend to source your data?
• Does the process require data sharing with a third-party?
• Will the data leave the EU or North America?

Answering these questions will highlight the types of data processing that the GDPR may see as high risk. For example, if you intend to use profiling, then you will identify the process as one that requires a DPIA from the first question.

In addition to a description of the nature of your processing, you also need to describe the scope of it. In other words:

• Does the data include data from special categories?
• How much data is involved?
• How often will you collect and use data?
• How long do you intend to store it?
• Approximately how many data subjects will be involved?
• What geographical regions will the data come from?

Finally, you need to describe the context of the processing. It will show you whether the technology you intend to use brings up flaws or issues that require a DPIA. For example, you'll need to ask:

• How established is the technology you intend to use?
• Is the technology novel?
• What issues of public concern should you consider?
• How much control do data subjects have over their data?
• What is the relationship you have with individuals who give you their data?

A complete description of your processing activities and methods allows you to move forward to phase two because it identifies which of these require a DPIA before processing can begin.

Assessment of Necessity and Proportionality of Processing Activities

With full descriptions of your processing activities in hand, you're now ready to ask yourself an important question: Do you have both a reason and a lawful basis for engaging in this type of processing?

The GDPR focuses heavily on data minimization. If you don't have a reason or permission to engage in a processing activity, then you shouldn't do so. This particularly applies to those activities that come with a high risk for data subjects. You need a good and lawful reason for engaging in these practices.

Some of the questions you can ask include:

• Which of the six lawful bases apply to your processing?
• What is the purpose of the processing?
• Can you achieve the same goal using a different method?
• Does your processing adhere to principles of data minimization and data quality?
• What will data subjects know about their information?
• How will you support data subject rights during processing?
• What methods are in place to safeguard international transfers?

Again, these aren't the only questions you might ask. Be sure to ask further questions that relate directly to your organization or data processes.

If you can't answer the questions in a way that complies with the GDPR, then you may want to go back to the drawing board.

For example, if you do not have a legal basis for processing or your processing application does not fit the purpose, then you already have issues with the proposed idea regardless of the risks identified later in the DPIA.

Identifying and Assessing the Risks

By now, you understand that your data processing application is lawful, meets GDPR standards, and is necessary to meet your goals.

To move forward, you need to describe the risks associated with the activity.

Be sure to describe not only the risk but the potential it has to impact individuals' privacy and their ability to uphold their rights.

These risks are specific to your description of the processing activity, so it's important to be thorough.

You may also find it useful to rank the risks according to:

• Likelihood of harm
• Severity of harm
• Overall risk

Identifying Measures to Reduce and Eliminate the Risks

Finding risks isn't the end of the road. Virtually no data processing activity is risk-free. The point of the DPIA is to find ways to address each item signaled as having medium to high risk of harm or severe harm.

Remember to outline not only each measure to reduce the risk but to detail what effect it could have and whether there is a residual risk.

Some of the common categories of risks include:

• Breach of confidentiality or integrity
• Loss of personal data
• Mis-classification of data
• Prevention of exercising data subject rights

Keeping Documents

Your DPIA isn't something to do in your head or write on scrap paper.

To be GDPR compliant, you should prepare to hand over any and all potential documentation including a copy of your GDPR Data Protection Impact Assessment.

You don't need to publish your DPIA, but some industries may find they benefit from the perceived transparency of doing so. If you do choose to publish it, you don't need to upload the entire assessment, particularly if it includes security details. Even a summary of the findings provides helpful insight to those who may be concerned.

Ask Your DPO

If the GDPR required you to designate a Data Protection Officer (DPO), then you should present your DPIA to them for advice both during and after the process. Your DPO will then provide advice and potentially a summary, and you need to keep these as supporting information and documentation.

Examples of a GDPR Data Protection Impact Assessment

What does a GDPR Data Protection Impact Assessment look like in the wild? We found some helpful examples to illuminate the process for you regardless of the complexity of your data processing activities.

The University of Cambridge shares an example of the Data Privacy Impact Assessment it requires staff to complete.

The form includes seven parts:

• Section A: Describe the nature of the data processing
• Section B: Establishing the lawfulness of the data processing
• Section C: Transparency and awareness
• Section D: Re-use of existing personal data
• Section E: Accuracy of personal data
• Section F: Necessity of the data processing
• Section G: Data retention and security

Each part has sub-sections that ask important and relevant questions regarding the details of the processing.

At the end, it provides a form for the Data Protection Officer to complete that describes the risk of harm, immediate actions required, and recommendations for the college based on the questions asked on the previous pages.

This is a great way to answer relevant questions to determine the risk of processing, keep everything documented in one place and have a final review and determination made about the processing activity.

For another example, let's look at a template from the NHS - the public body that runs the UK's health service. As such, it is subject to strict data processing regulations both from the UK and the EU.

The South, Central and West faction of the NHS provides the DPIA template that services providers must use on its website.

In addition to a thorough explanation of the DPIA, it also includes several important parts. A brief overview of what the DPIA process is and what it generally requires is included in the beginning of the document:

Next, it introduces the DPIA with screening questions that reveal whether a DPIA is needed at all:

If the DPIA is required, users must use the following chart and accompanying documents:

This structure makes it very easy for even those not familiar with a DPIA to learn a little about what one is and determine if one is needed. If one is needed, this template helps walk anyone through the required steps to complete the DPIA.

The DPIA for the Scottish Government and the personal data it holds in a relationship with the European Social Fund provides an excellent example of an in-depth DPIA. It includes not only the four basic elements outlined by the GDPR but all general compliance procedures.

It begins with a very thorough description of the project, the data that's being processed for the project and how it will be processed. The legal basis for the processing is disclosed, also very thoroughly:

It then goes on to include a stakeholder analysis and consultation, which is not required under the GDPR but may be required by a supervisory body depending on the nature of the organization and its data processing activities:

Another unique section added to the Scottish Government's DPIA is the direct comparison of whether its processes are compliant with the principles of the GDPR. Descriptions of how each principle has been met are included:

The document carefully quotes each potential risk, the solution or mitigation, and the result of the solution in a chart so that each part tracks carefully to another.

The Scottish Government example largely applies to public bodies or groups that process large amounts of data, and thus have stringent compliance expectations. However, it is a useful document to view if the goal of your DPIA is to leave no stone unturned and to be as completely thorough as possible.

Summary

A GDPR Data Protection Impact Assessment is essential for anyone who:

• Falls under the scope of the GDPR,
• Is starting a new processing activity (after May 25, 2018), and
• The processing activity is likely to create a high risk to rights and freedoms of individuals when considering the nature, scope, context and purposes of the processing

It's also a good idea to conduct a DPIA on older processes, particularly if they present risks highlighted by the GDPR.

The point of a DPIA is to describe your processing activities, identify potential risks, and build in solutions from the very start of your design process. Doing so builds integrity both for your systems and your organization.

Don't forget to keep records of your DPIA to present to the authorities in case of a data breach or audit.