Privacy and Data Protection Impact Assessments

Privacy and Data Protection Impact Assessments (PIAs and DPIAs): A Complete CIPT Guide

Introduction
Privacy Impact Assessments (PIAs) and Data Protection Impact Assessments (DPIAs) are central tools in privacy risk management. The CIPT (Certified Information Privacy Technologist) exam tests them heavily because they are where privacy principles meet real technology, systems and engineering decisions. This guide covers why they matter, what they are, how they work and how to answer exam questions about them.

1. Why PIAs and DPIAs Are Important

Proactive risk management: A PIA or DPIA finds privacy risks before a system, product or process goes live. Fixing a privacy flaw at the design stage is far cheaper than fixing it after a breach, a regulatory action or a public backlash.

Privacy by Design and by Default: PIAs are the practical way to apply Privacy by Design (Ann Cavoukian's seven foundational principles) and GDPR Article 25 (data protection by design and by default). They turn abstract principles into concrete engineering requirements.

Legal and regulatory compliance:
- GDPR Article 35 requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of natural persons.
- GDPR Article 36 requires prior consultation with the supervisory authority if the DPIA shows high residual risk that cannot be mitigated.
- US E-Government Act of 2002 (Section 208) requires federal agencies to conduct PIAs for new or substantially changed IT systems that collect personally identifiable information (PII).
- Other frameworks also require or recommend them, including Canada's federal PIA directive, Australia's Privacy Act guidance and ISO/IEC 29134.

Accountability and demonstrable compliance: A documented PIA is evidence that the organization assessed risk responsibly. This supports the GDPR accountability principle (Article 5(2)).

Building trust: Published PIAs and transparent risk management build trust with customers, regulators and partners.

Cross-functional alignment: PIAs bring together engineering, legal, security, product, business owners and the DPO, so privacy is not handled in a silo.

2. What PIAs and DPIAs Are

Privacy Impact Assessment (PIA): A systematic process to identify, assess and reduce the privacy risks of a project, system, product, service or process that handles personal information. It is a broad, general-purpose tool used worldwide. It typically looks at compliance with Fair Information Practice Principles (FIPPs) and at the wider privacy impacts on individuals.

Data Protection Impact Assessment (DPIA): The specific term and process defined by the GDPR (Article 35). It is a type of PIA with prescribed minimum content and legal triggers. It focuses on risks to the rights and freedoms of data subjects, not only risks to the organization.

Key distinction: Every DPIA is a form of PIA, but not every PIA meets the formal requirements of a GDPR DPIA. In exam questions, the word DPIA usually signals a GDPR context.

Related assessments:
- Privacy Threshold Analysis (PTA) / screening questionnaire: A short initial assessment that decides whether a full PIA or DPIA is needed.
- Data Protection Assessment / Risk Assessment: Required under some US state laws (for example Colorado, Virginia and California CPRA regulations) for high-risk processing such as targeted advertising, sale of data, profiling or sensitive data.
- Transfer Impact Assessment (TIA): Assesses international data transfers after the Schrems II decision.
- Legitimate Interests Assessment (LIA): A three-part test of purpose, necessity and balancing.
- Security Risk Assessment: Focuses on confidentiality, integrity and availability. It overlaps with a PIA but is narrower.
- Algorithmic / AI Impact Assessment: Increasingly required for automated decision-making and AI systems (for example the EU AI Act's fundamental rights impact assessment).

3. When Is a DPIA Required? (GDPR Triggers)

Article 35(3) requires a DPIA in particular for:
1. Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that leads to decisions with legal or similarly significant effects.
2. Large-scale processing of special categories of data (Article 9), such as health, biometric, genetic, racial or ethnic origin, religion, sex life or orientation, political opinions and trade union membership, or of criminal conviction data (Article 10).
3. Systematic monitoring of a publicly accessible area on a large scale, such as CCTV.

The Article 29 Working Party (now EDPB) guidelines (WP248) list nine criteria. Processing meeting two or more of them generally requires a DPIA:
1. Evaluation or scoring, including profiling and predicting
2. Automated decision-making with legal or similar significant effect
3. Systematic monitoring
4. Sensitive data or data of a highly personal nature
5. Data processed on a large scale
6. Matching or combining datasets
7. Data concerning vulnerable data subjects, such as children, employees or patients
8. Innovative use or application of new technological or organizational solutions, such as IoT, facial recognition or AI
9. Processing that prevents data subjects from exercising a right or using a service or contract

Supervisory authorities also publish blacklists (processing that always requires a DPIA) and may publish whitelists (processing that does not), under Article 35(4) and (5).

4. Required Content of a DPIA (GDPR Article 35(7))
At a minimum, a DPIA must contain:
a) A systematic description of the processing operations and purposes, including the legitimate interest where applicable
b) An assessment of the necessity and proportionality of the processing in relation to the purposes
c) An assessment of the risks to the rights and freedoms of data subjects
d) The measures envisaged to address the risks, including safeguards, security measures and mechanisms that ensure protection of personal data and demonstrate compliance

Also note:
- The controller must seek the advice of the DPO, where one is designated (Article 35(2)).
- Where appropriate, the controller should seek the views of data subjects or their representatives (Article 35(9)).
- Processors must assist controllers with DPIAs (Article 28(3)(f)).
- The DPIA must be reviewed when the risk changes (Article 35(11)).

5. How a PIA / DPIA Works: The Process

Step 1: Screening / Threshold Analysis. Use a short questionnaire to decide whether personal data is involved and whether the processing is high risk. Document the decision even if no full assessment is needed.

Step 2: Plan and Scope. Identify the project owner, stakeholders, the DPO, the timeline and the systems in scope. Begin as early as possible in the system or software development life cycle (SDLC), ideally at requirements and design.

Step 3: Describe the Processing / Data Flow Mapping. Document:
- What data is collected, from whom and how
- The purposes and legal bases
- Where data is stored, who has access and with whom it is shared
- Retention periods and deletion methods
- Cross-border transfers
- Data flow diagrams and data inventory

Step 4: Assess Necessity and Proportionality. Check data minimization, purpose limitation, accuracy, storage limitation, transparency, lawful basis and how data subject rights are supported.

Step 5: Identify Privacy Risks. Consider risks to individuals: loss of confidentiality, discrimination, identity theft, financial loss, reputational harm, loss of autonomy, chilling effects, surveillance and inability to exercise rights. Useful tools include:
- Solove's Taxonomy of Privacy: information collection, processing, dissemination and invasion
- Calo's subjective and objective harms
- LINDDUN privacy threat modeling: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance
- NIST Privacy Framework and the NIST Privacy Risk Assessment Methodology (PRAM), which uses problematic data actions and their likelihood and impact
- FAIR for quantitative risk analysis
- Contextual Integrity (Nissenbaum)

Step 6: Evaluate Risk. Rate each risk by likelihood x severity (impact). Use a risk matrix (low, medium, high) or quantitative scoring.

Step 7: Identify Mitigating Controls. Examples include:
- Technical: encryption, pseudonymization, anonymization, access controls, logging, data minimization, differential privacy, tokenization, privacy-enhancing technologies (PETs)
- Organizational: policies, training, contracts (DPAs), vendor due diligence, retention schedules
- Transparency: privacy notices, just-in-time notices, consent mechanisms, user dashboards

Step 8: Assess Residual Risk and Sign-Off. Decide whether to accept, mitigate, transfer or avoid each risk. Management or the risk owner signs off. Under the GDPR, if high residual risk remains, consult the supervisory authority before processing (Article 36). The authority has up to 8 weeks to respond, extendable by 6 weeks.

Step 9: Integrate Outcomes into the Project. Turn the recommendations into requirements, user stories, design changes and test cases. A PIA that is not acted on has little value.

Step 10: Monitor and Review. A PIA is a living document. Revisit it when the system changes, new data types or purposes are added, new vendors are engaged, a breach occurs or laws change.

6. Roles and Responsibilities
- Controller: Legally responsible for carrying out the DPIA
- DPO: Advises on the DPIA and monitors its performance, but does not carry it out as the owner
- Processor: Assists by providing information
- Privacy technologist / engineer: Maps data flows, identifies technical risks and designs controls
- Project / business owner: Owns the processing and accepts residual risk
- Security team: Assesses security controls
- Legal / compliance: Interprets legal requirements
- Data subjects: Consulted where appropriate

7. PIAs in the Technology Lifecycle
For CIPT, know that PIAs fit into:
- SDLC / Agile: Run lightweight, iterative PIAs per sprint or feature, not only once at the end
- DevOps / CI-CD: Automated privacy checks, privacy champions and threat modeling sessions
- Vendor and cloud procurement: Assess third-party risk before onboarding
- Mergers and acquisitions: Assess acquired data assets
- Decommissioning: Confirm secure deletion

