Is your SMS provider a data processor?

In the usual set-up, yes. When a business uploads its customers' numbers to an SMS provider and tells it what to send and when, the business is the controller and the provider is a processor. Article 4(8) of the UK GDPR defines a processor as a person or body "which processes personal data on behalf of the controller", and article 28 then says what has to be in writing between the two: a contract covering eight specific terms, plus rules about who else the provider may hand the data to. The ICO's guidance on contracts, under review since the Data (Use and Access) Act 2025 but current, walks through every one of them.

It's easy never to read that contract. It's usually a data processing agreement linked from the provider's terms, accepted with a tick when the account was opened. That's allowed (article 28(9) says the contract "shall be in writing, including in electronic form"), but it's still the document that decides what happens to your customer list, so it repays ten minutes.

Who decides what?

The ICO's guidance gives the dividing line as a set of decisions. Whoever decides "to collect personal data in the first place", "the purpose or purposes the data are to be used for", "which individuals to collect data about", "what to tell individuals about the processing" and "how long to retain the data" is likely to be a controller. A processor, within the terms of its contract, may decide things like "what IT systems or other methods to use", "how to store the personal data" and "the details of the security measures".

Map that onto texting and the roles fall out quickly. You choose the list, write the message, pick the time and decide who gets left off. The provider chooses its servers, its routes to the networks and its security set-up. The ICO's closest example is a gym that gives a printer its members' names and addresses to print event invitations: the gym "is the controller" and "The printing company is a processor processing the personal data only on the gym's instructions." Swap envelopes for texts and that's the relationship.

Two caveats. The ICO says "an organisation is not by its nature either a controller or a processor", so the label attaches to each activity, not to the company. And article 28(10) says a processor that starts "determining the purposes and means of processing" becomes a controller for that processing. A provider that used your customers' numbers to market its own services, for instance, would be acting as a controller of that data, with all the duties that brings. The marketing rules run on a separate track: who counts as the sender of a marketing text under PECR is covered in our guide to SMS marketing rules, and the short version is that the business instigating the texts stays responsible.

What does the contract have to say?

Article 28(3) requires the contract to set out "the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller". For an SMS account that's a short paragraph: mobile numbers, names and message content for the customers you choose to text, processed to send texts and receive replies, for as long as the account is open.

Then come the eight terms. Here they are with what each one means for a texting account.

The ICO adds detail on several of these. An instruction "can be documented by using any written form, including email", so the settings you choose in the dashboard and the sends you schedule count. On the end of the contract, it accepts that "it may not be possible for data in backups or archives to be deleted immediately", provided the data is "put immediately beyond use" and deleted on the processor's next cycle. And it recommends "that the contract is as clear as possible about how the processor will help the controller" with breaches. Article 33(2) already obliges a processor to "notify the controller without undue delay after becoming aware of a personal data breach"; a contract that says how and to whom makes that real. (What you then owe your own customers is in our post on telling customers about a data breach.)

What about sub-processors?

Texts don't go straight from a provider's server to a phone. Somewhere along the line there's a hosting company, often another messaging company (an SMS aggregator), and the mobile networks at the end. Our guide to how business texts reach UK phones maps the route.

Article 28(2) controls who else gets your data: "The processor shall not engage another processor without prior specific or general written authorisation of the controller." Most providers ask for general authorisation, which is fine, but it comes with a condition: the processor "shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object". In practice that means a published list of sub-processors and a way of hearing about changes, usually an email or a page you can watch.

Article 28(4) makes the obligations flow downhill. Each sub-processor must be bound by the same data protection obligations, by contract, and "the initial processor shall remain fully liable to the controller" for a sub-processor that fails. The ICO adds that the wording "do not need to exactly mirror" the main contract, but should offer an equivalent level of protection. For a small business the practical step is knowing that the list exists and who is on it.

Where does the data go?

Sending personal data to an organisation outside the UK is what the ICO calls a "restricted transfer", and its three-step test is simple: the UK GDPR applies to the data, you're initiating the transfer to an organisation outside the UK, and that organisation is a separate legal entity. Letting someone abroad look at the data counts too. The ICO's example is a UK business whose customer service partner in India can access its systems, which meets all three steps even though nothing is sent.

Every restricted transfer needs a mechanism: UK adequacy regulations, appropriate safeguards (such as the ICO's International Data Transfer Agreement, with a transfer risk assessment) or one of the narrow exceptions. Adequacy is the easy one. The ICO's list says "All the countries in the European Economic Area (EEA) have full adequacy", which covers the 27 EU states plus Iceland, Norway and Liechtenstein, and adds full adequacy for places including Guernsey, Jersey, the Isle of Man, Switzerland, New Zealand and Israel. The United States is covered only for transfers under the UK Extension to the EU-US Data Privacy Framework. Since the 2025 Act, the test for adequacy is that protection is "not materially lower" than in the UK.

So the question for a provider is where its servers are, where its sub-processors are, and where its support staff sit when they look at an account. If the answer is the UK or the EEA, there's nothing more to arrange. If it's anywhere else, the contract should say which mechanism covers it.

Can a processor be fined?

Yes, and recently in large amounts. Article 32 puts the security duty on "the controller and the processor" alike, and the ICO has used it against companies that handle data for others.

In March 2025 it fined Advanced Computer Software Group £3,076,320, down from a provisional £6.09m, over a 2022 ransomware attack. The ICO described Advanced as a company that "processes people's personal information on behalf of" the NHS and other healthcare providers. Hackers got in "via a customer account that did not have multi-factor authentication", and the personal information of 79,404 people was taken.

In October 2025 it fined Capita £14m: £8m for Capita plc and £6m for Capita Pension Solutions Limited, which "processes personal information on behalf of over 600 organisations providing pension schemes, with 325 of these organisations also impacted by the data breach." The attack in March 2023 took the personal information of 6.6 million people. Among the lessons the ICO drew for everyone else was "Checking agreements and responsibilities between data controllers and data processors."

Neither fine lets the controllers off. Article 28(1) says a controller "shall use only processors providing sufficient guarantees" of appropriate security, so picking a provider is itself a data protection decision. For a small business that's mostly a matter of asking the right questions and keeping the answers.

Questions to put to an SMS provider

Each of these maps to a line in article 28, and each has an answer you can check in writing.

1. Where is the data processing agreement, and does it cover the details and the eight terms in article 28(3)?
2. Who are your sub-processors, and how will I hear about changes before they happen?
3. Where is my data stored, and from which countries can your staff or sub-processors access it?
4. If you have a breach, how and how quickly will you tell me?
5. How do I get a customer's data out for an access request, and how do I delete it for an erasure request?
6. What happens to my contacts and messages when I close the account, and how long do backups keep them?
7. Do you use my contacts or message content for any purpose of your own?

A provider that answers all seven in a document is doing what article 28 asks.

CaptiFi Connect sends to UK mobiles only, and until a new account is approved a person reads each of its texts before it goes out; contacts and message history export to CSV, which covers a handover at the end of a contract or an access request. How accounts and data are protected is set out on the security page. Whoever you use, the sub-processor list is the line to read first in the paperwork.