Do You Need a Data Processing Agreement (DPA)? A Guide for Freelancers

Practical guide · GDPR Art. 28 · for developers, marketers, VAs, and agencies who handle a client's data

If you're a freelance developer, marketer, virtual assistant, or agency and you ever touch a client's customer data — their email list, their site's database, their support inbox — you're not just a freelancer to GDPR. You're a processor, and Article 28 requires a written contract between you and your client before that processing starts. Most freelancers skip this because it feels like paperwork for big companies. It isn't — the obligation applies at any scale, and it's one of the more commonly overlooked compliance gaps in freelance work.

Are you actually a "processor"? A quick test

You're a processor (not just a controller of your own business data) whenever you handle personal data on someone else's behalf, under their instructions, for their purposes — not yours. Common freelancer/agency situations:

• You're a developer with database or admin access to a client's site, where customer records live.
• You're a marketer running email campaigns through a client's mailing list.
• You're a VA handling a client's customer support inbox or CRM.
• You're a bookkeeper or accountant with access to a client's customer/invoice records.
• You host, back up, or migrate data for a client as part of a technical engagement.

If none of that applies — you only ever see your own client's contact details, for your own invoicing — you're a controller of your own data, not a processor of theirs, and a DPA isn't triggered by that relationship (though you still need your own privacy policy — see our privacy policy checklist).

What Article 28(3) requires the DPA to actually contain

A one-line "we comply with GDPR" clause in your services contract is not a valid DPA. Art. 28(3) lists mandatory content — a compliant DPA must set out, in writing:

• Subject matter and duration of the processing.
• Nature and purpose of the processing — what you're actually doing with the data.
• Categories of data subjects and personal data involved (customers, employees, etc.; names, emails, payment info, etc.).
• The Controller's rights and obligations, and confirmation you process only on their documented instructions.
• A confidentiality commitment from anyone on your side who touches the data.
• Security measures under Art. 32 (encryption, access controls, backups — whatever's actually appropriate to the processing).
• Sub-processor rules — you need the client's prior authorisation (general or specific) before using any sub-processor (e.g. your own hosting provider), and you stay liable for their performance.
• Assistance obligations — helping the client respond to data subject rights requests and meet their own breach-notification duties.
• A breach-notification duty from you to the client, without undue delay.
• End-of-contract data handling — delete or return all data when the engagement ends, unless law requires you to keep it.
• Audit rights — the client (or their auditor) can verify your compliance.

Who signs it, and in which direction?

The same template works both ways — only the labels change:

• If you hire a supplier who processes data for you (an email platform, a hosting provider, another freelancer with database access), you're the Controller and they sign as Processor.
• If a client hires you and you touch their customer data, you're the Processor and they sign as Controller.

Many freelancers need both directions at once: Processor to their clients, Controller to their own sub-processors (their hosting company, their email tool) — each relationship needs its own signed DPA.

Quick self-audit

1. List every client whose customer/personal data you can currently access.
2. For each one, is there a signed, written DPA — not just a mention in the main contract?
3. Does it name your own sub-processors (hosting, email, etc.) and how you got authorisation to use them?
4. Does it state a breach-notification timeframe you'd actually meet?
5. Do you know what "delete or return" means in practice for each client's data once an engagement ends?

If you answered "no" or "not sure" for any client with real data access, that's a gap worth closing before it becomes a client's audit question or a regulator's.

Not legal advice. This guide is general information, not a substitute for advice from a qualified lawyer or data protection professional about your specific situation. NormaKit's templates are likewise informational starting points, not legal advice, and should be reviewed and adapted before use.