DPIA Explained: What Every Organization Needs to Know

A privacy risk is much easier to fix before a system goes live than after personal data has already started flowing through it.

Consider an AI system that profiles customers, a platform that continuously monitors employees, or an analytics tool that combines data from multiple sources. Each may create risks to individuals that are difficult to see from the technology alone, and some types of processing require organizations to assess those risks before they begin.

A Data Protection Impact Assessment (DPIA) is the process used to identify those risks, assess their potential impact, and determine what safeguards are needed. This guide explains when a DPIA is required, what it must contain, how to conduct one, and how DPIAs apply to AI systems and other high-risk processing under GDPR and the EU AI Act.

Key takeaways

• A DPIA helps organizations identify and address privacy risks before high-risk processing begins.
• GDPR Article 35 requires a DPIA when processing is likely to result in a high risk to individuals’ rights and freedoms.
• Common DPIA triggers include large-scale sensitive data processing, systematic monitoring, profiling, and certain automated decision-making activities.
• A DPIA should assess how personal data is collected, used, stored, shared, and protected, as well as the potential impact on individuals.
• The assessment should identify specific safeguards that can reduce or eliminate the risks before processing begins.
• Organizations should involve the DPO and other relevant stakeholders early, rather than treating the DPIA as a documentation exercise at the end of a project.
• AI systems can create additional assessment requirements, making it important to consider GDPR obligations alongside applicable EU AI Act requirements.
• A DPIA should be reviewed when the processing, technology, data, or level of risk materially changes.

What is a DPIA?

A Data Protection Impact Assessment (DPIA) is a documented process used to identify and reduce privacy risks before an organization carries out high-risk processing of personal data. It examines how personal data will be used, how individuals could be affected, and what safeguards are needed to reduce those risks.

DPIA vs. PIA: What is the difference?

A Privacy Impact Assessment (PIA) is a broader term for assessing privacy risks in a project, system, or process. It can be used voluntarily or under privacy requirements in different jurisdictions. A DPIA is more specific. It refers to the assessment required under GDPR and follows defined requirements for when it must be conducted, what it should cover, and how privacy risks should be addressed. In simple terms, a DPIA is a legally required form of privacy impact assessment under GDPR, while a PIA is the broader concept. Not every PIA is a DPIA, but a DPIA can be considered a type of PIA.

Who is responsible for a DPIA?

The data controller is ultimately responsible for ensuring that a DPIA is conducted when required. The controller determines why and how personal data is processed, so it is also responsible for assessing the associated risks and deciding what measures are needed to address them. The DPO must be consulted where the organization has appointed one. If a data processor is involved in the processing, the processor must also assist the controller with the DPIA where required.

Why DPIAs matter for AI in 2026

AI has made DPIAs increasingly relevant because many AI systems process personal data in ways that can significantly affect individuals. Systems used for profiling, automated decision-making, employment, credit, healthcare, or other high-impact purposes may create privacy risks that need to be assessed before deployment. The EU AI Act also introduces additional assessment requirements for certain high-risk AI systems. Where both GDPR and the AI Act apply, organizations may need to address privacy risks through a DPIA alongside broader fundamental-rights considerations under the AI Act. A DPIA should therefore be treated as part of the design and governance process, rather than a document prepared after a system has already been deployed.

When is a DPIA mandatory under GDPR?

Under GDPR Article 35, a DPIA is required before processing begins when the processing is likely to result in a high risk to individuals’ rights and freedoms. This assessment considers the nature, scope, context, and purposes of the processing, rather than simply the technology being used. The GDPR identifies three specific situations where a DPIA is mandatory. Beyond these, national Data Protection Authorities (DPAs) can identify additional processing activities that require a DPIA, while EDPB risk criteria help organizations assess whether other processing activities are likely to create a high risk. The following 5 points show the main situations organizations should consider when determining whether a DPIA is required.

1. Systematic profiling with significant effects

A DPIA is mandatory when an organization carries out systematic and extensive profiling that forms the basis for decisions producing legal effects or similarly significant effects on individuals. Examples include:

• Automated credit scoring
• AI-based recruitment or candidate screening
• Insurance risk profiling
• Behavioral profiling that can significantly affect individuals

