GDPR checklist for SaaS: 16 steps for a new product

A GDPR checklist for a SaaS product starts by working out where you are a controller and where you are a processor, then puts the matching paperwork, product features and processes in place before your first customer signs. The 16 items below cover the data map, legal bases, data processing agreements, sub-processors, international transfers, security, user rights, DPIAs, breaches and cookies, in the order most early-stage teams can realistically tackle them.

Key takeaways

• Most SaaS companies are processors for the data customers upload and controllers for their own account, billing, analytics and marketing data; each role has different duties.
• A data processing agreement meeting Article 28 GDPR and a published sub-processor list are the first things B2B buyers ask for.
• Build rights requests, retention and deletion into the product, because you must answer most requests within one month.
• Plan for breaches now: controllers must notify the regulator within 72 hours where feasible, and processors must tell their customers without undue delay.
• Fines reach up to EUR 20 million or 4% of worldwide turnover, but lost enterprise deals are usually the first cost of getting it wrong.

Why does a SaaS product need its own GDPR checklist?

A SaaS product needs a tailored checklist because it handles two very different kinds of personal data at once. The General Data Protection Regulation (EU) 2016/679 treats the company that decides why and how data is processed (the controller) differently from the company that processes it on someone else's behalf (the processor). A typical B2B SaaS is both, and buyers will test you on each side in security questionnaires and contract negotiations.

The stakes are real: under Article 83, infringements of core principles, user rights or transfer rules can bring fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. In Ireland the regulator is the Data Protection Commission. This article is a practical aid, not legal advice; get professional advice on contracts and edge cases.

Part 1: Know your data

1. Build a data map. List every category of personal data the product and the business touch: user accounts, customer content, support tickets, logs, analytics, billing, marketing lists. For each, note where it is stored, who can access it and which vendors receive it.

2. Decide your role for each data set. Customer content processed on the customer's instructions usually makes you a processor. Your own sign-up, billing, product analytics and marketing data make you a controller. Write the answer down; it drives everything below.

3. Pick a legal basis for each controller purpose. Article 6 offers contract, legal obligation, legitimate interests and consent, among others. Running the service usually rests on contract; product analytics and B2B marketing often rest on legitimate interests, which needs a documented balancing test; non-essential cookies need consent.

4. Keep a record of processing activities. Article 30 requires controllers and processors to keep records. The small-business exemption for organisations with fewer than 250 employees does not apply where processing is not occasional, is likely to result in a risk or includes special categories of data, and the DPC's guidance says records must be available to it on request. A SaaS processes data continuously, so assume you need one.

Part 2: Contracts and vendors

5. Publish a data processing agreement (DPA). Article 28(3) lists what a controller-processor contract must contain: processing only on documented instructions, confidentiality, security, help with rights requests and breaches, deletion or return of data at the end, and audit rights. Have a standard DPA ready to attach to your terms.

6. Maintain a sub-processor list. Under Article 28(2), a processor cannot engage another processor without the controller's prior specific or general written authorisation, and with general authorisation it must inform the controller of changes so they can object. Publish your hosting, email, support and AI vendors and set up a change notification process.

7. Sign DPAs with your own vendors. Your cloud provider, CRM, analytics and LLM API providers process data for you. Check their terms flow down the same obligations.

8. Check international transfers. Chapter V restricts transfers outside the EEA. For US vendors, check whether they are certified under the EU-US Data Privacy Framework or rely on standard contractual clauses. Our guide on whether it is safe to use US tools under the EU-US Data Privacy Framework explains the current position.

Part 3: Build privacy into the product

9. Apply data protection by design and by default. Article 25 requires appropriate technical and organisational measures from the design stage, and by default only the data necessary for each purpose. In practice: collect less, make optional fields optional, and default sharing settings to private.

10. Secure the platform. Article 32 calls for security appropriate to the risk, including, as appropriate, pseudonymisation and encryption, ongoing confidentiality and resilience, the ability to restore data, and regular testing. Single sign-on, MFA for staff, encryption in transit and at rest, least-privilege access, logging and tested backups are the baseline buyers expect.

11. Build user rights tooling. Controllers must respond to access, erasure, rectification and portability requests without undue delay and within one month, extendable by two months for complex cases (Article 12(3)). As a processor you must help customers do this, so give admins export and delete functions rather than handling every request by hand.

12. Set retention and deletion rules. Decide how long you keep each data category, including backups and logs, and what happens when a customer leaves. Automate deletion where you can.

Part 4: Transparency and risk

13. Write a clear privacy notice. Articles 13 and 14 require you to tell people who you are, what you collect, why, on what basis, who receives it, transfers, retention and their rights. Keep the website notice (controller data) separate from the DPA (customer data).

14. Run a DPIA for high-risk processing. Article 35 requires a data protection impact assessment before processing likely to result in a high risk, especially with new technologies. AI features, profiling, large-scale monitoring and sensitive data are common triggers; see our guide to running a DPIA for AI features.

15. Decide whether you need a DPO. The DPC explains a DPO is mandatory for public bodies, for core activities involving regular and systematic monitoring on a large scale, or large-scale processing of special category or criminal data. If you appoint one, publish their contact details and notify the DPC.

16. Prepare a breach response plan. Controllers must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk (Article 33). Processors must notify the controller without undue delay. Our walkthrough of the 72-hour breach notification process in Ireland turns this into a runbook.

What about cookies and non-EU founders?

Two extra items often catch new SaaS teams. First, cookies and similar trackers on your marketing site and app are governed by the ePrivacy rules as well as GDPR; the DPC's cookie guidance explains that non-essential trackers need prior consent. Second, if your company is not established in the EU but offers services to people in the EU or monitors their behaviour, Article 27 usually requires you to designate a representative in the Union in writing, with limited exceptions for occasional, low-risk processing.

Which items should you do first?

If you only have a week, do items 1, 2, 5, 6, 13 and 16. They answer the questions in nearly every procurement review, and they force the data mapping that makes the rest straightforward. Then schedule the product items (9 to 12) into your roadmap like any other feature.

Frequently asked questions

Is a SaaS company a data controller or a processor?

Usually both. It is a processor for the personal data customers put into the product and process on their instructions, and a controller for its own account, billing, analytics and marketing data. The role is decided by who determines the purposes and means, not by what the contract calls you.

Do startups with fewer than 250 employees need a record of processing activities?

In practice, yes. The Article 30 exemption does not apply where processing is not occasional, is likely to result in a risk or involves special category data. A SaaS product processes data continuously, so the exemption rarely helps.

Do I need a data protection officer for my SaaS?

Only if your core activities involve large-scale regular and systematic monitoring or large-scale processing of special category or criminal data, or you are a public body. Many early-stage SaaS companies do not need one but still name a person responsible for data protection.

Do I need to sign a DPA with every customer?

Where you process personal data on a customer's behalf, Article 28 requires a binding contract with specific terms. Most SaaS companies publish a standard DPA that forms part of their terms of service, and negotiate changes only with larger customers.

What happens if we get GDPR wrong?

Regulators can order changes, ban processing and impose fines of up to EUR 10 million or 2% of turnover for many controller and processor obligations, and up to EUR 20 million or 4% for core principles, rights and transfers. Commercially, the earlier cost is usually failed security reviews and lost deals.

If you would like to work through this checklist for your own product, book a free 30-minute call.

Cover photo by RDNE Stock project on Pexels.