The GDPR audit in 2026: testing compliance, not just documentation

What a GDPR audit has to show

Article 5(2) establishes the accountability principle: the controller is responsible for compliance with the principles and must be able to demonstrate it. Article 24 turns that into a duty to implement appropriate measures, to review them and to update them. An audit is one way of gathering evidence, but the report alone does not create compliance.

There is no universal "GDPR compliance certificate". The certification mechanisms of article 42 are voluntary and do not reduce the responsibility of the controller or the processor. In the same way, a clean audit of a defined scope does not automatically confirm the compliance of processes that were never examined.

A good report separates four kinds of finding:

• breach of a provision - for instance no legal basis, or an information duty that was never discharged;
• risk to the rights and freedoms of individuals - for instance excessive access to medical records;
• weakness in a safeguard - for instance an administrative account without multi-factor authentication;
• absence of evidence - the measure may work, but the organisation holds no test result, no record of the decision and no named owner.

The processing map comes before the documents

The starting point is an inventory of processes, systems, data sets, flows and recipients. The auditor sets what the process owners say against the configuration of the applications, the contracts, the logs, the forms, samples of requests and what actually happens in practice. The record of processing activities is an important source, but it should not be the only map.

Roles also have to be assigned correctly. A controller determines the purposes and means of processing, a processor acts on the controller's behalf, and joint controllers jointly determine purposes and means. The label written into a contract does not settle the role; what settles it are the facts and the actual influence of each party. ^[3]

Article 30 provides a limited exemption for organisations employing fewer than 250 persons. It cannot be relied on where the processing is not occasional, is likely to result in a risk, or includes special categories of data or data relating to criminal convictions and offences. In practice, continuous HR, sales or customer service processes often rule the simplified approach out.

Purposes, legal bases and the article 5 principles

Every operation should have a defined purpose and a basis under article 6. Consent is only one of the six bases and should not be selected by reflex. Where special categories of data are processed, an appropriate condition under article 9 is needed as well. An audit checks these elements separately for each purpose, instead of assigning a single basis to an entire system.

The assessment also covers minimisation, accuracy, storage limitation, transparency, and integrity and confidentiality. A date of birth may be necessary in one process and excessive in a contact form. Retention should not be a single number applied to all data: the purpose, sector-specific legislation, limitation periods for claims and the events that trigger deletion all have to be taken into account.

Article 25 requires data protection by design and by default. In practice an audit asks whether a new system, before it went live, was assessed for purpose, data scope, permissions, retention, interfaces, logs, suppliers and risk. The default setting should limit processing to the data needed for a specific purpose, rather than shifting the burden of configuring privacy onto the user.

Transparency and the exercise of data subject rights

A privacy notice is supposed to describe the real process. It should set out, among other things, the purposes, the legal bases, the recipients, the storage period or the way it is determined, the rights of the individual and any transfers. One generic text will not simultaneously fit recruitment, monitoring, a newsletter and complaint handling.

Auditing data subject rights does not stop at the procedure. A real or test request for access, rectification, erasure, restriction, portability or objection should be traced end to end: from identifying the applicant, through locating the data across all systems and working copies, to the response within the deadline. As a rule the response is given within one month; where requests are complex or numerous the period may be extended by two further months, provided the individual is informed within the first month. ^[4]

The review should also cover the data of other people, legally protected secrets and the extent of the copy provided in the response. The right of access does not automatically mean handing over every document unaltered, but the controller has to supply a faithful and intelligible copy of the personal data undergoing processing.

Suppliers, processors and cloud services

An article 28 processing agreement is needed where a supplier processes data on the controller's behalf. The audit examines not only the presence of clauses but also the instructions, the purpose and duration of processing, the categories of data, confidentiality, security, sub-processors, assistance with data subject rights and breaches, return or deletion of data, and the ability to audit.

The supplier list should cover systems purchased centrally as well as tools that departments or individual employees started using on their own. Trial accounts, free applications, OAuth integrations, analytics tools and support services deserve particular attention. A supplier's assurance that it is "GDPR compliant" does not replace an assessment of its role, the contract, the safeguards and the transfers.

The Commission has published standard controller-to-processor clauses for the purposes of article 28. They should not be confused with the standard contractual clauses that serve as a safeguard for transfers to a third country. ^[5]

Article 32: security appropriate to the risk

