GDPR compliance for websites and apps: the checklist

Most cookie banners in the Netherlands are not compliant. They load tracking cookies before you click "accept", or the "refuse" button is deliberately hidden behind an extra click or a gray text link. The Dutch Data Protection Authority and its European sister organizations fine this more and more often, with fines that can run into serious money. GDPR compliance is not a legal side issue you tick off with a plugin: it is structure that sits in your code and your processes.

Data minimization: ask less

The foundation of the GDPR is simple: collect only what you genuinely need, and keep it no longer than necessary. Every field you store is both an obligation and a risk. The more personal data you collect, the greater the damage when something goes wrong. A few concrete rules:

• Do not ask for a date of birth if you only want to know whether someone is an adult. A yes-no checkbox is enough.
• Do not keep data "just in case": define a retention period per type of data and delete automatically after that.
• Anonymize where you can: for statistics and analysis you often do not need data that traces back to individuals.

Collecting less data is not only compliant, it also reduces the damage of a data breach and the burden of access requests. What you do not have cannot leak and you do not have to manage. Data minimization is therefore both a legal requirement and simply good management.

Cookies and consent

This is where things go wrong most often in practice. The rule is clear: tracking and marketing cookies may only load after the user has actively given consent. Not before, and not "up front for speed". Only functional cookies that are strictly necessary for the site to work, such as a shopping cart or a logged-in session, may run without consent.

A correct cookie banner meets a few hard requirements:

• Refusing is as easy as accepting: an equivalent button, not a hidden link or a gray text you can barely see.
• No pre-ticked boxes: consent must be an active, conscious choice by the user.
• Withdrawing is always possible: a user must be able to change their choice later just as easily as giving it.
• Nothing loads up front: all tracking scripts stay off until the choice is actually made.

We build the consent logic so tracking stays technically blocked until the user agrees. Not just a banner that looks tidy, but code that actually holds back the cookies. The difference between those two is exactly where most fined sites went wrong: a pretty banner above a site that meanwhile simply tracked.

Security and data processing agreements

Securing personal data is a GDPR obligation, not an option. That means encryption in transit with HTTPS everywhere, encryption of sensitive data at rest, access control so only authorized people can reach data, and logging of that access. With every platform we build, we log who viewed personal data and when, so a possible data breach is traceable and you can meet your reporting obligation.

If you work with external parties that process data for you, think of an email provider, a hosting party, or an analytics tool, then you need a data processing agreement with each of them. Without that agreement you are fully liable for what they do with the data. Inventory all your suppliers, check which personal data they process, and arrange the paperwork. This is administrative work that is boring until it goes wrong.

EU hosting reduces risk

Transferring data to countries outside the EU is legally complicated terrain, with shifting case law about what is and is not allowed. By hosting within the EU you bypass most of that complexity in one go. We host by default on Hetzner in Germany with Cloudflare in front, so personal data stays within the EU. For customers with sensitive data, such as in healthcare or legal services, that is not a detail but a hard requirement set by their own regulators. At a platform like ClaimHandler, which works with damage cases and personal data, privacy by design from the first line of code has been the starting point.

Do not forget the rights of the data subjects either, because they are invoked more and more often. People have the right to view, correct, and delete their data, and you must be able to respond within a month. If your data sits scattered across five systems without an overview, such a request becomes a nightmare and you run the risk of missing the deadline. So build in from the start that you can look up per person which data you hold and export or delete it in one action. That is not only compliant, it saves you a lot of manual work later.

A short practical checklist to start with: set up a data register of what you collect, record retention periods, make your cookie banner technically correct, collect data processing agreements with all your suppliers, and set up a process for access and deletion requests so you can respond within the legal deadline. Want your site or app reviewed? Take a look at our compliance service. We build privacy in from the foundation instead of sticking it on afterward, because the latter is always more expensive and weaker.