A GDPR audit is one of those tasks that sounds serious but is rarely carried out regularly in practice. The reason is simple: without proper structure, an audit becomes a one-off exercise — a document review that quickly becomes outdated once it is finished. Yet the GDPR requires continuity. The accountability principle under Article 5(2) GDPR does not say that a controller has conducted an audit — it says that a controller is able to demonstrate compliance at any point in time.

A genuine GDPR audit is not an event. It is a process.

What Is a GDPR Audit

A GDPR audit is a systematic review of an organisation’s compliance with the requirements of the regulation. It covers verification of documentation, processes, security measures, and operational practice — not only what is written down, but what actually functions in practice.

An audit may be internal (conducted by an employee or the DPO) or external (commissioned from outside specialists). In both cases, its value depends on whether the findings lead to concrete corrective actions — and whether those actions are documented.

When to Conduct a GDPR Audit

A GDPR audit should be conducted:

Periodically — at least once a year, regardless of whether changes have occurred. Experience shows that in the course of a year, something significant changes in every organisation: a new vendor appears, the scope of processing changes, the person responsible for a data area leaves.

After significant changes — implementing a new IT system, a change in the business model, a merger or acquisition, expanding to new markets, deploying AI tools.

Before a supervisory authority inspection — if the organisation has received notification of a planned inspection or a data subject complaint, an audit helps identify and remedy gaps before the regulator does.

After a personal data breach — a post-incident audit helps identify the cause of the breach and implement controls to prevent recurrence.

What to Check During a GDPR Audit — Areas to Cover

1. Record of Processing Activities

• Does the record exist and is it complete?
• Does it reflect current processes — new systems, new vendors, new purposes?
• Does each processing activity have an identified legal basis, purpose, data categories, recipients, and retention period?
• Has the record been updated in the past 12 months?

A record of processing activities that has not been updated since the GDPR was implemented is one of the most common and most easily detected deficiencies during supervisory inspections.

2. Legal Bases for Processing

• Does each processing activity have an identified and documented legal basis?
• Are consents collected correctly — freely, specifically, with the ability to withdraw?
• Is legitimate interest documented with a balancing test (LIA)?

3. Data Processing Agreements

• Has a DPA compliant with Article 28 GDPR been concluded with every processor?
• Is the list of processors up to date — have new SaaS, cloud, or IT support vendors appeared?
• Do the agreements contain all required elements, including provisions on sub-processors?

4. Authorisations to Process Personal Data

• Does every person with access to personal data hold a current authorisation?
• Are authorisations updated when roles or responsibilities change?
• Is there an authorisation register with a history of changes?

5. Data Retention

• Are retention periods defined for each data category?
• Is data actually deleted once the retention period expires?
• Is there documentation confirming completed deletions?

6. Data Subject Rights

• Does the organisation have a defined process for handling requests (access, erasure, rectification, restriction)?
• Are requests logged and handled within one month?
• Is there documentation of handled requests?

7. Risk Assessment and DPIA

• Has a risk assessment been conducted for processing activities?
• For high-risk processes, was a DPIA conducted prior to launch?
• Are risk assessments updated when processes change?

8. Data Security

• Have appropriate technical and organisational measures been implemented (Article 32 GDPR)?
• Is there a personal data breach response procedure?
• Are incidents logged?

9. Information Obligations

• Are information notices up to date and consistent with actual processing?
• Does the privacy policy describe the organisation’s actual tools and processes — not a generic template?

10. Transfers Outside the EEA

• Has the organisation identified all vendors processing data outside the EEA?
• Has the appropriate transfer mechanism been applied (adequacy decision, SCCs)?
• Are transfers documented in the record of processing activities?

The Biggest Weakness of Manual Audits

Organisations that conduct GDPR audits using Excel spreadsheets, Word checklists, or PDF documents encounter the same problem: the audit findings are a snapshot of the state on a given day — not a living picture of the organisation.

A week after the audit closes, a new vendor appears. A month later, the person responsible for handling data subject requests leaves. A quarter later, a new HR system is deployed. None of these facts are visible in the post-audit documentation — unless someone actively updates it. In practice, nobody does.

What a Software System Changes — Audit as a Continuous Process

A software system for GDPR management changes the nature of the audit. Instead of a one-off review — continuous monitoring of compliance status.

The record of processing activities is always up to date — because every change is entered in real time by those responsible for individual areas, and the system stores a full version history. During an audit — internal or external — the auditor sees the current state and change history, not a document that may have been last edited a year ago.

Authorisations are managed as a process — the system sends reminders for reviews, logs grants and revocations, and shows who currently has access to which data and since when. The auditor does not need to gather information from multiple departments — everything is in one place.

Retention works systematically — the system generates notifications when a review or deletion deadline is approaching. Every deletion is documented. The auditor can at any point review the history of retention actions.

Data subject requests are logged with the date of receipt, handling stages, and date of closure. The auditor immediately sees whether deadlines were met — and has full documentation to present during a supervisory inspection.

Risk assessments and DPIAs are linked to processing activities — showing which processes have a current assessment, which require updating, and what risks have been identified. Results are available as PDF reports ready for presentation.

Data processing agreements are managed in a single register showing expiry dates, scope, and linked processing activities. The auditor does not need to search through file folders — they see a list of all processors and agreement status.

How to Prepare for a GDPR Audit — Practical Plan

Step 1 — Gather documentation Record of processing activities, processor list with DPAs, authorisation register, risk assessment results, data subject request register, breach register, information notices.

Step 2 — Identify gaps Compare documentation with actual processes. Where are the discrepancies? Which documents are outdated? Which processes have no assigned accountability?

Step 3 — Assign responsibility for corrective actions Every gap must have an owner and a deadline. Without this, a list of gaps remains a list.

Step 4 — Document findings The audit report should contain: scope, methodology, identified gaps, recommendations, and a corrective action plan with deadlines. This is evidence of compliance with the accountability principle.

Step 5 — Schedule the next audit An audit is a cyclical process. The next review date should be set before the current audit is closed.

Summary

A GDPR audit is a compliance verification tool — but its value depends on how it is conducted and what happens afterwards. A one-off document review provides a snapshot of a given day. A software system for GDPR management turns the audit into a continuous process — where keeping documentation up to date, assigning accountability, monitoring deadlines, and documenting actions are part of daily work, not a one-off exercise.

Key principles: conduct audits periodically and after significant changes; verify practice, not just documents; every gap must have an owner and a deadline; document findings as evidence of accountability; schedule the next audit before closing the current one.

FAQ

Is a GDPR audit mandatory? The GDPR does not explicitly require audits. It does, however, impose the accountability principle — the controller must be able to demonstrate compliance at any point in time. An audit is the most practical way to fulfil this obligation.

Who should conduct a GDPR audit? It may be the DPO (if appointed), a dedicated data protection employee, or an external specialist. What matters is that the auditor has access to all areas of the organisation and genuine independence of assessment.

How often should a GDPR audit be conducted? At a minimum once a year. In organisations that frequently change processes, vendors, or systems — more often. A software system allows continuous monitoring of compliance status and reduces the need for comprehensive one-off reviews.

How long does a GDPR audit take? It depends on the size of the organisation and the state of documentation. In a small company — from a few hours to a few days. In a large organisation with multiple locations — several weeks. When documentation is maintained in a software system, audit time is significantly reduced — the auditor has access to current data rather than having to gather it.

What is the difference between an internal and an external audit? An internal audit is less expensive and can be conducted more frequently, but may lack independence. An external audit brings fresh perspective, higher credibility, and often identifies gaps the internal team does not see. The optimal approach: regular internal audits, an external one every few years or before key events.