GDPR for web developers — privacy built into the code

It is a widespread misconception that data protection only concerns lawyers. In reality, a large part of it is determined in code: which fields a form collects, which cookies a page sets, where data is sent, and whether a user's data can even be found and deleted again. The Data Protection Regulation (GDPR) applies as soon as a page processes information about identifiable people — and most do.

§What counts as personal data?

Personal data is any information about an identifiable person — not just the obvious like name and email. Also an IP address, a device ID, a cookie value or a combination of information that together points to a person counts. As a developer the point is to know what data a site actually collects — also what happens in the background via third-party scripts and statistics.

§Data minimization in practice

One of the strongest principles is data minimisation: collect only what you really need. It is a concrete decision every time you create a form. Do you really need birth date phone number and address to send a newsletter? Every field you remove is data you do not need to protect store safely or be able to delete again. Less collection is both more privacy-friendly and less work for you.

§Cookies and consent

Cookies and similar technologies that are not strictly necessary for the site to function generally require user consent before being set. This typically applies to analytics, marketing and tracking cookies. Strictly necessary cookies — such as one that keeps a user logged in or remembers cart contents — do not require consent. Valid consent must be voluntary, informed and an active action: pre-ticked boxes and 'continue to accept' don't count. It must be as easy to say no and withdraw consent as to say yes.

• 01Set non-essential cookies/scripts ONLY after active consent
• 02Strictly necessary cookies may be set without consent
• 03Pre-ticked boxes are not valid consent
• 04Saying no should be just as easy as saying yes
• 05The user must be able to withdraw their consent afterwards

§Build so rights can be fulfilled

Users have the right to insight, correction, deletion and to have their data handed over. These rights live or die depending on how you have built the system. Can you find all data about a specific person? Can you export it in a usable format? Can you delete it — also in log files, in backups and with third parties you have sent it to? A 'delete my account' button that actually just hides the account does not fulfil the right to deletion. Think it into the data model from the start.

§Third parties and data transfer

Modern websites often rely on external services: statistics, fonts, maps, video embedding, payment solutions. Every time you embed something external, the user's data — at minimum the IP address — can be sent to the third party. Be aware of which third parties a site talks to, whether there is a data processor agreement and where data ends up. What looks like a harmless embedding can be a data transfer that must comply with the rules.

§Safety is part of the requirement

The regulation requires an appropriate level of security — without prescribing specific figures or products because it must be adapted to risk. In practice it is the same web security practices that apply: encryption during transport secure storage of passwords access control on the server updated components and logging so a breach can be detected. A data breach — e.g. a leaked database with user information — triggers a notification requirement so the ability to detect and document it is part of compliance not just good practice.

“Privacy is not a banner text you pour in at the end. It is determined in the data model, in the form's fields and in what the page sends forward in the background.”

— Rule of thumb from web development with personal data.