GDPR Checklist for SaaS Startups

Introduction

For most SaaS founders, the first serious GDPR conversation happens when an enterprise prospect's legal or procurement team sends over a security questionnaire. The questionnaire is usually long, the questions are technical, and the deal is contingent on having defensible answers — within days, not weeks.

The good news is that enterprise GDPR diligence is largely predictable. The questions repeat, the documents required are well-defined, and the controls expected are reasonable for a B2B SaaS business. The bad news is that founders who haven't prepared can lose deals to competitors who have — not because the competitor is more compliant in practice, but because they answered the questionnaire on time with the right documents attached.

This checklist covers the ten items every B2B SaaS needs in place before the first enterprise customer asks. It is not legal advice. It is a working founder's checklist of what enterprise procurement actually expects to see.

Why Enterprise Customers Care About Your GDPR Posture

When a company processes personal data on behalf of another company, the GDPR creates a chain of responsibility. The customer is the controller — they choose to engage your SaaS and remain legally responsible for the data. Your SaaS is the processor — but Article 82 also makes processors directly liable for damage they cause, and Article 28 imposes specific processor obligations independent of the customer's controls.

In practice, this means an enterprise customer must conduct due diligence on every SaaS vendor that touches personal data. If your SaaS doesn't have the basics in place, your customer's compliance team has to choose between accepting risk on your behalf — which they will not — or finding a vendor that doesn't put them in that position.

Step 1: Identify Your Role Under the GDPR

Most B2B SaaS providers wear two GDPR hats simultaneously. They are data controllers for the data they collect about their own users for their own purposes — your customer's admin accounts, their billing information, their login activity. They are data processors for the data their customers feed into the platform about end-users — the CRM records, the support tickets, the analytics events.

Some categories blur the line — aggregated usage analytics, for instance, can be either depending on how it is used. The starting point is to document which is which. Every other compliance step depends on this classification.

Step 2: Have a Data Processing Agreement Ready

Article 28 of the GDPR requires that any processor relationship be governed by a written contract — the Data Processing Agreement (DPA) — specifying at minimum:

• The subject matter and duration of processing.
• The nature and purpose of processing.
• The type of personal data and categories of data subjects.
• The rights and obligations of the controller.
• Specific processor obligations: confidentiality, security, sub-processor management, assistance with data subject rights, breach notification, and deletion or return of data at end of contract.

In practice, this means having a standard DPA template that you attach to your enterprise contracts, usually as an addendum to the master service agreement. Enterprise procurement teams will not sign without one. Templates from established vendors like Stripe, Slack and Notion are publicly available and are reasonable starting points for your own.

Step 3: Maintain a Current Sub-Processor List

A sub-processor is any third party that processes personal data on your behalf to deliver your service — cloud hosting (AWS, GCP, Azure), email delivery (SendGrid, Postmark), product analytics (Mixpanel, Segment), customer support (Intercom, Zendesk), error monitoring (Sentry), and so on.

Article 28(2) requires that controllers be informed of, and in many interpretations consent to, sub-processors. The standard industry pattern is:

• Publish your current sub-processor list at a public URL (commonly yoursaas.com/subprocessors).
• Include a notification mechanism — email subscription or RSS — for changes.
• Give 30 days' notice before adding a new sub-processor.
• Allow customers to object, typically by terminating their contract within the notice period.

Procurement teams ask for the sub-processor URL specifically. Not having one signals operational immaturity even when your underlying compliance is sound.

Step 4: Document Technical and Organisational Measures

Article 32 requires "appropriate technical and organisational measures" — TOMs — to ensure the security of personal data. What counts as appropriate is context-dependent, but the documentation expectation is universal. Procurement teams expect to see:

• Encryption at rest (database-level) and in transit (TLS 1.2 or higher).
• Access controls — role-based permissions, MFA for staff, audit logging of administrative actions.
• Backup and recovery procedures with documented RTO and RPO.
• Vulnerability management — regular dependency updates, penetration tests for more mature SaaS.
• Employee security training, even if informal.
• Physical security of any office space from which production systems are accessed.

Most SaaS publish a one-page TOM document or include this in a broader security overview. Larger customers will ask for SOC 2 Type II or ISO 27001 certification; if you are not at that maturity yet, a credible self-described TOM document is usually accepted for mid-market deals.

Step 5: Set Up International Data Transfer Mechanisms

If your SaaS processes EU personal data and stores or accesses it from outside the European Economic Area, the GDPR requires a documented transfer mechanism. The standard options:

• EU-US Data Privacy Framework — if the importer is in the US and Data Privacy Framework certified, this provides an adequacy basis as of July 2023.
• Standard Contractual Clauses (SCCs) — the 2021 modernised SCCs are the most common option. They must be paired with a Transfer Impact Assessment documenting whether the destination country provides protection equivalent to the GDPR.
• Binding Corporate Rules — practical only for multinational groups, requires regulator approval.

For most SaaS the answer is SCCs plus a TIA, with the EU-US DPF as a fallback for US sub-processors who are certified. Have the signed SCC PDF ready to attach to enterprise contracts; have a TIA template ready to share on request.

Step 6: Maintain a Record of Processing Activities

Article 30 requires every controller and processor to maintain internal records of processing activities. The exemption for organisations under 250 employees is narrower than founders often assume — it applies only if processing is occasional AND low-risk AND does not include special categories of data. Most SaaS processing does not qualify.

