Article 36: Prior consultation

To meet the article 36: prior consultation requirement, you must consult your supervisory authority before you start processing when your DPIA shows “high risk” that you cannot sufficiently mitigate with planned measures. Operationally, this means building a DPIA-to-consultation decision gate, preparing a regulator-ready consultation packet, and blocking go-live until the consultation outcome is recorded. (Regulation (EU) 2016/679, Article 36)

Key takeaways:

• Prior consultation is a pre-processing obligation triggered by a DPIA outcome, not a general “check with the regulator” step. (Regulation (EU) 2016/679, Article 36)
• Your control point is the DPIA residual risk decision: if high risk remains absent mitigations, you consult before launch. (Regulation (EU) 2016/679, Article 36)
• Auditors will look for repeatable evidence: role/scope clarity, an operating procedure, and retained decision records tied to specific processing changes. (Regulation (EU) 2016/679, Article 36)

Article 36 sits directly downstream of your DPIA program. If your organization runs a Data Protection Impact Assessment (DPIA) for a new or changed processing activity and the DPIA outcome indicates the activity would result in a high risk without adequate mitigating measures, GDPR requires that the controller consult the competent supervisory authority before processing begins. (Regulation (EU) 2016/679, Article 36)

For a CCO, compliance officer, or GRC lead, the practical problem is rarely “what does the law say.” The operational problem is routing, gating, and evidence: who decides whether residual risk is “high,” what mitigations qualify as sufficient, how you stop a product or program from launching early, and what exact packet you can produce in an exam to prove you made the consultation call correctly.

This page gives requirement-level implementation guidance you can put into an intake workflow (product, security architecture, procurement, and privacy), and into an audit narrative (how you decide, who signs, what artifacts you keep, and what happens when teams push to launch). It also flags common failure modes: unclear controller/processor role, “paper DPIAs,” and undocumented exceptions that quietly bypass consultation.

Regulatory text

Legal requirement (excerpt): “The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.” (Regulation (EU) 2016/679, Article 36)

Operator interpretation (what you must do)

You must implement a control that:

1. Identifies when a DPIA is required (your Article 35 workflow feeds this), and
2. Evaluates residual risk after planned mitigations, and
3. Triggers supervisory authority consultation before go-live when the DPIA indicates high risk absent adequate mitigating measures, and
4. Prevents processing from starting until consultation is completed and documented. (Regulation (EU) 2016/679, Article 36)

This is not satisfied by a policy statement. Examiners typically test the operational gate: can you show that high-risk processing could not launch without privacy sign-off and, where required, prior consultation documentation?

Plain-English interpretation of the requirement

Article 36 creates a “stop-and-consult” rule. If your DPIA says a planned processing activity is too risky for individuals and your mitigations do not sufficiently reduce that risk, you must ask the regulator for input before you begin the processing. (Regulation (EU) 2016/679, Article 36)

Think of it as a release management control for privacy risk:

• Input: DPIA outcome.
• Decision: residual risk remains high in the absence of mitigating measures.
• Action: consult supervisory authority.
• Constraint: do not start processing until the consultation step is completed and recorded. (Regulation (EU) 2016/679, Article 36)

Who it applies to (entity and operational context)

In-scope entities

• Controllers: Article 36 explicitly imposes the duty to consult on the controller. (Regulation (EU) 2016/679, Article 36)
• Processors and third parties: while not the obligated party under Article 36’s text, processors commonly influence the outcome because they design, operate, or propose measures that mitigate risk. Your contracts and delivery processes should support the controller’s ability to run the DPIA and reach a defensible decision.

In-scope operational contexts (typical triggers)

Prior consultation becomes relevant when you have:

• A new product feature, analytics use case, or surveillance/monitoring capability that triggers a DPIA and cannot be de-risked with planned controls.
• A major change in purpose, scope, data categories, scale, retention, or sharing (including with a third party) that changes the DPIA risk picture.
• A novel technical approach where you lack proven mitigations and your DPIA outcome stays “high risk.” (Regulation (EU) 2016/679, Article 36)

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

Step 1: Establish role and scope for each processing activity

Create and maintain a role-and-scope register that records, for each processing activity:

• Whether you act as controller, joint controller, or processor
• Data categories (including special categories if relevant)
• Systems involved and key third parties
• Owning business unit and technical owner

