When GDPR Article 36 prior consultation applies to your processing
Article 36(1) requires the controller to consult the supervisory authority before starting processing when a data protection impact assessment indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate it. The question is not whether the processing is risky at the outset, which is the territory of the DPIA itself, but whether the risk that remains after the planned safeguards are in place is still high. If it is, prior consultation is mandatory and processing must not begin until the consultation is complete. If the residual risk falls below that threshold, the controller proceeds on its own decision and the DPIA becomes the record of why.
The hard part is making that judgment honestly. Teams often score risk once, after the controls are already on the roadmap, and then treat anything with a named control as mitigated. A useful residual assessment asks whether each measure is implemented, tested and effective for this specific processing, and it names the risk that each measure does not remove. Confirm with your DPO and your legal team how your organization defines high risk, which scoring method it uses and who signs off a residual rating. The controller owns both the DPIA and the decision to consult. The supervisory authority does not approve the processing or make the decision for you. It issues written advice.
A submission the authority can act on is the second difficulty. Article 36(3) lists what must accompany the request, including the responsibilities of each controller, joint controller and processor, the purposes and means of processing, the measures and safeguards, the DPO's contact details and the DPIA itself. Gaps here delay the review, and the response period described under Article 36(2) does not start until the request is complete enough for the authority to assess. Ask your DPO which national supervisory authority you must approach, check whether your Member State requires prior authorization for public interest processing under Article 36(5), and assemble the file before you need it.
Which processing and teams fall under prior consultation
Prior consultation is triggered by a narrow outcome of the DPIA: high risk that remains after the controller's measures. The decisions below determine which operations reach that point, who must be named in the submission, and which internal teams must supply evidence before anything is filed.
Residual high risk after mitigation
Article 36(1) applies only when the DPIA shows high risk in the absence of measures, and the controller cannot reduce it. Record the residual risk separately from the inherent risk for each processing operation. A residual rating that is still high after encryption, access restriction and minimization is the trigger, so the DPIA must show which measures were modeled and why the remaining risk stays high. Confirm this threshold with legal counsel before filing.
Joint controller and processor roles
The submission must set out the responsibilities of controllers, joint controllers and processors. Map who decides purposes and means, who operates the system, and who holds sub-processors. Where a self-hosted platform runs in the client's own cloud, the client is usually the controller and the operator may be a processor under a written contract. Check that each role matches the contract text, not only the architecture diagram.
Member State prior authorisation rules
Article 36(5) allows Member State law to require controllers to consult and obtain prior authorisation for processing in the public interest, including social protection and public health. Identify whether your sector or country adds that requirement before designing the timeline. Ask the national supervisory authority or legal counsel which national rules apply, because a national authorisation can be needed in addition to the Article 36 consultation.
DPO as the authority contact
The DPO acts as the contact point for the supervisory authority on processing issues, including prior consultation under Article 39(1)(e). Confirm the DPO's contact details, which the submission must include, and make sure the DPO has reviewed the DPIA before filing. Where no DPO is designated, name the person who will receive and answer authority requests and document that role.
Security and architecture inputs
Security teams supply the measures and safeguards that the submission describes and that determine the residual rating. Collect current architecture diagrams, access models, encryption and key management details, logging coverage and backup arrangements. Each measure should map to a documented control with evidence of operation, because an authority that finds the description inaccurate can rely on its Article 58 powers.
Product and legal review of purposes
Product owners define the purposes and the data flows, and legal teams confirm the lawful basis and whether the processing is necessary. Changes to purposes, new data categories or new recipients after filing can make the submission out of date. Assign one owner to keep the purpose statement and data flow inventory synchronized with the DPIA version that is submitted.
What a prior consultation submission must contain
A prior consultation request is only as useful as the file behind it, so the controller should assemble the submission as a single pack that answers each item the authority will check. Article 36(3) lists what must accompany the request: the responsibilities of the controller, any joint controllers and any processors involved; the purposes and means of the processing; the measures and safeguards put in place to protect individuals; the contact details of the data protection officer where one is designated; the data protection impact assessment itself; and any other information the authority asks for. Missing or inconsistent items are the most common reason a request stalls, so start with a checklist that maps each element to a named owner and a source document.
The roles and means items are where engineers and compliance leads most often diverge. The compliance lead should name the controller entity and every joint controller or processor, with the contract or arrangement that allocates responsibility between them. The engineering team should describe the means in system terms: which platforms hold the data, where they run, which sub-processors and support access paths exist, and which data flows cross system boundaries. A weak submission describes purposes in general language such as improving services, or lists processors without stating what each one actually does with the data. Confirm that every system named in the DPIA appears in the description, and that the description matches current architecture rather than the design at the time of the original assessment.
The measures and safeguards item is where the submission must show that the residual risk genuinely remains high. List each technical and organizational measure, state whether it is in place, planned or assumed, and link it to the risk it reduces in the DPIA. Weak submissions list controls generically, claim measures that are not yet deployed, or omit the reasoning for why the remaining risk stays high after those controls. Keep evidence such as configuration exports, access reviews and test results ready to share if the authority asks. Finally, confirm the DPO contact details, check whether the DPO is designated for this processing, and prepare a short cover note that tells the authority which further information you can provide on request.
How a supervisory authority reviews a prior consultation request
This table walks through how a supervisory authority is likely to test a prior consultation request, step by step, from the high-risk trigger to its written advice and possible Article 58 action. Read each row as a question the authority will ask, and use the evidence column to check whether your submission would answer it without a follow-up request.
| Review step | What the authority looks for | Evidence that passes | Common findings |
|---|---|---|---|
| Trigger check | Whether the DPIA shows high residual risk after the controller's own measures, not inherent risk alone | A residual risk rating per risk with the reasoning for each rating and the measures already in place | Residual risk rated low without justification, or the request sent without any DPIA risk analysis |
| Completeness of the submission | All items listed in Article 36(3): responsibilities of controllers and processors, purposes and means, safeguards, DPO contact details, the DPIA | A submission checklist mapped to each Article 36(3) item, with the DPIA attached and the DPO named | Missing processor roles, missing DPO contact details, or a DPIA that is a draft |
| Measures test | Whether each mitigating measure would actually reduce the named risk, and whether it is operating today | Technical configuration evidence, access reviews, test results and owners for each measure | Measures described as planned, unverified or generic, with no link to a specific risk |
| Necessity and proportionality | Whether the processing purposes justify the risk and whether less intrusive options were considered | A written record of alternatives considered and why they were rejected | No alternatives recorded, or data collected beyond what the stated purpose requires |
| Consistency across the record | Whether the DPIA, record of processing, privacy notices and contracts describe the same processing | Cross-references between the DPIA and the controller's processing records and processor agreements | Contradictory descriptions of data categories, recipients or retention periods |
| Response window | Whether the authority can meet its written advice deadline | A dated submission with the controller's contact point available for questions during the review | Incomplete requests that stop the clock until the missing information arrives |
| Advice and extension | Written advice within up to eight weeks of receipt, extendable by six weeks for complex processing (Article 36(2)) | A plan for answering follow-up questions quickly so the review stays on its statutory track | Assuming processing can start on submission, or treating the review period as a fixed approval date |
| Article 58 powers | Whether processing would infringe the GDPR, and if so, which corrective or advisory powers to use | Processing that does not start until the authority's advice is received and any conditions are implemented | Processing begun before advice, leading to orders to limit, suspend or stop processing |
Preparing and filing a prior consultation request
This sequence takes a DPIA that shows high residual risk and turns it into a complete Article 36 request, with a record of who decided what, when it was sent, and how the supervisory authority's advice is put into practice.
Confirm the residual risk after mitigation
The controller, with its DPO and the business owner of the processing, re-scores each risk assuming the planned measures are in place. Article 36(1) applies only where high risk remains after those measures, so the test is the residual position, not the inherent one. The output is a residual risk register that lists each risk, the measures relied on, and the rating after mitigation. If no risk remains high, the prior consultation route does not apply and the decision should be recorded with its reasons.
Document the residual risk decision
Write a short decision record explaining why the remaining risk is high, which measures were considered and rejected, and why the controller cannot reduce the risk further. The record is signed by the accountable executive and the DPO, and the DPO's advice is noted as given. The output is a signed residual risk decision that can be produced to the authority and to internal audit. Keep it with the DPIA version it relates to.
Confirm the DPIA is current
Check that the DPIA reflects the processing as it actually runs today, including any new sub-processors, data sources, locations or features added since it was approved. Confirm the review date set in the DPIA has not passed and that any change in risk has triggered a fresh assessment. Where the DPIA is out of date, update it before filing, because the authority will assess the DPIA you submit. The output is a dated DPIA version with a change log.
Assemble the Article 36(3) submission package
Gather the items Article 36(3) requires: the responsibilities of the controller, any joint controllers and processors, the purposes and means of the processing, the measures and safeguards, the DPO's contact details, and the DPIA itself. Add any further information the authority has previously asked for in similar cases or that your national authority publishes as required. Index every document with its version and date. The output is a submission index that a reviewer can check against the Article 36(3) list in one pass.
Check Member State requirements
Article 36(5) allows Member State law to require prior consultation and prior authorisation for certain processing in the public interest, including social protection and public health. Confirm with counsel or the national supervisory authority whether your processing falls under such a rule, and whether the authority publishes its own form or process. Where the processing crosses borders, identify the lead authority and any other authorities concerned. The output is a short written confirmation of the applicable national route, filed with the submission index.
Submit the request and record the date
Send the request through the channel the relevant authority specifies, from the controller with the DPO as the named contact. Record the exact date and time of receipt confirmation, because the response period under Article 36(2) runs from receipt of the request. Keep a copy of the transmitted package as sent. The output is a submission record with the authority's acknowledgement, which is the reference point for tracking the response window.
Track the response window and any extension
Article 36(2) allows the authority up to eight weeks to give written advice, extendable by six weeks for complex processing, and the authority may notify the controller of an extension within the first period. Diary both the initial deadline and the possible extended deadline, and log every request for information from the authority with its response date. Plan internal decisions around these dates, and do not start the processing without a response unless advice has been given or the authority has not objected in the form your national law provides. The output is a tracking log of deadlines, requests and correspondence.
Implement the advice and keep the evidence
Where the authority finds the processing would infringe the GDPR, it may use any of its Article 58 powers, so the advice can require changes before processing starts. Map each piece of advice to a control change, owner and completion date, and update the DPIA and residual risk register to match. Retain the advice, the response and the evidence of implementation for later inspection. The output is a remediation tracker closed against the written advice, and a note for the DPO confirming the processing may proceed on the stated basis.
Evidence that supports a prior consultation file
A prior consultation file is only as strong as the records behind it. The six artifacts below show the supervisory authority how the controller reached its residual risk conclusion, which measures it relies on, who is accountable, and when it will act. Keep each one current between submissions, because the authority will ask for the version that matches the processing as it stands.
Residual risk decision record
This record states the high residual risk conclusion that triggers Article 36(1), the risk scenarios considered, the measures assumed in place, and who approved the decision. Write down why the risk stays high after mitigation, since that reasoning is what the authority tests first. Check that the record names the processing it covers and the date it was approved, and re-approve it whenever a measure changes.
Current DPIA
The DPIA is the document the authority reads alongside the submission, so it must match the processing described in the request. Confirm that the version attached is the latest approved one and that its risk assessment reflects the residual position. Any gap between the DPIA and the live system weakens the file and invites follow-up questions.
Measures register
A measures register links each mitigation to the specific risk it reduces, the owner, the implementation status and the evidence that proves it works. Authorities look for measures that map to named risks rather than a generic list of controls. Review the register at each change to processing, and record which measures are planned rather than live so the residual risk assumptions are honest.
Responsibilities and processor map
Article 36(3) requires the responsibilities of controllers, joint controllers and processors to be stated in the submission. Keep a current map showing which entity decides purposes and means, which processors and sub-processors handle the data, and where the contracts sit. Check the map against processor agreements and infrastructure records, since a missing sub-processor is a common reason a file is returned.
DPO contact and involvement record
The submission must include the DPO contact details, and Article 39(1)(e) makes the DPO the contact point for the authority on prior consultation. Keep a record of the DPO's review of the DPIA, the advice given, and how it was handled, with dates. Confirm that the contact details are current and that the named person can answer questions within the response window.
Response tracker
Track the date the request was received and calculate the eight-week period under Article 36(2), together with the six-week extension that applies to complex processing. Record every request for information, every reply and every extension notice from the authority. Set internal reminders well before the deadline so the controller can answer questions without pausing the processing that the file covers.
What prior consultation costs in staff time and outside help
This table breaks down who is paid for each part of a prior consultation under Article 36 and whether the cost is one-time or recurring. Read it to see which costs fall on your own staff, which you might buy in, and what to request in a scoped quote. The GDPR sets no fees, so every cost here depends on your own processing and your local market.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Internal legal and DPO time | Your own staff | One-time per submission, plus follow-up during the authority's review | Number of exchanges with the authority, completeness of the DPIA, and how many questions the authority raises |
| Engineering time to evidence mitigations | Your own engineers or a implementation partner | One-time to produce evidence, then recurring to keep it current | How many technical measures the DPIA relies on and whether logs, configurations and access records already exist |
| External review of the DPIA | Independent privacy counsel or consultant, if engaged | Usually one-time per submission | Risk complexity, novelty of the processing, and the reviewer's scope as confirmed in a written quote |
| Local counsel for Member State rules | Local lawyer in the relevant country | One-time, where Member State law requires prior authorisation | Whether national law applies to your processing, such as public interest processing under Article 36(5) |
| Joint controller and processor coordination | Your staff and partners' staff | One-time to agree responsibilities, then recurring when roles change | Number of joint controllers, processors and sub-processors that must be described in the submission |
| Updating the DPIA after authority feedback | Your staff, with counsel if engaged | Recurring while processing is designed or changed | Scale of design changes the authority requests and how often the processing itself changes |
| Ways to keep cost down | Your organization | Ongoing | Start with a complete, current DPIA, reuse existing evidence, and ask each vendor for a fixed-scope written quote covering named deliverables |
Who owns the submission, who prepares the evidence and who issues the advice
The controller carries the legal obligation under Article 36. Your organization decides whether the residual risk in a DPIA is high, decides to consult, signs the submission and answers the authority's follow-up questions. The data protection officer, where one is designated, is the contact point for the authority on processing issues, including prior consultation. The DPO's involvement is required by the GDPR, but the DPO does not replace management's accountability for the decision.
- Consultation decision: Management or the accountable business owner confirms that residual risk remains high after mitigation and authorizes the consultation.
- DPIA ownership: The team that wrote the DPIA must be able to explain every risk rating and mitigation it contains.
- DPO contact role: The DPO is named in the submission and is the authority's usual point of contact on the processing.
- Joint controller and processor input: Your team gathers the responsibilities of each party so the submission describes them accurately.
- Response tracking: Assign someone to record the request date and calendar the response window and any extension notice.
Before submitting, confirm with your legal or DPO function which national supervisory authority is competent and whether national law adds its own prior authorization requirement.
An implementation partner can prepare the systems, controls and technical evidence that a submission describes. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so the partner's work usually sits behind the measures section of the package. The partner does not decide the legal position, does not sign the submission and has no authority to issue opinions. Only the supervisory authority gives advice under Article 36.
- System preparation: Configure the hosted environment, access controls, logging and encryption that the DPIA relies on.
- Measures evidence: Produce configuration records, test results and screenshots that show each safeguard is in place.
- Technical drafting: Help write the technical section of the package, describing architecture, data flows and safeguards, for the controller to review.
- Independence limits: Where the partner also built the system, the authority may weigh that relationship, so say so in the submission.
- Scope in writing: Agree in a fixed-scope document which deliverables are technical and which legal judgments stay with your team.
Check that the partner's written scope excludes any claim that it certifies or validates compliance, and that every technical statement in the package can be traced to evidence your team holds.
The competent supervisory authority receives the request and decides whether the processing would infringe the GDPR. Under Article 36(2), it gives written advice within up to eight weeks of receiving the request. For complex processing, that period can be extended by six weeks, and the controller is informed of the extension. The authority may use any of its Article 58 powers if it considers the processing would breach the GDPR. Its advice is not a certificate, and it does not confirm that the processing is compliant.
- Written advice: The response is advice on whether the processing would infringe the GDPR, delivered in writing.
- Response window: Up to eight weeks from receipt, extendable by six weeks for complex processing.
- Enforcement powers: The authority may use its Article 58 powers, so an unfavorable view can lead to further action.
- No certification: The GDPR requires no audit, attestation or certificate, and supervisory advice does not replace the controller's own accountability.
- Independence: The authority is an independent public body, separate from both the controller and any partner.
Confirm with the authority which language, portal and format it requires, and whether it asks for information beyond the Article 36(3) list.
Common reasons prior consultation files stall
Why does a prior consultation file stall when residual risk is only asserted?
The file stalls when the controller states that residual risk is acceptable without showing how that conclusion was reached. Article 36(1) is triggered by high risk remaining after mitigation, so the supervisory authority will test whether the mitigations were scored and whether the remaining risk was measured against them. Each identified risk should have a likelihood and impact rating before measures, the measures that reduce it, and a rating after measures, with the reasoning written down. Ask your DPO or privacy lead to confirm that every residual risk marked as acceptable has a traceable rating and an owner who signed it off.
How does an out-of-date DPIA delay a prior consultation?
A DPIA that predates a material change in the processing, the systems or the data flows describes a system that no longer exists, so the authority cannot give advice on it. Before submitting, compare the DPIA against the current architecture, the current sub-processor list, the current data categories and the current retention settings. Check the dates of the last review and the change log for the systems involved. Where the processing has changed since the DPIA was written, update the assessment first and record what changed and why, because a submission built on an outdated DPIA usually returns with questions that restart the clock.
What happens when the measures in the DPIA are not actually implemented?
Described measures that are not live undermine the whole submission, because Article 36(3) asks for the measures and safeguards, and the authority will expect them to exist. Typical gaps include access reviews that are documented but not run, encryption stated as enabled on systems where it is not configured, and logging described but not retained. Before submission, verify each measure against the running system, collect the configuration output, access review records or test results that show it works, and mark any measure still in progress with a date and an owner. Your internal team or an implementation partner can prepare that evidence, but only the controller can attest that the measure is in place.
Why do missing processor or joint controller details slow down a submission?
Article 36(3) requires the file to set out the responsibilities of controllers, joint controllers and processors, so an unclear split of roles forces the authority to send questions back. Common gaps are a sub-processor that appears in the architecture but not in the contract list, a joint controller arrangement that exists in practice but has no written allocation of duties, and vague statements about who holds the encryption keys or performs support access. Build a single table listing each party, its role, the data it touches, its location and the contract or arrangement that governs it. Confirm each entry against the signed processing agreements, not against internal assumptions.
How should a team track the eight-week response period?
Teams lose time when nobody owns the response clock, so the authority's reply period starts without anyone tracking it. Under Article 36(2), the authority has up to eight weeks from receipt to give written advice, extendable by six weeks for complex processing, and it may use its Article 58 powers if it considers the processing would infringe the GDPR. Record the date the request was received, the date the extension notice arrives if one does, and the named person who answers questions during the period. Keep the DPO informed, since Article 39(1)(e) makes the DPO the contact point for prior consultation. Prepare the processing changes that may be required in parallel, so a request for changes does not stop all work.
Can a team handle the file itself, or does it need outside help?
A team can prepare the file internally, and many do, but the controller must own the decision, the DPO must be involved, and the authority responds to the controller, not to a consultant. Outside help is most useful for preparing evidence from technical systems, checking that described measures match running configurations, and building a traceable residual risk register. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside a client's infrastructure and prepares the systems and evidence used in compliance assessments. It does not write or submit the legal position for the controller and does not issue any authority decision. Engagements are fixed-scope, with the deliverables agreed in writing before work starts.
What does preparing a prior consultation file cost, and what drives it?
No supplied source gives a cost for a prior consultation file, so the reader should ask for a quote built from a written scope rather than rely on a published figure. The main cost drivers are the number of processing activities that need consultation, how many systems and sub-processors must be documented, whether the measures already exist or must be built, and how much traceable evidence is missing. Costs fall into internal staff time from the DPO, security and engineering teams, legal review, and any external support. Ask any provider to itemize the work into the DPIA update, the evidence collection, the residual risk register and the response tracking, and to state which items are one-time and which recur when processing changes.
Questions buyers ask before consulting a supervisory authority
How much effort does prior consultation take?
Prior consultation is a submission step at the end of a DPIA, so its effort depends mostly on how complete the DPIA already is. Most of the work sits in the assessment itself: describing the processing, documenting the measures already in place, and showing that high risk remains. The submission then needs the responsibilities of controllers, joint controllers and processors, the purposes and means, the measures and safeguards, the DPO's contact details, the DPIA and any other information the authority requests (Article 36(3)). Costs fall into internal time from the DPO, legal, security and engineering teams, and any outside help you choose to buy. Ask any partner for a written scope that lists which of these items they will prepare and which your staff must confirm.
How long does the supervisory authority take to respond?
The authority must give written advice within up to eight weeks of receiving the request if it considers the processing would infringe the GDPR (Article 36(2)). For complex processing, that period can be extended by six weeks, so the outer limit is fourteen weeks. The clock starts when the authority receives a complete request, so an incomplete submission can delay the start of the period in practice. Confirm the authority's own intake rules and any information it asks for before you file, because a request it cannot act on will not give you the timeline you planned around.
Can we file a prior consultation without a consultant?
Yes. The GDPR places the duty to consult on the controller, not on a consultant, so your organization can file the request itself. What decides whether it is practical is in-house capacity: someone must own the DPIA, understand the technical measures well enough to defend them, and be able to answer follow-up questions from the authority. The DPO acts as the contact point for the authority on processing issues, including prior consultation (Article 39(1)(e)), so the DPO's involvement is required in substance even if an outside firm helps with drafting. Check your national supervisory authority's guidance on the submission format before you start.
What does the work need from our DPO and engineers?
The DPO needs to own the submission and the dialogue with the authority, including the DPO contact details that must appear in the request. Engineers need to document the processing as it is actually built: data flows, where data is stored and processed, who has access, how it is encrypted and logged, and which measures reduce the risk. The gap that usually causes delay is a mismatch between the DPIA and the running system. Ask engineers to confirm each stated measure against configuration, not memory, and keep the evidence with the DPIA so answers to follow-up questions can be given quickly.
Can a partner issue the supervisory authority's advice?
No. Only the supervisory authority can give written advice under Article 36(2), and the GDPR requires no audit, attestation or certificate that an outside firm could issue in its place. A partner can help prepare the systems, the measures and the documentation the submission relies on, and can help your team answer technical questions. The controller remains responsible for the processing and for the decision to proceed. Be wary of any proposal that promises a particular outcome from the authority, since the authority decides what it considers an infringement and which Article 58 powers to use.
What can the authority do if processing would infringe the GDPR?
If the authority considers the planned processing would infringe the GDPR, it can use any of its Article 58 powers in addition to giving written advice (Article 36(2)). The practical risk is that the authority requires changes before processing starts, or uses its wider powers to stop or restrict it. Fines under Article 83 are a separate question, and the GDPR sets maximum amounts for each category of infringement. Plan for the possibility of further questions, and build time into the project for changes the authority may ask for before any high-risk processing goes live.
Does prior consultation apply to national public interest processing?
It can. Member State law may require controllers to consult the supervisory authority and obtain prior authorisation for processing in the public interest, including social protection and public health (Article 36(5)). If your processing falls under such a national rule, the requirement may apply in addition to the high-risk trigger in Article 36(1). Confirm with your national authority or legal counsel which national rules apply to your sector and location before you plan the timeline.
How DeployOpen prepares systems and evidence for prior consultation
DeployOpen prepares the technical inputs for a prior consultation submission, but it does not decide, file or answer for the controller. An engagement is fixed in scope: the parties agree in writing which self-hosted platforms, which processing measures and which documents are covered, and which deliverables will be handed over. A quote follows from that written scope. Typical technical inputs include a description of the hosting architecture inside the client's own cloud accounts, data centers or air-gapped networks, the access control and logging configuration for the processing platform, encryption and key management設定, backup and restore arrangements, and the mitigating measures the DPIA relies on. Each measure should be paired with the configuration evidence that shows it is actually in place.
Before any engagement starts, the controller should confirm what the supervisory authority will expect in the submission, including the responsibilities of joint controllers and processors, the DPO contact details and the DPIA itself. Ask the implementation partner which of those items it will prepare, which remain the controller's own work, and who signs off the residual risk position. Also confirm that any Member State requirement for prior authorisation for public interest processing has been checked with the national authority or local counsel, since Article 36(5) leaves that step to national law.
The controller owns the decision to consult, the wording of the submission and the filing. DeployOpen does not issue opinions, and it does not predict or influence how the supervisory authority will respond. The authority alone gives written advice within the response period set by Article 36(2), and that advice may be extended. Plan for that waiting period in the project timeline, and ask any partner to state in writing which inputs they will deliver, in what format and by what date, so the controller can file on time.
