Art.24 GDPR

GDPR Art.24: Responsibility of the Controller

What This Control Requires

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.

In Plain Language

The buck stops with the controller. Article 24 makes it clear that if you determine why and how personal data gets processed, you're responsible for making sure everything complies with the GDPR - and you need to be able to prove it.

This is a risk-based obligation, so proportionality matters. A small consultancy handling basic client contact details doesn't need the same controls as a health-tech company processing millions of medical records. You assess the nature, scope, context, and purpose of your processing, evaluate the risks to individuals, and calibrate your measures accordingly.

Compliance isn't something you set up once and forget about. Article 24 explicitly requires you to review and update your measures as things change - new processing activities, evolving threats, updated regulatory guidance, organisational restructuring. And the accountability principle under Article 5(2) means you need a paper trail: documentation, audits, and evidence that your controls actually exist and work.

How to Implement

Put a governance structure in place with clear accountability. Data protection needs a senior owner - someone at board or executive level who is responsible for it. Designate a DPO or data protection lead, and define who does what across departments. Make data protection part of business decision-making, not something that gets tacked on after the fact.

Run a proper risk assessment of your processing activities. Evaluate each activity against the nature, scope, context, and purposes criteria, and assess the risks to individuals. Use a consistent methodology that accounts for both likelihood and severity of potential harm. Document everything and use the results to prioritise where you invest your compliance effort.

Choose technical measures that match the risks you've identified. Encryption, pseudonymisation, access controls, data loss prevention, backup and recovery, monitoring and logging, secure development practices - pick what's appropriate based on your specific risk profile and what's realistically available. Don't gold-plate low-risk processing, but don't cut corners on high-risk activities either.

Embed data protection into how the organisation actually operates. Write and enforce clear policies and procedures. Run training and awareness programmes. Establish incident response and breach notification processes. Conduct regular compliance audits. Maintain your Records of Processing Activities. These aren't just box-ticking exercises - they're what regulators will ask to see.

Build a continuous improvement cycle. Schedule regular reviews of your risk assessments, policies, and technical controls. Watch for changes that might require updates - new processing activities, shifts in the threat landscape, fresh regulatory guidance. Keep an audit trail of what you reviewed, what you found, and what you did about it. Report compliance status to senior management regularly so it stays on the agenda.

Evidence Your Auditor Will Request

Data protection governance framework with defined roles, responsibilities, and accountability
Risk assessment documentation for processing activities
Technical and organisational measures documentation proportionate to identified risks
Evidence of regular review and updating of compliance measures
Senior management reporting on data protection compliance status

Common Mistakes

No formal risk assessment conducted, leading to disproportionate or inadequate compliance measures
Compliance measures implemented once but never reviewed or updated
Data protection treated as an IT-only issue rather than an organisational responsibility
Inability to demonstrate compliance through documentation and evidence
No senior management oversight or accountability for data protection

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.1	Related
ISO 27001	A.5.2	Related
NIS2	Art.20	Related

Frequently Asked Questions

What is the difference between a controller and a processor?

A controller decides the why and how of processing - the purposes and means. A processor handles data on the controller's behalf, following their instructions. You can be both for different activities. The defining question is always: who is making the decisions about why data is being processed?

How do we demonstrate compliance?

Through documentation that tells a coherent story. Records of processing activities, policies and procedures, risk assessments, DPIAs, training records, audit reports, breach logs, data subject request records, processor agreements, and evidence of regular reviews. When a regulator looks at it, they should be able to see a functioning data protection programme, not just a stack of templates.

How often should compliance measures be reviewed?

At least annually as a baseline, but also whenever something significant changes - new processing activities, new technology, organisational restructuring, or updated regulatory guidance. High-risk processing deserves more frequent attention. Each review should ask whether your existing measures still match your current risk profile.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment