GDPR Data Protection Impact Assessment: Complete Step-by-Step Guide — AuditFront Blog

What is a Data Protection Impact Assessment?

A Data Protection Impact Assessment (DPIA) is a structured process for identifying and minimizing the data protection risks of a project, system, or processing activity. Under GDPR Article 35, a DPIA is legally required before you begin any type of processing that is “likely to result in a high risk to the rights and freedoms of natural persons.”

In practical terms, a DPIA forces you to think systematically about how you handle personal data, what could go wrong, and what safeguards you need in place. It is not a checkbox exercise — when done properly, a DPIA is one of the most useful privacy tools available. It surfaces risks early, when they are cheapest to address, and creates a documented record of your decision-making that regulators expect to see.

The concept is not new. Privacy impact assessments have existed in various forms for decades. What GDPR did is make them a legal obligation in specific circumstances, with enforcement powers behind them.

When is a DPIA legally required?

Article 35(1) of GDPR states that a DPIA is required when processing is “likely to result in a high risk” to individuals’ rights and freedoms, “taking into account the nature, scope, context and purposes of the processing.”

Mandatory triggers (Article 35(3))

A DPIA is always required in these three scenarios:

Systematic and extensive automated decision-making that produces legal effects or similarly significant effects on individuals. This includes profiling used for credit decisions, automated hiring screening, insurance risk assessment, or algorithmic content moderation that affects access to services.
Large-scale processing of special category data (Article 9) or criminal conviction data (Article 10). Special categories include racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, and data concerning sex life or sexual orientation.
Systematic monitoring of a publicly accessible area on a large scale. This covers CCTV surveillance, Wi-Fi tracking in public spaces, and similar large-scale monitoring activities.

Additional criteria from regulatory guidance

The Article 29 Working Party (now the European Data Protection Board) published guidance identifying nine criteria that indicate high-risk processing. If your activity meets two or more of these criteria, you should conduct a DPIA:

Evaluation or scoring — including profiling and predicting, especially based on performance, economic situation, health, personal preferences, interests, reliability, behavior, location, or movements
Automated decision-making with legal or similar significant effect
Systematic monitoring — observation, monitoring, or control of data subjects
Sensitive data or data of a highly personal nature — special categories, financial data, location data, private communications
Data processed on a large scale — consider the number of data subjects, volume of data, duration, and geographical extent
Matching or combining datasets — from different sources in ways that exceed the data subject’s reasonable expectations
Data concerning vulnerable data subjects — children, employees, patients, elderly people, asylum seekers
Innovative use of technology — fingerprint recognition, facial recognition, IoT devices, AI/ML systems
Processing that prevents data subjects from exercising a right or using a service or contract — such as screening customers against a fraud database before offering a loan

National supervisory authority lists

Each EU member state’s supervisory authority publishes its own list of processing activities that require a DPIA. These lists vary by country. If you operate across multiple member states, check each relevant authority’s list. Common examples include large-scale employee monitoring, systematic credit scoring, health data processing, and biometric identification systems.

When is a DPIA not required?

A DPIA is not required when processing is unlikely to result in a high risk — for example, standard payroll processing for a small company, basic customer relationship management, or processing that is essentially identical to an activity for which a DPIA has already been conducted (and the results still apply).

However, when in doubt, conducting a DPIA is always the safer choice. There is no penalty for performing a DPIA when one wasn’t technically required, but there are significant penalties for failing to conduct one when it was.

The 9-step DPIA process

Step 1: Identify the need for a DPIA

Before starting a DPIA, confirm that one is necessary. Review the triggers above against your planned processing activity. If you are uncertain, document your reasoning for deciding whether a DPIA is needed — this screening record itself is valuable evidence for regulators.

Create a brief description of the processing: what data is involved, why it’s being processed, and who is affected. This becomes the foundation for the rest of the assessment.

Step 2: Describe the processing

Document the processing activity in detail:

What personal data will be collected? List specific data categories (names, email addresses, location data, health records, behavioral data, etc.)
From whom? Identify the data subjects (customers, employees, website visitors, patients, etc.)
How will data be collected? Directly from data subjects, from third parties, through automated observation, etc.
What is the purpose of the processing? Be specific — “improving the product” is too vague; “personalizing content recommendations based on browsing history” is concrete.
What is the lawful basis under Article 6? (consent, contract, legitimate interest, legal obligation, vital interests, or public task)
How will data flow? Map the data lifecycle: collection, storage, processing, sharing, retention, and deletion. Include all systems, databases, and third parties that touch the data.
How long will data be retained? Define retention periods for each data category.
Who has access? List internal teams and external processors with access to the data.

