GDPR Audit Checklist: 10 Practical Controls and the Evidence Auditors Expect

This practical GDPR audit checklist measures the gap between policy, operational reality and evidence. For each control it explains why failures happen, what the minimum evidence should be, who should own the activity and what type of finding typically results. The focus is operational (not legal) and intended to help build an auditable chain from policy to remediation.

Why this matters: audits do not only test whether controls exist, but whether they operate and are documented. In organisations where incident reporting and remediation are frequent, verification shifts from "do we have a procedure?" to "can we detect, evaluate and document every decision?". Clear separation of proposers, approvers, executors and verifiers preserves the probative value of the audit trail — if the same person creates, updates and closes an item, the chain loses evidential strength.

Index

• 1. Records of processing activities (RoPA)
  • Minimum fields and evidence
• 2. Legal basis and privacy notices
  • Evidence to keep for each notice version
• 3. Handling data subject requests (DSARs)
  • Minimum DSAR register fields
• 4. Data protection impact assessments (DPIAs)
• 5. Data breach handling and notification
  • Minimum incident record
• 6. Contracts and ongoing monitoring of processors
  • Minimum evidence per processor
• 7. International data transfers
• 8. Retention and deletion
  • Making retention verifiable
• 9. Security measures and access controls
  • From declared control to verified control
• 10. Privacy by design and change approvals
• Pre-audit checks to run yourself
• From checklist to an audit evidence pack
  • Common mistakes that weaken audits
  • Seven pre-audit questions

1. Records of processing activities (RoPA)

Registers usually fail not because they are missing but because they are out of date. A register that describes the organisation a year ago is ineffective if teams have onboarded new SaaS, changed vendors or added processing steps since. Problems become visible when a live system operates under a legal basis, retention period or vendor that the register does not reflect.

Small and medium organisations should note that regulatory exemptions sometimes exist for enterprises below a certain size, but exemptions do not apply where processing is regular, likely to pose risks to individuals, or concerns special categories of data. A continuous activity such as payroll can remove exemption relief.

Minimum RoPA fields and evidence

• Processing ID and related system: link to the actual application and vendor. A generic process name without a system mapping undermines traceability.
• Owner and purpose: named function owner, legal basis, data categories and categories of data subjects. Without a named owner, no one is accountable for changes.
• Recipients and retention: processors, transfers, retention rule and deletion implementation method.
• Review trail: date, author of the change, approval, and archived previous versions. A record without a timestamp only shows that someone edited it, not when or why.

Practical test: pick three live systems (for example HR timekeeping, CRM and ticketing). Trace each system back to its RoPA entry. If the system predates the register update, raise a finding with an owner and a remediation deadline. Retain records of decommissioned processing with cessation and deletion dates. Time-stamped versions, file hashes or digital timestamps are strong evidence of what was in force at a given date.

2. Legal basis and privacy notices

A correct privacy notice on paper can still fail audit if systems collect more data, for different purposes, or for longer than the notice describes. A common example is a newsletter signup that also feeds profiling or advertising lists not disclosed at collection.

Verification must cross-check, processing by processing: legal basis, the privacy notice covering that processing, the channel of collection and the actual behaviour of the application. Tools that publish notices can help distribution but do not replace the operational check of consistency.

Evidence to keep for each notice version

• Version history, publication date, author, DPO review and the set of processing activities covered.
• Screenshots with timestamps, persistent URLs or application build identifiers, plus an archival hash of the notice file so you can demonstrate which version was live at a specific date.

If an auditor identifies a purpose that is not present in the notice, remediation should be assigned to the channel owner and closed only after the new notice is live and a functional test of the collection form confirms the change.

3. Handling data subject requests (DSARs)

DSAR processes typically fail at intake. Requests arrive by unmonitored mailboxes, chat messages or forwarded personal emails. When the operational team starts processing, statutory deadlines may already have elapsed. Auditors look for clear records of receipt, identity checks, deadlines, responses and deletions propagated across linked systems.

A single point of intake with clear instructions for other channels is essential. Convert every contact into a traceable record so deadlines are calculated from the receipt registered in the central intake system, not from an operator’s memory.

Minimum DSAR register fields

• Request ID and channel: date/time of receipt, originating channel and who forwarded it.
• Data subject and right exercised: identity verification evidence when required, type of request, and systems impacted.
• Owner and deadline: responsible person, calculated statutory deadline, justified extensions and current state.
• Verifiable closure: copy of the response sent, evidence of actions taken with processors and spot checks proving deletion or access delivery in source systems.

