Article 36 — Prior consultation

Article 36 GDPR: Prior Consultation

1. The place of Article 36 within the GDPR's risk-based architecture

Article 36 is best understood not as an isolated procedural obligation, but as the final escalation stage of the GDPR's preventive risk-management framework.

The GDPR does not generally require a controller to obtain permission from a supervisory authority before processing personal data. This is an important departure from the regulatory model that existed under Directive 95/46/EC. Under the earlier regime, general notification requirements could require organisations to notify supervisory authorities of processing operations in advance. The GDPR deliberately moved away from that model.

Instead, the GDPR adopts a risk-based and accountability-based approach.

The basic architecture can be understood as follows:

Processing contemplated → risk assessment → DPIA where required → mitigation measures → assessment of residual risk → prior consultation if high residual risk remains.

Article 36 therefore sits immediately after Article 35.

Article 35 asks:

Has the processing been assessed through a DPIA, and what risks does it create?

Article 36 asks the next question:

Having conducted that DPIA and attempted to mitigate the risks, is the remaining risk sufficiently serious that the supervisory authority must become involved before processing begins?

This makes Article 36 an institutional safety valve.

The GDPR normally places responsibility on the controller. The controller determines the purposes and means, chooses the legal basis, designs the processing, implements safeguards and demonstrates compliance. But the GDPR recognises that there may be circumstances in which the controller's own assessment is not sufficient.

Where processing presents a high level of residual risk that the controller cannot adequately reduce, Article 36 brings an independent public authority into the decision-making process.

This is particularly important where processing may have serious consequences for individuals, where novel technologies are involved, where large-scale processing is contemplated, or where the consequences of misuse, error, discrimination, exposure or loss of control over personal data could be substantial.

Article 36 therefore reflects three fundamental GDPR principles:

1. Accountability: the controller must first assess and attempt to manage the risk itself.

2. Prevention: intervention should occur before harmful processing begins.

3. Independent oversight: where high residual risk cannot be adequately addressed, the supervisory authority should have an opportunity to intervene.

This is why Article 36 is closely connected to Articles 5(2), 24, 25, 32 and 35.

2. Article 36(1): When does prior consultation arise?

The first paragraph contains the central trigger for Article 36.

The obligation does not arise merely because processing is potentially risky.

It does not arise merely because a DPIA has been conducted.

It does not arise merely because the processing involves sensitive personal data.

It does not arise merely because innovative technology is being used.

The critical question is whether, following the DPIA and consideration of mitigation measures, the processing presents a sufficiently serious residual high risk.

This requires careful analysis.

2.1 The controller is the person responsible

The primary legal obligation rests on the controller.

This follows naturally from the structure of Article 35 as well. The controller is the party responsible for determining why and how personal data are processed and is therefore the party ultimately responsible for determining whether the processing can lawfully proceed.

The processor does not independently assume the Article 36 obligation simply because it is technically involved in the processing.

Example

suppose a bank appoints a cloud provider to host customer data.

The bank is the controller.

The cloud provider is the processor.

If the bank's DPIA concludes that the intended processing presents an unmitigated high risk, it is the bank that must undertake the prior consultation.

The processor may have an important supporting role. It may need to provide information concerning:

• security architecture;

• encryption;

• access controls;

• retention mechanisms;

• incident-response systems;

• subprocessors;

• data locations;

• technical safeguards;

• deletion mechanisms; and

• other technical and organisational measures.

But those contributions do not transfer the statutory responsibility for consultation away from the controller.

This distinction is important because Article 28 also requires processors to assist controllers with compliance obligations. Article 36 must therefore be viewed together with the controller-processor relationship under Article 28.

3. The DPO does not become the decision-maker

The same distinction applies to the Data Protection Officer.

A DPO may be heavily involved in the Article 36 process, but the DPO is not normally the person who bears the controller's statutory responsibility for making the consultation.

Article 39 is particularly important here.

The DPO's responsibilities include advising the controller concerning DPIAs and monitoring compliance. The DPO may also act as a contact point for the supervisory authority.

Therefore, in practice, the DPO may:

• advise that consultation is required;

• review the DPIA;

• challenge the controller's risk assessment;

• communicate with the supervisory authority;

• coordinate information requested by the authority;

• explain the mitigation measures;

• facilitate meetings;

• monitor implementation of the authority's advice; and

• advise senior management about the consequences of proceeding.

But the DPO does not become the controller.

This is an important accountability distinction.

A controller cannot later defend itself by saying:

“Our DPO handled the DPIA and consultation.”

The GDPR's allocation of responsibility does not work that way.

The organisation remains accountable.

4. Joint controllers create an additional layer of complexity

Article 36 becomes more complicated where multiple entities jointly determine the purposes and means of processing.

Under Article 26, joint controllers must transparently determine their respective responsibilities.

Where a DPIA reveals high residual risk, the joint controllers should therefore have already addressed questions such as:

• Who conducted the DPIA?

• Who assessed the residual risk?

• Who decides whether consultation is necessary?

• Who communicates with the supervisory authority?

• Who supplies technical documentation?

• Who bears responsibility for implementing safeguards?

• Who responds to regulatory requests?

• Who implements changes required following consultation?

The existence of a joint-controller arrangement does not eliminate Article 36.

Quite the opposite.

The more complex the processing arrangement, the more important clear governance becomes.

A joint-controller agreement should therefore ideally address the mechanics of DPIAs and prior consultation.

Example

imagine an advertising platform and a social-media company jointly determine the purposes and means of a sophisticated behavioural-targeting system.

The DPIA identifies significant risks involving profiling, discrimination, manipulation and loss of individual control.

If those risks remain high after mitigation, the joint controllers should not each independently approach the supervisory authority in an uncoordinated fashion.

