GDPR for a Small SaaS: What You Actually Owe, in Order

This page is about what the privacy regulation asks of the company that runs a subscription app, which here means yours, rather than what you can ask of a company that holds data about you. It is also not a list of penalties.

The reader owns a working product. People in Europe or the United Kingdom sign in and pay for it. It was built by the owner or built for them with an AI builder, nobody in the company does privacy for a living, and the question arrived at the same time as the first European customer. Most writing about GDPR for startups assumes a compliance budget and somebody to spend it; this assumes neither.

What follows is every duty that lands on a product like that, the sequence they land in, and the place each one is already worked out. Three of them are answered in full elsewhere on this site, so this page sends you there instead of saying it again.

Every fact below comes off a page somebody else publishes: the regulation’s own text on the Union’s legal database, the guidance the European Data Protection Board and the Information Commissioner’s Office write for small organisations, one analytics platform’s documentation, and the pages ranking for this phrase today, each read as raw markup on 3 September 2026 and named in the sentence that uses it. AxonBuild has audited, certified, hosted, represented and advised nobody here, and no sentence on this page decides whether your company has met a duty. That decision is yours, with whoever gives you legal advice, and every source is named so you can take it to them.

The nine rows below are the duties of the company running the app, as the regulation’s own articles and the two regulators’ guidance set them out: a lawful basis and a notice, a written record, vendor agreements, answering requests for a copy and to remove, a retention decision, security with a breach process, a data location, and sometimes a representative.

Does GDPR apply to an app you built yourself?

Two tests decide it and Article 3 of the regulation states both: where the company is established, and whether the app offers goods or services to people in the Union or watches what they do there. The board’s guide for small organisations adds that an offer counts even when it is free.

The first test is about you. Article 3(1) of the regulation, read on 3 September 2026, applies it to processing “in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not”. A company registered inside the area is covered by where it sits, and moving the database elsewhere changes nothing about that.

The second test is about your customers, and it is the one that catches a product built on another continent. Article 3(2), on the same page and the same date, extends the regulation to a controller or processor not established in the Union where the processing relates to “the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union”, or to “the monitoring of their behaviour as far as their behaviour takes place within the Union”.

The clause people miss is the one about payment. The offer counts whether or not money changes hands, which means a free tier, a waiting list and a public beta all sit inside the same sentence as a paid plan. The European Data Protection Board’s guide for small organisations, read the same day, writes the test out as four practical conditions, and one of them is being “an organisation, based in a non-EEA country, selling goods or offering services, even for free, targeting individuals in an EEA country”. On that guide’s own wording, a company registered in the United States is inside the conditions the moment it offers the service, free or paid, to people there and the offer targets them, or it monitors their behaviour there; European signups on their own are evidence of targeting rather than the test itself.

The same guide sets out six key principles it says an organisation must comply with when it processes personal data, and adds that the organisation must be able to demonstrate that compliance. That last clause is why so much of what follows is paperwork rather than code.

Controller or processor: which one are you here?

The roles split by who decides. The regulation defines a controller as the body that “determines the purposes and means of the processing”, and a processor as one that “processes personal data on behalf of the controller”. A small subscription product is usually both at once, on different data.

For the accounts that sign up on your own website, you decide why the data exists and what happens to it, which puts you on the controller side of the regulation’s own definition in Article 4(7), read 3 September 2026. Every duty on this page follows from that.

For a business customer whose staff or whose own customers end up in your tables because they pay you to hold them, the deciding is usually theirs, and Article 4(8) describes that party as one processing “on behalf of the controller”. This is the split that surprises founders selling into other companies: the same product can be the controller of its billing contacts and somebody else’s processor of the records inside a workspace, in one database. Which side a specific incoming request falls on is a separate decision with its own steps, and it is made on the page that handles requests rather than here.

One owner went through a customer-facing product they had built themselves, checking it line by line against the privacy rules and against how its data is looked after, and came out of it thinking most owners in the same position had not thought about the thing they found. The founder who went looking like that had a customer’s own form in front of them, and what that form asks for and how much of it can be answered honestly on day one is set out where that form is answered.

The GDPR rules a small SaaS meets, and where each answer lives

Here is the whole surface in one table. The left column is the duty in plain words, the middle names the article or guidance page that sets it out, and the right says where the working answer already exists. Nothing here is a judgement about whether your product has met anything; it is a map, and a GDPR compliance checklist for SaaS in the only sense this page uses the word, which is a list of things to go and read.

