GDPR Isn’t a Cookie Banner: The Audit Findings That Actually Get Companies Fined
Seven years after GDPR took effect, most organizations still treat it like a checkbox they ticked in 2018. They dropped in a cookie banner, published a privacy policy their own lawyers haven’t read since, and moved on. Then a data subject access request lands, or a breach hits, or a regulator comes knocking — and suddenly the gap between “we have a privacy policy” and “we can actually demonstrate compliance” becomes very, very expensive. The uncomfortable truth I keep running into in audits is that GDPR failures rarely look dramatic. They’re not master hackers exfiltrating databases. They’re mundane, systemic gaps that sat quietly in plain sight until the day they didn’t. And with AI now feeding on personal data for marketing, sales, and product decisions, the old gaps have gotten wider and the new ones are appearing faster than most compliance programs can track.
Here’s what I actually find when I open the hood — and, more importantly, how to fix it.
Finding #1: No Defensible Lawful Basis (Especially for AI)
What I find: Organizations collect personal data across forms, chat, analytics, and enrichment tools without a documented lawful basis for each processing activity. When AI enters the picture, this gets worse — data collected for support or account management quietly gets repurposed to train or run marketing models, with no fresh basis and no assessment. “Legitimate interest” is invoked as a magic phrase, but no Legitimate Interest Assessment (LIA) exists to back it up.
Why it matters: Lawful basis is the foundation of the entire regulation. Without it, every downstream activity is built on sand — and repurposing data for AI without a compatible basis is one of the fastest-growing enforcement themes in Europe.
How to remediate: Build a processing inventory that maps each data type to a specific lawful basis. Where you rely on legitimate interest, write the LIA — a genuine three-part balancing test, not a paragraph. For any AI use, treat it as its own processing activity: document the basis for feeding personal data into the model, and never assume that consent for one purpose covers another.
Finding #2: The Privacy Notice Doesn’t Match Reality
What I find: The privacy policy describes a company that stopped existing years ago. It doesn’t mention the AI tools now processing customer data, doesn’t name key processors, and says nothing about profiling or automated decision-making. It’s transparency theater — technically present, functionally useless.
Why it matters: Transparency is a legal obligation, not a courtesy. If you’re using AI to score, segment, or make decisions about people, they have a right to know — in plain language — what’s happening and what it means for them.
How to remediate: Rewrite the notice to reflect current reality. Disclose AI processing explicitly, describe what the AI does with personal data, name your processor categories, and clearly explain any profiling and its likely consequences. Then put a recurring review on the calendar — a privacy notice is a living document, not a monument.
Finding #3: Data Subject Rights Requests Can’t Reach the AI Layer
What I find: The company can pull a record from the CRM when someone files an access or erasure request — but has no idea how to locate that person’s data inside the AI system, its logs, or its training set. Worse, when someone objects to marketing or profiling, the objection updates a flag in one system while the AI keeps processing them unchanged.
Why it matters: Rights that stop at the CRM aren’t rights. “We can’t delete that from the model” is a finding, not an acceptable answer — and an objection that doesn’t actually stop processing is a live violation every day it persists.
How to remediate: Map where personal data flows across every system, including the AI layer and its logs. Build rights fulfillment that propagates: an objection or erasure request must reach — and take effect in — the AI system, not just the primary database. Where model training makes deletion technically hard, document your handling approach in advance rather than improvising under a 30-day clock.
Finding #4: Vendor Contracts and Transfers Left Unmanaged
What I find: Personal data flows to a stack of third parties — AI vendors, ad platforms, analytics, enrichment services — often without signed Article 28 Data Processing Agreements. The AI vendor’s terms are unread, meaning nobody actually knows whether the vendor is training its own models on the company’s data. And data routinely leaves the EEA (frequently via US-based AI providers) with no valid transfer mechanism and no Transfer Impact Assessment.
Why it matters: You remain accountable for personal data even after it leaves your systems. An unread AI vendor contract that permits training on your data can turn your customers’ information into someone else’s product — and undocumented international transfers are a well-established enforcement target.
How to remediate: Inventory every processor and sub-processor. Get signed DPAs in place, and read the AI vendor’s terms specifically for whether your data trains their models — get that prohibited in writing if it isn’t already. For any transfer outside the EEA, confirm a valid mechanism (SCCs or adequacy) and complete a Transfer Impact Assessment for high-risk vendors.
Finding #5: No DPIA for High-Risk Processing
What I find: The organization is doing exactly the kind of large-scale profiling and automated decision-making that makes a Data Protection Impact Assessment mandatory under Article 35 — and no DPIA exists. There’s also no Record of Processing Activities that includes the AI, so when a regulator asks the company to demonstrate compliance, there’s nothing to hand over.
Why it matters: GDPR runs on accountability. It’s not enough to be compliant; you have to be able to prove it. A missing DPIA on high-risk AI processing is both a violation in itself and a signal to any regulator that the deeper controls probably aren’t there either.
How to remediate: Run the DPIA before scaling the AI initiative, not after. Document the processing, the risks to individuals, and the mitigations — and consult your DPO. Update the Article 30 Record of Processing Activities to include the AI. These artifacts are the evidence that turns “we think we’re compliant” into “here’s the file.”
My Perspective
After enough of these audits, a pattern becomes impossible to ignore: GDPR compliance almost never fails on the technology. It fails on the paper trail and the follow-through. The encryption is usually fine. What’s missing is the documented lawful basis, the honest privacy notice, the rights process that actually reaches every system, and the evidence that ties it all together. GDPR is, at its core, an accountability regime — and accountability is exactly the muscle most organizations skipped building.
AI has raised the stakes considerably. The same discipline GDPR has demanded since 2018 — know your data, justify your processing, honor people’s rights, prove it — is now the same discipline that frameworks like ISO 42001 and the EU AI Act demand for AI systems. That’s not a coincidence; it’s convergence. The companies that treated GDPR as a genuine data-governance practice rather than a cookie banner are the ones now absorbing AI governance almost effortlessly. The ones that faked it in 2018 are discovering there’s nothing underneath to build on.
My advice is simple and unglamorous: stop auditing for the banner and start auditing for the evidence. Can you produce your lawful basis, your DPIA, your vendor DPAs, and your rights-fulfillment records on demand? If yes, you’re most of the way there. If not, that gap won’t announce itself — until the day a request, a breach, or a regulator forces it into the open. Fix it while it’s still your choice.
AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do
Your Shadow AI Problem Has a Name-And Now It Has a Score
Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.
InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security
- The AIMS/ISMS readiness ladder: seven steps from curious to certified
- AI Governance Careers: The Skills Gap Nobody Is Filling (2026)
- AI Governance & Cybersecurity That Holds Up Under Scrutiny
- “Sorry, Typo”: Why a Markdown File Is Not a Security Control
- Security against defeat implies defensive tactics; ability to defeat the enemy means taking the offensive
DISC InfoSec blog | DISC InfoSec Site
. It should be a clear and concise document that is accessible by individuals.
the requirements on giving privacy information to data subjects. These are more detailed and specific than in the 
Act 1998 (DPA).
, and has been used by thousands of organisations worldwide. It includes:
; and
) (EU 2016/679 regulation) coming up on 25 May 2018, many organizations are addressing their data gathering, protection and retention needs concerning the privacy of their data for EU citizens and residents. This regulation has many parts, as ISACA has described in many of its 
view is that privacy is an essential part of functionality, the security of the system and its processing activities.
across the entire processing effort for the affected data. This end-to-end need for protection includes collection efforts, retention requirements and even the new “right to be forgotten” requirement, wherein the customer has the right to request removal of their data from an organization’s storage.
demands the 
implemented are proactive rather than reactive. As its principal goal, the system needs to prevent issues, releases and successful attacks. The system is to keep privacy events from occurring in the first place.
, the most important point for organizations to understand about GDPR is transparency. The EU wants full disclosure of an organization’s efforts, documentation, reviews, assessments and results available for independent third-party review at any point. The goal is to ensure privacy managed by these companies is not dependent upon technology or business practices. It needs to be provable to outside parties and, therefore, acceptable. The EU has purposely placed some strong fine structures and responses into this regulation to ensure compliance.
, it has been found that it is good practice to look at these 6 areas for all the collected and retained data, not just EU-based data. This zero-tolerance approach to data breaches is purposely designed to be stringent and strong. Good luck to all in meeting and maintaining the data privacy and security requirements of 
.
