GDPR DPIAs: When and How to Conduct Them

A Data Protection Impact Assessment (DPIA) is a structured process for evaluating the potential impact of a data processing activity on the rights and freedoms of natural persons. Introduced by Article 35 of the General Data Protection Regulation (GDPR), the DPIA is one of the regulation’s most important accountability mechanisms — it forces organisations to identify and address privacy risks before they materialise, rather than responding to them after the fact.

For technology companies, DPIAs are not a bureaucratic formality. They are a practical tool for embedding privacy into product development, demonstrating compliance to supervisory authorities, and building trust with users. Organisations that treat DPIAs as a genuine risk management exercise — rather than a tick-box obligation — consistently make better decisions about data processing and avoid costly regulatory interventions.

What is a DPIA under the GDPR?

Article 35(1) of the GDPR states that where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. The assessment must be carried out prior to the processing.

A DPIA is not a one-off compliance document. It is an ongoing process that begins during the design phase of a processing activity and continues throughout its lifecycle. The assessment must be revisited whenever the nature, scope, context, or purposes of the processing change in a way that could alter the risk profile.

The concept is rooted in the principle of accountability (Article 5(2)) and the obligation to implement data protection by design and by default (Article 25). A DPIA is the mechanism through which controllers demonstrate that they have systematically considered the privacy implications of their processing and taken steps to mitigate identified risks.

When is a DPIA mandatory?

Article 35 sets out both general criteria and specific examples of processing that requires a DPIA. The European Data Protection Board (EDPB) has supplemented these with additional guidance, and national supervisory authorities have published their own lists of processing activities that mandate a DPIA.

General threshold

A DPIA is required whenever processing is likely to result in a high risk to the rights and freedoms of natural persons. The EDPB’s guidelines identify nine criteria that indicate high risk. As a rule of thumb, if a processing activity meets two or more of these criteria, a DPIA is likely to be required:

• Evaluation or scoring. Profiling and predicting behaviour, including performance at work, economic situation, health, personal preferences, reliability, behaviour, location, or movements.
• Automated decision-making with legal or similarly significant effect. Processing that produces decisions about individuals that have legal consequences or comparably significant impacts.
• Systematic monitoring. Observing, monitoring, or controlling data subjects in a systematic manner, including through networks or CCTV in publicly accessible areas.
• Sensitive data or data of a highly personal nature. Processing special categories of data (Article 9), criminal conviction data (Article 10), or data that is inherently private (financial records, location data, communications metadata).
• Data processed on a large scale. The GDPR does not define “large scale” precisely, but relevant factors include the number of data subjects, the volume of data, the duration of processing, and the geographical extent.
• Matching or combining datasets. Merging data from multiple sources in ways that exceed the reasonable expectations of data subjects.
• Data concerning vulnerable data subjects. Processing data about children, employees, patients, asylum seekers, or other individuals who may be unable to freely consent or object.
• Innovative use of technology. Deploying novel technological or organisational solutions — fingerprint recognition, facial recognition, IoT devices, machine learning — where the privacy impact is not yet fully understood.
• Processing that prevents data subjects from exercising a right or using a service or contract. Any processing that acts as a gatekeeper to services or opportunities.

Specific examples in Article 35(3)

Article 35(3) provides three concrete examples of processing that always requires a DPIA:

• Systematic and extensive profiling with significant effects. A systematic and extensive evaluation of personal aspects relating to natural persons, based on automated processing including profiling, on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person.
• Large-scale processing of special categories of data. Processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10.
• Systematic monitoring of publicly accessible areas on a large scale. Large-scale, systematic monitoring of a publicly accessible area — such as CCTV surveillance of a city centre or public transport network.

National supervisory authority blacklists

Article 35(4) requires each supervisory authority to publish a list of processing operations that require a DPIA. These “blacklists” vary by jurisdiction but commonly include employee monitoring systems, large-scale health data processing, credit scoring, loyalty and behavioural tracking programmes, biometric identification systems, and processing involving children’s data. Controllers must consult the blacklist published by the supervisory authority in each jurisdiction where they operate.

