Collecting evidence for a GDPR audit

Start from accountability — it tells you what to collect

GDPR's defining feature for an auditor is accountability (Article 5(2)): the controller must not only comply but be able to demonstrate compliance. That single principle is your collection strategy — for every obligation, you are looking for documented, current, true evidence that it is met. An undocumented good practice fails the accountability test even when the practice itself is sound, because the controller cannot prove it on demand.

The record of processing (Article 30) — start here

The record of processing activities (RoPA) is the master inventory of what personal data the organisation holds, why, on what basis, where it flows, and how long it's kept. Almost every other GDPR control hangs off it, so audit it first and test it hard.

Obtain the RoPA and check it is current and approved, not a stale spreadsheet last touched at implementation.
Test it against reality — walk through two or three actual processing activities and confirm they appear, accurately. Then go the other way: pick a system you know exists (the CRM, the support tool) and confirm it appears in the RoPA.
Cross-check the RoPA's claims against other evidence — retention periods against actual data ages, lawful bases against the consent or contract records, transfers against the actual sub-processor list.

Existence check

Auditor confirms a RoPA document exists, is nicely formatted, and covers many systems. Verdict: compliant. (In fact it omits the new marketing-analytics platform entirely and lists a retention period nobody enforces.)

Reality check

Auditor names three systems from interviews and checks each appears in the RoPA; finds the analytics platform is missing; then samples live records in one system and finds data eight years old against a stated two-year retention. Two concrete findings, both evidenced.

Lawful basis and consent

Every processing activity needs a lawful basis (Article 6), and where the basis is consent, GDPR sets a high bar (Articles 4(11), 7).

Lawful-basis mapping — is a basis recorded for each activity in the RoPA, and is it plausible? "Legitimate interests" claimed for everything is a red flag; ask for the legitimate-interests assessments.
Consent capture — where consent is used, how is it obtained? Pre-ticked boxes, bundled consent, and "by using this site you agree" all fail the freely-given / specific / informed test.
Consent withdrawal — withdrawal must be as easy as giving it. Walk through actually withdrawing consent and confirm it propagates to the systems that relied on it.

Data-subject rights — walk a real request

Rights handling (Articles 12–22) is where the abstract becomes concrete. The strongest evidence by far is a walkthrough of one real request end to end (see audit techniques).

What a rights walkthrough exposes

Pick one completed access request from the log and trace it: did it arrive on a monitored channel; was identity verified; was the one-month clock started and tracked; were all systems holding the person's data located (this tests the RoPA again); was the response complete and on time; is there proof of dispatch? One trace tests four or five obligations at once — and routinely reveals that requests to a personal inbox are missed, or that nobody actually knows how to find every copy of a person's data.

Then sample the request log for timeliness across the population — one clean walkthrough plus a sample is sufficient evidence; either alone is not (see evidence fundamentals).

DPIAs, processors, transfers and breaches

DPIAs (Article 35) — is there a process, and a trigger that reliably catches high-risk processing before it starts? Sample recent new processing and check whether a DPIA was considered. Missing DPIAs are usually a missing-trigger problem, not a missing-template problem.
Processor management (Article 28) — Article 28 contracts in place for each processor, and evidence the controller actually oversees them (due diligence, audit rights exercised, sub-processor changes tracked). A signed contract is the floor, not the ceiling.
International transfers (Chapter V) — for each transfer outside the EEA, a valid mechanism (adequacy, SCCs + transfer risk assessment). Cross-check against the actual sub-processor locations, not the intended ones.
Breach handling (Articles 33–34) — is there a detection-to-notification process, and does the 72-hour clock work? Walk through any real incident; if there have been none, test the process against a tabletop scenario and check staff know how to raise one.

The responsible person

Where a Data Protection Officer is required (Article 37), the DPO is a key interviewee, and the evidence should show genuine independence and access to top management — not a DPO in name only with a conflicting day job. Check the DPO is resourced, reports to the highest level, and is involved early in new processing. Where no DPO is mandated, identify who actually owns the obligation and audit their independence the same way (see roles & responsibilities).

The recurring GDPR audit failure

Almost every weak GDPR audit fails the same way: it confirms documents exist without testing whether they are true. The RoPA lists a system nobody mentioned; the consent mechanism has no working withdrawal path; the retention policy says two years but live data goes back eight; the processor list omits the analytics vendor. Walkthroughs and sampling are how you catch the gap between the documented and the actual — and that gap is where the real findings always are.

The GDPR audit checklist

Everything above is the method. The GDPR audit checklist applies it across the whole regulation — every obligation as a scored question, with suggested evidence and a finding level on each, and a Regulatory Compliance Matrix mapping every paragraph to the questions that cover it. Download the matrix and the sample free from the product page to see the coverage before you decide.

See the GDPR checklist →