Articles · GDPR

2027-04-10 11 min EN / FR

GDPR for freelancers and small agencies: the register and the data processing agreement

If you build or maintain systems for clients, you handle personal data, even if you never open a customer table. A shop's order database, a CRM export, a support mailbox, a log file with IP addresses: all of it is personal data. That makes the GDPR relevant to you, usually in the role of processor.

Two documents come up constantly: the processing register and the data processing agreement (DPA). Both are simpler than their reputation suggests.

This is practical guidance, not legal advice. For your own situation, check the CNIL's guidance or ask a lawyer.

Controller or processor?

  • Controller: decides why and how personal data is processed. Your client, for their customers' data.
  • Processor: processes data on the controller's behalf and on their instructions. You, when you host, maintain or operate their systems.

You are a controller for your own data: your clients' contact details, your invoices, your website visitors.

You can become a controller by accident if you start using client data for your own purposes (reusing a customer list, testing a tool on production data, training a model on it). Don't.

The register of processing activities

The GDPR requires a written register of processing activities. There is an exemption for organisations under 250 people, but it does not apply if the processing is more than occasional, likely to create a risk, or involves sensitive data. In practice, almost every business with customers or staff handles data regularly, so assume you need one. It is also the best tool for knowing what you hold.

As a controller (your own business)

For each processing activity (client management, invoicing, website analytics, recruitment, newsletter), record:

  • Purpose
  • Categories of people and data
  • Recipients (your accountant, hosting provider, email tool)
  • Transfers outside the EU, and the safeguards used
  • Retention period
  • Security measures, in general terms
  • Legal basis (contract, legal obligation, legitimate interest, consent)

As a processor (for your clients)

A processor keeps a lighter register of what it does for each client:

  • Name and contact of each controller you work for
  • Categories of processing carried out (hosting, maintenance, support, backups)
  • Transfers outside the EU, if any
  • General description of security measures

A spreadsheet is enough. The CNIL publishes register templates you can adapt. The important thing is that it exists, is accurate and is updated when something changes.

The data processing agreement

When a controller uses a processor, the GDPR requires a written contract covering the processing. It can be a standalone document or a section of your service contract. It must state:

  • Subject, duration, nature and purpose of the processing
  • Type of personal data and categories of people concerned
  • That you act only on the controller's documented instructions, including for transfers outside the EU
  • Confidentiality: everyone authorised to process the data is bound by confidentiality
  • Security measures appropriate to the risk
  • Sub-processors: you only engage another processor with the controller's authorisation (specific or general with a chance to object), and you pass the same obligations on to them
  • Assistance: you help the controller respond to people exercising their rights, and with security, breach notification and impact assessments
  • Breach notification: you tell the controller without undue delay (the controller's own deadline towards the authority is 72 hours, so your delay should be short, and many contracts specify hours)
  • End of contract: you delete or return the data, at the controller's choice, unless the law requires storage
  • Audits: you provide the information needed to show compliance and allow audits

Practical clauses worth adding

  • The exact list of sub-processors (hosting provider, backup storage, monitoring, email sending, AI tools) and where they process data
  • A deletion procedure with a deadline, and written confirmation
  • Rules for production data in test environments
  • A description of who has access and how access is granted and removed (see the offboarding checklist)
  • Handling of local copies on your laptop (none by default)

Need a readable DPA and register?

We help freelancers and small agencies draft a processing register, a one-page DPA and a sub-processor list that match how you actually work.

Talk about your setup Custom solutions

Your sub-processors

Every tool that touches client data is potentially a sub-processor of yours: your error tracking service, a log platform, a cloud backup, a ticketing tool, an AI assistant that sees code or data.

For each one:

  • Is client personal data actually sent to it? If you can avoid it (scrubbing logs, masking data), do.
  • Is there a DPA with this provider? Most major providers publish one.
  • Where is data processed? If it leaves the EU, what safeguard applies (an adequacy decision, standard contractual clauses)? These mechanisms have changed over the years, so check the current status.
  • Is your client informed and, where required, has it authorised the provider?

Keep a list. Clients increasingly ask for it in their security questionnaires.

Security measures you can state honestly

Don't copy a long list of measures you don't apply. A short, true list is better:

  • Access limited to named people, with strong authentication
  • Credentials in a password manager or vault, never shared in chat
  • Encrypted disks on work devices
  • Encrypted connections to client systems
  • Separate accounts per client, accounts in the client's name wherever possible (see the 30-minute account ownership audit)
  • Backups encrypted and restore-tested
  • No client production data on personal devices or test environments without a written reason
  • Prompt updates of the tools you use
  • Offboarding of access at the end of each engagement

Overpromising in a contract is a liability. State what you really do.

When something goes wrong

If you discover that client data was exposed (a leaked key, a misconfigured storage bucket, a stolen laptop):

  • Contain it: revoke access, rotate keys, isolate the system.
  • Tell the client quickly, in writing, with what you know and what you don't yet. They are the controller and decide on notification to the authority.
  • Collect facts: what data, how many people, since when, what logs exist.
  • Help the client with their notification, since their 72-hour clock starts when they become aware.
  • Document the incident and what you changed afterwards.

Keep a simple incident template ready before you need it.

Using AI tools with client data

This is where many small providers are exposed. Before pasting client data, logs or code into an AI tool:

  • Check whether the plan retains your inputs or uses them for training
  • Check where the data is processed
  • Check what your DPA and contract allow
  • Remove personal data you don't need, and never include secrets
  • Tell clients how you use such tools if their data could be involved (see also adding AI without handing over the keys)

If you can't answer these questions, don't send the data.

What clients will appreciate

  • A one-page DPA that is readable and complete
  • A sub-processor list they can read in a minute
  • A clear incident procedure
  • A deletion confirmation at the end of the engagement
  • Honesty about what you do and don't do

For a small provider, this is a competitive advantage. Many agencies can't produce any of these documents.

Common mistakes

  • Believing that "we only do the technical part" means you aren't covered
  • No written agreement with clients who give you access to personal data
  • Copying a production database to a laptop "just this once"
  • No list of sub-processors
  • Contract security promises that don't match reality
  • Keeping client data after the engagement ends
  • Using client data to test a personal side project or tool
  • No incident procedure
  • Treating the register as a one-time exercise

Checklist

  • Role clarified for each engagement (controller or processor)
  • Own register completed and dated
  • Processor register by client
  • DPA signed for each client with access to personal data
  • Sub-processor list with locations and safeguards
  • Security measures described truthfully
  • Rules for test data and local copies (see GDPR and test environments)
  • Incident procedure written, with client contacts
  • AI tool usage checked against contracts
  • Deletion procedure and confirmation at end of engagement
  • Register and list reviewed at least once a year

Related

From vague promises to documents you can send

If clients ask for a DPA, a sub-processor list or an incident procedure and you want versions that match your real practice, write us.

Start a conversation All articles