Article 24: Responsibility of the controller

GDPR Article 24 requires you, as a controller, to implement risk-appropriate technical and organizational measures and be able to prove processing complies with the GDPR, then review and update those measures as needed (Regulation (EU) 2016/679, Article 24). Operationalize it by mapping controller processing, assigning owners, converting requirements into control procedures, and building an evidence pack that stands up in audits and regulator inquiries.

Key takeaways:

• Article 24 is an accountability requirement: you must both do the right things and be able to demonstrate them (Regulation (EU) 2016/679, Article 24).
• “Appropriate” measures are risk-based; your scope and control depth must track processing risk (Regulation (EU) 2016/679, Article 24).
• The fastest path is a role-and-scope register, an operating procedure with named owners, and recurring evidence packets.

Article 24 is where “accountability” becomes operational. It does not hand you a checklist. It tells you to choose and implement controls that fit your processing and your risk profile, and to be able to demonstrate that your choices work in practice (Regulation (EU) 2016/679, Article 24). For a CCO, Compliance Officer, or GRC lead, the practical challenge is repeatability: turning broad GDPR obligations into day-to-day execution across product, engineering, marketing, HR, customer support, and procurement.

Most organizations already have pieces of Article 24 scattered across privacy policies, security controls, and audit programs. Article 24 fails happen when those pieces are not tied together to controller processing decisions, when ownership is unclear, or when evidence is missing at exam time. Regulators and enterprise customers generally ask the same questions: What personal data do you control, why do you process it, what risks does that create, what controls mitigate the risks, and where is the proof that controls run as designed?

This page gives you requirement-level implementation guidance: who must comply, what “appropriate measures” looks like in operator terms, how to build an Article 24 control system, and what artifacts to retain so you can demonstrate compliance on demand.

Regulatory text

Text (excerpt): “Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary.” (Regulation (EU) 2016/679, Article 24)

What the operator must do

Article 24 creates three operator duties (Regulation (EU) 2016/679, Article 24):

1. Risk-assess your controller processing using the “nature, scope, context, purposes” lens and the risk to individuals’ rights and freedoms.
2. Implement appropriate measures (technical and organizational) so processing actually complies with GDPR requirements.
3. Demonstrate compliance with evidence, and review/update measures when conditions change.

Think of it as a management system requirement for GDPR: define scope, implement controls, keep proof, and refresh the system as risk changes (Regulation (EU) 2016/679, Article 24).

Plain-English interpretation (what Article 24 means in practice)

• You are responsible for GDPR compliance for the processing you control. You cannot outsource accountability to a processor or a tool.
• “Appropriate” means defensible for your risk. If you process sensitive data, operate at scale, combine datasets, or make impactful decisions about people, you need tighter controls and stronger proof.
• “Be able to demonstrate” means you need audit-ready evidence: not just policies, but records showing decisions, control operation, exceptions, and remediation.

Who it applies to

Entity scope

• Controllers: any organization that determines the purposes and means of processing personal data falls within Article 24 for that processing (Regulation (EU) 2016/679, Article 24; Regulation (EU) 2016/679).
• If you are a processor for some activities and a controller for others (common for SaaS providers), Article 24 applies to the controller side. Your first operational step is a role decision per processing activity.

Operational contexts where Article 24 shows up

• Launching new products or features that collect or infer personal data.
• Adding a new third party (cloud, analytics, support tools) that touches personal data.
• Expanding into new geographies, data categories, or customer segments.
• Merging datasets, introducing new profiling, or changing retention practices.
• Responding to incidents, complaints, or regulator inquiries that test your ability to demonstrate compliance.

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

Use this as a build plan for an Article 24 “accountability pack” you can hand to auditors, regulators, or enterprise customers.

Step 1: Build a controller role-and-scope register

Create a register that answers, for each processing activity you control:

• Controller vs processor role determination (and joint controller if applicable).
• Purpose(s) of processing.
• Data subject categories (customers, employees, prospects, end users).
• Personal data categories (identifiers, contact data, usage data, special categories if any).
• Systems where data lives (apps, warehouses, ticketing, logs).
• Third parties involved (processors/sub-processors) and data flows.
• High-level risk notes tied to rights and freedoms.

