Many organisations treat a Data Protection Impact Assessment (DPIA) as a compliance document. Regulators increasingly see it differently. A DPIA is only valuable if the risks it identifies are actually addressed.
In January 2026, France’s data protection regulator (CNIL) fined France Travail EUR 5 million after finding that although the organisation had completed DPIAs, many of the recommended security measures were never implemented. Attackers later exploited those gaps and accessed data belonging to around 43 million people.
The case highlights an important lesson. A DPIA should not be treated as paperwork to complete before launching a project. It should guide decisions, reduce privacy risks, and ensure the right controls are put in place before personal data is processed.
What Is a Data Protection Impact Assessment?
A Data Protection Impact Assessment (DPIA) is a structured process used to identify and reduce privacy risks before processing personal data.
It helps organisations understand how personal data will be collected, used, stored, and shared, assess the potential impact on individuals, and determine what controls are needed to reduce those risks.
Unlike a general risk assessment, a DPIA focuses on risks to individuals rather than risks to the organisation. It is completed before processing begins and should result in practical actions, not just documentation.
DPIA vs Privacy Impact Assessment vs Security Audit
These terms are often used interchangeably, but they serve different purposes.
| Data Protection Impact Assessment | Privacy Impact Assessment | Security Audit | |
| Purpose | Assess privacy risks before processing begins | Evaluate broader privacy impacts | Verify security controls |
| When used | Before high-risk processing | Usually during project planning | After systems are operational |
| Primary focus | Risks to individuals | Privacy practices and governance | Effectiveness of security controls |
| Standard | GDPR Article 35, national privacy laws | ISO/IEC 29134 | ISO/IEC 27001, NIST CSF |
| Key question | Should this processing proceed? | How does this affect privacy? | Are security controls working? |
When a DPIA Is Required
A DPIA is not required for every processing activity. However, privacy laws generally require one whenever personal data processing is likely to create a high risk for individuals.
Mandatory Triggers Under the GDPR
Article 35 of the GDPR identifies three situations where a DPIA is mandatory.
| Trigger | Example |
| Automated profiling that significantly affects individuals | Credit scoring, automated recruitment, insurance pricing |
| Large-scale processing of sensitive personal data | Health records, biometric data, religious beliefs |
| Large-scale monitoring of public areas | CCTV networks, public surveillance systems |
Other High-Risk Processing Criteria
Even if the mandatory triggers do not apply, regulators generally expect a DPIA when two or more of the following risk factors are present:
- Automated profiling or evaluation
- Automated decision-making
- Systematic monitoring
- Processing sensitive personal data
- Large-scale processing
- Combining datasets from multiple sources
- Processing data relating to children, employees, or other vulnerable individuals
- Using new or emerging technologies
- Processing that limits an individual’s rights or access to services
How to Conduct a DPIA
Although the exact methodology varies between regulators, most DPIAs follow the same core process.
1. Screen whether a DPIA is needed
Review the planned processing against regulatory triggers, published guidance, and your organisation’s internal criteria. Even if a DPIA is not required, document the decision and the reasons behind it.
2. Describe the processing
Document what personal data will be collected, why it is needed, the legal basis for processing, who will receive the data, how long it will be retained, and whether it will be transferred internationally.
3. Map the data flows
Identify where personal data is collected, stored, shared, and deleted. Include cloud services, third-party providers, integrations, backup systems, and cross-border data transfers.
4. Assess necessity and proportionality
Consider whether all of the data being collected is genuinely required. Could the same objective be achieved with less personal data or by using pseudonymised information?
5. Identify risks to individuals
Focus on how the processing could affect the people whose data is being processed. Examples include identity theft, financial loss, discrimination, reputational harm, or physical safety risks.
6. Score the level of risk
Evaluate both the likelihood and severity of each identified risk using a consistent scoring method. This helps prioritise the risks that require additional controls.
7. Define mitigation measures
Identify the technical and organisational controls needed to reduce each risk. Every mitigation should have a clearly assigned owner, implementation timeline, and expected outcome. If high residual risks remain after mitigation, the GDPR requires organisations to consult the relevant supervisory authority before proceeding.
8. Sign off, review, and maintain the DPIA
A DPIA is not a one-time exercise. It should be reviewed whenever significant changes are made to systems, processing activities, technologies, or business operations.
Choosing a Risk Scoring Method
A consistent risk scoring method helps organisations prioritise privacy risks and compare assessments across different projects. Several recognised frameworks can support this process.
1. The CNIL Method
The French data protection regulator (CNIL) provides one of the most widely used DPIA methodologies. It assesses each risk based on two factors: likelihood and severity, using a four-level scale ranging from negligible to maximum.
The framework also considers the potential impact on individuals, including physical, financial, and reputational harm. Because it includes free guidance and supporting software, it is often a practical starting point for organisations implementing DPIAs for the first time.
2. ISO/IEC 29134
ISO/IEC 29134 provides international guidance for conducting privacy impact assessments. It is particularly useful for organisations that already follow ISO 27001 or are implementing ISO/IEC 27701, as the terminology and governance processes align closely.
Unlike the CNIL methodology, ISO/IEC 29134 is well suited to assessing broader information systems rather than individual processing activities.
3. The NIST Cybersecurity Framework
The NIST Cybersecurity Framework (NIST CSF) is not a DPIA methodology, but it complements one.
Once privacy risks have been identified, the NIST CSF helps organisations select and organise security controls across its six core functions: Govern, Identify, Protect, Detect, Respond, and Recover.
It is important to remember that the NIST CSF focuses on cybersecurity risk, while a DPIA focuses on privacy risk. Both frameworks work best when used together rather than as substitutes for one another.
Read More: What Is the NIST Cybersecurity Framework?
DPIA Requirements by Jurisdiction
Privacy laws around the world take different approaches to DPIAs, but they all share the same goal: identify and reduce high-risk processing before personal data is used.
Indonesia
Under UU No. 27/2022 tentang Perlindungan Data Pribadi (UU PDP), organisations must conduct a DPIA when processing is likely to pose a high risk to individuals. This includes automated decision-making, processing sensitive personal data, large-scale processing, and systematic monitoring or evaluation.
The two-year transition period ended on 17 October 2024, meaning the DPIA requirement is now fully in effect. Organisations can face administrative penalties of up to 2% of annual revenue for non-compliance.
If your organisation processes high-risk personal data, a DPIA should already be part of your privacy programme.
Malaysia
Malaysia introduced comprehensive DPIA guidance in April 2026, alongside new guidelines covering automated decision-making, profiling, and data protection by design.
A DPIA is generally required for large-scale processing, high-risk processing activities, or any use of automated decision-making or profiling. Organisations must keep DPIA records for at least two years after processing ends and review assessments every two years.
Under the Personal Data Protection (Amendment) Act 2024, breaches of the data protection principles can result in fines of up to RM1 million and imprisonment of up to three years.
Malaysia now has one of the most detailed DPIA frameworks in Southeast Asia, making regular reviews and governance essential.
Vietnam
Vietnam has one of the most prescriptive DPIA requirements in the region.
Under Law No. 91/2025/QH15 and Decree 356/2025/ND-CP, organisations must prepare a DPIA dossier and submit it to the Ministry of Public Security within 60 days of starting personal data processing. Separate assessments are also required for cross-border data transfers.
DPIAs must be updated whenever processing changes significantly and may be reviewed during regulatory inspections. In Vietnam, a DPIA is not just an internal assessment. It is a formal regulatory requirement.
Europe and the UK
The GDPR requires organisations to complete a DPIA whenever processing is likely to create a high risk to individuals. If significant risks remain after mitigation, organisations must consult the relevant supervisory authority before proceeding.
Many European regulators also publish lists of processing activities that automatically require a DPIA, so organisations should always check their local regulator’s guidance. GDPR provides the foundation for many DPIA requirements worldwide, but local guidance may introduce additional obligations.
DPIA Template and Example
Knowing the process is one thing. Putting it into practice is another. To help you get started, we’ve created a free DPIA template that you can use to identify privacy risks, document mitigation measures, and standardise assessments across your organisation
DPIA Enforcement Cases
Recent enforcement actions show that regulators are willing to penalise organisations for failing to conduct a DPIA or for not acting on its findings.
1. France Travail (EUR 5 Million)
France Travail completed DPIAs before processing personal data, but many of the recommended security controls were never implemented. Attackers later exploited those weaknesses and accessed the personal data of around 43 million people. The CNIL fined the organisation EUR 5 million, demonstrating that completing a DPIA is not enough if the identified controls are never put into practice.
Lesson learned: A DPIA only delivers value when its recommendations are implemented and continuously maintained.
2. Swedish Police Authority (SEK 2.5 Million)
The Swedish Authority for Privacy Protection found that police officers had used the Clearview AI facial recognition service without completing the required DPIA. The authority imposed a SEK 2.5 million fine and ordered additional governance measures, staff training, and deletion of the unlawfully processed data.
Lesson learned: New technologies should never be deployed without first assessing their privacy impact.
3. Dutch DPA and ICS (EUR 150,000)
International Card Services introduced an online identity verification process for around 1.5 million customers without conducting a DPIA. Although no data breach occurred, the Dutch regulator concluded that the processing met the GDPR’s high-risk criteria and fined the company EUR 150,000.
Lesson learned: A missing DPIA can result in enforcement action, even when there is no security incident.
Common Mistakes of DPIA
Even organisations that conduct DPIAs can make mistakes that reduce their effectiveness.
1. Conducting the DPIA too late
A DPIA should be completed before processing begins so privacy risks can influence the design of a project. Running it after deployment turns it into a compliance exercise rather than a decision-making tool, as changing systems after they are live is often more difficult and costly.
2. Assessing the wrong risks
A DPIA focuses on risks to individuals, not business risks such as regulatory fines or operational downtime. The assessment should consider how people could be affected, including identity theft, discrimination, financial loss, reputational harm, or loss of privacy.
3. Reusing old assessments
Every processing activity should have its own assessment. Reusing an existing DPIA may overlook changes in data flows, technologies, or processing purposes, resulting in privacy risks that are no longer accurately assessed.
4. Failing to keep the DPIA updated
A DPIA should be reviewed whenever systems, technologies, vendors, or processing activities change. Keeping assessments up to date ensures that new privacy risks are identified before they become security or compliance issues.
5. Not involving the DPO
Where required, the Data Protection Officer (DPO) should be involved throughout the assessment process. Their advice helps ensure privacy risks are properly evaluated, regulatory requirements are considered, and appropriate safeguards are recommended.
6. Never verifying the controls
Completing a DPIA is only the first step. Organisations should regularly review and test the controls they implemented to ensure they continue to work as intended, especially after system changes or new processing activities are introduced.
Putting DPIA Findings Into Practice
A DPIA is only effective when its recommendations are put into practice. Risk controls should be assigned to clear owners, built into day-to-day operations, and reviewed regularly to ensure they continue to work. Whenever systems, processes, or data handling change, the DPIA should be reviewed as well.
Zentara helps organisations turn DPIA findings into practical security improvements. Our cybersecurity consultants support privacy governance, while our VAPT services validate that security controls work as intended and our Managed SOC continuously monitors for emerging risks.
Explore how Zentara can help strengthen your privacy and cybersecurity programme with practical security services.
Frequently Asked Questions
1. What is the difference between a DPIA and a PIA?
A DPIA is mandated by GDPR Article 35, with prescribed contents and penalties for omission. A PIA is a broader voluntary practice with no fixed format.
2. Is a DPIA the same as a security audit?
No. An audit asks whether your controls work. A DPIA asks whether the processing should happen at all, given the risk it poses to individuals.
3. Who is responsible for conducting a DPIA?
The data controller. Where a DPO is appointed they must be consulted and they advise, but the controller decides.
4. When in a project should a DPIA be done?
During design, while the architecture, vendors, and data flows can still change. A DPIA run at launch can document risk but no longer reduce it.
5. Do I have to file a DPIA with a regulator?
Under GDPR, no, unless residual risk stays high after mitigation. Vietnam is the exception: Decree 356 requires submitting the DPIA dossier to the Ministry of Public Security within 60 days of starting processing.
6. What happens if you skip a required DPIA?
It is a standalone violation. Under GDPR it carries fines of up to EUR 10 million or 2 percent of global turnover.
7. How long is a DPIA valid?
Most regimes set no expiry but require review when the processing materially changes. Malaysia is the strictest, requiring a refresh every two years.
8. Does the EU AI Act replace the DPIA?
No. The Fundamental Rights Impact Assessment complements a DPIA under Article 27(4). Completing one does not satisfy the other.
