The term Data Protection Impact Assessments (DPIAs) and Privacy Impact Assessments (PIAs) are often used interchangeably, however each carries a separate meaning and functions differently in practice. 

Over the years, more and more privacy and data protection laws such as the General Data Protection Regulation (GDPR) have included requirements to carry out some form of impact assessment, though they may not treat DPIAs and PIAs in the same way.

Let’s examine each definition and clarify their differences so your organization can leverage these assessments effectively. 

Data protection vs. Data privacy

Let's first take a look at the difference between data protection and data privacy.

Data privacy mainly comprises the policies that protect access to data based on user consent. Data privacy originates from privacy laws, which organizations translate into internal practices and rules that govern internal privacy practices. You can think of data privacy as the policies you have in place to respect consent and applicable laws. 

Data protection is a series of preventative controls taken by an organization that stops or minimizes unauthorized use of data assets. It’s the actions taken by an organization to keep outsiders from gaining access to the valuable data held by a business. You can consider data protection as the actions you take to prevent a data hack, data breach, or other data incidents — which closely aligns with the work of your security team. 

What is a Privacy Impact Assessment? 

Organizations worldwide employ PIAs to audit privacy risks as part of a complete data privacy strategy. 

PIAs are particularly useful when part of a go-to-market plan. That is, it may be easier to address privacy gaps prior to launching a new project or initiative compared to afterward. 

Global regulators encourage privacy by design. Embedding PIAs into your new product development process aligns with this perspective.

The work produced from a PIA is documentation of the processes, products, and third-party vendors involved in the collection and processing of personal data and personally-identifiable information (PII). The ultimate goal is to determine how these data flows impact privacy on a policy level.  

The ideal outcome of a PIA is to enable an organization to identify its vulnerabilities concerning privacy compliance. From this point, the team can determine the steps they need to take to remedy them.

PIAs in practice across the world

For templates and instructions provided by specific data authorities, review some examples through the following links: 

• PIAs according to France’s CNIL
• PIAs in Alberta, Canada
• PIAs according to British Columbia’s OIPC
• 10 steps to undertake a PIA in Australia
• How to conduct a PIA in New Zealand

What is a Data Protection Impact Assessment?

Data Protection Impact Assessments originate from Article 35 of the GDPR where it’s a legal requirement to carry out these risk assessments under certain circumstances. Like PIAs, DPIAs reflect the principle of data protection by design.

GDPR requirements state that data controllers should conduct a DPIA during the planning stages of any new data processing activities that may result in a high risk to the rights and freedoms of the data subject such as processing sensitive data.

A DPIA must contain the following: 

• Comprehensive documentation about the data collection or processing operation and its purpose.
• Justification for its stated purpose using one or several of the GDPR’s legal basis for processing.
• A risk analysis of the data subjects’ rights and freedoms in relation to your activities.
• The policies and procedures you’ll follow to mitigate these risks, protect personal data, and pursue GDPR compliance.

Examples of potentially high-risk processing activities under the GDPR

The Information Commissioner’s Office (ICO) provides a non-exhaustive list of contextual examples where a DPIA may be necessary: 

• The use of new technologies such as artificial intelligence, machine learning, autonomous vehicles, smart/wearable products, and more.
• Denial of service, including credit checks or mortgage applications  
• large scale profiling of natural persons based on automated decision making
• Processing biometric data, including facial recognition systems, identity verification, and access control for devices or software 
• Processing genetic data, such as medical diagnosis, testing, and research
• Data matching across disparate sources 
• Invisible processing through marketing list brokering, online tracking by third parties, and more

The GDPR also allows DPAs to create blacklists and whitelists. The former is a checklist of activities that would always require a DPIA. The latter is a similar checklist but comprised of activities that typically do not need a DPIA.

DPIAs and the CCPA (as amended)

Since the GDPR introduced DPIA requirements, other prominent regulatory bodies have taken notice. The CCPA (as amended) requires covered organizations to submit DPIAs to the California Privacy Protection Agency (CPPA). However, the requirements for submissions are still to be clarified through theCCPA (as amended) final regulations.  

Request a free trial of OneTrust DataGuidance today or follow OneTrust DataGuidance on LinkedIn to stay up to date with the latest news and developments in data protection laws.