Continue your mission
A Data Protection Impact Assessment (DPIA) is a structured risk analysis required under GDPR Article 35 before initiating processing activities likely to create high risks to individuals. This article covers when a DPIA is mandatory, what it must contain, the prior consultation requirement when residual risk remains unacceptable, and how CDA's PCA methodology integrates DPIAs into the continuous compliance lifecycle.
# Privacy Impact Assessment (DPIA)
A Data Protection Impact Assessment (DPIA) is a structured process for identifying, analyzing, and mitigating privacy risks before a new processing activity begins. GDPR Article 35 makes DPIAs legally mandatory when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The assessment must describe the processing, evaluate its necessity and proportionality, assess risks to data subjects, and identify technical and organizational measures to address those risks.
The DPIA is a pre-processing control. It does not validate that a system was built correctly after the fact. It forces the privacy and security implications of a new system or workflow to be examined before development resources are committed and before personal data is collected. This timing is the core of its value: changing a system design before it is built costs a fraction of retrofitting controls after deployment.
The DPIA is sometimes called a Privacy Impact Assessment (PIA), the term used in North American and Australian contexts. The concepts are substantively identical, though GDPR's DPIA requirements add specific structural mandates and a formal prior consultation path that many earlier PIA frameworks lacked. Under GDPR, failure to conduct a required DPIA, or conducting an inadequate one, is itself a violation that can result in supervisory authority action independent of any underlying harm.
Within the Planetary Defense Model, the DPIA bridges the DPS (Data Protection and Sovereignty) and RGA (Risk Governance and Assurance) domains. DPS governs what data is collected and how it is protected. RGA governs the processes that ensure that governance is real, documented, and continuously maintained. The DPIA is the gate that connects a new processing activity to both domains: it ensures that protection requirements are identified (DPS) and that the decision to proceed is documented, defensible, and subject to ongoing review (RGA).
When a DPIA Is Mandatory
GDPR Article 35(3) specifies three categories of processing that always require a DPIA:
First, systematic and extensive evaluation of personal aspects of natural persons, based on automated processing including profiling, and on which decisions are made that produce legal effects or similarly significantly affect the person. This covers algorithmic credit scoring, insurance underwriting systems, hiring algorithms, predictive policing, and any other system that uses automated processing to categorize people and make or recommend decisions about them.
Second, large-scale processing of special categories of data (health data, genetic data, biometric data used for unique identification, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life or sexual orientation) or of personal data relating to criminal convictions and offenses. The scale threshold is not defined numerically in the regulation, but supervisory authority guidance points to number of data subjects, geographic scope, data volume, and duration of processing as relevant factors.
Third, systematic monitoring of publicly accessible areas on a large scale. This covers CCTV surveillance, drone surveillance, facial recognition in public spaces, and behavioral tracking on public platforms.
Beyond these three explicit categories, Article 35(1) applies the DPIA requirement broadly to any processing "likely to result in a high risk." The European Data Protection Board (EDPB) has published guidance identifying nine additional risk criteria: evaluation or scoring; automated decision-making with legal or similar effects; systematic monitoring; sensitive or highly personal data; data processed on a large scale; matching or combining datasets; data concerning vulnerable persons (children, employees, patients); innovative use of new technologies; and data transfers across borders with novel safeguards. The presence of two or more of these factors typically triggers the DPIA requirement even if none of the three explicit Article 35(3) categories apply.
Each EU member state supervisory authority publishes a list of processing operations that require a DPIA in their jurisdiction. These national lists can add requirements beyond the baseline. In Germany, the DSK (Conference of Independent Data Protection Authorities) publishes an extensive list. The UK ICO publishes a screening checklist. Organizations operating across multiple EU jurisdictions must check national lists as well as the baseline GDPR requirements.
The Required Structure of a DPIA
GDPR Article 35(7) specifies that a DPIA must contain at minimum:
A systematic description of the envisioned processing operations and the purposes of the processing, including the legitimate interests pursued by the controller where applicable. This section documents what data is collected, from whom, through what means, by what systems, for what stated purpose, and on what legal basis under GDPR Article 6.
An assessment of the necessity and proportionality of the processing operations in relation to the purposes. This section challenges whether the stated purpose could be achieved with less data, less invasive processing, or shorter retention. It is where privacy-by-design principles are applied analytically. If the purpose can be achieved with anonymized data, the collection of personal data is not proportionate. If the purpose requires 30 days of data retention, retaining data for two years is not proportionate.
An assessment of the risks to the rights and freedoms of data subjects. This is the core risk assessment section, and it is where security expertise is essential. Risks include unauthorized access (external breach, insider threat), accidental disclosure (misconfigured access controls, misdirected communications), data corruption (integrity failures), processing beyond the stated purpose (function creep), discrimination arising from automated processing, and inability of data subjects to exercise their rights. Each risk is assessed for likelihood and severity. Severity includes reversibility: a breach of medical records may be irreversible in its reputational harm to the individual, while an accidental disclosure of a mailing list can be partially mitigated.
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 GDPR. This section maps from identified risks to specific controls: encryption at rest and in transit, access controls and role-based permissions, audit logging, data subject rights workflows, retention enforcement mechanisms, contractual controls for processors, and monitoring for anomalous access patterns.
Prior Consultation with the Supervisory Authority
Article 36 creates a mandatory pre-processing consultation requirement when a DPIA reveals that a processing activity would result in a high residual risk that the controller cannot adequately mitigate with available measures. In this case, the controller must consult the supervisory authority (the national DPA) before commencing processing.
The supervisory authority has eight weeks (extendable by six weeks in complex cases) to respond with written advice or to exercise its investigatory and corrective powers. If the DPA determines that the processing would violate GDPR, it must provide written advice and may use its powers to prohibit the processing.
Prior consultation is rarely invoked in practice, partly because most organizations successfully identify mitigating measures, and partly because the consultation requirement creates a strong incentive to redesign processing to reduce risk rather than submit to regulatory scrutiny. However, it is a real mechanism. German, French, and UK supervisory authorities have received prior consultation submissions, primarily for large-scale public sector surveillance systems and novel health data processing programs.
Conducting a DPIA in Practice
The DPIA is most effective when conducted as a cross-functional exercise involving privacy counsel, security engineers, the system architect or product owner, and a data subject representative or user advocate. Privacy counsel brings regulatory knowledge. Security engineers bring technical threat modeling expertise. The system architect understands the actual data flows. The user advocate provides the data subject perspective that the regulation requires be centered.
The sequence in practice follows this path: the privacy team screens proposed processing activities for DPIA triggers using the EDPB criteria and applicable national lists. If triggered, the DPIA is initiated before detailed system design begins. The processing is documented in the record of processing activities. The risk assessment draws on threat modeling outputs from security teams. Control selection follows from the risk assessment and is validated against the organization's existing control framework (ISO 27001, NIST CSF, CIS Controls). If residual risks remain, the team either redesigns the processing to eliminate the risk, accepts the risk with documented rationale, or consults the DPA.
The completed DPIA must be retained as a record. It is not a one-time document: GDPR requires that DPIAs be reviewed when there is a change in the processing that may affect the risk assessment.
The DPIA matters for three distinct reasons: legal obligation, economic logic, and organizational discipline.
The legal obligation is clear: failing to conduct a required DPIA is a violation of GDPR Article 35. Fines for this violation are imposed under GDPR Article 83(4), which allows penalties up to 10 million EUR or 2% of global annual turnover. Supervisory authorities have fined organizations specifically for DPIA failures, including a 2022 fine by the German DPA (Berlin) against an organization for operating a facial recognition system without conducting a required DPIA.
The economic logic is the classic case for upstream quality control. Identifying a privacy risk during the DPIA process, before development begins, costs a fraction of the effort required to retrofit controls, rearchitect data flows, or respond to a regulatory investigation after the fact. Studies of software security consistently show that fixing a defect in design costs roughly 5-10 times less than fixing it in development, and 10-100 times less than fixing it in production. Privacy risks have the same cost structure.
The organizational discipline argument is subtler but equally important. The DPIA process forces organizations to articulate exactly what data they are collecting, from whom, for what purpose, on what legal basis, for how long, and who has access. Many organizations, when subjected to this discipline for the first time, discover that they cannot answer these questions for existing systems. The DPIA process builds the habit of asking these questions before processing begins, which over time produces a data governance culture rather than a reactive compliance culture.
DPIA and Security Control Selection
The technical section of a DPIA directly drives security control selection. The risks identified in the DPIA (unauthorized access, data breach, function creep, integrity failure) map to specific control categories that security engineers implement. This makes the DPIA the governance document that connects privacy requirements to security engineering requirements.
Encryption controls address unauthorized access risks. Access control and identity management controls address both unauthorized access and excessive access by authorized users. Audit logging and monitoring address detection of anomalous access and support breach investigation. Data minimization at the application layer (collecting only required fields, anonymizing where identification is not needed) addresses scope risk. Retention enforcement (automated deletion at the end of the defined retention period) addresses the risks of unnecessary data accumulation. Contractual controls for processors address third-party exposure.
The DPIA creates a documented record of why each control was selected: not because a framework checklist required it, but because a specific risk was identified and the control was the appropriate mitigant. This traceability from risk to control is what makes the control environment auditable and defensible.
Integration with Threat Modeling
DPIA risk assessment and security threat modeling address overlapping territory from different starting points. Threat modeling (STRIDE, PASTA, LINDDUN) identifies how a system can be attacked or misused. DPIA risk assessment identifies how processing harms data subjects. Privacy-specific threat modeling frameworks, particularly LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance), align the two disciplines explicitly.
Organizations that integrate DPIA risk assessment with threat modeling produce more complete analyses than organizations that run them separately. A DPIA that borrows from threat modeling will identify technical attack paths (SQL injection leading to data exfiltration) alongside policy risks (employees accessing records beyond their need). A threat model that incorporates DPIA thinking will flag privacy harms (discrimination from aggregated inferences) alongside system compromise.
Children's Data and Special Category Data
Processing that involves children (under 16 under GDPR, under 13 under US COPPA) or special categories of data (health, biometric, genetic, race, religion, political opinion, sexual orientation) imposes elevated DPIA requirements and more demanding control standards. The severity weighting of breach risks increases substantially when the affected population includes children or when the data categories are more sensitive. Organizations processing children's data should assume a DPIA is required and apply the highest control tier.
CDA's Perpetual Compliance Assurance (PCA) methodology captures the central insight about compliance governance: "Compliance is not an event. It is a state." DPIAs are one of the clearest illustrations of this principle. A DPIA is not a document produced once to satisfy a regulatory requirement. It is a living record of a processing decision, the risk analysis that supported it, and the controls selected to manage it. That record must be revisited whenever the processing changes.
PCA integrates DPIAs into the compliance lifecycle through a change management gate. Every new processing activity, and every material change to an existing one, triggers a DPIA screening as part of the RGA-domain governance process. This screening is not bureaucratic friction. It is the mechanism that keeps the organization's risk profile current. New tools, new data integrations, new analytics initiatives all require the same question: what are the privacy risks, have we identified them, and are our controls adequate?
The operational implementation within CDA's RGA missions uses a DPIA register (maintained in the GRC platform of the organization's choice) that tracks every processing activity assessed, the DPIA outcome, the controls committed to, and the next scheduled review date. High-risk processing activities are reviewed annually or whenever a material change occurs. Lower-risk processing is reviewed on a biennial cycle. The register gives the data protection officer (DPO), the CISO, and the board a current view of the organization's privacy risk posture, not a historical snapshot.
CDA also cross-references DPIA outputs into the security control framework. When a DPIA identifies a risk that requires an encryption control, that control requirement is tracked in the same system as other security controls, with the same ownership, the same testing cadence, and the same reporting to the CISO. Privacy controls are not a separate compliance silo. They are security controls with a privacy risk rationale, governed through the same program that governs all other security controls.
This integration is particularly important for the DPS-domain Sovereign Data Protocol. The SDP asserts data sovereignty as a measurable operational state. A DPIA that identifies where data flows, who has access, and what controls protect it is the analytical foundation for SDP implementation. Organizations that have strong DPIA processes tend to have better data maps, better access controls, and more defensible retention practices than those that treat privacy impact assessment as a one-time compliance exercise.
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.