This register is the anchor for “nature, scope, context, purposes” and for scoping “appropriate measures” (Regulation (EU) 2016/679, Article 24).

Operational tip: keep it change-controlled. Article 24 expects you to update measures when needed, and you cannot do that if scope is stale (Regulation (EU) 2016/679, Article 24).

Step 2: Define your Article 24 operating procedure (SOP)

Write a short SOP that makes Article 24 executable. Include:

• Named owners: privacy owner (often DPO or privacy counsel), security owner, product owner, data owner.
• Trigger events: new processing, new third party, material change to purposes, new data category, architecture change, incident learnings, audit findings.
• Required approvals: privacy review sign-off, security sign-off, procurement sign-off for third parties, and risk acceptance authority.
• Control cadence: how often you review the register and evidence, plus ad hoc updates when triggers fire (Regulation (EU) 2016/679, Article 24).

If you run Daydream for third-party risk management and privacy governance, this SOP maps cleanly into workflow: intake, scoped review tasks, approvals, and evidence collection tied to each processing activity.

Step 3: Translate “appropriate measures” into a control set you can test

Article 24 does not list measures, but it requires measures that ensure GDPR compliance and proof of compliance (Regulation (EU) 2016/679, Article 24). Make the control set explicit and map each control to where it runs.

A practical control set usually includes:

• Governance controls: policy standards, documented roles/responsibilities, training expectations, risk acceptance process.
• Lifecycle controls: privacy review at design, change management gates, release checklists where personal data scope changes.
• Technical controls: access management, logging, encryption where relevant, environment separation, secure deletion capabilities.
• Third-party controls: due diligence before onboarding, contract checks, processor management, sub-processor tracking.
• Data rights and transparency controls: request intake/fulfillment workflow, notices alignment with actual processing, retention controls.

Keep each control in a testable format: objective, owner, system/workflow, frequency, evidence output, and exception handling.

Step 4: Establish “demonstrate” evidence packets (recurring, auditable)

Build an evidence packet template per quarter (or aligned to your audit cadence) that includes:

• Current role-and-scope register export.
• Latest risk assessment notes tied to processing changes.
• Control run evidence (tickets, logs, screenshots, reports).
• Exceptions list with documented risk acceptance and remediation tracking.
• Record of reviews and updates to measures (change log).

This is the fastest way to satisfy the “be able to demonstrate” portion without scrambling (Regulation (EU) 2016/679, Article 24).

Step 5: Review and update where necessary (make “necessary” explicit)

Define what “necessary” means in your environment by listing triggers and thresholds in your SOP. Examples:

• New personal data category added to an existing product workflow.
• New third party gains access to production personal data.
• Material increase in processing scale (new region, new customer segment).
• Incident findings show control failure.
• Audit identifies a gap.

Then enforce it through change management: no production change that affects personal data scope closes without the required privacy/security sign-offs.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with retention aligned to your audit and regulatory needs (Regulation (EU) 2016/679, Article 24):

• Controller role-and-scope register (versioned).
• Article 24 SOP with owners, triggers, approvals.
• Risk assessment records for key processing activities (even if lightweight).
• Control inventory mapped to processing activities and systems.
• Control operation evidence (reports, tickets, screenshots, access reviews, training completion where applicable).
• Exception/risk acceptance records with approver, rationale, expiry/revisit date.
• Change log showing measures were reviewed/updated “where necessary.”

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your evidence packet:

1. Show me how you determined what measures are “appropriate.” Bring the register, risk notes, and mapped control set (Regulation (EU) 2016/679, Article 24).
2. Who owns controller compliance for each processing activity? Auditors dislike “privacy owns everything.” Show data owners and system owners.
3. How do you know controls run consistently? Provide recurring evidence and exception tracking.
4. What changed recently, and how did controls update? Show trigger events and change log (Regulation (EU) 2016/679, Article 24).
5. How do third parties fit into your accountability story? Show onboarding due diligence outputs, contract checks, and monitoring.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails Article 24	Better approach
Treating Article 24 as “have a GDPR policy”	Policy alone rarely demonstrates operating compliance (Regulation (EU) 2016/679, Article 24)	Pair policy with an SOP, control runs, and evidence packets
No clear controller vs processor decisions	Mis-scoping obligations leads to missing controls	Maintain a role-and-scope register per processing activity
Controls exist but are not mapped to processing	You cannot show “appropriate for the risk”	Map controls to risk factors and processing contexts (Regulation (EU) 2016/679, Article 24)
Evidence is ad hoc and scattered	Demonstration fails during diligence or regulator requests	Standardize evidence packets and store centrally
“Review and update” is informal	Changes happen without privacy risk recalibration	Put triggers into change management and require approvals

