Data protection on your website: cookies, forms, legal notice

This article explains the basics and technical connections from a web design point of view. It is not legal advice and does not replace a review by a lawyer who specialises in data protection, by a data protection officer or by the supervisory authority of your federal state. The legal position, case law and interpretation change. What applies to your business depends on your industry, legal form, the services you use and your target group.

This is how we see our role: we build sites in such a way that as little personal data as possible arises, we document the technical facts in plain language, and we work with your legal adviser when it comes to judgements and wording.

In Germany, access to information on a visitor’s end device (cookies, local storage, fingerprinting techniques) is governed by the Telecommunications Digital Services Data Protection Act (TDDDG). As a rule it requires consent, unless the storage or access is strictly necessary to provide the service that the visitor has expressly requested. The GDPR rules also apply to the subsequent processing of personal data.

1. Does your site store or read anything on the visitor’s device? No: no prompt is needed under the TDDDG. Yes: go on.
2. Is it strictly necessary for the requested function to work (shopping basket, login, security, storing the cookie choice)? Yes: consent is not needed, but name it in the privacy policy. No: go on.
3. Does it serve analytics, convenience beyond what is necessary, marketing or third-party embeds? Then consent is generally required. Check whether you can do without the service.
4. If consent is needed: the service may only load after active agreement. Declining must be just as easy as agreeing. The decision can be withdrawn at any time, and the site works even if the visitor declines.

Typical mistakes with the banner

• The “Accept all” button is large, while “Decline” is a small piece of text in a corner.
• Services already load before the visitor has decided.
• Pre-ticked boxes for analytics and marketing.
• Declining makes the site unusable.
• The visitor’s choice is not saved, and the banner reappears on every visit.

In practice this means: anyone who does without services that require consent often needs no banner at all, and the site becomes faster and calmer as a result. The guide Cookie banners and data protection goes with this.

The form is the most common place where visitors knowingly hand over data. It is worth designing it carefully, because it builds trust and reduces risk.

• Only necessary fields. A name and a way to reply are often enough. Every further field needs a purpose.
• Encrypted transmission. The site is delivered exclusively over HTTPS.
• A notice in plain sight. Next to the submit button there is a short sentence on what the data is used for, and a link to the privacy policy.
• No pre-ticked consents. Further purposes such as a newsletter need their own voluntary consent.
• Spam protection without a third-party service. A hidden extra field (honeypot), a timing check, server-side limits. Services from large providers raise data protection questions.
• Secure delivery. The message reaches your mail server over an encrypted connection, and the sender details are configured correctly so that it does not end up in the spam folder.
• Storage and deletion. Decide how long enquiries are kept, and delete them afterwards.

For practical tips on the design itself, see the guide Designing a contact form properly.

The privacy policy informs visitors about what data you process and why. It must be understandable and match the site. A common outline:

1. Controller (name, address, contact) and, where applicable, data protection officer.
2. Hosting and server logs: what data arises, how long is it stored, which service provider runs the server?
3. Cookies and similar technologies: which are set, for what purpose, with what lifetime, on what basis?
4. Contact by form or email: purpose, legal basis, retention period.
5. Services used: analytics, maps, fonts, videos, newsletters, payment services, each with the provider, purpose and data transfer.
6. Disclosure to third parties and transfer to third countries, where applicable.
7. Data subjects’ rights: access, rectification, erasure, restriction, objection, data portability, complaint to the supervisory authority.
8. A note on changes and the date of the policy.

Common mistakes

• The policy describes services that are not (or no longer) in use, and says nothing about others that are running.
• Texts taken from templates meant for another legal form or industry.
• Outdated references to former legal bases or discontinued procedures.
• Wording that is too general (“we use cookies”) with no purpose or duration given.
• The policy is not updated after changes to the site.

A simple measure: after every technical change, go through the list of embedded services and check it against the policy. We are happy to show you the tools for this (for example a list of all loaded resources in the developer tools).

Visitors and customers have rights: they can ask for information about what data you have stored about them, and for rectification, erasure and objection. A request must in principle be answered without undue delay, and under the GDPR as a rule within one month. For that you need a procedure, which can be simple in small businesses:

1. Who receives requests (the address in the privacy policy)?
2. How do you verify the identity of the person asking, without collecting more data yourself?
3. Where is personal data held (email program, customer list, accounting, form archive, backups)?
4. Which data do you have to keep because of statutory retention periods, and which may or must be deleted?
5. Who replies and documents it?

Also set deletion periods for enquiries that did not lead to an order, for example a fixed period after the enquiry is closed. The length depends on purpose and legal position and belongs in a discussion with your legal adviser. Backups contain old data: there needs to be a rule for those too, saying when they are overwritten.

As soon as a service provider processes personal data on your behalf, you generally need a data processing agreement. On a website this typically concerns the hosting provider, email provider, newsletter service, maintenance providers with access to data, and appointment booking and payment services.

What you should check: does the agreement exist, and is it signed or accepted online? Does it state the purpose, type of data, duration, technical and organisational measures and the sub-processors? Where is data processed, and is it transferred to countries outside the European Economic Area? What happens to the data when the contract ends?

What you should document: a list of all service providers with the purpose, status of the contract and a contact person. It helps with enquiries from visitors and the supervisory authority and with your own overview. Depending on the business, a record of processing activities is also mandatory or strongly recommended.

Your web designer is a service provider too. If they have access to form data, customer lists or backups, they belong on the list. We put this in writing before we are given access, and limit it to what is necessary.