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.
- Overview
Practical Steps And Common Mistakes
- 1. Define the approval model clearly
- 2. Keep your subprocessor list accurate
- 3. Match the addendum to your DPA
- 4. Pass down the right contractual obligations
- 5. Deal with UK and overseas processing honestly
- 6. Build a realistic objection process
- 7. Align legal drafting with internal ownership
- 8. Avoid overpromising in public-facing materials
- 9. Think about special categories of data and regulated customers
- 10. Review the addendum as your business grows
- Key Takeaways
If you sell software to UK customers, sooner or later someone will ask about your subprocessor addendum. That request often lands just before signature, when the deal team wants to close and nobody wants a privacy argument holding things up. The problem is that many SaaS businesses either treat it like a generic supplier schedule, copy wording from a US template, or forget to line it up with their Data Processing Agreement and actual vendor stack.
Those mistakes can create real friction. A customer may push back because your approval process is unclear, your list of subprocessors is out of date, or your contract says one thing while your privacy notice and security materials say another. This guide explains what a subprocessor addendum is, why UK customers ask for it, what clauses usually matter most, and how to avoid common drafting issues before you sign a contract or spend money on a new provider.
Overview
A subprocessor addendum is the part of your contractual data protection framework that deals with third parties you engage to process personal data on your behalf. For UK SaaS businesses, it usually sits alongside a main services agreement and a Data Processing Agreement, and it should match how your product and supplier chain actually work.
A useful UK-facing subprocessor addendum should clearly explain who your subprocessors are, what they do, how you appoint them, and what protections apply when personal data moves through your vendor stack.
- Define what counts as a subprocessor and distinguish this from ordinary suppliers
- Identify the categories of subprocessors you use, and when possible list current providers
- Set out whether customers get prior notice, a right to object, or both when you add or replace a subprocessor
- Confirm that written terms with each subprocessor impose data protection obligations equivalent to those in your customer DPA
- Explain where personal data may be processed, including any transfers outside the UK
- Describe your process for due diligence, security review, and ongoing oversight of subprocessors
- Make clear what happens if a customer objects to a proposed subprocessor
- Check that the addendum aligns with your privacy notice, security materials, and internal vendor list
What Subprocessor Addendum Means For UK Businesses
For a UK SaaS business, a subprocessor addendum is usually about transparency, control, and consistency. Customers want to know which third parties handle their data and what contractual protections sit behind those arrangements.
Under UK data protection rules, a processor generally cannot appoint another processor without the controller's prior specific or general written authorisation. In practical terms, that means your customer contract needs a clear mechanism covering subprocessor appointments if you process personal data for customers.
What is a subprocessor?
A subprocessor is usually a third party that processes personal data on behalf of you, where you are already processing that data for your customer. In a typical SaaS model, your customer is the controller, you are the processor, and your cloud host, support tool provider, analytics platform, or email delivery service may be a subprocessor if they process customer personal data for your service.
Not every supplier is a subprocessor. A payment provider you use for your own billing, a corporate accountant, or a contractor working only on your internal business systems may not fall into that category for customer data processing purposes. This is where founders often get caught, because they either over-list ordinary suppliers or miss suppliers who do handle in-scope customer data.
Why customers ask for a separate addendum
Many enterprise customers, public sector bodies, and security-conscious SMEs want a separate subprocessor schedule because it gives them cleaner visibility. It can be easier to review than searching through a DPA for scattered clauses about approval, notice, and overseas transfers.
It also helps procurement teams compare your process against their internal standards. If your customer has to report to legal, privacy, or security teams before signing, a well-drafted addendum often shortens the back and forth.
How it fits with your other contracts
Your subprocessor addendum should not sit in isolation. It usually interacts with several other documents, including:
- your main SaaS terms or master services agreement
- your Data Processing Agreement
- your privacy notice or privacy policy
- your information security schedule or security FAQs
- your internal vendor register and procurement process
The legal risk is not just weak wording. The bigger operational risk is inconsistency. If your DPA promises prior notice of every new subprocessor but your customer success team cannot actually give that notice, you have created a contractual promise your business may struggle to meet.
What UK customers usually care about most
Most customers are not looking for perfection. They want a workable process and a supplier that knows where data goes.
The issues that usually matter most are:
- whether subprocessors are clearly identified
- whether the customer gets notice before changes
- whether they can object on reasonable grounds
- whether there are proper written terms with each subprocessor
- whether international transfers are dealt with lawfully
- whether security expectations are passed down the chain
If your product handles sensitive employee, health, children’s, or financial data, expect more scrutiny. In those deals, your customer may want tighter approval rights, more detailed security language, or named subprocessors rather than broad categories only.
When This Issue Comes Up
The subprocessor question usually comes up when your sales process becomes more mature, not when you first launch. It tends to appear when customers start doing proper procurement reviews or when your own vendor stack becomes more complex.
Before you sign a customer contract
This is the most common moment. A customer sends over its procurement pack, asks for your DPA, and then asks whether you use subprocessors. If your answer is informal or inconsistent, the deal can slow down fast.
Typical trigger points include:
- enterprise procurement questionnaires
- public sector or education tenders
- security reviews before onboarding
- requests for a vendor risk assessment
- customer redlines on your DPA
If your team is still answering these requests manually from memory, that is usually a sign you need a cleaner subprocessor position.
When you add a new vendor to your tech stack
A new hosting provider, support platform, AI service, CRM integration, or email tool can affect your customer commitments. Before you spend money on setup or switch suppliers, check whether that vendor will process customer personal data and whether your existing contracts let you appoint them.
This matters particularly where your contracts give customers prior notice or a right to object. If you onboard the vendor first and think about the paperwork later, you may create a breach risk.
When customers ask about international transfers
Subprocessor addendums often become a bigger issue where data leaves the UK. Customers may ask not only who your subprocessors are, but where they are based, where they access data from, and what transfer mechanism you rely on.
If your vendor stack includes providers in the US or elsewhere outside the UK, your addendum should not pretend everything is processed locally if it is not. The better approach is to be accurate, clear, and consistent with the transfer arrangements in your DPA.
When your business moves upmarket
Early-stage SaaS founders often get away with light-touch customer terms. Once you start selling into larger organisations, regulated sectors, or procurement-led buyers, that changes. A subprocessor addendum becomes part of your standard legal pack, much like your customer terms, privacy documents, and security responses.
This is also the point where contract hygiene matters more generally. Businesses that want to scale in the UK should have a sensible legal setup around business structure, trade mark protection, staff and contractor contracts, privacy compliance, and customer agreements. Your subprocessor approach sits inside that bigger picture of being ready for due diligence and larger deals.
Practical Steps And Common Mistakes
The best subprocessor addendums are operational documents as much as legal ones. They work because they reflect your real supplier chain, your internal approval process, and the way your product handles data.
1. Define the approval model clearly
Your contract should say whether the customer gives specific authorisation for each named subprocessor, or general authorisation subject to notice of changes. In the SaaS market, general authorisation with advance notice and a limited right to object is often the most workable model.
If you use general authorisation, spell out:
- how notice will be given
- how much notice the customer gets before the change takes effect
- what grounds count as a valid objection
- what happens if the objection cannot be resolved
A common mistake is promising an unrestricted right for the customer to veto any new subprocessor for any reason. That can make your business hard to operate. Another common mistake is offering no meaningful objection process at all, which many customers will reject.
2. Keep your subprocessor list accurate
If you attach a schedule of current subprocessors, make sure it is correct on the day you send the contract. The list should usually include the provider name, the service they provide, and the location or processing region at a practical level.
Founders often copy an old vendor list without checking whether the providers still have access to customer personal data. They also forget tools used by support, logging, infrastructure monitoring, or error tracking teams. Those omissions can create credibility issues when customers compare your contract against your security or technical documentation.
3. Match the addendum to your DPA
Your subprocessor addendum and Data Processing Agreement should tell the same story. If one document says subprocessors may only be used with prior written consent and the other says you can add them on notice, expect redlines.
Check for consistency on:
- definitions of controller, processor, and personal data
- security commitments
- audit or information rights
- international transfer wording
- liability and termination consequences
This is especially important if you have built your legal pack from more than one template source.
4. Pass down the right contractual obligations
Your customer wants comfort that your subprocessors are not operating on looser terms than you agreed with the customer. Your subprocessor contracts should therefore include appropriate written obligations on confidentiality, security, assistance, deletion or return of data, incident cooperation, and any transfer requirements that apply.
You do not usually need to mirror every customer clause word for word. But the overall protection level should be equivalent in the areas that matter most for processor-to-processor arrangements.
A common drafting error is using only a vendor’s click-through terms and assuming they are enough. Sometimes they are not, especially for larger customers or higher-risk data sets. You may need a negotiated supplier DPA, extra security terms, or a transfer mechanism.
5. Deal with UK and overseas processing honestly
If personal data is processed outside the UK, say so accurately and make sure the underlying transfer arrangements are addressed in your wider data protection documentation. Customers are usually more concerned about surprise than location alone.
Your wording may need to cover:
- where a subprocessor is established
- where support staff can remotely access data
- whether data is hosted in one region but backed up in another
- what transfer safeguard is used where required
A frequent mistake is listing a provider as UK-based because your account manager is in London, even though the provider stores or accesses data elsewhere.
6. Build a realistic objection process
A customer objection clause should be usable in practice. The usual approach is to require the customer to object in writing on reasonable data protection grounds within a set period after notice.
If that happens, your contract might allow the parties to discuss an alternative, suspend the affected feature, or as a last resort let the customer terminate the impacted service. The key is to avoid promising outcomes your business cannot operationally deliver.
The main risk is vague wording. If the contract says the customer may object, but says nothing about timing, reasons, or consequences, the issue often resurfaces during a live supplier change when everyone is under pressure.
7. Align legal drafting with internal ownership
A good addendum fails quickly if no one internally owns it. Decide who updates the subprocessor list, who approves new vendors, who sends customer notices, and who checks whether the vendor handles customer personal data at all.
Useful internal controls often include:
- a vendor onboarding checklist
- a central subprocessor register
- legal or privacy review before procurement sign-off
- product and engineering input on data flows
- a process for notifying customers where required
For smaller teams, this does not need to be heavy. It does need to be clear.
8. Avoid overpromising in public-facing materials
Some SaaS businesses publish a subprocessor page or summary list as part of their privacy and security materials. That can be helpful, but the wording must match your contracts.
If your public materials say you will always give 30 days’ notice of every change, your legal documents and internal systems should support that. The same point applies to statements about local hosting, encryption, and access controls.
9. Think about special categories of data and regulated customers
If you sell into healthcare, education, HR tech, fintech, or other sectors handling more sensitive information, your subprocessor terms may need more detail. Customers may ask for stricter due diligence, named approvals, or more information about security and incident handling.
That does not always mean agreeing to bespoke terms for every customer. It may mean having a stronger standard position for higher-risk use cases and knowing where you can negotiate.
10. Review the addendum as your business grows
Your first customer version will not be your last. New products, new regions, AI features, acquisitions, and changes to your infrastructure can all affect the accuracy of your subprocessor wording.
Set a regular review point, especially before major fundraising, procurement pushes, or expansion into more regulated customer segments. Buyers and investors often look for signs that your contracts, privacy position, and supplier management practices line up.
FAQs
Do all SaaS businesses need a subprocessor addendum?
Not always as a standalone document, but most SaaS businesses that act as a processor for customer personal data need clear contractual wording about subprocessors somewhere in their legal pack. A separate addendum is often helpful when customers want visibility and a cleaner approval process.
What should be listed in a subprocessor schedule?
Usually the provider name, the service they perform, and the relevant processing location or region. Some businesses also include the purpose of processing or categories of data where that helps explain the setup.
Can a customer refuse a new subprocessor?
That depends on the contract. Many agreements allow objections on reasonable data protection grounds within a notice period, rather than giving an unlimited veto. The consequences should be clearly stated in the contract.
Is a cloud hosting provider always a subprocessor?
Often yes, if it processes personal data you handle for customers as part of delivering your SaaS service. But classification depends on the actual role the provider plays and whether it processes in-scope customer personal data on your behalf.
Does a subprocessor addendum need to deal with overseas transfers?
Usually yes, at least at a high level where relevant. If your subprocessors store or access customer personal data outside the UK, your wider data protection documents should explain the applicable transfer arrangements and your addendum should not contradict them.
Key Takeaways
- A subprocessor addendum helps UK SaaS businesses explain how third party providers process customer personal data and what approval process applies.
- The document should align with your Data Processing Agreement, customer contract, privacy materials, and real vendor stack.
- Customers usually focus on notice of changes, objection rights, equivalent contractual protections, security standards, and overseas processing.
- Common mistakes include outdated subprocessor lists, vague objection clauses, inconsistent drafting, and overpromising on notice or approvals.
- The best approach is practical and operational, with clear internal ownership for vendor review, contract updates, and customer communications.
If your business is dealing with a subprocessor addendum and wants help with Data Processing Agreements, supplier contracts, customer SaaS terms, or privacy compliance, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.








