GDPR for Freelance Developers: You're More Liable Than You Think

Processor vs Controller: Where You Sit

The client is usually the data controller — they determine why personal data is processed. You, as the developer, are typically a data processor — you handle personal data on the controller's behalf.

But here's the nuance. If you have ongoing access to the production database (for maintenance, debugging, deployments), you're actively processing personal data. If your development environment contains real customer data, you're processing it. If you can read, copy, or delete user records as part of your work, that's data processing.

As a processor, GDPR Article 82 makes you directly liable for damages caused by processing that "does not comply with this Regulation" — specifically where you haven't complied with obligations placed directly on processors, or where you've acted outside the controller's lawful instructions. You can be fined by a supervisory authority independently of your client.

The DPA You Need With Every Client

Article 28 requires a written contract between controller and processor covering specific terms. If you're building or maintaining a site that handles EU personal data, you need a Data Processing Agreement with your client.

Most freelancers don't have this. Their engagement letter or contract says nothing about GDPR obligations. That's a problem for both parties — but particularly for you if something goes wrong.

Your standard contract should include at minimum: that you'll only process data on the client's documented instructions, that you'll maintain appropriate security measures, that you'll assist the client in fulfilling data subject rights, that you'll notify them of any breach without undue delay, and that you'll delete or return data at the end of the engagement.

What Client Agreements Should Include

Beyond the DPA, your freelance contracts should protect you in other ways. Include a clause that the client is responsible for providing compliant requirements — if they ask you to build a feature that creates a compliance problem (like a pre-ticked consent box), you've flagged the issue in writing and they've overridden your advice.

Add a representation that you'll implement GDPR-compliant patterns as standard practice, and that any deviation from those patterns requested by the client shifts liability to them. This matters if you later get dragged into an enforcement action — documentation that you flagged the risk and were overruled is significantly better than no documentation.

Liability if You Build Something Non-Compliant

The bad news: if you're a processor and you build something that causes a data breach due to negligence — inadequate security, exposed endpoints, unencrypted data at rest — you're jointly and severally liable with the controller. The affected individual can sue either of you, or both.

The good news: Article 82(3) says you can escape liability if you prove you're "not in any way responsible for the event giving rise to the damage." If the client overrode your security recommendations and caused the breach, you have a defence. If you just wrote insecure code, you don't.

When Clients Refuse Compliance Work

This happens more than it should. Client wants the site live without the cookie consent implementation you quoted for. Client wants to skip the privacy policy because "it's just a brochure site." Client wants to use real user data in the development environment because it's easier. Running a GDPR audit before delivery is a good way to document what you checked and what the client declined.

Your options, in order of preference: (1) decline the work that creates the compliance problem, (2) include the compliance work as non-optional scope, (3) document in writing that you've flagged the risk and they've refused to address it, then decide whether to continue the engagement.

What you shouldn't do: proceed with work that you know creates a GDPR violation without documenting your objection. "The client said it was fine" is not a GDPR defence.