DPIA Process: How to Screen, Assess and Approve High-Risk Processing

A data protection impact assessment, or DPIA, is a structured assessment carried out before personal-data processing that is likely to create a high risk to individuals' rights and freedoms. It describes the planned processing, tests whether it is necessary and proportionate, identifies potential harm, evaluates safeguards and records whether the residual risk is acceptable.

A DPIA is not simply a legal form completed by the privacy team after a project has been designed. It is a decision process that should influence architecture, data collection, access, retention, transparency, human oversight, vendor selection and launch approval.

Article 35 of the GDPR requires a DPIA before relevant high-risk processing begins. The European Commission highlights systematic and extensive evaluation including profiling, large-scale sensitive-data processing and large-scale systematic monitoring of public areas as clear examples. Supervisory authorities also publish jurisdiction-specific lists of processing that requires, or may not require, a DPIA.

This guide sets out a practical end-to-end workflow that organisations can implement without making every project complete an excessive assessment.

Begin with a short privacy screening#

The most effective DPIA process starts with a concise screening form embedded in project, procurement, technology-change or product-governance workflow. The screen should be quick enough to complete early, when design choices can still change.

Useful screening questions include:

• Will the initiative introduce a new purpose for personal data?
• Will it use special-category, biometric, genetic, criminal-offence, precise-location or children's data?
• Will it involve systematic monitoring, tracking or surveillance?
• Will it evaluate, score, rank, profile or predict people?
• Could a decision produce legal or similarly significant effects?
• Will data be processed on a large scale?
• Will datasets be matched, combined or enriched from multiple sources?
• Will individuals find the processing unexpected or difficult to avoid?
• Will an innovative technology or AI system materially affect how data is used?
• Could the processing prevent a person from exercising a right, obtaining a service or entering a contract?
• Will a processor, new country or complex chain of subprocessors be involved?
• Has the relevant supervisory authority placed this type of processing on a mandatory DPIA list?

The screen should produce one of three outcomes: DPIA Required, DPIA Not Required, or More Information Required. A “not required” outcome still needs a rationale, reviewer and date. The system should not permit a project owner to answer high-risk indicators and approve the negative decision alone.

Define the assessment scope#

A DPIA should assess a coherent processing operation or set of similar operations. Scope that is too narrow misses cumulative risk; scope that is too broad becomes generic.

Identify the controller or joint controllers, purpose, project stage, countries, population, systems, processors, data sources and launch date, then link the assessment to the relevant RoPA records. A reusable DPIA may cover similar operations, but each deployment should confirm that its facts, scale, countries, controls and residual risk remain within the approved scope.

Describe the data lifecycle#

The assessment should make the proposed processing understandable to a reviewer who is not part of the project. A data-flow description should cover:

1. Collection, sources and the categories of people and data involved.
2. Validation, combination, inference, systems, models and users.
3. Decisions, outputs, recipients, processors and countries.
4. International transfers, retention and disposal.
5. Access, correction, restriction, export and erasure throughout the service lifecycle.

A diagram can be attached, but the record should also contain structured relationships to systems, processors, recipients, transfers and controls. Diagrams become outdated quickly when they are not connected to governed master data.

Assess necessity and proportionality#

A common weakness is moving directly from description to cyber controls. A DPIA must also challenge whether the processing should occur in the proposed form.

For each purpose, ask:

• Is the purpose specific, explicit and legitimate?
• Is the selected lawful basis appropriate to the facts?
• Is every data category genuinely needed?
• Could the outcome be achieved with less data, lower precision or aggregated information?
• Is collection direct and transparent, or will individuals be surprised?
• Is the retention period tied to a defensible trigger and requirement?
• Can access be limited to fewer roles?
• Is automated decision-making necessary, and is meaningful human intervention available where required?
• Can individuals exercise access, correction, objection, restriction and erasure in practice?
• Are less intrusive vendors, architectures or methods reasonably available?
• Does the expected benefit justify the interference and potential harm?

Record alternatives considered and why they were accepted or rejected. This prevents the DPIA from becoming a description of a predetermined solution.

Identify risks from the individual's perspective#

Privacy risk is not the same as the organisation's regulatory or reputational risk. The primary assessment should consider possible effects on people.

Potential harms include:

• Identity theft, fraud, financial loss or denial of service.
• Discrimination, exclusion, manipulation or unfair treatment.
• Exposure of sensitive facts, location or confidential relationships.
• Physical safety, employment, credit, insurance or reputational harm.
• Inaccurate decisions that are difficult to challenge.
• Re-identification or inability to access, correct or erase data.
• Disproportionate effects on children, employees or vulnerable groups.

Each risk should identify a cause, event and consequence. “Data breach” is too broad. A better statement is: “Excessive administrator access could enable unauthorised viewing of applicants' health information, causing loss of confidentiality and potential employment discrimination.”

Score risk consistently#

A simple scoring model can combine likelihood and severity, but the descriptions behind the numbers matter more than mathematical precision.

Likelihood should consider threat capability, exposure, scale, frequency, accessibility, control maturity and history. Severity should consider the nature and sensitivity of data, number and vulnerability of individuals, reversibility, duration and potential material or non-material harm.

Use a defined matrix such as Low, Moderate, High and Very High. Assess:

