High Risk After a DPIA: Prior Consultation Before Processing Begins

A Data Protection Impact Assessment can lead to a clear project stop: if a high risk to the rights and freedoms of natural persons remains despite the safeguards planned by the controller, the controller must consult the competent supervisory authority before processing begins. This prior consultation under Article 36 GDPR is a separate decision point, not merely another paragraph in the DPIA.

This article explains how organisations identify the need for consultation, which information belongs in the package and why silence from the authority is not a substitute for clearance. The focus is the position after the DPIA, not the general question of how to write a DPIA.

Article 36(1) GDPR links prior consultation to the result of the DPIA. The controller must consult the supervisory authority before processing where the DPIA indicates that the processing would result in a high risk that is not sufficiently mitigated by the measures the controller has taken or plans to take.

The issue is not whether any risk remains. Processing personal data is rarely risk-free. The question is whether an objective assessment still shows a high risk to the rights and freedoms of natural persons and whether the technical and organisational measures can bring that risk down to a sufficiently controlled level.

Consultation is therefore the final step of a reliable risk assessment. It does not replace the description of the processing or the selection of safeguards. Nor should an organisation treat it as retrospective confirmation of a project that has already gone live.

A DPIA should show which risks exist at the outset and which safeguards are intended to reduce them. These may include access restrictions, logging, deletion rules, encryption, human review, testing and procedures for correcting inaccurate results. A safeguard must not only be promised by a provider, it must be realistically implementable in the intended use.

The final decision should record the initial risk, the expected effect of each safeguard and the residual risk separately. General provider assurances or an untested concept will not by themselves prove that the risk has actually been reduced.

A change in purpose, data sources, recipients, groups affected or technical operation can undermine the earlier assessment. Article 35(11) GDPR requires a review at least where there is a change in the risk represented by the processing operations. A consultation decision must therefore remain tied to the version of the processing that was assessed.

Article 36(3) GDPR identifies the information the controller must provide to the supervisory authority. This includes the respective responsibilities of the controller and any processor, the purposes and means of the intended processing, the measures and safeguards intended to protect the rights and freedoms of data subjects, and the contact details of the data protection officer where one has been appointed.

The package must also include the Data Protection Impact Assessment under Article 35 GDPR. It should explain the specific processing, necessity and proportionality, risks and proposed remedial measures, rather than merely state a conclusion. Any further information requested by the supervisory authority must also be supplied.

A practical file structure can contain a short project summary, a roles and responsibilities map, data flows and recipients, the DPIA, a safeguards register and contact details for questions. The glossary entries on the Data Protection Impact Assessment and notification to the supervisory authority provide additional terminology. This makes it clear which document supports which statement.

Prior consultation is placed before the processing starts. Organisations should therefore include a binding hold point in the project plan. Procurement, IT, the business unit and the privacy function need to understand that a technical rollout is not automatically a lawful start of processing.

This remains true where a provider has already been configured, a model has been trained or a pilot has been completed. A pilot can reveal new information about errors, impacts and people affected. That information must be reflected in the DPIA and consultation package before production scope expands.

For role allocation with external providers, the page on processors and service providers provides additional context. Prior consultation remains distinct: it concerns the high-risk status of the specific processing, not merely the label used in a contract.

Under Article 36(2) GDPR, the supervisory authority provides written advice to the controller and, where applicable, the processor within up to eight weeks of receiving the consultation request if it considers that the intended processing would infringe the Regulation. For complex processing, the period may be extended by up to six weeks, and the authority must inform the controller and processor where applicable.

The period is not a general approval mechanism. Article 36(2) GDPR expressly states that a failure by the authority to respond within the period does not prevent further intervention under the Regulation. The production start therefore needs its own documented decision based on the actual response and the current risk position.

If the authority identifies insufficient risk assessment or mitigation, it may use its powers under Article 58 GDPR. Questions, additional documents and changes to safeguards should therefore be recorded in a coherent procedural file.

The project file should contain the reason for the DPIA, the version of the processing, the risk assessment, the safeguards and the decision to consult. After submission, keep the package sent, questions, responses, notices about time periods and the final production decision in the same file.

A change requires a new comparison. A different provider, a new data source or a larger group of users may trigger another assessment. The decision should always be tied to a concrete version of the processing, not only to a product name.

The existing article on DPIAs for new software and AI explains the threshold assessment that comes first. The privacy compliance and governance page provides the organisational framework, while the role check supports an initial controller and processor allocation.

We help you assess whether the DPIA still shows high risk, whether the safeguards are sufficiently documented and which information belongs in the consultation package. Send us the processing description, DPIA, safeguards register, role allocation and planned start date so that the next step can be defined reliably.