Article 24 — Responsibility of the controller

Article 24 is one of the central accountability provisions of the GDPR. It translates the general accountability principle in Article 5(2) into a broader operational obligation imposed on the controller.

Article 5(2) establishes the principle that the controller is responsible for compliance with the GDPR and must be able to demonstrate compliance. Article 24 gives that principle practical substance by requiring the controller to establish an organisational and technical framework capable of ensuring compliance.

The provision therefore has two dimensions:

1. substantive responsibility, the controller must actually comply with the GDPR; and

2. demonstrable accountability, the controller must be able to show, with appropriate evidence, that its processing activities comply.

This makes Article 24 fundamentally different from a purely reactive obligation. The controller cannot simply wait for a complaint, investigation, data breach or regulatory inspection and then attempt to correct the problem. It must establish mechanisms before and throughout processing that are reasonably capable of preventing, identifying and correcting non-compliance.

1. Position of Article 24 within the GDPR

Article 24 appears in Chapter IV, Section 1, which deals with thegeneral obligations of controllers and processors.

Its position is significant.

The provision operates as a bridge between:

• the high-level accountability principle in Article 5(2);

• the governance and organisational requirements in Articles 24, 31;

• privacy by design and default under Article 25;

• processor governance under Article 28;

• records of processing under Article 30;

• security under Article 32;

• data protection impact assessments under Article 35; and

• the responsibilities of the Data Protection Officer under Article 39.

Article 24 should therefore not be read in isolation.

It establishes a general compliance architecture, while subsequent provisions impose more specific requirements.

For example:

Article 24 asks: What overall governance and risk-based measures has the controller established to ensure and demonstrate compliance?

Article 25 asks:

Has data protection been incorporated into the design and default configuration of processing systems?

Article 32 asks:

Are appropriate security measures in place?

Article 35 asks:

Has the controller formally assessed processing that is likely to result in high risk?

Article 30 asks:

Has the controller documented its processing activities?

Thus, Article 24 is both general and foundational.

2. The controller is the primary addressee

The opening words of Article 24 are:

“Taking into account the nature, scope, context and purposes of processing…”

The obligation is directed primarily at the controller.

This follows from the definition of controller in Article 4(7): the controller determines the purposes and means of processing.

The controller therefore occupies the central position in the GDPR's accountability framework.

The CJEU has emphasised this general responsibility in its case law. In C-492/23, Russmedia, the Court recognised the general accountability and compliance obligations imposed upon controllers by Articles 5(2) and 24.

This is important because organisations sometimes attempt to treat GDPR compliance as something that can simply be outsourced to:

• software vendors;

• cloud providers;

• processors;

• consultants;

• privacy platforms;

• cybersecurity providers; or

• external lawyers.

That is not how Article 24 operates.

A controller may delegate tasks, but it does not thereby delegate away its ultimate responsibility for ensuring that its own processing complies with the GDPR.

Example

A company uses a third-party HR platform to process employee information. The vendor provides:

• encryption;
• access controls;
• retention functionality;
• audit logs; and

• deletion mechanisms.

The company cannot simply say:

“The vendor handles GDPR.”

The company remains responsible for determining whether:

• the processing has an appropriate legal basis;

• only necessary data are collected;

• retention periods are justified;

• employees receive appropriate information;

• processor arrangements comply with Article 28;

• access rights can be exercised;

• security is appropriate;

• international transfers are lawful; and

• the vendor's technical capabilities actually support GDPR compliance.

The processor has its own obligations, but the controller remains accountable for the processing for which it determines the purposes and means.

3. Article 24 creates a proactive obligation

One of the most important characteristics of Article 24 is its proactive nature.

The controller must not merely respond to violations after they occur.

It must establish an environment in which compliance is built into the processing operation.

This means that the controller should consider compliance:

• before processing begins;

• when systems are designed;

• when vendors are selected;

• when new categories of personal data are introduced;

• when processing purposes change;

• when technologies change;

• when risks evolve;

• when laws or regulatory guidance change; and

