# Privacy law for SaaS builders: GDPR, CCPA, and beyond
A customer emails your support inbox: "Send me all the data you have on me, and delete my account." Your support rep forwards it to engineering. Now someone has to find that person's data across Stripe (payments), Salesforce (CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →), Segment (event tracking), and a Snowflake warehouse feeding your analytics dashboards. This is a Data Subject Access Request (DSAR), and under GDPR you have 30 days to respond. Most mid-market SaaS companies discover, at that moment, that nobody actually knows where all the personal data lives.
This lesson walks through why that happens and how to fix it before the request lands.
GDPR (General Data Protection Regulation) is the EU's data protection law, in force since 2018, enforced by national Data Protection Authorities (DPAs) coordinated loosely under the European Data Protection Board. It applies to any company processing personal data of people in the EU, regardless of where the company is based.
CCPA (California Consumer Privacy Act), amended and expanded by the
Key point for builders: these laws are not the same, but they rhyme. Both give individuals rights over their data. Both require you to know what you hold and where.
Each of these is a technical workflow, not just a legal policy. That's the part non-technical teams underestimate.
Most SaaS products are multi-tenant: one codebase and often one database schemadatabase schemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → serves many customer organizations, with rows tagged by a tenant_id or account_id. This is efficient for engineering but complicates privacy work in two ways.
First, personal data sprawls across systems that don't share a common ID. A user's email might be the key in Salesforce, a customer_id in Stripe, an anonymous user_id in Segment that only later gets identified, and a hashed value in your warehouse for analytics. Answering "what do we know about this person" means resolving identity across all four.
Second, deletion is not simple deletion. Stripe retains transaction records for tax and accounting law reasons (in the US, generally 7 years is a common retention practice; in the EU, national tax codes often require similar periods). You cannot delete a paid invoice just because someone files a GDPR erasure request. GDPR itself carves out this conflict: Article 17(3) allows retention where required by law. So "delete everything" really means "delete or anonymize what you're allowed to, document what you're not."
1. Identify the person. Match the email in the DSAR to internal IDs across Stripe (customer object), Salesforce (contact record), Segment (identified user traits), and warehouse tables (via a resolved identity graph, if one exists).
2. Pull the data. Stripe has an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → for exporting a customer's object and charges. Salesforce exports contact and activity history. The warehouse is the hard part: personal data may be scattered across dozens of tables from years of ad hoc pipelines.
3. Apply exceptions. Financial records tied to tax obligations stay. Anything not legally required to be retained goes.
4. Respond within the deadline. 30 days under GDPR (extendable once by 60 more days for complex requests). CCPA gives 45 days, extendable once by another 45.
5. Log the whole thing. Regulators can ask you to prove you have a process, not just that you handled one request well.
A simple diagnostic before any regulator asks: run this kind of query against your warehouse and see how long it takes, and how many tables you have to touch.
-- crude example: find every table referencing a given user
-- (run against warehouse metadata, e.g. Snowflake's INFORMATION_SCHEMA)
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY ('%email%', '%user_id%', '%customer_id%')
ORDER BY table_schema, table_name;If this returns 60 tables across five schemas with no data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.View full definition → documentation, that's your governance gap. Mature teams solve this with a data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition → (tools like Atlan, Collibra, or open-source OpenMetadata) that tags columns containing personal data (PII, personally identifiable information) and tracks lineage from source to dashboard.
Governance is the set of policies and controls determining who can access what data, for how long, and why. For SaaS specifically, three practical checks matter most:
Data mapping. A living document (not a one-time PDF) listing every system that touches personal data, what it holds, its legal basis for processing (GDPR requires one: consent, contract, legitimate interest, etc.), and retention period. The UK Information Commissioner's Office has a free, practical guide to this: ICO's guide to data mapping.
Retention schedules enforced in code, not policy documents. If your privacy policy says "we delete inactive accounts after 2 years" but no cron job actually does that, you have a compliance gap and a discoverable one in litigation.
Access audits. Regularly review who inside your company (not just external processors) can query raw customer data. A support engineer with unrestricted warehouse access to production PII is a common finding in security reviews and a real GDPR "data minimization" violation (Article 5(1)(c): only process what's necessary).
Knowledge check
1. A SaaS company is based entirely in the US but has customers who are individuals located in the EU. Under GDPR, what determines whether the law applies to this company?
2. Why does a Data Subject Access Request (DSAR) often become a scramble at mid-market SaaS companies, according to the lesson?
3. A company operates only in California and has no EU customers. Why might it still need to think about GDPR-style rights (access, deletion, portability) rather than just CCPA?
4. Select ALL correct answers about the individual rights described in the lesson that create engineering obligations for SaaS companies.
Select all the correct answers.
5. Select ALL correct answers about why privacy laws like GDPR and CCPA are described as 'not the same, but they rhyme.'
Select all the correct answers.
Under GDPR, Stripe and Salesforce are your data processors; you are the data controller (the entity deciding why and how data is processed). You need a Data Processing Agreement (DPA) with each vendor, standard in their enterprise contracts. But the DPA doesn't absolve you: if Salesforce mishandles data because you configured it wrongly (e.g., made a report public), you're still liable to the regulator.
This is why "we use compliant vendors" is not the same as "we are compliant." A 2023 enforcement pattern from EU DPAs: several companies were fined not because their cloud vendor was insecure, but because of their own misconfiguration (public S3 buckets, over-permissive Salesforce sharing rules).
Fines are real and material. GDPR maximum penalties are up to €20 million or 4% of global annual revenue, whichever is higher (this is a legal ceiling, not a typical fine; actual fines vary widely by case and severity, per the European Data Protection Board's enforcement records). CCPA/CPRA fines are lower per violation (roughly $2,500 per unintentional violation, $7,500 per intentional one, as amounts set by California statute, subject to periodic adjustment) but multiply fast at consumer-data scale, since each affected individual can count as a separate violation.
For a data or product leader assessing SaaS privacy readiness, run through: