GDPR Audit Checklist: Evidence, Exceptions and Owners

A GDPR audit checklist tests whether an organisation can explain its processing and show the decisions behind it. This page gives 32 prompts across lawful bases, records, processor relationships, rights, security, transfers and governance. Each prompt needs an owner, evidence and a conclusion. Some duties are conditional: a DPIA is required for likely high-risk processing, a DPO in Article 37 cases, and authority breach notification when the Article 33 risk threshold is met. The checklist is a way to find gaps, not a statutory form or a promise that an exported report itself proves compliance.

The checklist follows the accountability principle in Article 5(2) GDPR: compliance must be demonstrable. It is also useful for internal review and customer due diligence, which may ask different questions from a supervisory authority. Record what was actually inspected and what remains uncertain; an empty box marked “not applicable” is not an assessment.

Key Takeaways

• A GDPR audit tests evidence, not intentions — Art. 5(2) requires you to demonstrate compliance, document by document.
• The checklist runs across six areas: lawful basis, ROPA, processor contracts, data subject rights, security, and transfers.
• The ROPA (Art. 30) is a useful organising map where required, but no rule makes it the first artifact in every inspection.
• Tools can connect records and remind owners; verify what they actually import, what remains manual and whether exports retain the decision trail.

How to Use This GDPR Audit Checklist

For each item, record evidenced, partial, missing or not applicable with reason. Note the legal provision, activity, person responsible, location and date of the evidence, a sample checked and the next action. Evidence is more than a policy filename: it might be a current register entry, a reviewed contract, a sample access response or a tested deletion log. Start with a small representative set of activities rather than declaring the whole company compliant from one department’s paperwork. The audit methodology explains prioritisation; the longer audit guide covers programme design. This page is the runnable prompt list.

Lawful Basis, Records and Contracts

Lawful basis and consent. Start with the legal ground for every activity:

Take one customer service and one employee activity. Identify the actual purpose and data subject, then ask why the stated basis applies to that operation. A service contract does not make Article 6(1)(b) available for every vendor or employee processing activity; necessity to a contract with the person concerned must be assessed. Where legitimate interests are used, review necessity and the balance with individual rights. Where consent is used, look for an actual choice and a withdrawal route. Keep the Article 9 condition distinct from Article 6 where special-category data is involved; Article 10 data also has its own constraints. An audit that merely counts six ticked lawful-basis labels misses the hardest decision.

1. Every processing activity has a documented lawful basis under Art. 6(1) GDPR.
2. Special-category processing has an additional Art. 9(2) condition documented.
3. Where consent is the basis, it meets Art. 7 — freely given, specific, informed, unambiguous, and as easy to withdraw as to give.
4. Legitimate-interest bases have a documented balancing test on file.
5. Where consent is relied on, records show what information and choices the person received, when and how they acted, and how withdrawal is honoured; retention of proof is proportionate.

Record of processing activities (Art. 30). The ROPA is a useful map of activities when the duty applies:

6. A written ROPA, including electronic form, covers relevant activities where Article 30 applies; any under-250 exception is assessed by activity, not assumed for the organisation.
7. Controller entries include the Article 30(1) categories appropriate to the role: purposes, people and data categories, recipients and, where possible, envisaged erasure periods and a general description of security measures.
8. Transfers to third countries are listed with their safeguards.
9. The record reflects material changes in purposes, recipients, systems and retention; an owner and review trigger are identified.
10. Processor activities are recorded under Art. 30(2) where you act as a processor.

The under-250 exception does not cover relevant processing that is non-occasional, likely to result in risk to people’s rights and freedoms, or includes Article 9 or 10 data. Routine payroll is generally not occasional. Compare controller and processor record fields instead of duplicating one form. Article 30 does not prescribe a vendor or spreadsheet layout, but it does require written form and availability to the authority on request. A ROPA guide helps test these fields; the broader GDPR compliance checklist addresses the programme, not just its record. Keep evidence of who supplied each entry and when it was last confirmed.

Processors and contracts (Art. 28). Classify suppliers by what they actually do, then examine the processing relationships:

