Book a call
All guides

Guide

The GDPR for startups running a cloud platform

What the GDPR asks of a startup's cloud platform in engineering terms: controller or processor, the records to keep, and the controls that prove it.

The General Data Protection Regulation has applied directly in every member state since 25 May 2018. It covers any organisation established in the EU that handles personal data. It also covers any organisation outside the EU that offers goods or services to people in the EU or watches their behaviour. Personal data means anything that relates to an identifiable person: an email address, an IP address, a user ID in a log line. For a startup, that's nearly every table in the database.

A large part of the Regulation covers decisions a lawyer or a data protection officer makes: why a company processes data, on what basis, and what it tells people. This guide stays on the part an engineer can answer. That means which role a company is in and which documents have to exist. It also means what the platform has to do when someone asks for their data, asks for deletion, or asks what happened after a breach.

This is an engineer's reading of the rules. I wrote it to help teams decide whether the rules touch their platform. It isn't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.

Does it apply to you?

If one of these lines describes your company, the rest of this guide applies. If none does, the rule probably sits outside your company. A thirty-minute call confirms that faster than the text can.

  • We hold any data about people in the EU: customers, users, employees, candidates, or leads. That alone puts us in scope, whatever our size.
  • We run software for other companies, and their users' data flows through it. That makes us a processor for that data, and every customer will want a data processing agreement before they sign.
  • We decide what to collect from our own users and why. For that data we're a controller, with the full set of duties, including a privacy notice and a lawful basis for each purpose.
  • We send prompts, logs, or analytics to a vendor outside the EU, or run on a US cloud. Those are transfers, and each one needs a legal mechanism and a record.
  • We profile people, score them, track them at scale, or handle health, biometric, or other special category data. That raises the bar: an impact assessment, possibly a data protection officer, and a harder look at our lawful basis.

What it asks of your platform

Which role we're in, per data set

A controller decides why and how to process personal data. A processor acts on a controller's instructions. A B2B SaaS startup is usually both. It's a processor for the customer data inside the product, and a controller for its own users, staff, billing, and marketing.

The split matters because the duties differ. A processor's obligations come mostly from the Article 28 contract with each customer, plus security, breach help, and a list of its own sub-processors. A controller owes the whole Regulation. I write the split down in one table before anything else. The records, the notices, and the contracts all follow from it.

The documents that have to exist

The first document is a record of processing activities. It lists each purpose, the categories of data and people, who receives the data, where it goes outside the EU, how long the company keeps it, and the security measures. The exemption for companies under 250 staff is narrow, so I see almost every SaaS keep one anyway. Next comes a data processing agreement with each processor the company uses, and one ready for each customer it processes for.

A privacy notice covers the company's own users. A data protection impact assessment has to come before any high-risk processing, such as large-scale monitoring, scoring, or special category data. The Regulation only requires a data protection officer when the core activity is large-scale monitoring or large-scale special category data. I see a lot of startups sit outside that, though appointing one voluntarily is common. Fines reach 2% or 4% of global turnover, or 10 or 20 million euro if higher, depending on the article breached.

What the platform has to be able to do

Article 32 asks for security appropriate to the risk and names pseudonymisation, encryption, resilience, recovery, and regular testing. Article 25 asks for privacy by default: the minimum data, kept only as long as the purpose needs. In practice, that means a data map that names each store and its retention. It also means a deletion job that actually runs and reaches backups on a schedule, an export that returns one person's data in a usable format within a month of the request, and access logs on the stores that hold personal data.

A breach has to reach the supervisory authority within 72 hours of the company becoming aware of it. The people affected hear about it without undue delay when the risk to them is high. That clock needs alerting that reports the breach and logs that show what it touched. Transfers outside the EU need an adequacy decision, such as the EU-US Data Privacy Framework, or standard contractual clauses plus an assessment of the destination. The data residency guide covers the AWS side.

The Digital Omnibus: what may change, and what has not

The European Commission proposed a Digital Omnibus on 19 November 2025 that would amend the GDPR. The Council agreed its negotiating position on 21 October 2026. The main proposals are a 96-hour breach deadline limited to breaches likely to cause high risk, a narrower reading of what counts as personal data for the organisation holding it, lighter record-keeping for companies under 750 staff, and machine-readable consent signals from browsers.

The Parliament hasn't voted, so none of it is law. The 72-hour deadline and the current record rules still apply. My sources are the Council's press release and the Parliament's Legislative Observatory, checked on 4 November 2026. I build to the current text and keep the design flexible on the parts that may move.

Common questions

We are a ten-person SaaS. Do we need a data protection officer?
Probably not. The duty turns on what a company does, not on its size: large-scale regular monitoring of people, or large-scale special category data, as a core activity. A product that tracks every user's behaviour across the web can cross that line at ten people. A project management tool doesn't. I recommend deciding on the facts and recording the decision.
Can we send user data to an AI model API?
Yes, under four conditions. The vendor is a processor under a data processing agreement, and the transfer mechanism for its location is in place. The purpose sits inside your lawful basis, and the vendor doesn't train on the data unless your users agreed to that. In the designs I ship, prompts carry only what the task needs, and I pick EU endpoints where the vendor offers them.
How do we handle a deletion request in a system with backups?
Deletion from live stores happens promptly, with a record that shows the team honoured the request. Backups then age out on a documented retention period, with a process to re-delete if anyone ever restores one. Regulators have accepted that approach when the retention is short and written down. What they don't accept is a backup that never rotates.
What would you fix first?
The data map and the deletion path. The map shows what the company actually holds, which often surprises the founders, and it drives the records, the notices, and the retention. The deletion path is the control a user or a customer's audit tests first. I see a lot of startups unable to demonstrate it on the day. Could your team delete one user's data end to end this week?

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?