• throughout the operational life of the processing.

Article 24 therefore embodies the idea that GDPR compliance is a continuing organisational function rather than a one-time legal exercise.

A privacy policy created in 2018 and never reviewed again cannot, by itself, demonstrate ongoing accountability in 2026.

Likewise, completing a DPIA once does not necessarily satisfy the continuing governance obligation if:

• the technology materially changes;

• the purposes expand;

• additional data are introduced;

• the number of affected individuals increases;

• new vulnerabilities emerge; or

• the risk profile changes.

4. “Ensure” compliance and “be able to demonstrate” compliance

The wording of Article 24 contains two separate but interconnected obligations:

“to ensure … that processing is performed in accordance with this Regulation”

and

“to be able to demonstrate” compliance.

These should not be treated as identical.

4.1. Ensuring compliance

The first obligation is substantive.

The controller must actually organise its processing so that it complies with the GDPR.

Example

if Article 5 requires data minimisation, the controller should establish processes that actually limit collection to necessary information.

If Article 17 requires erasure in applicable circumstances, the organisation should have systems capable of locating and deleting relevant information.

If Article 32 requires appropriate security, the organisation should actually implement suitable safeguards.

4.2. Demonstrating compliance

The second obligation is evidentiary.

The controller must be able to produce evidence showing that it has taken appropriate measures.

This could include:

• policies;

• procedures;

• contracts;

• DPIAs;

• risk assessments;

• records of processing;

• consent records;

• training records;

• audit reports;

• access logs;

• deletion logs;

• security assessments;

• vendor assessments;

• incident records;

• data-retention schedules;

• privacy notices;

• records of data-subject requests;

• technical documentation;

• governance minutes;

• testing results; and

• certification or code-of-conduct evidence.

The important point is that compliance without evidence may be difficult to demonstrate, particularly during regulatory scrutiny.

5. Accountability is broader than paperwork

A common misunderstanding is that accountability means maintaining a large collection of documents.

That is incorrect.

A controller does not become accountable merely because it has:

• a privacy policy;

• a GDPR manual;

• a data protection officer;

• a DPIA template; and

• a records-of-processing spreadsheet.

The underlying processing must actually comply.

Documentation is evidence of governance; it is not a substitute for governance.

Example

A company has a beautifully drafted retention policy stating: “Customer data shall be deleted after three years.” But its database technically retains the data indefinitely. The company cannot demonstrate genuine compliance merely by producing the policy. The policy says whatshould happen. The controller must also demonstrate what actually happens.

This distinction between documented intention and operational reality is central to Article 24.

6. “Appropriate technical and organisational measures”

Article 24 requires:

“appropriate technical and organisational measures”

The term “appropriate” is crucial.

The GDPR deliberately avoids prescribing one universal compliance package.

A hospital, an online retailer, a university and a small consultancy do not present identical privacy risks.

Accordingly, Article 24 adopts a risk-sensitive and context-dependent approach.

Technical measures generally concern technological mechanisms, while organisational measures concern governance, people, processes and institutional controls.

The distinction is not absolute.

7. Technical measures

Technical measures can include:

• encryption;

• pseudonymisation;

• access controls;

• authentication;

• multi-factor authentication;

• role-based permissions;

• network segmentation;

• logging;

• monitoring;

• automated deletion;

• data-loss prevention;

• backup controls;

• endpoint protection;

• secure configuration;

• vulnerability management;

• secure software development;

• database restrictions;

• tokenisation;

• masking; and

• privacy-enhancing technologies.

However, Article 24 does not say:

“Controllers must always use encryption.”

Instead, the controller must determine whether encryption or another measure is appropriate in light of the risks.

Article 32 contains more detailed security requirements, but those security measures can also form part of the broader accountability architecture under Article 24.

8. Organisational measures

Organisational measures include:

• privacy policies;

• internal procedures;

• staff training;

• governance structures;

• approval procedures;

• vendor-management processes;

• retention schedules;

• incident-response procedures;

• data-subject rights procedures;

