Article 38: Position of the data protection officer

GDPR Article 38 requires you, as a controller or processor, to ensure the Data Protection Officer (DPO) is involved properly and in a timely way in all issues relating to personal data protection. To operationalize it, build mandatory “DPO touchpoints” into intake and change workflows (projects, vendors, DPIAs, incidents), then retain evidence that the DPO was consulted early enough to influence outcomes. (Regulation (EU) 2016/679, Article 38)

Key takeaways:

• Embed DPO engagement into your operating workflows, not just policy language. (Regulation (EU) 2016/679, Article 38)
• Define triggers for “all issues” and require documented DPO input before decisions are locked. (Regulation (EU) 2016/679, Article 38)
• Keep an audit-ready evidence trail showing timely involvement across projects, third parties, and incidents. (Regulation (EU) 2016/679, Article 38)

Article 38 is a requirement about execution discipline: the DPO must be brought into the work early, consistently, and with enough context to give meaningful guidance. The fastest way to fail Article 38 is to appoint a DPO “on paper” and then route privacy-impacting decisions around them until the end of a project, after a contract is signed, or once an incident has already forced a rushed response. (Regulation (EU) 2016/679, Article 38)

For a CCO or GRC lead, the operational question is simple: where do privacy-impacting decisions get made, and how do you prove the DPO was involved before those decisions became expensive to change? This page translates the legal requirement into repeatable control steps, evidence artifacts, and audit questions you can expect from regulators, customers, or internal assurance.

The practical outcome you want is a set of workflow gates and records that show: (1) the organization knows what “issues relating to personal data protection” means in its context, (2) the DPO is automatically pulled into those issues, and (3) leadership sees and respects DPO input as part of normal governance. (Regulation (EU) 2016/679, Article 38)

Regulatory text

Text (excerpt): “The controller and the processor shall ensure that the data protection officer is involved, properly and in a timely manner, in all issues which relate to the protection of personal data.” (Regulation (EU) 2016/679, Article 38)

Operator interpretation: You must design your governance so the DPO is not optional, not last-minute, and not bypassed. “Ensure” means you need mechanisms (workflow gates, required fields, approvals, meeting cadences, escalation paths) that cause DPO involvement to happen reliably, plus records that prove it happened. (Regulation (EU) 2016/679, Article 38)

What “properly and in a timely manner” means in practice:

• Properly: The DPO receives relevant context (purpose, data categories, systems, recipients, retention, security measures) and has a defined way to provide guidance that is captured and considered. (Regulation (EU) 2016/679, Article 38)
• Timely: The DPO is engaged early enough to shape design choices, contract terms, and risk decisions, not merely to rubber-stamp after implementation. (Regulation (EU) 2016/679, Article 38)

Plain-English requirement

If your organization touches personal data, you must pull the DPO into decisions that affect privacy and data protection, early enough that their input can change the plan. Then you must be able to show, with records, that this happens across the business. (Regulation (EU) 2016/679, Article 38)

Who it applies to

Entities: Any organization acting as a controller or processor under the GDPR that has a DPO (whether required or voluntarily appointed). Article 38 is written as an obligation on both controllers and processors. (Regulation (EU) 2016/679, Article 38)

Operational contexts where this shows up most:

• Product and engineering: new features, tracking, personalization, identity, logging, analytics.
• Security: breach response, monitoring, access control changes, encryption choices.
• Third party risk management / procurement: onboarding processors, subprocessors, SaaS tools, data-sharing partners.
• Data governance: retention changes, new data sources, model training data, cross-border transfers.
• Customer and HR operations: employee monitoring, background checks, benefits providers, customer support tooling.

If you are both controller and processor in different lines of business, your Article 38 operating model has to work across both roles without ambiguity. A role-and-scope register prevents “we thought we were only the processor” gaps. (Regulation (EU) 2016/679, Article 38)

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

Step 1: Define the scope of “issues relating to the protection of personal data”

Create a short, enforceable trigger list used by intake forms and change tickets. Start with triggers that match real workflows:

• New or changed processing of personal data (collection, use, sharing, retention).
• New systems that store, transmit, or analyze personal data.
• New third parties that receive or access personal data.
• Security incidents involving personal data, or material changes to security controls affecting personal data.
• Any activity that requires or may require a DPIA based on your DPIA criteria.