This description should be thorough enough that someone unfamiliar with the project can understand exactly what happens to personal data at every stage.

Step 3: Assess necessity and proportionality

Evaluate whether the processing is necessary and proportionate to its stated purpose:

Is all the data you’re collecting actually needed? Could you achieve the same purpose with less data or anonymized data?
Is the processing proportionate to the goal? A facial recognition system to prevent shoplifting in a corner store is disproportionate; using it at a high-security government facility may be proportionate.
Have you considered less invasive alternatives? Document what alternatives you considered and why you chose the current approach.
How will you inform data subjects? What transparency measures are in place?
How will you support data subject rights? Can individuals access, correct, delete, and port their data?

Article 35(7)(b) specifically requires the DPIA to include an assessment of the necessity and proportionality of processing in relation to the purposes.

Step 4: Identify risks to individuals

This is the core of the DPIA. Identify risks to the rights and freedoms of data subjects — not risks to your organization. Think about what could go wrong from the individual’s perspective:

Confidentiality risks:

Unauthorized access to personal data (data breach)
Data shared with unintended recipients
Staff accessing data beyond their role

Integrity risks:

Data is inaccurate or corrupted, leading to wrong decisions about individuals
Unauthorized modification of records

Availability risks:

Data loss preventing service delivery (e.g., medical records unavailable during treatment)
System downtime affecting individuals’ access to their data

Rights and freedoms risks:

Discrimination based on profiling
Financial loss from identity theft
Reputational damage from data exposure
Loss of autonomy through pervasive monitoring
Chilling effect on free expression
Exclusion from services based on automated decisions
Physical safety risks (e.g., exposure of domestic abuse victim’s address)

For each risk, assess the likelihood (remote, possible, probable) and severity (minimal, significant, severe) of harm.

Step 5: Identify measures to mitigate risks

For each identified risk, determine what measures will reduce either the likelihood or severity of harm:

Technical measures:

Encryption at rest and in transit
Pseudonymization or anonymization
Access controls and role-based permissions
Automated data deletion at end of retention period
Logging and monitoring of data access
Data minimization in collection and storage

Organizational measures:

Staff training on data handling procedures
Clear data processing agreements with third-party processors
Incident response procedures
Regular access reviews
Data protection policies and procedures

Contractual measures:

Data processing agreements with suppliers
Confidentiality clauses
Audit rights over processors

For each measure, document how it reduces the identified risk and assess whether the residual risk (after mitigation) is acceptable.

Step 6: Consult with stakeholders

Article 35(9) requires you to seek the views of data subjects or their representatives “where appropriate.” In practice, this might mean:

Surveying or consulting with the individuals who will be affected
Consulting with employee representatives or works councils (especially for employee monitoring)
Seeking input from user advocacy groups
Running focus groups or public consultations for high-impact processing

Even when formal consultation isn’t practical, involve relevant stakeholders in the DPIA process:

Data Protection Officer (DPO): Article 35(2) specifically requires that the controller seek the DPO’s advice when conducting a DPIA
IT / Security team: for technical risk assessment and mitigation
Legal team: for lawful basis assessment and regulatory requirements
Business owners: for understanding the purpose and necessity of processing
Third-party processors: for understanding their security measures and data handling practices

Step 7: Document the assessment

Compile all findings into a structured DPIA document. At minimum, Article 35(7) requires:

A systematic description of the processing operations and purposes
Assessment of necessity and proportionality
Assessment of risks to the rights and freedoms of data subjects
Measures envisaged to address risks, including safeguards, security measures, and mechanisms to ensure protection of personal data

AuditFront’s GDPR assessment templates include a structured DPIA format that covers all required elements.

Step 8: Decide whether to proceed

Based on the DPIA findings, decide on next steps:

Proceed as planned — if residual risks are acceptable after mitigation measures
Proceed with modifications — if the DPIA identified changes needed to reduce risk to an acceptable level
Consult the supervisory authority — Article 36 requires you to consult your supervisory authority (prior consultation) if the DPIA indicates that processing would result in a high risk that you cannot sufficiently mitigate
Do not proceed — if risks cannot be adequately mitigated and the processing is not legally mandated