• DPIA processes;

• privacy review procedures;

• access governance;

• internal audits;

• compliance monitoring;

• contractual controls;

• escalation mechanisms;

• employee confidentiality arrangements; and

• responsibility allocation.

Example

A company permits employees to work from home. Technical measures may include:

• VPN;
• MFA;
• endpoint encryption; and
• remote device management.

Organisational measures may include:

• a work-from-home policy;

• restrictions on family access to devices;

• reporting obligations for lost devices;

• mandatory security training; and

• procedures for handling personal data outside the office.

Neither dimension is necessarily sufficient alone.

9. The four-factor test: nature, scope, context and purposes

Article 24 expressly requires the controller to take into account:

1. nature;

2. scope;

3. context; and

4. purposes.

These factors form the foundation of the risk assessment.

9.1. Nature of processing

“Nature” concerns what is actually being done with the personal data.

The controller should consider:

• collection;

• recording;

• organisation;

• storage;

• consultation;

• use;

• disclosure;

• combination;

• profiling;

• monitoring;

• transfer;

• publication;

• deletion; and other processing activities.

The type of personal data also matters.

Processing:

• ordinary contact information,

is generally different from processing:

• health information;

• biometric information;

• financial information;

• precise location data;

• children's information; or

• information revealing political opinions.

Example

An organisation processing names and business email addresses for ordinary business communication faces a different risk profile from a healthcare provider processing detailed medical histories. The same technical measure may therefore not be equally appropriate in both environments.

10. Scope of processing

Scope concerns the scale and reach of the processing.

Relevant considerations include:

• number of data subjects;

• volume of personal data;

• duration;

• geographical reach;

• number of processing operations;

• number of systems involved;

• number of recipients;

• frequency of processing.

A database containing information about 500 individuals presents a different scale from a platform serving 50 million users.

Similarly, processing conducted only in one country differs from processing conducted across multiple jurisdictions.

11. Context of processing

Context refers to the circumstances surrounding processing.

This is often where the practical complexity of Article 24 becomes apparent.

Relevant considerations may include:

• the relationship between controller and data subject;

• reasonable expectations;

• whether individuals are vulnerable;

• whether processing is compulsory;

• whether data are publicly available;

• the technological environment;

• contractual relationships;

• regulatory requirements;

• power imbalances;

• the method of collection; and

• the circumstances in which data are used.

Example

Employee monitoring involves a fundamentally different context from ordinary customer analytics. The employer has organisational power over the employee, which may affect:

• expectations;
• freedom of choice;
• potential consequences; and
• the severity of harm.

The controller must therefore account for the context rather than simply assessing the technology in isolation.

12. Purposes of processing

The controller must also consider why the data are being processed.

Purpose is important because the same information can create different risks depending on its use.

For example:

A person's location information used to:

• provide navigation,

may present one risk profile.

The same location information used to:

• monitor employees;

• predict behaviour;

• assess insurance risk; or

• infer sensitive characteristics,

may create significantly greater risks.

Purpose therefore influences both the nature of the risk and the measures required.

13. Risks of varying likelihood and severity

Article 24 requires consideration of:

“the risks of varying likelihood and severity for the rights and freedoms of natural persons”

This wording is important because GDPR risk assessment is not simply about asking:

“Could something go wrong?”

Almost anything can go wrong.

The relevant questions are:

1. What could happen?

2. How likely is it?

3. How serious would the consequences be?

4. Whose rights and freedoms could be affected?

5. What safeguards reduce that risk?

14. Likelihood

Likelihood concerns the probability that a particular risk will materialise.

For example:

• accidental disclosure of an email may have moderate likelihood;

• sophisticated compromise of a highly protected system may have lower likelihood;

• unauthorised access caused by publicly shared passwords may have a much higher likelihood.

However, likelihood should be assessed realistically rather than mechanically.

A low-probability event can still require significant safeguards where the consequences are exceptionally severe.

15. Severity

Severity concerns the magnitude of harm if the risk materialises.

The GDPR recognises that harm may be:

