Building GDPR-Compliant SaaS: The Technical Guide for Founders and Engineers

GDPR compliance is not a legal checkbox. It is an engineering problem. The regulation defines rights for individuals; your code either honours those rights or it doesn't. This guide covers what GDPR actually requires engineers to build, in plain terms — without the legal language that obscures the technical requirements.

This guide is for technical founders, engineering leads, and product teams building SaaS products with European users.

What GDPR actually requires

GDPR (General Data Protection Regulation) is a European Union regulation governing the processing of personal data. Its core principles:

1. Lawfulness, fairness, transparency — you need a legal basis for processing, and users must know what you're doing
2. Purpose limitation — data collected for one purpose can't be used for another
3. Data minimisation — collect only what you need
4. Accuracy — keep data correct and up to date
5. Storage limitation — don't keep data longer than necessary
6. Integrity and confidentiality — protect data with appropriate security
7. Accountability — you must be able to demonstrate compliance

These principles have specific technical implementations.

Lawful basis for processing

Before collecting or processing any personal data, you must have a lawful basis. There are six; for SaaS, the relevant ones are:

Basis	When it applies	Technical implication
Contract	Processing necessary to perform a contract with the user	Core product functionality — logging in, storing their data to provide the service
Legitimate interests	Your business interest outweighs the user's privacy interest	Analytics, fraud prevention, security — must be assessed and documented
Consent	User has freely given, specific, informed, unambiguous consent	Marketing emails, tracking cookies, non-essential analytics
Legal obligation	Processing required by law	Tax records, legal hold situations

The most common mistake: Treating "legitimate interests" as a catch-all that covers everything you want to do. It isn't. Legitimate interests requires a documented balancing test. If in doubt, use consent.

What consent actually means under GDPR

GDPR consent requirements are strict:

• Freely given: Users cannot be required to consent as a condition of using the service (unless the processing is necessary for the service)
• Specific: Consent for marketing emails does not cover consent for sharing data with third parties
• Informed: Users must understand what they're consenting to
• Unambiguous: Pre-ticked checkboxes are not valid consent. Silence or inactivity is not consent.
• Withdrawable: Users must be able to withdraw consent as easily as they gave it

Engineering implication: You need a consent management system that records when consent was given, what the user consented to, and allows withdrawal.

Data subject rights: what you must build

GDPR gives individuals eight rights. For SaaS products, these translate into specific engineering requirements:

Right of access (Article 15)

Users can request a copy of all personal data you hold about them.

What to build:

• A mechanism (account settings or email request) to trigger a data export
• Export must include all personal data — account info, usage data, any derived data
• Must be provided within 30 days
• Must be in a machine-readable format

Right to rectification (Article 16)

Users can request correction of inaccurate data.

What to build:

• Profile editing for user-provided data
• A way to request correction of data users can't edit themselves
• Propagation of corrections through all systems where that data exists

Right to erasure — "right to be forgotten" (Article 17)

Users can request deletion of their personal data.

What to build:

• Account deletion functionality that actually deletes data (not just marks as inactive)
• A deletion pipeline that removes data from: primary database, backups (on rotation schedule), analytics systems, email marketing systems, CDN caches
• Document what data you retain after deletion and the legal basis for retention (e.g., transaction records for tax purposes)

The hard parts:

• Backups: you don't need to immediately delete from backups, but deleted records must not be restored from backup
• Derived data: if you've computed aggregates or trained models on the user's data, what is the obligation?
• Third-party systems: deletion requests must flow to all sub-processors who hold copies

Right to data portability (Article 20)

Users can request their data in a machine-readable format to transfer to another service.

What to build:

• Data export in a standard format (JSON, CSV)
• Export triggered via account settings or upon request
• Must include data the user provided, not derived data

Right to object (Article 21)

Users can object to processing based on legitimate interests or for direct marketing.

What to build:

• Unsubscribe mechanism for marketing communications
• A way to object to processing for specific purposes (analytics, profiling)
• System to honour those objections — a user who objects to analytics tracking must not be tracked

Right to restriction (Article 18)

Users can request that processing be limited (data retained but not used) in certain circumstances.

What to build:

