Five years after GDPR became enforceable, DPAs across the EU are running out of patience. The fines issued in 2024 totalled over €2.1 billion — and the enforcement trend for 2025 is steeper. What's striking is how many of those fines trace back to the same operational failures, repeated by companies that understood the regulation perfectly well in theory.
Here are the five mistakes we see most frequently, and what fixing them actually looks like in practice.
1. Treating data subject requests as edge cases
The most common compliance gap we encounter isn't a missing privacy policy or an unsigned DPA. It's a shared inbox with 200 unread deletion requests.
Under GDPR Article 12, controllers have 30 days to respond to any data subject request — access, erasure, portability, restriction, or objection. That clock starts the moment the request arrives, regardless of how it arrives. It doesn't pause because the team is busy, because the request was sent to the wrong address, or because nobody was sure which department owned it.
Many SaaS companies treat Subject Access Requests (SARs) as rare legal events rather than operational processes. They are neither. A mid-sized B2B SaaS with 5,000 active users should expect dozens of SARs per year. A consumer-facing platform should expect hundreds. The companies that fail are the ones who wait for their first penalty before building a response workflow.
The fix: Classify every inbound SAR immediately. Assign it to an owner. Track the 30-day deadline explicitly. None of this requires legal counsel — it requires a process.
2. "Legitimate interests" used as a blanket exemption
Legitimate interests under Article 6(1)(f) is one of the six lawful bases for processing personal data. It requires a three-part balancing test: identifying the legitimate interest, assessing whether processing is necessary for that interest, and weighing it against the data subject's rights and expectations.
In practice, many SaaS companies list "legitimate interests" as their lawful basis for every processing activity that doesn't fit neatly into consent. Analytics. Behavioural profiling. Email marketing. Fraud detection. Sales outreach. The logic is understandable — consent is brittle and legitimate interests feels more flexible. But regulators have made clear that this approach fails the balancing test for broad categories of processing, particularly where individuals have a reasonable expectation of not being tracked.
The fix: Conduct and document a Legitimate Interests Assessment (LIA) for each processing activity where you rely on this basis. The documentation is the defence — without it, you have a legal basis in name only.
3. Incomplete Records of Processing Activities
Article 30 of GDPR requires organisations with more than 250 employees — and all organisations whose processing is likely to result in a risk — to maintain a Record of Processing Activities (ROPA). In practice, the threshold is interpreted broadly enough that almost every SaaS company of substance should have one.
A ROPA is a living document. It needs to reflect actual data flows, not the data flows you thought you had when you wrote it two years ago. The product has shipped seven new features since then. You've onboarded three new sub-processors. You're now storing session recordings. None of that is in the document.
Regulators increasingly use ROPA audits as the opening move in an investigation. An incomplete or outdated ROPA signals poor governance and typically leads to a broader inquiry.
The fix: Review your ROPA every time you onboard a new vendor, launch a new feature that processes personal data, or change a data retention period. Treat it as infrastructure, not a compliance artefact.
4. Sub-processor agreements signed once and forgotten
Article 28 requires that every sub-processor — any third party processing personal data on your behalf — be governed by a contract that imposes GDPR-equivalent obligations on them. This includes your analytics platform, your customer support tool, your marketing automation system, your cloud infrastructure provider, and any AI service you're passing user data to.
The problem isn't usually that these contracts don't exist. It's that they were signed during onboarding and never reviewed again. Sub-processors change their terms, add new sub-sub-processors, or shift their data processing infrastructure to non-EEA jurisdictions. You're responsible for knowing when this happens.
The fix: Maintain a register of all sub-processors with the date their DPA was reviewed. Set a calendar reminder to recheck any sub-processor's terms annually, and whenever you receive a terms-of-service update email.
5. Ignoring the 72-hour breach notification window
Article 33 requires notification to your supervisory authority within 72 hours of becoming "aware" of a personal data breach. The word "aware" has been interpreted by multiple DPAs to mean aware of a reasonable probability of a breach, not awareness of confirmed, verified facts.
Most companies don't miss this deadline because they don't care — they miss it because their internal escalation process takes three days, or because the engineering team spends 48 hours trying to understand the scope before telling legal. By then, the window has closed.
The EDPB's guidance is unambiguous: you don't need to have full details before notifying. An initial notification with incomplete information is acceptable. A late notification with complete information is not.
The fix: Define a breach response playbook with clear escalation triggers and timelines. The 72-hour clock should be the organising principle, not the afterthought.
None of these failures are obscure edge cases. They're the operational gaps that separate companies with genuine GDPR compliance programmes from companies with privacy policies. The distinction matters more than it did in 2019 — regulators now have the investigative capacity and the precedent to act on it.