GDPR for your SaaS payment and customer-data stack: the 2026 checklist (including founders outside the EU)

Map every tool holding customer data and decide whether each is your processor or an independent controller. Sign DPAs with processors and cover non-EEA transfers with adequacy, the DPF or SCCs. Keep invoices for the tax period. Answer data requests within one month, report notifiable breaches within 72 hours where feasible and, outside the EU, usually appoint an EU representative.

The checklist below follows the stack a SaaS actually runs: auth, checkout and payments, billing and invoicing, email, analytics and LLM features. It's written for founders in India, the US or elsewhere who sell to people in the EU, and for small EU teams. We run a merchant of record, so we point out where using one changes a step. None of this is legal advice; have a privacy lawyer check your setup.

The stack map

The role decides the paperwork. A processor needs an Article 28 DPA from you. An independent controller needs a line in your privacy notice and a lawful basis for whatever you share with it.

Roles follow what a vendor actually does with the data, whatever the contract calls it (EDPB Guidelines 07/2020). Several vendors above hold more than one role.

The 10 steps

1. Map your data and keep a record of processing

Start with a spreadsheet, one row per tool from the table above. For each, note what personal data goes in (emails, names, IP addresses, card details, prompts), whose data it is, why you collect it, who receives it, where it's stored, how long you keep it and how it's secured. Article 30 calls this the record of processing activities. The exemption for organisations under 250 people falls away when processing isn't occasional, and customer data in a SaaS never is, so assume you need one. A provisional Omnibus IV deal reached on 9 June 2026 would limit the duty for organisations under 1,000 people to high-risk processing, but it hasn't been formally adopted. Include data you never meant to collect: support-ticket attachments, logs with IP addresses, text users paste into your AI feature.

Done when: every tool has a row with data, data subjects, purpose, recipients, location, retention, security measures and role.

2. Give every vendor a role

A vendor is your processor for data it handles on your instructions and a controller for data it uses for its own purposes. Many hold both roles. Payment companies are a common place to get this wrong. Stripe is your processor for running payments and a controller for its own fraud and loss prevention, anti-money-laundering and know-your-customer checks, and product improvement. Adyen says it acts as a controller when it acquires payments. A merchant of record is the legal seller, so it is an independent controller for checkout, invoice and tax data. That's how we work: buyers contract with tiun AG, and under section 2.2 of our Data Protection Addendum we're an independent controller, neither your processor nor a joint controller. Treat each contract as evidence and check it against what the vendor actually does with the data. More in Is your merchant of record a GDPR processor or a controller?

Done when: each row names your role, their role and the evidence: the contract clause and what the vendor actually does.

3. Sign DPAs and review sub-processors

Every processor needs a contract that sets out the subject matter, duration, nature and purpose of the processing, the types of data and whose data it is. It must also cover the Article 28(3) duties: acting only on your documented instructions, confidentiality, security, rules for sub-processors, help with data requests, breaches and impact assessments, deletion or return at the end, and audits. Most SaaS vendors publish a click-through DPA; accept it and save a dated copy. Then open each processor's sub-processor list. Article 28(2) requires your prior written authorisation for sub-processors, usually given as general authorisation with a right to object to changes, so subscribe to update notices where a vendor offers them. Note which entities sit in the US and which are AI providers. Independent controllers, a merchant of record included, don't sign an Article 28 DPA for their own data; you list them as recipients in your privacy notice. Our Data Protection Addendum covers that controller-to-controller relationship, not processing on your behalf. See What to check in a payment provider's sub-processor list.

Done when: you hold a dated DPA for every processor and receive update notices for each sub-processor list.

4. Cover international transfers

