GDPR Compliance for Small Web Agencies

Chapter 1 — Why This Applies to You (Yes, You)

The myth that gets agencies in trouble

The most common misconception among small agencies is some version of: "We just build websites. Our clients own the data."

Under GDPR, that's only half true. When your client asks you to build a contact form, set up analytics, or configure email marketing, you are processing personal data on their behalf. That makes you a data processor under Article 28, with direct legal obligations of your own — obligations that exist regardless of what your contract says.

Regulators have been explicit about this. Processing without a written contract that meets Article 28 requirements is itself a violation — for both parties. If your client gets audited and cannot produce a compliant contract with you, that is their violation. If you process data without the right terms in place, it is yours.

What "processing" means in practice

Almost everything an agency does touches personal data:

If you do any of these for EU-based clients (or their EU visitors), you're in scope. There is no size threshold for GDPR — unlike NIS2, a one-person shop is fully covered.

What actually happens when something goes wrong

The dramatic fines make headlines, but they are not the realistic risk for a small agency. The realistic risks, in order:

1. A client procurement review fails you. Larger clients increasingly audit vendors before signing. No DPA template? You lose the deal or sign their one-sided paper.
2. A data breach you can't document. You must notify the affected client (and often the authorities) within 72 hours of becoming aware. If you don't know where data lives or who to call, you miss the deadline.
3. A subject access request lands. A website visitor demands their data. Your client calls you in a panic because the request involves systems you built.
4. Insurance won't cover you. Professional indemnity insurers now routinely ask for documented GDPR processes.

None of these require a regulator to be involved. All of them cost real money and reputation. Compliance is cheaper than any of them.

The good news

For a small agency, GDPR is mostly documentation discipline, not technology. You almost certainly already do most of the right things technically — encrypted connections, access control, backups. What you lack is the paperwork that proves it. This guide fixes exactly that.

Chapter 2 — Your Two Roles: Controller vs Processor

GDPR assigns every organisation one of two roles in each processing activity, and the roles carry different duties. Getting this straight is the foundation for everything else.

When you're a controller

You are a controller when you decide why and how personal data is processed — i.e., it's your own business purpose. For an agency this typically means:

• Your own CRM and client records
• Your own marketing and newsletter
• Your own website's analytics and contact form
• Job applications you receive
• Freelancer and supplier records

As a controller you owe individuals the full set of duties: lawful basis, privacy notice, data subject rights handling, breach notification to authorities, records of processing.

When you're a processor

You are a processor when you handle personal data on someone else's instructions — your clients' data. Building and maintaining their sites, hosting their databases, administering their email accounts.

As a processor you owe narrower but still direct duties:

• Process only per documented instructions (the contract)
• Keep records of what you process for whom
• Secure the data appropriately
• Notify each client of a breach without undue delay (your contracts should say within 24–48 hours)
• Get authorisation before using sub-processors (e.g., your hosting provider)
• Delete or return data when the engagement ends

Why the distinction matters commercially

Two consequences worth internalising:

1. Your clients owe you DPAs. Every client for whom you touch personal data should have signed a data processing agreement with you. Most small agencies have none — meaning they've been non-compliant since day one, along with their clients.
2. You owe your sub-processors the same. Your hosting provider is your sub-processor when working on client sites; you need their DPA on file (all major providers publish theirs) and your clients need to be told roughly who they are.

One role per activity

Note that you can be both at once for the same client: controller for your invoicing data about them, processor for their website users' data. Document them separately. Chapter 4's register handles this cleanly.