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.
Data Processor Responsibilities Under UK GDPR (The Core Legal Duties)
- 1) Only Process Data On Documented Instructions
- 2) Confidentiality (Limit Access And Train Staff)
- 3) Appropriate Security Measures (Not Just “Good Intentions”)
- 4) Sub-Processors: You Can’t Just “Outsource And Forget”
- 5) Assist The Controller With Compliance Requests
- 6) Breach Notification Duties
- 7) Records Of Processing Activities (ROPA) For Processors
- 8) International Data Transfers (If Data Leaves The UK)
Step-By-Step: How To Stay Compliant As A Data Processor (Practical Checklist For SMEs)
- 1) Confirm Your Role (Controller, Processor, Or Both)
- 2) Map The Data You Handle For Clients
- 3) Put The Right Contract In Place Before You Start Processing
- 4) Implement Real Security Controls (And Document Them)
- 5) Control Sub-Processors
- 6) Have A Breach Response Process You Can Actually Use
- 7) Align Your Privacy Documentation With Your Reality
- Key Takeaways
If your business uses suppliers who handle personal data for you (think payroll, cloud hosting, marketing platforms, IT support, CRM systems, or outsourced customer service), you’re almost certainly working with a GDPR “data processor”.
And if you provide services that involve handling someone else’s customer or employee data, there’s a good chance you are the processor.
Either way, understanding what UK GDPR expects of processors matters. Under the UK GDPR and the Data Protection Act 2018, processors don’t just “follow orders” - they have direct legal obligations, and getting them wrong can create serious commercial and regulatory risk for your business.
In this guide, we’ll break down what a processor is, what the role of the processor under GDPR rules actually requires, and the practical steps small businesses can take to stay compliant from day one.
What Is A Data Processor Under UK GDPR (And Why Does It Matter)?
Under the UK GDPR, the two key roles you’ll see are:
- Data controller: decides why and how personal data is processed (the “decision-maker”).
- Data processor: processes personal data on behalf of a controller (the “service provider”).
This matters because your responsibilities (and your legal risk) change depending on which “hat” you’re wearing.
Quick Examples (So You Can Spot It In Real Life)
Your business is likely a controller when you:
- collect customer details to fulfil orders or provide services
- store employee records and run payroll
- decide what customer data to collect via your website
Your supplier is likely a processor when they:
- host your website or customer database
- manage payroll based on data you provide
- send marketing emails on your instructions
- provide outsourced IT support with access to staff/customer devices
Your business may be a processor when you:
- provide outsourced HR, IT support, bookkeeping, or marketing services
- run a SaaS platform where clients upload customer data and you process it for them
- operate a call centre handling enquiries for another business
One important catch: some businesses can be both a controller and a processor depending on the activity. For example, an IT provider may be a processor when accessing client data to fix issues, but a controller for its own staff HR records and business operations.
Data Processor Responsibilities Under UK GDPR (The Core Legal Duties)
So, what are the headline responsibilities for a data processor under UK GDPR?
Processors have direct statutory obligations. In plain English, you’re expected to process personal data securely and in a controlled way - even if you’re “only” handling it for someone else.
1) Only Process Data On Documented Instructions
A processor must only process personal data on the controller’s documented instructions, unless UK law requires otherwise.
In practice, this means you should be able to answer:
- What data are we processing?
- What are we doing with it (hosting, analysing, emailing, storing, deleting)?
- Who told us to do that, and where is that instruction recorded (contract, ticketing system, statement of work)?
This is one reason a properly drafted Data Processing Agreement is so important - it puts the instructions (and limits) in writing.
2) Confidentiality (Limit Access And Train Staff)
Processors must ensure people authorised to process the data are subject to confidentiality obligations.
For a small business, “confidentiality” is usually delivered through a mix of:
- employment contracts / contractor terms
- confidentiality clauses in client agreements
- access controls (role-based access, least privilege)
- staff training and clear internal rules
If you use personal devices or remote working, this is also where internal policies matter, like an Acceptable Use Policy that sets clear expectations for how your team can handle client/customer data.
3) Appropriate Security Measures (Not Just “Good Intentions”)
Processors must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
There isn’t one “magic list” that suits every business. Security should be proportionate to:
- the nature of the data (e.g. medical data is higher risk)
- the amount of data
- what could go wrong (loss, unauthorised access, ransomware)
- how easy it would be to cause harm to individuals
Common security measures that are often expected include:
- multi-factor authentication for admin access
- encryption in transit and (where possible) at rest
- regular patching and vulnerability management
- strong password controls and password managers
- secure backups and tested disaster recovery processes
- logging and monitoring for suspicious access
If you’re storing data in cloud tools, don’t assume the tool is automatically compliant just because it’s popular. You still need to assess whether your setup is lawful and secure - especially for access permissions, retention settings, and international data transfers. Many businesses start by sanity-checking common tools via an GDPR cloud storage compliance lens.
4) Sub-Processors: You Can’t Just “Outsource And Forget”
Processors often rely on other suppliers (sub-processors) - for example, hosting providers, email delivery services, analytics tools, or offshore support teams.
Under UK GDPR, a processor can only appoint sub-processors with the controller’s prior written authorisation (either specific authorisation for each sub-processor, or a general authorisation that allows sub-processors subject to notice and an opportunity for the controller to object). You also need a written contract in place with sub-processors that imposes data protection obligations equivalent to those you owe the controller.
Practically, this means:
- maintaining an up-to-date list of sub-processors
- getting written approval via either specific approval, or a general authorisation process with notice/objection rights
- flowing down key UK GDPR obligations into sub-processor contracts
- doing due diligence before onboarding a new sub-processor
5) Assist The Controller With Compliance Requests
Processors must help controllers meet their UK GDPR obligations, taking into account the nature of the processing and the information available to the processor.
This can include assistance with:
- responding to data subject rights requests (e.g. access requests)
- security measures and evidence of compliance
- data protection impact assessments (DPIAs) where relevant
- breach response and notifications
The key point: controllers can’t comply properly unless processors provide timely support. This is why response times and responsibilities should be clearly set out in your processing terms (not left vague).
6) Breach Notification Duties
If there is a personal data breach, processors must notify the controller without undue delay after becoming aware of it.
It’s then generally the controller’s job to decide whether the ICO and affected individuals need to be notified - but they can only do that if you give them the right information quickly.
To make breach response realistic (not chaotic), many businesses adopt a documented Data Breach Response Plan so your team knows what to do, who to contact, and what details to capture when something goes wrong.
7) Records Of Processing Activities (ROPA) For Processors
Processors must maintain records of categories of processing activities carried out on behalf of controllers (with some limited exceptions). This is often overlooked by smaller service providers.
Even a lightweight record is better than nothing. Typically, you’d record:
- who your controller-clients are
- the categories of processing you do for them
- sub-processors you use
- international transfers (if any)
- security measures in place (high level)
8) International Data Transfers (If Data Leaves The UK)
If, as a processor, you transfer personal data outside the UK (or allow access from outside the UK), you and the controller need to ensure there’s a lawful transfer mechanism in place (for example, the UK International Data Transfer Agreement (IDTA) or the UK Addendum to SCCs).
This commonly comes up when:
- you use overseas hosting or support teams
- your sub-processors store data outside the UK
- administrators access client systems while travelling
This is another area where “we didn’t realise” isn’t a great defence, so it’s worth mapping where data actually goes in your service delivery.
What Is The Role Of The Processor GDPR Requires In Contracts (And What Must Be In Writing)?
One of the most practical parts of processor compliance is getting the contract right.
UK GDPR requires a binding written agreement between the controller and processor that sets out the processing and includes specific terms.
In other words, if you’re a processor, you should expect (and usually insist) that your client relationship includes proper data protection clauses, not just a vague line saying “we comply with GDPR”.
Key Clauses A Processor Contract Usually Needs
A compliant controller–processor contract typically sets out:
- Subject matter and duration of the processing
- Nature and purpose of the processing
- Type of personal data and categories of data subjects
- the controller’s instructions
- confidentiality obligations
- security requirements
- rules around sub-processors
- assistance obligations (rights requests, DPIAs, breach management)
- deletion or return of data at end of services
- audit rights / compliance information sharing
If you provide services to multiple clients, you’ll often build this into your standard terms or a separate schedule. Many businesses use a dedicated Data Processing Schedule to keep the privacy terms consistent and easy to update.
It can be tempting to copy/paste clauses from a template, but processors often get caught out because the contract says one thing and the business does another (for example, the contract bans sub-processors but the processor uses five software tools behind the scenes). The goal is alignment: the contract should reflect how you actually deliver your service.
Step-By-Step: How To Stay Compliant As A Data Processor (Practical Checklist For SMEs)
Data processor compliance can feel abstract until you turn it into a simple process you can follow and repeat.
Here’s a practical checklist you can implement even if you’re a small team.
1) Confirm Your Role (Controller, Processor, Or Both)
Start by mapping your services and asking: are we deciding the “why/how” (controller), or carrying out tasks on someone else’s behalf (processor)?
If you’re both, separate those activities in your documentation and your contracts.
2) Map The Data You Handle For Clients
You don’t need a massive spreadsheet to start with, but you do need visibility. Capture:
- what personal data you receive (names, emails, payment info, HR data, special category data)
- where it’s stored (systems, devices, cloud platforms)
- who can access it (roles, teams, contractors)
- who else touches it (sub-processors)
- how long you keep it and how deletion works
3) Put The Right Contract In Place Before You Start Processing
If you’re the processor, don’t start work until the processing terms are agreed. If you’re the controller, don’t onboard a processor without those terms either.
In many cases, this is handled through a Data Processing Agreement that sits alongside your main services agreement.
4) Implement Real Security Controls (And Document Them)
Security isn’t just an IT issue - it’s a legal compliance issue under UK GDPR.
Set minimum baseline controls (MFA, patching, backups, encryption) and write down:
- your security measures
- who is responsible internally
- how you review and update controls
This helps when a controller asks for “evidence” of your GDPR compliance - something that often happens in supplier due diligence questionnaires.
5) Control Sub-Processors
Make it standard practice to:
- maintain a list of sub-processors you use
- review their security and data protection terms before onboarding
- ensure your customer contracts allow you to use them (with the right approvals)
6) Have A Breach Response Process You Can Actually Use
A breach response plan shouldn’t live in someone’s inbox.
Make sure your team knows:
- what counts as a “personal data breach” (it’s broader than hacking)
- how to escalate internally
- how to notify the controller quickly with meaningful details
Many businesses operationalise this with a written Data Breach Response Plan and basic incident templates.
7) Align Your Privacy Documentation With Your Reality
If you’re only acting as a processor for client data, your public-facing privacy documents may focus more on your own business data (like website visitors, prospects, and your own employees).
But you still want your internal and client-facing documentation to be consistent - and if you collect any personal data directly (for example, on your website), you’ll generally need a compliant Privacy Policy that reflects what you do.
If you’re trying to build a comprehensive compliance framework, bundling your approach into a structured programme (policies + agreements + processes) can be far easier than trying to fix issues one-by-one later. Some businesses take that approach using a GDPR Package so the essential documents and steps are covered together.
Common Data Processor Compliance Mistakes (And How To Avoid Them)
Most businesses don’t get into trouble because they’re trying to do the wrong thing - it’s usually because they’re busy, scaling quickly, and data protection becomes an afterthought.
Here are common mistakes we see, and what to do instead.
Mistake 1: Assuming The Controller Is “Fully Responsible”
Controllers do carry significant responsibility, but processors also have direct UK GDPR obligations. If you’re a processor, you need your own compliance controls, not just a client’s instructions.
Mistake 2: No Processor Agreement (Or A Generic Clause That Doesn’t Fit)
If you can’t point to processing terms that include the required UK GDPR clauses, you’re exposed.
Fix: put a proper processor agreement or schedule in place, and make sure it matches your actual service delivery (including sub-processors and international access).
Mistake 3: Using Sub-Processors Without Approval
It’s easy to sign up to tools “to get the job done” without thinking about data protection approvals.
Fix: maintain a sub-processor list and bake authorisation into your contracts (either a general authorisation model with notice and an opportunity for the controller to object, or specific approvals).
Mistake 4: Weak Internal Controls (Especially For Small Teams)
Small teams often share logins, use personal devices, or skip training because it feels “too corporate”. Unfortunately, these are the exact habits that create breaches.
Fix: implement basic access controls and policies early (it’s much easier before you have 20 people and multiple systems).
Mistake 5: Slow Or Incomplete Breach Notification
Processors must notify controllers without undue delay. Delays often happen when no one is sure whether something is actually a breach.
Fix: train your team on what a breach looks like and use a simple escalation pathway with clear internal owners.
Key Takeaways
- Under UK GDPR, processors have direct legal duties (not optional best practice) and these apply even where you’re processing on behalf of someone else.
- The processor’s role is to process personal data only on documented instructions, maintain confidentiality, and implement appropriate security measures.
- Processors must manage sub-processors carefully, including getting the right form of written authorisation and flowing down UK GDPR obligations into sub-processor contracts.
- If a breach happens, processors must notify the controller without undue delay and provide enough detail to support regulatory decisions.
- A compliant written contract (often a Data Processing Agreement or schedule) is essential, and it should reflect how you actually deliver the service.
- For small businesses, staying compliant is much easier if you put baseline policies, security controls, and breach response processes in place early.
If you’d like help reviewing your data processing arrangements or putting the right documents in place, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.


