GDPR for Startups: What You Actually Need to Do

GDPR has been in force since 2018, but many startups still treat it as a European problem they'll deal with later. If you have a single EU customer, employee, or visitor to your website, you are subject to GDPR — regardless of where your company is incorporated.

This guide cuts through the legal complexity to explain what GDPR actually requires and what practical steps you need to take. This is not legal advice; consult a qualified lawyer for your specific situation.

First: Does GDPR Apply to You?

GDPR applies to any organization that:

Is established in the EU, or
Offers goods or services to people in the EU (even for free), or
Monitors the behavior of people in the EU (including website analytics)

That last point catches most startups. If you use Google Analytics, you're monitoring EU visitors. If you accept EU sign-ups, you're offering services to EU residents. GDPR applies.

The extraterritorial reach: A US company with no EU offices, employees, or servers that sells software to EU businesses is still subject to GDPR. The EU has pursued enforcement against US companies, and GDPR fines can be up to €20 million or 4% of global annual turnover, whichever is higher.

The 6 Lawful Bases for Processing

Every processing activity needs a lawful basis. "We need it for our business" is not a lawful basis. The six are:

1. Consent

The person has freely given, specific, informed, and unambiguous agreement to the processing. Consent must be as easy to withdraw as to give.

When to use it: Marketing emails, non-essential cookies, optional analytics.

Common mistake: Pre-ticked checkboxes, bundled consent, or requiring consent as a condition of service. These don't count as valid consent.

2. Contract

Processing is necessary to fulfill a contract with the individual.

When to use it: Processing a customer's email address to send them a receipt, using billing information to charge for a subscription.

3. Legal Obligation

Processing is required to comply with law.

When to use it: Tax record keeping, responding to court orders.

4. Vital Interests

Processing is necessary to protect someone's life.

When to use it: Rare — medical emergencies. Unlikely to apply to most startups.

5. Public Task

Processing is necessary for a task in the public interest.

When to use it: Government bodies and some research institutions. Rarely applies to private companies.

6. Legitimate Interests

Processing is necessary for your legitimate interests, balanced against the individual's rights.

When to use it: Security monitoring, fraud prevention, B2B marketing to existing customers, service improvement. Requires a documented balancing test.

For most SaaS startups: Core product functionality runs on contract. Marketing emails to opted-in users run on consent. Security logging and fraud prevention run on legitimate interests.

Privacy Policy Requirements

Your privacy policy must cover, at minimum:

Who you are: Company name, address, contact details
What data you collect: Specific categories (name, email, payment info, usage data, etc.)
Why you collect it: For each purpose, the lawful basis
How long you keep it: Retention periods or the criteria used to determine them
Who you share it with: Third parties and subprocessors, with categories or names
International transfers: If data leaves the EEA, the transfer mechanism (Standard Contractual Clauses, adequacy decision, etc.)
Data subject rights: How individuals can exercise their rights (see below)
Right to complain: Contact details for the relevant supervisory authority
Automated decision-making: If you use it, including profiling

Format requirements: Must be concise, transparent, intelligible, and easily accessible. Legalese that no one can understand violates GDPR. Plain language is required.

Cookie Consent: What's Required

Cookies that are not strictly necessary require consent. This means:

Requires consent:

Google Analytics (unless configured for cookieless mode)
Meta Pixel / advertising cookies
Hotjar, FullStory, and similar session recording tools
Intercom, Drift, and similar chat tools that set persistent cookies

Does NOT require consent (strictly necessary):

Session cookies that keep you logged in
Shopping cart cookies
Security cookies (CSRF tokens)
Load balancing cookies

Implementing Cookie Consent Correctly

A compliant cookie banner must:

Describe what categories of cookies you use
Allow users to accept, reject, or configure categories
Not pre-select optional categories
Be as easy to reject as to accept (no dark patterns)
Record consent with a timestamp
Allow users to change their preferences later

Compliant tools: Cookiebot, OneTrust, Osano, Usercentrics. Note that many "GDPR banners" are not actually compliant — the "X to close" banners that assume consent are not valid.

US company selling to EU: You still need a compliant cookie consent mechanism. EU visitors to your US-hosted website are protected by GDPR.

Data Subject Rights

EU residents have the following rights, which you must be able to fulfill:

Right	What It Means	Your Deadline
Right of Access (DSAR)	Provide a copy of all personal data you hold	30 days
Right to Erasure ("Right to be Forgotten")	Delete personal data when requested	30 days
Right to Rectification	Correct inaccurate data	30 days
Right to Restriction	Stop processing while a dispute is resolved	Without undue delay
Right to Portability	Provide data in a structured, machine-readable format	30 days
Right to Object	Stop processing based on legitimate interests or for marketing	Immediately for marketing
Rights re: automated decisions	Explanation of automated decisions, human review option	30 days