Three of those rows are finished work. The moment somebody actually asks you to remove what you hold about them, the copies that request has to reach and the ones it is allowed to leave alone are worked through step by step on their own page, and this row only says the duty exists. How long each category is allowed to stay, what starts its clock and what happens at the end are settled one row at a time on the page that builds the schedule. Which of the two rights a request for a copy is actually using, and what has to come back in the file, are separated on the page that builds the export.

The order matters more than it looks. A lawful basis is the row every other row leans on, because a record describes purposes and a retention decision is a judgement about a purpose. Founders usually meet the rows backwards, working out from the first customer question.

One thing this table is not is a customer’s requirement list. A customer’s own list of requirements is a different document from the regulation’s, it arrives with items on it that no privacy rule asks for, and working through one of those is its own subject.

Your lawful basis, and the one place the two lists stopped matching

Article 6(1) of the regulation, read 3 September 2026, says processing “shall be lawful only if and to the extent that at least one of the following applies” and then lists six: consent, performance of a contract, a legal obligation, vital interests, a public-interest task, and legitimate interests. For a subscription product two of those do nearly all the work. Running the account somebody paid for is contract territory. Anything the account holder did not ask for, such as product analytics or a marketing list, tends to be argued under consent or legitimate interests, and which one applies is a question for whoever advises you.

The list is no longer identical on both sides of the Channel, and none of the five ranked guides to GDPR compliance for SaaS companies, each read on 3 September 2026, mentions the difference. The Information Commissioner’s Office guide to lawful basis, read 3 September 2026, says “There are seven lawful bases available for you to use” and lists them as (a) to (f) with an extra entry, (ea) recognised legitimate interest, sitting between public task and legitimate interests.

That guide describes the extra basis as processing “necessary for one of the pre-approved purposes” and names five of them: safeguarding “vulnerable” people; responding to emergencies; preventing or investigating crime; national security, public security and defence; and sharing personal information with an organisation that needs it for their public task or function at their request. The same page adds that the basis cannot apply to a public authority processing personal information to perform its official tasks.

The date on that change is on the page itself. The guide’s own latest-updates entry reads “02 April 2026 - we have updated this guidance to reflect amendments introduced by the Data (Use and Access) Act and to follow the ICO’s latest style guide”. A company selling into both jurisdictions is reading two lists that stopped being the same list, though for a small product the practical effect is narrow, because those five purposes are emergency and public-function shaped rather than commercial.

Two more sentences from the same guide are worth copying into whatever document you keep. It says the basis must be determined before the processing starts and must be documented, and it says that swapping to a different basis later without good reason is not permitted, singling out consent as the one you usually cannot swap away from. Deciding the basis after the feature ships is the common order and the guide’s own wording puts it the other way round.

Every vendor your app calls is on somebody’s list

A modern AI-built app reaches more third parties than its owner can name from memory. The usual set:

• the platform the app was built on
• the database, and whatever the app is hosted on
• the model provider behind any clever feature
• whoever sends the transactional email
• whoever takes the card
• the product-analytics tool

Article 28(3) of the regulation, read 3 September 2026, says processing by a processor “shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller”. That is the duty in one sentence: for each of those vendors there is meant to be a written arrangement, and customers may ask to see the list. The word for a vendor sitting underneath one of your vendors is subprocessor, and the chain runs longer than the six lines above suggest.

What such an arrangement actually says, and what you are promising by signing one, is deliberately not on this page. When a customer sends their own agreement over for signature, what it is actually asking you to promise, and which of your vendors ends up named in it, is worked out on the page that reads one.

Two of the six lines have their own answers as well. What the model vendor behind your app’s clever feature keeps, for how long, and what it takes to switch that off, is answered where those vendors’ own terms are read.

The analytics tool is the part most founders forget

Analytics is the vendor nobody thinks of as a vendor, because it was added in an afternoon and produces charts rather than customer records. It is also the one collecting things nobody chose to collect. One platform documents this clearly enough to use as a worked example, which is why it is quoted here rather than recommended.

PostHog’s own GDPR documentation, read 3 September 2026, opens by saying the guide is not legal advice and recommending that you read the full text of the regulation and seek independent legal advice about your obligations. Its own feature table then splits what it offers by stage: during collection it names autocapture controls, masking personal information and sanitizing events as they are captured, and before ingestion it names anonymizing data before storage.

