What Article 24 GDPR asks controllers to prove
Article 24 requires the controller to implement appropriate technical and organisational measures that ensure and can demonstrate that processing complies with the GDPR, taking into account the nature, scope, context and purposes of the processing and the risks to individuals. The measures must be reviewed and updated where necessary. If you are a compliance lead or engineer, the practical question is not whether a control exists on paper but whether you can show a regulator or customer that it operates and that someone revisits it when the processing changes. Article 24 is the anchor for much of the rest of the regulation: the security duty in Article 32, the design duty in Article 25 and the processor contract rules in Article 28 all rest on the same principle that the controller is accountable.
Article 24(2) adds that, where proportionate to the processing, these measures include appropriate data protection policies. Article 24(3) allows adherence to approved codes of conduct or approved certification mechanisms to be used as an element to demonstrate compliance. Read that carefully. A certificate is supporting evidence, not a shield. Certification under Article 42 is voluntary, lasts for a limited period and does not reduce the controller's or processor's responsibility. Before you invest in any certification, confirm with the certification body and your supervisory authority which mechanisms are approved and how they would be assessed for your processing. The GDPR itself requires no audit, attestation or certificate, so the evidence you build for Article 24 should stand on its own.
Article 24 is hard because it is principle-based. Nothing in the text tells you which controls are enough for your organisation, so the work is deciding what is appropriate for your risks, documenting that decision and keeping the proof current as systems, vendors and purposes change. Regulators take this seriously: when setting a fine, supervisory authorities consider the degree of responsibility of the controller or processor, including the technical and organisational measures implemented under Articles 25 and 32 (Article 83(2)(d)). In practice, that means the policies, risk assessments, configuration records, access reviews and change history you can produce on request are part of your fine exposure as well as your defence. Start by listing the processing activities in scope, the risk judgement behind each measure, and the owner who reviews it.
Which processing, systems and teams Article 24 covers
Article 24 applies to whatever the organization decides about personal data, so the first effort is deciding where that boundary sits. The cards below cover the scoping decisions that change how much evidence the controller must produce and who must produce it.
Every processing activity where you are controller
Start with a list of processing activities in which your organization decides the purposes and means, such as customer onboarding, payroll, marketing or support tickets. Each activity carries its own risk, its own measures and its own evidence, so an activity missing from the list is an activity without a demonstrable control. Check that the list matches the record of processing and that activities run by business units outside IT are included.
Systems and data stores holding that data
Map each application, database, file share, backup set, log store and analytics pipeline that holds personal data for those activities. Copies in test environments, exports sent to spreadsheets and archives count as well. The effort grows with the number of stores, because each one needs measures that can be described, tested and shown to a supervisory authority.
Teams that set purposes and run systems
Two groups usually hold different parts of the controller duty: the business owners who decide why data is processed, and the platform or IT teams who decide how systems run. Article 24 responsibility sits with the organization, so each measure needs a named owner in both groups. Check that roles, approvals and change records show who made each decision.
Processors whose evidence feeds your demonstration
Hosting providers, SaaS vendors and managed service firms that process data on your behalf will produce part of the evidence you need to show compliance. Collect their security reports, sub-processor lists and incident notices into your own evidence file, and confirm what each contract lets you request. Responsibility for the overall outcome stays with you even when a processor performs the work.
Self-hosted platforms inside your boundary
When platforms run in your own cloud accounts, data centers or air-gapped networks, your team owns the configuration, patching, access and logging directly, so those controls appear in your scope with no processor in between. Confirm which components the vendor or implementation partner touches during setup and which remain under your administration after handover.
How an assessor tests Article 24 in practice
This table sets out the steps a supervisory authority or audit-style assessor takes to test Article 24, what each step asks the controller to produce, and the findings that appear most often. Read it as a checklist: if a step cannot be evidenced, the measures behind it are unlikely to be accepted as demonstrating compliance.
| Test step | Evidence requested | Common findings |
|---|---|---|
| Confirm the risk assessment that drives measures | Documented assessment of processing nature, scope, context and purposes, with risks to individuals and the measures chosen against each risk | Risk assessment is missing, generic or dated before the system changed; measures cannot be traced to any identified risk |
| Check the policy set and its approval | Data protection policies with version history, named approver, approval date and the systems or teams they bind | Policies exist but were never approved by management; policies name roles or tools the organization no longer uses |
| Check review dates and review records | Scheduled review dates, minutes or sign-offs showing reviews happened, and a list of changes made as a result | Review dates have passed with no record of review; reviews are recorded as complete without any changed content |
| Sample evidence that measures operate | Access review exports, configuration screenshots or logs, training completion records and sample tickets for the period tested | Policy describes a control that no system enforces; evidence covers only the day of the audit rather than the whole period |
| Trace changes that should trigger review | Change records for new processing purposes, new systems, new processors or incidents, and the reassessment linked to each | New systems go live with no reassessment; changes are logged but never linked back to the risk assessment or policies |
| Verify demonstrability | Single location where an auditor can find policies, risk records, review history and sample evidence, with version history | Evidence is spread across personal drives and email; the organization cannot show which version was in force on a given date |
| Check use of codes of conduct or certification | Approved code or certificate scope, its validity period and the gap analysis against the controller's own processing | Certificate is cited as proof of compliance without checking that its scope covers the processing under review |
How to build the Article 24 control set step by step
This sequence turns the general duty in Article 24 into a working control set, where each step produces a document or record that shows the controller can both meet the duty and demonstrate it.
Inventory processing activities and their risks
Start by listing every processing activity that involves personal data, including the purpose, the categories of data subjects and personal data, the systems and locations involved, and the processors used. For each activity, record the risk to individuals in plain terms, such as loss of confidentiality, unwanted disclosure or inability to exercise rights. The output is a processing inventory with a risk note against each entry, which later steps use as the basis for every measure. Confirm the inventory is complete by checking it against application catalogs, cloud accounts and vendor contracts, not only against the policy owner's memory.
Define the measures and the policy hierarchy
Using the risk notes, decide which technical and organizational measures apply to each activity or group of activities, such as access control, encryption, logging, retention limits and staff training. Arrange them in a hierarchy: a top-level data protection policy, standards that set minimum requirements, and procedures or runbooks that describe the steps. Article 24(2) makes policies a measure where proportionate, so the policy set should be proportionate to the size and risk of the processing. The output is an approved measures catalog that links each measure to the risks it addresses and to the policy that governs it.
Assign accountable owners for each measure
Give every measure a named owner who answers for its operation, along with a deputy where the measure depends on one person. Owners should come from the business and technology functions that run the system, not only from the compliance team, because the controller remains responsible for compliance. Record who approves exceptions and who may accept residual risk. The output is an ownership register that lists each measure, its owner, its approver and its escalation route. Confirm that each owner has accepted the role in writing and understands what evidence they must produce.
Map measures to systems and processors
Trace each measure to the systems, configurations and processors where it is actually applied. For a self-hosted platform, this means linking the access policy to the directory service, the encryption setting to the storage configuration, and the logging requirement to the log pipeline and retention store. Where a processor runs part of the processing, record which of its controls the controller relies on and where the processor contract sets those obligations. The output is a control-to-system map that shows gaps where a measure is written in policy but not configured anywhere.
Set a review cycle with defined triggers
Article 24(1) requires measures to be reviewed and updated where necessary, so the control set needs both a scheduled review and event-driven triggers. Scheduled reviews should cover the full measures catalog and the owner register. Triggers typically include a significant system change, a new processing purpose, a security incident or near miss, a new processor, a change in law or regulatory guidance, and a material change in the risk assessment. Record the chosen review interval and the trigger list in the policy so that the cadence can be checked later. The output is a review schedule and a trigger list approved by the accountable executive.
Collect evidence as a routine output
Design each measure so that it produces evidence as a normal by-product of operation, rather than assembling proof only when an assessor or regulator asks. Examples include access review records, configuration baselines exported on a schedule, change tickets linked to privacy reviews, training completion logs and version-controlled policy documents. Store evidence where its integrity and history can be shown, and set retention periods that match the controller's own policy. The output is an evidence index that maps each measure to the artefacts that demonstrate it and to the date of the most recent review. Confirm with the independent auditor or supervisory authority which evidence forms they expect before the index is finalized.
How policies, codes of conduct and certification fit as evidence
Article 24 does not make a written policy mandatory in every case. Under Article 24(2), data protection policies are one of the measures a controller implements where they are proportionate to the processing activities. The practical question for you is whether your processing is large, sensitive or complex enough that a policy set is the expected way to show management direction and staff rules. Where it is, the policies should name owners, state the rules that engineers and support staff must follow, and be reviewed when processing changes. A controller with a small, low-risk processing footprint may need less, but should be able to explain that judgment and record it.
Article 24(3) allows adherence to an approved code of conduct or an approved certification mechanism to be used as an element to demonstrate compliance. The word that matters is *element*. A code or certificate adds to your evidence file, but it does not replace the work of showing that your own measures fit your own risks. Article 42 certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the responsibility of the controller or processor. Confirm with your supervisory authority and the certification body you are considering which schemes are approved, what scope they cover, and how they expect the certificate to be presented in an investigation or customer audit. Acceptance varies by Member State and by authority, so do not assume a certificate obtained in one country carries the same weight elsewhere.
Evidence that satisfies Article 24 and how to keep it current
Article 24 asks the controller to demonstrate compliance, not just to have measures in place. The artefacts below are the records an assessor or supervisory authority will ask for, and each one needs an owner and a trigger that tells someone when to update it between reviews.
Risk assessment register
This register links each processing activity to the risks it creates for individuals, the likelihood and severity you assessed, and the date of that assessment. Article 24(1) ties the measures to the nature, scope, context and purposes of processing, so the register is the starting point for every other artefact. Check that each entry names an owner, that new systems and vendors add entries before launch, and that a change in purpose or data category reopens the entry.
Approved policy set with version history
Article 24(2) expects appropriate data protection policies where they are proportionate to the processing. Keep each policy with an approval date, an approver, a version number and the previous versions, so you can show which rule applied on the day of an incident. Review triggers should include a change in law, a material incident, a new processing purpose or a change in the organization's structure.
Measure-to-risk mapping
This document shows which technical and organizational measure addresses which risk in the register, and who checked that the measure is adequate. An assessor will look for gaps, such as a risk with no measure or a measure with no risk behind it. Re-run the mapping whenever a risk entry changes, and record the reason when a measure is removed or replaced.
Control operating records
These are the logs, tickets and reports that show a measure ran as described: access reviews, backup restore tests, patch records and configuration baselines. Article 24 requires demonstration, so a policy with no operating record is weak evidence. Assign each control an owner and a frequency, and flag any period where the record is missing, because that gap is what an assessor tests first.
Review minutes and change logs
Article 24(1) requires measures to be reviewed and updated where necessary, so minutes from periodic reviews and a change log for policies, risk entries and configurations are core evidence. Minutes should record decisions, the people present and the follow-up owners. Keep the change log tied to a named approver, and confirm that reviews happen on a schedule and after triggering events, not only before an audit.
Processor assurance and training records
Controllers keep records showing that processors and staff were chosen, instructed and trained in line with the controller's measures. Processor assurance covers contract terms, security questionnaires and audit reports you reviewed, with dates and reviewers. Training records show who completed which module and when. Schedule a recheck for each processor when its service, location or sub-processors change, and retrain staff after policy revisions.
What meeting Article 24 costs in money and effort
This table breaks down the cost components of meeting Article 24, showing who is paid for each, whether the cost is one-time or recurring, and what moves it up or down. No fees or durations are given because none were supplied, so use the drivers to build a written scope and request an itemised quote.
| Cost component | One-time or recurring | Who is paid or who does the work | What drives it up or down |
|---|---|---|---|
| Risk assessment and scoping of processing | One-time, then repeated when processing changes | Internal privacy and security staff, sometimes an outside facilitator | Number of processing activities, data categories and systems in scope; a clear inventory lowers effort |
| Drafting data protection policies | One-time, then recurring review | Internal legal and compliance staff, optionally an external lawyer or consultant | Number of policies needed, existing templates, and how many business units must approve them |
| Legal review of policies and controller positions | Recurring when law or guidance changes | External counsel or in-house legal, billed by hour or by fixed fee | Jurisdictions served, sector rules layered on top of the GDPR, and how much existing text can be reused |
| Engineering time to implement technical measures | One-time build, with ongoing change effort | Internal engineers, or an implementation partner under a fixed-scope agreement | Age of the platform, how many systems hold personal data, and whether controls are built in or retrofitted |
| Records, evidence and version control tooling | Recurring licence or hosting cost, unless self-hosted | Software vendor or open-source operator, plus internal administration time | Number of users, retention periods, and whether the tool is commercial or self-hosted open source, which removes licence spend |
| Evidence upkeep and periodic review | Recurring, usually scheduled | Internal control owners who collect and check evidence | Frequency of reviews, number of controls, and whether evidence is captured automatically from logs and tickets |
| Optional external review or testing | Recurring if repeated, usually one-time per engagement | Independent auditors or testers, who are separate from any party that built the controls | Scope of the review, whether it covers only policies or also technical controls, and the depth of sampling |
Which self-hosted open-source tools produce Article 24 evidence
CISO Assistant has the broadest reach for Article 24 because it ships GDPR among more than 200 frameworks. The controller can hold its measure register, framework mappings and assessment records in one place instead of spreading them across separate spreadsheets. Its automatic mapping between frameworks also lets one measure serve several obligations, which helps when GDPR overlaps with ISO 27001 or SOC 2 controls.
- Measure register: Record each technical and organizational measure with its owner, the risk it addresses and its review date, so the set can be shown as reviewed and updated.
- Framework mapping: Reuse one measure across GDPR and other frameworks in scope, after checking that each mapping matches your own reading of the text.
- Assessment records: Store compliance assessments against the GDPR framework with dates, results and linked evidence.
- Governance history: Keep the policy set, roles and assessment history together for management review.
Confirm which GDPR framework content your release includes, and test the mappings against your legal and compliance reading before relying on them. The CISO Assistant README describes the project's current feature set.
Article 24(2) expects appropriate data protection policies where they are proportionate to the processing. XWiki suits the written policy set because it keeps every change under version control. An assessor who asks what a policy said on a given date can get an answer from the page history rather than from memory or a shared drive copy.
- Change history: Each change is recorded with what changed, when and by whom, which gives a dated trail of how each policy evolved.
- Version comparison: Compare any two versions to show the difference between the policy in force during an incident and the version that followed it.
- Rollback: Return a page to an earlier version when a change was wrong. Confirm how rollbacks appear in the history in your release.
- Review and approval records: Use pages to hold review dates and sign-off notes. Confirm whether your version has a built-in approval workflow or whether approvals need a separate step.
Check how the history is kept through backups, exports and any future migration, because the page history is only useful evidence if it survives those steps. The XWiki blog post on document version control explains the versioning model.
Article 24 places compliance responsibility on the controller, so each policy needs a named owner who can show that the policy is maintained. BookStack suits this role because user abilities come from the roles assigned to each person. Permissions can be overridden per role at the shelf, book, chapter or page level, which lets policy ownership follow the organization's accountability structure.
- Role-based abilities: Define roles such as policy owner, approver and reader, and assign them according to function.
- Granular overrides: Set permissions at shelf, book, chapter or page level. For example (illustrative), a privacy team could edit the transfers chapter while other staff only read it.
- Named ownership: Assign each policy page to an accountable owner, so the record shows who is responsible for keeping it current.
- Access records: Review role assignments and page permissions periodically. Confirm what export or reporting options your version provides for this review.
Test the permission model by signing in as each role and confirming that access matches what the policy says. The BookStack roles and permissions documentation sets out how overrides are applied.
Each tool's licence affects how you deploy, modify and share it, and the licence should be settled before the tool becomes part of your evidence chain. No tool makes the organization compliant. Article 24 places the duty on the controller, and an assessor will test whether the measures actually operated, not whether a platform holds the right records.
- CISO Assistant (AGPL-3.0-only): This is a strong copyleft licence. If you modify the software and make it available to users over a network, obligations to offer the modified source may apply. Get legal review before changing it.
- XWiki (LGPL-2.1-or-later): This is a weak copyleft licence. Its obligations attach mainly to modifications of the licensed components, so custom extensions need a licence review.
- BookStack (MIT): This is a permissive licence. Keep the copyright and licence notice when you redistribute the software.
- Evidence limits: The tools store records and show history. They do not perform the controls, so the organization still needs to operate and prove each measure.
Ask counsel to confirm the licence obligations for your specific modifications and deployment model before you build on any of these tools.
Where organisations fall short on Article 24
Article 24 asks for measures that are risk-based, documented, reviewed and provable. Most shortfalls are not missing tools but broken links between a policy, a risk decision, a control and the evidence that shows the control works. The cards below name the gaps assessors and supervisory authorities most often find, with the step that closes each one.
Policies with no owner or review date
A data protection policy that nobody is accountable for, and that carries no review date, reads as a document written once and never tested. Article 24(1) expects measures to be reviewed and updated where necessary, so a policy without a named owner has no one to trigger that review. Check that every policy names an accountable role, a version, an approval record and a next review date, and that the review is tied to a calendar entry or ticket. Use a wiki with version history so older versions remain available for comparison.
Risk assessment that does not drive measures
Many organisations produce a risk register that lists processing risks but never connects a risk rating to a specific control, owner or deadline. Article 24(1) ties the measures to the nature, scope, context and purposes of processing and the risks to individuals, so the register should explain why each measure exists. Check that every high-rated risk maps to at least one implemented measure, an accepted residual risk with a named approver, or an open action with a date. Where a risk has no measure, record that gap explicitly.
Evidence that exists only for the audit
Screenshots and reports prepared the week before an assessment show a snapshot, not a working control. Article 24 requires the controller to be able to demonstrate compliance, which means evidence should come from routine operation: access reviews, change tickets, backup restore logs and training records created as work happens. Check whether each evidence item has a source system, a collection frequency and an owner who would produce it without being asked. Keep the evidence in the same place as the policy it supports.
Processor assurances not linked to controller decisions
Vendor questionnaires, certificates and hosting contracts often sit in procurement files with no connection to the controller's own measures. Under Article 24, the controller remains responsible for choosing and overseeing measures, even when a processor operates part of the system. Check that each processor assurance is tied to a documented decision about whether it is sufficient for the risk, who reviewed it, and when it will be reassessed. Where a processor's certification is relied upon, confirm its scope covers the service actually used.
No review trigger after system changes
Measures set at go-live often stay unchanged while the platform gains new integrations, data fields, administrators or hosting regions. Article 24(1) requires review and updating where necessary, but without a defined trigger that review depends on memory. Check whether changes to architecture, new processing purposes, new processors or a significant incident automatically prompt a reassessment of the affected measures. Link the change management process to the risk register so that a change request cannot close without a data protection check.
Questions buyers ask about Article 24 cost, effort and help
How much effort does Article 24 take to meet?
Effort depends on how many processing activities the organisation runs, how sensitive the data is, and how much of the environment is already documented and tested. Article 24(1) asks for measures scaled to the nature, scope, context and purposes of processing and the risks to individuals, so a small service handling low-risk data needs far less than a platform processing health or financial records across many systems. The largest drivers are the size of the processing inventory, the number of systems and vendors touched, the state of existing policies and the frequency of review, because the Article requires measures to be reviewed and updated where necessary. Ask any partner to size the work against a named list of processing activities and systems before agreeing a fixed scope.
Can an organisation meet Article 24 without outside help?
Yes. The GDPR does not require an external audit, attestation or certificate, and Article 24 places the duty on the controller itself. Organisations with a capable privacy and security function can design the measures, write the policies and keep the evidence internally. Outside help is most useful where the internal team lacks time, has no experience with technical controls across hosted platforms, or needs an independent view before a customer or regulator review. Any outside party prepares systems and evidence, but only the controller owns its compliance decisions. Whichever route is chosen, the organisation should be able to show who approved each measure and when it was last reviewed.
What does Article 24 need from our own staff?
The work needs named people who own decisions, not only people who write documents. Typically this includes a senior sponsor who accepts residual risk, system owners who confirm how their platforms process personal data, engineers who configure access control, logging and backup, and a privacy lead who maintains the policies and review cycle. Article 24(2) links policies to the measures, so the people who approve policies must also be able to check that staff follow them. Expect recurring time for review, because measures must be kept current as processing changes. Confirm the time commitment of each role with your own managers before the engagement starts.
How long does it take to put Article 24 measures in place?
The timeline depends on the number of systems in scope, how much documentation already exists and how quickly decisions can be made. Organisations with mature policies and an accurate processing inventory usually need less time to show that measures are in place than those starting from scratch. The first cycle is typically the longest, because it includes gap analysis, policy drafting, configuration changes and evidence collection. After that, the work shifts to scheduled review and updates. No fixed duration applies to every organisation, so request a phased timeline in the written scope with milestones tied to named deliverables.
Does certification under Article 42 remove our Article 24 duty?
No. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Article 24(3) allows adherence to approved codes of conduct or certification mechanisms to be used as an element to demonstrate compliance, but it is one element of evidence, not a substitute for the controller's own measures. Certification also does not replace the need to keep records, review measures and respond to data subject requests and breaches. Treat certification as a question for an accredited body, and treat your Article 24 evidence as something you must maintain regardless of any certificate.
What should we ask an implementation partner to put in a written scope?
A written scope should state which processing activities and systems are covered, which Article 24 measures the partner will design, configure or document, and which parts remain with the organisation. Ask for a list of deliverables such as the policy set, configuration baselines, access and logging evidence, backup and restore tests and a review calendar. Confirm how changes in scope are priced and approved, what the partner will not do, and who owns each artefact after handover. Partners prepare systems and evidence; they do not issue audit reports or certificates, so ask who will act as the independent assessor if one is needed. Engagements at DeployOpen are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
What recurring costs does Article 24 create after the first cycle?
Most of the cost after the first cycle is ongoing: periodic review of policies and measures, updates when systems or processing change, evidence collection for customers or regulators, and staff time for training and approvals. Some organisations also pay for tooling, hosting and support retainers. The one-time costs are mainly the initial gap analysis, policy drafting and configuration work. Ask any provider to separate one-time and recurring items in the quote, and to state what triggers a chargeable change, such as a new processing activity, a new vendor or a new platform release. Where a retainer is offered, confirm what it includes and how often reviews take place.
How DeployOpen prepares Article 24 evidence
DeployOpen plans, implements and documents the self-hosted open-source platforms that hold the policies, records and controls an organization uses to demonstrate Article 24 compliance, inside the client's own infrastructure. The organization remains the controller and owns its compliance decisions, and DeployOpen prepares the systems and evidence for an assessment, while any formal assessment is carried out by independent parties.
How we scope
- Agree in writing which processing activities, systems and policies fall within the Article 24 work.
- Identify which controller decisions the organization keeps and which technical tasks DeployOpen performs.
- Confirm the hosting location, access model and existing policy library before any build starts.
How we build
- Deploy a self-hosted compliance platform and document wiki in the client's own cloud or data center.
- Configure role-based permissions so policy owners approve changes and staff only read published versions.
- Load policy and control records and map them to the frameworks the organization is assessed against.
How we hand over
- Deliver the policy set, version history and control records in a form the organization can maintain.
- Document how reviews of measures are scheduled, recorded and updated when risks change.
- Provide a handover that shows where each piece of Article 24 evidence is stored and who owns it.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
- Help the organization prepare for questions from its auditor, certification body or supervisory authority.
- Ask the client to confirm with its own counsel or assessor which certifications, if any, it will pursue.
