GDPR Audit in 2026: Assessment of Technical and Organisational Measures
Тoday, personal data simultaneously exists within products, cloud infrastructure, analytics services, CRM systems, correspondence, spreadsheets, artificial intelligence models, and integrations with external services.
A GDPR audit should reveal not only what a company declares, but also what actually happens to personal data within its systems, processes, and the day-to-day work of its teams.
Why the Traditional GDPR Checklist No Longer Works
There are different approaches on the market. The scope of an assessment often looks something like this: a list of GDPR articles is taken, the company is asked to provide its privacy policy, contracts are reviewed, several boxes are ticked, and a report is prepared. The problem is that real compliance does not work this way.
A company may have the right policy but the wrong product. It may have a well-configured system, while employees bypass it by using email or an ordinary spreadsheet. It may have an agreement with a processor, while an external service has broad access through an API that no one has reviewed for two years.
An audit therefore involves three different “truths”:
- legal truth — what the company has declared in its documents, agreements, and governance system;
- technical truth — what the systems actually collect, transfer, store, protect, and delete;
- behavioural truth — how people actually work with data, where they invent workarounds, and how they create shadow data flows.
A proper audit begins where these three truths are compared with one another. The risk usually exists precisely in the gaps between them.
This is why GDPR paper tigers exist 😊
The Special Formula: 3 × 14 × 3
To prevent an audit from turning into a chaotic discussion about “everything related to the GDPR,” we propose a methodology consisting of three dimensions, fourteen domains, and three consecutive stages.
The formula sounds simple. In practice, each of its elements is responsible for a separate part of the assessment.
| Dimension | What we assess | Typical question |
|---|---|---|
| Legal | Lawful grounds, documents, transparency, governance, and accountability. | Does the legal model correspond to the actual processing? |
| Technical | Systems, access rights, APIs, event logs, backups, encryption, deletion, and integrations. | Can the system actually perform what the company promises? |
| Behavioural | Working habits, data exports, shared accounts, forwarding through email and work chats, and unauthorised services. | Are people bypassing the established rules? |
Methodology Formula
14 GDPR domains × 3 dimensions × 3 stages = a structured audit model that moves from the factual situation to documented gaps and a manageable remediation plan.
Step 0. First, Understand the Business
There is a temptation to begin an audit with documents. The proposed methodology begins with the story of the business: what the company sells, who the users are, where the data originates, why it is needed, and which teams, systems, and contractors are involved in the chain.
At the beginning of the audit, it is necessary to identify:
- key processing activities and business purposes;
- categories of data subjects and personal data;
- the geography of processing and international transfers;
- the main systems, databases, APIs, and external services;
- the people responsible for the relevant processes: product, legal, security, marketing, HR, and support;
- high-risk elements: profiling, artificial intelligence, biometrics, geolocation, surveillance, children’s data, or large-scale processing.
Step 1. Fact-Finding: Establishing How Everything Actually Works
This stage follows an evidence-based principle. Every statement should be supported by something that can be demonstrated: a document, screenshot, system export, event log, ticket, interview note, or step-by-step walkthrough of the system.
What Is Collected During the Fact-Finding Stage
| Working material | What it provides to the auditor |
| Record of processing activities | Processing activities, purposes, categories of data, systems, and responsible persons. |
| Data flow map | Where the data comes from, where it is modified, and where it is transferred. |
| System inventory | Applications, databases, storage facilities, integrations, and technical owners. |
| Lawful basis matrix | The purpose of processing, lawful basis, necessity assessment, and evidence. |
| Access matrix | System, role, access level, privileged accounts, MFA, and responsible person. |
| Contractor map | Processors and subprocessors, countries, DPAs, technical measures, and transfer mechanisms. |
| Retention map | Data category, system, retention period, deletion method, and backups. |
| Record of actual practices | Manual exports, unauthorised services, shared accounts, workarounds, and “temporary” copies. |
Documents are important here, but they are only one layer of evidence. For example, a policy may provide for deletion after 12 months. A system review, however, may show that there is no automatic deletion, archives have not been taken into account, and employees keep local spreadsheets “just in case.”
Practical Rule
Fact-finding shows what is actually happening. Until this stage has been completed, it is better not to rush to a conclusion that the company “complies” or “does not comply.”
Step 2. Gap Assessment: Finding Where the Model Diverges from Reality
Once the factual situation has been established, the assessment begins. The methodology proposes comparing the evidence with GDPR requirements, regulatory practice, and best practices.
The central question is simple: where do the legal model, technical reality, and human behaviour fail to correspond with one another?
To prevent the report from becoming a collection of general statements, gaps should be divided by type.
| Type of gap | How it appears in practice |
| Legal gap | Processing takes place, but there is no lawful basis or the chosen basis is incorrect. |
| Documentation gap | The actual movement of data is not reflected in the RoPA, notice, or policy. |
| Technical gap | The system does not support the declared requirement; for example, deletion does not work. |
| Process gap | There is no responsible person, response period, approval procedure, escalation route, or control point. |
| Evidence gap | The company states that a control works but cannot prove it. |
| Behavioural gap | Employees bypass the process or create uncontrolled data flows. |
| Contractor gap | A third party has access to or processes data without proper control. |
| Governance gap | There is no regular oversight, updating process, or evidence of accountability. |
A good gap record is not simply the phrase “update the privacy policy.” It should specify the assessment area, dimension, description of the issue, evidence, connection with the GDPR, risk, root cause, severity level, responsible person, recommended action, and deadline.
For example, the statement “the privacy notice does not describe the transfer of data to an analytics service” merely describes the surface of the issue. One properly documented gap will often reveal an entire chain of causes.
Step 3. Remediation Plan: Turning the Audit into a Manageable Programme of Change
This is where many audits fail. The company receives 60 pages of conclusions but does not understand what it should do on Monday morning. The result should therefore be not a list of suggestions, but an organised remediation work plan.
Each action should answer four questions:
- What exactly needs to be changed?
- Who is responsible?
- By what deadline must it be completed?
- What evidence will demonstrate completion?
| Type of remediation | Examples |
| Documents | RoPA, privacy notices, DPA, DPIA, LIA, retention policy, and DSAR procedure. |
| Processes | Assessment of new contractors, incident escalation, DSAR request workflow, access reviews, and privacy reviews before launch. |
| Technical measures | MFA, role-based access controls, logging, encryption, automatic deletion, API restrictions, and secrets management. |
| Culture and behaviour | Role-based training, an approved data export procedure, privacy representatives within teams, and a prohibition on unauthorised services. |
Evidence of completion is critical. The statement “MFA has been implemented” should be supported by an export from the access-management system, a screenshot, and access rules.
The statement “the DSAR process works” should be supported by the ticket workflow, deadline control, a test request, and an example response.
Final Logic
The gap assessment shows what is wrong. The remediation plan shows how to correct it, who will do so, and how the result will be demonstrated.
Fourteen Domains: Covering the Entire Data Lifecycle
The fourteen domains are not fourteen separate folders. They are fourteen mini-audits which, together, cover the journey of data from collection to deletion, including incidents, contractors, and the governance system.
| Domain | Main audit question |
| 1. Access management, authentication, and authorisation | Who actually has access? Are MFA, the principle of least privilege, access-granting, modification and revocation procedures, and logging of privileged actions in place? |
| 2. Encryption, passwords, and tokens | Where are credentials, API keys, tokens, logs, and backups stored? Is there any plaintext storage, weak hashing, or secrets stored in repositories? |
| 3. Incident response, breach detection, and notification | How does the company detect breaches, determine the moment at which it became aware of them, escalate the situation, and document the 72-hour period? |
| 4. Data protection by design and by default | What does the product collect and display by default? Are data minimisation and privacy reviews integrated into development? |
| 5. Technical control of contractors | What technical access does the contractor have? Are API permissions, subprocessors, and onward access restricted? |
| 6. DPIA and technical risk assessment | Have high-risk processing activities been identified? Have risks to individuals’ rights been assessed, and have mitigation measures been implemented? |
| 7. Video surveillance and monitoring | What exactly falls within the field of view, how long are recordings retained, are notices provided, who has access, and what is the lawful basis? |
| 8. Lawful basis and purpose compatibility | What are the purpose and lawful basis for each processing activity? Has there been any unnoticed expansion of purpose or a weak LIA? |
| 9. Consent, settings, and withdrawal | Is consent separate and demonstrable? Is it equally easy to withdraw, and does the withdrawal reach every relevant system? |
| 10. Transparency and notices | Do the notices explain the actual purposes, recipients, retention periods, transfers, and profiling? |
| 11. Exercise of data subject rights | Can the company locate, export, rectify, and delete data across every system within the required period? |
| 12. Retention and deletion | Does deletion work technically? What happens to archives, backups, logs, and local copies? |
| 13. Management of processors and third parties | Are there DPAs, descriptions of technical measures, contractor assessments, audit rights, subprocessor controls, and lawful transfer mechanisms? |
| 14. Accountability, documentation, DPO, and interaction with regulators | Can the company demonstrate compliance rather than merely claim it? |
Why use this particular structure? Because risks rarely exist in one place.
A consent issue may simultaneously be a legal gap, a technical synchronisation error between the consent banner and the CRM, and a behavioural issue where the marketing team continues campaigns after consent has been withdrawn.
A retention issue may begin with a policy, continue with the absence of automatic deletion, and end with local copies stored in email.
Typical GDPR Non-Compliance Scenarios
GDPR risks tend to repeat themselves. The industry may be different and the product may be different, but the structure of the problems is often the same.
1. Paper compliance. Documents exist, but no one has checked whether they correspond to the actual architecture and working processes.
2. The data map ends with the “official” systems. It does not include exports, shared drives, support attachments, local files, or unauthorised services.
3. Consent exists only in the banner. The status is not synchronised with the CRM, analytics services, or suppression lists, and withdrawal of consent does not propagate any further.
4. Retention periods exist, but deletion does not. Periods have been defined, but the system does not delete the data, backups have not been taken into account, and there is no evidence of deletion.
5. The DPA is signed, but the contractor’s access is not controlled. The agreement is satisfactory, but API permissions are broad, access logs are not reviewed, and subprocessors are unknown.
6. A DSAR procedure exists, but there is no search map. The company knows how to respond from a legal perspective but does not know where to physically locate all data relating to a particular individual.
7. The DPO or privacy team is involved after launch. The review takes place after the purpose, architecture, and contractor have already been selected, when changing the product has become expensive.
In 2026, these scenarios are becoming even more visible because of artificial intelligence, profiling, cloud architecture, and the interaction between the GDPR and other digital regulations.
What Should Remain After a Good GDPR Audit?
Following an audit, the company should receive an evidence-based set of materials that can be used for remediation, management reporting, pre-transaction reviews, and ongoing monitoring.
The minimum set may include:
- a concise management summary covering the key risks, business impact, and principal priorities;
- a record of processing activities and data flow map;
- inventories of systems, access rights, contractors, and retention periods;
- a gap register containing evidence, risks, root causes, and priorities;
- a remediation plan specifying responsible persons, deadlines, and evidence of completion;
- an evidence repository enabling the company to demonstrate the basis for the conclusions;
- a schedule for regular post-audit risk reviews.
The key point is that the audit should not remain static. Imagine a GDPR audit as a book that you are reading, except that you cannot skip pages or go back — unless it is to check what happened earlier.
Conclusion: A GDPR Audit as a Reconstruction of the Real Life of Data
A GDPR audit in 2026 is not a search for a missing policy. It is a reconstruction of the real life of personal data within the company.
The proposed methodology breaks the system down into its components, examines it from legal, technical, and behavioural perspectives, takes it through fourteen risk areas, and follows a clear sequence: facts first, gaps second, changes third.
The essence of the approach can be summarised in three sentences:
- Fact-finding shows what is actually happening.
- Gap assessment shows exactly what is not working and why.
- The remediation plan shows how to correct it and how completion will be demonstrated.
If a policy is not supported by evidence from the system, it is merely an intention. If a control has no responsible owner, it is temporary. If implementation cannot be demonstrated, then from an accountability perspective, it almost does not exist.
A good GDPR audit therefore does not end with the conclusion that “risks exist.” It ends with a manageable model in which the company understands how its data moves, knows its priorities, and can demonstrate that compliance works not only on paper.