Enforcement context and risk implications

No public enforcement case sources were provided in the source catalog for this page, so this guidance avoids naming specific cases. Practically, Article 24 weaknesses tend to surface during regulator inquiries, customer audits, and incident response because those are the moments you must “be able to demonstrate” compliance, not just claim it (Regulation (EU) 2016/679, Article 24). The risk is compounded when you cannot show how measures were selected based on processing risk, or when your scope documentation is outdated.

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

Use this phased plan to get to audit-ready operation without inventing a long transformation program.

First 30 days (stabilize scope and ownership)

• Stand up the controller role-and-scope register for top business processes and systems that handle personal data.
• Assign named owners per processing area (data owner, system owner, privacy reviewer, security reviewer).
• Draft and publish the Article 24 SOP with trigger events and required approvals (Regulation (EU) 2016/679, Article 24).
• Build an evidence packet template and pick a central repository.

Days 31–60 (make it executable)

• Map each major processing activity to a control set (governance, lifecycle, technical, third-party, data rights).
• Embed privacy/security gates into change management and third-party onboarding.
• Run a first cycle of control evidence collection using the template.
• Create an exceptions workflow with time-bound remediation tasks.

Days 61–90 (prove it, then harden)

• Perform an internal mock audit against Article 24: pick two processing activities and test whether you can demonstrate compliance end-to-end (Regulation (EU) 2016/679, Article 24).
• Close gaps: missing owners, missing system coverage, weak evidence, inconsistent approvals.
• Establish a recurring review/update cadence plus an “out-of-cycle” change trigger process.
• If you use Daydream, configure recurring tasks and evidence requests so the Article 24 packet is continuously current.

Frequently Asked Questions

Does Article 24 require specific controls like encryption or access reviews?

Article 24 does not prescribe specific controls; it requires “appropriate technical and organisational measures” based on your processing context and risk, plus proof those measures work (Regulation (EU) 2016/679, Article 24). You should document why the controls you chose are appropriate for each processing activity.

We have GDPR policies. Why isn’t that enough for Article 24?

Article 24 requires you to “be able to demonstrate” compliant processing, which typically means operational evidence: owned procedures, control run outputs, exceptions, and updates when processing changes (Regulation (EU) 2016/679, Article 24). Policies support the story, but they rarely prove execution.

What’s the minimum evidence we should keep to demonstrate Article 24 compliance?

Keep a role-and-scope register, an Article 24 SOP with owners and triggers, and recurring evidence packets showing control operation and updates (Regulation (EU) 2016/679, Article 24). If you can’t reproduce decisions and control runs on request, you will struggle to demonstrate compliance.

How does Article 24 interact with third-party risk management?

If a third party processes personal data for you, your controller accountability remains, and your measures must cover onboarding, contracting, and oversight so you can demonstrate compliant processing (Regulation (EU) 2016/679, Article 24). Practically, tie third-party intake to your processing register and evidence packet.

Who should “own” Article 24 inside the company?

Compliance or the privacy function should own the Article 24 management system (register, SOP, evidence), but operational owners must exist in engineering, product, IT, and procurement. Auditors will expect accountability to be distributed to the teams that run the processing (Regulation (EU) 2016/679, Article 24).

What does “reviewed and updated where necessary” mean operationally?

Define trigger events (new processing, new data categories, new third parties, major changes, incident learnings) and route them through change management with required approvals and evidence capture (Regulation (EU) 2016/679, Article 24). Then keep a change log that proves you acted when conditions changed.