The governance arrangement should establish who coordinates the consultation, while preserving each party's substantive responsibilities under the GDPR.

5. Which supervisory authority should be consulted?

The supervisory authority must be one competent to deal with the relevant processing.

This becomes particularly important in cross-border processing.

The GDPR contains detailed rules concerning supervisory-authority competence, particularly in Articles 55 and 56.

A controller operating exclusively within one Member State will generally have a much simpler situation.

But consider a multinational enterprise headquartered in Germany that processes employee data throughout France, Spain, Italy and Poland.

If its DPIA concerns a processing operation subject to cross-border processing, determining the appropriate supervisory authority may require consideration of the GDPR's competence and cooperation mechanisms.

Article 36 should therefore not be treated as creating a free-standing rule concerning jurisdiction.

It operates within the broader supervisory-authority framework of Chapter VI.

6. “Prior to processing” is critical

The consultation must occur before the relevant processing begins.

This is one of the most important practical aspects of Article 36.

The purpose is preventive intervention.

The supervisory authority is supposed to have an opportunity to assess the proposed processing before individuals are exposed to the identified high risks.

Therefore, a controller cannot ordinarily say:

“We will launch the system now and consult the DPA afterwards.”

That defeats the preventive purpose of Article 36.

Imagine that a hospital intends to deploy an AI system that analyses patient information to predict clinical outcomes.

The DPIA identifies substantial risks that cannot currently be reduced to an acceptable level.

The hospital cannot launch the system on 1 January and submit an Article 36 consultation on 15 January merely because it intends to cooperate with the authority.

The consultation is supposed to take place before the processing begins.

7. What happens when processing has already begun?

The situation becomes more difficult where the risk changes after processing begins.

Article 36 is primarily a pre-processing mechanism, but real-world processing environments are dynamic.

For example:

A company launches a facial-recognition system after conducting a DPIA.

Initially, the system is limited to a small population and the risk is considered manageable.

Six months later, the company:

• expands the database dramatically;

• introduces new biometric matching technology;

• combines facial data with behavioural profiles;

• begins sharing the results with third parties; and

• discovers a serious technical vulnerability.

The risk profile may now be materially different.

The controller may need to reassess the DPIA under Article 35(11), and if the new assessment demonstrates sufficiently high residual risk, the supervisory authority may need to become involved.

The lesson is important:

Article 36 is not simply a one-time procedural box to be checked at the beginning of a project.

The underlying risk-management framework is dynamic.

8. The most important phrase: “high risk in the absence of measures”

The wording of Article 36(1) creates one of the most interesting interpretative questions in the provision.

The provision refers to processing that would result in a high risk in the absence of measures taken by the controller to mitigate the risk.

At first glance, this could produce two interpretations.

Interpretation one: look at the inherent risk

Under one interpretation, the controller asks:

Would this processing be high risk if safeguards were absent?

If the answer is yes, Article 36 consultation might appear to be required regardless of how effective the controller's safeguards are.

That interpretation would make Article 36 extremely broad.

Almost every serious DPIA could potentially lead to consultation because DPIAs often concern processing that would inherently be dangerous without safeguards.

Interpretation two: focus on residual risk

A more coherent interpretation is that the controller must consider the safeguards and mitigation measures actually available.

The controller first identifies the inherent risks.

It then introduces appropriate measures.

It then asks:

After those measures are implemented, is the remaining risk still high?

If the answer is yes, prior consultation is required.

This residual-risk interpretation fits the overall architecture of Article 35 and Recital 94.

It also corresponds to the logic of risk management.

The GDPR does not require organisations to eliminate every conceivable risk. That would be impossible.

Instead, the objective is to identify, evaluate and appropriately mitigate risks.

The critical issue therefore becomes the residual risk.

9. Inherent risk versus residual risk

This distinction is fundamental and should be mastered.

Inherent risk

This is the risk associated with the processing before safeguards are taken into account.

For example:

A company proposes to process biometric data of one million individuals.

The inherent risk may be very high because biometric information is highly sensitive and difficult to replace if compromised.

Mitigated risk

The company introduces:

• strong encryption;

• strict access controls;

• pseudonymisation;

• separation of identifiers;

• limited retention;

• independent audits;

• purpose limitation;

• access logging;

• strict employee permissions; and

• robust deletion mechanisms.

The risk decreases.

Residual risk

After all reasonable measures are considered, some risk remains.

The crucial Article 36 question is:

Is the residual risk still high?

If the answer is no, Article 36 consultation may not be required.

If the answer is yes, prior consultation is triggered.

This is why a DPIA should not merely contain a list of risks.

It should demonstrate the relationship between:

risk → severity → likelihood → mitigation → residual risk.

10. High risk is not the same as any risk

Another common mistake is to assume that Article 36 applies whenever a DPIA identifies a risk.

That is incorrect.

Personal-data processing almost always involves some degree of risk.

The GDPR does not require supervisory-authority consultation for every risk.

The threshold is high risk.

Moreover, the relevant risk concerns the rights and freedoms of natural persons.

This means the analysis should not focus exclusively on corporate or financial risks.

A controller may suffer substantial financial consequences from a data breach, but Article 36 is concerned primarily with risks to individuals.

The controller therefore needs to examine possible consequences such as:

• discrimination;

• identity theft;

• financial loss;

• reputational harm;

• psychological harm;

• physical harm;

• loss of autonomy;

• unlawful surveillance;

• exclusion;

• unfair treatment;

• denial of opportunities;

• exposure of intimate information;

• chilling effects on behaviour;

• loss of confidentiality; and

• interference with fundamental rights.

11. Likelihood and severity must both be examined

A sophisticated Article 36 analysis cannot simply say:

