GDPR for agencies: what actually applies to your briefing workflow

Personal data hides in more agency documents than most teams realise. A practical, non-legal guide to the parts of GDPR that touch briefing, research and client data.

Most agency GDPR conversations happen once, at the point of signing a client contract, and then never again. Meanwhile the briefing workflow quietly accumulates personal data: interview transcripts, customer quotes, contact lists, research recordings, influencer details, talent releases.

This is a practical orientation, not legal advice. If you are handling large volumes of sensitive data, get a lawyer.

You are probably a processor, sometimes a controller

When a client gives you their customer data to work with, they decide why it is processed — they are the controller, and you are the processor acting on their instructions. When you collect data for your own purposes, such as your own newsletter list or your staff records, you are the controller.

The distinction matters because the obligations differ. Controllers must establish a legal basis and handle data subject requests. Processors must act only on documented instructions, keep the data secure, and disclose their own sub-processors.

Personal data is broader than you think

It is any information relating to an identified or identifiable person. Names and emails obviously. Also: IP addresses, device identifiers, a customer quote attributed to a job title in a small company, a photograph, a voice recording, a Slack handle.

A brief containing three verbatim customer interview quotes is a document holding personal data, with every obligation that follows — including the possibility that one of those customers asks for their data to be deleted.

The four questions worth asking about any tool

  1. Where is the data physically stored? EU storage avoids the complexity of international transfer mechanisms entirely.
  2. Is there a data processing agreement, and does it name sub-processors? A vendor who cannot produce a current sub-processor list has not thought about this.
  3. What happens to the data on deletion, and does that include backups? "Deleted from the interface" and "deleted" are different claims.
  4. Is the content used to train models? This has become the most consequential question of the last three years, and the answer is frequently buried.

Switzerland is not the EU, but it is close

The revised Swiss Federal Act on Data Protection (revFADP, or revDSG in German) has been in force since September 2023 and is deliberately aligned with the GDPR. Switzerland holds an EU adequacy decision, so transfers from the EEA to Switzerland do not require additional safeguards.

In practice, a Swiss agency serving EU clients has to satisfy both regimes. The differences that matter are procedural — Switzerland has no equivalent of the GDPR's administrative fines against companies, but it does have criminal liability for individuals in certain cases, which tends to focus attention.

Retention is where most agencies are non-compliant

Not through malice, through inertia. Project archives from 2017 sitting on a shared drive, containing research participant contact details, with no retention policy and no deletion date.

The principle is storage limitation: keep personal data only as long as necessary for the purpose. That requires deciding what the period is, per data type, and then actually deleting. A retention policy nobody executes is documentation of an intent to comply, which is not the same thing.

A minimum viable checklist

  • Know which of your tools hold client personal data, and where each stores it
  • Have a signed DPA with every one of them
  • Define retention periods for research data, and set calendar reminders to execute them
  • Keep personal data out of briefs where an anonymised summary would do the same job
  • Have a named person who receives data subject requests, and a documented 30-day process
  • Check the AI training clause in every tool you have adopted since 2023