Article 5(2) Accountability: requirements and evidence

What Article 5(2) accountability requires from your systems

Article 5(2) makes the controller responsible for complying with the Article 5(1) principles and for being able to demonstrate that compliance. If you are the compliance lead or engineer who must show that personal data processing follows those principles, the central point is that asserting compliance is not enough. Article 24 turns this duty into practice: the controller must put in place appropriate technical and organisational measures, be able to demonstrate that processing follows the GDPR, and review and update those measures where necessary. Where proportionate, the measures include data protection policies. In most organizations the gap is rarely good intent. It is the absence of records that show what the system does, who decided it, and when that decision was last checked.

The GDPR requires no audit, attestation or certificate, and no supervisory authority will hand you a pre-approved compliance status. Certification under Article 42 is voluntary and does not reduce your responsibility, so the evidence burden sits with you. Ask your team which documents would satisfy a supervisory authority asking how a specific processing activity meets the principles. Typical answers include the records of processing under Article 30, breach documentation under Article 33(5), data protection impact assessments under Article 35, and the assessment and safeguards for transfers under Article 49(6) where they apply. Confirm for each system that these artefacts exist, name an owner, and show the date they were last reviewed. Missing dates are a common reason a record cannot demonstrate anything.

Systems can support this proof if you design for it. Configuration baselines, access reviews, retention job logs and change history should be retrievable without rebuilding them from memory. Wiki platforms with version history, such as XWiki, can show what a policy said at a given time and who changed it, which matters when a regulator asks what was in force during a past incident. Compliance management tools such as CISO Assistant can track GDPR assessments alongside other frameworks, but they record only what your team enters, so the tool is a register, not a guarantee. Decide early who maintains each record, how often it is reviewed, and what triggers an update when a processing purpose or system changes.

Which systems and teams fall under the accountability duty

Article 5(2) reaches every processing activity the controller decides on, not only the systems that hold the main customer database. The scoping questions below decide which tools, vendors, teams and review cycles must produce evidence, so they should be answered before the evidence set is built.

Which processing activities does the organization control?

Start from the purposes and means the organization sets, not from the production database. Marketing automation, support ticketing, analytics pipelines, HR tools, test copies of live data, log stores and backups all carry personal data under the controller's decisions. Each one needs a recorded purpose, a lawful basis and a retention rule. Ask each business unit to list the personal data it handles, because shadow tools created outside IT are the most common gap in the evidence set.

Where does a processor act for the controller?

Where a vendor hosts, supports or analyzes personal data on the organization's behalf, the organization remains responsible for demonstrating that the processing is controlled. The evidence set must therefore include the processing contract, the vendor's instructions, the sub-processor list and the vendor's security assurance. Check whether each contract matches what the vendor actually does, since a signed agreement that does not reflect real data flows will not satisfy an assessor.

Which teams own each tool, vendor and data flow?

Accountability fails when no named owner can produce the record. For every system, assign one accountable team and one person who can answer questions about its purposes, access and retention. Record who approves new data flows and who signs off changes to them. Where ownership sits between IT, security, legal and product, write the split down so that a regulator's question about one data store does not stall across departments.

Which systems hold data outside production?

Backups, log pipelines, data warehouses, developer laptops and staging environments often hold copies of production personal data with weaker controls. Each copy is a processing activity in its own right and must appear in the records and in deletion and access procedures. Ask engineering for a list of every location where a production extract can land, and confirm that retention and access rules apply to those locations too.

Which changes trigger a documentation update?

Article 24(1) expects measures to be reviewed and updated where necessary, so the evidence must reflect the current state of the systems. New data categories, new vendors, changed hosting locations, new purposes and significant architecture changes should each trigger an update to the records and assessments. Define these triggers in the change process so that updates happen at the point of change rather than at the next audit.

How often does the review cycle run?

Set a recurring review of policies, records of processing, data protection impact assessments and vendor assurance, and record the date and outcome of each review. Confirm with the organization's own governance and legal teams what interval they adopt, because the GDPR does not set a fixed period for these reviews. A dated review log, showing what changed and who approved it, is often the strongest single piece of evidence that accountability operates in practice.

How an assessor tests accountability

This table compares what an assessor asks for, the evidence that answers each request, and the gaps that appear most often when documents and systems disagree. Read each row as a question the controller should be able to answer with dated, system-generated proof rather than a policy statement alone.

Test approach	Evidence requested	Common findings
Request the record of processing and compare it with live systems	Records of processing activities under Article 30, with owners, purposes, categories of data, recipients, retention periods and transfers, plus a system inventory or data map	Processing purposes or systems named in the record that no longer exist, or systems holding personal data that appear in no record
Sample policies and check their review dates	Data protection and security policies with version history, approval records, owners and the date of the last review	Policies approved years earlier with no review, or policies that describe retention or access rules the systems do not enforce
Test DPIA files for completeness and timing	Data protection impact assessments under Article 35 for high-risk processing, showing the risk analysis, mitigations, sign-off and review dates	DPIAs written after go-live, missing for new high-risk processing, or not updated after a material change in the system
Review transfer assessments and safeguards	Transfer impact assessments and the safeguards relied on for each third-country flow, including the assessment referred to in Article 49(6) where a derogation is used	Transfers listed in the record with no assessment on file, or assessments that do not reflect the current hosting location or sub-processors
Check that Article 24 measures are reviewed and updated	Dated review records for technical and organisational measures, change requests linked to reviews, and evidence of follow-up on identified gaps	Reviews recorded as complete with no changed measures, or review findings that stay open with no owner or deadline
Compare documented processes with system logs and tickets	Access logs, deletion job output, rights request tickets, breach register entries and change records that match what the procedures describe	Procedures state that deletion runs monthly or that access is reviewed quarterly, but logs or tickets show no such activity
Trace a sample of decisions from policy to operation	A selected processing activity followed from its recorded lawful basis, through its DPIA and configuration, to logs showing the rule operated	Recorded lawful basis or retention period that does not match the configured system behaviour or backup retention
Ask who approved and who can change the evidence	Approval records, role assignments and change history for the record, policies and DPIAs	Documents edited without a traceable author or date, or no clear owner for the record of processing

How to build demonstrable accountability step by step

This sequence turns Article 5(2) from a principle into a working set of records, owners, policies and dated reviews, so the controller can show an assessor or supervisory authority how each processing activity complies.

Inventory every processing activity
Start by listing each purpose for which the organization processes personal data, the systems that hold it, the teams that run them and any processors or sub-processors involved. Record the data categories, data subjects and recipients for each entry, and flag any special category data under Article 9. The output is a register of processing activities that serves as the basis of the Article 30 records of processing. Confirm completeness by checking the register against system inventories, identity provider exports and vendor contracts, and note any system that cannot yet be mapped to a purpose.
Assign owners and approval paths
For each processing activity, name an accountable business owner who decides purpose and retention, and a technical owner who runs the system. Set who must approve new processing, material changes and exceptions, and document whether a data protection officer must be consulted, including the written internal analysis of whether a DPO must be designated. The output is an ownership matrix with approval steps. It is done when every register entry has both owners and no activity lacks a named approver.
Write the policy set proportionate to the risk
Article 24(2) asks for data protection policies where they are proportionate, so decide which policies the organization's size, processing volume and risk justify. Typical sets cover acceptable use, retention, access, incident handling, vendor onboarding and data subject requests. Each policy should name its owner, scope, approval date and the register entries it governs. The output is an approved, versioned policy set. Check it by confirming each policy is referenced by at least one processing activity, and that gaps are recorded as accepted risks with an owner.
Link each activity to its evidence
For every processing activity, identify the records that show the controls operate: the lawful basis note, DPIA where one is needed, retention rule, access review, transfer assessment, processor contract and breach log entries. Store a pointer to each artifact in the register so an assessor can move from a processing purpose to its proof without a search. The output is an evidence map. It is complete when each entry links to current evidence, and any missing artifact is listed with a responsible owner and a target date set by the organization.
Set a review cycle with dated outputs
Article 24(1) requires measures to be reviewed and updated where necessary, so fix a review schedule for the register, policies and evidence, and set triggers for early review such as a new system, a new processor, a new purpose or a security incident. Each review should produce a dated record of what was checked, what changed and who approved it. Keep these records under version control so the history shows what was in force at any date. Confirm the cycle works by sampling a few entries at review time and checking that the evidence still matches the system as it runs.

Evidence that makes the principles demonstrable

Article 5(2) is met by evidence, not by a single document. The artifacts below connect the processing record, breach file, impact assessments, transfer analysis, policies and change history, and each needs an owner who keeps it current between assessments.

Record of processing activities

The Article 30 record lists each processing activity with its purposes, categories of data and recipients, transfers, retention periods and security measures. It is the starting point for showing the controller knows what it processes. Review it when a system is added, a vendor changes or a new purpose appears, and have the business owner of each activity confirm their entries at least once a year. Check that every system in the asset inventory maps to at least one entry. Retain superseded versions so you can show what was recorded at a given date.