The same page says IP addresses “can be considered personal data under GDPR” and documents the setting that controls whether they are captured, at both organisation and project level. The default is not the same everywhere. For organisations on its European cloud, that page states IP capture “is automatically disabled by default for all new projects”; for its United States cloud and for self-hosted instances it describes the same setting as one you configure manually. Which region a founder happened to pick during signup therefore decides what the tool started collecting on day one, and nothing in the interface announces that.

Two more lines from the same document are worth knowing. Where an instance is self-hosted outside the region or running on the United States cloud while capturing data about people inside it, the page says you should use its before-storage transformations to anonymize. And on erasure it says a user must be able to request that their data be removed, adds “How you facilitate that request is up to you”, and says the platform provides data-deletion features to help. That is a vendor saying, in its own documentation, that the route belongs to you. Its European managed option is described on the same page as hosted on servers based in Frankfurt.

Masking and tokenization sit in the collection column of that table rather than the deletion column, and whether data that has been stripped or replaced still counts as personal data is answered directly in the retention page’s own FAQ rather than from a vendor’s feature list.

The three answers that start “we are too small for that”

Three duties have a small-company carve-out written into the article that creates them, and all three carve-outs read narrower than the phrase suggests. The table quotes the conditions rather than summarising them, because the conditions are the whole answer.

Two of the three turn on the same word. A product that bills people on a schedule and holds their records between visits is continuous by design, and the article’s exemption is written for processing that is occasional. The board’s own guide for small organisations shows what it has in mind: its compliance page, read 3 September 2026, says organisations employing fewer than 250 persons are not required to mention “purely occasional” activities in their record, and gives a one-off event such as the opening of a shop as its example. The same page says records should be kept in writing, including in electronic form, that the record must be available to the data protection authority of the EEA country where you operate if requested, and that it falls under the responsibility of the organisation’s manager.

Article 30(1) also says what a record has to contain, which is less than most templates sell: the purposes, the categories of people and of data, the categories of recipients including recipients in third countries, transfers where applicable, “where possible, the envisaged time limits for erasure of the different categories of data”, and “where possible, a general description” of the security measures.

None of that says which side of a carve-out your company is on. What it does say is that the answer is a reading of three sentences rather than a rule of thumb about headcount, and none of the five pages ranking for this phrase, each answering an automated read on 3 September 2026, reads them. Taking the whole body copy of each of those five including its navigation, Article 27 appears zero times, Article 37 appears zero times, the 250-person threshold appears zero times, the seventh lawful basis appears zero times and the name of the 2026 statute appears zero times. Article 30 appears once, on one page, naming the record duty as an obligation without the paragraph that qualifies it. The five addresses are given here unlinked, because every one of them sells into this query: www.vanta.com/resources/gdpr-compliance-for-saas, www.metomic.io/resource-centre/a-guide-to-gdpr-for-saas-apps/, gdprregulation.eu/gdpr-for-saas-companies/, www.cookieyes.com/blog/gdpr-for-saas/ and www.scrut.io/hub/gdpr/gdpr-for-startups. The second of them turned away a plain request with a 403 on that date and answered only the browser-shaped one, so its counts come from that read. All five end in a route to the publisher’s own product or service.

What a platform’s paperwork does not reach

A vendor’s agreement covers the vendor. It describes what that company does with data you send it and what it promises about its own machines, and it stops at the edge of its own service. Every duty in the table above sits with the company running the app, and no plan tier changes which party that is. One builder publishes its own agreement, its own vendor list and its own storage-region rules, and reading what those cover for an app built on it is a different exercise from the one on this page. Whether one named database vendor’s own agreement, region list and vendor list actually cover what your app does with them is answered vendor by vendor rather than here.

The breach duty is the clearest case of the split, because the vendor tells you and then the decision is yours. The board’s guidance on data breaches, read 3 September 2026, sets out three primary principles for a controller: documentation of any personal data breach; notification to the relevant data protection authority within 72 hours, “unless it is unlikely to result in a risk to individuals”; and communication to the individuals themselves without undue delay where the breach is likely to result in a high risk to them. The same page adds that even breaches assessed as unlikely to be risky must still be recorded with at least the basic details, the assessment, the effects and the steps taken in response. Someone has to make that call, in a hurry, and no vendor page makes it for you.