“The processing involves sensitive data, therefore the risk is high.”

Risk is more nuanced.

The controller should consider both:

severity of potential harm

and

likelihood of occurrence.

Consider two scenarios.

Scenario

A A database contains highly sensitive medical information. A vulnerability could expose the data and cause serious harm. However, the system is heavily isolated, strongly encrypted, access is extremely limited, and independent security testing has demonstrated a very low probability of compromise. The inherent risk may be high, but the residual risk may have been significantly reduced.

Scenario

B A company operates an automated decision-making system that determines whether individuals receive essential services. The system has known accuracy problems, discriminatory outcomes and no effective human review. Even if the company claims that the processing is secure from a cybersecurity perspective, the rights-related risk may remain extremely high. This demonstrates an important point:Security risk and data-protection risk are not identical.

A perfectly secure system can still unlawfully interfere with individuals' rights.

12. “High risk” extends beyond cybersecurity

Article 36 should never be reduced to an information-security provision.

Cybersecurity is important, but GDPR risk includes much more.

Suppose a company develops an AI recruitment system.

The system has:

• excellent encryption;

• no known cybersecurity vulnerability;

• strong access controls;

• secure infrastructure.

Nevertheless, the algorithm systematically disadvantages certain categories of applicants.

The processing could still present a very high risk.

Why?

Because the risk concerns individuals' rights and freedoms, not merely confidentiality or system security.

The DPIA and Article 36 process must therefore consider substantive risks such as:

• discrimination;

• unfair profiling;

• lack of transparency;

• inaccurate decisions;

• inability to contest decisions;

• excessive data collection;

• unlawful inference; and

• disproportionate interference with privacy.

13. The role of Recital 94

Recital 94 provides particularly important interpretative context.

It makes clear that prior consultation is relevant where:

1. the DPIA indicates high risk;

2. safeguards and mitigation mechanisms have been considered;

3. the controller considers that the risk cannot reasonably be mitigated; and

4. the processing is therefore capable of producing significant risks for individuals.

The reference to available technologies and costs of implementation is particularly significant.

The GDPR does not operate on the simplistic principle that a controller must implement every theoretically possible safeguard regardless of cost.

The controller must consider what is reasonably available.

But “too expensive” is also not a magic escape route.

A controller cannot simply say:

“We could eliminate the risk, but we do not want to spend the money.”

The proportionality and reasonableness of the proposed mitigation must be examined.

The more severe the potential consequences for individuals, the weaker a purely economic justification becomes.

14. The “cost” argument must be treated carefully

Imagine that an organisation discovers that a particular security architecture would substantially reduce the risk of exposing highly sensitive personal data.

The architecture costs €2 million.

The controller decides not to implement it because the existing system is cheaper.

If the consequences of failure could include serious and irreversible harm to individuals, the controller may have difficulty defending its position merely by pointing to cost.

The correct analysis is not:

“Can we afford the measure?”

It is:

“Taking into account the nature, scope, context and purposes of the processing, the severity and likelihood of harm, available technology and implementation costs, have we taken appropriate measures such that the residual risk is acceptable?”

This is much more demanding.

15. Examples of potentially unacceptable residual risk

The more severe and irreversible the potential consequences, the more likely consultation becomes necessary.

Consider a system that processes data in a way that could lead to:

• termination of employment;

• denial of housing;

• denial of financial services;

• exclusion from essential public services;

• serious financial loss;

• exposure of highly intimate information;

• threats to physical safety;

• serious discrimination;

• unlawful surveillance; or

• other consequences that individuals cannot realistically reverse.

The question is not simply whether something “bad” could happen.

The controller must consider whether the risk is sufficiently serious and insufficiently mitigated to remain high.

16. New technology can be particularly significant

Innovative technologies frequently create Article 36 issues because the controller may lack sufficient experience regarding their consequences.

Examples

may include:

• advanced AI systems;
• biometric identification;
• large-scale behavioural analytics;
• novel genetic-data processing;
• extensive location tracking;
• sophisticated profiling;
• large-scale facial recognition;
• emerging neurotechnology;
• novel surveillance systems; and
• complex data combinations. But an important examination point is: New technology does not automatically trigger Article 36. The technology is relevant because it may affect the nature, scope, context or purposes of processing and therefore the level of risk. The actual legal question remains the level of risk after mitigation.

17. Article 36 and Article 35 must be distinguished

This distinction is extremely important.

Article 35

Article 35 concerns the DPIA.

Its function is essentially:

Identify and evaluate the risks and determine how they can be addressed.

Article 36

Article 36 concerns prior consultation.

Its function is:

Bring the supervisory authority into the process where the controller cannot adequately reduce the remaining high risk.

Therefore:

DPIA ≠ prior consultation.

A DPIA is not automatically submitted to the supervisory authority.

Most DPIAs do not result in Article 36 consultation.

The normal outcome should be that the controller identifies risks and mitigates them adequately.

Article 36 represents an escalation mechanism.

18. A DPIA does not equal DPA approval

Another critical distinction is:

DPIA ≠ DPA approval.

A controller cannot say:

“The DPA approved our DPIA.”

Ordinarily, the supervisory authority does not approve every DPIA.

The DPIA is principally an accountability instrument maintained by the controller.

The supervisory authority becomes involved under Article 36 only where the statutory conditions for prior consultation are met.

This is one of the reasons Article 36 is exceptional rather than routine.

19. Article 36(2): What does the supervisory authority do?

Once consultation has been properly triggered, Article 36(2) governs the authority's response.

The authority is required to respond where it considers that the intended processing would infringe the GDPR, particularly where:

• the controller has inadequately identified risks;

• the controller has inadequately mitigated risks; or

• other GDPR requirements are not satisfied.

