GDPR audit step by step: what to check before an auditor or a UODO inspection
GDPR audit step by step: 12 areas with legal provisions, evidence and a remediation plan, plus what Polish law says about how a UODO inspection works.
ZeroLayer Team 15 min read
A GDPR audit is a review in which an organisation checks whether it processes personal data in line with the Regulation and whether it can demonstrate this with documents. The GDPR does not explicitly require an “audit”, but without a periodic review it is hard to meet the accountability principle. Below we break the review down into 12 areas, each with the relevant provision, control questions and evidence, and describe what the Polish Personal Data Protection Act (ustawa o ochronie danych osobowych) says about how an inspection by the Polish Data Protection Authority (UODO) works.
- 72 hours
- from becoming aware of a breach to notifying the supervisory authority, where feasible
- Art. 33(1) GDPR
- 1 month
- to respond to a data subject request, extendable by a further 2 months
- Art. 12(3) GDPR
- 30 days
- maximum duration of a UODO inspection, counted from the presentation of the authorisation
- Art. 89(1) of the Personal Data Protection Act
- EUR 20m / 4%
- maximum fine for infringing the principles, data subject rights and the rules on data transfers
- Art. 83(5) GDPR
Does the GDPR require an audit?
Not explicitly, but indirectly yes. The GDPR has no provision on an annual audit, but it contains three obligations that cannot be met without a periodic review:
- Accountability (Art. 5(2)). The controller is responsible for compliance with the principles in Art. 5(1) and must “be able to demonstrate compliance” with them.
- Review of measures (Art. 24(1)). Technical and organisational measures “shall be reviewed and updated where necessary”.
- Testing of security (Art. 32(1)(d)). Among the security measures, the Regulation lists regularly testing, assessing and evaluating their effectiveness.
The GDPR does not specify a frequency. A sensible approach is a full review once a year and an additional one after a major change, such as the roll-out of a new system or a serious breach.
A GDPR audit is a different obligation from the information system security audit that the Polish National Cybersecurity System Act (ustawa o krajowym systemie cyberbezpieczeństwa, KSC) imposes on essential entities; we describe the latter in our article on what a cybersecurity audit looks like (in Polish).
How to carry out a GDPR audit: preparation
Before the first question, three decisions are needed.
- Scope. Write down which processes, units and systems the review covers. The first audit should ideally cover the whole organisation; later ones can focus on areas with gaps.
- Team. You need people who know the processes: HR, marketing, IT, customer service, procurement. If the organisation has a data protection officer, monitoring compliance and “the related audits” are among the DPO's tasks (Art. 39(1)(b)).
- Evidence rule. Every “yes” answer must have evidence: a document, a system record, a configuration screenshot, a register entry. Record an answer without evidence as “partially”. The inspector will treat it the same way, as they establish the facts on the basis of documents, inspections and explanations (Art. 87 of the Personal Data Protection Act).
Checklist: 12 areas of a GDPR audit
The order is deliberate: first you establish what data you process and where, then the legal bases and obligations towards data subjects, and finally processors and security.
1. Inventory of processes and the record of processing activities
The starting point is a list of processes involving personal data, that is, the record of processing activities under Art. 30. The exemption for organisations employing fewer than 250 persons (Art. 30(5)) is narrow: among other things, it does not cover processing that is not occasional. The record is made available to the supervisory authority on request (Art. 30(4)), so it should be ready to show at short notice. We describe its contents in our guide to the record of processing activities. In the audit you check three things: whether the record exists, whether it covers all the processes the team mentioned in interviews, and when it was last updated.
2–4. Legal bases, information obligations, data subject rights
| Area | Provision | What to check | Evidence |
|---|---|---|---|
| Legal bases | Art. 6(1), Art. 9(2) | Whether every process in the record has one legal basis from Art. 6(1); whether special categories of data (e.g. health data) also have a condition from Art. 9(2) | Legal basis column in the record; for legitimate interests, a note with the balancing test |
| Consent | Art. 7(1) | Whether, for processing based on consent, you can demonstrate who consented, when and to what | Consent records with date and form content |
| Information obligations | Art. 13, Art. 14 | Whether, in every data collection channel (web form, recruitment, contract, CCTV), the person receives the information at the time the data is obtained; for data from other sources, whether they receive it within the time limit in Art. 14(3) (at the latest within one month) | Current notices with version dates, screenshots of forms |
| Data subject rights | Art. 15–22, Art. 12(3) | Whether there is a procedure for handling requests for access, rectification, erasure, restriction, portability and objection; whether responses are given within one month, and any extension is communicated within that month with reasons | Procedure, request log with dates of receipt and response |
A request-handling procedure alone is not enough. Without a request log, the organisation cannot demonstrate that it met the time limit in Art. 12(3), even if in practice it responds quickly.
5–7. Processors, data protection officer, transfers outside the EEA
| Area | Provision | What to check | Evidence |
|---|---|---|---|
| Processor contracts | Art. 28(1)–(3) | Whether every vendor processing data on your behalf (cloud, accounting, hosting, CRM) has been assessed for “sufficient guarantees”, has a contract with the elements of Art. 28(3)(a)–(h), including the right to audits and inspections (point (h)), and uses sub-processors only with written authorisation | Vendor list linked to the record, signed contracts, vendor assessment notes |
| Data protection officer | Art. 37–39; Art. 8–10 of the Personal Data Protection Act | Whether the organisation is required to designate a DPO; if so, whether it has done so, notified the President of UODO within 14 days (Art. 10(1) of the Act) and whether the DPO reports directly to the highest management level (Art. 38(3)) | Designation document, confirmation of notification, organisational chart |
| Transfers outside the EEA | Art. 44–49 (Chapter V) | Whether data goes to third countries, e.g. through cloud services; on what basis: an adequacy decision (Art. 45), standard contractual clauses (Art. 46(2)(c)), binding corporate rules (Art. 47) | Map of data locations at vendors, clauses in contracts |
When is a DPO mandatory? Art. 37(1) lists three situations: the processing is carried out by a public authority or body; the core activities consist of regular and systematic monitoring of data subjects on a large scale; or they consist of large-scale processing of special categories of data or data relating to criminal convictions. In Poland, public bodies within the meaning of this provision are public finance sector units, research institutes and the National Bank of Poland (Art. 9 of the Personal Data Protection Act). If the organisation decided it does not need a DPO, record the reasoning.
When an incident occurs at a vendor, the processor notifies the breach to the controller (Art. 33(2)), and notification to UODO is the controller's responsibility. We go through this scenario in our article on a personal data breach at a vendor (in Polish).
8–12. Security, breaches, DPIA, privacy by design, retention
| Area | Provision | What to check | Evidence |
|---|---|---|---|
| Security of processing | Art. 32(1) and (2) | Whether the choice of safeguards follows from a risk assessment; whether there is encryption or pseudonymisation where appropriate (point (a)), backups and the ability to restore data (point (c)), regular testing (point (d)) | Risk analysis, security policy, reports from restore tests and security tests |
| Breaches | Art. 33(1) and (5), Art. 34(1) | Whether there is a procedure that allows the risk to be assessed and a breach to be notified within 72 hours; whether there is an internal register of all breaches, including those not notified; whether the procedure sets out when data subjects are informed (high risk) | Procedure, breach register describing facts, effects and remedial action |
| Data protection impact assessment (DPIA) | Art. 35(1) and (3) | Whether any process requires a DPIA and whether it was carried out before the processing started | DPIA document or a note on why it was not required |
| Privacy by design and by default | Art. 25(1) and (2) | Whether someone checks data minimisation when new systems and forms are rolled out; whether default settings do not make data accessible more widely than necessary | Project checklist, deployment acceptance records |
| Retention | Art. 5(1)(e), Art. 13(2)(a) | Whether every process has a defined storage period or criteria for determining it, and whether data is actually deleted afterwards | Retention schedule, “time limits for erasure” column in the record (Art. 30(1)(f)), deletion logs |
Art. 32 does not give a list of mandatory safeguards. It requires them to be matched to the risk, taking particular account of destruction, loss, alteration, unauthorised disclosure of, or access to, data (Art. 32(2)). That is why in the audit you first ask about the risk assessment and only then about specific safeguards. We show how to build and record such an assessment in our article on the risk matrix and risk register. The ability to restore the availability of data in a timely manner under point (c) ties in with business continuity planning, which we describe in our article on the business continuity plan, BCP and DRP.
With breaches, two obligations are easily confused. Notification to UODO concerns breaches where the risk to individuals is not unlikely (Art. 33(1)). Documentation concerns all breaches, including the facts, effects and remedial action taken (Art. 33(5)). An empty breach register is worth verifying in conversations with the team. If nobody knows that an email with personal data sent to the wrong recipient must be entered in the register, the register does not show the real picture.
You check the DPIA with one question: does any process fall under Art. 35(3) (among others, large-scale processing of special categories of data, systematic monitoring of publicly accessible areas on a large scale) or under the list of processing operations published by the President of UODO under Art. 35(4) (announcement of 17 June 2019, Monitor Polski (M.P.) 2019 item 666)? If so, the DPIA should exist and should have been carried out before the processing began.
How to record the audit result: gap list and remediation plan
The outcome of a GDPR audit is a list of gaps. Each gap should have five fields: description, provision, priority, owner and deadline. Set the priority using two criteria: how much risk the gap creates for individuals and how much work closing it requires. High-risk, low-effort gaps, such as a missing processor contract with one vendor, are closed straight away.
A sample, fictitious extract from such a list:
| Gap | Provision | Priority | Owner | Deadline |
|---|---|---|---|---|
| No processor contract with the HR system vendor | Art. 28(3) | High | Procurement manager | 14 days |
| No log of data subject requests is kept | Art. 12(3), Art. 5(2) | High | Data protection officer | 30 days |
| No retention periods for recruitment data | Art. 5(1)(e) | Medium | HR | 90 days |
| Backup restore testing has not been carried out | Art. 32(1)(c) and (d) | Medium | IT | 90 days |
The remediation plan is approved by management, because it is the controller that is responsible for compliance (Art. 5(2), Art. 24(1)). The report and subsequent updates of the plan are also evidence of the review of measures under Art. 24(1).
UODO inspection: what the Personal Data Protection Act says
The rules for inspections are set out in Chapter 9 of the Personal Data Protection Act of 10 May 2018 (consolidated text Journal of Laws (Dz.U.) 2019 item 1781; the 2026 amendments did not affect this chapter). Below are the provisions that are useful when preparing.
| Issue | What the provision says | Legal basis |
|---|---|---|
| When an inspection takes place | In line with the inspection plan approved by the President of UODO, on the basis of information obtained, or as part of monitoring the application of the GDPR | Art. 78(2) |
| Start | The inspector presents a personal authorisation together with an official ID; the authorisation sets out, among other things, the subject-matter scope of the inspection and the dates | Art. 81 |
| Representative | The inspected entity designates in writing a person authorised to represent it during the inspection | Art. 83(2) |
| Inspector's powers | Entry to premises between 6:00 and 22:00, access to documents, inspection of equipment and systems, requests for explanations, questioning of witnesses, commissioning expert opinions | Art. 84(1) |
| Obligations of the inspected entity | Providing conditions for the inspection, making copies or printouts of documents and certifying them as true copies | Art. 84(2) and (3) |
| Employees | The inspector may question an employee as a witness, including a person working under a civil-law contract | Art. 86 |
| Report | The inspected entity has 7 days to sign the inspection report or submit written objections | Art. 88(4) |
| Duration | No longer than 30 days from the presentation of the authorisation, excluding the time for objections and signing the report | Art. 89(1) |
| What next | If the findings indicate that an infringement may have occurred, the President of UODO promptly initiates proceedings | Art. 90 |
Practical conclusions: designate in advance the person who will represent the organisation and prepare an authorisation for them; keep the evidence from the checklist in one place, because it is the inspected entity that makes the copies; warn employees that Art. 86 allows anyone who works with the data to be questioned.
GDPR fines: upper limits
The GDPR provides for two tiers of administrative fines. In both cases, for an undertaking the higher of the two amounts applies.
| Tier | For infringing what | Legal basis |
|---|---|---|
| Up to EUR 10,000,000 or 2% of total worldwide annual turnover | Obligations of the controller and processor under Art. 8, 11, 25–39, 42 and 43 (including the record, processor contracts, security, breaches, DPIA, DPO) | Art. 83(4)(a) GDPR |
| Up to EUR 20,000,000 or 4% of total worldwide annual turnover | The basic principles and conditions for consent (Art. 5, 6, 7, 9), data subject rights (Art. 12–22), transfers to third countries (Art. 44–49), non-compliance with an order of the authority | Art. 83(5) GDPR |
| Up to PLN 100,000 | Public finance sector units referred to in Art. 9(1)–(12) and (14) of the Public Finance Act (ustawa o finansach publicznych), research institutes, the National Bank of Poland | Art. 102(1) of the Personal Data Protection Act |
The amount of a fine in a specific case depends on the circumstances listed in Art. 83(2) GDPR. Amounts in euro are converted into zloty at the average National Bank of Poland exchange rate of 28 January of the given year (Art. 103 of the Act).
How SelfAudyt helps with a self-assessment
SelfAudyt has a GDPR module with questions that refer to specific provisions. You answer “yes”, “partially”, “no” or “not applicable”, and every gap goes into the risk register and the remediation plan with a deadline and a responsible person. You can invite IT, HR and the data protection officer to the team. The library contains templates for the record of processing activities and a processor contract. The inspection preparation section lets you select a UODO inspection and a date, and then shows the auditor's checklist, the gaps to close and a simulated conversation with the auditor.
SelfAudyt is a self-assessment. It is not an external audit, a legal opinion or a certificate, but it helps close the obvious gaps before an auditor or a UODO inspector arrives. The quick 8-question test gives you an indicative picture.
FAQ
Is a GDPR audit mandatory?
The GDPR does not use the word “audit” as a separate obligation of the controller. However, the duty to review periodically follows from the accountability principle (Art. 5(2)), from Art. 24(1), under which protective measures are reviewed and updated where necessary, and from Art. 32(1)(d), which requires regularly testing, assessing and evaluating the effectiveness of security measures.
How often should a GDPR audit be carried out?
The Regulation does not specify a frequency. Sensible practice is a full review once a year and an additional review after a significant change, such as the roll-out of a new system or a serious breach.
How long does a UODO inspection last?
Under Art. 89(1) of the Personal Data Protection Act, an inspection lasts no longer than 30 days from the presentation of the authorisation to carry it out. This period does not include the time for raising objections to the inspection report or for the inspected entity to sign and return it.
What can a UODO inspector demand?
The inspector may enter premises between 6:00 and 22:00, examine documents related to the scope of the inspection, inspect equipment and IT systems, request explanations, question witnesses and commission expert opinions (Art. 84(1) of the Act). They may also question the inspected entity's employees, including those working under civil-law contracts (Art. 86).
How does a GDPR audit differ from an audit under the KSC Act?
A GDPR audit concerns the processing of personal data and stems from Regulation 2016/679. The information system security audit under the KSC Act applies to essential entities and covers the cybersecurity of systems. An organisation subject to both regimes carries out both reviews, although some of the evidence, such as the risk analysis, can be shared.
Disclaimer
This article is for information purposes only and reflects the law as at 24 October 2026. It is not legal advice. A self-assessment, including one carried out in SelfAudyt, does not replace an external audit or a legal opinion. The obligations of a specific organisation, including the need to designate a data protection officer and to carry out a DPIA, should be confirmed with a lawyer or a data protection officer.
Sources
- Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR) — EUR-Lex, Polish text
- Personal Data Protection Act of 10 May 2018 (ustawa o ochronie danych osobowych), ISAP entry — Chancellery of the Sejm
- Consolidated text of the Personal Data Protection Act (Dz.U. 2019 item 1781) — Journal of Laws of the Republic of Poland
- Announcement of the President of UODO of 17 June 2019 on the list of types of processing operations requiring a DPIA (M.P. 2019 item 666) — ISAP
- Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts (ustawa o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 item 252) — Journal of Laws of the Republic of Poland (Art. 16 amends Art. 104 of the Personal Data Protection Act)
Read next
Compliance
Business continuity plan (BCP) and disaster recovery plan (DRP): what to include and what NIS2 requires
Business continuity and disaster recovery plans: how they differ, what to include, how to test them and what NIS2, the Polish KSC Act and GDPR require in 2026.
16 min read
Compliance
Record of processing activities (RoPA): how to build and maintain it in 2026
Record of processing activities step by step: Art. 30 GDPR elements, controller vs processor records, under-250 exemption, a sample entry and typical errors.
15 min read
Compliance
5×5 risk matrix and risk register: how to assess information security risk
A 5×5 risk matrix for information security: likelihood and impact scales, acceptance thresholds, a sample risk register and KSC, NIS2 and GDPR requirements.
16 min read