Alex is Sprintlaw’s co-founder and principal lawyer. Alex previously worked at a top-tier firm as a lawyer specialising in technology and media contracts, and founded a digital agency which he sold in 2015.
What Must A Data Processor Agreement Include Under UK GDPR?
- 1) The Processing Details (The “What Are We Actually Doing?” Section)
- 2) Processing Only On Documented Instructions
- 3) Confidentiality Obligations
- 4) Security Measures (Not Just “We Take Security Seriously”)
- 5) Sub-Processors (Your Supplier’s Suppliers)
- 6) Help With Data Subject Requests
- 7) Personal Data Breach Support
- 8) Deletion Or Return Of Data At The End Of The Service
- 9) Audit And Compliance Information
- Key Takeaways
If you run a small business, you’re probably using third parties to help you operate and grow - cloud storage, email marketing, payroll, CRM systems, customer support tools, analytics, and more.
Here’s the catch: as soon as those suppliers handle personal data for you, UK GDPR will often require a written data processor agreement (also called a DPA) - where the supplier is acting as a processor.
And while “get a DPA in place” sounds like yet another admin task, it’s actually one of the simplest ways to reduce avoidable GDPR risk. A properly drafted DPA clarifies who does what, what security standards apply, and what happens if something goes wrong.
Below, we’ll break down what a data processor agreement is, when you might need one, what it should include, and how to get it sorted without it taking over your week.
What Is A Data Processor Agreement (And Why Should You Care)?
A data processor agreement is a contract between:
- You (the controller) - the business deciding why and how personal data is processed; and
- Your supplier (the processor) - the business processing personal data on your instructions.
Under the UK GDPR, controllers can’t just “hand off” data to suppliers and hope for the best. Where a processor is processing personal data on your behalf, UK GDPR expects a written agreement with specific mandatory terms.
From a practical point of view, a good DPA helps you:
- set clear rules on how your supplier can (and can’t) use the data
- require appropriate security measures
- manage breach response obligations and timelines
- control subcontracting (sub-processors)
- reduce confusion if a customer asks you about their data (for example, a Subject Access Request)
It’s also a common “quick win” in GDPR compliance. If the ICO ever asks how you manage processor risk, being able to show you have DPAs in place (and that you understand them) goes a long way.
Controller Vs Processor: The Simple Version
It’s easy to get stuck on the labels, so here’s a straightforward way to think about it:
- You’re likely the controller if it’s your customer list, your staff records, your marketing database, or your service delivery.
- Your supplier is likely the processor if they only handle that data to provide their service to you (for example, hosting your database or sending emails on your behalf).
Sometimes, a supplier might be a controller in their own right (or a joint controller) depending on what they do with the data. That’s one reason why using a “one-size-fits-all” template can create problems - you want the agreement to match the real relationship.
When Do UK Businesses Need A Data Processor Agreement?
You’ll often need a data processor agreement whenever a third party processes personal data on your behalf as a processor. This can apply whether you’re a sole trader, limited company, charity, or partnership - the key question is the data processing role, not your business structure.
Common examples where small businesses often need a DPA include:
- Cloud hosting and storage (customer data stored on a hosted platform)
- IT support providers who access staff devices or email accounts
- Payroll and HR providers processing employee data
- Email marketing platforms sending campaigns to your customer list
- Customer support tools used to manage enquiries and tickets
- Bookkeeping/accounting platforms holding customer names, addresses, payment details (even if limited)
If you’re using processors but you haven’t reviewed your contracts in a while, it’s worth doing a quick audit. Many businesses “inherit” tools over time and don’t realise how many third parties have access to personal data.
“But My Supplier Already Has Terms And Conditions - Isn’t That Enough?”
Sometimes it is, sometimes it isn’t.
Many larger suppliers include a DPA (or “data processing addendum”) in their standard terms. That can be fine - if it includes the UK GDPR-required clauses and reflects what’s actually happening.
However, smaller suppliers, agencies, freelancers, and niche providers often don’t have GDPR-ready processor terms. Or they may have clauses that cause issues (for example, overly broad rights to use your data, unclear sub-processing, or vague security commitments).
If you want something properly tailored, a dedicated Data Processing Agreement is often the cleanest way to document the relationship.
What If You’re The Processor For Your Clients?
Many UK businesses sit on both sides of this.
For example, if you’re a marketing agency, IT provider, virtual assistant, software developer, or bookkeeping service, you might be a processor when you’re handling client contact lists or customer records under instruction.
In that case, your clients may request your DPA, or you may want to offer one as part of your standard onboarding pack. It can help you win business too - because it shows you take GDPR seriously and have a professional setup.
What Must A Data Processor Agreement Include Under UK GDPR?
UK GDPR doesn’t just say “put it in writing”. It expects specific content in the contract.
In plain English, your data processor agreement should clearly cover:
1) The Processing Details (The “What Are We Actually Doing?” Section)
- Subject matter of the processing (what service is being provided)
- Duration of processing (how long the supplier will handle data)
- Nature and purpose (why the data is processed and what happens to it)
- Types of personal data (for example, names, emails, addresses, IP addresses, payroll data)
- Categories of data subjects (customers, employees, contractors, website users)
This is often overlooked, but it matters. If a dispute happens later, these details are what help you show the supplier went beyond your instructions (or didn’t).
2) Processing Only On Documented Instructions
A core rule: processors must only process personal data based on your documented instructions (unless required by law to do otherwise).
For small businesses, this is important because it helps prevent your supplier from deciding to reuse or repurpose your customer list “for their own analytics” or “service improvement” unless you’ve agreed to it.
3) Confidentiality Obligations
Anyone at the processor who can access the data should be under a confidentiality duty.
This becomes especially relevant where a supplier uses contractors or outsourced staff. It also overlaps with your broader confidentiality approach in client and supplier contracts - but the DPA should still be explicit about confidentiality for personal data.
4) Security Measures (Not Just “We Take Security Seriously”)
The agreement should require appropriate technical and organisational measures to protect personal data.
What “appropriate” means depends on your business, the type of data, and the risks. For example, payroll data and health data will require a higher security standard than a basic email list.
In practice, you may want the DPA to reference measures like:
- access controls and least-privilege permissions
- encryption (in transit and/or at rest)
- secure development practices (where relevant)
- staff training and internal policies
- backup and disaster recovery
If your business stores personal data in the cloud (as most do), it’s also worth thinking through whether your tools are configured in a GDPR-friendly way. For example, questions around cloud storage often come up in practice, like whether cloud storage is being used compliantly.
5) Sub-Processors (Your Supplier’s Suppliers)
Most processors rely on other providers - hosting services, support tools, analytics, and so on.
Your data processor agreement should deal with:
- whether the processor can use sub-processors at all
- how you’re notified of changes
- what approval rights you have (specific approval, general approval, or a notice-and-object approach)
- requirements for the processor to impose equivalent obligations on sub-processors
This is a common weak spot. If you don’t have sub-processing controls, you can end up with your data being passed through multiple providers without visibility - which is exactly the type of risk GDPR is trying to reduce.
6) Help With Data Subject Requests
Individuals have rights under UK GDPR (access, deletion, rectification, objection, and more). If you receive a request, you may need your processor’s help to locate, export, correct, or delete data.
The DPA should set expectations for cooperation, timeframes, and practical support.
7) Personal Data Breach Support
If your processor suffers a security incident, you may have tight reporting deadlines depending on the circumstances.
Your data processor agreement should clearly cover:
- that the processor must notify you without undue delay after becoming aware of a personal data breach
- what information they must provide
- how they will help you investigate and remediate
- who bears the cost of response (often negotiated)
8) Deletion Or Return Of Data At The End Of The Service
When the relationship ends, your data needs to be returned or deleted (unless retention is required by law). The DPA should say:
- what happens to the data on termination
- how long deletion takes
- whether backups are included
- what evidence of deletion you can request
9) Audit And Compliance Information
Processors must make available information needed to demonstrate compliance and allow audits/inspections (within reason). This doesn’t always mean you’ll be turning up at your supplier’s office - but you should have a mechanism for:
- receiving security/compliance information
- asking reasonable questions
- obtaining certifications or reports where appropriate
If you’re building your overall compliance framework, you’ll also want to ensure your outward-facing documentation is consistent with your processor arrangements - for example, your Privacy Policy should accurately describe how you use suppliers and what happens to personal data.
Common Mistakes Small Businesses Make With Data Processor Agreements
Most DPA problems aren’t caused by bad intentions - they’re caused by being busy. Here are some issues we see regularly with growing businesses.
Using A Generic Template That Doesn’t Match Your Setup
A template might list the wrong categories of data, or assume you’re sharing marketing data when you’re actually processing employee records. It may also miss key UK GDPR clauses entirely.
This can leave you exposed if you ever need to enforce the contract (or show compliance).
Accidentally Letting The Processor Become A Controller
Some supplier terms are drafted to give the supplier broad rights to use data “for their own purposes”. That can shift roles (or muddy them), which creates extra compliance obligations and customer transparency requirements.
That’s not always “wrong”, but it needs to be understood and documented properly.
Not Thinking About International Data Transfers
If your processor (or their sub-processors) stores data outside the UK, you may need appropriate safeguards. This can be a tricky area, especially if your tools use international infrastructure.
The key takeaway: your DPA should help you identify where data goes, and what protections apply.
Forgetting The People Side Of Security
GDPR compliance isn’t just about IT systems - it’s also about staff behaviour and policies.
If your team uses AI tools, personal devices, or shared accounts, you may need internal rules that line up with your processor controls. Having a Acceptable Use Policy can help set clear expectations about how staff handle personal data in day-to-day work.
Similarly, if your business is experimenting with AI, it’s worth being clear-eyed about confidentiality and data handling - concerns around AI confidentiality come up a lot in practice, and they often intersect with your supplier contracts.
No Link Between The DPA And The Commercial Contract
A data processor agreement is often an add-on to a main services agreement (for example, an IT services contract). If the two documents contradict each other (for example, different liability caps, termination rights, or security commitments), it can create real headaches.
Ideally, your DPA and your broader services contract should be consistent and work together.
How To Put A Data Processor Agreement In Place (A Practical Checklist)
If you want a straightforward way to tackle this, here’s a step-by-step approach that works well for small businesses.
1) List Your Key Suppliers Who Touch Personal Data
You don’t need to start with every minor tool. Focus first on suppliers that:
- have access to customer data
- store employee data
- process payment-related personal data
- provide IT support or system administration
2) Confirm The Roles (Controller/Processor/Controller)
Ask: are they processing on your instructions, or are they deciding how and why data is processed?
If you’re not sure, it’s worth getting advice - mislabelling roles can lead to the wrong contract terms and compliance steps.
3) Review What You’ve Already Signed
Look for:
- a separate DPA document
- “data processing” clauses in the main contract
- references to security measures and sub-processors
- breach notification obligations
If the agreement is missing the mandatory UK GDPR terms, that’s a red flag.
4) Put The Right Agreement In Place (And Make It Easy To Reuse)
For many small businesses, the best approach is to have a consistent, lawyer-drafted DPA template that you can use with suppliers (and also provide to your clients if you act as a processor).
This is where a tailored Data Processing Agreement is especially useful - it gives you a solid base that reflects your real operations rather than forcing you to squeeze your business into a generic template.
5) Make Sure Your External Docs Match Your Reality
When you use processors, you often need to tell people (in clear language) that third parties help you deliver your services.
That’s why your Privacy Policy and internal compliance documents should be updated alongside your DPAs - it keeps everything aligned and avoids saying one thing publicly while doing another operationally.
6) Keep Records And Review Regularly
DPAs aren’t a “set and forget” job.
Suppliers change their systems, add sub-processors, move data hosting, and update security measures. A light-touch review schedule (for example, annually or when you onboard a new major tool) can help you stay compliant without it becoming a full-time project.
If you’re trying to pull your overall compliance together, a structured GDPR approach (rather than piecemeal fixes) can be more efficient in the long run, like a GDPR package that covers the key building blocks.
Key Takeaways
- A data processor agreement is often required under UK GDPR where a supplier acts as a processor and processes personal data on your behalf.
- Your DPA should clearly document the processing details, require processing only on your instructions, and set out confidentiality and security obligations.
- A strong DPA should also deal with sub-processors, breach notification and support, help with data subject requests, and what happens to data at the end of the relationship.
- Common mistakes include relying on generic templates, unclear controller/processor roles, ignoring international transfers, and letting the DPA conflict with the main services contract.
- A practical way to manage DPAs is to audit your key suppliers, review existing terms, and implement a consistent, tailored agreement you can reuse as you grow.
Information only: this article is not legal advice. If you’d like help putting a data processor agreement in place (or reviewing what you already have), you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.