This is significant because the supervisory authority's review is not necessarily limited to asking:

“Did you perform a DPIA?”

It can examine the substantive legality of the proposed processing.

20. The authority's review can extend beyond risk mitigation

Suppose a controller submits a sophisticated DPIA.

The DPIA is technically excellent.

The security controls are strong.

The residual cybersecurity risk is relatively low.

But the controller has no valid legal basis for the processing.

The supervisory authority is not required to ignore that issue merely because the DPIA itself is well prepared.

The authority may consider whether the intended processing complies with the GDPR more broadly.

Potential issues may include:

• Article 5 principles;

• lawful basis under Article 6;

• special-category requirements under Article 9;

• transparency under Articles 13 and 14;

• data-subject rights;

• automated decision-making requirements;

• purpose limitation;

• data minimisation;

• retention;

• international transfers;

• security;

• controller-processor arrangements; and

• other applicable GDPR obligations.

Thus, Article 36 consultation is not merely a technical DPIA audit.

It can become a broader regulatory compliance examination.

21. The phrase “in particular” matters

Article 36(2) refers particularly to circumstances in which the controller has insufficiently identified or mitigated the risk.

The words “in particular” are important.

They suggest that inadequate risk identification or mitigation is a central example, but not necessarily an exhaustive limitation on what the authority may examine.

The supervisory authority can therefore consider the wider legality of the intended processing.

This makes an Article 36 consultation potentially significant from a regulatory perspective.

A controller should not approach the authority assuming:

“We only need to defend the DPIA.”

The authority may examine the entire processing operation.

22. Written advice

Where the authority concludes that the intended processing would infringe the GDPR, Article 36(2) requires it to provide written advice.

The written nature is important for several reasons.

First, it creates an authoritative record of the authority's concerns.

Second, it allows the controller to understand precisely what the authority considers problematic.

Third, it enables subsequent monitoring of whether the controller has implemented the necessary changes.

Fourth, it creates documentary evidence that may become relevant if further regulatory action occurs.

In practice, written advice can therefore function as a roadmap for bringing the proposed processing into compliance.

23. Is the advice legally binding?

This is one of the most nuanced issues in Article 36.

The text refers to “advice.”

That wording is important.

Article 36 consultation is not, by itself, structured as a general licensing regime.

Therefore, a controller should not automatically interpret the authority's written advice as a formal authorisation or prohibition.

However, this does not mean that the controller can safely ignore the advice.

Why?

Because Article 36(2) expressly permits the supervisory authority to use its powers under Article 58.

This fundamentally changes the practical significance of the consultation.

24. Article 36 and Article 58 must be read together

Article 58 provides supervisory authorities with a range of powers.

These include investigative and corrective powers.

Depending on the circumstances, the authority may:

• obtain information;

• conduct investigations;

• obtain access to premises and equipment;

• issue warnings;

• issue reprimands;

• order compliance;

• order the rectification or erasure of personal data;

• impose limitations on processing; and

• impose a temporary or definitive limitation, including a ban on processing.

The exact power available depends on the circumstances and applicable law.

Therefore, the practical lesson is:

Do not confuse “advice” with “permission to proceed.”

The authority may issue advice and, where appropriate, exercise its Article 58 powers.

25. Why this makes Article 36 quasi-authoritative in practice

Suppose a controller submits an Article 36 consultation.

The authority responds:

The proposed processing lacks sufficient safeguards and presents an unacceptable risk.

The controller could theoretically argue that the document is merely “advice.”

But if the authority simultaneously exercises an Article 58 corrective power prohibiting the processing, the controller obviously cannot proceed.

Thus, Article 36 should be understood as a consultation mechanism with potentially significant regulatory consequences.

It is not simply an informal conversation with the DPA.

26. The eight-week period

Article 36(2) provides a maximum period of up to eight weeks for the authority to provide its written advice.

This deadline serves an important practical function.

Without a time limit, prior consultation could potentially delay commercial or public-sector projects indefinitely.

The GDPR therefore attempts to balance:

regulatory scrutiny

against

legal and operational certainty.

Eight weeks is substantial enough to allow a complex regulatory assessment but short enough to prevent indefinite administrative uncertainty.

27. Extension by six weeks

The authority may extend the period by six additional weeks where the intended processing is sufficiently complex.

The maximum therefore ordinarily becomes:

8. weeks + 6 weeks = 14 weeks

But the extension is not supposed to be automatic.

Complexity is relevant.

A genuinely novel, technically complicated or large-scale processing operation may justify an extension.

Example

consider a proposed system involving:

• several million individuals;

• biometric data;

• multiple controllers;

• multiple processors;

• international infrastructure;

• AI-driven profiling;

• several legal bases; and

• complex technical safeguards.

The authority may reasonably need additional time.

But a controller should not assume that every consultation automatically takes fourteen weeks.

28. The authority must explain the extension

The supervisory authority must inform the controller and, where applicable, the processor:

• that the period is being extended; and

• why the extension is necessary.

There is therefore an accountability obligation on the authority itself.

The extension cannot simply be imposed without communication.

Moreover, the authority must notify the controller within one month of receiving the consultation request.

This creates an important procedural safeguard.

29. Suspension of the deadline

The Article 36 deadline can also be suspended while the supervisory authority waits for information it has requested.

This is logically necessary.

Imagine that the authority asks the controller for:

• the complete DPIA;

• details concerning data flows;

• technical documentation;

• processor contracts;

• algorithmic testing results; and

• risk-mitigation evidence.

The controller provides only part of the material.

The authority cannot reasonably be expected to complete its assessment while critical information is missing.

The period may therefore be suspended until the requested information is obtained.

This creates a practical lesson for controllers:

A defective consultation package can delay the process.