A deletion recorded in the CRM but not executed by the email marketing vendor is non-compliant. Preserve confirmations from processors and documented reasons for any refusals. Periodic sampling of closed DSARs helps detect mismatches between recorded status and actual effect.

4. Data protection impact assessments (DPIAs)

DPIAs are weak when treated as one-off launch documents and left unchanged while systems evolve: a supplier change, a new purpose or an added data source can render the original DPIA obsolete. Equally problematic is documenting control measures that were never implemented, such as a pseudonymisation approach listed in the DPIA but absent from system configurations.

Controls to look for

• Mandatory screening at project gate: every project that meets simple risk thresholds should generate a dated decision, even if the outcome is that a DPIA is not required.
• Tracked measures: owners, implementation status and test evidence.
• Active review: periodic re-assessment and mandatory review upon significant change.

A DPIA that does not link to RoPA entries, processors and security controls is largely descriptive. Auditors expect coherence between the risk described, the mitigations claimed and the actual technical or organisational state.

5. Data breach handling and notification

Breach procedures usually exist; the common failure is missing timestamps. Who discovered the event, when was it assessed as a personal data breach, and who decided to notify (or not)? Without that sequence, even well-managed technical remediation is difficult to justify.

Minimum incident record

• Facts and timing: discovery timestamp, assessment time, systems and categories of data involved.
• Risk assessment: criteria applied, potentially affected individuals and impact.
• Notification decision: decision-maker, rationale, deadlines and any communications issued.
• Remediation: root cause, corrective actions, owners and verification of closure.

Keep incident, breach and audit findings records distinct. For example, an email accidentally sent to the wrong recipient requires privacy assessment separate from the IT ticket for message recall. Link but do not conflate these records.

Exercise scenarios regularly to surface stale escalation contacts and unrealistic decision timelines.

6. Contracts and ongoing monitoring of processors (Art. 28 GDPR)

Signing a Data Processing Agreement (DPA) is only the start. Auditors want to know how the processor was assessed before onboarding, what documentation was reviewed, how sub-processors were authorised and what happened if a security guarantee expired or a data centre changed.

Processor qualification and continuous monitoring should link contract, RoPA, questionnaires, received documents and periodic re-reviews. A vendor’s questionnaire alone does not replace independent verification.

Minimum evidence per processor

• Contract and scope: signed DPA, listed processing activities and documented instructions.
• Initial assessment: criteria used, documents reviewed, approval and acceptance evidence.
• Sub-processors: notifications, authorisations and dated objections.
• Periodic review: review frequency scaled by criticality, refreshed evidence and any open remediation items.

If a support function moves activities to a third country, effective controls should intercept the notification, update RoPA and re-evaluate transfer safeguards. Don’t rely on informal commercial emails to capture such changes.

7. International data transfers

Indirect transfers are the usual trap. Contracts show an EU-headquartered vendor, while support staff or backups are outside the jurisdiction. If the register only records the vendor’s legal seat, it gives a false sense of compliance.

Verification should start from data flows, system logs, sub-processors and the true location of primary and secondary copies and metadata. For each transfer record the legal basis (e.g. SCCs), safeguards applied, contextual assessment where required and confirmation from the recipient.

Practical rule: ask where the data, backups, logs and remote support access live. The vendor’s registered address does not answer that.

Keep signed clauses, date of signature, confirmation of recipient controls and triggers for re-review. When architecture or sub-processors change, re-run the assessment; an undated historical evaluation does not prove continuing coverage.

8. Retention and deletion

A retention period in a privacy notice proves nothing unless systems enforce it. Common failures include candidate records stored indefinitely, mailboxes retaining attachments without rule, and logs kept forever. Auditors ask for the last executed deletion and supporting job logs, not just a polished table of retention periods.

Each data category needs a retention term, legal rationale, the systems in scope and the operational rule that enforces deletion. If deletion is manual, document frequency, responsible operators, selection criteria and verification. If automatic, preserve job configurations, run results and error handling logs.

How to make retention verifiable

• System-level rules: retention linked to databases, file systems, mailboxes, logs and processors.
• Execution logs: date, scope, count of records purged and anomalies, while not retaining the deleted personal data itself.
• Governing backups: retention lifecycle for backups, rotation and behaviour after a restore.
• Justified exceptions: legal hold basis, owner and review date.

A quarterly log showing CRM purges, vendor confirmation and random checks against restored backups is strong evidence. A manager’s statement without execution logs is not.

9. Security measures and access control

Access control failures usually arise because accounts remain active after people leave. Article 32 requires appropriate security relative to risk, demonstrated with dated evidence rather than declarative statements.