• physical;

• material; or

• non-material.

Recital 75 provides a particularly important list of potential consequences, including:

• discrimination;

• identity theft;

• fraud;

• financial loss;

• reputational damage;

• loss of confidentiality;

• loss of control over personal data;

• social disadvantage;

• psychological or other serious effects.

Therefore, risk cannot be reduced to cybersecurity alone.

A privacy violation can exist even where there is no hacking incident.

16. Vulnerable individuals

Recital 75 specifically highlights vulnerable persons, including children.

This is important because the same processing operation can produce different levels of risk depending on the population affected.

Example

behavioural profiling of:

• sophisticated commercial users,

may involve one level of risk.

Profiling:

• children,

may involve substantially greater risks because children may have reduced understanding of the consequences of data processing.

This is particularly relevant when Article 24 is read together with:

• Recital 38;

• Article 8;

• Article 25; and

• Article 35.

17. Objective assessment of risk

Recital 76 states that risk should be evaluated through an objective assessment.

This prevents the controller from simply declaring:

“We believe the processing is low risk.”

The controller should be capable of explaining:

• the identified risks;

• the methodology;

• the assumptions;

• the likelihood assessment;

• the severity assessment;

• existing safeguards;

• residual risks; and

• the reasons for selecting particular measures.

This does not necessarily require one prescribed mathematical methodology.

The GDPR leaves methodological flexibility to controllers.

But the assessment should be reasoned, credible and proportionate.

18. Article 24 and the DPIA under Article 35

Article 24 and Article 35 are closely connected.

Article 35 requires a DPIA where processing is likely to result in a high risk to individuals.

Article 24, however, has a broader reach.

A controller may need to conduct risk assessment for Article 24 purposes even where Article 35 does not technically require a formal DPIA.

Therefore:

No DPIA does not mean no risk assessment.

The DPIA is a specific formal mechanism for high-risk processing.

Article 24 establishes the broader accountability obligation.

19. Appropriateness is not perfection

The GDPR does not require controllers to eliminate every conceivable risk.

The requirement is to implement measures that are appropriate.

This means proportionality matters.

A controller does not necessarily have to adopt:

• the most expensive technology;

• every available security tool;

• zero-risk architecture; or

• every possible privacy control.

Instead, it must determine what is reasonably appropriate in light of:

• the processing;

• risks;

• available technology;

• organisational circumstances;

• potential harm; and

• the rights and freedoms affected.

20. Article 24 requires effectiveness

A measure can exist formally but still fail functionally.

For example:

A company has an access-control policy but employees all share the same administrator account.

The organisation possesses a policy.

But the control may be ineffective.

Similarly:

A company has a deletion policy but has no technical mechanism to delete data from backup systems or subsidiary databases.

Again, formal documentation does not necessarily equal effective compliance.

Article 24 therefore requires measures capable of actually ensuring compliance.

21. Continuous review and updating

Article 24 expressly states:

“Those measures shall be reviewed and updated where necessary.”

This creates a dynamic obligation.

Compliance is not static.

Risk changes because:

• technology changes;

• threats change;

• business models change;

• laws change;

• processing purposes change;

• new vendors are introduced;

• new data categories are collected;

• new vulnerabilities emerge;

• organisational structures change; and

• regulatory expectations develop.

A controller must therefore periodically revisit its measures.

22. What triggers review?

A review may become particularly necessary following:

• a data breach;

• a near-miss incident;

• a significant change in processing;

• introduction of AI systems;

• implementation of new monitoring technologies;

• introduction of biometric processing;

• acquisition or merger;

• new processor arrangements;

• expansion into another jurisdiction;

• new categories of personal data;

• changes to retention periods;

• regulatory guidance;

• enforcement decisions; or

• identification of a new security vulnerability.

Example

A company initially uses a customer database only for order fulfilment. Later it introduces:

• AI-based profiling;
• personalised advertising;
• behavioural analytics; and
• automated credit decisions.

The original Article 24 assessment may no longer be adequate.

The processing has fundamentally changed in:

