GDPR compliance guide for SaaS startups

Do you need to comply with GDPR?

GDPR applies to you if you process personal data of EU or UK residents, regardless of where your company is incorporated. If you have EU users, EU employees, or process EU customer data (including B2B — employee emails count as personal data), GDPR applies.

The UK has its own version of GDPR (UK GDPR) that is almost identical to EU GDPR post-Brexit. If you have UK users, you need to comply with both.

Common misconception: you don't need to be a European company or have a European office for GDPR to apply. A US-based SaaS with EU customers must comply.

Lawful basis for processing

Every piece of personal data you process must have one of six lawful bases. For SaaS companies, the most common are:

Contractual necessity: Processing is required to deliver the service the user signed up for. Login data, billing data, and usage data for operating the product are typically covered here.

Legitimate interests: Processing is in your legitimate business interest and doesn't override the individual's rights. Marketing analytics, security monitoring, and fraud detection often fall here. Requires a Legitimate Interests Assessment (LIA) to document.

Consent: The user has explicitly opted in. Required for non-essential cookies, email marketing, and tracking pixels. Consent must be freely given, specific, and withdrawable.

Document your lawful basis for each data type in your Record of Processing Activities (ROPA). Regulators ask for this.

Data Processing Agreements (DPAs)

A DPA is a contract required by GDPR when you share personal data with a third party that processes it on your behalf. Every SaaS tool in your stack that touches EU personal data needs a signed DPA.

Common vendors requiring DPAs: AWS, Google Cloud, Azure, Stripe, Intercom, HubSpot, Salesforce, SendGrid, Slack (for EU employee data), any analytics tool that receives user data.

Your own customers need a DPA with you if you process their employees' or users' data as a data processor. Include a DPA in your standard subscription agreement or make one available on request.

Sub-processor DPAs: If you share data with a third party, you need to list all sub-processors in your DPA with your customer and notify them of changes.

Record of Processing Activities (ROPA)

ROPA is a register of every data processing activity your company performs. It's required by GDPR Article 30 for companies with 250+ employees or that process sensitive data or process data regularly that could risk rights and freedoms of individuals. In practice, regulators expect it from any serious business.

Each ROPA entry should include: type of personal data, categories of data subjects (users, employees, leads), purpose of processing, legal basis, retention period, who you share it with, and security measures.

Your ROPA doesn't need to be fancy — a Google Sheet works. The key is having it and keeping it current. Regulators have requested ROPAs from companies in breach investigations before they've issued fines. Not having one is an aggravating factor.

Data Subject Rights

GDPR gives individuals eight rights over their data. You must have processes to fulfill each:

Right of access (Subject Access Request / SAR): Individuals can request a copy of their personal data. You have 30 days to respond (extendable to 90 days for complex requests). Build a process — even a manual one — before you receive your first request.

Right to erasure: Individuals can request deletion of their data. You must delete it unless you have a legitimate reason to retain it (e.g., legal obligation). Document your exceptions.

Right to rectification: Individuals can request correction of inaccurate data. Your product should ideally allow users to update their own data.

Right to portability: Individuals can request their data in a machine-readable format. For SaaS, this means being able to export a user's data as CSV or JSON.

Right to object: Individuals can object to processing based on legitimate interests or for direct marketing. For marketing emails, this is typically handled via unsubscribe links.

Breach notification requirements

Under GDPR, a personal data breach must be reported to your lead Data Protection Authority (DPA) within 72 hours of discovery if it's likely to risk individuals' rights and freedoms. This is a tight window — you need a process in place before a breach happens.

Reporting threshold: not all breaches require reporting. A breach affecting a single employee's name and email with low risk of harm may not require notification. A breach exposing payment data, health records, or credentials requires notification.

Individual notification: if the breach is likely to result in high risk to individuals, you must also notify the affected individuals "without undue delay."

What to have in place: an internal incident log, a decision tree for assessing whether notification is required, and the contact details for your lead DPA (based on your EU establishment or where most of your EU customers are).

Privacy by Design

Privacy by Design means building privacy into your product architecture from the start, not bolting it on after. GDPR requires it explicitly in Article 25.

Practical implementations: data minimization (don't collect fields you don't need), access controls that limit who can see personal data, data retention automation (delete data after the retention period expires), pseudonymization of personal data in non-production environments.

For engineering teams: personal data should not appear in application logs. Logs are often widely accessible and rarely deleted on schedule — they become a compliance liability. Use structured logging with PII masking or hashing.

Cookie consent: if you run analytics, advertising pixels, or session recording tools, you need a cookie consent mechanism that doesn't load non-essential cookies until the user opts in. This is one of the most commonly fined areas by the French DPA (CNIL) and the Irish DPC.