Breach documentation register

Article 33(5) requires the controller to document every personal data breach, including the facts, effects and remedial action taken, whether or not it was notified. The register shows regulators that decisions about notification were made and recorded. Assign the privacy lead to maintain it and have legal sign off on the notification decision for each entry. Keep entries even for minor incidents, since a missing entry is harder to explain than a closed low-risk one. Retain the register for the life of the controller's processing and confirm the retention rule with counsel.

Data protection impact assessments

Under Article 35, a DPIA records the processing, its necessity and proportionality, the risks to individuals and the measures chosen to address them. Accountability depends on showing the DPIA was done before processing began and reviewed when the design changed. Assign a named system owner and a privacy reviewer, and reassess after material changes such as new data categories or new sub-processors. Keep the approved version, the reviewer's comments and the dated review history together. Ask whether the organization has a documented threshold for when a DPIA is triggered.

Transfer assessments and safeguards

Where a transfer relies on the safeguards described in the second subparagraph of Article 49(1), Article 49(6) requires documented assessment and safeguards. For transfers generally, the file should show the transfer mechanism, the destination's legal risks and any supplementary measures. Assign the legal owner to approve each assessment and the technical owner to confirm the measures exist in the system. Review the file when a sub-processor, hosting location or remote access path changes. Retain it for as long as the transfer continues and for a period agreed with counsel after it ends.

Approved policies with version history

Article 24(2) expects data protection policies where they are proportionate, and the policies only count as evidence if they were approved and were in force when the processing took place. Keep each policy in a wiki or document system that records every change, who made it and when, and that allows rollback to an earlier version. Require sign off by a named executive at each material revision and a review date on every page. Ask the implementation partner to set up the approval workflow, but the organization must own the approvals.

Change and review records for systems

Article 24(1) requires measures to be reviewed and updated where necessary, so the organization should be able to show that systems were examined and changed in response to risk. Change tickets, access reviews, configuration reviews and the minutes of periodic compliance reviews are the records that show this. Assign a control owner for each review, set a recurring schedule and link each review to the records it reviewed. Retain the records for the review cycle plus the period your auditors expect. Confirm the retention period with your assessor before you rely on it.

What meeting Article 5(2) costs in money and effort

This table compares the main cost components of demonstrating accountability under Article 5(2), who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fee or duration figure is supplied for this topic, so use the table to shape a written scope and ask vendors and partners to price each row against it.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Tooling or licenses for records, policy management and audit trails	Recurring, usually per user or per seat or per instance, with some one-time setup	Number of processing activities, number of systems in scope, and whether records live in a dedicated tool or a wiki	Use self-hosted open-source tools already in the estate, and confirm licensing terms and any hosting costs in writing
Internal engineering time to wire logs, consent records and processing records into systems	One-time build, then recurring maintenance as systems change	Number of applications, log sources and data stores, and how many lack structured audit logging	Standardize logging formats and make record-keeping part of new system design rather than a retrofit
Creating and reviewing the documents (records of processing, policies, DPIAs, transfer assessments)	One-time for the first set, then recurring on each review cycle	Number of processing purposes, whether a DPO or legal reviewer must sign off, and how many documents reference each other	Keep one processing register as the source of truth and link other documents to it instead of copying content
Evidence upkeep (collecting, dating and storing proof that controls ran)	Recurring, tied to review cycles and to each change in processing	Frequency of control reviews, how many owners must provide evidence, and whether evidence is collected automatically	Assign named owners, set collection dates and automate exports where the platform supports them
External review of the documents by a consultant, DPO service or legal adviser	Usually one-time for the initial review, recurring for periodic reviews	Size of the processing estate, number of jurisdictions, and how much of the documentation is new	Agree a written scope with defined deliverables, and ask for a quote that separates initial review from ongoing review
Time an independent assessor spends sampling and testing the evidence	Recurring at each assessment, where an assessment is commissioned	Number of samples requested, how complete and consistent the records are, and the number of systems tested	Keep evidence organized by processing activity so that samples can be pulled quickly, and confirm the assessor's scope and fee basis before work starts

Open-source tools that hold accountability evidence

Article 5(2) is satisfied by evidence you can produce on request, so the question is where that evidence is kept, who can change it and how changes are traced. The three tools below cover different parts of that job: framework mapping and assessment, versioned written records, and role-based access to those records. Confirm each one against your own environment and license obligations before you rely on it.

Assessment and framework mapping

