Article 37: Designation of the data protection officer

Article 37 requires you to formally designate a Data Protection Officer (DPO) when your organization’s processing triggers the GDPR’s DPO criteria, and to do so in a way that is defensible under scrutiny. Operationalize it by making a documented applicability decision, appointing a qualified internal or external DPO, and wiring the role into governance, records, and third-party contracting. (Regulation (EU) 2016/679, Article 37)

Key takeaways:

• Start with a written applicability determination tied to your controller/processor role and processing scope. (Regulation (EU) 2016/679, Article 37)
• Treat “designation” as an operating model: mandate, reporting line, resourcing, and coverage across business units and products. (Regulation (EU) 2016/679, Article 37)
• Keep an evidence packet: decision record, appointment letter/contract, scope, and triggers for re-evaluation. (Regulation (EU) 2016/679, Article 37)

The Article 37: designation of the data protection officer requirement is easy to misunderstand because teams treat it like a job title instead of a compliance control. Regulators and customers will not accept “we have a privacy person” as evidence. They look for a clear designation decision, a named DPO (internal or external), and proof that the role covers the processing activities that triggered the requirement. (Regulation (EU) 2016/679, Article 37)

For a CCO, Compliance Officer, or GRC lead, the fastest path is to convert Article 37 into a repeatable workflow: (1) decide whether you must designate a DPO, (2) document that decision in a way that ties back to your processing reality (controller vs. processor, systems, and data categories), (3) appoint the DPO with a defined mandate and access, and (4) build a re-assessment trigger so the designation stays correct as products and third parties change. (Regulation (EU) 2016/679, Article 37)

This page focuses on practical execution: who owns what, what to write down, which artifacts auditors ask for, and the mistakes that create avoidable findings in diligence and supervisory reviews.

Regulatory text

Provided excerpt (Article 37): “The controller and the processor shall designate a data protection officer in any case where:” (Regulation (EU) 2016/679, Article 37)

Operator meaning of the excerpt: Article 37 creates a conditional obligation. Your first operational task is to determine whether your organization is in one of the “in any case where” situations that make DPO designation mandatory, then to execute a formal designation that stands up to evidence-based review. (Regulation (EU) 2016/679, Article 37)

What you must be able to show on request:

• A documented decision on whether Article 37 applies to you, grounded in your actual processing and role as controller and/or processor. (Regulation (EU) 2016/679, Article 37)
• If it applies, proof of DPO designation (named individual or contracted service) with defined scope of coverage. (Regulation (EU) 2016/679, Article 37)

Plain-English interpretation (requirement-level)

If your organization’s processing meets the GDPR’s conditions that require a DPO, you must appoint one. “Designate” is not informal. It means you can point to a specific person (or an external provider) and show: when they were appointed, what they cover, and how they engage with the organization as a standing governance function. (Regulation (EU) 2016/679, Article 37)

Treat this as a governance control that sits above your privacy program and informs how you run DPIAs, incident response, product reviews, and third-party processing decisions. Article 37 is the “appointment trigger”; it forces clarity on roles and scope before you argue about process details. (Regulation (EU) 2016/679, Article 37)

Who it applies to (entity and operational context)

Article 37 applies to controllers and processors. That includes:

• Organizations acting as a controller for customer, employee, user, or prospect personal data.
• Service providers acting as a processor for clients, including SaaS, managed services, and outsourced functions where the client determines the purposes/means. (Regulation (EU) 2016/679, Article 37)

Operational contexts where this comes up most often:

• A SaaS company that is a processor for enterprise customers but a controller for its own marketing, billing, and HR data.
• A group structure where multiple subsidiaries process personal data differently; a single DPO may be designated, but the scope must be explicit.
• A third party ecosystem where your organization sub-processes data or relies on sub-processors; DPO designation decisions must still anchor to your own role and processing. (Regulation (EU) 2016/679, Article 37)

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

Step 1: Build a “role-and-scope register” for Article 37

Create a living register that answers, per business line or system:

• Are we acting as controller, processor, or both?
• What personal data categories are in scope?
• Which systems and products process the data?
• Which third parties touch the data (processors/sub-processors), and under what contracts? (Regulation (EU) 2016/679, Article 37)

This register becomes your backbone evidence during audits and customer due diligence. It also prevents the most common failure mode: appointing (or failing to appoint) a DPO based on assumptions rather than mapped processing reality. (Regulation (EU) 2016/679, Article 37)

Step 2: Make and document the applicability determination

Write a short decision record that includes:

• Date, owner, approver.
• Summary of relevant processing activities.
• Conclusion: DPO required / not required (with rationale).
• Re-evaluation triggers (examples below). (Regulation (EU) 2016/679, Article 37)

If you decide a DPO is not required, the decision record still matters. Many organizations get challenged on absence of designation; your defensible story is the paper trail. (Regulation (EU) 2016/679, Article 37)

Step 3: Select the DPO model (internal vs. external) and define scope

Article 37 permits designation; it does not force a specific org chart in the excerpt you have here. Operationally, you need to choose:

• Internal DPO: named employee with allocated time, authority, and access.
• External DPO: named individual via a services agreement, with clear SLAs for availability, reviews, and incident participation. (Regulation (EU) 2016/679, Article 37)

Define scope explicitly:

• Which legal entities are covered.
• Which products/systems are covered.
• Which geographies are covered.
• Coverage for controller activities vs. processor activities (they differ in practice). (Regulation (EU) 2016/679, Article 37)

Step 4: Execute formal designation and governance wiring

Put in place artifacts that prove the designation is real:

• Appointment letter or board/exec delegation memo naming the DPO and start date.
• Role description (responsibilities, independence expectations, escalation path).
• Reporting line and conflict management statement (how you avoid placing the DPO inside functions that decide purposes/means without checks). (Regulation (EU) 2016/679, Article 37)

Then wire the DPO into operating workflows:

• Intake: product launches, new data uses, new markets, onboarding new third parties.
• Change management: material system changes, new integrations, AI/analytics features.
• Incident response: privacy incident triage and communications workflows.
• Contracting: processor/sub-processor terms review inputs, especially around data processing scope. (Regulation (EU) 2016/679, Article 37)

A practical control design: require a DPO sign-off (or documented consult) on DPIA determinations and high-risk third-party processing proposals. Keep it lightweight, but consistent. (Regulation (EU) 2016/679, Article 37)

Step 5: Set trigger events and a recurring evidence cadence

Define trigger events that force re-assessment of whether the DPO designation remains correct, such as:

• Launching a new product line that changes data categories or processing intensity.
• Adding a new high-impact third party that expands processing footprint.
• M&A, new subsidiaries, or major geographic expansion. (Regulation (EU) 2016/679, Article 37)

Run a recurring evidence cadence:

• Refresh the role-and-scope register.
• Confirm the DPO designation remains accurate and staffed.
• Record exceptions and remediation actions. (Regulation (EU) 2016/679, Article 37)

Where Daydream fits: use Daydream as the system of record for (a) your Article 37 decision record, (b) the role-and-scope register mapped to systems and third parties, and (c) an evidence packet that you can export for audits and customer questionnaires without rebuilding the story each time. (Regulation (EU) 2016/679, Article 37)

Required evidence and artifacts to retain (audit-ready packet)

Keep these in one place, versioned, and easy to export:

1. Article 37 applicability decision record (required vs. not required, with rationale). (Regulation (EU) 2016/679, Article 37)
2. Role-and-scope register for controller/processor activities, systems, data categories, and third parties. (Regulation (EU) 2016/679, Article 37)
3. DPO designation artifact (appointment letter, resolution, or executed services agreement identifying the DPO). (Regulation (EU) 2016/679, Article 37)
4. DPO role description and governance map (responsibilities, escalation, access points). (Regulation (EU) 2016/679, Article 37)
5. Operating procedure that shows where DPO engagement is mandatory vs. optional, plus who owns the workflow steps. (Regulation (EU) 2016/679, Article 37)
6. Evidence of operation: meeting minutes for privacy governance, documented consults on high-risk changes, exception log and remediation. (Regulation (EU) 2016/679, Article 37)

Common exam/audit questions and hangups

Expect auditors, regulators, and enterprise customers to ask:

• “Are you a controller or processor for each major dataset, and how did you decide?” (Regulation (EU) 2016/679, Article 37)
• “Show me your decision record for whether a DPO is required.” (Regulation (EU) 2016/679, Article 37)
• “Who is your DPO, and what entities/systems does the designation cover?” (Regulation (EU) 2016/679, Article 37)
• “If you use an external DPO, show the contract and proof of ongoing engagement.” (Regulation (EU) 2016/679, Article 37)
• “What triggers a re-assessment of DPO designation?” (Regulation (EU) 2016/679, Article 37)

Hangups that cause findings:

• Unclear group scope (subsidiaries believe they are covered; the paperwork does not say so).
• DPO “in name only” with no defined touchpoints in change management or third-party onboarding. (Regulation (EU) 2016/679, Article 37)

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Skipping the controller/processor split