A controller should therefore submit a complete, coherent and technically defensible consultation package from the outset.

30. Silence by the DPA does not equal approval

This is one of the most important practical points arising from Article 36 and Recital 94.

The fact that the authority does not respond within the prescribed period should not be interpreted as:

“The DPA has approved the processing.”

Recital 94 expressly makes clear that the absence of a response does not prejudice the authority's ability to exercise its powers under the GDPR.

Therefore:

No response ≠ approval.

This is a critical distinction from licensing systems where silence may sometimes have legal consequences equivalent to consent.

Article 36 does not establish such a general approval-by-silence mechanism.

31. Article 36(3): Information supplied to the authority

The third paragraph identifies the information the controller must provide.

This requirement is logical because the supervisory authority cannot meaningfully assess a processing operation without understanding how it works.

The information should allow the authority to answer:

• Who is responsible?

• What is being processed?

• Why is it being processed?

• How is it being processed?

• What risks exist?

• What safeguards have been implemented?

• Who can access the data?

• What technical and organisational arrangements exist?

• What did the DPIA conclude?

32. Responsibilities of the parties

The first category concerns the respective responsibilities of:

• the controller;

• joint controllers; and

• processors.

This becomes particularly important in complex corporate structures.

Imagine a multinational group where:

• ParentCo determines the purposes;

• Subsidiary A collects the data;

• Subsidiary B operates the analytics;

• CloudCo hosts the infrastructure;

• AI Provider supplies the model; and

• VendorCo provides identity verification.

The supervisory authority needs to understand this architecture.

Otherwise, it may be impossible to determine:

• who makes decisions;

• who controls the data;

• who performs which processing;

• who implements safeguards;

• who handles data-subject rights; and

• who is responsible for compliance failures.

33. Why Article 36 expressly mentions groups of undertakings

Large corporate groups frequently create complicated data-processing arrangements.

A single project may involve several legal entities.

The fact that those entities belong to the same corporate group does not automatically make them one controller.

Each entity's actual role must be assessed.

The authority therefore needs visibility into the organisational structure.

This is especially important where data move between group companies.

For example:

ParentCo may determine the purposes while SubsidiaryCo processes employee data for operational purposes.

Calling both entities “the group” is legally insufficient.

The Article 36 submission should identify their actual GDPR roles.

34. Purposes and means

The authority must also receive information concerning the purposes and means of processing.

This reflects the central concept of controllership.

The purpose answers:

Why is the data being processed?

The means answer:

How will the processing be carried out?

A consultation request should therefore be sufficiently concrete.

A statement such as:

“We will use AI to improve services”

would be inadequate.

The controller should explain:

• what data will be used;

• whose data will be used;

• what the AI system will do;

• what outputs it will generate;

• how those outputs will be used;

• whether decisions will be automated;

• whether humans will review outputs;

• who will receive the outputs;

• how long the data will be retained; and

• how individuals can exercise their rights.

The authority needs enough detail to assess actual risk.

35. Measures and safeguards

The controller must also explain the safeguards protecting individuals.

These safeguards can operate at several levels.

Technical safeguards

Examples

include:

• encryption;
• pseudonymisation;
• access controls;
• authentication;
• network segregation;
• logging;
• monitoring;
• vulnerability management;
• secure deletion;
• tokenisation.

Organisational safeguards

Examples

include:

• internal policies;
• employee training;
• role-based access;
• governance committees;
• incident-response procedures;
• audit programmes;
• supplier controls;
• retention policies.

Legal and procedural safeguards

Examples

include:

• contractual restrictions;
• data-processing agreements;
• transparency mechanisms;
• rights-management procedures;
• human review;
• appeal mechanisms;
• purpose limitations. The authority needs to understand not merely that safeguards exist, but whether they actually address the identified risks.

36. The DPIA itself

The DPIA is central to the consultation.

The authority should be able to see:

• the processing description;

• necessity and proportionality analysis;

• identified risks;

• severity and likelihood;

• proposed mitigation measures;

• residual risk;

• consultation rationale.

A weak DPIA can therefore undermine the entire Article 36 consultation.

If the DPIA does not convincingly explain why the residual risk remains high, the authority may have to request additional information.

Conversely, an exceptionally well-prepared DPIA can make the consultation considerably more efficient.

37. “Any other information requested”

The final category is deliberately broad.

The information list in Article 36(3) is therefore not exhaustive.

The authority can request additional information necessary to assess the proposed processing.

This could include, depending on the circumstances:

• technical architecture;

• algorithmic documentation;

• testing results;

• processor agreements;

• subprocessor information;

• data-flow diagrams;

• security assessments;

• penetration-testing results;

• retention schedules;

• access matrices;

• legitimate-interest assessments;

• contractual arrangements;

• records concerning data-subject rights;

• evidence supporting proportionality;

• internal governance documentation.

The practical consequence is that the controller must be prepared for an iterative regulatory dialogue.

38. Article 36(4): Consultation during legislative preparation

Paragraph 4 creates a different form of prior consultation.

This provision does not concern a private controller seeking to launch a processing operation.

It concerns Member States and legislative or regulatory measures.

Where a Member State prepares:

• a proposal for legislation to be adopted by its national parliament; or

• a regulatory measure based on such legislation,

and the measure relates to personal-data processing, the supervisory authority must be consulted.

This is a fundamentally different regulatory situation.

39. Why Article 36(4) exists

The objective is to prevent privacy problems from being embedded in legislation itself.

Suppose a government proposes legislation establishing a nationwide database containing large quantities of personal data.

If privacy implications are considered only after the legislation is enacted and the database becomes operational, regulatory intervention may become much harder.

It is therefore preferable to involve the supervisory authority during legislative design.

This allows privacy risks to be identified at the policy-making stage.

