GDPR compliance for SaaS: what your EU customers will check.
For a SaaS company the GDPR arrives mostly through customers' contracts. Here is what each role demands, what an EU buyer's privacy team asks for, and the gaps that hold deals up.
Last updated Published by TryTrustableNot legal advice
A B2B SaaS company is usually a processor for its customers' data and a controller for its own: sign-ups, billing, support, marketing and website analytics. As a processor, the GDPR asks for an Article 28 contract (the DPA), Article 32 security, records under Article 30(2), notifying customers of breaches without undue delay, and control of sub-processors. Transfers out of the EU need an adequacy decision or standard contractual clauses. EU customers' procurement teams check all of it before signing.
What applies, and when
The GDPR, Regulation (EU) 2016/679 has applied since 25 May 2018; there is no transition left. It reaches a SaaS company three ways. An EU establishment brings its processing into scope under Article 3(1). Without one, Article 3(2) applies to processing related to offering services to people in the EU or monitoring their behaviour there; the EDPB territorial scope guidelines work through examples. And as a processor for EU customers, the obligations arrive through the Article 28 contract and the transfer clauses they require. The GDPR guide covers scope, representatives and fines in general; this page is about running a SaaS product under it.
| Data | Your role | Main duties |
|---|---|---|
| Data customers upload or generate in the product | Processor | Art. 28 contract, Art. 32 security, Art. 30(2) records, Art. 33(2) breach notice to the customer, sub-processor control, help with rights requests |
| Your customers' users' account data | Usually controller | Lawful basis (Art. 6), notice (Art. 13), rights, retention |
| Website visitors, leads, marketing lists | Controller | Cookie consent under the ePrivacy rules, notice, lawful basis for marketing |
| Product telemetry and logs with personal data | Controller or processor, depending on purpose | Decide, document and limit retention |
Roles are fact-specific. Record your reasoning per processing activity.
What EU customers and regulators look for
Before signing, an EU customer's privacy or procurement team typically asks for:
- A DPA meeting Article 28(3): instructions, confidentiality, security, sub-processors, assistance, deletion or return, audits
- A sub-processor list with each provider's role and location, and how you notify changes under Article 28(2)
- A transfer mechanism for every country data reaches. The adequacy list includes the US for companies certified under the EU-US Data Privacy Framework; elsewhere, including India, the 2021 standard contractual clauses plus a transfer impact assessment
- Technical and organisational measures, usually as Annex II of the clauses: encryption, access control, logging, backups, testing
- Breach notice terms shorter than the controller's 72 hours, and a named contact
- How you help with rights requests: export and deletion that work per user, not a support ticket
A supervisory authority looking at a processor directly asks for the Article 30(2) records, the Article 32 measures and the breach log. Article 83(4) puts processor obligations in the €10 million or 2% tier.
The gaps we see most often in SaaS companies
- A sub-processor list that has not been updated since an analytics, email or AI provider was added
- No mechanism to notify customers of a new sub-processor before it starts processing
- Analytics or session replay in the app firing before consent, for users the company is controller for
- Personal data in application logs and error trackers with no retention limit
- Deletion at contract end that misses backups, logs and sub-processors
- Support staff with standing access to all customer data
- Customer data sent to an AI model provider that the DPA and sub-processor list do not mention
- A transfer impact assessment that the customer asks for and nobody has written
The free cookie scanner shows what fires before consent on your site; the record of processing activities template gives the Article 30 structure.
A realistic timeline
| Step | What it produces | Typical effort |
|---|---|---|
| Map data and roles | Processing activities, roles, systems, sub-processors, locations | Two to four weeks |
| Contract pack | DPA, sub-processor list, transfer clauses, measures annex | Two to six weeks with counsel |
| Engineering | Per-user export and deletion, log retention, consent in the app and site, access controls | One to three months |
| Operate | Records kept current, change notices sent, breach process rehearsed | Continuous |
Planning ranges from typical programmes, not regulatory deadlines. The GDPR already applies in full.
What drives the cost
No regulator publishes a cost. The drivers are whether you need an EU representative under Article 27 (a paid service for most companies), whether your core activities require a DPO under Article 37, legal time for the contract pack and transfer assessments, and engineering time for deletion, export and retention. The ceiling on the other side is Article 83: €20 million or 4% of worldwide turnover for the most serious infringements.
GDPR checklist for a SaaS company
| # | Task | Done when |
|---|---|---|
| 1 | Record each processing activity and your role in it | Article 30(1) and 30(2) records exist |
| 2 | Publish a DPA that covers every Article 28(3) term | Offered as standard, not negotiated from scratch |
| 3 | Maintain a sub-processor list with roles and locations | Matches what is actually connected |
| 4 | Set up change notices for sub-processors | Customers can subscribe and object |
| 5 | Put a transfer mechanism behind every non-EU location | Adequacy, DPF certification or SCCs, with a TIA where needed |
| 6 | Document Article 32 measures as an annex | Encryption, access, logging, backups, testing described truthfully |
| 7 | Commit to a breach notice deadline and rehearse it | Customer notified within the DPA deadline in a drill |
| 8 | Build per-user export and deletion | Works through the product or API |
| 9 | Limit retention in logs, backups and error trackers | Periods set and enforced |
| 10 | Hold analytics and marketing tags until consent | A scan shows nothing non-essential before consent |
| 11 | Check whether you need an EU representative or a DPO | Decision recorded with reasons |
How TryTrustable helps, and what it does not do
- GDPR mapped to shared controls. GDPR requirements sit on the same control set as SOC 2 and ISO 27001 in the compliance programme
- Consent with proof. The consent manager records each choice against the notice version shown, and the cookie scanner shows what loads before consent
- Security evidence from code and cloud. SDK and CI checks plus GitHub, AWS and Google Cloud checks evidence the Article 32 measures you describe
- For the buyer. A public trust page and sealed reports a customer can verify
Note for EU buyers evaluating us: TryTrustable hosts customer data in India (Mumbai) today, which is a transfer to a country without an adequacy decision; an EU region is part of our expansion. The platform does not draft your DPA, choose your lawful basis or sign transfer clauses. TryTrustable does not hold SOC 2, ISO 27001 or ISO 42001 itself yet: all are in progress, as the security page says. Customer data is hosted in India (Mumbai) today; we are expanding to Singapore, the US and the EU.
Sources
- EUR-Lex: Regulation (EU) 2016/679 (GDPR)
- EUR-Lex: Directive 2002/58/EC (ePrivacy)
- EUR-Lex: Implementing Decision (EU) 2021/914, standard contractual clauses
- EUR-Lex: Implementing Decision (EU) 2023/1795, EU-US Data Privacy Framework
- European Commission: adequacy decisions
- EDPB: Guidelines 3/2018 on territorial scope
Checked against these sources in October 2026. Laws, standards and dates change: check the source before you rely on a figure. Not legal, audit or certification advice.
Related audience guides: SOC 2 for AI start-ups · ISO 42001 for AI start-ups · EU AI Act for SaaS · DPDP for SaaS · SOC 2 from India
The things people ask us
Is a SaaS company a controller or a processor under the GDPR?
Both, for different data. For the data customers put into the product you are usually a processor acting on their instructions (Article 28). For your own account, billing, support, marketing and website data you are a controller. Each role has its own duties, and your privacy notice and DPA should say which is which.
What must a GDPR data processing agreement contain?
Article 28(3) lists it: processing only on documented instructions, confidentiality of staff, Article 32 security, the conditions for sub-processors, help with data subject requests and with Articles 32 to 36, deletion or return at the end, and information and audits to demonstrate compliance.
Do we need to tell customers before adding a sub-processor?
Under Article 28(2) you need the controller's prior written authorisation. With a general authorisation, which most SaaS DPAs use, you must inform customers of intended additions or replacements and give them the chance to object. That means a maintained sub-processor list and a way to notify changes.
Can EU customer data be hosted outside the EU?
Yes, with a transfer mechanism. Countries with an adequacy decision, including the US for companies certified under the Data Privacy Framework, receive data freely. India has no adequacy decision, so transfers there rely on the 2021 standard contractual clauses plus a transfer impact assessment.
How quickly must a SaaS processor report a breach?
Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a personal data breach. The controller then has 72 hours to notify its supervisory authority, so customers usually write a shorter deadline, often 24 to 48 hours, into the DPA.
One consent record, one control set.
We show GDPR requirements mapped to the controls you already run for SOC 2, and a consent decision recorded against the notice version the person saw. Thirty minutes.