Failure mode: One global statement (“we are a processor”) with no mapping to HR, marketing, billing, telemetry, and support systems.
Fix: Maintain the role-and-scope register and tie it to systems and third parties. Make it the input to your Article 37 decision record. (Regulation (EU) 2016/679, Article 37)

Mistake 2: Treating designation as a one-time HR event

Failure mode: You have an appointment letter, but no operating procedure, no triggers, and no evidence of consults.
Fix: Add DPO consult steps to product intake, third-party onboarding, incident response, and material system changes. Track them like any other compliance control. (Regulation (EU) 2016/679, Article 37)

Mistake 3: Scope gaps for third-party processing

Failure mode: Procurement signs DPAs and adds sub-processors without a privacy governance checkpoint.
Fix: Make third-party onboarding a trigger event: the DPO (or privacy governance function) must review processing scope changes that affect the Article 37 analysis. (Regulation (EU) 2016/679, Article 37)

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for this requirement, so this page does not summarize specific regulatory actions.

Operational risk still exists even without case examples:

• Regulatory defensibility risk: inability to show a reasoned designation (or non-designation) decision record. (Regulation (EU) 2016/679, Article 37)
• Customer diligence risk: enterprise buyers frequently ask who the DPO is and how privacy governance works; weak artifacts slow deals.
• Program integrity risk: without a clear DPO model, DPIA and high-risk change decisions become ad hoc and inconsistent. (Regulation (EU) 2016/679, Article 37)

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

Use phases instead of calendar promises. Move as fast as your org can approve governance changes.

Phase 1 (Immediate): Decide and document

• Stand up the Article 37 role-and-scope register (systems, data categories, third parties, controller/processor role). (Regulation (EU) 2016/679, Article 37)
• Draft and approve the Article 37 applicability decision record.
• Identify candidate DPO options (internal/external) and gaps in independence, bandwidth, or expertise.

Phase 2 (Near-term): Designate and wire into operations

• Execute the DPO designation artifact (appointment letter or services agreement) and define entity/product/geography coverage. (Regulation (EU) 2016/679, Article 37)
• Publish the operating procedure: when to consult the DPO, who owns intake steps, what “done” looks like.
• Update third-party onboarding and contracting checklists to include DPO consult triggers tied to processing scope changes. (Regulation (EU) 2016/679, Article 37)

Phase 3 (Ongoing): Evidence, triggers, and continuous validity

• Run a recurring control cycle: refresh the register, confirm the designation remains accurate, and log exceptions with remediation.
• Test the workflow with a tabletop exercise: simulate a major new integration or a privacy incident and record DPO engagement evidence. (Regulation (EU) 2016/679, Article 37)
• Centralize artifacts in a system of record (Daydream or equivalent) so you can answer audits and customer questionnaires quickly and consistently. (Regulation (EU) 2016/679, Article 37)

Frequently Asked Questions

Do we need a DPO if we are “only a processor” for enterprise customers?

Processors can be required to designate a DPO under Article 37 depending on the “in any case where” criteria that apply to their processing. Start with a documented applicability decision tied to your actual processing activities. (Regulation (EU) 2016/679, Article 37)

Can we appoint an external DPO service instead of hiring?

Article 37 allows designation; the operational requirement is that the DPO is clearly identified and the designation is provable through a contract and scope definition. Keep evidence of ongoing engagement, not just the signed agreement. (Regulation (EU) 2016/679, Article 37)

What is the minimum evidence an auditor will accept for designation?

Keep a decision record (why required or not), plus an appointment letter/contract naming the DPO and the scope covered. Back it with an operating procedure and a small sample of operated evidence (consults, meeting notes, exceptions). (Regulation (EU) 2016/679, Article 37)

How do we handle group companies and subsidiaries?

Document which legal entities are covered by the designation and align that to the role-and-scope register. If some entities are excluded, write that down and keep a separate applicability record for them. (Regulation (EU) 2016/679, Article 37)

What triggers a re-evaluation of whether a DPO is required?

Tie triggers to processing reality: new products, major system changes, new third parties that materially change processing scope, and structural changes like acquisitions. Record each trigger review outcome in your evidence packet. (Regulation (EU) 2016/679, Article 37)

Who should own Article 37 operationally: Legal, Compliance, or Security?

Assign a single control owner (often GRC/Compliance) to run the decision record and evidence cadence, then define required inputs from Legal, Security, and Procurement. The DPO is a designated role; the control owner ensures the designation stays correct and evidenced. (Regulation (EU) 2016/679, Article 37)