Conducting Gdpr Dpia

Conducting GDPR Data Protection Impact Assessment

Overview

A Data Protection Impact Assessment (DPIA) is a structured process mandated by Article 35 of the GDPR to identify, assess, and mitigate risks to the rights and freedoms of natural persons arising from data processing operations. The DPIA is not merely a compliance checkbox but a living risk management instrument that must be conducted before processing begins and updated throughout the processing lifecycle. This skill implements the methodology recommended by the European Data Protection Board in WP248rev.01 (Guidelines on Data Protection Impact Assessment) and incorporates enforceable requirements from Art. 35(1)-(11).

Mandatory DPIA Triggers — Art. 35(3)

A DPIA is required when processing is likely to result in a high risk to the rights and freedoms of natural persons, particularly in these cases:

Automatic Triggers Under Art. 35(3)

EDPB WP248rev.01 Criteria — Two or More Triggers Require a DPIA

The EDPB established nine criteria for identifying high-risk processing. If a processing operation meets two or more of these criteria, a DPIA is presumptively required:

1. Evaluation or scoring — Profiling, prediction, credit scoring, behavioural analysis
2. Automated decision-making with legal or significant effect — Processing that determines access to services, contracts, or benefits
3. Systematic monitoring — Observation, tracking, or surveillance of data subjects
4. Sensitive data or data of a highly personal nature — Art. 9 special categories, financial data, communications metadata, location data
5. Data processed on a large scale — Volume of data subjects, volume of data items, geographic scope, duration of processing
6. Matching or combining datasets — Merging data from multiple sources beyond the data subject's reasonable expectation
7. Data concerning vulnerable data subjects — Children, employees, mentally ill, asylum seekers, elderly, patients
8. Innovative use or applying new technological solutions — Fingerprint and facial recognition combined with access control, IoT applications, AI-driven processing
9. Processing that prevents data subjects from exercising a right or using a service — Including but not limited to screening processes that block access

DPIA Content Requirements — Art. 35(7)

Every DPIA must contain at minimum the following four elements:

(a) Systematic Description of Processing Operations and Purposes

• Nature of the processing: collection, recording, organisation, structuring, storage, adaptation, alteration, retrieval, consultation, use, disclosure, dissemination, combination, restriction, erasure, destruction
• Scope: categories of data subjects, categories of personal data, volume and frequency, geographic scope
• Context: relationship between controller and data subjects, how data was obtained, data subject expectations
• Purpose: specific purposes per Art. 5(1)(b), lawful basis under Art. 6(1), and if applicable Art. 9(2) condition

(b) Assessment of Necessity and Proportionality

• Lawful basis justification with specificity
• Purpose limitation analysis: is each data element necessary for the stated purpose?
• Data minimisation assessment: could the purpose be achieved with less data or anonymised data?
• Storage limitation: are retention periods justified and enforced?
• Data subject rights facilitation: how are Arts. 15-22 rights enabled?
• Safeguards for international transfers under Chapter V where applicable

(c) Assessment of Risks to Rights and Freedoms

For each identified risk, assess:

Types of harm to assess:

• Physical harm (discrimination leading to violence, denial of healthcare)
• Material harm (financial loss, identity theft, loss of employment)
• Non-material harm (reputational damage, emotional distress, loss of autonomy)
• Social harm (chilling effect on free speech, discrimination, exclusion)
• Loss of control over personal data (inability to exercise rights, unknown processing)

(d) Measures to Address Risks

• Technical measures: encryption at rest and in transit (AES-256, TLS 1.3), pseudonymisation per Art. 4(5), access controls (RBAC), automated deletion, audit logging
• Organisational measures: privacy policies, staff training, DPO oversight, incident response procedures, data processing agreements per Art. 28
• Contractual measures: data subject notification, consent mechanisms, processor obligations
• Residual risk assessment: risk level after implementation of mitigating measures

DPIA Process Methodology

Step 1: Screening and Scoping (Week 1)

1. Complete the Privacy Threshold Analysis questionnaire to confirm DPIA obligation.
2. Define the processing operation boundary: which systems, data flows, and organisational units are in scope.
3. Identify the DPIA team: processing owner, DPO, IT security representative, legal counsel, and where appropriate a data subject representative per Art. 35(9).
4. Gather existing documentation: system architecture diagrams, data flow maps, privacy notices, consent forms, processor agreements.

Step 2: Systematic Description (Week 2)

1. Map the complete data lifecycle from collection to deletion.
2. Document all data elements processed, with lawful basis for each.
3. Identify all recipients and sub-processors.
4. Document international transfers and applicable safeguard mechanisms.
5. Record the technology stack and infrastructure involved.

Step 3: Necessity and Proportionality Assessment (Week 3)

1. For each data element, document why it is necessary for the stated purpose.
2. Assess whether less invasive alternatives could achieve the same purpose.
3. Evaluate data minimisation compliance.
4. Confirm retention periods are proportionate and technically enforced.
5. Verify data subject rights can be exercised effectively.

Step 4: Risk Identification and Assessment (Week 3-4)

1. Conduct threat modelling against the data flow map (sources of risk: internal actors, external attackers, processors, system failures).
2. For each threat, assess likelihood and severity using the matrix in Art. 35(7)(c).
3. Document risks in the risk register with unique identifiers.
4. Calculate inherent risk levels before mitigation.