When is a DPIA not required?

Not every processing activity requires a DPIA. The obligation is triggered only where processing is likely to result in a high risk. Situations where a DPIA is generally not required include:

• Low-risk processing. Routine operations such as payroll processing, standard customer relationship management, or supplier contact databases are unlikely to meet the high-risk threshold, provided they do not involve special category data or large-scale profiling.
• Processing already assessed. If a DPIA has already been carried out for a similar processing operation and the risk profile has not changed, a new DPIA is not necessary. However, the controller must document why the existing assessment remains valid.
• Supervisory authority whitelists. Article 35(5) permits supervisory authorities to publish lists of processing operations that do not require a DPIA. Where a processing activity appears on the relevant whitelist, no DPIA is needed.
• Processing with a legal basis in EU or Member State law. Article 35(10) provides that a DPIA is not required where the processing has a legal basis in EU or Member State law, and that law regulates the specific processing operation and a DPIA was already carried out as part of the legislative process.

Even where a DPIA is not strictly mandatory, conducting one voluntarily is good practice for any processing that involves personal data at scale. The process itself surfaces risks and design improvements that might otherwise go unnoticed.

The DPIA process: a step-by-step approach

The GDPR does not prescribe a single methodology for conducting a DPIA, but Article 35(7) sets out the minimum content requirements. The following process satisfies those requirements and aligns with the guidance published by the EDPB, the ICO, and the CNIL.

Step 1: Describe the processing

Begin with a clear, factual description of the envisaged processing. This should cover:

• The nature of the processing. What operations will be performed on the data? Collection, storage, structuring, retrieval, consultation, use, disclosure, combination, erasure — be specific.
• The scope. What categories of personal data are involved? How many data subjects are affected? What is the geographical scope?
• The context. What is the relationship between the controller and the data subjects? What are the data subjects’ reasonable expectations? Is there any relevant industry context or prior regulatory guidance?
• The purposes. Why is the processing being carried out? What outcomes does the controller seek to achieve?
• The data flows. Map the journey of personal data from collection to deletion. Identify all recipients, processors, sub-processors, and any international transfers.
• The technology. Describe the systems, algorithms, and infrastructure involved. For automated decision-making or machine learning, explain the logic, training data, and outputs.

Step 2: Assess necessity and proportionality

Article 35(7)(b) requires the DPIA to assess the necessity and proportionality of the processing in relation to its purposes. This step asks whether the processing is genuinely needed and whether the same objectives could be achieved with less intrusive means.

Key questions to address:

• What is the lawful basis for the processing under Article 6 (and Article 9 if special categories are involved)?
• Is the processing necessary to achieve the stated purpose, or could the purpose be achieved with less data, fewer data subjects, or less invasive techniques?
• Are data minimisation and storage limitation principles being respected?
• How will data subjects be informed about the processing?
• How will data subject rights (access, rectification, erasure, portability, objection) be facilitated?
• If the processing involves international transfers, what transfer mechanism is being used and is it adequate?

Step 3: Identify and assess risks

This is the core of the DPIA. For each aspect of the processing, identify the risks to the rights and freedoms of data subjects. Risks should be assessed in terms of both likelihood and severity.

The rights and freedoms at stake extend beyond data protection to include privacy, freedom of expression, freedom from discrimination, and economic rights. Consider both tangible harms (financial loss, identity theft) and intangible harms (distress, reputational damage, loss of autonomy, chilling effects on behaviour).

Common risk categories include:

• Unauthorised access or disclosure. Could the data be accessed by individuals who should not have it?
• Inaccuracy. Could errors in the data lead to incorrect decisions about individuals?
• Excessive data collection. Is more data being collected than is necessary?
• Lack of transparency. Will data subjects understand what is happening with their data?
• Function creep. Could the data be used for purposes beyond those originally intended?
• Algorithmic bias. Could automated processing produce discriminatory outcomes?
• Re-identification. Could pseudonymised or aggregated data be linked back to individuals?
• Cross-border transfer risks. Are data subjects’ rights adequately protected when data moves to other jurisdictions?