From declared control to verified control

• Encryption: failing areas often include backups and export paths. Keep dated configuration extracts for every system that holds copies.
• Access reviews: a list alone is weak. Keep signed review decisions, tickets showing revocation or continued justification and dates.
• Backups and restores: evidence should include successful restore logs from tests, not only scheduled job reports.

Integrate account revocation with HR offboarding, but still run independent access reviews. If a quarterly review finds accounts for former staff, record revocation action, date, responsible person and re-run the check. An exception managed and evidenced is stronger than a perfect-sounding policy.

Preserve dated config extracts (with hashes where possible), admin access logs and restore proofs. Isolated screenshots show a point-in-time, not continuous effectiveness.

10. Privacy by design and change approvals

Privacy by design becomes auditable within change management. The usual failure is deploying functionality that introduces new data, purposes or a vendor without prior privacy review — then trying to retrofit RoPA and DPIA entries after release.

Implement a privacy gate with clear activation criteria. New personal data, new subject categories, profiling, international transfers, new processors or retention changes must halt release until a dated assessment is recorded. The workflow should separate proposer, privacy reviewer and approver, with a distinct verifier sampling compliance.

Essentials

• Activation criteria integrated into the change process.
• Dated decision with linked RoPA and DPIA entries.
• Limited, timeboxed derogations with mandatory re-review.
• Post-release sampling comparing approved changes with the deployed system.

An urgent 30-day derogation is a temporary exception, not a permanent approval. If it lapses without re-review it becomes a finding.

Pre-audit controls to verify yourself

Quick checklist to run before an auditor arrives:

• Are RoPA entries linked to three live systems end-to-end (system → legal basis → notice → retention)?
• Are DSARs recorded with receipt timestamp, identity steps and closure evidence including processor confirmations?
• Are DPIA screenings and DPIAs dated, DPO-reviewed and linked to the implementation evidence?
• Do breach records include discovery and decision timestamps and a remediation verification trail?
• Are processor contracts on file and were initial assessments documented and re-reviewed?
• Are international transfers documented with recipient confirmations and up-to-date safeguards?
• Do retention jobs leave an execution log that proves deletions actually ran?

If responses rely on a single person’s memory, the evidence pack is not ready.

From checklist to an audit evidence pack

A checklist becomes useful only when each control can be reconstructed months later by someone unfamiliar with the original activity. For each control capture: owner, date, version, supporting evidence, decision and remediation in one linked path. If responding to an auditor requires hunting through personal emails, chats and local spreadsheets, the organisation lacks a governed evidence chain: documents exist but cannot prove when, why and by whom they were produced.

Start with the areas that commonly produce findings: RoPA, DSAR handling and processors. Perform small but real sampling from production systems rather than exhaustive document reviews — a few correctly executed samples reveal more about operational compliance than a pile of policies.

Common mistakes that weaken audits

• Retroactive approvals: documents signed after processing started are not preventive evidence.
• Open-ended exceptions: perpetual derogations become indistinguishable from tolerated non-compliance.
• Scattered evidence: untimestamped screenshots, email attachments and local versions show existence but not execution.
• Unverified closures: items marked closed without technical confirmation reappear on spot checks.
• Conflated categories: mixing incidents, exceptions and findings in one log destroys decision traceability.

Good practice: each finding should keep an ID, originating control, severity, owner, deadline, action, closure evidence and verifier. Exceptions must include rationale, residual risk, compensating controls and expiry. Incidents require facts, assessments, decisions and follow-ups stored separately but linked.

Seven pre-audit questions

1. Can I start from three production systems and reach the RoPA entry, notice, legal basis and retention without oral explanations?
2. Does each control have a named owner distinct from the verifier?
3. Do evidences show date, version, author and link to the control or finding?
4. Do DSARs show receipt, statutory deadline, response and execution in source systems and processors?
5. Are DPIAs, negative screenings and significant change records updated to reflect the current systems?
6. Are incidents, exceptions and findings recorded in separate registers with clear decision criteria?
7. Have close-out remediation items been tested in the systems by sampling?

If any answer depends on a single individual’s memory, you are not ready for an external audit.

AuditReady can help convert this checklist into assigned controls, versioned evidence and tracked findings up to proof of closure. Link privacy registers, processors and DPIAs in one operational environment and assemble a structured Audit Day Pack without digging through scattered emails and folders. Visit AuditReady to see how to prepare your next GDPR audit with verifiable evidence and automated collection where appropriate: https://audit-ready.eu/?lang=en