Article 35: Data protection impact assessment

Article 35 requires you, as a GDPR controller, to complete and document a Data Protection Impact Assessment (DPIA) before starting any processing that is likely to create a high risk to individuals’ rights and freedoms, especially when using new technologies. Operationalize it by building a DPIA trigger workflow, running a standardized assessment, recording decisions, and retaining an auditable evidence packet. (Regulation (EU) 2016/679, Article 35)

Key takeaways:

• DPIA is a pre-processing requirement for controllers when processing is likely to be high risk. (Regulation (EU) 2016/679, Article 35)
• Treat DPIA as an intake gate tied to change management, product launches, and new data uses, not a policy-only activity.
• Your audit defense depends on evidence: scope/role decisions, assessment outputs, approvals, and tracked remediation.

A DPIA program fails most often for one reason: nobody can tell you, with evidence, which processing changes must trigger a DPIA and who is accountable for completing it before go-live. Article 35 is narrow in wording but broad in operational impact because it forces you to identify “types of processing” that are likely to result in a high risk, and to assess impact “prior to the processing.” (Regulation (EU) 2016/679, Article 35)

For a CCO, privacy lead, or GRC owner, the fastest path is to turn Article 35 into an intake-and-approval control that sits in front of production processing. Build a consistent DPIA template, define “high-risk” triggers in plain language your engineering and product teams can apply, and require documented sign-off before launch. Store the record so you can show a regulator, customer, or auditor what you considered, what you decided, and what you changed.

This page focuses on requirement-level implementation guidance for the article 35: data protection impact assessment requirement, with steps, artifacts, and exam-style questions you can use immediately.

Regulatory text

What the law says (excerpt): Where processing, particularly using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, the controller must, prior to the processing, carry out an assessment of the impact of the envisaged processing on the protection of personal data; one assessment may cover similar processing operations with similar high risks. (Regulation (EU) 2016/679, Article 35)

Operator interpretation (what you must do):

1. Decide whether you are acting as a controller for the processing at issue. Article 35’s explicit duty in the excerpt is on the controller. (Regulation (EU) 2016/679, Article 35)
2. Identify processing that is “likely to result in a high risk.” You need a repeatable, documented method for making this determination. (Regulation (EU) 2016/679, Article 35)
3. Complete the DPIA before processing begins. Treat it as a gate to production, not a retrospective document. (Regulation (EU) 2016/679, Article 35)
4. Use a single DPIA for sets of similar processing when the risk profile is similar, to avoid duplicative work while staying defensible. (Regulation (EU) 2016/679, Article 35)

Plain-English requirement: what Article 35 expects in practice

If a new or changed data processing activity could meaningfully harm people (privacy intrusion, loss of control, discrimination, chilling effects, security exposure), you must pause before launch and document a structured risk assessment and the mitigations you will apply. The deliverable is not only the DPIA write-up; it is the operational discipline that prevents “high-risk by default” processing from going live without review. (Regulation (EU) 2016/679, Article 35)

Who it applies to (entity and operational context)

Applies to:

• Controllers conducting GDPR-scoped personal data processing where the processing type is likely to be high risk, including scenarios involving new technologies. (Regulation (EU) 2016/679, Article 35)

Common operational contexts that should be wired to DPIA intake:

• New product features that change how personal data is collected, inferred, or shared.
• New analytics, profiling, monitoring, or identity resolution uses.
• New data sources or new recipients (including third parties) for existing data.
• New systems, vendors, or architectures that materially change confidentiality, access, retention, or transfer paths.

You do not need to guess perfectly on day one. You do need a documented, consistently followed method to decide when a DPIA is required and to prove the DPIA occurred before launch. (Regulation (EU) 2016/679, Article 35)

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

Step 1: Create a role-and-scope register (foundation control)

Maintain a register that, for each processing activity in scope, records:

• Controller vs processor role (and if mixed, which parts are controller activities)
• Processing purpose
• Personal data categories (including any special sensitivity your organization tracks)
• Affected systems and key third parties
• Owner (product + engineering) and compliance approver

This register prevents the most common failure mode: teams arguing about ownership after launch, when “prior to the processing” can no longer be met. (Regulation (EU) 2016/679, Article 35)

Step 2: Define DPIA trigger events and embed them in intake workflows

