GDPR for B2B SaaS: Getting the Processor Side Right
If you sell software to other businesses, most of the personal data in your product belongs to your customers: their staff, their clients, their contacts. For that data you are usually a processor acting on their instructions, while for your own sign-ups, billing and marketing you are a controller.
Customers, and their procurement teams, will expect a data processing agreement, a list of sub-processors, ways to export and delete data, and a clear promise about breaches. This guide sets out what a small SaaS company needs to put in place, in the product and on the website, to meet those expectations under the UK GDPR.
Before you start: this is not legal advice
This guide describes common, practical ways for a small software company to meet its UK GDPR duties as a processor. It is not legal advice. Contract terms such as liability caps, indemnities and audit rights are commercial and legal decisions, and a customer with a regulated or sensitive use case, such as healthcare or financial services, may need more than a standard set of terms. Take advice from a solicitor or data protection specialist before finalising your agreement, and read the ICO's guidance on controllers and processors.
If you also sell to customers in the European Union, the EU GDPR applies alongside the UK rules and may require extra steps, such as an EU representative in some cases. The Data (Use and Access) Act 2025 amends the UK regime in stages, so check the ICO's current guidance on any point that matters to you.
Your two roles, data by data
The same company can be controller for some data and processor for other data. Splitting it clearly is the foundation for everything else, because it decides which privacy notice, which agreement and which process applies.
| Data | Your usual role | Covered by |
|---|---|---|
| Records your customers upload or create in the product, such as their clients, contacts, tickets or files | Processor | Your data processing agreement with each customer |
| Account holders' names, emails and login details | Usually controller for running the account; processor where the customer administers its users | Your privacy notice, and the DPA where relevant |
| Billing contacts and invoices | Controller | Your privacy notice |
| Marketing site visitors, trial sign-ups and newsletter subscribers | Controller | Your privacy notice and cookie consent |
| Product usage analytics and logs | Depends on what they contain and how you use them | Decide deliberately and state it in both documents |
| Support conversations | Often processor for customer data shown in the ticket, controller for the conversation record | Both, described clearly |
What customers look for in your DPA
Your agreement must include the terms in Article 28(3) of the UK GDPR, and customers' reviewers will check for them. In practice they also look at a few points where agreements differ:
- A description of the processing. An annex listing the categories of data and people, the purpose, the duration and the nature of the service. Make it specific to your product rather than a copy of a generic template.
- Breach notice timing. The law says without undue delay. Customers often ask for a specific number of hours so they can meet their own 72-hour deadline to the ICO. Only promise what your team can actually deliver.
- Audit approach. Most small vendors meet the audit duty by providing security documentation, answering questionnaires and offering a call, with on-site audits limited to reasonable notice and frequency.
- End of contract. How long after termination customer data is deleted, how customers can export it before then, and how long it stays in backups.
- Sub-processor changes. How much notice you give and what happens if a customer objects.
- International transfers. Which safeguards apply when data leaves the UK, and the EU standard contractual clauses where you serve EU customers.
Publish the agreement on a web page and let customers accept it through the order form or the terms of service, so small customers do not need to negotiate. Keep a signable PDF for larger customers whose procurement process requires one.
The fix, step by step
Step 1
Map where you are controller and where processor
List every category of personal data your company touches, from customer records in the product to billing contacts, trial sign-ups, logs and support tickets. For each, write down whether you decide the purpose or follow the customer's instructions. Pay special attention to usage analytics and logs, which often contain customer data. Use the result to shape both the customer agreement and your own privacy notice, so the two documents never contradict each other.
Step 2
Publish a DPA customers can accept
Draft
an agreement that covers every Article 28 term and describes your actual product in an annex: data categories,
purposes, duration and security measures. Publish it at a stable address such as example.com/legal/dpa,
reference it from your terms of service and order forms, and keep a version history with dates. Prepare
a signable copy for customers who need one, and track which customers accepted which version.
Step 3
Publish and maintain a sub-processor list
List every third party that can access customer data: cloud hosting, database and file storage, email delivery, error monitoring, support tools and any AI or search services. For each, show the purpose and location. Publish the list next to the DPA, offer an email subscription for changes, and give advance notice before adding one, with a clear route for customers to object. Check error-monitoring and logging tools carefully, because they often capture personal data unexpectedly.
Step 4
Build export and deletion into the product
Give account administrators a way to find, export and delete individual records, so they can answer their own users' access and erasure requests without raising a ticket. Offer a full account export in a common format such as CSV or JSON, and a documented deletion process at the end of the contract. State how long data persists in backups after deletion, and make sure it expires on schedule rather than being restored accidentally.
Step 5
Set up breach notice to customers
Write an incident process that includes notifying affected customers without undue delay, since they must decide within 72 hours whether to report to the ICO. Keep an up-to-date list of security contacts for each customer, separate from billing contacts. Prepare a template notice that says what happened, which customers and data are affected, what you have done, and what the customer may need to do, and rehearse the process at least once a year.
Step 6
Settle hosting location and transfer safeguards
Record where customer data is stored and where it can be accessed from, including support staff and sub-processors abroad. If data leaves the UK, identify the safeguard for each route, such as adequacy regulations, the UK extension to the EU-US Data Privacy Framework, or the international data transfer agreement or addendum. State the hosting region in your trust documentation, since many customers ask for it before signing.
Step 7
Fix your own marketing site and sign-up flow
On the public site you are a controller like any other business. Make sure product analytics, advertising pixels and chat widgets wait for consent where required, that trial sign-up forms do not pre-tick marketing boxes, and that your privacy notice covers visitors, trial users and customer contacts. Run the site through the audit and fix what it finds, because a careless marketing site undermines the trust your security page is trying to build.
A sub-processor page that answers the usual questions
Procurement reviewers usually want four things for each sub-processor: who it is, what it does, where the data goes and what safeguard applies. A simple table is enough. The example below is for a fictional scheduling product.
Sub-processors for Rota Harbour (example.com)
Last updated: 1 September 2026. Subscribe to changes: example.com/legal/subprocessors/updates
Provider Purpose Data Location Safeguard
Cloud host Application hosting, database All customer data UK Not a restricted transfer
Email delivery Sending notification emails Recipient names, emails US UK Extension to the EU-US DPF
Error monitoring Diagnosing application errors Limited request data EU UK adequacy regulations
Support platform Handling support tickets Data customers include US International data transfer addendum
We give at least 30 days' notice before adding or replacing a sub-processor.
Customers may object by emailing privacy@example.com within that period.The notice period and objection process are your choice to make in your agreement; the example value is illustrative. Whatever you choose, apply it consistently, because a change made without the promised notice is a breach of your own contract.
Product features that make compliance easier
Customers are controllers, and they need your product to help them meet their own duties. Features that do this also reduce support load and speed up sales reviews.
| Feature | What it helps customers do |
|---|---|
| Record-level search, export and delete | Answer subject access and erasure requests from their own users. |
| Configurable retention | Keep data only as long as their own policy says. |
| Role-based access and single sign-on | Limit who in their organisation sees personal data. |
| Audit logs | See who accessed or changed data, which also helps during a breach investigation. |
| Controlled support access | Support staff see customer data only with permission, for a limited time, and the access is logged. |
| Tenant isolation | Assurance that one customer can never see another's data, which should be tested, not assumed. |
Keeping it right as the product grows
- Add a privacy check to feature design. Any feature that sends customer data to a new service, or uses it in a new way, triggers a review of the sub-processor list, the DPA annex and the privacy notice.
- Keep a trust page. One page linking the DPA, sub-processors, security overview and contact address answers most questions before they are asked.
- Reuse questionnaire answers. Keep a maintained library of answers to common security and privacy questions, reviewed at least yearly.
- Check logs for personal data. Scrub or minimise request bodies and identifiers in logs and error reports.
- Review your own processors. Your suppliers need agreements too; the breach response plan and supplier checks apply to you as a controller as much as to your customers.
For consent on your marketing site, see fixing cookie consent banners and the GDPR Guide.
1. Is a B2B SaaS company a controller or a processor?
Usually both, for different data. For the records your customers put into the product, you are normally a processor acting on their instructions. For your own sign-ups, billing contacts, marketing and the running of your business, you are a controller. Some data, such as product analytics and logs, needs a deliberate decision. Mapping each category of data to a role is the first step, because it decides which documents and duties apply to it.
2. Do I need to publish a data processing agreement?
The law requires a written agreement with each customer for whom you act as processor, and publishing a standard one is the practical way for a small SaaS company to provide it. Customers can accept it through your terms or order form, and larger customers can sign a copy. It must cover the Article 28 terms and describe your actual processing, so review it whenever the product or your sub-processors change.
3. What is a sub-processor list and why do customers ask for it?
It lists the third parties that can access customer data on your behalf, such as hosting, email delivery and support tools, with their purpose and location. Customers need it because, as controllers, they must authorise sub-processors and understand where their data goes. Publishing it with a way to subscribe to changes, and giving notice before adding one, is how most vendors meet the authorisation requirement in their agreements. Keep it accurate, because reviewers compare it with your DPA.
4. How quickly must a SaaS provider report a breach to customers?
The UK GDPR says a processor must tell the controller without undue delay after becoming aware of a breach. It does not set a number of hours for processors, but customers must decide within 72 hours whether to report to the ICO, so they often ask for a specific commitment in the agreement. Promise a time your team can genuinely meet, and keep security contacts for each customer up to date.
5. Can we use customer data to train AI features?
Only with care. Using customer data for your own purposes, such as training models that serve other customers, goes beyond acting on each customer's instructions and may make you a controller for that use. You would need a lawful basis, transparency and, in practice, clear agreement from customers in your terms. Many vendors offer settings to opt in or out. Take advice before launching such a feature, and update your DPA and privacy notice.
6. Do we need to host data in the UK?
No, the UK GDPR does not require UK hosting, but transfers outside the UK need a recognised safeguard, such as adequacy regulations, the UK extension to the EU-US Data Privacy Framework, or the international data transfer agreement or addendum. Many customers prefer UK or EU hosting and will ask where data is stored, so decide your hosting region deliberately, document it, and list the safeguard for every sub-processor outside the UK.
7. How do we help customers with their users' subject access requests?
Build tools so customer administrators can search for, export and delete records about an individual themselves, and document how to use them. Your agreement should commit you to assist with rights requests, and a request that reaches you directly from one of your customer's users should normally be passed to the customer rather than answered by you, since they are the controller. Keep a record of what you forwarded and when.
The GDPR Audit checks what a visitor can see on your public site: the cookie banner, scripts that load before consent, the privacy policy and the routes people have to exercise their rights, with a fix guide for each finding.
Open GDPR Fixes →