Building a GDPR-Proof Website in the Netherlands
Most small companies treat GDPR β the AVG in Dutch β as a privacy statement you copy from somewhere and a cookie banner you install. That combination is exactly what fails an inspection, because neither of them is where the obligations actually live.
Here is what a small business website really needs, and what the Autoriteit Persoonsgegevens actually looks at.
The idea in one paragraph
You may only collect personal data you have a lawful reason to collect, you must tell people what you are doing with it, you may only keep it as long as you need it, and you must be able to hand it over or delete it when asked. Everything else is detail. If you can answer "what do we collect, why, where does it go, and how long do we keep it" for every form and every script on your site, you are most of the way there.
What counts as personal data
Wider than people expect. Obviously names, email addresses and phone numbers. Also IP addresses, cookie identifiers, device fingerprints, and anything that can single somebody out even without a name. That last part is why analytics and advertising scripts are in scope at all.
The five things that are usually wrong
1. Analytics loading before consent. This is the most common failure by a wide margin. Google Analytics and similar tools set identifiers and send data to a third party. In the Netherlands, non-essential cookies and similar techniques need consent under the Telecommunicatiewet before they run. A script in the page head that fires on load has already acted before anyone clicked anything.
There are two clean fixes. Either load analytics only after consent, or switch to a privacy-friendly, cookieless analytics tool that does not identify individuals β several are designed specifically so that no consent is required. The second option often gives cleaner numbers anyway, because you are no longer only measuring the people who clicked accept.
2. A cookie banner with no real refusal. Refusing must be as easy as accepting. A banner with a big "Accept all" and a grey "Manage settings" that takes three clicks to refuse is not valid consent, and the Dutch DPA has been explicit about this. Accept and Reject should sit side by side, look equally prominent, and take one click each.
3. Contact forms that collect more than they need. Every field is data you now have to justify, secure and delete. If you do not need a phone number to answer an enquiry, do not ask for one. Ask what the enquiry needs and nothing more β this is data minimisation, and it is also a conversion improvement, so it is the rare requirement that pays for itself.
4. No processor agreements. If a supplier handles personal data on your behalf β your hosting company, your email marketing tool, your CRM, your form service β you need a data processing agreement with them. Most serious suppliers publish one you can accept online; the work is knowing who your processors are. Make the list.
5. A privacy statement that describes someone else's website. Copied statements mention data you do not collect and omit what you do. It must describe your actual processing: what you collect, why, the lawful basis, who you share it with, how long you keep it, where it is stored, and how someone exercises their rights. It also needs a real contact route for those requests.
What is different in the Netherlands
The GDPR is European, but a few things are specifically Dutch.
The supervisory authority is the Autoriteit Persoonsgegevens. It publishes its focus areas and it does act on complaints. It has been notably active on cookie banners, and its usual first step is a warning with a period to fix things rather than an immediate fine β companies that respond with a plan generally resolve it.
Cookies specifically fall under the Telecommunicatiewet, not only the AVG. That is the source of the consent-before-placement rule.
There is also a data breach notification duty: a reportable breach goes to the AP without undue delay and generally within 72 hours. That is a short window if you have never thought about who would make that call, so decide now who is responsible.
And do not confuse this with the KVK number and other commercial details you must publish β those come from different rules, and are covered separately.
Since June 2025, one more thing
Your cookie banner now also falls under the European Accessibility Act. It has to be operable by keyboard, announced properly to a screen reader, and it must not trap focus. Many banners fail all three, including plenty sold as compliance products. A banner that is legally correct on consent and inaccessible in practice has traded one problem for another.
A practical checklist
Work through this in an afternoon:
- Open your site in a fresh private window, refuse everything, and look at the network tab. If anything is still talking to a third party, that is your first job.
- Count the fields on every form. Remove any you do not act on.
- List every third party that touches your data. Check you have an agreement with each.
- Read your privacy statement as if you were a customer. Does it describe your business?
- Check the retention question: how long do form submissions stay in your inbox? "Forever" is an answer, and not a good one.
- Test the cookie banner with a keyboard only.
What this costs
Very little, if you do it while building. Consent-gated scripts, a form that asks for less, a real privacy statement and a signed agreement with each processor is maybe a day of work on a normal small business site.
The expensive version is discovering all of it after a complaint, when you are fixing things under a deadline and answering questions at the same time. That is the same pattern as accessibility, and the same advice applies: an hour spent checking now is worth a week spent later.
This is a practical guide, not legal advice. For your own obligations, talk to a privacy lawyer or check the guidance the Autoriteit Persoonsgegevens publishes.
Keep reading
Need help with your project?
Get direct, personal advice on your project β response within 24 hours, in English, Dutch or Spanish