Step 4: Identify mitigating measures

For each identified risk, document the measures that will be taken to reduce the likelihood or severity of harm. Mitigating measures may be technical, organisational, or legal:

• Technical measures. Encryption, pseudonymisation, access controls, automated data retention and deletion, audit logging, anomaly detection, differential privacy techniques, secure development practices.
• Organisational measures. Staff training, data protection policies, incident response procedures, contractual obligations on processors, regular audits, role-based access restrictions.
• Legal measures. Obtaining explicit consent where appropriate, implementing appropriate transfer mechanisms (Standard Contractual Clauses, adequacy decisions), ensuring data processing agreements are in place with all processors.

After applying mitigating measures, assess the residual risk — the risk that remains. If the residual risk is acceptable, the processing may proceed. If it remains high, further measures must be considered or the supervisory authority must be consulted under Article 36.

Step 5: Document the assessment

The DPIA must be documented in sufficient detail to demonstrate compliance. The documentation should include all elements described above, together with:

• The date of the assessment and the names of the individuals involved.
• The advice of the Data Protection Officer (if one has been appointed).
• The views of data subjects or their representatives, where sought.
• The decisions taken and the rationale for those decisions.
• A clear statement of the residual risk and whether it is accepted, mitigated, or requires supervisory authority consultation.

Step 6: Consult the DPO

Article 35(2) requires the controller to seek the advice of the DPO when carrying out a DPIA. The DPO should be involved from the outset, not presented with a finished document for rubber-stamping. The DPO’s role is to provide independent advice on whether the assessment is thorough, whether the identified risks are complete, and whether the proposed mitigating measures are adequate. The DPO’s advice and the controller’s response to it should be recorded in the DPIA documentation.

Step 7: Consult the supervisory authority (if necessary)

Where the DPIA indicates that the processing would result in a high residual risk — that is, a high risk that the controller cannot sufficiently mitigate — Article 36 requires the controller to consult the supervisory authority before commencing the processing. The consultation must include the DPIA documentation, information about the respective responsibilities of the controller and any processors, and any other information the supervisory authority requests.

The supervisory authority has eight weeks to respond (extendable by six weeks for complex cases). It may provide written advice, impose conditions on the processing, or prohibit it. Proceeding with high-risk processing without consultation is a serious compliance failure.

Integrating DPIAs with product development

Article 25 of the GDPR requires controllers to implement data protection by design and by default. The DPIA is the primary mechanism for translating this obligation into practice within product and engineering teams.

Embedding DPIAs in the development lifecycle

Rather than treating the DPIA as a separate compliance exercise conducted after a product has been designed, organisations should integrate the assessment into their standard development workflow:

• Requirements phase. Conduct a preliminary screening to determine whether a DPIA is required. If it is, initiate the DPIA alongside the product requirements document.
• Design phase. Use the DPIA to evaluate architectural choices, data models, and third-party integrations. The assessment should inform decisions about what data to collect, how to store it, and what access controls to implement.
• Implementation phase. Verify that the technical and organisational measures identified in the DPIA have been implemented as specified.
• Testing phase. Include privacy-specific test cases derived from the DPIA’s risk assessment — for example, testing that data minimisation controls function correctly, that retention policies are enforced, and that consent withdrawal mechanisms work as intended.
• Launch and post-launch. Review the DPIA before launch to confirm that the processing matches the assessed design. Schedule periodic reviews to capture changes introduced after launch.

Engineering teams should contribute directly to the DPIA process by documenting data flows, identifying technical risks, and proposing privacy-enhancing technologies. The most effective DPIAs are collaborative documents produced by privacy, legal, security, and engineering working together — not compliance artefacts produced in isolation by the legal team.