GDPR has no rule on where servers sit; it regulates transfers out of the EEA (Chapter V). For each vendor that receives or can access data from outside the EEA, write down the tool that covers it: an adequacy decision (Switzerland, the UK and Japan have one; India doesn't), the EU-US Data Privacy Framework if the US company is certified, or standard contractual clauses with a transfer impact assessment. The DPF is valid in November 2026, but under pressure since the US Supreme Court's Trump v. Slaughter ruling of 29 June 2026 let the President remove FTC commissioners at will; the FTC enforces the DPF's commercial rules. See Is the EU-US Data Privacy Framework still valid?

An EU region doesn't settle the question. US-owned vendors often reach data through US support staff or sub-processors, and that access is a transfer. Separately, a cloud or communications provider under US jurisdiction can be ordered under the CLOUD Act (18 U.S.C. 2713) to disclose data in its "possession, custody, or control" wherever it's stored, so weigh that when you assess the vendor. That applies to us too: some of the providers we use are US companies. If you're a non-EU company collecting data directly from people in the EU, that collection isn't a transfer; GDPR applies to you directly under Article 3(2). In September 2024 the Commission announced a separate set of SCCs for importers in that position, and it still hasn't adopted them.

Done when: every vendor that receives or can access data from outside the EEA has a named transfer tool.

5. Pick a lawful basis for each purpose

Write one basis next to each purpose in your map. Accounts, login, delivering the product and billing can run on contract (Article 6(1)(b)), but only for people who are party to your contract. Users at a business customer usually aren't, so their basis is normally legitimate interests (Article 6(1)(f)). Legal obligation (Article 6(1)(c)) covers only duties under EU or member-state law, such as an EU country's rule on keeping invoices; a duty that comes only from Indian, US or Swiss law needs legitimate interests instead. Fraud prevention can run on legitimate interests, backed by a written balancing test. So can analytics that stores and reads nothing on the user's device; cookie- or SDK-based analytics needs consent first (step 6). Sending prompts to an LLM to run a feature your customer asked for can rest on contract; training or evaluating models on those prompts is a separate purpose that needs its own basis.

Marketing emails to individuals need consent, except under the soft opt-in for your own existing customers (ePrivacy Directive, Article 13(2)), whose details vary by member state, as do the rules for business addresses. When a merchant of record makes the sale, the sale is legally the MoR's, so you may not qualify for the soft opt-in; collecting your own opt-in is the safe route.

Done when: every purpose has one basis and your privacy notice lists them.

6. Checkout and cookies

Cookie consent comes from Article 5(3) of the ePrivacy Directive, as each EU country implements it, on top of GDPR. It covers anything stored on or read from the user's device, personal data or not. Storage that is strictly necessary for a service the user asked for, such as login and cart cookies and security cookies that protect the login, needs no consent. Analytics, session replay and ad pixels do, and that includes your pricing and checkout pages; France's CNIL allows a narrow exemption for some audience measurement. Make them load only after consent, then open your browser's developer tools and confirm they wait. With tiun as merchant of record, checkout is part of our service and we're the controller for the data it collects. You're responsible for everything on your own site around it, including any conversion tracking you fire on the success redirect.

Done when: no non-essential cookie or pixel fires before consent on any page, checkout included.

7. Retention vs erasure

Set a retention period for each data category and delete on schedule. Where EU or member-state law requires you to keep invoices, that duty beats an erasure request: Article 17(3)(b) lets you refuse. Where the duty comes only from non-EU law, Article 17(3)(b) doesn't apply: keep the invoice on legitimate interests (Article 6(1)(f)) with a written balancing test. If the person objects, you can refuse erasure only while the record is still needed for that duty and you can show compelling grounds, such as penalties under that law (Articles 17(1)(c) and 21(1)). Keep the invoice and delete the rest of the profile. Periods differ by country:

• Switzerland: 10 years for books and accounting vouchers, counted from the end of the financial year (Code of Obligations, Art. 958f).

• Germany: 8 years for accounting vouchers, invoices included, for records whose period hadn't expired by the end of 2024 (Fourth Bureaucracy Relief Act). Books and annual accounts stay at 10 years. Periods run from the end of the calendar year and are extended while a tax assessment is still open.

• France: 10 years for accounting documents and supporting vouchers under the Commercial Code (art. L123-22). Loi n° 2026-534 of 25 June 2026 also raises the tax retention period in art. L102 B of the tax procedures code from 6 to 10 years, for documents whose period expires after 1 January 2027.

• EU VAT One Stop Shop: if you register for OSS yourself instead of using a merchant of record, keep OSS records for 10 years from the end of the year of each sale.

• Other countries: ask your accountant before you set a number.

With tiun as merchant of record, the sales invoices are ours: we issue them in our own name and keep them as long as tax law requires. You keep the payout credit notes and the per-transaction tax records from your dashboard, plus your own books.

Done when: each data category has a period, a legal reason and an automated deletion job.

8. Answer data subject requests

People can ask to access, correct, delete or export their data, restrict processing, or object to it. You have one month to answer. For complex or numerous requests you can extend by two further months, if you tell the person why within the first month (Article 12(3)). In a stack like the one above, the hard part is finding everything. Use your data map as the search list, and test each tool's export and deletion features before a real request arrives. If a buyer asks you for payment or invoice data and you sell through tiun, forward the request to us at legal@tiun.io; we hold that data as controller and handle the request. Data you've exported from tiun is your own copy, so requests about it are yours to answer. UK requests follow slightly different rules (see below).

Done when: a test request on a real account returns that person's data from every tool, inside the month.

9. Prepare for breaches

Notify your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to put people at risk; if you're later, give reasons (Article 33). If the risk is high, tell the people affected without undue delay (Article 34). Without an EU establishment you don't get the one-stop shop, even with a representative, so you notify the authority in every member state where affected people live (EDPB Guidelines 9/2022). Processors must tell you without undue delay; check that each DPA says so. Log every breach, reported or not.

The Digital Omnibus proposal (COM(2025) 837) would extend the deadline to 96 hours and require notice only for breaches likely to be high-risk. It isn't law. The Council agreed its position on 21 October 2026, backing the longer deadline; Parliament's committees haven't voted yet, so negotiations between the two haven't started. Switzerland requires notice to the FDPIC "as quickly as possible" when a breach is likely to lead to a high risk, with no fixed hour limit (FADP Art. 24).

If a breach hits our side, we notify you without undue delay. Under section 7.5 of our Data Protection Addendum, we lead communication with buyers, and you don't contact them about the breach without our consent unless the law requires it.

Done when: a one-page runbook names who decides, which authorities get notified and who owns the 72-hour clock.

10. Plan your exit

Work out how you'd leave each vendor before you need to. For each contract, find the export path and format, how long exports stay available after termination, and how the vendor will delete or return your data at the end, as Article 28(3)(g) requires of processors. Ask for written confirmation.

Since 12 September 2025 the EU Data Act has required cloud and SaaS providers serving customers in the EU to support switching: notice of at most two months, a transition of at most 30 days (up to seven months where that's technically unfeasible) and at least 30 days to retrieve data. Switching charges are capped at cost until 12 January 2027 and banned after that. Custom-built services are partly exempt, and time-limited test or evaluation versions are fully exempt (Article 31). The rules cover providers wherever they're based, for business and consumer customers alike, so they apply to you too if you sell SaaS in the EU. See The EU Data Act's switching rules.

Saved cards are the hardest data to move, so ask your payment provider before signing whether it exports card data to a new PCI-compliant provider. With us, section 18.2 of our Master Services Agreement gives you at least 90 days after you leave to export customer records by CSV or API. Under section 18.1, existing subscriptions keep billing on tiun until the buyer cancels, the subscription ends, you tell us to cancel them, or we end them, which we can do at any time. We don't commit to moving saved card tokens to another provider, and under section 4.7 of our Master Services Agreement saved payment methods sit in the buyer's own tiun account. Plan for buyers re-entering card details with a new provider.

Done when: for every tool you know the export path, the post-termination window and who confirms deletion.

Founders outside the EU

GDPR reaches a company with no EU establishment when it offers goods or services to people in the EU or monitors their behaviour there (Article 3(2)). Regulators weigh the signs together: prices in euros, a site in an EU language that isn't used in your home country, ads aimed at EU countries, or marketing that mentions customers in the EU (EDPB Guidelines 3/2018). A founder in Bengaluru or Austin actively selling subscriptions to people in the EU is in scope.

Article 27 then requires you to appoint, in writing, a representative established in a member state where your users are. The exemption covers processing that is occasional, doesn't include large-scale special-category or criminal-offence data, and is unlikely to create risk. The EDPB treats processing as occasional only when it isn't carried out regularly and falls outside your regular course of business, which rules out most subscription businesses. The representative is your contact point for authorities and users and must also maintain your record of processing (Article 30). Regulators can address orders and fines to you through it, but it doesn't take over your liability. We're a Swiss company, so the rule applies to us as well: our EU representative is Rivacy GmbH in Hamburg.

Switzerland sets a higher bar. The revised FADP (Art. 14) requires a foreign controller to appoint a Swiss representative only when its processing of personal data of people in Switzerland is connected with offering them goods or services or monitoring their behaviour, and is also large-scale, regular and high-risk. All four conditions must be met. See Swiss data protection (revFADP) vs GDPR.

The UK has its own version, supervised since 30 September 2026 by the Information Commission, which replaced the ICO. UK GDPR Article 27 still requires a UK representative for non-UK companies caught by its Article 3(2); the Data (Use and Access) Act 2025 left that duty in place, and your EU representative doesn't cover the UK. The Act did change other things. Since 19 June 2026 you must give people a way to complain to you directly and acknowledge complaints within 30 days (Data Protection Act 2018, section 164A). For UK access requests, the clock pauses while you wait for clarification, and you need only make a reasonable and proportionate search (UK GDPR Articles 12A and 15(1A)). The 72-hour breach deadline is unchanged.

Recent enforcement

Regulators in the EEA and UK issued about €1.2 billion in GDPR fines in 2025, taking the total since May 2018 to €7.1 billion by 10 January 2026, according to DLA Piper's January 2026 survey. Between 28 January 2025 and 27 January 2026, breach notifications averaged 443 a day, up 22% from 363.

The fine most relevant to a non-EU SaaS company was €1 million. On 11 December 2025 the CNIL fined Mobius Solutions, an Israeli company whose platform builds personalised advertising campaigns and which had been Deezer's processor. The case began when Deezer users' data turned up on the dark web. Mobius had copied data on more than 46 million Deezer users, without Deezer's instructions, to improve its own services, still held it after the contract ended, and kept no record of processing as a processor. It said three employees made the copy without its knowledge; the CNIL held the company responsible. Mobius had no EU establishment, so the one-stop shop didn't apply, and the CNIL took jurisdiction because analysing, segmenting and hosting Deezer's user data counted as monitoring people's behaviour.

FAQ

Is Stripe GDPR compliant?

Stripe publishes a DPA (last updated 28 September 2026). It acts as your processor for running payments and as a controller for its own purposes: fraud and loss prevention, AML and KYC checks, legal compliance, choosing banks and payment-method partners, and improving its products. EEA businesses contract with Stripe Payments Europe, Limited in Ireland, but personal data also goes to Stripe, LLC in the US. Stripe's Data Transfers Addendum (updated 18 November 2025) covers that under the Data Privacy Framework first, with SCCs as the fallback. That makes Stripe usable under GDPR. Your own compliance still depends on steps 1 to 4: Stripe in your data map, its roles recorded, the DPA on file and the transfer documented.

Do I need a data protection officer?

Only where Article 37 or national law requires one. Article 37 applies when your core activities consist of large-scale regular and systematic monitoring of people, or large-scale processing of special-category or criminal-offence data, or when you're a public authority. A typical B2B SaaS meets none of these. Germany adds its own triggers: you need a DPO if, as a rule, at least 20 people are constantly engaged in automated processing of personal data, or, whatever your headcount, if you run processing that needs a data protection impact assessment or process personal data commercially for transfer or for market or opinion research (BDSG section 38). A DPO and an EU representative are separate roles, and the EDPB considers the representative role incompatible with that of an external DPO.

Does a merchant of record make me GDPR compliant?

No. With tiun as MoR, checkout, invoices and VAT records sit with us as an independent controller, and so do buyer accounts and subscription records. You still own the steps for your product data, emails and analytics: your record of processing, DPAs with your other vendors, consent on your own site, data requests about your product and your privacy notice. Section 5.2 of our Data Protection Addendum requires that notice to name us as merchant of record and independent controller and to link to our privacy policy. More on what a MoR does and doesn't take off your plate in merchant of record compliance risk.

Do I need EU hosting?

No. GDPR has no data-localisation rule; it regulates transfers out of the EEA. A US server is fine under the transfer rules if the vendor is DPF-certified, or with SCCs, a transfer impact assessment and any extra safeguards it shows you need. EU hosting cuts the number of transfers you have to document. It doesn't put data beyond US legal process if the provider, or a US parent that controls it, is subject to US jurisdiction (CLOUD Act, 18 U.S.C. 2713). We process data primarily in Switzerland and the EEA, and some of the providers we use are in the US.

Do I need both an EU and a UK representative?

If you're outside both and sell to people in both, usually yes. EU GDPR Article 27 and UK GDPR Article 27 are separate duties with the same exemptions. One provider can serve both only if it is established in the UK and in an EU member state; representative services usually do this through separate UK and EU entities.