Guide
Web design and data protection: what GDPR requires
As soon as personal data is processed in web design, clear obligations apply. What these are specifically, what's almost always missing in practice, and what actually suffices.
As soon as personal data is processed in web design, you need a legal basis, purpose limitation, defined deletion periods, information for data subjects, and a data processing agreement with every involved service provider. In practice, the same three points are almost always missing: the deletion period, the notice at the point of collection, and clarification of whether the provider uses the data for its own training.
01 — Data Protection
What GDPR requires
As soon as personal data is processed — and that happens faster than expected, for instance as soon as someone enters a name or phone number — the usual obligations apply: name the legal basis, define the purpose, maintain data minimization, define retention periods, inform data subjects.
Practically, this means for web design: a data processing agreement with every involved service provider, checking where processing takes place, a documented deletion period, and an understandable section in the privacy policy. Three things are almost always missing in practice: the defined deletion period, the notice at the point where data is collected, and clarification of whether the provider uses the data for its own training.
A data protection impact assessment is only required when there's likely high risk — not for most projects of this type. The review itself should still be documented so that if questions arise, it's clear why it was omitted.
02 — Contract
What needs to be clarified in writing
- Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
- Handover upon termination. In what format, within what timeframe, at what cost.
- No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
- What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
- Documentation as a deliverable. Not as a promise, but as a line item in the proposal.
03 — Risks
What can go wrong
- The system answers incorrectly. Containable by having it work exclusively from verified content and escalate when uncertain rather than guess. This is a configuration decision, not a property of the technology.
- The effort is underestimated. Most common reason: unclear starting situation. An honest assessment of the current state before the proposal prevents this more reliably than any buffer.
- No one maintains it. The biggest risk of all — and the most easily avoidable.
- Data protection gaps. Almost always arise from missing deletion deadlines and unclear responsibility, rarely from the technology itself.
- Vendor lock-in. Avoidable if access credentials, data, and documentation contractually remain with the client.
04 — Questions
Frequently asked questions
What if we don't like any of the directions?
Then we go back to the discovery phase — usually that means something important about the business hasn't been understood yet. It rarely happens, but better to start fresh than to force a design.
Do we even need custom design?
Not necessarily. If you need a site with five pages and no brand ambitions, a well-adapted standard system is the more sensible choice. Custom design pays off when you need to stand out from competitors or manage many pages.
Do we get several drafts?
Two to three directions on one page type. Ten variations help no one — they just shift the decision to the client instead of making it.
How many revision rounds are included?
Two rounds per draft are standard and usually sufficient, because the directional decision is made after the first presentation. Additional rounds are possible but noticeably extend the timeline.
Will this look good on mobile too?
We design the narrow view first, because that's where the majority of visitors arrive. The wide view is the easier case, not the other way around.
Do you also provide image material?
No, that's not part of the design system. But we specify exactly what kind of images are needed and recommend suitable sources or a photographer if required.
What about accessibility in design?
We check contrast, font sizes, focus presentation, and click areas against WCAG 2.1 AA. That's significantly cheaper in design than later in implementation.
Next step
Send us a few sentences about your project.
We read every inquiry ourselves and respond personally. No sales team, no callback form into the void.