In this sense, Article 36(4) is a form of privacy-by-design at the legislative level.

40. Article 36(4) is broader than Article 36(1)

An important distinction is that Article 36(4) does not use the same high-risk trigger found in Article 36(1).

Article 36(1):

high residual risk following a DPIA → controller must consult.

Article 36(4):

legislative or regulatory measure relating to processing → Member State must consult the supervisory authority.

Therefore, Article 36(4) should not be treated as simply another version of Article 36(1).

Its function is institutional rather than project-specific.

41. Article 36(4) and legislative quality

The supervisory authority's involvement can improve legislative quality in several ways.

It can identify:

• excessive data collection;

• vague purposes;

• disproportionate retention periods;

• insufficient safeguards;

• unclear access rights;

• inadequate transparency;

• weak data-subject rights;

• inappropriate sharing mechanisms;

• insufficient oversight;

• excessive surveillance;

• incompatibility with GDPR principles.

This is particularly important where legislation creates large-scale databases or authorises government agencies to undertake extensive data processing.

42. Article 36(5): National law can go further

Paragraph 5 is particularly important because it creates an opening for Member States to impose stricter requirements.

The GDPR normally creates a harmonised framework.

But Article 36(5) permits Member State law to require controllers to:

• consult the supervisory authority; and

• obtain prior authorisation.

This is different from the ordinary Article 36(1) mechanism.

43. Consultation versus authorisation

This distinction must be remembered.

Article 36(1)

The controller must consult the supervisory authority where the relevant high-risk conditions exist.

Article 36(5)

National law may additionally require consultation and even prior authorisation for specified public-interest processing.

The second mechanism therefore resembles a licensing system much more closely.

It is an exception to the general GDPR approach that processing does not ordinarily require prior regulatory permission.

44. The limitation: public interest

Article 36(5) is not unlimited.

The processing must concern the performance of a task carried out by the controller in the public interest.

The provision specifically mentions areas such as:

• social protection; and

• public health.

This is significant.

A Member State cannot simply create a general national-law requirement that every private-sector controller must obtain DPA approval before processing personal data.

The opening clause is connected to specific public-interest processing.

45. Connection with Article 6(1)(e)

The phrase “task carried out in the public interest” naturally connects Article 36(5) with Article 6(1)(e).

Article 6(1)(e) provides a legal basis for processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority.

But the two provisions should not be mechanically equated.

The existence of an Article 6(1)(e) legal basis does not automatically mean that Article 36(5) authorisation is required.

Rather, Article 36(5) permits Member States to create such additional requirements for specified public-interest processing.

The national legislation must therefore be examined.

46. Article 36 and accountability

Article 36 is an excellent example of the GDPR's accountability principle.

Under Article 5(2), the controller must not merely comply.

It must be able to demonstrate compliance.

Article 36 reinforces this architecture.

The controller must be able to demonstrate:

1. what processing it intends to undertake;

2. why it intends to undertake it;

3. what risks exist;

4. how those risks were assessed;

5. what safeguards were considered;

6. which safeguards were implemented;

7. what residual risk remains;

8. why the residual risk cannot reasonably be reduced further; and

9. why consultation is necessary.

The consultation package therefore becomes an important accountability record.

47. Article 36 as a governance mechanism

From a corporate-governance perspective, Article 36 should not be handled as a last-minute legal filing.

An organisation contemplating potentially high-risk processing should ideally establish an internal escalation process.

For example:

Business proposal

Privacy/legal assessment

Risk assessment

DPIA

Risk mitigation

Residual-risk assessment

DPO review

Decision: acceptable risk or Article 36 consultation

This converts Article 36 into a governance mechanism rather than a purely legal formality.

48. The controller should document why consultation was or was not required

One of the most important practical lessons is that the controller should document its reasoning.

Suppose a DPIA initially identifies high risk.

The controller then introduces:

• pseudonymisation;

• data minimisation;

• restricted access;

• shorter retention;

• human review;

• stronger security;

• transparency measures.

After implementation, the residual risk falls to an acceptable level.

The controller decides not to consult the supervisory authority.

That decision should itself be documented.

Why?

Because Article 5(2) accountability means the controller should be able to explain:

Why did we conclude that Article 36 was not triggered?

A simple statement saying “DPA consultation not required” is weak.

A stronger record would show:

Initial risk → mitigation → residual risk → assessment → conclusion.

49. The relationship between Article 36 and privacy by design

Article 25 is also highly relevant.

Article 25 requires data protection by design and by default.

Article 36 can be viewed as the external escalation point of that principle.

The controller should first design the system so that privacy risks are reduced.

If the design still produces unacceptable high residual risks, Article 36 brings the supervisory authority into the process.

This creates a hierarchy:

Design safely → assess risks → mitigate → escalate if necessary.

Article 36 is therefore not a substitute for privacy by design.

A controller cannot deliberately build a risky system and then rely on the DPA to solve the problem.

50. Article 36 and security under Article 32

Article 32 is also relevant.

A DPIA involving personal-data security should consider appropriate technical and organisational measures.

However, Article 36 is broader than Article 32.

Example

suppose a company proposes a system for evaluating employees.

Its cybersecurity is excellent.

Yet the system uses invasive monitoring to infer employee productivity.

The major risk may not be unauthorised access at all.

It may involve:

• excessive surveillance;

• lack of transparency;

• inaccurate inference;

• disproportionate monitoring;

• chilling effects;

• unfair employment decisions.

Thus, strong Article 32 security measures do not automatically eliminate Article 36 concerns.

51. Article 36 and Article 24

Article 24 requires the controller to implement appropriate measures and demonstrate that processing is performed in accordance with the GDPR.

Article 36 fits naturally into this obligation.

