GDPR Article 24 requires a controller to put appropriate technical and organisational measures into practice, be able to demonstrate that its processing complies with the Regulation, and review and update those measures when necessary. It is a risk-sensitive duty, not a prescribed folder of policies or an annual certification requirement. The relevant risks concern people’s rights and freedoms; the controller must consider the nature, scope, context and purposes of its processing as well as how likely and severe the harm could be. The official Article 24 text reproduced by the CNIL is the starting point.
Article 5(2) states the accountability principle: the controller is responsible for, and able to demonstrate, compliance with Article 5(1)’s principles. Article 24 gives that responsibility an operational form across the Regulation. The distinction matters. An organisation can have a polished policy but use data for an unrecorded purpose; conversely, a sensible practice without enough evidence can be hard to explain or verify. The accountability principle and this Article 24 guide should therefore be read together, with each real processing activity as the unit of analysis.
What the three paragraphs actually say
Article 24(1) asks the controller to implement measures appropriate to its processing and risks, so that it both ensures and can demonstrate GDPR-compliant processing. The measures are to be reviewed and updated where necessary. Article 24(2) says appropriate data-protection policies should be among those measures when proportionate to the processing activities. Article 24(3) permits adherence to an approved Article 40 code of conduct or approved Article 42 certification mechanism to serve as an element of demonstration. None of the paragraphs says that one certificate proves every processing activity lawful.
The provision addresses the controller, the person or organisation that determines purposes and means. A processor has direct GDPR duties of its own, including those in Article 28 and Article 32, and the controller must manage the processor relationship. It would be wrong to call every vendor the Article 24 controller simply because it operates a system. Equally, outsourcing a database or appointing a DPO does not transfer the controller’s Article 24 duty away. Start by documenting who decides why the data are used and who supplies the service; the role can differ between activities.
The standard changes with risk. A local retailer using a small customer file and a hospital operating a large patient system will not necessarily need identical controls or review depth. Yet neither can rely on staff numbers alone. The Article 30(5) small-organisation exception is conditional: nonoccasional processing, risk and Article 9 or 10 data can remove it. Article 24 itself is not waived for a small controller. Proportionality means being able to explain why chosen measures fit the actual activity, not claiming that a short checklist is always enough.
Turn an obligation into a decision you can show
Take a new customer-support system as an example. Before importing tickets, the controller should specify the purpose, data categories, legal basis, recipients, retention rule and access model. It should decide whether the vendor is a processor, what instructions and safeguards are needed, and whether any international transfer occurs. It should inform customers appropriately, restrict access, define how requests and incidents will be handled, and assign an owner to revisit the design when the product changes. Article 24 does not prescribe one document with that exact name; the point is that the decisions and their implementation can be shown.
A useful evidence chain connects four things: the requirement, the decision, the operating control and the verification. For support tickets, the requirement might be storage limitation. The decision might be to remove closed tickets after a defined period, subject to a documented legal hold. The control is a configured deletion or review workflow. Verification is a sample showing that the workflow actually ran and exceptions were limited. A retention policy alone proves intent; a deletion log without the rationale proves operation but not the legal reasoning. Together they make the measure reviewable.
Do not equate “demonstrate” with reversing every burden of proof in an enforcement case. A supervisory authority still has to establish an infringement according to the applicable procedure. The controller has an independent statutory obligation to be able to show compliance with the GDPR requirements that apply to its processing. If its records are absent or contradict its practice, it will struggle to satisfy that duty. Honest documentation of an unresolved risk and a corrective action is more useful than a perfect-looking register that does not match the system.
Decide which evidence is required and which is helpful
Some records have specific legal triggers. Article 30 describes records of processing activities and its qualified small-organisation exception. Article 35 requires a data protection impact assessment when processing is likely to create a high risk. Article 33(5) requires documenting personal-data breaches, including the facts, effects and remedial action, so the supervisory authority can verify compliance. Where consent is relied on, Article 7(1) requires the controller to demonstrate it. An Article 28 processor relationship needs a contract or other binding legal act under Union or Member State law with the required content. These are not interchangeable entries in one generic “evidence register.”
Other evidence is a practical way to show that a chosen measure works. Versioned notices can show what people were told at a particular time. Training records can show whether people with privileged access received relevant instruction. An access review can expose stale permissions. A sample of rights requests can show whether responses are timely and reasoned. Such materials may be important for a controller’s circumstances, but Article 24 does not impose a universal fixed inventory, training frequency or retention period for every item. Match evidence to the risk and obligation it is meant to support.
For a processing record, distinguish a legal field from a management field. Article 30 specifies certain content; an internal owner, review date or source-system identifier may make maintenance easier but is not itself a separate Article 30 field. The Article 30 record guide helps make that distinction. A record copied from a template and never reconciled to live applications will not demonstrate that actual purposes, recipients or retention periods are under control.
A controller may also need to record a decision not to perform a particular step. If an activity was screened and a DPIA was not required, preserve the facts behind that conclusion and the trigger for reconsideration. If a breach was assessed as unlikely to pose risk and was not notified, document why, rather than merely recording “no notification.” If a person’s request is refused, Article 12(4) requires the reasons and information about complaint and judicial-remedy rights. Article 24 is helped by a reasoned exception trail, not by mechanically closing every task as complete.
Review when facts change
Article 24 requires review and updating where necessary. It does not set an annual programme audit for every controller. A planned periodic review can still be a sound management choice, particularly where many systems and owners change over time. The more important question is what events reopen the decision: a new purpose, a larger population, a new data category, a change of processor or location, an incident, a legal change, or evidence that a measure failed. Define a trigger and owner for each significant control.
Suppose the support system adds automated sentiment analysis of ticket text. The original legal-basis analysis, information notice, retention rule and perhaps DPIA screening may no longer fit. A controller that reviews only once per year could operate the new feature for months without the relevant decision. A release gate that alerts the privacy owner before activation makes Article 24 more real. The privacy-by-design duty in Article 25 is particularly relevant at this point: it concerns measures built into the determination of means and processing itself, including defaults.
Review also means testing whether controls achieve their purpose. If the policy limits access to support tickets but every administrator can read them, revise permissions or justify the scope. If a processor says it deleted returned data but a backup keeps it indefinitely, ask how the backup is controlled and when it expires. Article 24 does not name a particular test interval. Use likelihood, severity, rate of change and control history to choose one, then record exceptions and action. The GDPR audit methodology can help structure sampling without treating the audit calendar as a statutory number.
How Article 24 relates to Articles 25, 28, 30 and 32
Article 24 is the controller’s broad responsibility to organise and evidence compliant processing. Article 25 applies data protection by design and by default when means are chosen and during processing. Article 32 requires appropriate security from both controller and processor, considering risk, state of the art, cost and context. A firewall or encryption setting may contribute to Article 32 but cannot by itself establish a lawful basis or an appropriate retention rule. Read the Article 32 security guide for the risk-based security standard.
Article 28 concerns the relationship with a processor: instructions, safeguards, assistance, deletion or return, audit information and subprocessors, according to the applicable arrangement. The controller remains accountable for selecting and overseeing a processor, while the processor can itself breach direct GDPR duties. Article 30 is an inventory and control tool, not a substitute for the actual implementation of each recorded measure. A controller can keep a complete register and still send data to a recipient it omitted or retain it longer than justified.
The DPO under Articles 37–39 advises, monitors and cooperates with the authority where the role applies. The controller should involve the DPO and give necessary resources and independence, but should not make the DPO personally “sign off” every processing activity as if the DPO were the controller. Management and relevant business owners must make decisions and supply facts. The DPO can challenge the reasoning and help reveal a gap. The DPO designation guide explains when appointment is required.
Policies, codes and certifications: useful but limited
Article 24(2) makes suitable data-protection policies part of the measures where proportionate. A useful policy tells people what to do: which activity needs review, who can approve a new purpose, how an incident is escalated, where evidence is kept, and what happens when a processor changes. A policy that only restates GDPR article numbers will not guide an engineer or HR colleague. Train the people who execute it, check whether they can follow it, and revise it when the organisation changes.
Article 24(3) speaks specifically of approved Article 40 codes and approved Article 42 certification mechanisms. ISO 27701, ISO 27001 or a commercial privacy badge must not automatically be labelled an Article 42 GDPR certification. An external standard may provide useful security or privacy-management evidence within its scope, but the controller still has to examine the particular processing and legal duties. The ISO 27001 and GDPR comparison separates information-security management from GDPR compliance.
When reviewing any certification, ask what entity, sites, services, period and criteria it covers, who assessed them, and whether the mechanism is in fact approved under the relevant GDPR provision. Even a valid Article 42 mechanism is only an element of demonstration, not a defence against every infringement. A company can be certified for one operation and fail to provide a lawful notice for another. The evidence should sharpen the review rather than end it.
A workable Article 24 review in seven steps
Start with one material processing activity, not the entire organisation at once. Name the controller and its purpose, then trace the data from collection to deletion or archival restriction. Identify the legal rules actually triggered, including national conditions where they matter. Record the owner’s decisions and the risk reasoning. Inspect the live control or sample the workflow. Compare what the system does with the record and notice. Finally, assign fixes, review dates and a trigger for reopening the analysis.
For example, a retailer might rely on contract necessity for delivery data, a separate legal obligation for accounting records and a distinct basis for marketing. The same customer profile can contain data with different retention reasons. A person’s erasure request should remove unnecessary marketing uses while preserving only the records whose continued retention is justified. Article 24 evidence should show who made that separation and how the system enforces it. A single “customer data kept seven years” row would hide the actual legal and technical choices.
Keep the file readable by another person. Link the processing record to the notice version, processor arrangement, DPIA if any, control description and latest review. Mark facts that have not been verified. If the business owner cannot explain an export, the record may be too abstract. If the technical owner cannot tell which control implements the stated retention rule, the policy may be too detached from operations. These are good points to test before an inspection or a breach forces a reconstruction under time pressure.
Do not promise that a particular evidence package is requested “on day one” of every supervisory inspection. Powers and requests depend on the case. Maintain evidence because the organisation needs to know and demonstrate what it does, not because a universal ten-document demand exists. When the authority asks a specific question, a connected record lets the controller respond accurately without creating explanations after the fact.
Enforcement and practical limits
Article 83 does not expressly list Article 24 in either of its two fine-ceiling lists. It lists Article 5 principles in the higher tier and specified controller and processor duties in Articles 25 to 39, among others, in the lower tier. An investigation may concern Article 24 alongside a listed provision, but it would be inaccurate to assign an automatic standalone Article 24 maximum of €10 million or 2% of turnover. The facts, legal findings and Article 83(2) factors govern any fine; corrective powers under Article 58 are also relevant. The Article 83 fines guide explains the framework without predicting a penalty for a missing policy.
An Article 24 failure may coexist with a more specific breach, but those provisions should not be treated as duplicate labels for the same fact. If a company lacks a required DPIA, Article 35 addresses that obligation; if security is inappropriate, Article 32 matters; if it cannot show a structured process or has not reviewed stale measures, Article 24 may be relevant. The authority’s findings and the national procedure determine the outcome. Avoid using one historic fine as a price tag for future Article 24 risk.
Software can help link processing, applications, processor contracts, DPIAs, incidents, rights requests, audits and evidence. It cannot decide that a disputed purpose is lawful or make an untested control effective. A review-controlled system is valuable when it shows sources, missing facts, accountable decision-makers and changes over time. The controller should be able to export and explain those decisions in ordinary language without depending on a vendor’s green status indicator.
Common questions
Does Article 24 require an annual GDPR audit?
No fixed annual frequency appears in Article 24. Measures must be reviewed and updated when necessary. A periodic audit can be sensible, but changes in processing and risk may require earlier review.
Must every controller keep a ROPA and DPIA register?
Article 30’s small-entity exception has important qualifications, and Article 35 requires a DPIA for likely high-risk processing. It is useful to record screening decisions, but Article 24 does not turn every processing activity into a mandatory DPIA or prescribe a universal “DPIA register.”
Does ISO 27701 prove Article 24 compliance?
No. Article 24(3) refers to approved GDPR codes under Article 40 and certification mechanisms under Article 42 as possible elements of demonstration. An ISO standard can provide relevant evidence within its scope, but it is not automatically an approved Article 42 mechanism or proof that all GDPR requirements have been met.
What should a controller show first?
Show an accurate description of the processing and connect it to the applicable legal basis, notice, safeguards, processor arrangements, retention and review decision. The right supporting documents depend on the activity and question being asked; a generic binder is less useful than evidence that matches reality.