A mid-size digital agency is building a new WordPress site for a retail client. The brief includes migrating an existing customer email list from the old site. The development team pulls a CSV export of 14,000 email addresses, first names, and purchase histories from the client’s Shopify store, works with it locally during development, and stores it in a shared Dropbox folder for a few weeks while the migration is validated. Nobody signs a data processing agreement. Nobody on the dev team has clearance to hold that data. When the project finishes, the CSV is left in the Dropbox folder indefinitely.
This scenario plays out in some form at dozens of UK agencies every week. It is a serious UK GDPR breach waiting to happen — not in a theoretical, hypothetical way, but in the way that attracts ICO investigations, enforcement notices, and fines that can reach 4% of global annual turnover for the most serious violations. And yet it feels completely normal from inside the agency, because nothing obviously bad is happening. The data is just sitting there.
Understanding where your actual exposure lies — and what the law requires you to do about it — is one of the unglamorous but genuinely important pieces of running a digital agency in the UK. This article covers the practical reality, not the legalese.
Controller vs. Processor: Understanding Your Role
The first thing to get straight is your legal role when you’re handling client data. UK GDPR distinguishes between two types of organisation: data controllers, who determine why and how personal data is processed, and data processors, who process personal data on behalf of a controller, following their instructions.
Most digital agencies operate in both roles simultaneously, which is where confusion arises. When it comes to your own data — the contact details of your leads, clients, and suppliers stored in your CRM — you are the data controller. You decided to collect it, you determine how it’s used, and you bear primary responsibility for protecting it. When it comes to data you handle on behalf of your clients — their customers’ email addresses, their users’ analytics data, their subscriber lists — you are almost certainly a data processor.
This distinction matters enormously because the obligations that flow from each role are different. As a controller, you need a lawful basis for every type of processing you do (legitimate interests, consent, contractual necessity, and so on), and you need a privacy policy that explains it all. As a processor, you are bound to act only on the documented instructions of the controller, and you must have a written Data Processing Agreement (DPA) in place before you touch the data.
The key test: if you are accessing, storing, transforming, analysing, or transmitting personal data that belongs to your client’s end-users — their customers, subscribers, employees, or website visitors — you are acting as a data processor, and a DPA is legally required. “We’ve always done it this way” is not a substitute.
There is a third category worth mentioning: joint controller. If your agency and a client are both making decisions about how end-user data is processed — for example, in a shared analytics arrangement or a co-branded email campaign — you may be joint controllers, with corresponding shared obligations. Joint controllership is rarer for most agencies but is increasingly relevant for those running marketing automation programmes on behalf of clients.
Data Processing Agreements: The Gap Almost Every Agency Has
Under UK GDPR Article 28, every controller must have a written contract in place with each processor it uses. Equally, if you are a processor, every controller whose data you handle must have a signed DPA with you. This isn’t optional, and “we have a general services agreement” doesn’t satisfy it unless that agreement contains the specific clauses Article 28 requires.
A compliant DPA must include: the subject matter, duration, nature and purpose of the processing; the type of personal data and categories of data subjects; the obligations and rights of the controller; instructions that the processor only acts on the controller’s documented instructions; confidentiality obligations on authorised personnel; security measures; rules on engaging sub-processors; assistance with data subject rights requests; help with breach notifications and DPIAs; data return or deletion on contract termination; and audit rights.
That is a specific list. A DPA that says “we’ll keep your data safe and not share it with anyone” does not satisfy it. For agencies that process significant volumes of client customer data — running email campaigns, managing analytics, migrating CRM data, building e-commerce sites — a proper DPA template is not a nice-to-have. It is a legal requirement.
The practical implication: review every active client engagement and ask whether you have access to personal data belonging to that client’s end-users. For each one where the answer is yes, you need a signed DPA. A well-drafted template can be used across all clients with minor customisation per engagement. If you don’t have one, the ICO’s model clauses for controller-processor contracts are a reasonable starting point, though a data protection solicitor can produce a more agency-specific version for a few hundred pounds.
The Types of Personal Data Agencies Actually Handle
It helps to be specific about the kinds of personal data a typical UK digital agency encounters in the course of normal client work. The list is longer than most people expect:
- Website analytics data: Google Analytics 4, Matomo, Hotjar, and similar tools collect IP addresses, browser fingerprints, and behavioural data on individual users. If your agency has access to a client’s analytics account, you are processing personal data. GA4’s approach to IP anonymisation has specific configuration requirements; unconfigured GA4 can place your client in breach of their own ICO obligations, and you in breach as their processor.
- Email subscriber lists and CRM exports: any CSV, API integration, or direct database access involving email addresses and associated attributes (name, purchase history, preferences, location) constitutes processing personal data. These are among the highest-risk data types because they are frequently exported, stored locally, and shared across teams without formal controls.
- E-commerce customer data: Shopify, WooCommerce, and Magento stores hold names, delivery addresses, payment histories, and sometimes partial payment card data. Agencies with admin access to these platforms — for development, support, or reporting purposes — are processing all of it.
- Form submissions and enquiry data: if you build or manage contact forms, lead capture pages, or intake forms for clients, you are typically the first stop for that submission data before it lands in a CRM. Even temporary possession counts as processing.
- Employee data from client HR or intranet projects: agencies building internal tools, staff directories, or HR platforms may work directly with employee records — names, job titles, employment details. This is personal data and often more sensitive than customer data.
- Support ticket content: if you’re managing a helpdesk or shared inbox on behalf of a client, the conversations in those tickets frequently contain personal information about the client’s customers.
For each category, the question is the same: do you have a DPA with the relevant client, are you applying appropriate security measures, and do you have a clear data retention policy that means you’re not holding it longer than necessary?
Sub-Processors: Every Tool You Use Is in Scope
Here is the part of GDPR compliance that most agencies genuinely haven’t thought through. When you are a data processor for a client, any third-party tool or service you use to process that client’s data becomes a sub-processor. You are required to have your controller’s authorisation before engaging a sub-processor, and you bear responsibility for the sub-processor’s compliance with GDPR.
In practice, this means that every SaaS tool your agency uses that might touch client personal data is a sub-processor. Your project management tool — if client contact details or support ticket content lives in it. Your cloud storage provider — if client data CSVs sit in it. Your design collaboration tool — if it contains screenshots of client customer data. Your email service — if you’re sending communications on behalf of clients from your own account.
You don’t need to list every sub-processor in every DPA, but you do need to be able to demonstrate that you’ve carried out due diligence on the tools you use, that they have their own compliant data processing infrastructure (look for SOC 2 Type II, ISO 27001, or equivalent certifications), and that you can provide clients with a list of sub-processors you’re using in relation to their data if they ask.
Common gap: agencies that use US-based SaaS tools (including many popular project management and analytics platforms) must ensure that international data transfer mechanisms are in place — either Standard Contractual Clauses (SCCs) or an equivalent framework. Since the invalidation of Privacy Shield and the subsequent UK-US Data Bridge, this has become a specific area of scrutiny. Most major US vendors now provide SCCs as standard; check your vendor’s DPA for confirmation.
Your Own CRM Data: What You Owe Your Clients and Contacts
Separate from the processor role, agencies also have direct controller obligations for the personal data they hold about their own contacts — prospective clients, current clients, and lapsed clients in their CRM; email subscribers to their newsletter; candidates who’ve applied for jobs; freelancers and subcontractors in their supplier database.
The core obligations here are more familiar but worth stating clearly. You need a lawful basis for holding and using each category of data. For clients, this is typically contractual necessity or legitimate interests. For prospects, legitimate interests is usually the applicable basis for follow-up communications, but it requires a balancing test — you genuinely need to be able to demonstrate that your interests in marketing to them are not overridden by their privacy interests. For newsletter subscribers, you need freely given, specific, informed, and unambiguous consent — a pre-ticked box does not satisfy this.
You also need to honour data subject rights. If a current or former client requests a copy of all personal data you hold about them (a Subject Access Request, or SAR), you have one calendar month to provide it. This is not as simple as exporting a CRM record — it requires searching emails, documents, project files, and any other system where their data might live. Agencies without organised data stores find SARs extremely time-consuming. Having all client data centralised in a structured platform — rather than scattered across email threads, spreadsheets, and separate tools — makes SARs manageable rather than a week-long exercise in forensic archaeology.
Similarly, if a contact asks to be removed from your database, the right to erasure applies. “Removed from the mailing list” is not the same as erasure — you may need to delete records from your CRM, email platform, and any other system where their data sits. Your data retention policy should define how long different categories of data are kept, and there should be a process for actually acting on it rather than just having a policy document that nobody reads.
Breach Response: What You’re Actually Required to Do
A personal data breach under UK GDPR is broader than most people realise. It’s not just a hack. It includes the accidental exposure of personal data, unauthorised access by an employee, emailing a client database to the wrong recipient, losing a laptop with unencrypted data on it, or a third-party tool suffering a breach that exposed data you’d transferred to it. The definition is: any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
If a breach occurs and you are the controller, you must report it to the ICO within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. If you are a processor and you suffer a breach involving a client’s data, you must notify the controller “without undue delay” — in practice, as fast as possible, and certainly within 24 hours so the controller has time to assess whether they need to report to the ICO within their 72-hour window.
The 72-hour clock is unforgiving. Agencies that discover a breach on a Friday afternoon and decide to deal with it on Monday are already at risk of a procedural violation. The ICO does not require you to have all the answers within 72 hours — you can submit an initial notification acknowledging a breach is under investigation and follow up with more detail. But you must have initiated the report within the window.
For a small agency, having a breach response procedure doesn’t need to be a 40-page document. It needs to be a clear, short set of instructions that answers: who gets notified internally, who decides whether this is reportable, who files the ICO report, and who notifies affected clients. It should be written down and known to your team before a breach happens — not improvised in a panic after one.
Practical Steps to Get Your Agency Into Better Shape
GDPR compliance for a digital agency is not a one-time project — it’s an ongoing operational practice. But getting from “we haven’t really thought about this” to “we have a defensible position” doesn’t require months of work. Here is the practical sequence:
- Conduct a data audit. Map every category of personal data your agency holds, where it lives, why you hold it, the legal basis, and who has access. This takes a day or two the first time but creates the foundation for everything else. The ICO calls this a Record of Processing Activities (ROPA), and while it’s only mandatory for organisations with 250+ employees or those whose processing is high-risk, it is extremely useful for any agency.
- Identify every client engagement involving personal data. For each one, check whether a DPA exists. If not, issue one immediately. Use a template so you can turn these around quickly — this is not something that should take more than a day per client once you have a good template.
- Review your sub-processor list. For each SaaS tool your team uses, check whether it has a compliant DPA and what international transfer mechanisms it relies on. Most will have this information in their trust centre or privacy documentation. Make a note of anything that’s unclear or missing and chase the vendor.
- Update your privacy policy and internal policies. Your client-facing privacy policy needs to accurately reflect how you process data and the basis for each type. Your internal policies need to cover data retention, breach response, SAR handling, and acceptable use of client data.
- Train your team. The most technically correct policies are worthless if your developers are still emailing client CSVs to personal Gmail accounts for convenience, or if your account managers don’t know what a SAR is. A short annual training session — one hour covering the basics — is far more effective than a dense policy document nobody reads.
- Register with the ICO. Most organisations that process personal data are required to pay the data protection fee to the ICO. For most small agencies this is £40 per year. It is a legal requirement, not a voluntary payment. Check your current registration status at ico.org.uk.
None of this is especially onerous. The agencies that have the biggest compliance gaps are almost always those where GDPR has been treated as someone else’s problem — a footnote in the website’s privacy policy rather than an operational reality. Getting your house in order protects you, protects your clients, and signals professional credibility to the clients who ask about it.
GDPR Compliance as a Client Trust Signal
There is a commercial dimension to this that’s worth naming. Larger clients — particularly those in regulated sectors like financial services, healthcare, or legal — now routinely include data protection due diligence in their supplier selection process. You may be asked to complete a vendor security questionnaire, provide evidence of your ICO registration, share your DPA template, or demonstrate that your sub-processors are compliant. Agencies that cannot answer these questions competently lose pitches they would otherwise win.
More broadly, clients who trust you with their customer data are placing significant confidence in you. A client whose 40,000-subscriber email list ends up in a breach, even through no fault directly attributable to you, will hold you partly responsible if you lacked the basic contractual and procedural safeguards that should have been in place. The reputational cost of a data incident is almost always disproportionate to the size of the fine — it is the client relationships and the word-of-mouth damage that hit hardest.
Treating data protection seriously — having the DPAs, the controls, the retention policies, the breach procedures — is not just about compliance. It is about being the kind of agency that clients can confidently bring sensitive work to. That is a genuine competitive advantage in a market where most small agencies are still winging it.
For more on running a well-structured agency, see our guides on getting digital contracts signed efficiently, why client communication logs matter, and keeping your CRM data clean and accurate. To see how Marque handles client data, records, and secure document management in one place, visit the features page.