Data privacy laws that actually govern your SaaS contracts

GDPR requires that any contract between a controller and a processor include, at minimum (Article 28):

• Subject matter and duration of processing: what data, for how long.
• Sub-processor authorization: the vendor must disclose (or get consent for) any downstream vendors it uses, like AWS for hosting or Twilio for notifications.
• Data subject rights support: the vendor must help the controller respond to access, deletion, and portability requests within statutory deadlines (typically one month).
• Breach notification: the vendor must notify the controller "without undue delay" after becoming aware of a breach, since the controller has its own 72-hour notification clock to the relevant DPA.
• International transfer mechanism: if data leaves the EEA, the contract needs a legal basis such as Standard Contractual Clauses (SCCs), the EU Commission's approved template for cross-border transfers.

Fines under GDPR can reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → up to 4% of global annual turnover or €20 million, whichever is higher. As of 2025, cumulative GDPR fines across the EU are estimated (per the GDPR Enforcement Tracker, a free public database) at well over €5 billion since 2018, with Meta, Amazon, and Google among the largest individual penalties.

Practical tell: if a SaaS vendor's DPA has no SCC reference and the vendor hosts data in the US, that is a transfer mechanism gap. Since the 2020 *Schrems II* ruling invalidated the earlier Privacy Shield framework, SCCs (or the newer EU-US Data Privacy Framework, adopted in 2023) are the main lawful path.

CCPA/CPRA: California's contract-by-another-name approach

The California Consumer Privacy Act (CCPA), later expanded by the California Privacy Rights Act (CPRA) effective 2023, is enforced by the California Privacy Protection Agency (CPPA), the first US regulator dedicated solely to privacy.

CCPA/CPRA does not use "controller/processor" language. Instead: the "business" collects data, and any SaaS vendor is a "service provider" (or, if it uses data for its own purposes, a "third party," which triggers stricter rules).

Contracts with service providers must include:

• A restriction that the vendor uses data only for the purpose specified in the contract, not for its own product improvement or ad targeting unless separately disclosed.
• A prohibition on the vendor selling or sharing personal data as defined by the law (CPRA's definition of "sharing" now explicitly captures cross-context behavioral advertising).
• Audit rights allowing the business to verify the vendor's compliance.
• A requirement that the vendor notify the business if it can no longer meet its obligations.

Practical tell: many SaaS vendors' standard terms say "we may use aggregated data to improve our services." Under CPRA, if that aggregation touches personal data without being properly de-identified per the statutory standard, the clause conflicts with service-provider restrictions. This is one of the most common redline fights in 2026-era SaaS contracts.

Unlike GDPR, CCPA/CPRA also gives California residents a private right of action for certain data breaches, meaning consumers, not just the regulator, can sue. That raises the stakes on the security-related clauses in your DPA (encryption standards, incident response timelines).

LGPD: Brazil's GDPR-inspired law with its own teeth

The Lei Geral de Proteção de Dados (LGPD), in force since 2020, is enforced by Brazil's Autoridade Nacional de Proteção de Dados (ANPD). It closely mirrors GDPR's structure (controller/processor, lawful bases, data subject rights) but with Brazil-specific requirements:

• Processing agreements must specify the legal basis relied on (LGPD has ten legal bases, close to but not identical to GDPR's six).
• The ANPD can impose fines up to 2% of a company's Brazilian revenue, capped at roughly R$50 million (about USD 10 million, estimate, exchange-rate dependent) per violation.
• International transfer rules are still maturing; ANPD has issued standard contractual clauses guidance more recently than the EU, so many vendors' template DPAs lag on LGPD-specific transfer language entirely.

Practical tell: a DPA that addresses GDPR and CCPA in detail but has a single generic line like "we also comply with applicable Brazilian law" is a sign the vendor has not actually built LGPD-specific mechanics. If you have Brazilian customers or process Brazilian employee data, that gap matters.

Reading a DPA like a buyer, not a lawyer

You do not need a law degree to catch the big gaps. Run this checklist on any SaaS vendor DPA:

1. Does it name the applicable laws explicitly (GDPR, CCPA/CPRA, LGPD), or is it vague ("applicable data protection laws")? Vague language often means untested compliance.

2. Is there a sub-processor list, and does the vendor commit to notifying you before adding new ones? (Check if companies like Snowflake, Stripe, or Twilio appear as embedded sub-processors, this is normal, but it must be disclosed.)

3. What is the breach notification window? GDPR pressure pushes vendors toward 24 to 72 hours; anything vague ("promptly") should be flagged.

4. Is there a cross-border transfer mechanism if the vendor's infrastructure sits outside your customers' jurisdiction?

5. Are audit rights real or symbolic? Some DPAs allow audits only via the vendor's own third-party certification (like SOC 2 or ISO 27001) rather than direct inspection. That is common and often acceptable, but you should know which model you are getting.

A useful public reference for benchmarking clause language is the IAPP (International Association of Privacy Professionals) resource center, which publishes free explainers on DPA structure and cross-border transfer mechanisms.

Key Takeaways

• GDPR, CCPA/CPRA, and LGPD do not just impose fines, they dictate specific clauses (sub-processor disclosure, breach notification windows, transfer mechanisms, use restrictions) that must appear inside SaaS DPAs.
• GDPR's Article 28 is the template most global DPAs are built around; look for SCCs or an equivalent transfer mechanism whenever data leaves the EEA.
• CCPA/CPRA reframes the relationship as business/service provider and specifically restricts vendors from using customer data for their own purposes or "sharing" it for behavioral advertising.
• LGPD mirrors GDPR's structure but has its own legal bases and a newer, less mature transfer framework, generic "we comply with Brazilian law" language is a warning sign.
• Non-compliant DPAs are usually spotted through absence, not error: missing sub-processor lists, vague breach timelines, and no named transfer mechanism are the three fastest tells.