The key consideration is not simply whether profiling takes place. The processing must be systematic and capable of producing a significant effect on the individual.

2. Large-scale processing of special category data

A DPIA is also mandatory when an organization carries out large-scale processing of special category personal data. This includes particularly sensitive information such as health, genetic, biometric, or other data covered by GDPR’s special category provisions. Examples could include healthcare systems analyzing patient records at scale or biometric identification systems operating across large populations. Organizations should consider both the type of data and the scale of processing when determining whether this trigger applies.

3. Systematic monitoring of publicly accessible areas

Systematic monitoring of publicly accessible areas is another automatic DPIA trigger under Article 35. A common example is a large-scale CCTV network monitoring public spaces. Other forms of continuous location or behavioral monitoring may also require assessment depending on how the monitoring is conducted and the risks it creates. The focus is on systematic monitoring rather than an isolated or occasional observation. Organizations should consider the scale, duration, coverage, and potential impact of the monitoring activity.

4. Additional requirements from national DPAs

The 3 situations above are specifically identified in GDPR Article 35(3), but they are not the only circumstances where a DPIA may be mandatory. Under Article 35(4), national Data Protection Authorities can publish lists of processing activities that require a DPIA within their jurisdiction. This matters for organizations operating across multiple EU or EEA countries. A processing activity that does not fall clearly within one of the three GDPR examples may still require a DPIA if it appears on the relevant national DPA’s list. Organizations should therefore check the requirements of the specific DPA or DPAs responsible for their processing activities rather than relying only on the general GDPR triggers.

5. Multiple high-risk indicators identified by the EDPB

The EDPB’s risk assessment criteria provide another way to determine whether processing is likely to create a high risk. The criteria include:

• Evaluation or scoring of individuals
• Automated decision-making with significant effects
• Systematic monitoring
• Processing sensitive or highly personal data
• Processing data on a large scale
• Combining or matching datasets from different sources
• Processing involving vulnerable individuals
• Using new or innovative technologies
• Processing that involves transferring data outside the EU or EEA

When processing meets two or more of these criteria, it generally indicates that a DPIA should be conducted.

The 2026 game-changer: DPIA + FRIA for high-risk AI

One of the most significant changes in 2026 is the introduction of the EU AI Act’s Fundamental Rights Impact Assessment (FRIA). For organizations deploying certain high-risk AI systems, FRIA adds a new assessment requirement alongside the existing GDPR Data Protection Impact Assessment (DPIA).

DPIA: Assessing privacy and data protection risks

A DPIA focuses on how the processing of personal data could affect individuals’ rights and freedoms.

• Required under GDPR Article 35 when processing is likely to pose a high risk to individuals.
• Conducted by the data controller before the relevant processing begins.
• Focuses on risks related to personal data and privacy.
• Helps organizations identify and reduce data protection risks before they cause harm.

FRIA: Assessing broader fundamental rights risks

A FRIA looks beyond privacy to consider how a high-risk AI system could affect people’s fundamental rights.

• Required under Article 27 of the EU AI Act for deployers of Annex III high-risk AI systems.
• Must be completed before deploying the AI system.
• Covers broader impacts such as discrimination, equal treatment, access to essential services, and access to justice.
• Applies alongside the DPIA where both requirements are triggered.

How the two assessments work together

The key point is that a DPIA and FRIA are not substitutes for each other. They assess different types of risk, so organizations may need both before deploying a high-risk AI system. At the same time, organizations do not have to duplicate the entire assessment process. The EU AI Act allows relevant work from a DPIA to be reused when conducting the FRIA. The FRIA can therefore complement the DPIA while addressing the broader fundamental rights risks that privacy assessment alone may not capture. For organizations deploying high-risk AI, the practical takeaway is clear: privacy assessment is only one part of responsible AI governance. The assessment process must also consider how the system could affect fundamental rights.

DPIA for AI systems: what standard templates miss

A standard DPIA template can provide a useful starting point, but it was often designed around more conventional data processing, such as CRM systems, databases, or website analytics. AI systems introduce risks that can change over time and may not be obvious from the data-processing workflow alone. Using a generic template without adapting it can result in a DPIA that is complete on paper but misses important AI-specific risks.

