GDPR audit readiness: the evidence pack for a regulator or customer

GDPR has no certification audit, but three kinds of review can arrive: a supervisory authority request, a customer audit under your processing agreement, and a due diligence questionnaire. Prepare one evidence pack organised by article, with owners and dates, so any of the three can be answered in days rather than weeks.

Who can ask, and on what basis?

• A supervisory authority. Article 30(4) says controllers and processors must make their record of processing available to the authority on request. Article 39 gives a data protection officer, where you have one, the task of cooperating with the authority. Article 5(2) makes the controller responsible for being able to demonstrate compliance.
• A customer, when you are a processor. Article 28(3) requires the processing contract to oblige the processor to make available all information needed to demonstrate compliance and to allow for and contribute to audits, including inspections, by the controller or another auditor it mandates.
• A partner or prospect. Not a legal audit, but they will ask for the same documents.

I used the unofficial gdpr-info.eu copy of the text, so check wording against EUR-Lex for anything you quote to a regulator.

What belongs in the evidence pack?

Organise by topic, one folder each, with an index listing owner, last review date and location.

1. Accountability and governance

• Privacy governance chart, DPO appointment or documented reason for none, and reporting line.
• Policies with approval dates, and training records.

2. Records of processing (Article 30)

• Current record with change history.
• Data flow diagrams for key systems.

3. Lawful basis, notices and consent

• Privacy notices, version history, lawful basis per purpose.
• Consent records where you rely on consent.

4. Data subject rights

• Request log: received date, identity check, action, response date.
• Procedures and templates. Article 12 sets one month to respond, extendable by two further months where necessary with notice.

5. Security of processing (Article 32)

• Risk assessment, technical and organisational measures list.
• Evidence of regular testing and evaluation, which Article 32(1)(d) calls for: scan reports, penetration tests, restore tests, access reviews.

6. Processors and transfers

• Processor register, signed agreements, sub-processor lists, review notes.
• Transfer mechanisms and assessments where data leaves the EEA.

7. Impact assessments (Article 35)

• Screening records, completed assessments for processing likely to cause high risk, and the decisions taken.

8. Breach management (Article 33)

• Incident procedure, breach register including non-notified events, and notification decisions. Article 33(5) requires documentation of every personal data breach.
• A tabletop exercise record.

9. Processor role (if you are one)

• Customer instructions log, assistance with rights requests, return and deletion evidence.

How do you rehearse?

Pick a scenario and time yourself.

• Authority letter: produce the Article 30 record and your latest breach register within one working day. Who sends it? Who approves?
• Customer audit request: assemble the pack, a security overview and sub-processor list within a week.
• Single data subject complaint: trace one person's data across systems and show what you did.
• Mock interview: ask an engineer where personal data lives and how they would delete one person's records.

Record what slowed you down, and fix it.

Which gaps do reviews find most often?

• Article 30 record that does not match systems in use.
• Processor agreements missing or without current sub-processor lists.
• Rights requests answered late or without logged identity checks.
• Breach register that omits near misses and decisions not to notify.
• Impact assessments done once and not revisited after changes.
• Security measures described but never tested.
• DPO or privacy lead who is not independent of conflicting tasks, or not involved early.

How should you handle an actual audit?

Appoint one coordinator. Log every request and response. Share what is asked, not the whole archive. Answer factually and promptly, ask for clarification when a question is unclear, and take legal advice for a regulator inquiry. Fix valid findings and record the fix with a date.

What to do

1. Build the folder structure above and assign owners.
2. Populate each folder from what already exists, then list gaps.
3. Close the gaps in this order: record of processing, processors, breach register, rights log.
4. Schedule evidence of testing under Article 32.
5. Run a timed rehearsal each year and after major changes.
6. Keep the index updated, since it is the first thing you will hand over.

Quick check

How Safeguard helps automate this

Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between reviews, which saves the team time. The Article 32 testing evidence comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. Regulators and independent auditors decide compliance, not Safeguard.

Open the framework mapping demo or book a call.

Sources

• GDPR Article 5
• GDPR Article 12
• GDPR Article 28
• GDPR Article 30
• GDPR Article 32
• GDPR Article 33
• GDPR Article 35
• GDPR Article 39

This is general information, not legal advice.

Last reviewed: 18 October 2026.