What every small agency needs to know about DPAs — when you need one, what to include, and how to get it signed without a lawyer.
Updated August 2026 · Reading time: 7 minutes
A Data Processing Agreement (DPA) is a legally required contract between a data controller and a data processor under Article 28 of the GDPR. If your web agency handles any personal data on behalf of clients — hosting their website, managing their email newsletter, running their analytics, storing their customer data — you are a data processor and your clients are data controllers. Without a DPA in place, both you and your client are technically in violation of the GDPR.
The short answer: because GDPR Article 28 requires it. Every controller that engages a processor must have a written contract that binds the processor to the same data protection standards the controller is subject to.
But the practical answer matters more. Enterprise clients and EU public-sector organisations will not sign with a vendor that cannot produce a DPA. It is a procurement gatekeeper — not having one disqualifies you before the conversation even starts. And without a DPA, a data breach on a client site becomes your liability, with no contractual framework to limit it.
Article 28(3) of the GDPR lists 9 specific items a DPA must cover. Without it, both controller and processor face regulatory risk — fines up to €10M or 2% of turnover for the processor.
A DPA defines who is responsible for what. Without it, a breach at your hosting provider or an employee sending customer data to the wrong email address is your liability with no limits.
Enterprise procurement teams now ask for DPAs before they ask for pricing. Having a professional DPA signals that you understand regulatory requirements — and that you can be trusted with their data.
If you do ANY of the following for clients, you need a DPA:
• Host client websites on your own servers or a reseller account
• Manage email marketing or newsletter platforms for clients
• Set up and maintain Google Analytics, Meta Pixel, or other tracking
• Process payments through a gateway you configured
• Store client customer data in any database or CRM
• Provide backup or disaster recovery services
• Have administrative access to client WordPress sites, servers, or cloud infrastructure
If you only design a website and hand over the files to the client who self-hosts, you may not need a DPA — but you are still a controller for the personal data you collect through your own business operations.
A properly drafted DPA has 9 mandatory elements under Article 28(3). For a small web agency, the following 7 clauses are the most critical to get right:
Describe the processing activities clearly: what data, for what purpose, for how long. Vague language creates ambiguity in a breach scenario.
List your technical and organisational measures: encryption, access controls, MFA, backups, employee training. Be specific — "appropriate measures" is not enough.
Name your sub-processors (hosting provider, CDN, email service) and include an authorisation mechanism. The DPA must allow the client to object to new sub-processors.
State the notification timeline — typically 24-48 hours after confirmation of a breach. Include contact details and the format of the notification.
Define what happens at the end of the contract: how and when you delete client data, certification of deletion, and any retention periods required by law.
If you use US-based services (AWS, Cloudflare, Google), specify the transfer mechanism. Standard Contractual Clauses (SCCs) are the most common for small agencies.
Grant the client the right to audit your compliance with the DPA (or accept third-party certifications as equivalent). Annual reports on security measures are standard.
Five mistakes that small agencies make with DPAs:
1. Using a generic template without customising it. A template gives you the structure, but you must fill in your actual sub-processors, actual security measures, and actual retention periods. A DPA that says "[Insert security measures here]" is not worth the PDF it is printed on.
2. Not updating the DPA when your stack changes. Every time you switch hosting providers, add a CDN, or start using a new analytics tool, your DPA becomes outdated. Schedule a quarterly review.
3. Signing the client's DPA instead of offering your own. Large clients will often present their own DPA. It will contain obligations that are reasonable for an enterprise but impossible for a 3-person agency. Always counter with your own DPA — it protects you from commitments you cannot meet.
4. Failing to maintain a Register of Processing Activities (RoPA). A RoPA is required under Article 30. It lists every processing activity you perform, the data categories involved, and the legal basis. It is the document that shows a regulator — or a client's procurement team — that you have your house in order.
5. Not having a data retention and deletion policy. GDPR Article 5(1)(e) requires that personal data be kept no longer than necessary. Without a documented retention schedule, you are holding data indefinitely — which is a violation.
Getting a DPA signed does not require a legal team. Here is the practical process:
Step 1: Draft or customise your DPA template. List your actual sub-processors, actual security measures, and contact information.
Step 2: Share it with new clients as part of your onboarding package. Present it as a sign of professionalism, not a legal burden.
Step 3: For existing clients, send a brief email: "As part of our GDPR compliance programme, we have updated our Data Processing Agreement. Please review and sign the attached document." Include a 30-day deadline.
Step 4: Store signed DPAs in a secure location (encrypted cloud storage) with client name, signing date, and expiry/review date.
Step 5: Review and update quarterly — or whenever you change your technology stack.
Our GDPR e-book includes a complete DPA template with Annex A–C, RoPA template, incident response plan, and 8 contract clauses — everything a small agency needs.
Yes. Hosting is a processing activity. Your client entrusts you with their website data, which may include customer personal data (contact forms, user accounts, e-commerce orders). As a hosting provider, you are a data processor under GDPR Article 28.
You can, but be careful. Many free templates omit required clauses or are written for specific jurisdictions. The safest approach is a template written for small EU service providers, customised with your actual sub-processors and security measures.
Without a signed DPA, you are both in violation of Article 28. Explain that the DPA protects both parties — it limits your liability and satisfies their regulatory obligations. If they still refuse, consider whether the relationship is worth the regulatory risk.
Technically yes — Article 28 applies regardless of the client's size. In practice, micro-clients (e.g. a local bakery with a 3-page brochure site) rarely ask for one. But having a standard DPA ready to send shows professionalism and protects you if something goes wrong.
A DPA is valid for the duration of the processing relationship. When the contract ends, the DPA obligations regarding data deletion and confidentiality survive. Review the DPA annually and whenever you change sub-processors or security measures.