If an organisation repeatedly conducts high-risk processing without proper escalation, this may reveal weaknesses in its broader accountability framework.

Therefore, Article 36 should be integrated into the organisation's compliance programme.

It should not exist as an isolated DPO procedure.

52. Article 36 and Article 35(7)

A well-designed DPIA under Article 35(7) already contains much of the information needed for Article 36 consultation.

The DPIA should describe:

• processing operations;

• purposes;

• necessity;

• proportionality;

• risks;

• mitigation measures.

Article 36 then adds the supervisory-authority dimension.

This explains why a good Article 36 consultation does not require the controller to start from scratch.

The consultation should essentially allow the authority to review the controller's existing risk analysis and the reasons why the controller believes the residual risk cannot adequately be mitigated.

53. A hypothetical example: AI recruitment system

Consider a company developing an AI recruitment system.

The system:

• analyses CVs;

• evaluates employment history;

• predicts candidate suitability;

• generates candidate scores;

• ranks applicants;

• uses historical recruitment data;

• processes potentially sensitive information.

A DPIA identifies significant risks.

The controller introduces:

• data minimisation;

• pseudonymisation;

• bias testing;

• human review;

• candidate transparency;

• audit logging;

• restricted access;

• model monitoring.

The controller then reassesses the risk.

If the remaining risks are adequately reduced, Article 36 may not be triggered.

But suppose testing shows that the system continues to systematically disadvantage certain categories of applicants.

The controller cannot simply say:

“We have already implemented many safeguards.”

The question is whether the remaining risk is still high.

If it is, and cannot reasonably be mitigated, prior consultation becomes relevant.

The DPA may then assess not only the safeguards but also issues such as:

• lawful basis;

• transparency;

• fairness;

• automated decision-making;

• data minimisation;

• proportionality;

• data accuracy;

• discrimination risks.

This demonstrates why Article 36 can become substantially broader than a conventional security review.

54. A second example: large-scale health database

Imagine a public authority proposes a national health-data platform.

The platform will contain:

• medical records;

• diagnoses;

• prescriptions;

• genetic information;

• demographic information;

• hospital data.

The processing is large-scale and highly sensitive.

The DPIA identifies serious risks.

The authority considers:

• encryption;

• pseudonymisation;

• role-based access;

• strict retention;

• audit logs;

• data minimisation;

• independent oversight.

However, some significant risks remain because the database necessarily centralises extremely sensitive information and enables broad access for multiple purposes.

The controller concludes that the residual risk remains high.

Article 36 consultation may therefore become necessary.

The DPA could examine:

• whether the purposes are sufficiently defined;

• whether the processing is necessary;

• whether access is proportionate;

• whether retention is justified;

• whether safeguards are sufficient;

• whether individuals have meaningful rights;

• whether the proposed architecture complies with the GDPR.

55. A third example: surveillance technology

Consider a city deploying a sophisticated facial-recognition system.

The controller argues that the technology is secure.

But the DPIA identifies:

• large-scale monitoring;

• biometric processing;

• false positives;

• potential discrimination;

• inability of individuals to avoid observation;

• significant effects on freedom of movement and privacy.

The authority would not be concerned merely with encryption.

It would need to consider whether the very design and use of the system is proportionate.

This is a classic example demonstrating why Article 36 is fundamentally about rights and freedoms, rather than merely cybersecurity.

56. A fourth example: financial profiling

Suppose a financial institution intends to combine:

• transaction data;

• location information;

• purchasing behaviour;

• online activity; and

• third-party data

to create detailed risk profiles.

The controller conducts a DPIA and implements strong security.

Nevertheless, the profiling may create serious risks involving:

• inaccurate inference;

• unfair treatment;

• financial exclusion;

• discrimination;

• lack of transparency;

• inability to challenge decisions.

The residual risk may therefore remain high despite excellent technical safeguards.

Again, Article 36 is potentially relevant.

57. The most important conceptual distinction

The entire provision can be reduced to a sequence of questions:

Question 1

Is the processing likely to result in high risk?

If no, Article 36 ordinarily does not arise.

If yes, continue.

Question 2

Has a DPIA been conducted?

If Article 35 requires one, yes.

Question 3

What measures can reduce the risk?

Consider technical, organisational and legal safeguards.

Question 4

What is the residual risk after mitigation?

This is the crucial stage.

Question 5

Does high residual risk remain?

If no, Article 36 consultation may not be required.

If yes, continue.

Question 6

Can the risk reasonably be mitigated?

If reasonable and effective measures can still reduce it, those measures should be considered and implemented.

If the risk cannot reasonably be reduced sufficiently, prior consultation is triggered.

Question 7

Has the processing started?

It should not start before the required consultation.

This sequence is far more useful than memorising Article 36 as a list of documents and deadlines.

58. Common mistakes concerning Article 36

Mistake 1: “Every DPIA requires consultation.”

False.

A DPIA does not automatically trigger Article 36.

Mistake 2: “Every high-risk processing operation requires consultation.”

Too broad.

The critical issue is the risk remaining after appropriate mitigation.

Mistake 3: “The processor must consult the DPA.”

Generally incorrect.

The controller bears the Article 36 obligation, although the processor may need to assist.

Mistake 4: “DPA advice is approval.”

Incorrect.

Consultation is not generally equivalent to regulatory authorisation.

Mistake 5: “No response means approval.”

Incorrect.

Silence does not eliminate the authority's powers.

Mistake 6: “The DPA only reviews the DPIA.”

Too narrow.

The authority may consider broader GDPR compliance.

Mistake 7: “Security controls eliminate all Article 36 risk.”

Incorrect.

Rights-related risks can remain even where cybersecurity is excellent.

Mistake 8: “Article 36 is only about private companies.”

