GDPR audit in 2026: how to test compliance, not just documentation

Accountability as the core audit principle

Article 5(2) of the GDPR establishes accountability: the controller is responsible for compliance with the processing principles and must be able to demonstrate it. Article 24 requires appropriate technical and organisational measures and their review and updating where necessary.^[1] An audit is one method of obtaining evidence, but a positive report does not create compliance by itself.

There is no single universal "GDPR compliance certificate". Certification mechanisms under Article 42 are voluntary and do not reduce the controller's or processor's responsibility. An audit must also state its scope clearly: a conclusion about recruitment processing says nothing about CCTV, marketing, or a clinical system if those areas were not examined.

A strong report should distinguish at least four types of finding:

• breach of a specific legal obligation, such as absence of a lawful basis or a missing transparency notice;
• risk to the rights and freedoms of individuals, such as overly broad access to sensitive records;
• a security weakness, such as an insufficiently protected administrative account;
• absence of evidence, where a control is claimed but no test, record, owner, or result exists to verify it.

Start with a map of processing

An audit should begin with the real map of processes, systems, datasets, data flows, and recipients. The Article 30 record of processing activities is an important source, but it should not be treated as an automatically accurate description of the organisation. It needs to be reconciled with application configuration, contracts, logs, forms, accounts, integrations, working copies, and actual employee practice.

Roles must also be classified correctly. A controller determines purposes and means. A processor processes personal data on behalf of a controller. Joint controllers jointly determine purposes and means for the relevant processing. The label in a contract does not decide the legal role if the facts show otherwise.^[3]

The Article 30 exception for organisations with fewer than 250 employees is narrow. It does not apply where processing is likely to result in risk, is not occasional, or includes special-category data or data relating to criminal convictions and offences. Permanent HR, customer, or user processes therefore often require a more detailed analysis than simply citing headcount.

Purposes, legal bases, and the Article 5 principles

Each processing purpose should have an appropriate Article 6 basis. Consent is only one of the available bases and should not be selected automatically. Special categories of data also require an Article 9 condition. The audit performs this assessment for specific purposes and operations rather than assigning one legal basis to an entire application.^[1]

The Article 5 principles must be tested as well: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality. A date of birth may be necessary in one process and excessive in a basic contact form.

Retention should not be one number for the whole organisation either. It needs to be tied to purpose, specific legislation, limitation periods, and the event that starts the retention period. A statement such as "we keep data for 5 years" without saying what the period runs from is not a retention rule but the appearance of one.

Privacy by design and privacy by default

Article 25 requires data protection by design and by default.^[1] An audit should therefore examine change and procurement processes: before a new system goes live, does anyone assess purpose, data scope, access rights, retention, interfaces, logging, suppliers, transfers, and risk?

Default settings should restrict processing to what is necessary for the relevant purpose. This does not create one mandatory technical configuration for every system. It requires deliberate design rather than expecting users to disable excessive collection or publication themselves. If no moment exists in the organisation at which someone asks these questions before deployment, Article 25 remains a statement in a policy.

Data-subject rights: procedures must work across systems

Testing rights should not stop at reading a procedure. A better test follows a real or controlled request from identity verification, through data discovery in internal and processor systems, to the decision, response, and evidence that the deadline was met.

As a rule, the controller responds without undue delay and within one month. The period may be extended by two further months where necessary because of complexity or number of requests, but the individual must be informed of the extension and reasons within the first month.^[1]

The right of access does not automatically require release of every original document. The controller must provide a copy of the personal data undergoing processing in a form that allows effective exercise of rights while respecting the rights and freedoms of others. CJEU case law clarifies the meaning of a copy and the obligation to provide a faithful and intelligible reproduction of the data.^[4]

Suppliers, processors, and shadow IT

An Article 28 contract is needed where a provider processes personal data on behalf of the controller. The audit should check not only the existence of clauses but whether they match the actual service: subject matter and duration, purpose, categories of data and persons, confidentiality, security, sub-processors, assistance with rights and breaches, return or deletion, and audit rights.^[1]