• nature;

• purpose;

• context;

• risk; and potentially

• scope.

The organisation should therefore reassess its measures.

23. Article 24(2): Data protection policies

Article 24(2) provides:

“Where proportionate in relation to processing activities, the measures referred to in paragraph 1 shall include the implementation of appropriate data protection policies by the controller.”

The word “shall” is important, but it is qualified by:

“Where proportionate…”

Therefore, the GDPR does not impose an identical policy architecture on every organisation.

The controller must determine whether policies are proportionate to its processing activities.

For a large organisation processing millions of records, detailed internal policies will generally be difficult to avoid.

Such policies might address:

• data classification;

• retention;

• deletion;

• access management;

• data-subject requests;

• breach response;

• employee monitoring;

• CCTV;

• BYOD;

• remote work;

• vendor management;

• international transfers;

• AI use;

• data minimisation;

• privacy by design;

• children's data;

• special-category data; and

• incident escalation.

24. Policies must have operational value

A GDPR policy should not merely be aspirational.

A useful policy should answer:

• Who is responsible?

• What must employees do?

• When must they do it?

• What information may be collected?

• How long may it be retained?

• Who may access it?

• What happens when something goes wrong?

• Who must be notified?

• What evidence must be maintained?

Example

A “Data Retention Policy” stating: “The company shall retain data only as long as necessary” may be legally correct but operationally weak. A stronger policy might identify:

• specific categories;
• retention periods;

• responsible teams;

• deletion triggers;

• exceptions;

• legal holds;

• technical deletion mechanisms; and

• periodic review requirements.

That makes the policy a genuine organisational measure.

25. Article 24 and the Data Protection Officer

Where an organisation has a DPO, Article 39 becomes highly relevant.

The DPO's functions include:

• monitoring compliance;

• providing advice;

• raising awareness;

• training staff;

• conducting audits; and

• advising regarding DPIAs.

The DPO can therefore contribute substantially to the Article 24 accountability framework.

However, the DPO does not replace the controller's responsibility.

The organisation cannot say:

“Our DPO is responsible for GDPR, therefore the business is not responsible.”

The DPO advises and monitors.

The controller remains responsible for compliance.

26. Article 24 and Article 25

Article 24 and Article 25 are closely connected but perform different functions.

Article 24 focuses on:

overall responsibility, accountability and appropriate measures.

Article 25 focuses specifically on:

data protection by design and by default.

Suppose a company develops an AI recruitment platform.

Article 24 requires the organisation to establish governance capable of ensuring compliance.

Article 25 requires privacy considerations to be incorporated into the system's design and default settings.

Thus, Article 24 provides the governance framework within which Article 25 operates.

27. Article 24 and Article 32

Article 32 provides specific security requirements.

Article 24 is broader.

Security is only one aspect of GDPR compliance.

A company can have excellent cybersecurity and still violate Article 24 through:

• unlawful processing;

• excessive data collection;

• inadequate transparency;

• unlawful retention;

• lack of rights procedures;

• invalid legal basis; or

• unlawful international transfers.

Conversely, Article 32 security requirements can form part of the measures required under Article 24.

28. Article 24 and Article 30

Article 30 requires records of processing activities in applicable circumstances.

Those records are extremely useful for Article 24 accountability.

A controller cannot effectively assess its compliance risks if it does not know:

• what data it processes;

• why it processes them;

• where they are stored;

• who receives them;

• how long they are retained; and

• where transfers occur.

Therefore, the ROPA frequently becomes a foundational accountability instrument.

29. Article 24 and Article 28: processors

Article 24 does not turn the processor into the controller.

But the controller must carefully govern processor relationships.

This includes:

• due diligence;

• contractual requirements;

• security assessment;

• subprocessor governance;

• audit rights;

• deletion/return obligations;

• incident management; and

• monitoring.

A controller that selects a processor without examining its capabilities may struggle to demonstrate that it took appropriate measures.

30. Supply-chain accountability

Modern processing rarely occurs entirely within one organisation.