Incorrect.

Paragraph 4 concerns legislative and regulatory measures, while paragraph 5 concerns certain public-interest processing.

Mistake 9: “Article 36(5) applies to all public authorities.”

Too broad.

The national-law authorisation mechanism is limited to the circumstances specified by the provision, particularly public-interest tasks.

Mistake 10: “The controller can launch first and consult later.”

Generally contrary to the preventive nature of Article 36.

59. Examination and legal-analysis framework

For an examination, advisory memo or legal opinion, the strongest method is to analyse Article 36 through the following structure.

Step 1: Identify the processing

Determine:

• controller;

• purposes;

• means;

• data categories;

• data subjects;

• scale;

• context;

• technology.

Step 2: Determine whether Article 35 applies

Ask whether the processing requires a DPIA.

Step 3: Identify the risks

Assess:

• nature;

• severity;

• likelihood;

• affected rights;

• potential consequences.

Step 4: Identify mitigation

Consider:

• technical;

• organisational;

• legal;

• procedural measures.

Step 5: Determine residual risk

This is the critical Article 36 stage.

Step 6: Ask whether high residual risk remains

If yes, consider prior consultation.

Step 7: Prepare the consultation package

Include:

• roles;

• purposes and means;

• safeguards;

• DPO details;

• DPIA;

• additional requested information.

Step 8: Do not commence processing prematurely

The consultation is prior to processing.

Step 9: Analyse the DPA response

Consider:

• written advice;

• requested modifications;

• possible Article 58 action.

Step 10: Check national law

Particularly for Article 36(4) and (5).

60. The deeper policy rationale of Article 36

The deeper philosophy behind Article 36 is that controllers should ordinarily regulate their own processing through accountability, but certain risks are too significant to be left entirely to self-assessment.

This is a very important feature of modern data-protection law.

The GDPR does not establish a system where regulators approve every processing activity.

That would be impractical and would undermine the risk-based model.

Instead, responsibility is initially placed on the organisation.

The controller must:

• understand its processing;

• identify risks;

• build safeguards;

• document its decisions;

• demonstrate compliance.

But if that internal system identifies a high residual risk that cannot reasonably be controlled, the controller must escalate the matter.

Article 36 therefore creates a bridge between:

internal corporate accountability

and

external regulatory oversight.

61. Why the provision is preventive rather than punitive

Article 36 is fundamentally preventive.

The objective is to intervene before individuals suffer harm.

This distinguishes it from many enforcement mechanisms under Article 58, which may operate after a suspected infringement has occurred.

Article 36 effectively asks:

“Should this processing proceed in its current form?”

before the answer becomes:

“What should the regulator do after the harm has occurred?”

That preventive orientation is one of its most important characteristics.

62. Relationship with the principle of proportionality

Article 36 cannot be understood without proportionality.

A processing operation may pursue a legitimate and socially valuable objective.

For example:

• preventing fraud;

• improving healthcare;

• detecting serious crime;

• administering social benefits;

• improving public services.

The fact that an objective is legitimate does not automatically make every method of achieving it proportionate.

The controller must consider whether the processing is:

• necessary;

• appropriate;

• limited;

• adequately safeguarded; and

• balanced against the rights and freedoms of individuals.

A DPA considering an Article 36 consultation may therefore examine whether the proposed means go further than necessary to achieve the intended purpose.

63. Article 36 as an escalation mechanism, not a compliance substitute

The final conceptual point is perhaps the most important.

Article 36 does not transfer responsibility for compliance from the controller to the supervisory authority.

The controller cannot say:

“We identified a high risk, so we sent it to the DPA. Whatever happens next is the DPA's responsibility.”

That is not how the GDPR works.

The controller remains responsible for its processing.

The authority's involvement does not eliminate:

• accountability;

• lawfulness;

• fairness;

• transparency;

• necessity;

• proportionality;

• security;

• data-subject rights; or

• other GDPR obligations.

Article 36 is therefore an escalation mechanism, not a regulatory shield.

64. Overall synthesis

Article 36 represents one of the clearest expressions of the GDPR's move away from indiscriminate regulatory notification toward risk-based supervision and accountability.

Its logic is sequential.

First, the controller is expected to understand the proposed processing.

Second, where Article 35 applies, the controller conducts a DPIA.

Third, the controller identifies the risks to individuals.

Fourth, the controller implements appropriate safeguards.

Fifth, the controller evaluates the remaining residual risk.

Sixth, where the residual risk remains high and cannot reasonably be mitigated, the controller must consult the supervisory authority before commencing the processing.

The supervisory authority then has an opportunity to examine the proposed processing, provide written advice and, where necessary, exercise its Article 58 powers.

The authority's silence does not amount to approval.

The controller remains responsible throughout.

Article 36(3) ensures that the authority receives enough information to conduct a meaningful assessment.

Article 36(4) extends the consultation philosophy to legislation and regulatory measures that involve personal-data processing.

Article 36(5) permits Member States, within the limits specified by the GDPR, to establish even stronger prior-consultation or authorisation requirements for certain public-interest processing.

The most important conceptual formula is therefore:

High inherent risk → DPIA → mitigation → residual-risk assessment → high residual risk remains → prior consultation.

And the most important legal distinction is:

DPIA is an internal accountability and risk-assessment mechanism; Article 36 is the external regulatory escalation mechanism.

The second does not replace the first.

Similarly:

Consultation is not ordinarily authorisation.

And:

DPA silence is not approval.

Ultimately, Article 36 embodies a central philosophy of the GDPR: organisations are expected to take primary responsibility for understanding and controlling the risks created by their processing, but where those risks remain sufficiently serious, the protection of individuals requires an independent supervisory authority to be brought into the process before the processing proceeds.