This avoids a frequent failure mode: teams assume “we’re just a processor,” then later discover controller-like decisions were made without the right governance. Keep this register current for activities that run through DPIA review.

Step 2: Create a DPIA-to-consultation decision gate

In your DPIA workflow, add a mandatory decision point after mitigations are defined:

Decision question: “Does the DPIA indicate high risk in the absence of measures taken to mitigate the risk?” (Regulation (EU) 2016/679, Article 36)

Operationalize this with:

• A defined residual risk rating method (your internal rubric is fine, but it must be consistent)
• Named decision owners (privacy lead + accountable controller representative)
• A required recorded outcome: consultation required / not required, with rationale

Step 3: Define the “no-go” release control

Implement a hard gating control in at least one system teams cannot bypass easily:

• Product release checklist
• Change management approval workflow
• Architecture review board sign-off
• Procurement onboarding gate for a new third party involved in the processing

Minimum rule: if consultation is required, the ticket cannot move to “approved for production” until the consultation record is attached and approved by the privacy owner. (Regulation (EU) 2016/679, Article 36)

Step 4: Build the consultation packet template (regulator-ready)

Article 36 tells you when to consult; your operating need is a packet that survives scrutiny. Standardize a consultation packet that includes:

• DPIA report and residual risk determination
• Description of processing purpose, scope, and data flows
• Planned measures taken to mitigate the risk (technical and organizational)
• Stakeholders/owners and where accountability sits (controller confirmation)
• Decision record: why mitigations are insufficient and why consultation is required (Regulation (EU) 2016/679, Article 36)

Keep the packet structured and version-controlled. Audits often fail on missing context rather than bad intent.

Step 5: Run the consultation process and document outcomes

Create an SOP that specifies:

• Which supervisory authority is competent (based on your establishment and processing context)
• Who submits (DPO/privacy counsel or designated privacy lead)
• How communication is tracked (case ID, email thread archive, portal export)
• How you translate outcomes into engineering requirements (remediation tickets and acceptance criteria)

Step 6: Post-consultation implementation and closure

Treat consultation outputs as binding work items:

• Convert regulator feedback into a remediation plan
• Re-run or update the DPIA if mitigations materially change the design
• Record final go/no-go approval and attach it to the release/change record

Step 7: Evidence retention and recurring review

Prior consultation is rare in many organizations, which increases the risk of “we didn’t know” gaps. Put the control on a recurring cadence:

• Periodic DPIA program review to confirm the consultation gate is still in the workflow
• Spot checks of high-risk DPIAs to confirm consultation decisions are documented
• Training for product/security/procurement intake owners

Daydream (as a workflow layer) typically fits here: it can standardize the DPIA-to-consultation trigger, required artifacts, and approval routing so you can prove the control operated even when the event is infrequent.

Required evidence and artifacts to retain

Maintain an “evidence packet” per in-scope processing activity:

Core artifacts (minimum)

• Role-and-scope register entry for the processing activity (controller/processor decision, systems, third parties)
• DPIA report, including risk ratings and mitigations
• Residual risk decision record stating whether Article 36 consultation is required, with approver names and dates
• Go-live/change approval record showing the gate was respected
• Consultation correspondence and submission materials (if triggered)
• Remediation tickets and closure evidence tied to consultation outcomes (Regulation (EU) 2016/679, Article 36)

Optional but high-value artifacts

• Data flow diagram and system architecture excerpt
• Third-party due diligence summary for vendors materially affecting the risk and mitigations
• Exception records (if any) with documented compensating controls and executive approval

Common exam/audit questions and hangups

Expect questions like:

1. Show me your criteria for “high risk” in DPIAs. Auditors want consistency and documented rationale.
2. How do you ensure processing doesn’t start before consultation? “Policy says so” will not pass; show the release gate.
3. Who decides consultation is required? Named owners and approval evidence matter.
4. How do third parties factor in? If a vendor provides the platform or analytics, auditors often ask how you validated mitigations.
5. Show a sample case. If you have none, you still need to show the control design, workflow configuration, and training records. (Regulation (EU) 2016/679, Article 36)

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating Article 36 as optional legal advice

Avoidance: bake consultation into the DPIA workflow as an explicit decision with a required recorded outcome. (Regulation (EU) 2016/679, Article 36)