The GDPR does not impose one list of safeguards on every organisation. The controller and the processor take account of the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the likelihood and severity of the consequences for individuals. Pseudonymisation, encryption, resilience, restoration of availability and regular testing of effectiveness are examples of measures applied in proportion to the risk.

Pseudonymisation limits the ability to attribute data directly to a person, but it is not the same thing as anonymisation. If additional information makes the link recoverable, the data remains subject to the GDPR, and the additional information has to be protected and kept separately. ^[1]

A technical audit should connect risk to evidence that a safeguard works. It examines, among other things, identity and access management, multi-factor authentication (MFA), encryption and key management, backups and restoration, patching, configuration, segmentation, event logging, endpoint and email protection, incident detection, supplier security and media sanitisation. Encryption limits the consequences of a lost device or an intercepted transmission, but it does not repair excessive collection of data or misuse by an account that is entitled to decrypt it. Not every environment needs an identical set of measures, but leaving one out should have a documented justification.

Article 32 sets no fixed frequency for scans, penetration tests or audits. The testing programme should follow from risk, the pace of change, how critical the processes are and earlier findings. A backup restore test, an access review, a vulnerability scan and a response exercise answer different questions; they are not interchangeable.

In case C-340/21 the Court of Justice made clear that a cyberattack or an unauthorised disclosure does not by itself prove that the measures were inadequate. At the same time the controller has to be able to demonstrate that they were appropriate, and the act of a third party does not automatically discharge it from liability. ^[6]

Breaches: a risk-based decision, not an automatic notification

A personal data breach covers accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It may affect confidentiality, integrity or availability. A failure that encrypts the only copy of a data set can be a breach even though nobody exfiltrated anything.

The controller notifies the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of the breach, unless it is unlikely to result in a risk to the rights and freedoms of natural persons. Where the risk is high, the individuals concerned generally have to be informed as well. The processor informs the controller without undue delay. ^[7]

The clock does not start only once the forensic work is finished. Where full information is not yet available, article 33(4) allows it to be provided in phases without further undue delay. An audit examines the whole path: reporting channels, out-of-hours cover, classification of the event, risk assessment, the decision whether to notify, communication with individuals, preservation of evidence and the register of all breaches, including those not notified.

DPIA: assessment before a high-risk operation

A data protection impact assessment (DPIA) is mandatory where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons. Article 35 names, among others, a systematic and extensive evaluation of personal aspects based on automated processing, processing of special categories of data on a large scale, and systematic monitoring of a publicly accessible area on a large scale.

In Poland the list published by the President of the Personal Data Protection Office in the Official Gazette in 2019 has to be taken into account. It is not a closed list of every high-risk situation. A DPIA is carried out before the operation begins and reviewed again where a change of purpose, technology, data scope or recipients may affect the risk. If a high residual risk remains despite the measures planned, article 36 requires prior consultation with the supervisory authority. ^[8]

A DPIA is not an elaborate sign-off form. It should describe the operations and purposes, assess necessity and proportionality, analyse the consequences for people, and identify measures together with their owners. Risk to the individual is not the same thing as financial risk to the organisation.

Transfers outside the EEA after Schrems II and the EU-US DPF

The Schrems II judgment of 16 July 2020 invalidated the Privacy Shield decision but did not invalidate the standard contractual clauses. The Court required the exporter and the importer to verify whether a level of protection essentially equivalent to that guaranteed in the EU can be ensured in practice, and to apply supplementary measures where they are needed. ^[9]

Locating the primary data centre inside the EEA does not settle the question. The audit also covers remote administrative access from a third country, support, telemetry, backups and further sub-processors. The EDPB recommends establishing whether an entity subject to the GDPR discloses data or otherwise makes it available to a separate controller or processor in a third country. ^[12]

Since 10 July 2023 Commission Implementing Decision (EU) 2023/1795 on the adequacy of the EU-US Data Privacy Framework has been in force. It permits transfers to a US organisation actively listed on the DPF list, within the scope of its certification. It is not enough that a supplier is established in the United States or displays the programme logo. ^[10]

By its judgment of 3 September 2025 the General Court dismissed the action against that decision in case T-553/23. An appeal was lodged on 31 October 2025 and, as at 24 August 2026, case C-703/25 P is still pending before the Court of Justice with no hearing date set. The adequacy decision therefore remains in force and transfers made on its basis are lawful. ^[11] Sensible planning here does not mean abandoning the DPF prematurely; it means making sure the contract and the architecture would allow a switch to another transfer mechanism without interrupting the service.

