Article 37: Designation of the data protection officer

To meet GDPR Article 37, you must decide whether your organization (as a controller and/or processor) is required to appoint a Data Protection Officer (DPO), document that decision, and, if required, formally designate a DPO with an appropriate mandate and scope. Operationally, this means running a repeatable DPO-need assessment tied to your processing activities and retaining auditable proof. ¹

Key takeaways:

• Article 37 is an appointment/designation requirement; auditors will expect a documented determination and a named DPO where required. ¹
• Your controller/processor role and processing scope drive the decision; keep a role-and-scope register to avoid gaps. ¹
• Evidence wins: keep the decision record, designation letter, scope, reporting line, and a maintained org-wide contact disclosure package. ¹

Article 37 is where GDPR turns “privacy program” into an explicit staffing and governance obligation. For a CCO or GRC lead, the fastest path to defensibility is to treat this as a requirement with a clear trigger test, a recorded outcome, and recurring re-validation. Regulators and enterprise customers rarely accept a vague statement like “we have privacy covered.” They ask: do you need a DPO, who is it, what is their scope, and can you prove the organization set them up to do the job?

This page focuses on requirement-level execution. You will: (1) determine whether Article 37 requires a DPO for your controller and/or processor activities, (2) designate a DPO when required, and (3) operationalize the designation so it survives procurement diligence, internal audit, and supervisory authority questions.

Two operational realities matter. First, many organizations are both controller and processor across different products or clients. Second, the DPO decision becomes stale as products, data, and customer segments change. Your goal is a lightweight but auditable mechanism that stays current and is easy to show on demand. ¹

Regulatory text

Excerpt (provided): “1. The controller and the processor shall designate a data protection officer in any case where:” ¹

What the operator must do from this excerpt: Article 37 imposes a duty on controllers and processors to designate a DPO when specific conditions apply. The operational obligation is not satisfied by a generic privacy contact or an informal role. You must (a) run a documented determination of whether your processing triggers the requirement, and (b) if it does, formally designate a DPO and maintain evidence that the designation exists and remains in force. ¹

Practical reading for GRC teams: treat Article 37 as a “named role control” with a scope statement, an assignment mechanism, a change-management trigger, and an evidence packet that can be produced quickly. ¹

Plain-English interpretation

Article 37 requires you to appoint a Data Protection Officer in defined situations. If you are in scope, you need a real person (internal or external) designated as DPO, with clear responsibilities and enough organizational standing to perform the role. If you believe you are not required to appoint a DPO, you still need to prove you evaluated the requirement and can explain why it does not apply to your processing. ¹

Who it applies to (entity and operational context)

In-scope entities

• Any organization acting as a controller for personal data processing.
• Any organization acting as a processor for personal data processing. ¹

Operational contexts where this becomes urgent

• You operate multiple products or business lines, and your controller/processor role changes by workflow.
• You process personal data across many systems, teams, and third parties, making it hard to evidence consistent governance.
• You undergo enterprise procurement or security reviews where DPO designation is a standard due diligence question. ¹

Minimum scoping discipline you need Maintain a GDPR role-and-scope register that ties:

• controller vs. processor role,
• processing purposes (high-level),
• personal data categories (high-level),
• systems/applications,
• product/business owner,
• third parties involved. ¹

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

Step 1: Establish a single owner and a standard decision workflow

Assign ownership to a function that can coordinate Legal, Security, and Product (often Privacy, Compliance, or GRC). Write a short operating procedure with:

• named accountable owner,
• required inputs (records of processing, system inventory, product briefs),
• review/approval path,
• change triggers (new product, new region, major new data category, major client segment change). ¹

Operator tip: Put the workflow behind an intake form so “new processing” cannot launch without answering the DPO-need questions.

Step 2: Build and maintain your “role-and-scope register”

Create (or update) a living register that reflects what you do in practice. This is the anchor artifact for Article 37 because it lets you show you understand where you are controller vs. processor and what processing exists. ¹

A simple table is enough:

Field	Example entry	Why it matters
Business line/product	HR platform	Scoping boundary
GDPR role	Controller	Determines obligations framing
Systems	HRIS, ticketing, analytics	Evidence of real footprint
Third parties	Payroll provider, cloud host	Spillover diligence and contracts
Data categories	employee identifiers, access logs	DPO assessment inputs
Owner	VP People Ops	Accountability

Step 3: Perform and document the Article 37 applicability assessment

Run a structured assessment against the Article 37 conditions, and record the outcome. The output must be understandable without tribal knowledge.

Your decision record should include:

• which business units and processing activities were reviewed,
• whether you act as controller, processor, or both for each,
• conclusion: DPO required / not required / required for specific scope,
• approval and date,
• next review trigger. ¹

Step 4: If required, formally designate the DPO (don’t keep it informal)

Create a designation package:

• designation letter or board/executive appointment memo,
• DPO name, title (or external provider), and start date,
• scope statement (which entities, regions, processing activities),
• reporting line and independence statement (documented). ¹

If you use an external DPO: retain the signed services agreement plus the scope and availability expectations as an exhibit. Treat them as a third party with appropriate due diligence and contract management, because you are outsourcing a regulated role.

Step 5: Operationalize access, engagement, and change management

Designation is fragile if teams bypass the DPO. Implement minimum routing rules:

• privacy impact and high-risk change intake routes to the DPO,
• incident response includes DPO notification criteria,
• procurement/security reviews include DPO contact validation,
• onboarding includes “how to engage the DPO.” ¹

Daydream can help here by turning Article 37 into an auditable requirement workflow with named owners, trigger events, and recurring evidence packets, so DPO designation does not live in a one-off document that nobody can find during diligence.

Step 6: Set a recurring evidence cadence

Pick a recurring cadence that fits your change velocity and ensure you can produce a clean evidence packet at any time:

• current DPO designation and scope,
• last applicability assessment and approvals,
• updated role-and-scope register,
• list of trigger events since last review and how they were handled,
• exceptions log and remediation status. ¹

Required evidence and artifacts to retain

Keep these in a single “Article 37 evidence packet” folder (versioned and access-controlled):

1. DPO applicability decision record (dated, approver identified) ¹
2. Role-and-scope register (controller/processor, data categories, systems, third parties) ¹
3. Designation letter / appointment memo (or external DPO contract exhibit) ¹
4. DPO scope statement (entities, regions, processing coverage, language about conflicts) ¹
5. Operating procedure (owners, triggers, approvals, review cadence) ¹
6. Change trigger log (new processing, new products, new markets) and outcomes ¹

Common exam/audit questions and hangups

Expect these questions in internal audit, customer due diligence, and supervisory authority interactions:

• “Are you a controller, processor, or both? Show me where.” Bring the role-and-scope register and map it to major systems. ¹
• “Show your decision that a DPO is or isn’t required.” Produce the applicability assessment with approver and date. ¹
• “Who is the DPO and what is their scope?” Provide the designation letter and scope statement. ¹
• “What changed since you last reviewed this?” Produce the trigger log and evidence of re-assessment. ¹

Hangup to plan for: teams often cannot produce a single definitive record. They have fragments across Legal, HR, and Security. Solve it with a requirement-specific evidence packet owned by GRC.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating “privacy lead” as equivalent to a DPO.
   Fix: If you are in scope for Article 37, issue a formal designation and keep it current. ¹

2. Mistake: No documented “not required” rationale.
   Fix: Create a one-page decision record with scope, assessment inputs, conclusion, and sign-off. ¹

3. Mistake: Unclear controller vs. processor role by product or client.
   Fix: Maintain the role-and-scope register and tie it to systems and third parties. ¹

4. Mistake: Policy exists, but no workflow forces engagement.
   Fix: Put DPO engagement into intake (new processing), incident response, and change management gates. ¹

Enforcement context and risk implications

No specific public enforcement cases were provided in the source catalog for this page, so do not treat any anecdote as authoritative here.

Operational risk is still clear: failure to designate a DPO when required creates an immediate credibility problem during regulator inquiries and enterprise procurement, and it often correlates with broader governance gaps (unclear roles, weak processing inventory, missing approvals). Article 37 is also easy for third parties to test: they will ask for the name, scope, and proof of designation. ¹

A practical 30/60/90-day execution plan

Use phases (not fixed timelines) so you can move fast without pretending every organization progresses at the same speed.

Immediate: establish control ownership and baseline

• Assign a single accountable owner for Article 37 execution. ¹
• Draft the operating procedure: inputs, approvers, triggers, evidence location. ¹
• Stand up the role-and-scope register with your top systems and processing activities. ¹

Near-term: complete determination and close any designation gap

• Run the applicability assessment across the full processing scope captured in the register. ¹
• If required, finalize and sign the DPO designation package (or external DPO engagement). ¹
• Publish internal guidance: how teams engage the DPO and when escalation is required. ¹

Ongoing: keep it evergreen and audit-ready

• Operate the trigger log and re-assess when products, regions, data categories, or third parties change. ¹
• Maintain an always-current evidence packet (decision record, register, designation, procedure, exceptions). ¹
• Run periodic spot checks: pick a new system or product change and verify the workflow would have routed to the DPO. ¹

Frequently Asked Questions

Do we need a DPO if we are only a processor?

Article 37 applies to processors as well as controllers, so you must still perform and document the applicability assessment for your processor activities. If the requirement triggers, you must designate a DPO for the in-scope processing. ¹

Can we outsource the DPO role to a third party?

Article 37 is about designation; it does not require the DPO to be an employee in the text provided. If you outsource, keep a signed engagement, scope statement, and evidence that the DPO can be reached and is embedded in your workflows. ¹

What evidence should we show a customer during due diligence?

Provide your DPO designation letter (or external DPO engagement exhibit), the DPO scope statement, and the most recent applicability assessment decision record. Keep the role-and-scope register ready in case the customer asks how you determined applicability. ¹

We decided a DPO is not required. What do we document?

Keep a dated decision record describing what processing was assessed, your controller/processor roles, and the approval. Also retain the role-and-scope register that supports the conclusion, and re-open the assessment when processing changes. ¹

Our organization has multiple EU and non-EU entities. Do we need one DPO or several?

Article 37 requires designation “in any case where” the conditions apply; the practical answer depends on the scope you define and can support with governance and evidence. Document the scope clearly in the designation package so it’s obvious which entities and processing are covered. ¹

What’s the fastest way to make this auditable?

Create a single “Article 37 evidence packet” with the decision record, designation documents, operating procedure, and an up-to-date role-and-scope register. Use a workflow tool (including Daydream) to track trigger events, approvals, and evidence so production during an audit is a retrieval task, not a scramble. ¹

Footnotes

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