A RoPA for a typical SaaS covers:

• Categories of data subjects (customers' admin users, customers' end-users, your own employees).
• Categories of personal data processed.
• Purposes of processing.
• Recipients — sub-processors, integration partners, internal teams.
• Retention periods per category.
• Security measures applied.

Most SaaS founders maintain this as a spreadsheet initially and graduate to a dedicated tool — Vanta, Drata, OneTrust — as headcount grows. The format matters less than the existence and accuracy of the record.

Step 7: Build a Data Subject Rights Workflow

GDPR Articles 15 to 22 give data subjects specific rights: access, rectification, erasure, restriction of processing, portability, objection, and rights related to automated decision-making. The standard SLA for a controller to respond is one month from receiving the request.

For a B2B SaaS acting as processor, most DSARs about end-user data come to your customer (the controller), who then asks you to comply with the technical part — exporting the data, deleting an account, providing a portable copy. You need a documented internal process:

• How a customer submits a DSAR to you (form, email, support channel).
• Who internally handles it and how it is tracked.
• Your SLA for responding back to the customer.
• How you produce the data export and verify completeness.
• How you confirm deletion when the right to erasure is invoked.

Procurement teams will ask whether your platform can technically support a DSAR. If you cannot export an end-user's data in a structured format on demand, that is a product gap, not just a process gap.

Step 8: Have a Breach Notification Process

Article 33 requires the controller to notify the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 33(2) requires processors to notify the controller "without undue delay" — interpreted in most DPAs as within 24 to 48 hours.

You need three things in place:

• An internal incident response process with clear roles, escalation paths and a decision tree for whether an incident constitutes a notifiable breach.
• A customer notification template ready to use — fill in the facts, send to the customer's named contact.
• A documented post-incident retrospective that captures cause, scope and remediation.

Many SaaS publish their incident response approach at a trust.yoursaas.com page — both as marketing collateral and as evidence to procurement. Specificity matters: "we will notify within 72 hours" reads better than "we take security seriously."

Step 9: Write a Proper Privacy Policy

Articles 13 and 14 of the GDPR require the controller to provide specific information when collecting personal data — controller identity, processing purposes, legal bases, retention periods, recipients, transfer mechanisms, DPO contact, the user's rights, and the right to lodge a complaint with a supervisory authority.

For your SaaS website (where you act as controller), the privacy policy must cover all of these for the data you collect from website visitors and customers. A generic "we use cookies and care about your privacy" template is not sufficient and is a frequent regulator-cited gap.

Step 10: Designate a Privacy Contact

Article 37 makes a formal Data Protection Officer mandatory only when (1) you are a public authority, (2) your core activities involve large-scale regular and systematic monitoring of data subjects, or (3) your core activities involve large-scale processing of special categories of data. Most early-stage B2B SaaS do not meet these thresholds and do not need a formal DPO.

However, every SaaS needs a privacy contact — a named individual responsible for privacy matters, with a published email address (typically privacy@yoursaas.com). This is what procurement looks for, not whether you have appointed a formal DPO. The contact handles privacy questions, customer DSAR escalations, and serves as the entry point for regulator correspondence if it ever arrives.

The Procurement Question Pack

Enterprise legal and security teams typically send a questionnaire covering most or all of the following. Having a single "compliance pack" document that pre-answers these dramatically shortens your sales cycle — often the difference between closing in three weeks and closing in three months.

Founders who maintain this pack in a shared folder and can attach it to a procurement email within 48 hours close more enterprise deals than founders with deeper compliance but slower response.

How ArgusEdge Helps

ArgusEdge addresses the public-facing surface of GDPR compliance — the part of your compliance posture that customers, regulators and crawlers actually inspect on your website. Specifically:

• Scans your privacy policy against the 15 GDPR Article 13/14 disclosure requirements and identifies which are missing, weak or out of date.
• Generates a privacy policy that names your actual sub-processors — the third-party scripts and services your site loads — with per-purpose legal basis and concrete retention periods.
• Audits your cookie consent flow against ePrivacy Article 5(3) and EDPB Guidelines 03/2022, with findings mapped to specific articles.
• Identifies undisclosed processors loaded on your site — the analytics, marketing or support widget your team forgot to add to the sub-processor list.
• Re-scan on demand to catch drift after marketing or product changes.

ArgusEdge does not generate DPAs, maintain a RoPA, or handle DSAR workflows. Those are internal organisational processes best served by dedicated compliance platforms (Vanta, Drata, OneTrust) or in-house tooling. ArgusEdge focuses on what your website actually does — the artefact that regulators and procurement teams will pull up first.

Final Thoughts

GDPR readiness is not a single deliverable. It is a stack of documents, processes and infrastructure choices that need to exist when an enterprise customer asks for them — which is usually three weeks before they need to sign your contract.

The founders who win those deals are not the ones with the most sophisticated compliance posture. They are the ones who responded to the security questionnaire within 48 hours, attached the right PDFs, and pointed the procurement team at credible URLs. This checklist is what "the right PDFs" actually means in practice.

Build the pack once. Reuse it on every deal. Run a free scan to find out what your website-side compliance looks like today — and where the easiest gaps are to close before the next enterprise prospect lands.