The supplier inventory should also include tools introduced directly by departments and employees: free applications, test accounts, OAuth integrations, analytics tools, ticket systems, repositories, transcription services, and generative-AI products. A vendor's statement that its service is "GDPR compliant" is not evidence that the organisation's particular use is compliant.

The European Commission has published standard controller-processor clauses for Article 28.^[5] They should not be confused with the Standard Contractual Clauses used as one transfer mechanism under Chapter V.^[6] These are two different instruments with different purposes, and they are regularly swapped in documentation.

Article 32: security appropriate to risk

GDPR does not prescribe a universal product list. Controllers and processors consider state of the art, implementation costs, the nature, scope, context and purposes of processing, and risks to individuals. Pseudonymisation, encryption, confidentiality, integrity, availability and resilience, restoration capability, and regular testing and evaluation are examples in Article 32, but selection must be risk based.^[1]

A technical audit may cover:

• identity management and account lifecycle;
• privileged access and MFA where justified;
• encryption in transit and at rest, including key management;
• backups, restore capability, and resilience;
• patching, vulnerability management, and hardening;
• segmentation and traffic restriction;
• logging and incident detection;
• endpoint, mobile-device, and email security;
• supplier security and remote access;
• secure deletion of data and media.

Encryption does not correct excessive data collection or misuse by an authorised user. A backup does not demonstrate resilience if nobody can restore it. In an audit, proof of operation is therefore more important than the name of the purchased tool.

Article 32 does not establish a universal annual penetration test or a single vulnerability-scan interval for all organisations. It requires regular testing, assessing, and evaluating the effectiveness of measures appropriate to risk. Frequency should follow system characteristics, changes, incident history, exposure, and other applicable regulation.

Personal-data breaches

Not every cybersecurity incident is a personal-data breach, and not every personal-data breach must be notified to the supervisory authority. First determine whether a security breach led to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. The controller then assesses risk to individuals.^[1]

Where a breach is likely to result in risk, notification to the authority is made without undue delay and, where feasible, within 72 hours after becoming aware of it. Where the risk is high, communication to individuals may also be required. A processor notifies the controller without undue delay after becoming aware of a personal-data breach.

An audit should examine a sample of incidents, including incidents that were not notified. The central evidence is documented reasoning: what occurred, what data and individuals were affected, what safeguards operated, how likelihood and severity were assessed, and who approved the decision. Not notifying is acceptable if it can be justified; the problem is the absence of any record of the decision.

DPIA: when high risk must be assessed

A Data Protection Impact Assessment is required where a type of processing, in particular using new technologies, is likely to result in high risk to individuals. Article 35 gives examples, and the supervisory authority publishes a list of processing operations requiring a DPIA.^[1][7]

The audit should not ask only "is there a DPIA?". It should test whether the organisation has a mechanism for identifying projects that require one, whether the DPIA was carried out before high-risk processing began, whether it includes risk-reducing measures, and whether it is reviewed when risk changes.

Employee monitoring, profiling, biometric data, new analytics, or AI solutions may increase the likelihood of high risk, but not every implementation automatically requires a DPIA. The concrete processing and the Article 35 criteria must be assessed.

Transfers outside the EEA

A common audit error is equating server location with absence of an international transfer. Data may be stored in Frankfurt while remote administration, support, telemetry, backups, or a sub-processor is outside the EEA. The whole processing chain must be examined.

A transfer may rely, among other mechanisms, on an adequacy decision or appropriate safeguards such as Standard Contractual Clauses.^[6] After Schrems II, signing the clauses alone does not end the analysis: the exporter must assess whether essentially equivalent protection can be ensured in the specific circumstances and apply supplementary measures where necessary. The EDPB has issued detailed recommendations on this.^[8][9]

The EU-US Data Privacy Framework remains, on 29 August 2026, a transfer mechanism for U.S. organisations that actually participate in the framework and for the scope covered by their certification. The 2023 Commission decision does not automatically cover every U.S. company.^[10]

