Data protection impact assessments (DPIA), sometimes referred to as a Privacy Impact Assessment (PIA), are a tool used to describe how you intend to process and protect the personal information(PI, PII, etc) of individuals. Many forms of regulation including the GDPR and some compliance standards will require a DPIA depending on the risk levels associated with the data you are processing.
In this article we'll explore when you need to complete a DPIA, the kinds of information to include, and how you can incorporate the generation of these documents into your existing product and software workflows.
When do you need a DPIA?
For many data processes, a DPIA will won't be required—but you might still want to complete one. Data protection impact assessments are required when the data processing activity is determined to be "high risk." The GDPR specifically requires them as part of Article 35. Other regulations may require some form of a data protection or privacy impact assessment in order to show commitment toward protecting a consumer's privacy.
As risk levels aren't clearly defined, here are a few activities that you can consider high risk.
- Automated decision-making based on personal information that could impact the individual's life in meaningful ways. This could include extensive profiling activities such as approvals of bank loans, job screening, credit checks and credit references, or legal processing.
- Monitoring of publicly accessible places, such as wireless access point data, security footage of public places, or traffic footage.
- High volume processing of sensitive personal data, such as identification numbers, financial records, or job applicant data.
Determining if an activity qualifies as high risk can be a challenge. In cases where there is any ambiguity it is best to conduct a DPIA. This will avoid any future regulatory problems, and if your organization adheres to a privacy by design it won't be an unfamiliar part of any new project.
Remember that DPIAs should be conducted for each new feature or product whenever the processing of personal information occurs, and when it is deemed high risk.
What information is included in a DPIA?
Various nations within the EU have their own expectations for what makes up a DPIA, though they cover similar areas. One point of reference is the DPIA template provided by the UK government. You can use it as a worksheet when completing your DPIA documentation.
A DPIA consists of:
- A description of the project
- A description of what data is processed and how
- Who is involved in the process
- An assessment of the necessity of the data processing
- Any identifiable risks and their severity
- What actions will be taken to mitigate or reduce risks
- Approval and sign-off from all the relevant stakeholders.
The most involved portion will be describing how the data is processed. You will need to prepare details about the following:
- Descriptions of the types of processing, how data is collected, how it is stored, and any sharing or sale that may occur. This aspect benefits greatly from a data flow diagram and data mapping.
- The scope of the processing. How sensitive is the data, what kind of data is processed, where is the data stored, and how much of the data is being used.
- The connection between your organization and the individuals whose data you are processing. This is considered the context for the processing, and should include details on the types of individuals you are collecting data about as well as how much control the individual has over the data.
- The purpose of the processing. What are your goals for processing the data and what benefit does it have for the individuals?
Who is responsible for a DPIA?
Impact assessments should be conducted by the individuals building the processing activities. They will likely be done in collaboration between engineering and product teams, and overseen by CISO's or team leads.
The data protection officer (DPO) will consult and offer guidance on where certain activities fall within the landscape of various regulations, and in general act as the final level of oversight and approval. In cases where the advisement of the DPO is overruled, it is common to include which individuals made the decision and explain the reasoning.
Large scale organizations may place all of this under the umbrella of legal or compliance teams. Data integrity or security teams are not always directly associated with those working toward compliance, so don't assume that a single department is in charge of everything data related. Maintaining individual DPIAs for each processing activity can be a challenge, and leaving the responsibility up to individuals may lead to neglect and non-compliance.
How does security play a role?
Data security is perhaps the most important part of data protection. Without it, good privacy practices won't prevent leaks of insecure data systems. DPIAs can play a dual role and be part of a security assessment. They can act as the first stage, before a product or feature is built, that can be assessed against later by your security team. This should happen once engineering builds the feature. The best way to ensure this happens is to attach DPIAs to the appropriate components and data in your data inventory. By identifying security concerns early, your teams can better determine the software requirements. As they build, a solid DevSecOps workflow can detect if these requirements were met and notify the appropriate data security team members.
Incorporating DPIAs into your existing workflow
Some organizations are accustomed to putting compliance paperwork at the end of the software development lifecycle. They build, do an internal audit, fix things, and then perform a formal audit. As DPIAs need to be created prior to building a new feature or product, this clearly doesn't line up. Instead, your organization needs to move privacy and data security to the beginning of your process. It should start in product, continue through development, and continue throughout the rest of a product's life.
In addition to making sure you are in line with regulations, conducting a DPIA at the outset of a project helps solidify what processing will be done and what data needs to be collected. This helps remove any ambiguity that may come up as features evolve. It also acts as a reference point when questions arise about how personal information should be handled. One of the key aspects of privacy by design is to deeply incorporate privacy and data security into the structure of your organization. By generating DPIAs early, and making sure they are visible to all stakeholders, you enable your whole team to adhere to this PbD.
While a data protection impact assessment may seem like a formality, it can help map out the ways your team will handle personal information when building software. Each DPIA shows regulators that your organization has taken the appropriate steps toward protecting the privacy of your customers. It keeps you accountable and the sign-off portion directly names individuals, so it is in everyone's best interest to abide by any claims made within the impact assessment.