Make the trigger list a controlled document owned by the privacy program, approved by compliance/legal as needed, and referenced in SOPs. (Regulation (EU) 2016/679, Article 38)

Step 2: Build mandatory DPO touchpoints into workflows

Map the triggers to the “front doors” where work enters:

• Project intake (product/IT portfolio tools)
• Procurement intake (third party onboarding)
• Security change management
• Incident response intake
• Data governance intake (new datasets, retention exceptions)

For each front door, implement one of these control patterns:

1. Hard gate: ticket cannot move to the next status until DPO review is recorded.
2. Risk-based routing: if trigger fields indicate personal data impact, the DPO is automatically added as reviewer/approver.
3. Time-bound consult: DPO must be notified within your internal SLA, and the ticket must document whether DPO feedback changed the plan.

Choose gates that match your culture. Hard gates work best for high-risk changes (new third party processors, new collection at scale); risk-based routing works best for high-volume, lower-risk work. (Regulation (EU) 2016/679, Article 38)

Step 3: Standardize what “involved properly” looks like

Define a minimum “DPO consultation packet” that the business must provide:

• Purpose and lawful basis rationale (if you track it internally)
• Data categories and data subjects
• Systems, data flows, and recipients (including third parties)
• Retention period and deletion method
• Security measures relevant to confidentiality/integrity
• Cross-border transfer considerations (if applicable to your program scope)

Then standardize the DPO output:

• A documented review comment with risk rating (your internal taxonomy)
• Required changes (must-fix) vs recommendations (should-fix)
• Decision record: accepted, accepted with conditions, rejected/escalated

This is where most programs break: DPO involvement happens, but it’s informal (Slack message, hallway chat) and unprovable. Move it into the system of record. (Regulation (EU) 2016/679, Article 38)

Step 4: Create an escalation path when the DPO is ignored

Article 38 is about “position” and involvement; operationally, you need a path for unresolved disagreements:

• If the DPO flags a material risk and the project owner disagrees, require escalation to a defined governance forum (privacy steering committee, security risk council, or equivalent).
• Require a written risk acceptance decision with owner, rationale, and compensating controls.

This protects the DPO function and protects the business. It also produces defensible evidence during an investigation. (Regulation (EU) 2016/679, Article 38)

Step 5: Prove operation with recurring evidence packets

On a recurring cadence, sample across your trigger categories and collect “evidence packets”:

• A project that changed data collection
• A third party onboarding where personal data is shared
• A security incident involving personal data
• A retention exception

Each packet should show the trigger, the DPO consult packet, the DPO’s input, and the final decision. This makes Article 38 auditable. (Regulation (EU) 2016/679, Article 38)

Where Daydream fits naturally: Daydream is useful as the system to standardize these requirement-specific operating procedures and assemble recurring evidence packets (decision record, control outputs, exceptions, remediation) so you can answer diligence and audits without scraping emails and ticket exports. (Regulation (EU) 2016/679, Article 38)

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository (GRC tool, ticketing system, or evidence vault), searchable by system, third party, and date:

1. Role-and-scope register (controller vs processor by product/service; systems; data categories).
2. Article 38 SOP describing triggers, workflow gates, and RACI (who submits, who reviews, who approves).
3. Workflow configuration evidence (screenshots or exports showing required DPO fields/approvals in intake tools).
4. DPO consultation records (tickets, meeting minutes, written feedback, tracked action items).
5. Decision logs and risk acceptances when DPO recommendations are not implemented.
6. Sampling and monitoring results showing the control operates (evidence packets with remediation where gaps exist).

These artifacts directly support the “ensure” standard in Article 38. (Regulation (EU) 2016/679, Article 38)

Common exam/audit questions and hangups

Expect these questions from regulators, internal audit, and customers:

• “Show me how the DPO is involved in new projects.” Bring a completed intake ticket with timestamps that show DPO involvement before build/launch. (Regulation (EU) 2016/679, Article 38)
• “How do you prevent teams from bypassing the DPO?” Point to hard gates, routing rules, and periodic sampling. (Regulation (EU) 2016/679, Article 38)
• “What counts as an ‘issue relating to protection of personal data’ here?” Produce your trigger list and how it’s embedded into processes. (Regulation (EU) 2016/679, Article 38)
• “How do you handle disagreements?” Provide escalation and risk acceptance records. (Regulation (EU) 2016/679, Article 38)

