What is a subprocessor?

A subprocessor is another processor that your business engages to carry out some of the personal-data processing you perform on a customer's behalf. If you process a customer's personal data on their instructions and engage a database provider to store those records on your behalf, the provider acts as your subprocessor for that storage.

The term is also written “sub-processor”. GDPR describes the relationship as a processor engaging “another processor” in Article 28(4)⁠ (opens in a new tab).

When a customer asks for your list, the task is to identify which providers carry out that work. Hosting, email and support services are useful places to look, but their role depends on what they do with the data.

This guide explains the EU/EEA GDPR framework. Other European jurisdictions have their own rules, so check the framework that applies to your business.

What counts as processing personal data?

Personal data is information about an identified or identifiable person, including ordinary details such as their name, a work email address that identifies them or account details linked to them. It doesn't have to be sensitive information.

Processing includes storing, retrieving, using, sharing and deleting that information. A database provider that only stores the records is still processing them; it doesn't need to read or analyse them for storage to count. These definitions come from GDPR Article 4(1) and (2)⁠ (opens in a new tab).

That makes the activity and the data a useful starting point when reviewing suppliers. A company name tells you who you pay; describing what the service does with personal data helps you work out its role.

Controller, processor and subprocessor: who does what?

The controller decides why personal data is processed and makes the essential decisions about how it happens. The processor is a separate organisation or person that processes it on the controller's behalf. A subprocessor performs some of that work for the processor. The controller and processor definitions are in GDPR Article 4(7) and (8)⁠ (opens in a new tab).

Imagine a software company considering Komplya to help maintain its subprocessor list. Alex, an employee responsible for reviewing the list, would use Komplya on the company's behalf. Alex's name and work email address are personal data, even though the account is for work.

For this hypothetical example, assume the company decides that Alex needs an account, which account details are used, who can access them and how long they are kept. Komplya handles those details only on the company's instructions to provide that access, and engages a hosting provider to store them on Komplya's instructions. These assumptions illustrate the roles; they do not describe a live customer arrangement or name Komplya's actual providers.

For that account-data processing, the relationship looks like this:

Company (controller)
       ↓
Komplya (processor)
       ↓
Hosting provider (subprocessor)

Alex is the data subject: the person the account details relate to, as defined in GDPR Article 4(1)⁠ (opens in a new tab). The company is Komplya's customer in this example, while Alex is the user acting for it. The hosting provider is Komplya's subprocessor because it carries out part of the processing Komplya undertakes for the company.

Choosing the software or hardware used to deliver the service can remain Komplya's responsibility as a processor. The company still decides the purpose and essential means of processing, while Komplya makes implementation choices within those instructions. The European Data Protection Board (EDPB) explains the distinction in Guidelines 07/2020, paragraph 40⁠ (opens in a new tab), and the processor's discretion within the controller's instructions in paragraph 80⁠ (opens in a new tab).

The same business can have different roles

Now consider a separate hypothetical activity: Komplya maintains its own marketing mailing list and decides which campaigns to send. For that processing, Komplya acts as a controller.

An email provider sending those campaigns only on Komplya's instructions is its processor for that activity. This relationship concerns Komplya's own marketing purposes, separately from handling Alex's account details for the company.

When building your subprocessor list, distinguish services handling data on your customers' behalf from services processing data for your own purposes. The EDPB explains how an organisation can have different roles for different activities in paragraph 82⁠ (opens in a new tab).

Because roles follow actual activities, a contract calling a supplier a “processor” cannot override a different relationship in practice. See EDPB Guidelines 07/2020, paragraph 12⁠ (opens in a new tab) on actual roles and paragraphs 28–29⁠ (opens in a new tab) on contractual labels.

Does every supplier belong on the subprocessor list?

For your subprocessor list, look for separate parties carrying out part of the processing you perform for a customer. Paying for a tool is not the test; the processing relationship is.

Alex's work reviewing the company's list does not make Alex a processor or subprocessor. An employee working under the company's direct authority acts as part of that organisation. The EDPB sets out the separate-entity test in paragraph 76⁠ (opens in a new tab) and explains the position of employees in paragraph 78⁠ (opens in a new tab).

Two businesses can instead act as independent controllers for their respective activities. Where each business determines its own purposes and means, sharing data between them is a transmission between separate controllers: paragraphs 69–72⁠ (opens in a new tab) explain situations involving separate controllers.

If the businesses jointly determine the purposes and means of the same processing, they are joint controllers for that processing; see paragraph 51⁠ (opens in a new tab).

In the account example, the hosting provider belongs on Komplya's subprocessor list for its storage of the company's employee account details. When reviewing another supplier, check the service you use, the information involved, its purpose and the supplier's terms against that same relationship test.

Why your customer needs to know

The company needs to understand which other organisations participate in handling Alex's account details, even if Alex only interacts with Komplya. GDPR Article 28 sets conditions for engaging them: prior specific or general written authorisation, a binding processing agreement and relevant data-protection obligations passed down to the subprocessor. Under general authorisation, intended additions or replacements must be communicated so the controller has an opportunity to object. See Article 28(2)–(4)⁠ (opens in a new tab).

Keeping a subprocessor list accurate helps you communicate these relationships, alongside the contracts and authorisation process.

Work out a supplier's role

To apply the distinction to a service your business uses, answer these questions:

1. What personal data does it handle, including storage or access?
2. What activity does it perform, and for what purpose?
3. Who decides that purpose and the essential processing arrangements?
4. Are you handling this data for your own purposes or on a customer's behalf?
5. Which separate organisations carry out part of that work?

Record the answers and any missing information so a colleague can follow your reasoning. For the hosting provider in the Komplya example, the explanation could be: “Stores employee account details so we can provide access to Komplya on our customer company's instructions.”

Check that description against the contract and your actual setup before using it to explain the supplier's place on the list.

Making the research easier

Provider documents explain the services and terms, while your team supplies the context: what you send to a service, why you use it and whose purposes it serves.

We are building Komplya to bring together provider research and explained suggestions, helping teams review which services belong on their subprocessor list and keep the information current. The planned approach combines provider details with how you use a service, so you can make an informed decision and choose what to publish.

See the planned Komplya workflow for provider research, review and publication.