Controllers commonly rely on:

• cloud providers;

• SaaS vendors;

• analytics providers;

• payment providers;

• HR platforms;

• CRM providers;

• AI providers;

• hosting providers; and

• cybersecurity providers.

Article 24 therefore has an important supply-chain dimension.

A controller should understand whether its suppliers enable or undermine compliance.

Example

An SME adopts software from a dominant technology vendor. The software automatically transfers employee information to servers outside the EEA without adequate safeguards. The SME may have limited technical control over the product, but that does not automatically eliminate its responsibility as controller. It may need to:

• assess the vendor;
• modify configuration;

• negotiate contractual protections;

• restrict functionality;

• implement alternative measures; or

• choose another provider.

31. Demonstrating compliance through evidence

Article 24 does not prescribe a single form of evidence.

Different processing activities require different evidence.

Possible evidence includes:

Governance evidence

• privacy policies;

• governance charters;

• responsibility matrices;

• DPO reports;

• committee minutes.

Processing evidence

• ROPA;

• data-flow maps;

• processing inventories;

• system inventories.

Legal evidence

• legal-basis assessments;

• legitimate-interest assessments;

• consent records;

• transfer assessments;

• contracts.

Risk evidence

• risk assessments;

• DPIAs;

• threat assessments;

• residual-risk evaluations.

Technical evidence

• access logs;

• encryption records;

• penetration tests;

• vulnerability reports;

• deletion logs.

Training evidence

• attendance records;

• training completion;

• assessments;

• awareness campaigns.

The objective is to establish a credible audit trail of accountability.

32. Article 24(3): Codes of conduct

Article 24(3) expressly recognises:

approved codes of conduct under Article 40

as an element that may demonstrate compliance.

Codes of conduct can provide sector-specific guidance.

They are particularly useful because GDPR obligations sometimes require contextual interpretation.

Example

a code may establish industry-specific approaches concerning:

• retention;

• transparency;

• security;

• processing standards;

• rights procedures.

But adherence to a code does not create an absolute safe harbour.

The wording “may be used as an element” is deliberate.

It is evidence supporting compliance, not an automatic guarantee of compliance.

33. Certification mechanisms

Article 24(3) similarly recognises approved certification mechanisms under Article 42.

Certification can provide evidence that an organisation or processing operation has been assessed against specified requirements.

But certification should not be misunderstood as:

“Certification = complete GDPR compliance.”

Certification is an element of demonstration.

The controller remains responsible for compliance with the GDPR as a whole.

34. Codes and certification cannot override the GDPR

Suppose a company follows an industry code that permits retention for five years.

If the controller's particular processing requires deletion after a shorter period under Article 5(1)(e), following the code does not automatically make five-year retention lawful.

The GDPR remains the superior legal standard.

Article 24(3) therefore creates evidentiary value rather than immunity.

35. Article 24 and accountability culture

Article 24 is ultimately about organisational culture.

A mature GDPR programme should not operate as:

“The legal department owns privacy.”

Instead, responsibility should be distributed throughout the organisation.

For example:

Management

• establishes governance and resources.

Legal/privacy team

• advises on legal requirements.

IT/security

• implements technical safeguards.

HR

• governs employee data.

Procurement

• conducts vendor assessments.

Product teams

• integrate privacy into design.

Marketing

• respects lawful processing and consent requirements.

Engineering

• implements technical privacy controls.

Business teams

• ensure actual operational compliance.

This is what accountability looks like in practice.

36. Article 24 in AI governance

Article 24 has become particularly significant in the context of AI.

Consider an organisation deploying an AI system that:

• profiles customers;

• predicts fraud;

• ranks applicants;

• recommends insurance premiums;

• analyses employee performance; or

• makes automated decisions.

Article 24 requires the controller to ask:

• What personal data are being processed?

• Why?

• Is the purpose lawful?

• What risks arise?

• Could the system discriminate?

• Is the output accurate?

• Who reviews decisions?

• How can individuals exercise their rights?

• What documentation exists?

