A concrete workflow for deciding whether a is required, completing the Article 35 assessment, and escalating only when residual high risk triggers Article 36 prior consultation.
Use it for new or materially changed processing that may affect individuals through profiling, large-scale sensitive data, systematic monitoring, vulnerable groups, combined datasets, new technology, or difficult-to-avoid services.
Use one operating record for GDPR Articles 35 and 36: screen the processing before launch, complete the , obtain DPO advice where a DPO is designated, choose and verify measures, reassess residual high risk, and prepare prior consultation when the remaining risk cannot be sufficiently mitigated.
1
Section 1
1. Screen whether Article 35 requires a DPIA
Start before the processing begins or before a material change is released. Record the processing operation, controller role, purposes, data categories, affected people, systems, suppliers, recipients, storage periods, and countries involved.
A is required where the nature, scope, context, and purposes of processing, especially when using new technologies, are likely to create high risk for natural persons. Treat the screening as a written decision: either open a DPIA, rely on a single assessment covering a set of similar operations with similar high risks, or document why the threshold is not met. Check the competent supervisory authority's published Article 35(4) list of processing that requires a DPIA and any Article 35(5) list of processing for which a DPIA is not required.
Article 35(10) can remove the Article 35(1)-(7) duty where processing under Article 6(1)(c) or (e) has a legal basis in Union or Member State law, that law regulates the specific processing operation or set of operations, and a general impact assessment was already performed when that legal basis was adopted. The exception does not apply where Member State law requires a DPIA before processing.
Automatic Article 35(3) checks: systematic and extensive automated evaluation or profiling with legal or similarly significant effects; large-scale special-category or criminal-offence data; large-scale systematic monitoring of a publicly accessible area.
Additional high-risk indicators from DPC/WP29 guidance: evaluation or scoring, automated decisions with legal or similarly significant effects, systematic monitoring, sensitive or highly personal data, large-scale processing, matched or combined datasets, vulnerable data subjects, innovative technology, or processing that prevents people from exercising a right or using a service.
Large-scale assessment evidence: number or proportion of data subjects, volume and variety of data, duration or permanence of processing, and geographic extent.
Treat two indicators as a strong rule-of-thumb signal rather than a substitute for Article 35's likely-high-risk test: some operations may require a with one indicator, while a reasoned decision may conclude that a combination does not create likely high risk.
Check non-EU transfers separately under Chapter V and as part of the processing context; a transfer is not itself one of the nine WP29 screening indicators.
If indicators are present but the team decides not to run a , record the reasons, approver, DPO advice where designated, competent-authority list checked, and the facts that would reopen the screening.
DPC guidance expands the screening criteria, including scoring, monitoring, sensitive data, scale, vulnerable groups, combined datasets, new technology, transfers, and unavoidable service access.
the more criteria are met
2
Section 2
2. Build the DPIA record around Article 35 content
Tie the to the processing operation and keep enough detail for an auditor, DPO, or supervisory authority to understand the decision without reconstructing the project history. A generic privacy memo does not supply that project record.
Use the CNIL structure to keep the assessment complete: context, fundamental principles, security risks, and validation. Use the DPC template prompts to capture scope, consultation, necessity and proportionality, risks, mitigation, residual risk, sign-off, and review ownership.
Context: describe the processing operations, purposes, controller and processor roles, data subjects, data categories, recipients, storage durations, data flows, supporting assets, applicable standards, and intended benefits.
Necessity and proportionality: explain lawful basis, purpose limitation, data minimisation, accuracy, retention, transparency, rights handling, processor arrangements, and international-transfer safeguards.
Consultation evidence: document DPO advice where a DPO is designated, processor input where processors support the processing, internal stakeholder input, and data-subject or representative views where appropriate.
Data-subject views: define whose views would be relevant, how they were sought, what changed as a result, or why seeking them was not appropriate because it would prejudice commercial or public interests or the security of processing.
Risk assessment: write each risk as a cause, event, and consequence for affected people; estimate severity and likelihood before and after measures, and distinguish confidentiality, integrity, availability, fairness, discrimination, loss of control, financial, physical, reputational, and distress impacts where relevant.
Decision trace: link each material fact, assumption, stakeholder view, risk rating, measure, acceptance, and approval to a dated owner and the version of the processing design assessed.
CNIL structures a PIA around context, fundamental principles, data-security risks, and formal validation, with templates for data flows, controls, risk mapping, action plans, advice, stakeholder views, and approval.
define and describe the context of the processing of personal data under consideration
3
Section 3
3. Choose measures and reassess residual risk
For each identified risk, record the initial likelihood and severity, the specific measure proposed, the owner, the expected effect on risk, and the residual risk after the measure. Do not close the on a list of broad controls without showing which individual risk each measure reduces.
Measures can change the processing design as well as the security layer. If a risk is created by unnecessary data, avoid it by removing the data. If the risk comes from access, retention, supplier handling, user information, or international transfer, the measure should address that exact cause.
Possible design measures: remove a data category, shorten retention, narrow recipients, avoid a combined dataset, drop an automated-decision feature, or let people use the service without the high-risk processing where feasible.
Possible governance measures: improve privacy notices, rights workflows, processor contracts, transfer controls, staff training, approval gates, incident handling, and evidence retention.
Possible security measures: access control, encryption, pseudonymisation, anonymisation where suitable, logging, backup, partitioning, vulnerability management, and operational controls around supporting assets.
Verification evidence: record configuration, test, review, contract, training, or monitoring proof showing that each claimed measure exists and works for the processing operation assessed.
Risk decision: record avoided, reduced, transferred, or accepted risk separately; contractual allocation can change responsibility between parties but does not transfer away the impact on the data subject.
Record accepted residual risks explicitly. If a residual high risk remains after measures, do not treat management acceptance as a substitute for Article 36 consultation.
DPC guidance describes identifying solutions, recording accepted risks, and using a risk register to track likelihood, impact, measures, and residual risk.
CNIL recommends mapping initial and residual risks by severity and likelihood and preparing an action plan with responsible persons, cost, and timeframe.
ENISA provides supporting security-control context for selecting technical and organisational measures for personal-data processing.
Security of Personal Data Processing
4
Section 4
4. Trigger prior consultation only for unmitigated high risk
Article 36 prior consultation is required when the indicates that the processing would result in high risk without measures that sufficiently mitigate it. Requiring a DPIA does not by itself trigger consultation.
Before consulting, assemble the package Article 36 expects and verify the competent authority's filing procedure. The intended processing should remain on hold while consultation is pending because Article 36 requires consultation before processing.
Consultation trigger: the controller has completed the , designed and assessed measures, and high risk still remains because the risk has not been sufficiently reduced, identified, or mitigated.
Consultation package: controller, joint-controller, and processor responsibilities; purposes and means; safeguards and measures; DPO contact details where applicable; the ; and any further information the authority requests.
Filing control: identify the competent supervisory authority, current filing route, controller signatory, submission version, secure attachments, confidential material, submission timestamp, and authority acknowledgement.
GDPR response period: if the supervisory authority is of the opinion that the intended processing would infringe the GDPR, it provides written advice within up to eight weeks of receiving the request, may extend by six weeks for complexity, and may suspend the period while waiting for requested information; keep internal launch planning separate from that statutory authority timetable.
Authority outcome: record advice, requested design changes, information requests, deadlines, and any Article 58 power used; update the and obtain a new launch decision rather than treating submission as approval.
Verify the competent authority's forms, portal, fees if applicable, confidentiality arrangements, and submission instructions before filing.
DPC guidance states that consultation is required when identified risks cannot be managed and residual risk remains high.
consult with the Data Protection Commissioner
5
Section 5
5. Evidence checklist for closing or reopening the workflow
Close the workflow only when the screening decision, contents, measures, residual-risk decision, and consultation assessment are all traceable to the same processing operation. If the product, data, threat environment, provider model, or affected population changes, reopen the screen and decide whether the DPIA needs review.
Keep the evidence concise but durable. The goal is to prove the controller knew the risks, selected measures, considered affected people and DPO advice where required, and escalated when Article 36 required it.
Screening record: Article 35(3) checks, DPC/WP29 high-risk indicators, national list checked where applicable, and reason for DPIA/no-DPIA decision.
record: processing description, purposes, necessity and proportionality assessment, stakeholder views, data-subject views or reason not sought, DPO advice, risk register, measures, residual-risk map, and sign-off.
Implementation proof: completed action plan, system changes, retention settings, access rules, processor evidence, notices, rights workflows, transfer safeguards, training, and security-control verification.
Prior-consultation record: trigger decision, competent authority, submitted package and version, correspondence, suspended-period information requests, written advice, project response, and final pre-processing approval.
Reopen triggers: new technology, new purpose, changed dataset or matching logic, expanded scale or geography, new vulnerable population, changed transfer destination, new threat or vulnerability, incident findings, or residual-risk measures that did not work.
Official guidance for practical DPIA screening criteria, project roles, records, mitigation, residual high risk, and the DPC consultation trigger.
DPC guidance expands the screening criteria, including scoring, monitoring, sensitive data, scale, vulnerable groups, combined datasets, new technology, transfers, and unavoidable service access.
DPC guidance describes identifying solutions, recording accepted risks, and using a risk register to track likelihood, impact, measures, and residual risk.
Show 2 more
DPC guidance states that consultation is required when identified risks cannot be managed and residual risk remains high.
DPC guidance emphasises good record keeping, integration of DPIA outcomes into project plans, and review when processing changes.
"DPIAs will be mandatory for any new high risk processing projects"
CNIL recommends mapping initial and residual risks by severity and likelihood and preparing an action plan with responsible persons, cost, and timeframe.
CNIL describes the PIA as a continuous improvement process updated when significant change occurs.
Official guidance for the four-part PIA method and its practical templates, including processing context, data flows, controls, risk mapping, action plans, advice, stakeholder views, and validation.
CNIL structures a PIA around context, fundamental principles, data-security risks, and formal validation, with templates for data flows, controls, risk mapping, action plans, advice, stakeholder views, and approval.
"define and describe the context of the processing of personal data under consideration"