In 2025, the General Court dismissed the action in T-553/23 Latombe v Commission. An appeal, C-703/25 P, was subsequently filed and remains pending on 29 August 2026.^[11] An audit should therefore describe the mechanism as currently valid rather than as finally confirmed forever.

GDPR and artificial intelligence

Generative AI creates several parallel questions: is there a legal basis for transmitting data to the model, is data minimised, who is controller or processor, where does the data go, is it used for further training, what is the retention period, who can access conversation history, and how can data-subject rights be exercised?

EDPB Opinion 28/2024 on AI models explains, among other matters, that model anonymity must be assessed case by case and that reliance on legitimate interests requires a full necessity and balancing test. It also addresses how unlawful processing during model development can affect later operations.^[12]

The AI Act does not replace GDPR. Both may apply to the same system. In 2026, part of the schedule changed: Sections 1-3 of Chapter III for high-risk systems under Article 6(2) and Annex III apply from 2 December 2027, while systems under Article 6(1) and Annex I apply from 2 August 2028. The AI-literacy duty in Article 4 belongs to Chapter I and has applied since 2 February 2025.^[13][14]

DPO: independence and conflicts of interest

A Data Protection Officer may perform other tasks provided they do not create a conflict of interests. An audit should test the DPO's actual position: access to top management, timely involvement in projects, resources, freedom from instructions on DPO tasks, and whether other duties require the person to determine purposes and means that they are then expected to oversee independently.^[1][15]

Conflict of interest does not follow from a job title alone. A person who independently decides architecture and processing purposes for a system may be conflicted if the same person is expected to provide independent oversight of that solution.

ISO/IEC 27701:2025

ISO/IEC 27701:2025 is the current edition of the privacy information management system standard and replaced the 2019 edition. It can help structure roles, risks, processes, and privacy evidence, but it is not Polish law and certification does not replace a GDPR compliance analysis.^[16]

In practice it is most useful as a documentation skeleton for an ISMS extended to cover privacy, rather than as a substitute for legal assessment of specific processing operations.

How to perform an evidence-based audit

For each area, use simple triangulation:

1. What does the organisation state in a policy, register, or contract?
2. What does the system configuration, log, form, database record, or case sample show?
3. What do the process owner, employee, and supplier actually do?

If these three views differ, the audit has probably found a more important problem than another missing document.

Example samples include newly hired and departed staff, including grant and revocation of access; data-subject requests and response deadlines; deletion after retention periods; consent records and withdrawal; processor agreements and sub-processors; remote support transfers outside the EEA; incidents and decisions to notify or not notify; backup-restore tests; new IT projects and DPIA decisions; and employee use of generative AI.

In 4crypto audits, the legal review can be combined with technical verification of configuration, email security, hardening, vulnerabilities, and logging. The criteria should remain separate: absence of a technical vulnerability does not prove data minimisation, while a perfect privacy notice does not prove effective authentication.

Common mistakes

1. Auditing documents only. GDPR concerns real processing, not a binder.
2. Treating consent as the default legal basis. Depending on the process, contract, legal obligation, public task, or legitimate interests may be the appropriate basis.
3. Retaining data "just in case" without defined retention rules and deletion mechanisms.
4. Treating a vendor's compliance statement as a substitute for evaluating roles, contract, security, and transfers.
5. Equating an EU data-centre location with absence of transfers outside the EEA.
6. Performing a DPIA after deployment merely to complete the project file.
7. Assuming an enterprise AI subscription by itself solves lawful basis, minimisation, retention, and transparency. It may improve security and contractual conditions but does not remove controller obligations.

What the report should contain

The report should identify:

• organisational, process, and system scope;
• criteria and legal-status date;
• evidence types and the sampling method;
• findings linked to specific provisions;
• separate assessment of risk to individuals and security weaknesses;
• implementable recommendations and their owners;
• deadline and evidence required to close a finding;
• audit limitations, including inaccessible systems or insufficient data.

The report should not promise "100% compliance" without reference to scope and time. Processing changes with systems, suppliers, employees, and purposes. An audit is a snapshot of status and a test of the governance mechanism, not a permanent guarantee.