CISO Assistant (AGPL-3.0-only) ships GDPR among more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, NIS2 and DORA. It runs audits and compliance assessments against those frameworks and maps requirements automatically between them, so one control can be shown to answer several obligations. For Article 5(2), the useful question is whether its GDPR mapping matches the controls you actually operate and whether the assessment records hold up when an authority asks for proof. Check how it handles your own control wording, and confirm what AGPL-3.0-only obligations apply if you modify and host it for users.

Versioned written records

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This matters for accountability because policies, records of processing and DPIA narratives must show what was approved on a given date, not only the current text. Check that your retention settings keep the history you need, that rollbacks are themselves logged, and that exported copies preserve version metadata for assessors.

Role-based access to records

BookStack (MIT) gives each user abilities through assigned roles, and those permissions can be overridden per shelf, book, chapter or page. Controllers can therefore let privacy staff edit DPIA pages while business owners only read them, or restrict a sensitive assessment to a named group. Access design is itself evidence: you should be able to show who could edit each accountability document and when those rights changed. Confirm that overrides are reviewed regularly, since an unexpected page-level grant can quietly widen who controls the record.

Who owns accountability, who prepares it and who checks it

The controller remains accountable under Article 5(2) for being able to demonstrate compliance with the Article 5(1) principles. That accountability cannot be transferred to a vendor or consultant. Your team decides the processing purposes, the lawful basis for each activity, the retention periods, the risk appetite behind security measures, and whether a supplier relationship is acceptable. These are decisions, and they must be recorded with a named owner and a date.

Decisions and sign-off: Approve the purposes, lawful bases, retention rules and risk acceptances, and record who signed each one.
Policy ownership: Own the policy set and review it on a schedule, as Article 24(1) expects for measures that are reviewed and updated where necessary.
Record ownership: Keep the records of processing activities under Article 30 current, since only your staff know when a system or purpose changes.
Evidence review: Check that captured evidence matches what the organization actually does, not only what the documents say.
Vendor oversight: Manage processors and sub-processors, and keep the contracts that support them.

Before any outside work starts, confirm that a named person in your organization can answer for each decision the documents record.

Where accountability usually breaks down and how to close it

Most accountability failures are not missing policies. They are gaps between what the organization says it does and what its systems, records and approvals can show. The cards below cover the gaps assessors and regulators most often find, each with a concrete fix, an owner and a trigger that should prompt a review.

Policies no system implements

A retention or access policy that exists only as a document cannot show that anything happens. Map each policy statement to a technical control, such as a deletion job, role assignment or log rule, and record where that control lives. The privacy lead owns the policy text, while the platform owner owns the configuration. Review the mapping whenever a new system is onboarded or a policy changes. Ask: can you point to the setting that enforces this sentence?

Record of processing that lags behind services

The Article 30 record is often updated quarterly while engineering ships new services weekly, so new processing appears in production before it appears in the record. Make a record entry a release gate: a new data store, integration or purpose cannot go live until its entry names the purpose, categories, recipients and retention. The product owner proposes the entry and the privacy lead approves it. Review the record at each release and at each new vendor contract.

DPIAs that are never revisited

A data protection impact assessment completed at launch and filed away does not show ongoing accountability once the processing changes. Set a named owner for each DPIA and tie it to change events: a new data category, a new recipient, a new automated decision or a material security incident. The DPO or privacy lead checks the trigger list at each release. Ask for the date each DPIA was last reviewed and what changed since then.

Transfer assessments kept outside the record

Transfer impact assessments and the safeguards behind a transfer often sit in a legal folder that the engineering team never sees. When a new sub-processor or support location appears, nobody links it to the assessment. Keep the transfer assessment, the contract reference and the technical measures in the same register as the record of processing, and tag each transfer to a system. The legal owner signs off, and the platform owner confirms the data path when hosting or access changes.

No evidence of who approved a change

When a configuration change or access grant has no recorded approver, the organization cannot show that a person with authority accepted the risk. Require a ticket reference and a named approver for changes to access rules, retention settings and data flows, and keep the approval in the same system as the change. Wiki pages with version history help record the decision context. Check a sample of recent changes and confirm each has an approver who was not the person who made it.

Policy reviews without a trigger

Policies reviewed only on an annual calendar can stay unchanged after a regulator decision, a breach or a new product launch. Define review triggers in the policy itself, such as a material incident, a new processing purpose, a change of hosting location or a published supervisory authority decision. The accountable executive signs off each revision, and the revision history shows what changed. Ask who can trigger an out-of-cycle review and how the trigger is recorded.

Questions buyers ask about Article 5(2) accountability

How much does it cost to make GDPR accountability demonstrable?