Several of the duties above arrive in a working app as one thing that quietly does not do its job: an erasure route that misses the copies written after it was built, an export nobody ever wired up, an analytics call carrying a field that was never meant to leave the browser. That is work on code and nothing else. Choosing a lawful basis, writing a notice, signing or arguing about an agreement, standing as anybody’s representative in a member state, and deciding whether a duty above has been met all sit outside it. No line above is legal advice.

Common questions about GDPR for a small SaaS

Does the regulation apply if my company is registered somewhere else?

Article 3(2) of the regulation, read 3 September 2026, extends it to a controller or processor not established in the Union where the processing relates to offering goods or services to people who are in the Union, “irrespective of whether a payment of the data subject is required”, or to monitoring their behaviour there. Where the company is registered is only the first of the two tests, and the second is whether the offer targets people in the Union or monitors their behaviour there, which is a narrower question than who happens to sign up.

Do I need a data protection officer for a small SaaS?

Article 37(1) names three situations in which one must be designated: processing by a public authority or body; core activities that require regular and systematic monitoring of people on a large scale; and core activities that involve large-scale processing of special categories of data or of criminal-conviction data. Read 3 September 2026, those are the article’s own three cases. Three of the five pages ranking for this phrase, read the same day, answer the question with a rule of thumb about the volume of sensitive data instead.

Is there a small-company exemption from any of this?

Article 30(5) carries the only headcount-based one in this set, and it is conditional. Its own text says the record duties do not apply to an organisation employing fewer than 250 persons unless the processing is likely to result in a risk to people’s rights and freedoms, the processing is not occasional, or it includes special categories or criminal-offence data. Article 27(2)(a) has a similar carve-out for the representative duty that also turns on processing being occasional.

Does it make a difference that my app is free?

Not to whether the regulation reaches you. Article 3(2)(a) covers the offering of goods or services “irrespective of whether a payment of the data subject is required”, and the board’s guide for small organisations lists an organisation outside the area “selling goods or offering services, even for free, targeting individuals in an EEA country” among its four practical conditions. Both were read on 3 September 2026.

Do I have to follow two different versions of these rules?

If you sell into both jurisdictions, you are reading two texts that no longer match at every point. Article 6(1) of the regulation lists six lawful bases. The Information Commissioner’s Office guide to lawful basis, read 3 September 2026, says there are seven and adds (ea) recognised legitimate interest, describing it as processing necessary for one of a set of pre-approved purposes. That guide’s own update note is dated 2 April 2026, which is when the guidance was revised to reflect the Data (Use and Access) Act; the date the legal change itself commenced is in that Act’s commencement provisions rather than in the guide.

Is a privacy policy the same thing as a privacy notice?

They are used interchangeably in most product copy, and neither phrase is what the regulation calls the duty. The board’s good-practice list for small organisations, read 3 September 2026, states it as informing individuals about how and for what purposes their personal data may be processed, and the Information Commissioner’s Office guide adds that the lawful basis and the purposes must be included in the privacy information given to people. The title matters less than whether those two things are in it.

Does using a hosted platform move any of this off me?

The platform’s own agreement covers the platform. The duties in the table above are addressed to the company that decides why the data is being processed, which is the company running the app, and picking a managed plan does not move that party. One vendor’s own documentation, quoted further up this page, puts the erasure route on the customer rather than on itself.

Which specific promises one named platform has actually put in writing, and what its region controls and vendor list cover, is read out one vendor at a time on the pages that do exactly that.

Which of these should be settled before the first paying customer?

Every duty in the table applies from the moment the app processes anybody’s personal data, paying or not, so none of them waits for a contract. Two get harder to fix later and are worth settling first. The Information Commissioner’s Office guide to lawful basis, read 3 September 2026, says the basis must be determined before the processing starts, must be documented, and should not be swapped later without good reason, which makes it a before rather than an after. The other is the vendor list, because every service the app already calls is one a customer may ask you to name, and the list only grows.

Are the penalties something a company this size should worry about?

Enforcement is a different subject from duty, and this page answers the duty question only. The regulators publish their own enforcement pages, and any figure that matters to a specific company depends on facts nobody can read off an article. What the sources above settle is what is being asked of the company running the app, which is the part you can act on without a lawyer in the room.