Write a short operating procedure that answers two questions:

• What events trigger a DPIA review?
• Who must approve before go-live?

Practical trigger design that works:

• Tie triggers to change management (new system, new data flow, new vendor, new purpose).
• Tie triggers to product development (PRD approval, security architecture review, launch checklist).
• Tie triggers to procurement (new third party that touches personal data).

Make the trigger mechanism concrete: a ticket type in your GRC tool, a required field in an intake form, or a mandatory checkbox in the launch template that opens a DPIA task.

Step 3: Run a standardized DPIA and document the decision

Your DPIA template should force specificity. At minimum, capture:

• Description of envisaged processing (what data, where from, where to)
• Nature/scope/context/purpose (use the same headings so reviews are consistent)
• Why the processing is likely (or not likely) to be high risk
• Key risks to rights and freedoms (write these as “harm statements”)
• Existing controls and planned mitigations
• Residual risk decision and rationale
• Go/no-go decision and conditions for launch

Avoid essays. Auditors want traceability: risk identified → control mapped → decision recorded.

Step 4: Approvals, gating, and “prior to processing” proof

Operationalize “prior to the processing” as an enforcement point:

• Do not allow production enablement until the DPIA task is approved.
• If your SDLC supports it, require DPIA sign-off before feature flags are enabled or data pipelines are scheduled.

Evidence matters more than intent. A completed DPIA dated after launch reads like an after-the-fact justification. (Regulation (EU) 2016/679, Article 35)

Step 5: Group similar processing into a single DPIA where defensible

Article 35 explicitly permits one assessment for “a set of similar processing operations” with “similar high risks.” (Regulation (EU) 2016/679, Article 35) Use a grouping rule such as:

• Same purpose + same data categories + same data subjects + same primary systems + same sharing model.

Document the grouping rationale. If one member of the group changes, require a delta review.

Step 6: Remediation tracking and re-assessment triggers

A DPIA is only credible if mitigations are implemented and tracked.

• Create action items with owners and due dates in your normal risk register or ticketing system.
• Add a re-assessment trigger when mitigations slip, scope expands, or a new third party is introduced.

Step 7: Make DPIA execution auditable (evidence packet discipline)

For each DPIA, retain a single “evidence packet” with:

• Intake record showing the trigger event and initial scoping
• Completed DPIA template
• Approval record (names, roles, dates)
• Linked architectural diagrams / data flow diagrams (as applicable)
• Control mapping (security, privacy, retention, access)
• Remediation tickets and closure evidence
• Exception/waiver record if you approved launch with residual risk

Daydream (and similar GRC workflows) is a practical fit here because it can standardize the intake form, route approvals, and preserve the evidence packet as a single record that survives org churn.

Required evidence and artifacts to retain

Use this checklist for audit readiness:

• Role-and-scope register entry for the processing activity (controller/processor, data categories, systems)
• DPIA trigger log (what triggered review and when)
• DPIA report (completed template with risk and mitigation)
• Decision record (approved/denied/approved with conditions)
• Implementation proof for mitigations (tickets, configurations, test results, training where relevant)
• Grouping rationale if one DPIA covers multiple similar operations (Regulation (EU) 2016/679, Article 35)
• Version history showing updates when processing changes

Retention period is a governance decision, but you should keep records long enough to respond to regulator inquiries and customer diligence for active and recently changed processing.

Common exam/audit questions and hangups

Expect these questions in audits, customer questionnaires, and supervisory authority engagement:

• “Show me your criteria for when a DPIA is required and evidence it ran prior to launch.” (Regulation (EU) 2016/679, Article 35)
• “List all DPIAs completed in the last cycle, and show which production systems they cover.”
• “How do you prove product teams cannot bypass DPIA gating?”
• “How do you handle similar processing operations under a single DPIA, and what’s your rule for ‘similar high risks’?” (Regulation (EU) 2016/679, Article 35)
• “Who signs off, and what happens when residual risk remains?”

Hangup to plan for: Engineering teams often treat DPIA as a privacy-only artifact. You need security, product, and data owners accountable for mitigations.

Frequent implementation mistakes and how to avoid them

Mistake: DPIA exists only as a policy statement.
Fix: Put the trigger into the workflows people already use (SDLC, procurement, change management), and require sign-off before production.

