If your SaaS product has users in the European Union, you are subject to GDPR. There is no revenue threshold, no user count minimum, no exemption for startups. The regulation applies the moment a single EU resident enters their email into your signup form.
We have built GDPR compliant systems for SaaS companies from pre launch to post Series B. The regulation is dense, but the engineering work is finite and well defined. Here is what you actually need to do.
GDPR in Plain English
The General Data Protection Regulation gives EU residents control over their personal data. Personal data means anything that can identify a person: name, email, IP address, device fingerprint, cookies, behavioral analytics, even a user ID if it links back to a real person.
GDPR requires that you have a lawful basis for processing personal data, that you only collect what you need, that you protect it appropriately, that you give users control over it, and that you report breaches within 72 hours.
Fines go up to 4 percent of global annual revenue or 20 million euros, whichever is higher. Those numbers get attention, but the real risk for most SaaS companies is losing enterprise deals. EU based companies will not sign a contract with a vendor that cannot demonstrate GDPR compliance.
Step 1: Data Mapping
You cannot comply with GDPR if you do not know what personal data you collect, where it lives, and who has access to it. Data mapping is the foundation of everything else.
Document every piece of personal data your system touches. That includes your database, your analytics tools, your email marketing platform, your error logging service, your customer support tool, and your payment processor. For each data point, record:
- What it is (email, IP address, name, etc.)
- Why you collect it (lawful basis)
- Where it is stored
- Who has access to it
- How long you retain it
- Whether it is shared with third parties
This exercise always surfaces surprises. Analytics platforms that store IP addresses you forgot about. Error logging tools that capture full request bodies including personal data. Support tools that retain conversation history indefinitely.
Your system architecture should make data flows explicit and auditable. If you cannot trace where a user's data goes, you cannot comply with GDPR.
Step 2: Establish Lawful Basis
GDPR defines six lawful bases for processing personal data. For most SaaS companies, three matter:
Contract. You need the user's email and name to provide the service they signed up for. This covers most of your core product data processing.
Legitimate interest. You have a reasonable business need to process the data, and it does not override the user's rights. This can cover analytics, fraud prevention, and security monitoring. But you need to document your legitimate interest assessment.
Consent. The user explicitly opted in. This is required for marketing emails, non essential cookies, and any data processing that is not strictly necessary for the service. Consent must be freely given, specific, informed, and unambiguous. Pre checked boxes do not count.
Step 3: Build Consent Management
If you rely on consent for any processing activity, you need a consent management system. This means:
Cookie consent banner that actually blocks non essential cookies until consent is given. Not a banner that says "we use cookies" while loading tracking scripts regardless. The banner must allow granular choices (analytics yes, marketing no) and be as easy to reject as to accept.
Email marketing opt in that is separate from your terms of service acceptance. You cannot bundle consent. A user agreeing to your ToS does not consent to your newsletter.
Consent records stored with timestamp, version of the privacy policy they agreed to, and the specific purposes they consented to. When an auditor or data subject asks, you need to prove when and how consent was obtained.
Step 4: Implement Data Subject Rights
GDPR gives users several rights you must honor, typically within 30 days:
Right of access. Users can request a copy of all personal data you hold about them. You need an export mechanism that generates a machine readable format (JSON or CSV) containing everything tied to their identity.
Right to erasure (right to be forgotten). Users can request deletion of their personal data. This means actually deleting it, not just marking it inactive. This includes backups, logs, analytics data, and data shared with third parties. Build your data architecture with deletion in mind from the start. Retroactively making data deletable is an order of magnitude harder than designing for it.
Right to rectification. Users can correct inaccurate data. Most SaaS products already let users edit their profile, but verify that changes propagate to all systems where that data is replicated.
Right to data portability. Users can request their data in a portable format to take to a competitor. This overlaps with right of access but emphasizes the format must be structured and commonly used.
Right to restrict processing. Users can ask you to stop processing their data while a dispute is resolved. You keep the data but do not use it.
The engineering work here is building an admin tool or automated pipeline that can find all personal data across your systems for a given user, export it, and delete it. If your data lives in 15 different services, this is a significant engineering project. If your architecture is well designed with a single source of truth, it is much simpler.
Step 5: Data Processing Agreements
If you use any third party service that processes personal data on your behalf (and you do: your cloud provider, payment processor, email service, analytics platform), you need a Data Processing Agreement (DPA) with each of them.
Most major SaaS vendors have standard DPAs available. AWS, Google Cloud, Stripe, and similar providers all offer them. Download and execute them. For smaller vendors, you may need to negotiate.
Your DPA needs to specify what data is processed, for what purpose, security measures in place, sub processor lists, breach notification obligations, and data deletion upon contract termination.
Step 6: Security Measures
GDPR Article 32 requires "appropriate technical and organizational measures" to protect personal data. This is deliberately vague, but in practice it means:
Encryption at rest and in transit. Access controls with least privilege. Regular security testing including penetration tests. Incident response procedures. Employee training on data protection. Pseudonymization where feasible, meaning replacing identifying data with tokens so the data cannot be attributed to a specific person without additional information.
Our mobile app security guide covers many of these technical controls in detail if your product includes a mobile component.
Step 7: Breach Notification
If you experience a data breach involving personal data, you must notify the relevant supervisory authority within 72 hours of becoming aware of it. If the breach poses a high risk to affected individuals, you must notify them directly as well.
This means you need breach detection capabilities, an incident response plan that includes GDPR notification procedures, and pre drafted notification templates so you are not writing them under pressure during an active incident.
Common Mistakes SaaS Companies Make
Soft deletes instead of hard deletes. Setting a "deleted" flag is not deletion under GDPR. The data still exists. You need actual removal from your database, and you need to handle cascading references to that data.
Ignoring analytics and logging. Your product database might be GDPR compliant while your analytics platform retains personal data indefinitely. Every system that touches personal data is in scope.
Copy pasting a privacy policy. Your privacy policy must accurately describe your specific data practices. A generic template that does not match your actual processing activities is worse than no policy because it creates documented evidence of misrepresentation.
Assuming US hosting is fine. After the Schrems II decision, transferring personal data from the EU to the US requires additional safeguards. Standard Contractual Clauses (SCCs) are the most common mechanism. Make sure your cloud provider and all sub processors have them in place.
The Cost of Getting It Right
For a typical early stage SaaS company, expect 100 to 300 hours of engineering work to build GDPR compliant data handling, plus $5,000 to $20,000 for legal review of your privacy policy, DPAs, and processing records.
The cost of getting it wrong is significantly higher. Beyond fines, a GDPR violation can block you from the entire EU market and destroy trust with enterprise customers globally.
If you need to build GDPR compliant infrastructure or retrofit an existing product, we handle the full stack development from data architecture to consent management. Get in touch and we will assess your current compliance posture.