8. Benefits Beyond Compliance
- Early detection of design flaws
- Lower breach likelihood and impact
- Better data governance and inventory accuracy
- Evidence for audits and regulators
- Better product quality and user trust
- Informed business decisions about acceptable risk

9. Common Pitfalls
- Running the PIA too late, after the design is fixed
- Treating it as a checkbox exercise
- Assessing only organizational risk instead of risk to individuals
- Failing to update it after changes
- Not involving engineers, who know how the system actually works
- Not implementing the recommendations

10. Exam Tips: Answering Questions on Privacy and Data Protection Impact Assessments

Tip 1: Timing is everything. If asked when a PIA should be performed, choose the earliest stage: design, planning or requirements, before processing begins. Answers like 'after deployment' or 'during testing only' are usually wrong.

Tip 2: Know the three GDPR Article 35(3) triggers. These are automated decisions or profiling with significant effects, large-scale special category or criminal data, and large-scale systematic monitoring of public areas. Also remember the WP248 rule of thumb: two or more of the nine criteria = DPIA likely required.

Tip 3: Focus on the individual. DPIAs assess risk to the rights and freedoms of data subjects. If an option focuses only on financial or reputational risk to the company, it is probably a distractor.

Tip 4: Know the four minimum elements of a DPIA. These are description, necessity and proportionality, risk assessment, and mitigating measures.

Tip 5: High residual risk = prior consultation. If a scenario says risks cannot be sufficiently mitigated, the correct next step under the GDPR is to consult the supervisory authority before processing (Article 36). It is not 'proceed anyway', and not always 'abandon the project'.

Tip 6: The DPO advises; the controller is responsible. Watch for options claiming the DPO must perform or approve the DPIA. The controller is accountable and the DPO gives advice.

Tip 7: PIA vs. security assessment. A security risk assessment covers confidentiality, integrity and availability. A PIA is broader and covers notice, choice, purpose limitation, minimization, data subject rights and fairness. If a question asks which assessment covers transparency or data minimization, the answer is the PIA.

Tip 8: A PIA is a living document. If a scenario introduces new data, a new purpose, a new vendor or a new technology to an existing system, the answer is usually to revisit or update the PIA.

Tip 9: Recognize the frameworks. Be ready to identify LINDDUN (privacy threat modeling), Solove's taxonomy (privacy harms), the NIST PRAM (problematic data actions), FIPPs and ISO/IEC 29134 (PIA guidelines). Questions may describe a method and ask you to name it.

Tip 10: Pick the most appropriate control. In scenario questions, choose controls that address the specific risk at its root. Data minimization or pseudonymization usually beats simply adding a notice. Prefer technical, preventive controls to purely detective ones when the goal is reducing risk.

Tip 11: Threshold assessments come first. If asked about the first step in deciding whether a full PIA is needed, the answer is usually a Privacy Threshold Analysis or screening questionnaire.

Tip 12: Watch for 'BEST', 'FIRST', 'MOST' wording. Several answers may be partly true. Choose the one that is most proactive, risk-based and aligned with Privacy by Design. Eliminate options that are reactive or legally incomplete.

Tip 13: Data mapping is foundational. A PIA cannot assess risk without knowing what data exists and how it flows. If asked what is needed before risks can be assessed, think data inventory or data flow diagram.

Tip 14: Think cross-functional. The best answers involve stakeholders from engineering, legal, security and the business. Answers suggesting one person or department does the PIA alone are often weaker.

Tip 15: US federal context. For US government agencies, remember the E-Government Act of 2002, which requires PIAs for new IT systems handling PII. These PIAs are generally made publicly available.

Sample Question Approach:
Scenario: A company plans to deploy facial recognition in its retail stores to identify repeat shoplifters. What should the privacy technologist do FIRST?
Reasoning: The scenario involves biometric (special category) data, systematic monitoring, innovative technology and possibly large scale. That meets multiple WP248 criteria, so a DPIA is required before deployment. The best answer is to conduct a DPIA before implementation, not to update the privacy notice or encrypt the database, which are possible mitigations identified later in the process.

Summary
PIAs and DPIAs are structured, proactive and repeatable processes for identifying and reducing privacy risks to individuals. They are legally required in many contexts, especially under GDPR Article 35. They support Privacy by Design and accountability, and they turn privacy principles into technical controls. For the exam, remember to do them early, focus on risks to individuals, know the GDPR triggers and required content, consult the supervisory authority when high residual risk remains, and keep the assessment up to date.