GDPR in 2026: The 10 Mistakes Businesses Are Still Making

GDPR came into force in May 2018. Eight years later, data protection authorities across Europe continue to issue significant fines for the same categories of violation. The law has not become more complex — enforcement has become more experienced. Regulators know where to look, what questions to ask, and what documentation to request. And the gap between organisations that have genuinely embedded GDPR into their operations and those that performed a 2018 compliance exercise and moved on has become increasingly visible.

These are the ten mistakes that appear most consistently in enforcement decisions, regulatory guidance, and audit findings. None of them are obscure. All of them are avoidable.

Mistake 1: Treating the privacy notice as the compliance programme

The privacy notice is a disclosure obligation. It tells people what you do with their data. It is not a compliance system. Organisations that updated their privacy notice in 2018 and treated GDPR as done have a disclosure document and nothing beneath it.

A functioning GDPR programme requires: documented lawful basis for each processing activity, working data subject rights processes, a breach response capability, retention schedules that are actually enforced, and third-party processor agreements that are current. The privacy notice reflects these things. It does not replace them.

Mistake 2: Relying on consent when you do not need it

Consent is one of six lawful bases for processing personal data under GDPR. It is often the hardest to maintain correctly — it must be freely given, specific, informed, and unambiguous, and it can be withdrawn at any time. Yet many organisations default to consent for processing activities that could be based on a more appropriate ground.

If you process personal data because it is necessary to perform a contract, use contractual necessity. If you process it to meet a legal obligation, use legal obligation. If you process it for a legitimate business purpose that is proportionate and does not override individuals’ rights, use legitimate interests with a documented balancing test.

The problem with unnecessary consent reliance is not just administrative. Every consent-based processing activity creates an ongoing obligation to manage withdrawals, track consent versions, and re-obtain consent when purposes change. If the consent was not necessary in the first place, this overhead is avoidable.

Mistake 3: Forgetting about processors

Every time you share personal data with a third-party service provider that processes it on your behalf — a cloud provider, a payroll processor, a marketing platform, an IT support company — you are required to have a Data Processing Agreement in place. The DPA must include mandatory clauses covering the processor’s obligations, the subject matter and duration of processing, and your rights to audit.

Most organisations have some DPAs. Few have reviewed them recently, and fewer have DPAs with all of their processors. The providers most commonly missed: IT support companies who have access to internal systems, HR platforms, document storage services, and business intelligence tools.

A processor that suffers a breach of your data without a DPA in place creates compounded liability for your organisation.

Mistake 4: Vague or bundled consent for marketing

Electronic direct marketing consent must be specific to the purpose and the channel. A checkbox that says “I agree to receive communications from our partners” does not constitute valid consent for email marketing. Neither does a pre-ticked box. Neither does a checkbox buried in the terms of service.

Consent for marketing must be: separate from other consent (not bundled with terms acceptance), specific to the channel and purpose, documented with the timestamp and the exact wording presented, and withdrawable through a mechanism that actually works.

Enforcement authorities in Spain, Italy, France, and Germany have issued some of their highest-volume sanctions for exactly this category of violation.

Mistake 5: Failing to respond to data subject requests on time

The one-month response window for data subject requests runs from the date of receipt, not the date someone first looks at it. A request received on a Friday afternoon and not noticed until Wednesday is already four days old.

Common failures: no defined process for receiving and tracking requests, no clear ownership of who responds, no escalation for complex requests that may require the two-month extension, and no documentation of the response timeline.

Data protection authorities track the handling of subject access requests carefully — they are among the most common sources of complaints that trigger formal investigations.

Mistake 6: Keeping data longer than necessary

Retention schedules are required under GDPR’s storage limitation principle. Personal data must be kept no longer than necessary for the purpose for which it was collected. Yet most organisations have never implemented an automated retention policy — data accumulates indefinitely in email systems, shared drives, and databases.

The enforcement risk is concrete: an organisation that retains former customer data for ten years beyond the relationship, without a legal basis for doing so, is processing that data unlawfully for every day of that retention.

Building a retention schedule is not complicated. Enforcing it automatically — rather than relying on manual deletion — requires the right infrastructure.

Mistake 7: Not documenting the legitimate interests assessment

Legitimate interests (Article 6(1)(f)) is a flexible lawful basis that allows processing of personal data where there is a genuine business purpose, the processing is necessary, and the interests of the business do not override the rights of the data subject. It requires a balancing test — documented.

The documented legitimate interests assessment (LIA) is frequently requested during regulatory investigations and routinely absent. Organisations that say they rely on legitimate interests but cannot produce a contemporaneous LIA have effectively claimed a lawful basis they cannot evidence.

Mistake 8: No breach register

GDPR Article 33(5) requires organisations to document all personal data breaches, including those that do not meet the notification threshold. The breach register must include the facts of the breach, its effects, and the remedial actions taken.

The majority of SMBs either have no breach register or have an empty one. When a breach occurs and the supervisory authority investigates, the absence of a register — or a register that shows only one entry (the current breach) — indicates that prior events were not identified or documented.

Mistake 9: Staff training that is not documented

GDPR compliance requires that staff who handle personal data understand their obligations. Training is a standard expectation. But training that happened once in 2019, with no records of who attended, is not a compliance asset — it is a liability. Regulators view undocumented training as equivalent to no training.

Training records should be individual-level (not just “a session was held”), dated, and retained for a defined period. Annual refreshers are expected for staff with significant data handling responsibilities.

Mistake 10: Ignoring cross-border transfer obligations

Every time personal data of EU residents moves outside the European Economic Area, the transfer requires a legal mechanism. Standard Contractual Clauses are the most common — but they require a Transfer Impact Assessment confirming that the destination country provides adequate protection in practice.

The Schrems II ruling in 2020 invalidated the Privacy Shield and made TIAs mandatory for transfers to the US. Many organisations implemented SCCs but never conducted the required TIA. The mechanism exists on paper; the substance does not.

Supervisory authorities are increasingly investigating cloud service usage and asking for TIA documentation. Organisations that cannot produce one for each significant cross-border transfer are exposed on a processing basis they considered resolved.

The common thread

Every one of these mistakes has the same root cause: compliance was treated as a documentation exercise rather than an operational programme. The policy was written, the notice was updated, the DPAs were signed — and then nothing changed in how the organisation actually handles data.

The organisations that pass regulatory examinations are not those with the best policies. They are those whose daily operations produce the evidence that the policies are real.