Article 35: Data protection impact assessment

Article 35 requires you, as a GDPR controller, to complete 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. Operationally, you need a repeatable intake-and-screening gate, a DPIA method, documented approvals, and retained evidence showing risk is assessed and addressed. ¹

Key takeaways:

• You must run the DPIA prior to processing when the planned activity is likely high risk. ¹
• Build a DPIA “front door”: triggers, owners, required inputs, and stop/go approvals tied to change delivery.
• Keep an audit-ready packet: decision record, DPIA, sign-offs, exceptions, and remediation tracking.

Article 35 is one of the GDPR requirements that regulators and enterprise customers use as a proxy for whether privacy risk management is real, or just a policy statement. The rule is simple in concept: if a planned processing activity is likely to result in high risk to people, you assess the impact before you start. ¹

For a CCO or GRC lead, the work is less about writing a “DPIA template” and more about making DPIAs unavoidable in the operational paths that create risk: new products, new data uses, new integrations with third parties, migrations to new platforms, and any material change to purpose, scope, or context. The fastest path to defensible compliance is to treat the DPIA as a gated control inside your delivery lifecycle (product, engineering, security, procurement), with clear ownership and a short list of required artifacts.

This page translates Article 35 into an implementation playbook you can stand up quickly: who must do it, what triggers it, how to run it step-by-step, what evidence to keep, what auditors ask for, and the failure modes that commonly break DPIA programs.

Regulatory text

Requirement (excerpt): Where processing, particularly using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons (considering the nature, scope, context, and purposes), the controller must, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on personal data protection. One assessment may cover similar operations presenting similar high risks. ¹

Operator translation (what you must do):

1. Decide your role per processing activity (controller vs. processor) so you know whether Article 35’s “controller shall” obligation attaches to you for that activity.
2. Identify “likely high-risk” processing before it goes live using an intake and screening step embedded in delivery/change processes.
3. Perform and document a DPIA before launch for in-scope processing, and use one DPIA for a set of similar processing operations where appropriate. ¹
4. Retain evidence that the DPIA happened pre-processing and drove risk treatment decisions.

Plain-English interpretation (requirement-level)

A DPIA is your documented analysis of how a planned processing activity could harm individuals (privacy, rights, freedoms) and what you will do about it. Article 35 is triggered by likelihood of high risk, not by whether you have already had an incident. The “prior to processing” clause is the exam pivot: a DPIA written after launch reads like retroactive justification, not risk management. ¹

Who it applies to (entity and operational context)

Applies to:

• Controllers conducting personal data processing that is likely to be high risk, especially where new technologies are involved. ¹

Operational contexts that commonly trigger Article 35 (practical, not exhaustive):

• New product features that materially change purpose (why you process) or context (relationship/expectations of individuals).
• New data types, new user populations, or materially increased scale (scope) that changes exposure.
• New third party data flows (e.g., analytics, advertising tech, fraud tooling, identity providers, customer support platforms).
• New automated decisioning or monitoring capabilities introduced through “new technologies” or novel use patterns. ¹

Role clarity is a control prerequisite. Many DPIA programs fail because teams cannot answer: “Are we the controller for this processing, a processor, or both depending on the step?” Fix that first with a role-and-scope register, then tie DPIA triggers to the register entries.

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

Step 1: Stand up a role-and-scope register for DPIA coverage

Create a living register that maps each processing activity to:

• Controller/processor role (and if mixed, which parts)
• Purpose(s) of processing
• Data categories and affected populations
• Systems/applications and data stores
• Third parties receiving/processing the data
• Owner (business) and accountable approver (risk)
  This register becomes your DPIA inventory anchor and reduces “we didn’t realize” gaps.

Step 2: Define DPIA trigger criteria and embed them in intake gates

Operationalize “likely high risk” by implementing mandatory DPIA screening questions in the workflows that create processing:

• Product requirements intake
• Architecture/security review
• Procurement/third party onboarding
• Data governance requests (new dataset access, new joins, new exports)

Control design tip: Don’t ask teams to self-diagnose “high risk” in the abstract. Ask factual questions that map to nature/scope/context/purpose and “new technologies,” then route to privacy review when thresholds are met. ¹

Step 3: Create a DPIA operating procedure with named owners and stop/go authority

Document, in a short SOP:

• Who can initiate a DPIA (product, engineering, procurement)
• Who leads it (privacy office/DPO function or delegated privacy champions)
• Who must approve before launch (e.g., DPO/privacy lead + business owner; security sign-off when controls are involved)
• What happens if approval is not granted (block release, require exception sign-off, or escalate)

Tie this SOP to your release management or change advisory process so “prior to processing” is enforced by workflow, not by reminders. ¹

Step 4: Execute the DPIA with a consistent structure

Use a DPIA template that forces completeness and produces auditable reasoning. Minimum sections to include:

• Description of the envisaged processing (what, why, how, where)
• Nature/scope/context/purpose analysis (explicitly stated)
• Risk identification to rights/freedoms (scenarios, not just categories)
• Existing and planned controls (technical/organizational)
• Residual risk statement and decision (approve, approve with conditions, reject, or redesign)
• Linkage to third party risk controls where processing is outsourced/shared

Practical example (what “good” looks like): A DPIA that cites the exact system, data elements, recipients, retention, and purpose change, then lists specific mitigations (access controls, logging, minimization, contractual restrictions with third parties) with owners and due dates.

Step 5: Make “one DPIA for similar processing” safe and defensible

Article 35 allows a single DPIA to cover similar high-risk operations. ¹ Treat this as a controlled aggregation:

• Define the “processing family” boundaries (same purpose, similar data, similar affected group, similar technology, similar recipients)
• Track deviations as “delta assessments” so teams update the DPIA when similarity breaks
• Version-control the DPIA and link each deployment/use case to the governing DPIA

Step 6: Track remediation and keep DPIA outputs alive

A DPIA that identifies mitigations but never tracks delivery becomes an audit finding. Add:

• A remediation tracker (ticketing integration is ideal) with owners and due dates
• A mechanism to re-open the DPIA when the processing changes (new third party, new purpose, new dataset, new model)

Step 7: Implement evidence retention and retrieval (audit-readiness)

Define where DPIAs live (single repository) and enforce required attachments at closure:

• Screening record (why triggered / why not)
• Final DPIA document
• Approvals/signatures
• Exception approvals (if any)
• Remediation evidence and closure notes

Daydream fit (earned, practical): If you run DPIAs across many products and third parties, Daydream can act as the system of record for the role-and-scope register, DPIA workflow, required evidence packets, and recurring control outputs. That reduces “lost DPIAs” and makes customer diligence faster because you can produce a consistent packet on demand.

Required evidence and artifacts to retain

Keep an “Article 35 evidence packet” per in-scope processing activity:

• Role-and-scope entry (controller/processor decision, data categories, systems, third parties)
• DPIA screening outcome (triggered/not triggered) with rationale
• DPIA report (final, versioned)
• Approval record showing DPIA completion prior to processing and who signed off ¹
• Risk treatment plan (mitigations, owners, due dates)
• Exception documentation if launched with unresolved risk, including compensating controls and time-bound plan
• Change log linking later material changes back to DPIA update decisions

Common exam/audit questions and hangups

Expect these questions from regulators, internal audit, or enterprise customers:

• “Show the DPIA for this processing activity and prove it was completed before go-live.” ¹
• “What triggers a DPIA here, and how do you ensure teams follow it?”
• “How do you decide controller vs. processor per processing step?”
• “Do third party integrations trigger DPIAs, and where is that decision recorded?”
• “How do you handle similar processing under one DPIA, and how do you track drift?”
• “Where are remediation actions tracked, and who is accountable?”

Hangup to anticipate: teams submit a DPIA as a document but cannot show operational enforcement (no workflow gate, no approvals, no inventory, no linkage to changes).

Frequent implementation mistakes (and how to avoid them)

1. DPIAs done after launch. Fix: make DPIA approval a release/procurement gate. “Prior to processing” is a timing requirement, not a preference. ¹
2. No role clarity. Fix: maintain a role-and-scope register and require it before DPIA initiation.
3. Trigger criteria too vague. Fix: use screening questions tied to nature/scope/context/purpose and new technologies; route edge cases to privacy for decision. ¹
4. DPIAs don’t drive mitigations. Fix: require a risk treatment plan with owners, and track closure.
5. “One DPIA for all” overreach. Fix: define similarity boundaries and require delta reviews when anything material changes. ¹
6. Evidence scattered across email and chat. Fix: single repository, required attachments, version control.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this section is intentionally limited to requirement implications. Article 35 is a pre-processing risk control. If you cannot demonstrate that you identified high-risk processing and assessed it before launch, you create regulatory exposure and weaken your position in investigations, complaints, and customer audits. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Assign accountable owner for DPIA operations (privacy office/DPO function) and backup.
• Publish DPIA SOP: triggers, roles, approvals, repository, and “no approval, no launch” rule. ¹
• Implement DPIA screening in at least one high-throughput gate (product intake or security architecture review).
• Create the role-and-scope register and populate it for your highest-risk products and data flows.

Days 31–60 (make it repeatable across the business)

• Expand screening to procurement and third party onboarding.
• Standardize the DPIA template and approval workflow; train product/security/procurement on how to submit complete inputs.
• Build the evidence packet checklist and require it before closing a DPIA.
• Establish remediation tracking with clear ownership (privacy, security, engineering).

Days 61–90 (make it auditable and durable)

• Run an internal audit-style review of a sample of recent changes: confirm DPIA timing, completeness, approvals, and mitigation closure. ¹
• Implement “similar processing” governance: processing families, delta assessments, versioning.
• Add monitoring triggers for material change events (new third party, new purpose, new dataset, major platform migration) to re-open DPIAs.
• Consider centralizing the program in Daydream to keep the register, workflow, and evidence retrieval consistent as volume grows.

Frequently Asked Questions

Do we need a DPIA for every new feature?

No. You need a DPIA before processing that is likely to result in high risk to individuals’ rights and freedoms, especially with new technologies. Use a screening gate to decide consistently and document the rationale. ¹

What does “prior to the processing” mean operationally?

Treat it as a hard gate before go-live or before the new processing purpose starts. Your evidence should show the DPIA approval date precedes deployment or enablement of the processing. ¹

Can one DPIA cover multiple products or workflows?

Yes, if they are similar processing operations presenting similar high risks. Define what “similar” means for your environment and require delta reviews when the purpose, data, technology, or recipients differ. ¹

We’re usually a processor. Do we still do DPIAs?

Article 35 assigns the obligation to the controller. In practice, many processors support controllers with information, drafts, or risk input, but you should first document your role per processing activity in a role-and-scope register. ¹

What’s the minimum evidence auditors ask for?

A DPIA document, a trigger/decision record, and proof of approval before launch are the core items. Add remediation tracking and closure evidence if the DPIA identified actions. ¹

How do we handle third parties in a DPIA?

Include the third party data flow in the processing description, identify risks introduced by sharing or outsourcing, and document the controls you require (technical and contractual). Link the DPIA to your third party due diligence and onboarding approvals.

Footnotes

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