• Inherent risk: before the proposed safeguards.
• Control strength: how effectively existing or planned measures reduce likelihood or severity.
• Residual risk: after safeguards are implemented.
• Confidence: how reliable the evidence and assumptions are.

Do not automatically average risks into one score. One severe residual risk can determine the decision even when most risks are low.

Define controls and treatment actions#

Controls should be specific, owned and testable. Examples include:

• Data minimisation, reduced precision and separation of identity from analytics.
• Pseudonymisation, encryption, key management and role-based access.
• Human review, accuracy testing, bias analysis and challenge routes.
• Shorter retention, automated deletion and clear notices.
• Processor, subprocessor and international-transfer safeguards.
• Logging, anomaly detection, breach response and rights-handling controls.
• Training and segregation of duties.

Every treatment action should have an owner, due date, priority, implementation status and evidence requirement. Planned controls should not reduce residual risk as though they already operate. The assessment can show a target residual risk separately from the current position.

Involve the right reviewers#

The controller remains responsible for the DPIA. Where a DPO is designated, Article 35 requires the controller to seek the DPO's advice. The DPO's comments and any decision not to follow them should be recorded.

Reviewers may include the business owner, product, privacy, legal, security, architecture, data governance, model risk, procurement and third-party risk. Consider affected individuals' views where appropriate. Review must challenge assumptions, and the project sponsor should not be the sole approver of high residual risk.

Decide, approve and escalate#

A clear decision model might include:

• Approved: Controls are implemented and residual risk is acceptable.
• Approved with conditions: Launch is permitted only when specified actions are completed or monitored.
• Rework required: The design or evidence is insufficient.
• Rejected: The processing should not proceed in the proposed form.
• Prior consultation required: High residual risk remains and supervisory-authority consultation is required before processing.

Where approval is conditional, define whether the system blocks launch until actions close. High or very high residual risk should require an appropriately senior risk owner and privacy approval. The workflow should preserve the DPO view, business decision and rationale.

Under Article 36, prior consultation is required where the DPIA indicates that high risk would remain in the absence of measures sufficient to mitigate it. The organisation should obtain legal advice and follow the competent supervisory authority's process.

Treat the DPIA as a living assessment#

Article 35 requires review when necessary, at least when the risk represented by the processing changes. A DPIA should therefore have both a scheduled review date and event-driven triggers.

Trigger reassessment for material changes to purpose, data, population, model, vendor, country, architecture, automation, scale or controls, and after relevant incidents, complaints or rights issues. Post-launch indicators can include complaints, override rates, false positives, access exceptions, deletion failures, model drift, processor incidents and control findings.

Use the 2026 draft EDPB template as a reference point#

In April 2026, the European Data Protection Board published a common DPIA template for public consultation to support organisations through description, necessity and proportionality, risk identification and mitigation. The consultation closed in June 2026, and the EDPB stated that the template would then be finalised subject to appropriate modifications. Organisations can use the draft as a reference point while checking for the final version and retaining sector-specific questions, scoring and approval rules.

A software workflow should not reproduce a template mechanically. It should preserve the core assessment logic while linking answers to live master data, tasks, controls, evidence and review history.

Common DPIA failures#

Common failures include starting after design is fixed, turning every screen into a full DPIA, assessing only cybersecurity, accepting vague controls, treating planned measures as implemented and filing the assessment separately from RoPA, processor, incident and change records. Early screening, evidence-based controls, accountable actions and connected records make the process more useful.

Frequently asked questions#

What is a DPIA?#

A DPIA is a documented assessment of planned personal-data processing that is likely to create high risk. It examines the processing, necessity and proportionality, risks to individuals and safeguards.

When is a DPIA required?#

It is required before processing likely to result in high risk, including specified examples in Article 35 and processing included on applicable supervisory-authority lists. A screening process should record the decision.

Is a privacy impact assessment the same as a DPIA?#

“Privacy impact assessment” is a broader term. A GDPR DPIA has specific legal triggers and required content. An organisation can use one methodology if it clearly identifies when the GDPR requirements apply.

Who owns the DPIA?#

The controller is responsible. The business owner should own the processing facts and actions, while privacy and the DPO advise and challenge. Other specialists contribute according to the risk.

Can processing begin before the DPIA is complete?#

A required DPIA should be completed before the relevant processing begins. Conditional project work may continue without live personal data, but launch governance should prevent unauthorised processing.

How often should a DPIA be reviewed?#

Review on a defined schedule and whenever the nature, scope, context, purpose, technology, controls or risk changes. High-risk and rapidly changing processing may require more frequent review.

Related Vilfora guides#

• GDPR Compliance Management: Build an Evidence-Ready Privacy Programme
• Record of Processing Activities: A Practical RoPA Guide
• Data Subject Request Management: An End-to-End GDPR Workflow
• GDPR Personal Data Breach Response: The 72-Hour Workflow
• Data Privacy Risk Management: From Data Inventory to Breach Response

Authoritative references#

• GDPR Articles 35–36 and full legal text — EUR-Lex
• European Commission: When a DPIA is required
• European Data Protection Board: DPIA and high-risk processing guidance
• EDPB: Common DPIA template announcement, April 2026

This article provides general information and implementation guidance. It is not legal advice. Organisations should obtain advice for their circumstances and verify current EU, national and sector-specific requirements.