Document this decision, including the reasoning, and obtain sign-off from an appropriate decision-maker.

Step 9: Monitor and review

A DPIA is not a one-time document. Article 35(11) requires the controller to review the DPIA “at least when there is a change in the risk represented by processing operations.” In practice, review your DPIA when:

The processing activity changes (new data categories, new purposes, new recipients)
New risks emerge (security incidents, regulatory changes, technology changes)
The organizational or technical environment changes (new systems, new processors)
At regular intervals, even if nothing has changed (annual review is good practice)

Who should be involved?

A DPIA is a collaborative effort. The following roles should participate:

Role	Responsibility
Project / Product owner	Describes the processing, defines purpose, assesses necessity
Data Protection Officer	Provides advice on methodology, risks, and compliance (mandatory per Article 35(2))
IT / Security	Assesses technical risks, proposes technical mitigations
Legal	Evaluates lawful basis, regulatory requirements, contractual measures
Business stakeholders	Provide context on business need and proportionality
Data subjects (where appropriate)	Provide input on impact and concerns

The controller (your organization) is responsible for conducting the DPIA. It can be delegated to internal teams or external consultants, but the controller remains accountable for the outcome.

Common DPIA mistakes

Treating it as a formality. A DPIA that is completed after the system is built and launched misses the point entirely. The value of a DPIA comes from conducting it early, when design changes are still feasible.
Focusing on organizational risk instead of individual risk. A DPIA assesses risks to data subjects, not to your company. “Reputational damage to the company” is not a DPIA risk — “financial loss to individuals from data breach” is.
Being too vague. “We will implement appropriate security measures” is not a mitigation. Specify what measures, how they address specific risks, and who is responsible.
Skipping the necessity and proportionality assessment. This step often reveals that you are collecting more data than needed, which is the cheapest and most effective risk reduction available.
Not consulting the DPO. This is an explicit legal requirement under Article 35(2). If you have a DPO, they must be involved.
Filing and forgetting. A DPIA that sits in a drawer provides no protection. Review it regularly and update it when circumstances change.
Ignoring the prior consultation requirement. If your DPIA concludes that residual risk remains high despite mitigation measures, you are legally required to consult your supervisory authority before proceeding. Skipping this step is a compliance violation in itself.

Examples of when a DPIA is needed

To make the criteria concrete, here are common scenarios where a DPIA is required:

Deploying an AI system that scores job applicants based on video interviews (automated decision-making + evaluation/scoring + innovative technology)
Implementing employee monitoring software that tracks keystrokes, screen activity, or location (systematic monitoring + vulnerable data subjects)
Launching a health app that collects heart rate, sleep, and exercise data on a large scale (sensitive data + large scale + innovative technology)
Building a customer loyalty program that combines purchase history with location tracking and demographic data (combining datasets + profiling + large scale)
Rolling out CCTV with facial recognition in retail stores (systematic monitoring + biometric data + innovative technology)
Creating a marketing platform that profiles user behavior across websites to serve targeted ads (profiling + large scale + systematic monitoring)
Processing children’s data for an educational technology platform (vulnerable data subjects + potentially large scale)

Integrating DPIAs with broader compliance

DPIAs do not exist in isolation. They connect to your broader compliance and security management:

ISO 27001: Your risk assessment process under ISO 27001 can be aligned with DPIA methodology. The controls identified through a DPIA map directly to ISO 27001 Annex A controls.
Records of Processing Activities (ROPA): Your ROPA should reference DPIAs conducted for each processing activity.
Data breach response: Risks identified in your DPIA should feed into your incident response planning.
Vendor management: DPIA findings about third-party processor risks should inform your vendor assessment process.

For a broader view of GDPR requirements, see our GDPR compliance checklist.

Get started with your DPIA

A well-conducted DPIA protects individuals, reduces your regulatory risk, and improves the design of your systems. The key is starting early, being thorough, and treating it as a living document rather than a compliance artifact.

AuditFront’s GDPR self-assessment templates include structured DPIA guidance that walks you through every required element. Combine it with our broader compliance templates to connect your DPIA findings to your overall security and privacy program.

Start your free GDPR assessment and build your DPIA on a solid foundation.