Building the processes:

Create a privacy@yourdomain.com or dpo@yourdomain.com inbox for requests
Document your DSAR process: who receives it, who fulfills it, how you verify identity
Know which databases contain personal data and how to export or delete a specific user's data
Maintain a log of all requests and responses

Exemptions: You can decline requests in limited circumstances (legal obligation to retain data, freedom of expression, public interest). Consult a lawyer for specific cases.

Data Processing Agreements (DPAs) with Vendors

Any vendor that processes personal data on your behalf is a data processor. GDPR Article 28 requires a written DPA with every data processor.

Vendors that likely need a DPA:

Cloud hosting (AWS, GCP, Azure) — all have standard DPAs available on request
Email service providers (SendGrid, Mailchimp, Postmark)
Analytics (Google Analytics, Mixpanel, Amplitude)
CRM (HubSpot, Salesforce, Pipedrive)
Customer support (Intercom, Zendesk, Freshdesk)
Payment processing (Stripe — has a standard DPA)
Logging and monitoring (Datadog, Sentry, Logtail)
Video conferencing (Zoom, Google Meet)

What a DPA covers:

Subject matter and duration of processing
Nature and purpose of processing
Type of personal data and categories of data subjects
Obligations and rights of the controller (you)
Data processor obligations (security, sub-processors, breach notification, etc.)

Practical step: Most major vendors have pre-signed DPAs available on their websites. Go to each vendor's privacy/legal page and download their DPA. For vendors without a standard DPA, use your own template or request they sign one.

The 72-Hour Breach Notification Rule

Under GDPR Article 33, if you suffer a personal data breach, you must notify the relevant supervisory authority within 72 hours of becoming aware of it — unless the breach is unlikely to result in risk to individuals.

What counts as a breach: Any accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. This includes accidental emails sent to the wrong person, misconfigured S3 buckets, and ransomware.

The 72 hours start when you become aware. This means your internal escalation process must be fast. A breach discovered on Friday at 6 PM still triggers the 72-hour clock.

What to include in the notification:

Nature of the breach (what happened)
Categories and approximate number of individuals affected
Categories and approximate number of records affected
Contact details for your DPO or privacy contact
Likely consequences of the breach
Measures taken or proposed to address it

Article 34 — Notifying individuals: If the breach is likely to result in high risk to individuals, you must also notify the affected individuals directly, without undue delay. This is separate from the regulatory notification.

Documenting all breaches: You must keep a record of all data breaches, even those you don't report to regulators. This includes the facts, effects, and remedial actions taken.

Do You Need a Data Protection Officer (DPO)?

A DPO is mandatory if you:

Are a public authority
Carry out large-scale systematic monitoring of individuals (behavioral advertising at scale)
Process special category data (health, biometric, religious beliefs, etc.) at large scale

For most SaaS startups: A DPO is not required. However, it's good practice to designate a privacy contact — typically the CTO, Head of Legal, or a senior engineer — who owns GDPR compliance.

If you're not sure: A consultancy DPO (part-time, external) is a cost-effective option. They fulfill the formal obligation without a full-time hire.

International Data Transfers

Transferring personal data outside the EEA (European Economic Area) requires a valid transfer mechanism.

Adequacy decisions: The EU has recognized some countries as providing adequate protection, including the UK (post-Brexit, temporary), Canada (partially), Japan, and others. The US was covered by Privacy Shield, which was invalidated in 2020.

Standard Contractual Clauses (SCCs): The most common mechanism for EU-US transfers. The 2021 SCCs (Module 2: Controller to Processor) are what you should use when signing DPAs with US vendors. Major cloud providers and SaaS companies have incorporated these into their DPAs.

Transfer Impact Assessments (TIAs): Post-Schrems II, transfers to the US also require assessing whether the receiving country's laws undermine the protections in the SCCs. For most commercial data transfers, a TIA concludes that the SCCs provide sufficient protection with appropriate safeguards.

Practical implication: If you use AWS in us-east-1 for EU customer data, you need SCCs in your AWS DPA (AWS provides these). If you use Google Analytics, you need to configure it properly and have SCCs in place with Google.

GDPR Compliance Checklist for Startups

GDPR is not a one-time project — it's an ongoing compliance obligation. The companies that handle it well treat it as a data hygiene practice rather than a compliance checkbox, and they end up with better data practices, fewer breaches, and stronger customer trust as a result.