Hangup you’ll see in practice: teams argue that only “privacy projects” require DPO input. Article 38 is broader; operationally, solve this with trigger-based routing tied to personal data touchpoints, not project labels. (Regulation (EU) 2016/679, Article 38)

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. A policy that says “we consult the DPO” fails if your tooling allows shipment without review. Fix: workflow gates and routing. (Regulation (EU) 2016/679, Article 38)
2. Late-stage DPO reviews. Consultation after contracts are signed or code is merged is not timely. Fix: require DPO review at intake and before procurement signature. (Regulation (EU) 2016/679, Article 38)
3. Unprovable consultation. Verbal advice leaves no evidence. Fix: minimum documentation standards and ticket-based recordkeeping. (Regulation (EU) 2016/679, Article 38)
4. No coverage for third parties. Procurement bypass is common. Fix: make “personal data involved?” a mandatory field that routes to the DPO in third party onboarding. (Regulation (EU) 2016/679, Article 38)
5. Undefined scope. Teams don’t know what must be escalated. Fix: publish a trigger list and train intake owners. (Regulation (EU) 2016/679, Article 38)

Enforcement context and risk implications

Public enforcement cases are not included in the provided source catalog, so this page does not list specific cases.

Operational risk is still clear: if you cannot demonstrate timely DPO involvement, you lose defensibility for downstream decisions (data minimization choices, retention periods, processor onboarding, incident handling). That increases the likelihood of adverse findings during supervisory authority inquiries and complicates customer diligence responses. (Regulation (EU) 2016/679, Article 38)

Practical 30/60/90-day execution plan

Days 0–30: Stand up minimum viable control

• Publish an Article 38 SOP with a trigger list and RACI. (Regulation (EU) 2016/679, Article 38)
• Identify the top intake systems (project intake, procurement, incident response).
• Add a mandatory “personal data impact” field and DPO routing rule to at least one high-volume workflow (procurement or project intake).
• Start a simple DPO decision log template.

Days 31–60: Expand coverage and make it auditable

• Add gates/routing to remaining front doors.
• Define the DPO consultation packet and enforce required fields.
• Implement an escalation and risk acceptance path for DPO disagreements.
• Run sampling: pull recent projects and third party onboardings; check for DPO involvement evidence; open remediation tickets for misses.

Days 61–90: Operationalize monitoring and reporting

• Produce recurring evidence packets across multiple categories (projects, third parties, incidents).
• Report KPIs internally (qualitative is fine): missed consults, late consults, high-risk escalations, remediation status.
• Train intake owners (procurement, product ops, security) on triggers and documentation expectations.
• If you use Daydream, configure a standing evidence collection workflow so your audit packet is generated from the same system that runs the process. (Regulation (EU) 2016/679, Article 38)

Frequently Asked Questions

Does Article 38 apply to processors as well as controllers?

Yes. The excerpt explicitly states “the controller and the processor” must ensure the DPO is involved properly and in a timely manner. (Regulation (EU) 2016/679, Article 38)

What counts as “all issues which relate to the protection of personal data”?

Treat it as any decision that changes how personal data is collected, used, stored, secured, shared (including with third parties), or retained. Define triggers and embed them in intake workflows so teams do not self-interpret scope. (Regulation (EU) 2016/679, Article 38)

What is “timely” in operational terms?

Timely means the DPO is consulted early enough to influence the design or decision, not after implementation or signature. Build DPO touchpoints at intake and before go-live or contract execution. (Regulation (EU) 2016/679, Article 38)

Do we need hard approval gates from the DPO for every item?

Article 38 requires involvement, not a specific approval model in the excerpt. Many teams use risk-based routing with hard gates reserved for high-risk triggers such as new third party processors or new data collection. (Regulation (EU) 2016/679, Article 38)

How do we prove compliance during an audit?

Produce a small set of evidence packets showing timestamps: the trigger event, the DPO consultation packet, the DPO’s recorded guidance, and the final decision or escalation outcome. Keep these in a system of record. (Regulation (EU) 2016/679, Article 38)

Our DPO gives advice in email and meetings; is that enough?

It can be, if you can reliably retrieve it and connect it to the decision record. Most teams move DPO input into tickets or a decision log so it’s searchable and consistently retained. (Regulation (EU) 2016/679, Article 38)