1. Training data memorization

AI models can unintentionally memorize information from their training data and reproduce it in later outputs. This creates a privacy risk when the training dataset contains personal or sensitive information. Example: an organization could train a model using internal documents that contain employee records, customer information, or support conversations. If the model later reproduces parts of that information in response to a prompt, personal data could be disclosed to someone who should not have access to it. An AI-specific DPIA should therefore examine:

• Where the training data comes from
• Whether it contains personal or sensitive data
• The legal basis for using that data
• What controls limit the exposure or reproduction of personal data
• Whether the model has been tested for memorization or unintended data disclosure

2. Hallucinations and inaccurate outputs

Generative AI can produce false or misleading information while presenting it confidently and convincingly. This creates a different type of risk from a conventional database error because users may trust the AI output and use it to make decisions. Example: an AI system supporting HR could generate an incorrect summary of an employee’s performance or qualifications. If a manager relies on that output during an employment decision, the error could directly affect the individual. A DPIA should therefore consider how the organization will:

• Test the accuracy and reliability of AI outputs
• Identify and correct incorrect outputs
• Require human review for high-impact decisions
• Prevent users from treating AI-generated information as automatically factual
• Record and respond to significant AI errors

3. Model drift

AI risk does not necessarily remain constant after deployment. A model can become less accurate when real-world conditions change, because the data and patterns it encounters may no longer match the conditions under which it was trained. Example: a fraud detection model may perform well when first deployed but become less effective as fraud techniques change. If the organization continues relying on the original model without monitoring its performance, inaccurate results can accumulate without being immediately visible. The DPIA should address the model’s entire lifecycle, including:

• How model performance will be monitored
• What indicators trigger a review or retraining
• How changes in accuracy or behavior are documented
• When retraining or fine-tuning requires the DPIA to be reviewed
• Who is responsible for approving significant model changes

4. Algorithmic opacity

Some AI models can produce decisions or recommendations without providing an explanation that users can easily understand. This becomes particularly important when the output has a significant effect on an individual. Example: an AI system used to assess loan applications could assign a higher risk score to an applicant without providing a clear explanation of the factors that influenced the result. If the organization cannot explain or meaningfully review that outcome, it may create problems around transparency and individuals’ rights. The DPIA should therefore examine:

• What the organization can explain about the model’s decision-making process
• What information can be provided to affected individuals
• When human review or intervention is required
• How individuals can challenge or request a review of an AI-supported decision
• Whether the system creates risks under GDPR rules on automated decision-making, including Article 22

5. Adversarial attacks

AI systems can also introduce security risks that are not normally captured in a conventional DPIA. Attackers may deliberately manipulate inputs to cause the model to produce an incorrect, unsafe, or unintended result. Example: an attacker could craft a malicious input that causes an AI system to misclassify content, bypass a safety control, or generate an output that the system would normally block. The risk becomes greater when the AI is connected to business systems or used to support important decisions. An AI-specific DPIA should consider:

• Which parts of the AI system are exposed to external or untrusted inputs
• How attackers could manipulate those inputs
• What testing has been performed against adversarial behavior
• What controls detect or limit malicious inputs
• How the organization will respond when the model behaves unexpectedly

How to conduct a DPIA: 7-step process

A DPIA should be treated as a risk assessment that happens before processing begins, not as a document prepared after a system is already in use. The process should involve the people who understand the data, technology, security, legal requirements, and business purpose of the processing.

Step 1: Determine whether a DPIA is required

Start by screening the proposed processing activity before any processing begins, including testing or pilot activities. The privacy lead or DPO should assess whether the activity meets the conditions that trigger a DPIA. The screening should consider:

• The GDPR’s mandatory DPIA triggers
• Relevant national supervisory authority requirements
• The EDPB criteria for identifying high-risk processing
• The nature, scope, context, and purpose of the processing
• Whether multiple risk factors apply at the same time

The outcome should be a documented screening decision showing whether a DPIA is required. If the assessment identifies a high-risk processing activity, the DPIA must be completed before processing starts.

Step 2: Describe the processing in detail