• A "restricted" account state where data is stored but not processed
• Clear audit trail of when restriction was applied and why

Cookie consent and tracking

This is where most SaaS products have visible compliance failures.

What requires consent

• Third-party analytics (Google Analytics, Mixpanel, Hotjar)
• Marketing pixels (Meta, Google Ads retargeting)
• Session recording tools
• Third-party chat widgets that track behaviour

What doesn't require consent

• Strictly necessary cookies (session authentication, CSRF tokens, load balancing)
• First-party analytics that don't track across sites and are fully anonymised

Building compliant consent

Option 1: Cookie consent banner A proper consent banner (not a notice — it must collect consent):

• Must appear before any non-essential cookies are set
• Must have separate toggles per category (analytics, marketing, etc.)
• Must have a reject-all option as prominent as accept-all
• Must store consent and send it to all third-party scripts

Option 2: Privacy-preserving analytics Tools like Plausible, Fathom, or Umami collect aggregate analytics without cookies and without personal data — they don't require consent. Simpler and cleaner for most SaaS products.

Data Processing Agreements with sub-processors

If you use any third-party service that processes personal data on your behalf, you must have a Data Processing Agreement (DPA) in place.

Common sub-processors most SaaS products use:

Service	Data processed	DPA available?
AWS / GCP / Azure	Everything stored in the cloud	Yes — sign in account settings
SendGrid / Mailgun	Email addresses, content	Yes
Intercom / Zendesk	User data, support conversations	Yes
Stripe	Payment data, user identity	Yes
Mixpanel / Amplitude	Usage events, user identifiers	Yes
Sentry	Error data, may include PII	Yes

Sign all DPAs before processing EU user data through these services. Keep a sub-processor register.

Privacy by design: the architecture principle

GDPR's Article 25 requires "data protection by design and by default." In engineering terms:

• Collect minimum data: If you don't need a field, don't collect it. If you collect it optionally, make it optional.
• Default to privacy: New features should default to the most privacy-preserving configuration, not the most data-collecting one.
• Pseudonymisation: Where possible, replace identifiers with pseudonyms in analytics and logging. Don't log raw user IDs in application logs if a hashed version works.
• Access control: Personal data access should be role-restricted. Not every engineer needs production database access.
• Retention policies: Implement automated data deletion. Logs older than 90 days should be deleted or anonymised automatically. Inactive accounts should trigger a retention review.

Data breach requirements

GDPR requires notification of data breaches to:

• The supervisory authority (in the EU member state where you're established or where your users are) within 72 hours of becoming aware
• Affected individuals without undue delay if the breach is high risk

What to build:

• Incident detection (logging, alerting)
• Incident response procedure that includes GDPR notification assessment
• A way to identify which users were affected by a given breach
• A communication mechanism to reach affected users quickly

72 hours is tight. The process must be pre-designed, not improvised.

Record of processing activities (ROPA)

GDPR Article 30 requires most organisations to maintain a record of processing activities — a document that describes:

• What personal data you collect
• Why you collect it (purpose)
• The lawful basis
• Who you share it with
• How long you retain it
• What security measures are applied

This is primarily a documentation task, not an engineering one — but it requires understanding of what the engineering does. Build it from your actual data flows, not from a template.

Technical implementation checklist

Before launching to EU users:

Data collection:

• Every data field has a documented lawful basis
• Consent is recorded with timestamp and version of privacy policy
• Cookie consent is collected before non-essential cookies are set

Data subject rights:

• Data export mechanism in place
• Account deletion deletes actual data (not soft-delete only)
• Deletion flows to analytics, email, and third-party systems
• Profile editing available for user-provided data

Sub-processors:

• DPA signed with every sub-processor
• Sub-processor register maintained

Security:

• Encryption at rest and in transit
• Access control on personal data
• Breach detection and response process documented

Documentation:

• Privacy policy accurate and current
• ROPA maintained
• Legitimate interests assessments documented where applicable

---

Building a SaaS product for European users and need help getting the technical implementation of GDPR right from the start? Contact us — we've built GDPR-compliant systems across SaaS, fintech, and B2B products, and can help you architect compliance as a product feature, not an afterthought.