GDPR Data Controller vs Data Processor: Key Differences for UK Businesses

If you run a small business in the UK, chances are you handle personal data every day - customer emails, staff records, delivery addresses, website enquiries, or even CCTV footage.

Under the UK GDPR and the Data Protection Act 2018, one of the first (and most important) questions is: are you a data controller or a data processor?

This sounds technical, but it matters because it shapes:

• who is responsible for compliance (and for what);
• which documents you need in place;
• how you should manage suppliers and outsourced services; and
• how risk is shared if something goes wrong (like a data breach).

In this guide, we’ll explain the GDPR data controller vs data processor question in plain English, with practical examples and contract tips you can actually use.

What Is The Difference Between A GDPR Data Controller And Data Processor?

The simplest way to understand the GDPR data controller vs data processor distinction is to focus on who is really making the key decisions about the processing.

Data Controller (The “Decision Maker”)

A data controller is the organisation that determines:

• why personal data is processed (the purposes); and
• the essential elements of how it is processed (the key means).

If it’s your business deciding to collect customer details to fulfil orders or manage your mailing list, you’re acting as the controller.

Data Processor (The “Service Provider”)

A data processor processes personal data on behalf of the controller. They don’t decide the “why”, and they must process data only on the controller’s documented instructions.

That said, processors can still make decisions about non-essential or day-to-day means (for example, what IT systems or security tools they use) as long as they stay within the controller’s instructions and the contract.

For example, if you hire an outsourced payroll provider, they’re processing staff data because you’ve instructed them to run payroll.

Can You Be Both A Controller And A Processor?

Yes - and this is where many small businesses get caught out.

You might be a controller for your own business operations, but a processor when delivering services to another business. For example:

• You’re a controller for your own staff HR records.
• You’re a processor if you manage customer support inboxes for a client and only act on their instructions.

Some arrangements also create “joint controllers” (more on that later), but for most SMEs, getting clear on controller vs processor is the big first step.

Common Examples For Small UK Businesses (So You Can Classify Yours)

Let’s make the GDPR data controller vs data processor concept more concrete with real-world examples.

Examples Where You’re Usually The Controller

You’re usually a controller when you decide the purposes of processing and the key means, such as:

• running an online shop and collecting customer names and delivery details;
• collecting enquiries via your website form;
• keeping a client list and sending newsletters;
• hiring employees and storing right-to-work documents;
• running CCTV in your premises (and deciding how long to keep footage).

Because your business is the one deciding the purpose and overall approach, you’ll generally be responsible for the core UK GDPR compliance obligations - including transparency, lawful basis, and responding to data subject requests.

That’s also why it’s common for controllers to need a clear Privacy Policy and internal processes that match what they’ve promised to individuals.

Examples Where You’re Usually The Processor

You’re usually a processor when another organisation decides the purposes and key means, and you simply carry out services involving personal data on their instructions, such as:

• a marketing agency uploading a client’s email list into their chosen platform and sending campaigns based on their instructions;
• an IT support provider accessing a client’s systems to troubleshoot issues;
• a virtual assistant handling customer support tickets for a business;
• a hosted call answering service taking messages for a client.

Even as a processor, you still have direct legal obligations (it’s not “the controller’s problem”). You also need the right contract in place before you start processing.

Examples That Often Get Misclassified

Some situations look like “processor” work but can be controller (or joint controller) work depending on who is really making the decisions, and whether the supplier uses the data for their own purposes:

• Recruitment agencies are often controllers (or joint controllers) for candidate data where they decide what to collect, how to assess candidates, and how to run their candidate database - but they may also act as processors in more limited, client-led arrangements.
• Accountants are often independent controllers for much of what they do (for example, meeting professional and legal obligations), but they can be processors for specific, tightly instructed activities.
• Software providers are commonly processors for hosted services, but if they use customer personal data for their own separate purposes (like product analytics, service improvement, or training models), they may be a separate controller for those purposes (or the arrangement may require a different structure and transparency).

If you’re not sure where you sit, don’t stress - classification depends on what you actually do in practice, not what a supplier calls themselves in their terms.

Key GDPR Responsibilities Of Controllers Vs Processors

Once you understand the controller vs processor divide, the next step is knowing what each role must do.

Both roles have responsibilities under the UK GDPR, but controllers usually carry the heavier compliance load because they’re the ones setting the direction of the processing.

Core Responsibilities Of A Data Controller

As a controller, you generally need to:

• identify a lawful basis for each processing activity (for example, contract necessity, legitimate interests, legal obligation, consent);
• provide transparency information (typically via your privacy notice);
• only collect what you need and keep it accurate and up to date;
• set retention periods (how long you keep data) and securely delete when no longer required;
• implement security measures appropriate to the risk;
• handle individual rights requests (access, rectification, erasure, objection, etc.);
• manage processor relationships, including contracts and due diligence;
• report personal data breaches to the ICO where required, and inform affected individuals when the risk is high.

In practice, this often means your business needs a small “compliance toolkit”: policies, notices, contracts, and a plan for what you’ll do if something goes wrong. Many businesses formalise this through a GDPR package such as a GDPR package and internal policies tailored to how they actually operate.

Core Responsibilities Of A Data Processor

As a processor, your main obligations include:

• only processing on documented instructions from the controller;
• keeping personal data secure (appropriate technical and organisational measures);
• helping the controller comply with obligations (for example, assisting with rights requests or breach management);
• using sub-processors only with permission and under proper terms;
• keeping records of processing activities (in certain cases);
• notifying the controller without undue delay after becoming aware of a personal data breach.