11. Each processor relationship is governed by a written contract, including electronic form, or another binding Union or Member-State legal act meeting Article 28(3) and (9).
12. Subprocessors have the required prior specific or general written authorisation, flow-down obligations and a route to notify changes; the initial processor remains liable for their performance.
13. Processor security measures have been assessed, not assumed.
14. Actual third-country transfers or access paths within the chain are identified and supported by an applicable Chapter V mechanism and safeguards where required.

A service contract alone does not establish whether the supplier is a processor. Ask who determines purposes and essential means for a real activity, using the controller-versus-processor guide. For a true processor, inspect documented instructions, confidentiality, security, assistance, audits, subprocessor terms and end-of-service treatment. On exit, the controller chooses return or deletion of personal data, and existing processor-held copies must be deleted, except where Union or Member-State law binding the processor requires storage. Test how the contract and actual backup cycle deal with copies rather than inventing an immediate technical deadline. The Article 28 guide is a useful companion to this contract check.

Rights, Security and Transfers

Data subject rights (Art. 12-22). Auditors and complainants both test whether requests are actually handled on time:

Run a fictional access request across two systems and a processor. The clock normally starts when the controller receives it, not when someone opens the ticket. Article 12 calls for action without undue delay and within one month, with a conditional extension of up to two months explained within the first month. If the controller takes no action, reasons must be communicated without delay and by one month at the latest, with information about complaint and judicial remedies. Test the content too: Article 15 information, a comprehensible copy of personal data, and an assessment where other people’s rights are implicated. A form acknowledgement is not a complete response.

15. A documented process exists to receive and log rights requests.
16. Identity verification is proportionate — no blanket demands for ID copies.
17. Requests are handled without undue delay and within the ordinary one-month period, with any lawful extension or refusal communicated correctly.
18. Response templates cover access, erasure, rectification, portability and objection.
19. An audit trail records each request and its outcome.

Identity checks should be proportionate to reasonable doubts, rather than a blanket collection of ID scans. Preserve the original request, search steps, reviewers, delivered material and reasoning for any withheld information. A practical right-of-access guide can help audit a response; the GDPR fines overview gives general enforcement context, not a prediction of this company’s outcome. The same audit trail should show when a processor assisted the controller and where a deadline was escalated.

Security and breach response (Art. 32-34). Document the measures and rehearse the notification path before you need it:

Choose a plausible lost-device incident and a separate service outage. Do not label both reportable breaches before establishing whether personal data was destroyed, lost, altered, disclosed or accessed without authority and whether the applicable risk threshold is met. Record awareness, evolving facts, likely consequences, mitigations and the person who made the decision. Article 33 requires documentation of every personal-data breach, even if it was not notified. It does not require a GDPR breach register for every ordinary technical incident; an organisation may nevertheless maintain a wider security log for operational reasons.

20. Technical and organisational measures are documented and proportionate to risk (Art. 32).
21. A breach-detection and internal-escalation process exists.
22. Where risk to individuals is not unlikely, authority notice is made without undue delay and, where feasible, within 72 hours of awareness; later notices include reasons, and phased updates are tracked.
23. Criteria for notifying affected individuals under Art. 34 are set.
24. A breach record documents every personal-data breach, including those not notified, with facts, effects, remedies and the risk conclusion.

International transfers (Art. 44-49). Since Schrems II, mapping and safeguards are audited closely:

Trace a real support workflow rather than stopping at the declared data-centre location. A supplier incorporated in the EEA may have third-country personnel or subprocessors with access; a supplier incorporated elsewhere is not automatically disallowed. Record where data is sent or accessed, by whom and on what basis. If using Standard Contractual Clauses, assess whether they can work in the destination context and whether supplementary measures are necessary. Adequacy, the various Article 46 safeguards and the narrow Article 49 derogations are different routes. Do not treat consent to an ordinary service as a convenient general substitute for a transfer mechanism.

25. All transfers outside the EEA are mapped.
26. Each relies on a valid mechanism — adequacy decision, Standard Contractual Clauses, or a derogation.
27. Where Article 46 safeguards such as SCCs are used, the exporter has assessed destination-law and practice risks and any needed supplementary measures for the actual transfer.
28. The record reflects the reality of where data actually flows, including sub-processors.