• How is the system monitored?

• What happens when the model changes?

The controller cannot simply say:

“The AI vendor built the model.”

The accountability obligation follows the controller.

37. Article 24 and discrimination risk

Recital 75 expressly recognises discrimination as a possible risk.

This is particularly significant for:

• recruitment;

• credit;

• insurance;

• housing;

• education;

• advertising;

• fraud detection; and

• public-sector decision-making.

Suppose an AI recruitment system systematically ranks applicants from a particular demographic lower.

Even if the organisation never intentionally sought to discriminate, the processing may create serious risks to individuals.

Article 24 therefore requires the controller to consider the risks associated with the processing and implement appropriate measures.

Such measures may include:

• bias testing;

• data-quality controls;

• human review;

• documentation;

• monitoring;

• model validation; and

• corrective procedures.

38. Article 24 is not a one-time compliance checklist

This is perhaps the most important practical lesson.

A controller should not approach Article 24 as:

“Have we completed the GDPR checklist?”

Instead:

“Do we continuously have a credible system for ensuring, monitoring, reviewing and demonstrating GDPR compliance?”

That is a substantially higher standard.

39. A practical Article 24 compliance framework

A controller can operationalise Article 24 through the following cycle:

Step 1 - Identify processing

Create an inventory of:

• systems;

• data;

• purposes;

• data subjects;

• recipients;

• processors.

Step 2 - Assess risk

Evaluate:

• nature;

• scope;

• context;

• purposes;

• likelihood;

• severity.

Step 3 - Select measures

Implement:

• technical controls;

• organisational controls;

• contractual controls;

• governance measures.

Step 4 - Document

Maintain:

• policies;

• assessments;

• records;

• approvals;

• evidence.

Step 5 - Monitor

Track:

• incidents;

• complaints;

• changes;

• audit findings;

• regulatory developments.

Step 6 - Review

Reassess when:

• processing changes;

• risks change;

• technology changes;

• law changes.

Step 7 - Improve

Update measures where necessary.

This produces a continuous accountability loop:

Identify → Assess → Implement → Document → Monitor → Review → Improve.

40. Key legal nuance: Article 24 does not require identical measures

A common error is to ask:

“What technical and organisational measures does Article 24 require?”

There is no universal list.

The correct question is:

“What measures are appropriate for this particular processing operation, considering its nature, scope, context, purposes and risks?”

This is why Article 24 is inherently contextual.

A measure appropriate for:

• a hospital,

may be disproportionate for:

• a small business processing ordinary business contacts.

Conversely, measures appropriate for a small business may be completely inadequate for:

• a national health database.

41. Article 24 and proportionality

The proportionality principle prevents both extremes.

The controller should avoid:

Under-protection

Implementing insufficient safeguards despite serious risks.

And:

Arbitrary over-engineering

Implementing burdensome controls without considering the actual processing context.

The objective is appropriate protection proportionate to the risks.

However, proportionality should not become an excuse for weak compliance.

The controller must be able to justify why its measures are appropriate.

42. The evidentiary significance of Article 24

Article 24 has substantial importance in regulatory investigations and disputes because it asks not merely:

“Did something go wrong?”

but also:

“What system did the controller have in place to prevent, detect and respond to the problem?”

Example

after a breach, the authority may examine:

• Was there a security assessment?

• Were risks identified?

• Were employees trained?

• Were access controls implemented?

• Were vulnerabilities known?

• Were policies reviewed?

• Were warnings ignored?

• Were measures tested?

• Was the processor properly assessed?

The existence and effectiveness of the accountability framework can therefore become highly significant.

43. Article 24 and regulatory expectations

Recital 77 recognises that controllers may draw upon:

• approved codes of conduct;

• certification;

• EDPB guidance;

• DPO advice; and

• other recognised best practices.

This is important because Article 24 is deliberately open-ended.

Controllers therefore benefit from monitoring authoritative regulatory guidance relevant to their processing activities.

A controller should not assume that compliance analysis ends with reading the text of the GDPR.