Common DPIA triggers for technology companies

Certain processing activities are particularly common in the technology sector and frequently trigger the DPIA obligation.

Artificial intelligence and machine learning

Any system that uses personal data to train, validate, or operate a machine learning model is likely to require a DPIA. The risks include algorithmic bias, lack of explainability, automated decision-making with significant effects, and the potential for models to memorise and reproduce personal data from training sets. The assessment should address the lawful basis for using personal data in training, the measures taken to ensure fairness and transparency, and the mechanisms available for data subjects to challenge automated decisions.

Behavioural analytics and profiling

Products that track user behaviour — clickstreams, session recordings, usage patterns, engagement metrics — and use that data to build profiles, segment users, or personalise experiences will often meet the EDPB’s criteria for evaluation or scoring and systematic monitoring. The DPIA should assess whether the profiling is proportionate, whether users are adequately informed, and whether opt-out mechanisms are effective.

Biometric processing

The use of biometric data for identification or authentication — facial recognition, fingerprint scanning, voice recognition — involves special category data under Article 9 and almost always requires a DPIA. The risks are amplified by the fact that biometric data cannot be changed if compromised. The assessment must address the necessity of biometric processing, the availability of less intrusive alternatives, and the technical measures in place to protect biometric templates.

Employee monitoring

Systems that monitor employee activity — email scanning, keystroke logging, screen capture, location tracking, productivity scoring — involve data about vulnerable data subjects (employees cannot freely refuse monitoring by their employer) and systematic monitoring. A DPIA is required in most cases and should address the lawful basis for monitoring, the proportionality of the measures, and the impact on employees’ reasonable expectation of privacy.

International data transfers

Processing activities that involve the transfer of personal data outside the European Economic Area require careful assessment, particularly following the Schrems II judgment. Where transfers rely on Standard Contractual Clauses or binding corporate rules, the DPIA should incorporate a transfer impact assessment evaluating the laws and practices of the recipient country, the supplementary measures in place, and the residual risks to data subjects.

Maintaining and reviewing DPIAs over time

A DPIA is not a static document. Article 35(11) requires controllers to carry out a review when there is a change in the risk represented by the processing operations. In practice, this means DPIAs should be treated as living documents that evolve alongside the processing activities they assess.

Triggers for review

A DPIA review should be initiated whenever any of the following occurs:

• A change in the nature, scope, context, or purpose of the processing. For example, expanding a service to new markets, adding new data sources, or introducing new features that process additional categories of data.
• A change in the technology. Migrating to a new cloud provider, adopting a new analytics platform, or upgrading an algorithm may alter the risk profile.
• A data breach or security incident. Any incident involving the processing activity should prompt a reassessment of the risks and the adequacy of existing safeguards.
• New regulatory guidance or case law. Supervisory authority decisions, court rulings, or updated EDPB guidelines may change the assessment of necessity, proportionality, or risk.
• Complaints or data subject requests. Patterns in complaints or access requests may indicate risks that were not identified in the original assessment.
• Scheduled periodic review. Even in the absence of specific triggers, organisations should review DPIAs at regular intervals — annually is a common and reasonable cadence.

Version control and audit trails

Each revision of a DPIA should be clearly versioned, dated, and attributed. Maintaining a full revision history demonstrates accountability and provides evidence that the organisation takes its DPIA obligations seriously. The revision history should record what changed, why, and what decisions were taken as a result.

Governance and ownership

Assign clear ownership of each DPIA to a named individual or team. The owner is responsible for monitoring the processing activity for changes, initiating reviews when triggers arise, and ensuring that the DPIA documentation remains current. The DPO should maintain a register of all DPIAs and their review status, and should report to senior management on the overall state of DPIA compliance.

Organisations that embed DPIA maintenance into their standard operating procedures — rather than treating assessments as one-off project deliverables — are better positioned to identify emerging risks and demonstrate ongoing compliance with the GDPR’s accountability obligations.