GDPR audit: how to test whether your data protection works in practice
A GDPR audit is your own documented test of whether data protection holds up in day-to-day operations. Get the legal requirements, a six-step method, a checklist with evidence and a worked example with samples.
Most organisations have the paperwork. There is a record of processing activities, a folder of data processing agreements, a privacy notice and a retention schedule. The question a board, an audit committee or a supervisory authority asks is different: does any of it work? Are rejected applications actually deleted after six months? Are access requests answered within a month? Does your payroll provider still use the sub-processor you approved three years ago?
That is what a GDPR audit is for. This guide sets out what the regulation requires, how to test rather than tick boxes, and how to report findings, with references to the GDPR's articles, EDPB guidance and the enforcement priorities for 2026.
The short answer: what is a GDPR audit, and do you need one?
A GDPR audit is a planned, documented review in which you test whether your policies, procedures and technical measures are actually followed and effective. The GDPR does not use the word "audit" for your internal review and sets no fixed frequency. But Article 5(2) (accountability), Article 24(1) (measures must be reviewed and updated) and Article 32(1)(d) (regular testing of security) mean that in practice you must be able to show that you check your compliance regularly. Run it on a risk basis, at least annually for your highest-risk processing, and always after significant change.
Four things that all get called a GDPR audit
Search for "GDPR audit" or "data protection audit" and you will find articles about four different things, each with its own legal basis, owner and output. Keep them apart before you plan anything.
| Type | Who does it | Legal basis | Output |
|---|---|---|---|
| Internal compliance audit | Compliance, internal audit, the DPO or an external adviser on your behalf | Art. 5(2), Art. 24(1), Art. 32(1)(d), and for the DPO Art. 39(1)(b) | Audit report with findings, severity and an action plan for management |
| Processor oversight | The controller, in respect of its processors | Art. 28(1) and 28(3)(h) | Documented oversight per processor, such as a questionnaire, an assurance report or an inspection |
| Supervisory authority audit | The national data protection authority | Art. 58(1)(b) (investigations in the form of data protection audits) | A decision, possibly a reprimand, an order or a fine |
| Assurance report or certification | An independent auditor or an accredited certification body | ISAE 3000 or ISAE 3402 (assurance standards), GDPR Art. 42 for certification of processing operations | A type 1 or type 2 report, or a certificate for specific processing operations |
A data protection impact assessment (DPIA) is not an audit. It assesses the risk of one processing operation, usually before it starts (Art. 35). An audit tests afterwards whether what you decided is really happening. Article 35(11) links the two: where necessary, the controller must review whether processing is carried out in line with the DPIA, at least when the risk changes. That review belongs naturally in the audit.
The rest of this article covers your own GDPR compliance audit and processor oversight, which should be planned together.
GDPR audit requirements: what the regulation actually says
No article says "you must carry out an annual internal audit". The obligation comes from several provisions that together make it hard to meet the regulation without testing regularly.
| Provision | What it says | What it means for the audit |
|---|---|---|
| Art. 5(2) | The controller is responsible for, and must be able to demonstrate, compliance with the seven principles in Art. 5(1) | The audit must produce evidence, not opinions |
| Art. 24(1) | Appropriate measures must be implemented and reviewed and updated where necessary | The closest the GDPR comes to a periodic review requirement |
| Art. 32(1)(d) | A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures | Security must be tested regularly, not just described |
| Art. 28(3)(h) | The processor must make information available and allow for and contribute to audits, including inspections | The basis for processor oversight |
| Art. 30 | Records of processing activities for both controllers and processors | The audit tests whether the record matches reality |
| Art. 33(5) | All personal data breaches must be documented, including those not notified | The breach log is both evidence and a source of findings |
| Art. 35(11) | Review where necessary whether processing follows the DPIA, at least when risk changes | DPIA measures are part of the test |
| Art. 39(1)(b) | The DPO monitors compliance, including the related audits | If you have a DPO, auditing is part of the role, but accountability stays with the controller |
The consolidated text is on EUR-Lex. Note that Article 32 requires appropriate measures judged against risk. Encryption and pseudonymisation are examples in the provision, not mandatory requirements in themselves. An audit should therefore test whether your measures fit your risk, not whether one particular technology is in place. The seven principles in Article 5, from lawfulness to accountability, form the backbone of the audit criteria. See our overview of the seven GDPR principles.
How to run a GDPR audit in six steps
The method below follows ordinary audit practice, as described for example in ISO 19011:2018 on auditing management systems, adapted to the GDPR. It works whether the audit is carried out by internal audit, your DPO or an external adviser.
Step 1: Set scope, criteria and independence
Decide what the audit covers: the whole organisation, a business area such as HR, or a single process. Write down the audit criteria, the specific requirements you test against, typically the GDPR's articles, national data protection law, your own policies and the terms of your data processing agreements.
Settle independence. The person who wrote the retention procedure should not test it. If you have a DPO, Article 38(6) requires that their other tasks do not create a conflict of interests, and that can happen if the DPO also owns the processes under audit.
Step 2: Prioritise by risk
You rarely have time to test everything every year. Use your record of processing and your data privacy risk assessment to pick the processing where a failure would hurt data subjects most: special category data under Article 9, large numbers of people, monitoring, new systems, and processing that has already caused breaches or complaints. Add the areas regulators are prioritising this year, covered further down.
Step 3: Gather documentation
Collect what describes how things are meant to work: your record of processing activities, policies, retention periods, privacy notices, data processing agreements, DPIAs, legitimate interest assessments, the breach log and training material. Review them for consistency before you interview anyone. Contradictions between the record and the privacy notice are common, and you can spot them at your desk.
Step 4: Test design and operation
This is where a real audit differs from a checklist. Test two things for each control. Design: would the procedure meet the requirement if it were followed? And operation: was it actually followed during the period you are auditing? Operation is tested with samples, system extracts and observation, never with interviews alone.
Step 5: Grade the findings
Describe each finding with five elements: the criterion (what the rule requires), the condition (what you found), the cause, the consequence for data subjects and a recommendation. Give it a severity. Without a shared scale, everything is either "important" or forgotten.
Step 6: Report, follow up and close
The report goes to management, which owns the risk. Each finding gets an owner, a deadline and a plan for how closure will be verified. A finding is only closed when someone has tested that the fix works. That follow-up is also what shows a supervisory authority you take accountability seriously.
GDPR audit checklist: what to test and what evidence to ask for
A useful checklist does not just ask "do you have a retention procedure?". It says which evidence shows the procedure works. The table below is the starting point we would use ourselves. Adapt it to your scope.
| Area | Legal source | Evidence that tests operation | Typical finding |
|---|---|---|---|
| Record of processing | Art. 30 | Compare the record with the system inventory, SaaS purchases and interviews | Systems in use that are missing from the record |
| Lawful basis | Art. 6 and 9 | Sample of processing operations: is the basis stated and justified, and is there a balancing test for legitimate interests? | Consent used where another basis fits better, or no balancing test |
| Transparency | Art. 12-14 | Check privacy notices against Art. 13 and 14 item by item, and where and when they are shown | Retention period or recipient categories missing |
| Data subject rights | Art. 12(3) and 15-22 | Request log: received, answered, any extension and the reason given | Replies after more than one month without an extension |
| Retention and deletion | Art. 5(1)(e) | System extract: is there data older than the retention period? | A retention period in the policy, no deletion in the system |
| Security of processing | Art. 32 | Access reviews, leavers list against active accounts, logging, restore tests | Leavers with active accounts |
| Personal data breaches | Art. 33 and 34 | Breach log, timestamps for discovery and notification, the risk assessment for data subjects | Breaches logged without a reasoned decision on notification |
| Processors | Art. 28 | Agreements, sub-processor lists, evidence of oversight carried out | No oversight documented after signing |
| International transfers | Art. 44-49 | Transfer mechanism per supplier and a transfer impact assessment where standard contractual clauses are used | A sub-processor outside the EEA that nobody has assessed |
| DPIAs | Art. 35 | Is there a DPIA where Art. 35(3) or the national list requires one, and were the measures implemented? | DPIA approved, agreed measures never implemented |
| By design and by default | Art. 25 | Sample of new systems: was data protection assessed at purchase and configuration? | Default settings that collect more than necessary |
| DPO and governance | Art. 37-39 | Designation, contact details sent to the authority, resources, reporting line to top management | A DPO with tasks that create a conflict of interests |
| Training | Art. 39(1)(b) | Completion rate by department, content and timing | New joiners start work without training |
If you need a broader list for implementation, our GDPR compliance checklist covers the basics. The table above is deliberately narrower. It is written for the person doing the testing.
Sampling and evidence: turning the checklist into a test
The GDPR says nothing about sample sizes, and there is no EU standard for an internal data protection audit. So set and justify your own method, and keep it stable so it can be repeated next year.
Three rules keep the method honest. Pick samples at random or by a fixed rule, not from what the process owner suggests. Write down the population, so the result reads as a proportion. And keep the evidence, so someone else can see what the conclusion rests on.
As a rule of thumb, we use the scale below. It is our own, not a legal requirement, and it should be adjusted for risk.
- Fewer than 10 events in the period, such as access requests: test all of them.
- 10 to 250 events: test around 15 to 25, more if special category data is involved.
- More than 250 events or records: test 25 or more, and add a system extract that covers the whole population.
GDPR audit report: findings, severity and structure
The report should be readable by an executive team in five minutes. Open with a one-page summary, then the findings in detail, and finally method and evidence.
The scale below is our suggestion. What matters is that you use the same one every year, so progress can be measured.
| Severity | Characteristics | Example | Suggested deadline |
|---|---|---|---|
| Critical | Processing without a lawful basis or a live risk to data subjects | Health data shared with a supplier without a data processing agreement | Immediately, within 30 days at most |
| High | Systematic deviation from a requirement | A retention period ignored across a whole process | 90 days |
| Medium | Isolated deviation or a documentation gap | One access request answered late | 6 months |
| Low | Improvement opportunity, no current breach of the rules | Unclear wording in an internal procedure | Next audit cycle |
A critical finding may also be a personal data breach. Then the regulation's deadlines apply, not the audit plan: notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it (Art. 33), and tell data subjects without undue delay if the breach is likely to result in a high risk to them (Art. 34). Our article on security breaches walks through the assessment.
Processor oversight as part of the audit
Much of your processing happens at other organisations. Article 28(1) says you may only use processors that provide sufficient guarantees, and Article 28(3)(h) gives you the right to the information and audits needed to check. The requirement for an agreement and oversight applies to processors, meaning those processing personal data on your behalf. An independent controller you share data with is not covered by Article 28. The EDPB's Guidelines 07/2020 on controller and processor (final version July 2021) help with that distinction.
How much oversight is enough? The GDPR does not say, but some national authorities have. The Danish authority, Datatilsynet, published guidance in October 2021 with a points scale: 1 to 3 points for the number of people affected (under 1,000, 1,000 to 10,000, over 10,000), 3 for special category data, 2 for other sensitive data such as national identification numbers, and 2 for intrusive processing. More points mean more demanding oversight, from written confirmation up to an independent assurance report or your own inspections. It is a useful published model even outside Denmark.
Assurance reports are common evidence. A type 1 report covers design at a point in time, a type 2 report also covers whether controls operated over a period. Read the report, not just the cover: check the period, the services covered, any qualified opinion and whether sub-processors are carved out. An ISO/IEC 27001 certificate speaks to security management within its stated scope. ISO/IEC 27701, revised as a standalone privacy standard in October 2025, goes further on privacy but is still no GDPR certification. Our article on ISAE 3000 explains the report types.
Remember the chain. In Opinion 22/2024 (October 2024), the EDPB said the controller should have information on the identity of all sub-processors readily available, and that checks should scale with risk. In an audit, that means testing whether the sub-processor list is current and whether you approved the changes. Our guide to auditing data processors goes into more detail.
How often should you audit, and what should you prioritise in 2026?
There is no statutory frequency. Sensible practice is an annual audit of your highest-risk processing, with a rolling plan that covers the rest over two to three years. Add ad hoc audits when something changes: a new HR or customer system, an acquisition, a new processor with access to special category data, or a breach that exposes a weak control.
Regulators' own priorities are a good guide to what to test first this year.
- Transparency. On 19 March 2026 the EDPB launched its coordinated enforcement action for 2026, in which 25 data protection authorities are examining compliance with the information obligations in Articles 12, 13 and 14. Test your privacy notices against Articles 13 and 14 item by item. Our guide to the right to be informed lists the requirements.
- Data subject rights. The coordinated action in 2025 covered the right to erasure (Art. 17) and the one in 2024 the right of access (Art. 15). Test your access request handling and your deletion processes.
- National priorities. Many authorities publish their own. Datatilsynet's list for 2026, for example, includes large processors, transparency, website tracking and employee monitoring. Check what your lead authority has announced.
If you test website tracking, remember that cookies are governed by the national rules implementing the ePrivacy Directive alongside the GDPR.
Worked example: auditing HR at a mid-sized company
Brightwater Logistics BV and Elena Novak are fictitious. We invented them for this article, and they are neither customers nor a case study.
Brightwater Logistics has 320 employees and 38 processing activities in its record. Elena Novak is the compliance manager running this year's audit. She uses the risk assessment to choose HR and recruitment, because they process sickness absence and trade union membership, which are special category data under Article 9, and because a new applicant tracking system went live a year ago. The audit period is the last 12 months. She plans 12 interviews and about 90 internal hours.
Four tests produce four findings.
- Deleting applications. The record and privacy notice say rejected and unsolicited applications are deleted after six months. A system extract shows 410 applications received more than six months ago. Elena draws 25 at random and finds 7 still in the system, or 28 %. The cause is that automatic deletion in the new system was never switched on. The finding is high severity under Article 5(1)(e) and affects the whole process, so she recommends switching deletion on and running a one-off clean-up.
- Access requests. There were 9 requests in the period, so all are tested. 8 were answered within one month. One was answered after 41 days, with no extension and no notice to the data subject, contrary to Article 12(3). The finding is medium, because it is isolated and was caused by holiday cover that never happened.
- The payroll provider. Elena scores the provider on the Danish points model. Around 1,400 current and former employees are in the payroll system (2 points), there is health and trade union data (3 points) and national identification numbers (2 points). That makes 7 points, at the upper end of the scale where the model points to the more demanding oversight concepts. The provider has an ISO/IEC 27001 certificate, but its scope covers hosting, not the payroll service, and the provider's sub-processor list names a company Brightwater never approved. The finding is high severity under Article 28(2) and 28(3)(h).
- Transparency for applicants. The applicant privacy notice does not state the retention period required by Article 13(2)(a). The finding is medium, and worth fixing fast in a year when authorities are testing exactly that.
The report to the executive team has 2 high and 2 medium findings and no critical ones. The key lesson is in the summary: two findings share one cause, the go-live of the new applicant tracking system without a data protection check. Elena therefore recommends a data protection by design checkpoint (Art. 25) for new systems. A checklist never finds that pattern. A test does.
What an internal audit cannot do
- It is not a certification. An internal audit does not prove to a supervisory authority that you comply. It shows that you work systematically.
- It is a snapshot. It must sit alongside ongoing operational controls.
- It is only as independent as the people doing it. Use an independent party for your highest-risk processing.
- It does not replace DPIAs, risk assessments or processor oversight. It tests whether they exist and work.
- It must follow the rules as they stand. EU lawmakers are working on GDPR simplification, including a May 2025 proposal to widen the record-keeping exemption in Article 30(5) and the Commission's broader Digital Omnibus of November 2025. Neither had entered into force as of 24 September 2026. Until they do, the exemption applies to organisations with fewer than 250 employees, and it falls away if processing is likely to result in a risk, is not occasional, or includes special category or criminal offence data.
What is at stake if you do not test?
Fine levels are set in Article 83. Breaches of, among others, Articles 25 to 39, covering processors, records, security and DPOs, can cost up to EUR 10 million or 2 % of global annual turnover (Art. 83(4)). Breaches of the principles, lawful basis, data subject rights and international transfer rules can cost up to EUR 20 million or 4 % (Art. 83(5)). In Denmark and Estonia, fines are initiated by the authority and imposed by the courts, as Article 83(9) and recital 151 provide.
When deciding on a fine and its amount, authorities consider, among other things, the degree of responsibility taking into account the technical and organisational measures you implemented (Art. 83(2)(d)) and any action taken to mitigate the damage (Art. 83(2)(c)). On 21 September 2026 the EDPB adopted new guidelines on when to impose a fine relative to other corrective powers, open for consultation until 13 November 2026. A documented audit does not undo an infringement, but it feeds into the assessment of how responsibly you acted.
How .legal supports your GDPR audit
In the GDPR module and Data Mapping, the record of processing, lawful bases, systems, processors and international transfers sit together, so the auditor can start by comparing the record with reality instead of assembling it.
Processor oversight can run through our Data Processor Audit Service, where questions to suppliers are sent, answered and documented in one place. Risk management gives you the basis for prioritising what the audit covers. And in compliance task management you plan the audit, assign each finding an owner and deadline, and see what has been closed.
The platform does not do the audit for you, and it does not make you compliant on its own. Sampling and judgement remain your work. But next year's audit starts where this one stopped. Book a demo to see how it looks in practice.
.legal compliance platform
Conduct smarter GDPR data audits
-
Automated audit checklists and workflows
-
Real-time compliance monitoring
-
Centralised findings and action tracking
-
Complete audit history and reporting
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
-1.png?width=68&height=52&name=bws_shipping_rgb%20-%20Kopi%20(2)-1.png)
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=493&height=57&name=KAUFMANN%20(1).jpg)