Once a DPIA is required, the organization needs to establish exactly what processing will take place. This description should be detailed enough for someone reviewing the DPIA to understand how personal data moves through the system and why each processing activity is necessary. Document:

• What personal data is collected and processed
• Who the data subjects are
• The purpose of each processing activity
• The legal basis for processing
• Where the data is stored and transferred
• Retention periods
• Third parties and processors involved
• International data transfers
• The technical systems involved

For AI systems, the description should also cover the AI model, its intended use, relevant training or input data, and where that data came from. This creates the foundation for assessing the risks in the next steps.

Step 3: Assess necessity and proportionality

The next question is not simply whether the organization can process the data, but whether the proposed processing is necessary and proportionate to the intended purpose. The assessment should demonstrate that the organization is not collecting or using more personal data than it needs. It should also confirm that the chosen legal basis is appropriate and that the processing respects principles such as purpose limitation and data minimization. Consider:

• Is the processing necessary to achieve the stated purpose?
• Is the legal basis valid and appropriate?
• Could the same purpose be achieved with less personal data?
• Could a less privacy-invasive technology or process be used?
• Are retention periods limited to what is necessary?

For AI, this may mean comparing different approaches. For example, if an organization wants to automate document classification, it should consider whether the AI system needs access to the full document or whether selected fields would be sufficient.

Step 4: Identify and assess risks to data subjects

The organization must then identify how the processing could affect individuals and assess the severity and likelihood of those risks. The assessment should consider risks such as:

• Unauthorised access or disclosure
• Loss or alteration of personal data
• Inaccurate information or decisions
• Discrimination or unfair treatment
• Excessive collection or use of data
• Unintended or incompatible use of personal data

Each risk should be recorded and assessed based on factors such as likelihood and potential impact. This creates a risk register that can be used to determine which safeguards are needed. For AI systems, the assessment should go further by considering risks such as model bias, inaccurate or hallucinated outputs, algorithmic opacity, model drift, training data memorization, and adversarial manipulation.

Step 5: Define mitigating measures and assess residual risk

After identifying the risks, the organization must determine what safeguards will reduce them. Each significant risk should be linked to a specific technical, organizational, or procedural measure. For example:

• Access risk → role-based access controls and authentication
• Data leakage risk → encryption and data loss prevention controls
• Accuracy risk → validation and human review
• AI bias risk → bias testing and monitoring
• Model manipulation risk → adversarial testing and security controls

The assessment does not end once the controls are identified. The organization must determine the level of residual risk that remains after the safeguards are applied. If the processing still presents a high risk to individuals despite the measures that can reasonably be taken, the controller must consult the competent supervisory authority before processing begins under GDPR Article 36.

Step 6: Consult the DPO

Where an organization has appointed a Data Protection Officer, the DPO must be consulted during the DPIA process. This is a formal requirement under GDPR Article 35(2), rather than an optional review. The DPO should provide advice on the DPIA and the proposed safeguards. If the DPO disagrees with the controller’s assessment or recommendations, that disagreement should be documented as part of the DPIA record. The DPO’s role is therefore not simply to approve the final document. Their involvement should provide an independent data protection perspective while the organization is still assessing the risks and deciding whether the processing can proceed. For AI systems covered by the EU AI Act’s FRIA requirement, this stage should also connect the DPIA process with the corresponding fundamental rights assessment.

Step 7: Document, review, and update

The final DPIA should be retained as evidence of the organization’s assessment and decision-making process. It should clearly show what was assessed, which risks were identified, what measures were implemented, and what residual risk remains. A DPIA should not be treated as a one-time document that is completed and archived. It should be reviewed when the processing changes in a way that could affect the risks, and periodically where the organization continues to carry out high-risk processing. The organization should also reassess the DPIA when a significant incident or breach reveals that the original risk assessment or safeguards may no longer be adequate.

Conclusion

Data protection impact assessments have become an essential part of responsible data governance, particularly as organizations adopt AI and other technologies that introduce new privacy risks. A DPIA is not simply a compliance document. When conducted properly, it helps organizations understand how personal data is used, identify risks to individuals, and determine whether appropriate safeguards are in place before processing begins.

