Article 36: Prior consultation

Article 36 (Prior consultation) requires you, as a controller, to consult your supervisory authority before starting a processing activity if your DPIA shows “high risk” remains after your planned mitigations. Operationalize it by building a DPIA-driven trigger, a defined consultation packet, a stop/go gate that blocks launch, and a retained decision record. ¹

Key takeaways:

• Prior consultation is a pre-processing launch gate triggered by a DPIA that still shows high risk after mitigations. ¹
• You need an operating procedure: who decides residual risk, who contacts the authority, what gets sent, and how you document outcomes.
• Auditors will look for proof that you stopped go-live until the consultation obligation was satisfied and recorded.

A mature GDPR DPIA process is not “complete” when the document is signed. Article 36 adds a hard escalation path: if the DPIA outcome is high risk and you cannot reduce that risk with reasonable measures, you must consult the supervisory authority before you begin processing. ¹

For a CCO or GRC lead, the fast path is to treat Article 36 as a control that sits between privacy risk assessment and production change management. That means: (1) define what “residual high risk” means in your organization, (2) create a mandatory stop/go checkpoint for product launches, new data uses, and major model changes, and (3) standardize the consultation packet so you can move quickly when the trigger hits.

This page focuses on execution: applicability, triggers, workflow, evidence to retain, and audit questions. It assumes you already run DPIAs under Article 35 and need to operationalize the “what happens when the DPIA is still high risk” branch without slowing the business unnecessarily. ¹

Regulatory text

Requirement (operator reading): You must consult the supervisory authority before processing when a DPIA indicates the processing would result in a high risk without measures to mitigate that risk, and your measures do not sufficiently mitigate it. ¹

What this means in practice:

• Article 36 is triggered by a DPIA outcome (a control output), not by intuition or a policy label. ¹
• The duty sits with the controller. If you are a processor, you typically support the controller’s DPIA and escalation, but the controller owns the consultation decision and outreach. ¹
• “Prior to processing” is operationally a deployment gate: you cannot start the processing activity (including enabling a feature, onboarding a dataset, or commencing a new use case) until you’ve met the consultation obligation and documented the outcome. ¹

Plain-English interpretation

If your DPIA says, “This plan is still high risk even after controls,” you do not get to accept the risk quietly and ship. You have to pause and consult the regulator first. ¹

Treat “consult” as a regulated escalation pathway. Your job is to make it predictable:

• Clear trigger conditions
• A repeatable submission package
• Named decision-makers
• A recorded go/no-go decision tied to launch approval

Who it applies to (entity and operational context)

In-scope entities

• Controllers conducting processing activities that require a DPIA and produce a residual high-risk outcome. ¹

Common operational triggers (real-world scenarios)

You should expect Article 36 to arise in scenarios like:

• New large-scale profiling or scoring use cases where mitigations cannot reduce risk to an acceptable level.
• New surveillance-like monitoring features or sensitive-context data uses where the DPIA cannot credibly reduce risk.
• High-impact AI/ML deployments using personal data where purpose, transparency, or control effectiveness is still unresolved at sign-off.

Your DPIA methodology should be capable of producing an explicit residual risk determination; otherwise, you cannot run Article 36 as a control.

What you actually need to do (step-by-step)

Step 1: Set your “role-and-scope” baseline

Create and maintain a register that captures:

• Whether you are acting as controller or processor for the specific processing activity
• Data categories and affected systems
• Business owner and technical owner
• Whether the activity requires a DPIA and the DPIA status

This prevents the most common scoping failure: teams assuming Article 36 is “a privacy team thing” without clarifying who is legally the controller for the processing in question. ¹

Daydream fit: Use Daydream to keep a single system-of-record for processing activities, DPIA status, and the Article 36 consultation gate, so product and security approvals pull from the same truth set.

Step 2: Define the Article 36 trigger in your DPIA workflow

Add a required DPIA decision field: Residual risk rating after mitigations.

• If residual risk is not high, document rationale and proceed through normal approvals.
• If residual risk is high, route to the Article 36 workflow and block launch. ¹

Make the trigger mechanical. Avoid ambiguous wording like “DPO discretion” without criteria; that is hard to defend in an audit because it looks arbitrary.

Step 3: Implement a “stop/go” launch gate

Integrate with your operational intake points:

• Product launch checklist
• Change management / release management
• Data onboarding (new datasets)
• Third-party onboarding for processing services that introduce new uses of personal data

Control objective: No production processing begins when an Article 36 trigger is active. ¹

Practical pattern: create a required approval called Privacy Prior Consultation Clearance. Only the DPO (or privacy counsel) can mark it cleared, and only after consultation is complete or the residual risk is reduced and re-assessed.

Step 4: Assemble the consultation packet (standard template)

Article 36’s excerpt in your provided source is short, but operationally you need a consistent packet that allows you to explain:

• The processing description and purpose
• The DPIA summary and identified risks
• Controls planned and why residual risk remains high
• Alternatives considered (including “don’t do it” or “narrow scope”) and why rejected
• Decision record: who approved the DPIA outcome and the trigger determination
• Contact point for follow-ups

Keep the packet standardized so you can move quickly and avoid ad hoc drafting every time.

Step 5: Engage the supervisory authority and track outcomes

Run consultation as a case with:

• Case owner (privacy)
• Legal reviewer
• Business sponsor
• Clear status states (drafting, submitted, awaiting response, follow-up, closed)
• A documented outcome (guidance received, required changes, or decision to halt)

