GDPR for SaaS Companies: Data Processing, Sub-Processors and Privacy by Design
Category: Industry Guides
Date: March 2026
Read time: 11 min read
Tags: GDPR, SaaS, Tech, Compliance
Introduction
GDPR treats SaaS companies differently from most other businesses. A hotel collects guest data for its own purposes. A retailer processes customer orders for itself. But a SaaS company often sits in the middle of two distinct relationships: it collects data for its own marketing and operations, and it processes data on behalf of its customers.
That dual position creates a more complex compliance picture than most founders expect. Get it wrong and you can find yourself liable not just for your own data practices, but for failures in how you handle your customers' customers' data.
This guide is written for SaaS founders, CTOs, and product managers who need a practical understanding of GDPR obligations — without the legal jargon.
Data Processor vs Data Controller: The Critical Distinction
The most important concept to understand is the difference between acting as a data controller and acting as a data processor.
You are a data controller when you determine the purposes and means of processing personal data. When you collect email addresses for your own newsletter, run analytics on your own website, or build a user database for your own product — you are the controller. You decide why and how the data is used.
You are a data processor when you process personal data on behalf of someone else — your customer. If your SaaS product stores, analyses, or manages personal data that belongs to your customer's users, you are processing that data as a processor, under your customer's instructions.
Most SaaS companies are both. You are a controller for your own marketing data and website analytics. You are a processor for the data your customers upload or generate inside your product.
This distinction matters enormously. As a controller, you must have your own lawful basis for processing and issue your own privacy notices. As a processor, you must act only on documented customer instructions, implement appropriate security, assist customers with data subject rights requests, and not use the data for your own purposes.
Confusing the two roles — or treating all your data as if you were only a controller — is one of the most common GDPR mistakes in the SaaS industry.
Data Processing Agreements with Customers
Wherever you act as a data processor, GDPR requires a written contract — known as a Data Processing Agreement (DPA) — between you and the data controller (your customer). This is not optional. Article 28 of GDPR makes DPAs mandatory.
Your DPA must cover:
- The subject matter, duration, nature, and purpose of the processing
- The type of personal data and categories of data subjects
- Your obligations and rights as a processor
- Requirements to process data only on documented instructions
- Confidentiality obligations for all staff who access the data
- Technical and organisational security measures
- Rules around engaging sub-processors (see below)
- Assistance with data subject rights requests
- Assistance with security and breach notification obligations
- Data deletion or return at the end of the contract
- Audit rights for the controller
Many SaaS companies embed their DPA in their Terms of Service or make it available as a separate document for customers to sign. Large enterprise customers will often want to negotiate the DPA directly. Having a well-drafted standard DPA ready — and a process for handling bespoke requests — is a basic commercial necessity.
Sub-Processors and the Vendor Chain
As a data processor, you almost certainly engage other services to help deliver your product. The cloud infrastructure you run on. The database provider. The email delivery service. The support platform. These are your sub-processors — companies that process your customers' personal data on your behalf.
GDPR requires you to:
- Only engage sub-processors with your customer's prior authorisation (either specific or general)
- Impose equivalent data protection obligations on sub-processors via contract
- Remain liable to your customer for any sub-processor failures
In practice, most SaaS companies use a general authorisation model: they publish a list of current sub-processors and notify customers in advance of any changes. Customers can object to new sub-processors (though in practice few do).
Your typical sub-processor chain might include:
- AWS or Google Cloud — infrastructure and storage
- Stripe — payment processing (note: Stripe acts as an independent controller for its own fraud and compliance purposes)
- Intercom or Zendesk — customer support (processes user contact data)
- SendGrid or Postmark — transactional email delivery
- Datadog or Sentry — logging and error tracking (may capture personal data in logs)
- Mixpanel or Amplitude — product analytics
Each of these must have a signed DPA or standard contractual clauses in place. Most major vendors provide these automatically or via their privacy centre. The key discipline is maintaining an up-to-date sub-processor list and ensuring contractual protections are in place before you start sending personal data to a new vendor.
Custodia automatically scans your website and product integrations to identify which third-party processors are active, helping you keep your sub-processor list accurate.
Privacy by Design in Product Development
Article 25 of GDPR requires privacy by design and by default. This means building data protection into your product from the start, not bolting it on after launch.
In practice, privacy by design means:
Data minimisation by default. Only collect the data you actually need. If a field on your signup form is not essential to core functionality, remove it. Defaults should be privacy-friendly — additional data collection should require active opt-in.
Access controls. Implement role-based permissions. Not every team member needs access to every customer's data. Audit logs should capture who accessed what and when.
Encryption at rest and in transit. All personal data should be encrypted in transit (HTTPS/TLS) and at rest. This is now a baseline expectation, not an advanced measure.
Data retention policies. Define how long you keep different types of data and implement automated deletion. Indefinite retention is almost never justified.
Pseudonymisation where possible. Separate identifying data from functional data where technically feasible. Analytics data can often be pseudonymised without losing utility.
DPIAs for high-risk features. A Data Protection Impact Assessment is required before launching processing that is likely to result in high risk — profiling users, processing special category data, large-scale monitoring, or automated decision-making that produces significant effects.
Privacy by design is also good engineering. Systems built with data minimisation in mind are easier to secure, easier to audit, and generate less compliance liability over time.
Cookie Consent and Analytics
Even as a SaaS business, your marketing website collects personal data through cookies and analytics tools. GDPR and the UK PECR require prior, informed, specific, and freely given consent before placing non-essential cookies.
This means:
- Your cookie consent banner must present a genuine choice — accept or reject — before analytics and marketing cookies load
- Pre-ticked boxes are invalid. Default to no consent.
- Visitors must be able to withdraw consent as easily as they granted it
- You must document consent records
Google Analytics 4 is not GDPR-compliant out of the box for EU visitors. You need consent mode configuration, IP anonymisation enabled, and your DPA with Google in place. If you use Facebook Pixel, LinkedIn Insight Tag, or other advertising pixels — each requires separate consent.
Many SaaS founders focus all their compliance energy on their product and overlook the marketing website. Both matter.
User Account Data and the Right to Erasure
The right to erasure — often called the right to be forgotten — is where SaaS products encounter significant engineering challenges.
Under GDPR, data subjects have the right to request deletion of their personal data in certain circumstances. For a SaaS company, this creates complexity:
Whose data is it? If you are a processor, the erasure request should come to the data controller (your customer) who then instructs you. Direct requests from end users present a grey area — you need a documented position on how you handle them.
Hard delete vs soft delete. Most SaaS applications use soft deletes — marking a record as deleted without immediately removing it from the database. This is a valid engineering pattern, but you need a process to ensure soft-deleted data is genuinely purged within a reasonable timeframe. Data that is "deleted" but sits indefinitely in your database does not satisfy erasure rights.
Cascading deletes. Personal data rarely sits in one table. User data propagates through audit logs, analytics events, email records, support tickets, and backup snapshots. Genuine erasure requires identifying all locations where data exists and purging each one.
Backup retention. Data in backups is still personal data. You should document your backup retention period and have a process for handling erasure requests that span backup windows.
Legitimate retention exceptions. Erasure is not absolute. You can retain data where it is necessary for legal claims, contractual obligations, or regulatory requirements. But you must document the justification.
The most defensible approach is to build a dedicated erasure workflow early — ideally before you have significant scale. Retrofitting deletion logic into a complex data model is expensive.
Data Portability Obligations
Article 20 of GDPR gives individuals the right to receive their personal data in a structured, commonly used, machine-readable format — and to transmit it to another controller.
For SaaS companies, this means:
- Building an export function that allows users to download their personal data in a usable format (JSON, CSV)
- The export should cover all data processed based on consent or contract performance (not legitimate interest)
- If technically feasible, you should be able to transmit data directly to another service on the user's request
Data portability requests apply to controllers. If you are a processor, portability obligations fall on your customer. However, building export functionality is good practice regardless — it reduces friction when customers switch providers and demonstrates compliance maturity to enterprise buyers.
Breach Notification Within 72 Hours
If you experience a personal data breach — an unauthorised disclosure, loss, or access to personal data — GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware.
The 72-hour clock starts when a "reasonable degree of certainty" exists that a breach has occurred. It does not start from when the breach actually happened.
As a processor, your primary obligation is to notify the data controller without undue delay. The controller then decides whether to notify the supervisory authority. Your DPA should specify the notification process and timeframe (typically 24-48 hours to allow the controller time to meet their own 72-hour deadline).
As a controller, you must notify the ICO (in the UK) or the relevant EEA supervisory authority if the breach is likely to result in risk to individuals' rights and freedoms. Not every breach requires notification — a lost USB containing encrypted data with no prospect of decryption may not need reporting.
Notifications to individuals are required where the breach is likely to result in high risk to their rights and freedoms.
Practical requirements:
- Maintain an internal breach register — even for incidents that do not require regulatory notification
- Have a documented incident response plan
- Know which supervisory authority you are registered with and how to notify them
- Test your incident response process before you actually need it
EU Data Residency Requirements and Standard Contractual Clauses
Many SaaS buyers — particularly in the public sector, healthcare, and financial services — require that their data is stored and processed within the EU or UK. This has become a significant commercial consideration, not just a compliance one.
If you transfer personal data outside the UK or EEA (including to US-based sub-processors), you need a legal transfer mechanism. The most common options are:
Standard Contractual Clauses (SCCs). The EU has approved updated SCCs (2021) that can be incorporated into DPAs with US processors. The UK has its own equivalent: the International Data Transfer Agreement (IDTA). Most major US cloud providers use SCCs or IDTA to legitimise transfers.
Adequacy decisions. The EU has granted adequacy to a number of countries (Japan, Canada, Israel, and others). The UK has its own adequacy assessments. Transfers to adequacy countries do not require additional mechanisms.
Transfer Impact Assessments (TIAs). Since the Schrems II ruling, organisations must conduct a TIA when relying on SCCs, assessing whether the destination country's laws undermine the protection the SCCs provide. In practice, major US cloud providers publish TIA documentation you can reference.
If you want to offer EU data residency — keeping data on EU-based infrastructure — this typically requires choosing EU regions on AWS, Google Cloud, or Azure and ensuring all your sub-processors also store data in-region. It is a product feature with real engineering cost, but increasingly demanded by enterprise customers.
Privacy Policy Requirements for B2B SaaS
Your privacy policy is a controller obligation. It must be transparent, concise, and written in plain language. For a B2B SaaS, your privacy policy should cover:
- What data you collect and why (broken down by category and purpose)
- The legal basis for each processing activity
- How long you retain each category of data
- Who you share data with (sub-processors, third parties)
- International transfers and the mechanism used
- Data subject rights and how to exercise them
- Your contact details and those of any DPO
- The right to lodge a complaint with a supervisory authority
Many SaaS companies have two distinct audiences: their own website visitors and their customers' users. Consider whether you need separate notices for each — a public-facing privacy policy for your marketing site and a supplementary notice for data processed within the product on behalf of customers.
Your privacy policy should also be a living document. Update it when you add new sub-processors, change your retention periods, or launch new processing activities.
Handling DSARs from End Users vs Business Customers
A Data Subject Access Request (DSAR) gives individuals the right to receive a copy of their personal data, information about how it is used, and details of any automated decision-making.
For SaaS companies, DSARs arrive in two flavours:
Requests from your own users — people who have signed up for your product or marketing. You are the controller. You must respond within one month (extendable to three months for complex requests). You must verify identity, provide a copy of all personal data, and explain the processing.
Requests from your customers' users — people whose data is processed inside your product because your customer loaded it there. You are the processor. Direct requests from these individuals should technically be handled by your customer (the controller). Your DPA should clarify that you will support your customer in responding to such requests — for example, by providing an export of the relevant data on request.
In practice, build a DSAR response workflow with a clear owner and a documented process. Track requests in a register. Do not ignore them — failure to respond is an enforcement trigger.
Custodia's DSAR management tools help teams track, document, and respond to requests within the regulatory deadline.
ICO Registration
In the UK, most organisations that process personal data must register with the Information Commissioner's Office (ICO) and pay an annual data protection fee. The fee is tiered by organisation size:
- Tier 1 (fewer than 10 staff or turnover under £632,000): £40/year
- Tier 2 (fewer than 250 staff or turnover under £36 million): £60/year
- Tier 3 (all others): £2,900/year
Failure to register when required is a criminal offence. Check your registration status on the ICO website and renew annually.
In the EU, there is no equivalent central registration — GDPR abolished the old notification requirements — but some member states have specific requirements. Check the local supervisory authority in any EU country where you are established.
Practical Compliance Checklist for SaaS Companies
Use this as a starting point, not a substitute for professional advice:
Legal foundations
- Identify all processing activities and document the lawful basis for each
- Maintain a Record of Processing Activities (RoPA)
- Appoint a DPO if required (mandatory for large-scale systematic monitoring of individuals or large-scale processing of special category data)
- Register with the ICO (UK) or local supervisory authority
Customer relationships
- Publish a standard DPA and make it available to all customers
- Maintain a list of sub-processors with notification process for changes
- Ensure DPAs or SCCs are in place with all sub-processors
Product and engineering
- Implement cookie consent on your marketing website (genuine reject option, no pre-ticked boxes)
- Build user data export functionality (data portability)
- Build user deletion workflow with cascade to logs, backups, and third-party systems
- Define and implement data retention policies
- Encrypt personal data at rest and in transit
- Implement access controls and audit logging
Policies and processes
- Publish a compliant privacy policy for your marketing site
- Publish or make available a supplementary notice for product data processing
- Document a DSAR response process with ownership and deadlines
- Document a breach response process with notification templates
- Test the breach notification process before you need it
Ongoing monitoring
- Review sub-processor list quarterly
- Conduct DPIAs before launching high-risk features
- Train staff on data protection annually
- Review and update your privacy policy when processing changes
Conclusion
GDPR compliance for SaaS companies is not a one-time project. It is an ongoing operational discipline — one that becomes more manageable when it is built into your product development process and commercial relationships from the start.
The companies that handle this well are not necessarily those with the largest legal budgets. They are the ones that have documented their data flows, put proper agreements in place with customers and vendors, built deletion and export into their product, and created internal processes for responding to incidents and requests.
Run a free scan of your website at app.custodia-privacy.com/scan to identify which third-party processors and trackers are currently active — and whether your consent mechanisms are operating correctly. It takes 60 seconds and requires no sign-up.
This guide is for informational purposes only and does not constitute legal advice. SaaS companies with complex data protection obligations should seek specialist legal or DPO advice.
Top comments (0)