Web designers occupy a unique and often underappreciated position in the GDPR landscape. You are not just building websites — you are building the infrastructure through which your clients collect, process, and store personal data about thousands of people. That puts responsibilities squarely on your shoulders, whether you are a freelancer working from a spare bedroom or a 20-person agency handling enterprise clients.
This guide covers everything web designers need to know about GDPR: your legal status as a data processor, your obligations around cookie banners and contact forms, your responsibility for the third-party tools you install, and how to protect yourself legally when handing off a completed project.
Are You a Data Controller or a Data Processor?
This is the first question every web designer needs to answer — and the answer determines your entire compliance framework.
Data controllers decide why and how personal data is processed. Your client — the business that owns the website — is typically the data controller. They decide to run a newsletter, collect enquiry forms, and install analytics.
Data processors process personal data on behalf of a controller. As a web designer or agency, you are almost certainly a data processor. When you build a contact form that stores submissions in a database, access a client's CMS to update content, or install third-party tracking tools on their site, you are processing personal data on their behalf.
The critical implication: under GDPR Article 28, every controller must have a written Data Processing Agreement (DPA) with every processor they use. If you are processing personal data for clients — and you almost certainly are — you need a DPA in place. This is not optional.
A DPA must specify: what data you process, for what purpose, for how long, what security measures you apply, whether you use sub-processors, and your obligations around data breaches. If you do not have a DPA template, create one now and include it in your standard client contracts.
GDPR-Compliant Contact Forms
Contact forms are one of the most common sources of GDPR non-compliance on websites. Getting them right is straightforward once you understand the rules.
- No pre-ticked boxes. GDPR requires consent to be freely given, specific, informed, and unambiguous. A checkbox that is pre-ticked does not meet this standard.
- State the purpose clearly. Users must know exactly what they are consenting to before they submit their data.
- Separate consent for different purposes. A single blanket consent checkbox cannot cover both "we will respond to your enquiry" and "we will add you to our newsletter."
- Only collect what you need. GDPR's data minimisation principle means your contact form should only request fields that are strictly necessary.
- Store data securely. Ensure storage is secure, access is restricted, and your client has a data retention policy.
Cookie Consent Banners: What the Law Actually Requires
Under GDPR and the UK's PECR, non-essential cookies require prior, informed consent before they are set. This means:
- The cookie banner must appear before any non-essential cookies are loaded
- Users must be able to reject cookies as easily as they can accept them
- There must be no pre-ticked boxes or consent assumed by scrolling or browsing
- Users must be able to withdraw consent at any time
- The banner must not use dark patterns that make rejection difficult
Google Analytics, Facebook Pixel, HubSpot tracking, Hotjar, and any other marketing or analytics tool cannot load until the user actively accepts. Clients who insist on loading everything regardless are asking you to build a non-compliant website. Document your advice in writing.
Installing Tracking Pixels: Where Responsibility Lies
Web designers routinely install Google Analytics, Facebook Pixel, Google Ads conversion tracking, LinkedIn Insight Tag, and similar tools. Every one of these involves transferring personal data to third parties.
- Your client is the controller. They bear primary responsibility for ensuring lawful processing.
- You are the processor who enables it. By installing the pixel or script tag, you physically implement the data collection.
- Best practice: When scoping a project that includes analytics or tracking tools, explicitly include cookie consent management as a line item. Treat it as non-negotiable infrastructure.
Privacy Policy Pages: Who Is Responsible?
The legal answer is clear: the data controller (your client) is responsible for their privacy policy. As a web designer, you are building the page that displays it. However, you have professional obligations:
- If you know the privacy policy is inaccurate or missing required disclosures, advise the client in writing
- If your client asks you to generate a privacy policy, make clear that a generic template may not be adequate
- Include privacy policy creation as part of your project scope, with a clear statement that the client is responsible for its accuracy
Hosting Providers and CDNs
The choice of hosting provider is a GDPR consideration. When you recommend or select a host for a client:
- The host is a sub-processor of your client's data
- Your client needs a DPA with their hosting provider
- If the host is based outside the EEA, data transfer rules apply
AWS, Google Cloud, and Azure all offer GDPR-compliant hosting with DPAs. CDNs like Cloudflare and Fastly similarly process request data — DPAs are available but must be in place.
Client CRM Integrations as Sub-Processors
When you integrate HubSpot, Mailchimp, ActiveCampaign, or any other CRM into a client's website, you are connecting their data flows to a sub-processor. GDPR requires:
- The controller (your client) to have a DPA with the CRM provider
- The CRM provider to be listed in the privacy policy as a third party receiving personal data
- Data transfer safeguards to be in place if the CRM is US-based
Part of your handover package should include a list of every third-party service integrated into the site.
Privacy by Design
GDPR Article 25 codifies Privacy by Design and Privacy by Default as legal requirements. For web designers, this means:
- Default settings should be the most privacy-protective options
- Privacy protections should be built in from the start of a project, not bolted on at the end
- Technical measures — HTTPS, secure form handling, access controls — should be standard, not optional
Handing Over Website Data at Contract End
When a client relationship ends, you have GDPR obligations as a data processor:
- Return or delete personal data processed on behalf of the client when the contract ends
- Provide the client with all data stored in systems you control
- Confirm in writing when deletion has been completed
Freelance Web Designers vs. Agencies
The obligations are the same in principle, but the practical differences matter.
Freelancers need a DPA in their standard contract, professional indemnity insurance covering data breaches, and ICO registration (in the UK).
Agencies process data at greater scale and need a comprehensive data processing register, formal sub-processor agreements, and staff training.
Both should conduct a simple data mapping exercise: list every piece of personal data you touch, where it comes from, where it goes, how long you keep it, and what legal basis applies.
Scan Your Clients' Websites for Free
GDPR compliance for web designers starts with knowing exactly what a website is doing with personal data. Before handing over a completed project, run it through Custodia's free website scanner to identify trackers, cookie issues, and missing consent mechanisms in 60 seconds.
Building GDPR compliance into your standard workflow protects your clients, protects your business, and differentiates you from designers who treat privacy as an afterthought.
Top comments (0)