Mistake: No role clarity (controller vs processor).
Fix: Maintain a role-and-scope register entry per processing activity and require it as a prerequisite to DPIA initiation.

Mistake: DPIA written as narrative with no control traceability.
Fix: Use a template that forces “risk → mitigation → owner → evidence” fields.

Mistake: DPIA completed after go-live.
Fix: Add gating: the launch checklist must link to an approved DPIA record dated before enablement. (Regulation (EU) 2016/679, Article 35)

Mistake: Treating “single DPIA for similar processing” as a shortcut without documentation.
Fix: Record why operations are similar and what would trigger a split or update. (Regulation (EU) 2016/679, Article 35)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not summarize specific decisions or penalties.

From a risk standpoint, the exposure is predictable: if a high-risk processing activity causes harm or triggers complaints, regulators and customers often ask for proof that you assessed and mitigated risks before processing began. Article 35’s “prior to the processing” timing requirement makes weak governance easy to spot. (Regulation (EU) 2016/679, Article 35)

Practical execution plan (30/60/90-day)

The plan below avoids fixed day counts beyond the requested structure and focuses on deliverables you can verify internally.

First 30 days (establish control ownership and minimum viable workflow)

• Name an accountable owner for DPIA operations (privacy/GRC) and a required approver set (product, security, legal as needed).
• Stand up a role-and-scope register for in-scope processing activities, starting with highest-risk systems and customer-facing products.
• Publish a DPIA operating procedure with trigger events and a mandatory “no approval, no launch” rule. (Regulation (EU) 2016/679, Article 35)
• Deploy a DPIA template and evidence packet structure (single folder/record per DPIA with required fields).

Days 31–60 (embed and scale)

• Integrate DPIA triggers into SDLC intake (PRD template), change management, and procurement workflows.
• Run DPIA tabletop sessions with product and engineering to calibrate what “likely high risk” means in your environment. (Regulation (EU) 2016/679, Article 35)
• Complete DPIAs for the active backlog of high-change or novel processing areas, and track mitigations to closure.

Days 61–90 (audit-ready hardening)

• Add quality checks: periodic review for missing approvals, late DPIAs, and incomplete mitigation evidence.
• Define grouping rules for “similar processing operations” and standardize when you can reuse a DPIA. (Regulation (EU) 2016/679, Article 35)
• Produce an audit pack: register extract, DPIA list, sample evidence packets, and proof of gating from your workflow tool (Daydream or equivalent).

Frequently Asked Questions

Do we need a DPIA for every processing activity?

Article 35 ties DPIAs to processing that is likely to result in a high risk to individuals’ rights and freedoms, especially with new technologies. You should operationalize this with clear triggers so teams can consistently decide when a DPIA is required. (Regulation (EU) 2016/679, Article 35)

Who is responsible for performing the DPIA?

The explicit obligation in the excerpt sits with the controller, so assign internal accountability accordingly. In practice, privacy/GRC coordinates, while product, engineering, and security provide the system detail and commit to mitigations. (Regulation (EU) 2016/679, Article 35)

What proves we did the DPIA “prior to the processing”?

Use dated approvals tied to a launch gate (release ticket, change record, feature flag approval) and retain the evidence packet. The DPIA record must show completion and sign-off before production enablement. (Regulation (EU) 2016/679, Article 35)

Can one DPIA cover multiple products or features?

Yes, Article 35 allows a single assessment for a set of similar processing operations that present similar high risks. Document your similarity criteria and keep a change trigger that forces a delta review when one member changes materially. (Regulation (EU) 2016/679, Article 35)

What’s the minimum content a DPIA must include?

The excerpt requires an “assessment of the impact” of the envisaged processing on personal data protection, completed before processing begins. Use a template that documents processing description, risk to rights and freedoms, mitigations, residual risk decision, and approvals. (Regulation (EU) 2016/679, Article 35)

How do we operationalize DPIA with third parties (vendors) involved?

Add procurement triggers for any third party that will access, host, or receive personal data, and require DPIA review when the third party changes the nature/scope/context/purpose or the security posture of the processing. Keep the third party and affected systems listed in the DPIA evidence packet. (Regulation (EU) 2016/679, Article 35)