What is a sub-processor?
A sub-processor is a third party that your supplier relies on to do its job, and that handles your customers' personal data in the process. If you are the controller and your supplier is the processor, the sub-processors are the companies the processor brings in behind the scenes, such as a cloud host or an email-sending provider. They sit one rung further down the chain, but they still touch the data.
Definition
Sub-processor, in one paragraph
A sub-processor is a company a data processor engages to help process personal data on a controller's behalf, and that itself handles that personal data. In plain terms: you hire a supplier to do something with your data, and your supplier hires others to help. Those others are the sub-processors. Under UK GDPR they are named, contracted and accounted for, because the processor stays responsible to you for everything they do.
The word that matters is "chain". Personal data rarely sits with a single company. A support tool, for example, has to send email through a delivery provider, take payment through a billing provider, and run its software on a cloud host. Each of those is a sub-processor, because each touches data the processor is handling for you. Knowing who sits in the chain is the whole point of the term.
| Data subject | The living person the personal data is about, for example your customer. |
|---|---|
| Controller | The organisation that decides why and how personal data is processed. Usually you. |
| Processor | A supplier that processes the data on the controller's behalf, under instruction. |
| Sub-processor | A third party the processor engages that also handles the personal data. |
| DPA | Data processing agreement: the contract that governs how the data is handled along the chain. |
| UK GDPR | The UK General Data Protection Regulation, the law that sets these duties. |
The chain
Controller, processor, sub-processor
The three roles form a chain of responsibility, and the term only makes sense once you can see where each link sits.
The controller decides
The controller is the organisation that decides why personal data is collected and what happens to it. If you run a shop and answer customer email, you are the controller of your customers' names, addresses and messages. You set the purpose, you carry the primary duty to the people whose data it is, and you choose who you trust to help.
The processor acts on instruction
A processor is a supplier you bring in to handle that data on your behalf, doing only what you have instructed and what the contract allows. A support tool that stores and organises your customer messages is acting as your processor. It does not get to decide to use that data for its own ends; it processes it for you, under a data processing agreement that pins down what it may and may not do.
The sub-processor sits one step further down
A sub-processor is a third party the processor itself engages to get the job done, and that handles the same personal data. The processor cannot do everything alone, so it relies on, say, an email-delivery provider to actually send replies and a cloud host to run the software. Those providers never deal with you directly, but they touch your data, so they belong in the chain and must be named. Crucially, the processor stays answerable to you for what its sub-processors do, so the chain does not let anyone duck responsibility.
Why it matters
What a published sub-processor list does for you
Naming the chain is not box-ticking. A clear, dated list is how a supplier earns trust and how you keep control of your own compliance.
You can see the whole chain
A list tells you exactly which other companies will touch your customers' data before you commit, instead of trusting a supplier blind. You can judge each provider on its merits and where it is based.
It meets a UK GDPR duty
A processor has to be transparent about sub-processors and have your authorisation for them. A published list and a notice commitment are the practical way that duty is met, rather than buried in a contract no one reads.
You get notice of changes
A good list is dated and comes with a promise to tell you before a new sub-processor goes live, so a change to who handles your data is never a surprise you find out about too late.
It supports your own records
As a controller you have your own accountability duties. Knowing your suppliers' sub-processors helps you keep your records of processing accurate and answer your customers honestly about where their data goes.
Reading a list well
What a good sub-processor list shows
Not all lists are equal. A useful one tells you more than a row of company names.
The clearest lists give you four things for each provider: the name, what it does, where it is based, and where it processes the data. The "where" matters because moving personal data outside the UK or EU adds its own safeguards under UK GDPR, so a UK or EU location is one less thing to check. A list that just names companies, with no context and no date, leaves you doing the detective work yourself.
A date is the quiet signal of a list maintained properly. Sub-processors change: suppliers switch hosts, add a payments partner, or drop a tool. A list with a "last updated" date, paired with a commitment to give notice before changes, tells you the supplier treats the chain as a living thing rather than a page written once and forgotten.
It is worth checking the list against the data processing agreement. The list is the human-readable view; the agreement is the contract that makes it binding and pins the processor to its responsibilities for the chain. The two should agree. If a provider appears in one and not the other, that is a question worth asking before you sign.
Sub-processor versus third-party sharing
A sub-processor handles your data on the processor's behalf, under instruction and inside the chain governed by the agreement. That is different from a supplier sharing your data with an unrelated third party for that party's own purposes, which is a separate matter with its own rules. The test is whether the company is acting for the processor on your behalf, or off doing its own thing with the data. The first belongs on the sub-processor list; the second is a red flag.
Where Solves fits
The sub-processors Solves uses
When you use Solves to handle support email, Solves is acting as your processor and you are the controller of your customers' data. To do the job, Solves relies on a deliberately short chain of sub-processors, and names every one. Postmark handles transactional email delivery, so replies and notifications reach the inbox. Stripe handles billing and card payments, which means card details go to Stripe and never touch Solves directly. A UK or EU cloud host runs the application and the database.
Keeping the chain short is a choice. Fewer sub-processors means fewer companies touching your customers' data and a list you can actually read. Alongside that, Solves encrypts customer support content at rest, restricts data to authorised access only, and keeps its operational logs to metadata, never message bodies or email addresses. The current, dated sub-processor list, with what each provider does and where it is based, is published in full, and the data processing agreement covers the contractual side.
FAQ
Common questions about sub-processors
What is a sub-processor in data protection?
A sub-processor is a third party that a data processor brings in to help carry out the work it does on a controller's behalf, and that handles personal data in the process. If you are the customer (the controller) and your supplier is the processor, then the suppliers your supplier relies on, such as its cloud host or its email-sending provider, are the sub-processors. They sit one rung further down the chain but still touch the data, so they have to be named, contracted and watched.
What is the difference between a processor and a sub-processor?
A processor handles personal data directly for the controller under the controller's instructions. A sub-processor handles that same data for the processor, one step removed from the controller. The relationship is a chain: controller, then processor, then sub-processor. Under UK GDPR the processor stays fully responsible to the controller for what its sub-processors do, which is why a processor needs the controller's permission before it adds or swaps one.
Why does a published sub-processor list matter?
A published list lets a customer see exactly which other companies will touch their data before they sign, and check it stays acceptable over time. It is the practical way a processor meets its UK GDPR duty to be transparent about the chain and to give notice of changes. Without one, you are trusting a supplier with your customers' personal data while having no idea who sits behind it. A clear, dated list is a sign a supplier takes the chain seriously.
Do I need to be told before a new sub-processor is added?
You should be. UK GDPR requires a processor to have the controller's authorisation for sub-processors, and to give the controller a chance to object to changes. In practice many suppliers publish their list and commit to giving notice before a new sub-processor goes live, so customers can review the change and raise concerns. The notice period and objection process should be set out in the data processing agreement, not left to chance.
Which sub-processors does Solves use?
Solves keeps the chain short and names it. Postmark handles transactional email delivery so replies and notifications reach inboxes. Stripe handles billing and card payments, so card details never touch Solves directly. A UK or EU cloud host runs the application and database. The current, dated list, with what each provider does and where it is based, lives on the sub-processors page, and the data processing agreement page covers the contractual side.
See who sits behind Solves
The full, dated sub-processor list names each provider, what it does and where it is based. The data processing agreement covers the contract.