Mistake 2: No enforceable “stop” control

Teams launch, then backfill documentation.
Avoidance: implement at least one system-enforced gate (change management, release approvals) that requires privacy approval and consultation evidence when triggered.

Mistake 3: Unclear controller/processor role

Consultation obligations depend on being the controller.
Avoidance: maintain a role-and-scope register and require role confirmation at intake before the DPIA begins.

Mistake 4: “Paper mitigations” that aren’t implemented

DPIA lists controls that never ship.
Avoidance: link mitigations to engineering tickets and require closure evidence before go-live.

Mistake 5: No retained decision record when consultation is “not required”

Audits often fail on missing negative evidence.
Avoidance: require a short written rationale and approver for “no consultation required,” stored with the DPIA.

Enforcement context and risk implications

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

Operationally, the risk is still concrete:

• Regulatory risk: if you begin high-risk processing without required prior consultation, you create a clear compliance gap tied to a specific go-live decision. (Regulation (EU) 2016/679, Article 36)
• Program risk: if your DPIA process is decoupled from release/change management, Article 36 becomes untestable and will fail under examination pressure.
• Third-party risk: processors and critical vendors can make or break mitigations. If your mitigations depend on third-party controls, you need those commitments in contracts, due diligence evidence, and implementation proof.

Practical 30/60/90-day execution plan

First 30 days (stabilize the requirement)

• Inventory processing activities currently subject to DPIA review and confirm which ones you own as controller (role-and-scope register baseline).
• Update the DPIA template to include a mandatory Article 36 decision field with approver sign-off. (Regulation (EU) 2016/679, Article 36)
• Implement an interim go-live gate: a manual checklist enforced by release managers if system gating is not ready.

Days 31–60 (operationalize and gate)

• Build the consultation packet template and standard evidence checklist.
• Integrate the gate into an enforceable workflow (change management or product release approvals) so teams cannot self-approve.
• Train intake owners (product, security, procurement, privacy) on triggers and required artifacts.

Days 61–90 (prove operation and close gaps)

• Run a tabletop on a hypothetical high-risk DPIA that requires consultation: test routing, packet creation, and go/no-go enforcement.
• Perform a sample-based control test: pick recent DPIAs and verify decision records, approvals, and linkage to shipped mitigations.
• Add recurring monitoring: periodic DPIA workflow QA and evidence packet completeness checks.

If you need repeatable evidence across multiple teams, Daydream can help by standardizing intake, required fields, approvals, and evidence retention so the Article 36 decision is consistently documented and auditable.

Frequently Asked Questions

What exactly triggers the article 36: prior consultation requirement?

A DPIA outcome that indicates processing would result in high risk in the absence of measures taken to mitigate that risk triggers prior consultation before processing starts. The trigger is the DPIA’s residual risk conclusion, not general project risk. (Regulation (EU) 2016/679, Article 36)

Does Article 36 apply to processors?

The regulatory text assigns the duty to consult to the controller. If you are a processor, you still need to support the controller by providing information about your processing and the measures you can implement, because those details affect the DPIA outcome. (Regulation (EU) 2016/679, Article 36)

Can we start processing while we wait for the supervisory authority response?

Article 36 requires consultation “prior to processing” when triggered by the DPIA. Your operating procedure should treat this as a no-go gate: do not start the processing until the consultation step is completed and recorded. (Regulation (EU) 2016/679, Article 36)

What if we add mitigations after the DPIA so the risk is no longer high?

Document the mitigations, update the DPIA outcome, and record the residual risk decision with approval. If the DPIA no longer indicates high risk absent mitigations, your record should show why prior consultation was not required. (Regulation (EU) 2016/679, Article 36)

What evidence do auditors expect if we’ve never had to consult?

They will still expect to see the control design and proof it is embedded in workflow: DPIA templates with an Article 36 decision, gating in release/change management, named owners, and training or procedure documents. (Regulation (EU) 2016/679, Article 36)

How should third-party involvement show up in our Article 36 process?

If third parties operate key parts of the processing or provide mitigations, your DPIA and consultation packet should reflect those dependencies and include the relevant due diligence and contractual commitments. Keep this tied to the specific processing activity and decision record. (Regulation (EU) 2016/679, Article 36)