For AI systems, this requires organizations to go beyond traditional privacy assessments. Training data, model behavior, inaccurate outputs, bias, transparency, security vulnerabilities, and ongoing model changes can all affect the risk profile of a system. Organizations deploying high-risk AI must also consider how GDPR DPIA requirements interact with the EU AI Act’s Fundamental Rights Impact Assessment (FRIA).

Building an effective DPIA process therefore requires more than completing a template. Organizations need clear governance, cross-functional expertise, documented risk assessments, appropriate safeguards, and processes for reviewing assessments as systems evolve. By embedding privacy and risk assessment into the AI lifecycle, organizations can make better deployment decisions, reduce regulatory exposure, and build greater confidence in how personal data is handled.

Need help conducting or strengthening your DPIA process? Terralogic’s cybersecurity experts help organizations assess privacy risks, strengthen data protection governance, implement privacy-by-design practices, and align their AI initiatives with regulatory requirements such as GDPR and the EU AI Act. Contact our team to learn how we can help your organization build a practical, scalable, and compliance-ready privacy program.

Frequently Asked Questions (FAQs)

1. What is a DPIA (Data Protection Impact Assessment)?

A Data Protection Impact Assessment (DPIA) is a documented process required under GDPR Article 35 when processing is likely to create a high risk to individuals’ rights and freedoms. It assesses what personal data will be processed and why, whether the processing is necessary and proportionate, what risks it creates, and what measures will reduce those risks. A DPIA is specifically defined under the GDPR and should not be confused with the broader concept of a Privacy Impact Assessment (PIA). For certain high-risk AI systems, organizations may also need to complete a Fundamental Rights Impact Assessment (FRIA) under the EU AI Act.

2. When is a DPIA required under GDPR?

A DPIA is required when processing is likely to result in a high risk to individuals’ rights and freedoms. GDPR Article 35 identifies three situations that specifically require a DPIA: systematic and extensive profiling with significant effects, large-scale processing of special categories of personal data, and large-scale systematic monitoring of publicly accessible areas. Organizations should also consider the risk criteria identified by the European Data Protection Board (EDPB), including new technologies, automated decision-making, profiling, large-scale processing, and processing involving vulnerable individuals. If the planned processing presents multiple high-risk characteristics, a DPIA may be required. For AI projects, this assessment should take place before the relevant processing begins, including testing or pilot activities where personal data is being processed.

3. What must a DPIA contain under GDPR?

GDPR Article 35(7) requires four core elements:

1. A systematic description of the processing operations and their purposes.
2. An assessment of the necessity and proportionality of the processing.
3. An assessment of the risks to individuals’ rights and freedoms.
4. The measures planned to address those risks, including safeguards and security measures.

Where a DPO has been appointed, the controller must also seek the DPO’s advice under Article 35(2). If high residual risk remains after the available safeguards have been applied, the controller must consult the relevant supervisory authority before starting the processing under Article 36.

4. What is the difference between a DPIA and a PIA?

A Privacy Impact Assessment (PIA) is a broader term for an assessment of privacy risks associated with a project, system, or processing activity. It may be used voluntarily or required under specific laws or organizational policies. A Data Protection Impact Assessment (DPIA), by contrast, is the specific assessment required by GDPR Article 35 when processing is likely to result in a high risk to individuals. The GDPR also defines what the assessment must contain and establishes requirements for DPO involvement and prior consultation with a supervisory authority where high residual risk remains. In simple terms, a DPIA is a legally defined form of privacy impact assessment under the GDPR. A general PIA does not automatically satisfy the GDPR’s DPIA requirements.

5. Is a DPIA required for AI systems?

Not every AI system automatically requires a DPIA. The requirement depends on the nature and risk of the personal data processing involved. However, many enterprise AI deployments can involve characteristics that increase privacy risk, such as large-scale personal data processing, profiling, automated decision-making, or the use of new technologies. Organizations should therefore assess the DPIA triggers before deploying an AI system that processes personal data. For high-risk AI systems covered by the EU AI Act, a separate FRIA may also be required. The DPIA and FRIA address different risks and should be assessed together where both obligations apply.