Governance and accountability. Review whether the organisation can keep earlier decisions current:

29. A DPO is appointed where Art. 37 requires, with documented independence.
30. Relevant staff receive proportionate data protection instruction and the organisation can show who received it and when; do not invent one GDPR-wide fixed training interval.
31. DPIAs are conducted for high-risk processing under Art. 35.
32. Relevant notices, retention rules and security policies have owners, change triggers and version history, and practice has been sampled against them.

Article 37 has three distinct DPO triggers: the relevant public-authority limb (excluding courts acting in their judicial capacity), core activities involving regular and systematic monitoring of individuals on a large scale, and core activities involving large-scale Article 9 or 10 processing. Do not infer a DPO duty from headcount alone. Article 35 DPIAs depend on likely high risk, not every new feature. If residual high risk cannot be mitigated, Article 36 prior consultation may be needed. The GDPR text and EDPB guidance supply the legal frame; the audit must connect it to the actual processing and national context.

Tools That Automate the Audit

A checklist defines the questions; software may help route them, keep versions and collect links to evidence. No product can infer a valid lawful basis, decide whether a breach creates risk, or guarantee an audit outcome. Compare tools on the same sample of actual work. The table describes categories to evaluate, not verified capabilities of every named vendor or a ranked purchase recommendation.

The GDPR audit tool comparison can help shortlist categories. Ask each candidate, including the existing manual process, to export one current ROPA entry, its source owner, a processor review and a rights-request decision. Mark what was shown, what needs configuration and what is only described in a sales page. Security evidence can support the Article 32 part of an audit, but it does not answer Article 6, 12, 28 or 30 questions by itself. A privacy platform may connect those questions, provided the organisation supplies and reviews correct facts.

Turning Findings Into a Remediation Plan

A checklist that produces gaps without ownership is not yet a plan. For each finding, record the affected processing, applicable provision, evidence reviewed, immediate risk, owner, action and review date. Prioritise by harm to people, legal timing and likelihood that the issue persists, then by the effort and dependencies needed to correct it. An unanswered access request close to its deadline may need action today; a complex data-mapping project may require staged work. A processor agreement can also be governed by another binding Union or Member-State legal act, so a missing signature is not by itself a complete Article 28 conclusion. Confirm the relationship and operative instrument before labelling it a breach.

Re-run the affected part of the checklist when a purpose, supplier, system, security measure or relevant law changes, and schedule a wider review at an interval proportionate to the programme. There is no GDPR-wide legal rule that every organisation must conduct this exact audit annually or close a fixed fraction of findings each quarter. Keep evidence of what changed and whether the remediation worked. For example, after revising an access process, sample a later response rather than merely closing the task because a policy was approved.

FAQ

What is a GDPR audit?

A GDPR audit is a systematic review of whether your organisation can evidence compliance across lawful basis, records, processor contracts, rights handling, security and transfers. Because Art. 5(2) GDPR requires you to demonstrate — not just assert — compliance, an audit tests documentation, not good intentions.

How often should I run a GDPR audit?

The GDPR does not prescribe an annual run of this checklist. Set a risk-based review schedule and trigger targeted reviews after changes in processing, suppliers, systems or incidents. Keep a record of the last sample and the next owner review; a high-risk programme may need more frequent checks than a simple stable one.

What is the first thing an auditor asks for?

There is no universal first document. A supervisory authority or customer may ask for the item relevant to its concern. A current Article 30 record, where required, is a useful map, but its statutory fields do not themselves require a lawful-basis entry. Your own audit can start there to find connected processor, retention and transfer questions.

Do I need software to pass a GDPR audit?

No. A well-maintained manual programme can demonstrate compliance. Software may reduce coordination and versioning effort when many people or entities contribute, but its value must be shown against the existing process and its total cost. Test whether it preserves sources, missing information and human review rather than merely producing a polished report.

Conclusion

Use the checklist as a standing set of evidence questions. Record a justified “not applicable” alongside evidenced, partial and missing findings, assign owners and retest corrections. If repeated updates overwhelm the team, evaluate software on the same sample and inspect its exports. The defensible result is an accurate set of decisions and records your people can explain, not the number of checked boxes or a report generated by a particular brand.