44. Relationship with Article 5(2): the accountability principle

Article 5(2) states the general principle:

the controller shall be responsible for, and be able to demonstrate compliance with, the principles of Article 5(1).

Article 24 expands that logic.

Article 5(2) essentially says:

You are accountable.

Article 24 says:

Here is part of how you operationalise that accountability.

Consequently, Article 24 is best understood as one of the principal implementation mechanisms for the GDPR's accountability principle.

45. The significance of Article 24 for privacy programmes

For a modern organisation, Article 24 can form the foundation of an enterprise privacy programme.

A mature programme may include:

• governance framework;

• privacy policies;

• ROPA;

• data inventory;

• legal-basis assessments;

• DPIA process;

• vendor-management programme;

• data-subject rights procedures;

• breach response;

• retention management;

• privacy-by-design process;

• employee training;

• monitoring;

• audits;

• certification;

• continuous improvement.

Article 24 provides the legal justification for viewing these not as isolated compliance exercises but as components of a broader accountability system.

46. A consolidated example

Consider an online financial-services company that processes:

• identity information;

• financial information;

• transaction history;

• location information;

• behavioural data.

It uses:

• cloud infrastructure;

• third-party analytics;

• AI fraud detection; and

• automated credit scoring.

Article 24 requires the company to consider:

Nature

Financial and behavioural data are involved, with profiling and automated decision-making.

Scope

Millions of customers may be affected across multiple jurisdictions.

Context

Financial decisions can have substantial consequences for individuals.

Purpose

The processing serves fraud prevention, credit assessment and customer management.

Risks

Potential harms include:

• financial loss;

• discrimination;

• identity theft;

• reputational harm;

• exclusion from services;

• inaccurate decisions.

Measures

The controller might therefore need:

• strong access controls;

• encryption;

• pseudonymisation;

• model governance;

• bias testing;

• accuracy controls;

• human review;

• retention controls;

• vendor due diligence;

• DPIAs;

• incident response;

• employee training;

• rights-management procedures.

Demonstration

It should also retain evidence showing:

• why those measures were selected;

• what risks were identified;

• how the controls operate;

• how they are tested;

• when they are reviewed; and

• what corrective actions were taken.

This is Article 24 in operation.

47. Important distinction: compliance versus accountability

It is useful to distinguish three concepts:

Compliance

The processing actually satisfies the GDPR.

Accountability

The controller has systems and governance designed to ensure compliance.

Demonstrability

The controller can produce credible evidence showing that it has fulfilled its responsibilities.

A mature organisation requires all three.

48. Final doctrinal understanding of Article 24

Article 24 should ultimately be understood as a governance obligation rather than merely a security provision or documentation requirement.

It imposes upon controllers a continuing duty to:

1. understand their processing;

2. assess the risks;

3. implement appropriate technical and organisational measures;

4. establish appropriate policies where proportionate;

5. ensure actual compliance;

6. maintain evidence of compliance;

7. monitor the effectiveness of measures;

8. review those measures when circumstances change; and

9. continuously improve the organisation's privacy framework.

The provision therefore transforms the GDPR from a collection of isolated legal rules into a system of continuous organisational accountability.

The essential principle can be expressed as follows:

A controller must not merely claim that it complies with the GDPR; it must organise its processing in a manner that makes compliance real, proportionate to risk, operationally effective, continuously reviewed, and capable of being demonstrated with credible evidence.

That is the central meaning of Article 24.

Key Takeaways

Element	Article 24 requirement
Who?	Controller
What?	Appropriate technical and organisational measures
Why?	To ensure GDPR compliance
Additional duty	Demonstrate compliance
Risk factors	Nature, scope, context and purposes
Risk dimensions	Likelihood and severity
Policies	Required where proportionate
Review	Measures must be reviewed and updated where necessary
Evidence	Policies, records, assessments, audits, technical evidence etc.
Codes	Approved codes may support demonstration
Certification	Approved certification may support demonstration
Underlying principle	Accountability
Character	Proactive, continuous and risk-based