What is a Data Protection Impact Assessment?

A Data Protection Impact Assessment, commonly called a DPIA, is a structured process for identifying and reducing privacy risks before high-risk personal-data processing begins. Under Article 35 of the GDPR, the controller must carry out a DPIA where planned processing is likely to result in a high risk to the rights and freedoms of individuals.

A DPIA is not simply a compliance form. It should support an informed decision about whether processing is necessary and proportionate, how people may be affected, which safeguards are required and whether the remaining risk is acceptable.

When is a DPIA required?

A DPIA must be completed before processing that is likely to result in high risk. The GDPR specifically highlights:

• systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal or similarly significant effects;
• large-scale processing of special-category data or personal data relating to criminal convictions and offences; and
• systematic monitoring of a publicly accessible area on a large scale.

Supervisory authorities publish additional lists of processing that requires a DPIA. Organisations should consult the list issued by the relevant authority and record the result of their screening decision.

Indicators of likely high risk

European guidance identifies criteria that can indicate likely high risk. These include evaluation or scoring, automated decision-making with significant effects, systematic monitoring, sensitive or highly personal data, large-scale processing, matching or combining datasets, data concerning vulnerable people, innovative technology, and processing that prevents people from exercising a right or accessing a service or contract.

Meeting two criteria often suggests that a DPIA is needed, although a single criterion can be enough where the risk is significant. Conversely, an organisation that decides a DPIA is unnecessary should document the reasoning and revisit it if the processing changes.

Who is responsible for the DPIA?

The controller is accountable for ensuring that the DPIA is completed. The work will normally involve the business owner, privacy team, security, engineering, legal, procurement and other specialists who understand the processing and its impact.

Where a Data Protection Officer has been appointed, the controller must seek the DPO's advice and document it. Processors must assist the controller where required by the processing agreement. Depending on the context, it may also be appropriate to seek the views of affected individuals or their representatives.

What must a DPIA contain?

At a minimum, a GDPR-compliant DPIA should include:

• a systematic description of the planned processing and its purposes, including any legitimate interest pursued by the controller;
• an assessment of whether the processing is necessary and proportionate to those purposes;
• an assessment of risks to the rights and freedoms of individuals; and
• the measures planned to address those risks, including safeguards, security controls and mechanisms demonstrating compliance.

The assessment should be detailed enough to explain the data flows, affected people, systems, recipients, retention, access, international transfers, automated decisions and operational context.

A practical DPIA process

1. Screen the project

Start early, before final design decisions or procurement commitments. Use a consistent screening questionnaire and consider the GDPR examples, EDPB criteria and applicable supervisory-authority lists.

2. Describe the processing

Document what data is collected, where it comes from, how it is used, which systems and vendors are involved, who receives it, where it is stored, how long it is retained and what happens at the end of the lifecycle.

3. Define purpose and lawful basis

Explain the specific purposes and confirm the relevant lawful basis. For special-category or criminal-offence data, document the additional legal condition. The DPIA should align with the Record of Processing Activities and privacy notices.

4. Assess necessity and proportionality

Consider whether each data element and processing step is genuinely needed, whether a less intrusive alternative is available, whether data quality is sufficient, how long data is retained, how access is controlled and how individuals can exercise their rights.

5. Identify risks to people

Assess possible physical, material and non-material harm from the perspective of affected individuals. Examples include discrimination, loss of confidentiality, identity theft, financial loss, exclusion, surveillance, reputational damage, inability to exercise rights or loss of control over personal data.

6. Evaluate likelihood and severity

Use a consistent methodology to assess inherent risk before safeguards and residual risk after safeguards. Scores should be supported by reasoning rather than treated as an automatic substitute for professional judgement.

7. Select and assign measures

Measures may include data minimisation, pseudonymisation, encryption, access controls, retention limits, human review, testing, transparency improvements, contractual safeguards, monitoring, incident response and restrictions on secondary use. Assign an owner and completion date to each measure.

8. Approve and record the decision

Document DPO advice, stakeholder input, approvals, accepted residual risk and any conditions for launch. Where the processing would still result in high risk despite planned measures, the controller must consult the competent supervisory authority before proceeding.

9. Review throughout the lifecycle

A DPIA is a living process. Review it when purposes, data, technology, vendors, scale, affected people or risk change, and periodically where the processing remains high risk.

When is prior consultation required?

If the DPIA indicates that the processing would result in high risk in the absence of measures and the controller cannot reduce that risk sufficiently, the controller must consult the supervisory authority before starting the processing. The consultation package should include the DPIA, responsibilities, purposes, safeguards and the DPO's contact details and advice where applicable.

DPIA, PIA, TIA and AI impact assessments

A Privacy Impact Assessment is a broader term and may be used outside the GDPR. A DPIA is the specific assessment required by Article 35. A Transfer Impact Assessment focuses on international data transfers and the protection available in the destination country. AI risk or fundamental-rights assessments may be required under the EU AI Act or organisational policy.

These assessments may overlap, but one does not automatically replace another. A connected process can reuse common information while preserving the legal purpose, decision criteria and evidence required for each assessment.

Common DPIA mistakes

• starting the DPIA after the project has already launched;
• describing technology without explaining the real business process and people affected;
• focusing only on cybersecurity and ignoring fairness, autonomy, discrimination and other rights;
• using generic risks and controls that are not connected to the actual processing;
• failing to assess necessity and less intrusive alternatives;
• omitting DPO advice, stakeholder input or approval records;
• accepting high residual risk without considering prior consultation; and
• treating the DPIA as finished when the system, vendor or purpose changes.

A practical DPIA checklist

• Complete and document a high-risk screening decision.
• Identify the controller, processors, owners and relevant stakeholders.
• Describe purposes, lawful bases, data flows, systems, vendors, retention and transfers.
• Assess necessity, proportionality and alternatives.
• Identify impacts on rights and freedoms from the individual's perspective.
• Score inherent and residual risk using a consistent methodology.
• Define safeguards, owners, deadlines and evidence requirements.
• Seek and record DPO advice where applicable.
• Escalate for prior consultation where high residual risk remains.
• Approve the decision and set review triggers.

How TrustWorks supports DPIA workflows

TrustWorks helps privacy teams run consistent, collaborative DPIAs without relying on disconnected spreadsheets, email chains and static documents.

• Structured assessments: use reusable templates, screening logic and intelligent questionnaires.
• Processing context: connect systems, vendors, data categories and flows to the assessment.
• Risk and measures: score risks, assign safeguards, track owners and monitor remediation.
• Collaboration: collect input from business, legal, security, engineering, procurement and the DPO.
• Evidence and approvals: preserve advice, decisions, versions and an audit-ready history.
• Continuous review: trigger reassessments when processing or risk changes.

TrustWorks supports DPIA and privacy-assessment workflows. It does not provide legal advice, and controllers should assess their obligations with qualified counsel and guidance from the relevant supervisory authority.

‍