Putting Data Protection into Practice on a Website
How GDPR requirements translate into concrete website decisions, from the right legal basis through data minimisation to local fonts and secure contact forms.
Data Protection Starts Before the First Line of Code
On a website, data protection is not a layer of banners and texts added at the end, it is a question of architecture. Anyone who only considers which data arises after launch is sticking plasters over decisions that were made long ago. The General Data Protection Regulation names this principle explicitly in Art. 25, once as data protection by design and once as data protection by default.
In practice this means checking every technical decision against one question, does it bring third-party data into play. An embedded map, a video embed, a font service, an analytics script. Each of these building blocks can send an IP address to an external server, often to locations outside the European Union. The clean order is to understand the data flow first, then choose the building block.
The most data-frugal option is almost always the fastest and the easiest to maintain.
The Six Legal Bases in Art. 6 GDPR
Every processing of personal data needs a legal basis. Art. 6(1) GDPR lists exactly six, and for a website three of them matter most. The overview below sorts them.
| Letter | Legal basis | Typical website case |
|---|---|---|
| (a) | Consent | analytics tracking, newsletter sign-up, external embeds |
| (b) | Performance of a contract | customer account, order handling, login area |
| (c) | Legal obligation | retention of invoice data |
| (d) | Vital interests | practically irrelevant for websites |
| (e) | Public task | only for public authorities |
| (f) | Legitimate interest | server logs to fend off attacks, fraud prevention |
The most common mistake is confusing (a) and (f). Legitimate interest sounds convenient because it works without consent, yet it only holds when a balancing of interests falls in favour of the controller and the operation stays foreseeable for the person concerned. Reach measurement with cookies or device recognition does not fall under it, it requires active consent.
Consent That Deserves the Name
Consent under the GDPR is tied to clear conditions. It must be freely given, specific to the purpose, informed, and expressed unambiguously. Pre-ticked boxes are invalid, which the Court of Justice of the European Union confirmed in the Planet49 ruling in 2019. A banner that hides the rejection behind several clicks while the acceptance sits in one large button is equally inadmissible.
Three hard requirements follow for practice.
- Rejecting has to be just as easy on the first level as accepting.
- Scripts that require consent may only load after the consent, not before.
- Withdrawal has to be possible at any time and as simple as giving consent.
The last condition is often overlooked. When a banner collects consent in two seconds but the withdrawal lies buried deep in the privacy policy, the consent is open to challenge. A permanently reachable toggle that visibly revokes the chosen status is the cleaner approach.
Data Minimisation as the Default
Art. 5(1)(c) GDPR requires data to be limited to what is necessary for the purpose. This principle of data minimisation is the most effective and at the same time the cheapest data protection measure, because data that is never collected needs neither storage, nor protection, nor deletion.
A contact form shows this well. What is necessary is a reply address and the message itself. Phone number, salutation, company name, or postal address are optional in most cases and should stay that way. Every mandatory field that is not strictly needed is a data protection risk without any return. An honest deletion period belongs here too. Enquiries that have been dealt with should be deleted after a reasonable time, not kept forever.
Local Fonts Instead of External Font Services
Fonts are probably the best-known stumbling block. A regional court in Munich ruled in 2022 that dynamically loading Google Fonts from their servers without consent breaches the GDPR, because it transmits visitors' IP addresses to the United States. Regardless of how far that single ruling reaches, the technical lesson is clear.
The robust solution is to embed fonts locally. The files sit on the site's own server and are served from there, without a foreign domain coming into play. This not only resolves the legal question, it also improves load time, because an additional connection to a third-party server is removed. Modern frameworks bring their own mechanisms for this, embedding the font files during the build and shipping them alongside the page.
The same pattern applies to maps, videos, and embedded content. Where an embed is unavoidable, a two-click solution helps, where the external content only loads after active consent. Until then the person sees only a local placeholder, and no data flows.
Handling Processors Properly
As soon as an external service provider processes personal data on behalf of the controller, Art. 28 GDPR applies. This affects almost every website, because even the host stores visitors' IP addresses in its server logs. Newsletter tools, external form providers, error monitoring, or a content delivery network fall under it too.
Each of these services needs a data processing agreement. It defines what the provider may do with the data and which technical and organisational measures it upholds. If the provider sits outside the EU or the European Economic Area, a second check is added, namely the search for a valid basis for the third-country transfer, such as standard contractual clauses or an adequacy decision. The sober consequence is to keep the number of integrated services small. Every provider fewer is one agreement fewer, one risk fewer, and one data flow fewer.
Secure Contact Forms
A form collects personal data and is therefore a sensitive point. It can be secured technically and organisationally with manageable effort.
Encryption via HTTPS is the foundation, so that entries cannot be read on their way to the server. A reference to the privacy policy right next to the form creates the transparency required by Art. 13 GDPR, without an enforced consent requirement turning into a hurdle. A data-frugal spam protection helps against automated abuse. A server-side honeypot field or a simple arithmetic task work without any external script and without profiling, unlike some widespread captcha services that themselves send data to third parties.
Handling the message after submission matters just as much. An encrypted transfer to the mailbox, a clearly named circle of recipients, and a defined retention period close the loop. Working cleanly here protects not only the senders' data but also the controller.
From Obligation to Stance
Data protection can be read as a burden or as a mark of quality. A website that gets by with few external services, is served locally, and only collects what it really needs is not just calmer in legal terms. It loads faster, is easier to maintain, and signals a careful handling of trust.
This is exactly where our method comes in, think further, plan further, build further, and go further. Data protection belongs in the planning phase, long before the first component exists, and it only holds when the build follows it. More on this stance is on the Mission page. Anyone who wants an existing site reviewed or wants to build data-frugally from the start finds the direct route through the Contact page.
Think data protection through from the start instead of repairing it later. We look at the current state and show the concrete levers.