GDPR Compliance for SaaS Founders: What You Actually Need to Do

GDPR Compliance for SaaS Founders: What You Actually Need to Do

Most SaaS founders treat GDPR as a legal checkbox. An attorney writes a privacy policy, it goes in the footer, done. This is not GDPR compliance. It is the appearance of GDPR compliance, and the gap between the two is where fines originate.

GDPR (General Data Protection Regulation) applies to any organisation that collects or processes personal data of individuals in the European Union, regardless of where the organisation is based. If you have EU users — or if you process data on behalf of a customer who has EU users — GDPR applies to you.

This guide covers what you actually need to do to comply, not just what you need to say you do.

What GDPR Actually Requires

GDPR is built on a set of principles that govern how personal data must be handled. Understanding these principles is more useful than memorising the regulation's 99 articles, because they tell you why specific requirements exist.

Lawfulness, fairness, and transparency. You must have a legal basis for processing personal data, and you must be transparent about what you are doing with it.

Purpose limitation. Data collected for one purpose cannot be used for a different purpose without further consent or a new legal basis.

Data minimisation. Collect only what you actually need. If an email address is sufficient, you do not need a phone number, date of birth, and postal address.

Accuracy. Keep personal data accurate and up to date. Provide users with mechanisms to correct their data.

Storage limitation. Do not keep personal data longer than necessary for the purpose it was collected for. Define and enforce retention periods.

Integrity and confidentiality. Protect personal data with appropriate technical and organisational security measures.

Accountability. You must be able to demonstrate that you comply with these principles, not just assert that you do.

Step 1: Understand What Personal Data You Collect

Personal data is broader than most founders assume. It includes: names, email addresses, IP addresses, device identifiers, cookies that identify a user across sessions, location data, and any data that can be combined with other data to identify a specific person.

Map your data flows:

• What personal data do you collect? At what touchpoints?
• Where is it stored? Which databases, third-party tools, cloud providers?
• Who has access to it within your organisation?
• What third-party services does it flow to (analytics tools, CRM, support platforms, payment processors)?
• How long do you retain it?

This mapping exercise — sometimes called a Record of Processing Activities (ROPA) — is required by GDPR for organisations of most sizes. It is also the most practical foundation for everything else, because you cannot manage what you have not mapped.

Step 2: Establish a Legal Basis for Each Processing Activity

Every processing activity needs a legal basis. The six options under GDPR:

Consent. The user has given specific, informed, unambiguous, freely given consent. Important: consent must be as easy to withdraw as to give, and pre-ticked boxes are not valid consent.

Contract. Processing is necessary to perform a contract with the data subject. This covers processing user data to provide your service.

Legal obligation. Processing is required by law (tax records, employment records).

Vital interests. Processing is necessary to protect someone's life. Rarely applicable in SaaS context.

Public task. Processing is necessary for a task in the public interest. Not applicable to most SaaS businesses.

Legitimate interests. Processing serves a legitimate interest of your company or a third party, and that interest is not overridden by the data subject's rights. This requires a Legitimate Interests Assessment (LIA) that you document.

Most SaaS processing activities use contract (for service delivery) and consent or legitimate interests (for marketing, analytics, and product improvement). Define the legal basis for each processing activity and document it.

Step 3: Update Your Privacy Documentation

Privacy policy. Must be written in plain language (not just legal boilerplate), cover every processing activity, identify all third parties who receive personal data, explain users' rights under GDPR, and provide contact information for your Data Protection Officer (if you have one) or privacy contact.

Cookie consent. If your SaaS collects cookies that are not strictly necessary for the service, you need granular cookie consent that allows users to accept or reject non-essential cookies before they are dropped. A blanket "we use cookies" banner is not sufficient.

Data processing agreements (DPAs). For every third-party service that processes personal data on your behalf — your cloud provider, analytics tool, CRM, support platform — you need a signed DPA. Most major providers have standard DPAs available; you sign them to formalise the relationship.

Step 4: Build Mechanisms for User Rights

GDPR grants users specific rights that you must be able to honour:

Right of access. Users can request a copy of all personal data you hold about them. You need a process to respond within 30 days.

Right to erasure ("right to be forgotten"). Users can request deletion of their personal data where there is no overriding legal basis to retain it. You need to be able to action this across all your systems and third-party processors.

Right to rectification. Users can correct inaccurate data.

Right to data portability. Users can request their data in a machine-readable format.

Right to object. Users can object to processing based on legitimate interests.

Right to restriction of processing. Users can request that processing be paused while a dispute is resolved.

Building these mechanisms into your product is not optional. A manual process handled by email is acceptable initially, but at scale you need product functionality that allows users to exercise their rights efficiently.

Step 5: Handle Data Breaches Correctly

Under GDPR, you have 72 hours from becoming aware of a personal data breach to notify your supervisory authority (in the UK, the ICO; in the EU, the relevant national data protection authority) if the breach is likely to result in a risk to the rights and freedoms of individuals.

If the breach is likely to result in a high risk to individuals, you also have to notify affected individuals without undue delay.

This requirement assumes you have an incident response process that detects breaches quickly. An organisation that does not know it has been breached until weeks later has missed its 72-hour notification window.

The cybersecurity incident response plan guide covers how to build that process, which is directly tied to meeting this GDPR requirement.

Step 6: International Data Transfers

If you transfer personal data outside the UK or EEA — for example, by using AWS in the United States, or by using a US-based analytics platform — you need a lawful transfer mechanism. The primary options are:

Standard Contractual Clauses (SCCs). Contractual clauses approved by the European Commission that provide appropriate safeguards for the transfer. Most cloud providers offer these in their DPAs.

Adequacy decisions. Transfers to countries that the EU has determined provide adequate protection (the UK for EU-to-UK transfers; limited other countries including Japan and New Zealand).

Binding Corporate Rules. For multinational organisations transferring data within the corporate group.

Most SaaS businesses that use US-based cloud infrastructure will rely on SCCs incorporated into their vendor DPAs. Confirm that each major vendor's DPA includes the current version of SCCs.

What Happens If You Get This Wrong

GDPR fines are tiered. Lower-tier violations (administrative breaches, less serious violations) can result in fines up to 2 percent of global annual turnover or €10 million, whichever is higher. Upper-tier violations (fundamental principles, data subject rights, cross-border transfers) can result in fines up to 4 percent of global annual turnover or €20 million.

The highest-profile fines have hit large companies. But regulators also pursue smaller organisations, particularly following customer complaints or breach notifications. The reputational damage from a public regulatory action can exceed the financial penalty for a growth-stage company.

The SOC 2 compliance guide covers the security certification layer that enterprise customers often require alongside GDPR compliance, and there is significant overlap in the technical controls required for both. The API security best practices guide covers the specific API-level controls that protect the personal data flowing through your SaaS.

For SaaS businesses building compliance programmes from the ground up or addressing specific GDPR gaps, our cybersecurity team works with founders on the technical and organisational controls that underpin compliant data handling. Contact us to assess where your current programme stands.