Even if your authority engagement is straightforward, the defensibility comes from the trace: when you paused, what you sent, and what you changed.

Step 6: Close the loop into engineering and operations

Prior consultation is not a paperwork exercise. The closure criteria should include:

• Updated controls implemented (or scope reduced)
• DPIA updated to reflect the post-consultation state
• Launch gate cleared with a dated approval record
• For third parties involved: contract/work instructions updated so the processing matches what was assessed

Required evidence and artifacts to retain

Keep an “Article 36 evidence packet” per triggering processing activity:

• DPIA with clear residual risk outcome and mitigation assessment ¹
• Role-and-scope record showing you are controller (or clarifying controller identity) for the activity ¹
• The trigger decision record (who determined residual high risk, when, and why)
• Launch gate record showing processing did not begin before clearance ¹
• Consultation packet submitted to the authority and correspondence log
• Remediation/change log mapping authority feedback to implemented actions
• Final go-live approval and updated DPIA version

Operational note: store these in a system that supports immutable timestamps and approvals. Email-only evidence collapses quickly under audit.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your criteria for determining DPIA residual high risk and how that triggers prior consultation.” ¹
• “How do you ensure processing doesn’t start before consultation is completed?” ¹
• “Who is accountable for the decision to consult: business owner, DPO, legal, or security?”
• “Provide an example where you halted or delayed a launch due to DPIA residual high risk.”
• “How do you handle processing involving third parties where your company is controller but the third party operates the system?”

Common hangup: teams have a DPIA template but no operational integration with release management, so the business can ship while privacy is still negotiating risk ratings.

Frequent implementation mistakes (and how to avoid them)

1. No clear controller/processor determination per activity.
   Fix: maintain a role-and-scope register tied to each DPIA and each system. ¹

2. Residual risk isn’t explicitly recorded.
   Fix: require a post-mitigation residual risk field and documented rationale.

3. “Consultation” is treated as optional advice.
   Fix: make it a mandatory workflow branch with a hard gate “prior to processing.” ¹

4. No proof the organization paused processing.
   Fix: connect Article 36 status to release approvals; retain tickets and approvals as evidence. ¹

5. Consultation outcomes don’t change the system.
   Fix: require a change log and an updated DPIA before closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list case examples.

Risk-wise, Article 36 failures are rarely isolated. If you skip consultation after a high-risk DPIA, you usually also have weaknesses in DPIA governance, change management, and documentation quality. That combination increases regulatory exposure because it reads as a control failure, not a one-off mistake. ¹

A practical 30/60/90-day execution plan

First 30 days (establish the gate)

• Name the owner for Article 36 decisions (DPO or privacy counsel) and the operational coordinator.
• Update DPIA template to include explicit residual risk after mitigations and an Article 36 trigger outcome. ¹
• Add a release-management checkpoint: “DPIA complete and Article 36 cleared (if triggered).”
• Stand up the role-and-scope register for controller/processor determination per processing activity.

Days 31–60 (make it repeatable)

• Publish an Article 36 SOP: triggers, routing, required approvals, and submission packet contents. ¹
• Build a standard consultation packet template and a correspondence log template.
• Train product, security, and data teams on the “stop/go” mechanics and what a trigger means for delivery timelines.
• Configure Daydream (or your GRC system) to track DPIA status, trigger states, and evidence packets in one place.

Days 61–90 (prove it works)

• Run a tabletop exercise: pick one high-risk hypothetical and execute the workflow end-to-end, including the launch gate.
• Audit your last set of DPIAs: confirm residual risk is explicit and that any high-risk outcomes were handled consistently with your SOP. ¹
• Implement metrics without inventing targets: track number of DPIAs with residual high risk, number escalated, and average time the gate remains open (internally measured).
• Tighten third-party onboarding: ensure processing run by third parties cannot commence until the controller’s Article 36 gate is cleared. ¹

Frequently Asked Questions

Does Article 36 apply to processors?

The obligation to consult the supervisory authority in Article 36 is placed on the controller. Processors still need to support by providing system details, security controls, and processing descriptions used in the controller’s DPIA and consultation packet. ¹

What exactly triggers “prior consultation” in operational terms?

A DPIA outcome that concludes residual high risk remains after your planned mitigations triggers Article 36, and you must consult before processing begins. Your DPIA workflow should produce an explicit residual risk decision so the trigger is auditable. ¹

Can we proceed if we accept the risk internally?

Not when the DPIA indicates high risk remains in the absence of sufficient mitigating measures; Article 36 requires consultation prior to processing in that scenario. Build a hard launch gate so internal risk acceptance cannot override the requirement. ¹

What evidence will a regulator or auditor expect to see?

Keep the DPIA, the residual-risk determination, proof the processing did not start before clearance, and the consultation correspondence and outcome record. Bundle it as an evidence packet per processing activity for fast retrieval. ¹

How do we prevent product teams from bypassing the gate?

Make the Article 36 clearance a dependency in release management and data-access provisioning, not a policy reminder. If a system can be enabled without that approval state, the control is not effective. ¹

We have multiple EU establishments. Which supervisory authority do we consult?

Article 36 requires consultation with the supervisory authority, but the determination of which authority is competent depends on your regulatory posture and establishment facts. Route this decision through privacy counsel and document the rationale in the case file. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 36