No fixed price applies, because the cost depends on how many processing activities, systems and suppliers the organization runs and how much of its evidence already exists. The GDPR itself sets no fee, and no researched figure is available here for accountability work. Costs fall into three groups: internal staff time to maintain records and policies, outside help to prepare systems and evidence, and any tooling. Recurring costs include reviewing records when processing changes and keeping evidence current. To compare quotes, ask each partner to itemize records of processing, policy drafting, DPIA support, evidence collection, tooling and review cycles, and to state which items are one-time and which recur.

How long does it take to put accountability evidence in place?

The duration depends on scope, and no timeline is given here without a written scope. The main drivers are the number of processing activities, how far current documentation is scattered across teams, how many systems hold personal data, and how many suppliers act as processors. An organization that already keeps a record of processing and versioned policies will move faster than one starting from informal practice. Ask for a phased plan that names the systems and processing activities in each phase, the internal reviewers required, and the points where the organization signs off before work moves on.

What does the internal team need to provide?

Accountability depends on the controller's own people, because only the organization can decide its purposes, lawful bases, retention periods and risk appetite. Expect to name an accountable owner, a business owner for each processing activity, and staff who can confirm how systems really handle personal data. Legal or privacy staff must approve policies and DPIA conclusions, and the security team must confirm the technical measures. Ask the partner to list these roles, the hours each role should expect, and the decisions the organization must make before evidence can be finalized.

Can we do GDPR accountability work in-house?

Yes, the GDPR places the duty on the controller, so an organization can build its own records, policies and evidence without an outside partner. The question is whether it has the time, skills and independence to do so consistently. Outside help is usually considered for preparing systems and evidence, such as configuring versioned documentation, setting up access controls on records, or documenting how deletion and logging actually run. Independent assessment is a different matter: only an independent auditor or certification body issues reports or certificates, and the organization should plan for that separately.

Does Article 42 certification remove our accountability duty?

No. Certification under Article 42 is voluntary and does not reduce the controller's or processor's responsibility for compliance. Under Article 24(3), adherence to approved codes of conduct or certification mechanisms may be used as an element to demonstrate compliance, but it is only one element. The controller still has to show, through its own records and evidence, that its processing follows the principles. Certification is also issued for at most three years by accredited certification bodies or supervisory authorities, so the controller must keep evidence current between reviews.

What should we ask a partner before signing?

Start by confirming the partner's role in writing: it prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. Ask for a fixed scope listing the processing activities, systems and documents in each deliverable, and for the acceptance criteria. Request a description of how records of processing, DPIAs, breach documentation and transfer assessments will be versioned and kept under review in line with Article 24(1). Also confirm who will do the work, how changes to scope are priced, what support continues after handover, and which items remain the organization's responsibility.

Which records make our compliance demonstrable to a regulator?

The records that most often carry the weight are the record of processing activities under Article 30, DPIAs under Article 35, breach documentation under Article 33(5), and transfer assessments and safeguards where Article 49(6) applies. Policies that set the controller's data protection approach, and the internal analysis of whether a data protection officer must be designated, also count as evidence. Keep a dated history of changes so you can show what was decided and when. Confirm with your supervisory authority or counsel which additional records apply to your sector and country.

How DeployOpen prepares accountability evidence

DeployOpen works on Article 5(2) by preparing the systems, records and evidence that let your organization show how it complies with the Article 5(1) principles. Your organization owns its compliance position, and an independent assessor or auditor reaches any conclusion about it.

How we scope

We agree in writing which processing activities, systems and documents fall within the accountability engagement.
The written scope names the self-hosted platforms, data flows and records of processing activities covered by the work.
Engagements are fixed-scope, with deliverables and timelines confirmed before any work starts, and ongoing support is available as a retainer.

How we build

We configure the compliance and documentation platforms in your own infrastructure to hold policies, records and assessment evidence.
We set up version-controlled documentation so changes to policies and records show what changed, when and by whom.
We configure role-based access so documentation owners can edit records while reviewers hold read or approval rights.

How we hand over

We deliver a documented evidence map linking each accountability duty under Article 24 to the records that support it.
We hand over records of processing, breach documentation templates and DPIA records in formats your team can maintain.
We train your named owners on keeping evidence current, including review dates for measures under Article 24(1).

How we support

We can support periodic review of evidence and documentation as your processing or systems change, under a retainer.
We can help your team prepare evidence packs for an independent assessor, while the assessor determines conformity.
We can confirm with your legal and privacy teams which codes of conduct or certification mechanisms, if any, your organization wishes to rely on.