Where the recipient is not covered by a valid adequacy decision, the basis may be, among others, the standard contractual clauses (SCC) of Decision 2021/914. The audit checks the correct module, the completion of the annexes, the transfer impact assessment, the technical and organisational measures, onward transfers and the ability to suspend the flow. The derogations of article 49 should not stand in for a permanent mechanism covering regular transfers. ^[12]

AI, employee monitoring and the website

Buying the enterprise edition of an AI tool does not settle GDPR compliance. It has to be established whether personal data ends up in prompts, attachments, logs, responses or the model; who is controller and who is processor; and what the purposes, legal bases, retention, sub-processors, transfers and training settings are. In opinion 28/2024 the EDPB stresses that the anonymity of a model and the possibility of relying on legitimate interests both require a case-by-case assessment. ^[13]

Article 4 of the AI Act on AI literacy among staff has applied since 2 February 2025. Training does not, however, create a legal basis for processing and does not replace GDPR obligations. ^[14]

Monitoring of company email is also governed by article 22³ of the Polish Labour Code: it has to be necessary for the statutory purposes, must not infringe the secrecy of correspondence or other personal rights, and requires the formalities for introducing monitoring to be met. The Polish supervisory authority indicates that deploying a system to monitor working time and information flow in email or on the internet requires a DPIA, because it combines high-risk criteria. That does not mean every incidental inspection automatically meets the threshold. ^[8][15]

In a website audit the GDPR is not the only instrument. Article 399 of the Polish electronic communications law governs the storage of information in, and access to information stored in, a user's terminal equipment, including ordinary cookies. Consent is not required in the statutory cases of necessity, but analytics and advertising tools have to be assessed separately. ^[15]

The DPO and management responsibility

A data protection officer has to be designated, among other cases, in public authorities and bodies, except for courts acting in their judicial capacity, and where the core activities require regular and systematic monitoring of data subjects on a large scale, or large-scale processing of special categories of data or of criminal conviction data. ^[1]

The DPO may be a member of staff or provide the service under a contract. The role needs resources, access to the highest level of management, the ability to act independently and freedom from conflicts of interest. The DPO does not, however, own compliance: responsibility for the decisions and the measures stays with the controller or the processor. An audit checks whether the DPO is involved early enough, rather than only after an incident or after a system has been bought.

How the audit runs, and what counts as evidence

1. Setting the scope. Entities, locations, processes, systems, period and assessment criteria.
2. Preliminary review. Records, policies, contracts, DPIAs, risk assessments, the breach register and earlier findings.
3. Interviews and process walkthroughs. Business owners, IT, security, HR, marketing, procurement, the DPO and customer service.
4. Sample testing. Permissions, data subject requests, retention, suppliers, privacy notices, breaches, backups and configurations.
5. Risk and compliance assessment. Every finding is given a legal basis, evidence, a consequence, an owner and a priority.
6. Remediation plan. Specific actions, dependencies, deadlines, the evidence that closes each item and the residual risk.
7. Verification. A finding is closed once the fix has been shown to work, not on the strength of a declaration.

The extent of the sample should be stated openly. If the auditor examined five contracts out of a hundred, or one system out of several environments, the report has to say so. Without that caveat a limited examination turns into an apparent guarantee.

Standards help, but they do not replace the law

ISO/IEC 27701:2025, published on 14 October 2025, describes a privacy information management system and replaced the 2019 edition. The change is not cosmetic: the new edition is a standalone standard, whereas the 2019 version was an extension of ISO/IEC 27001 and ISO/IEC 27002 and required an ISMS to be in place. Privacy certification without an ISO/IEC 27001 certificate is therefore possible today, which changes the economics for organisations that do not need a full ISMS. ISO/IEC 29134:2023 gives guidance on privacy impact assessments, and ISO/IEC 27001:2022 with Amd 1:2024 structures the information security management system. ^[16]

These are voluntary standards, not provisions of the GDPR. They can supply structure, criteria and evidence, but a certificate does not settle the lawfulness of a particular purpose, the validity of consent, the admissibility of a transfer or the fulfilment of an individual's rights.

The most recent published annual report of the President of the Personal Data Protection Office covers activity in 2024. It shows the breadth of complaints, breaches, inspections and decisions, but it does not create a universal checklist for every organisation. An audit should follow from the organisation's own processes and risk. ^[17]