GDPR went into effect on 25 May 2018. Eight years later, the same five mistakes keep showing up in custom software we audit. Here's how to avoid them.
By now, GDPR shouldn't be news. The text is stable, the case law is mature, and the supervisory authorities have been issuing fines long enough that there's no excuse for surprise. And yet — most custom software we audit in 2026 still gets the same things wrong. These aren't edge cases. They're the basics.
1. Storing things "just in case"
The most common GDPR violation we find is also the most preventable: collecting and storing personal data because "we might need it later." A signup form that asks for date of birth, gender, and physical address — when the service has nothing to do with any of those.
GDPR's data minimisation principle isn't subtle. If you don't have a defined purpose for a piece of data, don't collect it. If you do collect it, document the purpose and retain it only for as long as that purpose lasts.
A useful test: for every column in your users table, can you answer in one sentence why you need it and how long you'll keep it? If you can't, delete the column or document the answer.
2. Audit logs as an afterthought
Most systems we audit have application logs (debug traces) and almost nothing else. When a regulator or a customer asks "who accessed this person's data and when?", the team scrambles through Kibana hoping the right log line was emitted.
A proper audit log is its own structured event stream:
- Every read of personal data — by whom, when, and which records.
- Every modification — old value, new value, actor, reason.
- Every export, download, or external transmission.
- Immutable append-only storage with retention aligned to your policy (often 6 years for accounting-adjacent data, longer for healthcare).
And — this is the part most teams miss — the audit log itself must be auditable. Access to read the audit log is itself an audit event.
3. The "checklist" mindset
GDPR isn't a checklist. It's a set of principles enforced by regulators who care about whether you've actually internalised them. Teams that approach GDPR as "we ticked the boxes, we're compliant" tend to fail the first real test.
The principle that matters: when in doubt, ask "would the data subject expect this use of their data?" If the answer is no, you probably need consent or a different lawful basis. If the answer is "they didn't think about it," you have a problem.
4. Right to erasure — but where?
"Right to be forgotten" sounds simple until you map the systems where personal data ends up:
- The primary database.
- The read replicas (and how soon they catch up).
- The data warehouse and BI tools.
- Backups (and how long those are kept).
- The CDN cache.
- Search indexes.
- Email logs and CRM.
- The third-party processors you've sent data to.
A real erasure path either deletes from all of these, or anonymises with documented reasoning for the ones where deletion isn't operationally feasible (backups being the classic case). Either way, it's a coordinated process, not a DELETE statement.
5. Third-party processors that nobody tracks
By GDPR Article 30, you must keep a record of processing activities. In practice, every team we audit has a list that's either out of date or doesn't exist.
The processors that get forgotten:
- Email providers (every mailing tool processes recipient data).
- Analytics tools that survived a "quick proof of concept."
- The contact form provider.
- Customer support tools (chat widgets see everything).
- Internal tools where one engineer signed up with a corporate card.
The fix is operational, not technical: a register of processors, owned by someone who reviews it quarterly, and a process for adding/removing entries. Less glamorous than a dashboard, more important.
What you can take from this
GDPR rewards the engineering discipline you should already have:
- Don't store data you don't need.
- Make access auditable end-to-end.
- Plan for deletion, not just creation.
- Track every system that touches personal data.
- Treat "would the user expect this?" as a real question.
The systems that pass GDPR audits are usually the ones with clean architecture in general. The ones that fail tend to fail in other ways too — legacy mess, undocumented integrations, opaque data flows. GDPR isn't the goal; it's the side effect of doing things properly.
If you're building or auditing a system that handles personal data and want a second pair of eyes, that's exactly what our Tech Strategy & Audits engagements look like. Tell us about it.