Processors also need to ensure their own internal team understands how data is handled day-to-day. If staff are using business systems to process customer data, it’s smart to have an Acceptable Use Policy so expectations are clear and consistent.

What About “Joint Controllers”?

You may be joint controllers when two organisations jointly decide the purposes and key means of processing.

This is common in some partnerships, co-branded marketing campaigns, or where two businesses share a customer database for mutual benefit.

Joint controllership should be documented properly, including who handles transparency information and rights requests. If you’re working closely with another business and sharing personal data, it can also be worth documenting the arrangement through a Data Sharing Agreement.

What Contracts Do You Need? Data Processing Agreements, Clauses And Practical Tips

Contracts are one of the most overlooked parts of the controller vs processor issue - but they’re also one of the easiest ways to reduce risk.

When Do You Need A Data Processing Agreement (DPA)?

If you’re a controller using a processor, the UK GDPR requires you to have a written contract (often called a Data Processing Agreement or DPA) in place.

This applies whether your processor is:

• an IT support provider,
• a cloud hosting provider,
• a payroll provider,
• an outsourced customer support provider, or
• a marketing service provider handling customer lists.

In many cases, this DPA is implemented as a schedule to your main service agreement, such as a Service Agreement, rather than a standalone document.

What Should A GDPR-Compliant DPA Include?

A properly drafted DPA should cover, at a minimum:

• scope and instructions (what the processor can do, and what they can’t do);
• type of data and categories of individuals (e.g. customer contact details, staff payroll data);
• security requirements (and sometimes minimum standards);
• use of sub-processors (approval process and flow-down terms);
• assistance obligations (rights requests, DPIAs, breach support);
• international transfers (if data leaves the UK);
• return/deletion of data at end of services;
• audit/inspection rights (balanced with practicality for SMEs);
• confidentiality obligations for anyone processing the data.

Many DPAs are supported by operational documents too - for example a Data Processing Agreement and a data breach plan setting out who does what when an incident happens.

Don’t Rely On Generic Clauses (Even If They Look “GDPR Ready”)

It’s tempting to copy-paste a “GDPR clause” into your contracts and call it done.

The problem is that DPAs need to reflect your real-world setup. For example:

• If your supplier uses overseas subcontractors, you’ll need to deal with cross-border transfer terms.
• If sensitive data is involved (like health information), security and access controls need to be tighter.
• If you’re in a regulated industry, record-keeping and retention may have special rules.

A tailored agreement is usually far cheaper than trying to fix a dispute after a breach or a client complaint.

How To Manage Risk When You Outsource Or Use Third-Party Providers

Most small businesses rely on third parties - accountants, cloud storage, online booking tools, email marketing providers, and outsourced contractors.

Outsourcing can be great for growth, but it also means you’re trusting other organisations with personal data, which increases risk if you don’t do the basics.

Step 1: Map What Personal Data You Handle And Who Touches It

Before you can manage the controller/processor split properly, you need a basic map of:

• what data you collect (customers, suppliers, employees);
• where it’s stored (devices, cloud platforms, paper files);
• who has access (staff, contractors, suppliers); and
• why you need it (and how long you keep it).

This doesn’t need to be a massive corporate exercise - a practical spreadsheet is often enough to get started.

Step 2: Do Sensible Due Diligence On Processors

As a controller, you’re expected to choose processors that can provide “sufficient guarantees” they’ll protect personal data.

In plain English, you should check things like:

• Do they have security measures in place (e.g. MFA, encryption, access control)?
• Do they have a breach response process?
• Do they use sub-processors or overseas support teams?
• Are they willing to sign (or include) a compliant DPA?

If you’re dealing with high-risk data or a high volume of individuals, you may need to be more thorough (and document what you’ve checked).

Step 3: Make Sure Your Team Has Clear Rules

Even the best DPA won’t fix internal problems like staff emailing spreadsheets to personal accounts or saving passwords in a notes app.

Clear workplace rules help, especially if your team uses personal devices or works remotely. This is where internal policies and training matter - and if you’re asking staff to use personal devices, watch out for UK GDPR pitfalls around BYOD and monitoring.

Where personal data is being handled regularly by staff, having a set of workplace policies (and the right Employment Contract terms) can make expectations enforceable and reduce the risk of “informal” data handling becoming your normal.

Step 4: Have A Breach Response Plan Before You Need One

Data incidents are stressful, and things move quickly. If you don’t have a plan, it’s easy to lose time and make avoidable mistakes.

A practical breach plan should cover:

• who internally is responsible for triage and decision-making;
• how to contain the issue and preserve evidence;
• how to assess risk to individuals;
• when to report to the ICO (and how);
• how and when to contact affected individuals; and
• how to document what happened.

Many businesses build this into a formal Data Breach Response Plan, which keeps your process consistent and easier to follow under pressure.

Key Takeaways

• The data controller vs data processor distinction mainly comes down to decision-making: controllers determine the purposes and essential means, while processors process on the controller’s documented instructions (and may choose day-to-day operational means).
• Most small businesses are controllers for customer and employee data, but you may be a processor when you handle data for clients as part of your services.
• Controllers usually carry broader compliance responsibilities, including lawful basis, transparency, retention, and handling data subject rights requests.
• Processors still have direct UK GDPR obligations, including security, breach notification to the controller, and processing only on documented instructions.
• If you use a processor, you generally need a compliant Data Processing Agreement (often as part of your service contract) setting out instructions, security, sub-processing and end-of-contract deletion.
• Practical risk management matters just as much as paperwork: map your data, do due diligence on suppliers, train staff, and keep a breach response plan ready.

If you’d like help confirming whether you’re acting as a controller, processor or joint controller - or you want your contracts and privacy documents set up properly - you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.