SaaS founders: NDAs, partnership agreements and DPAs online without a lawyer

SaaS founders close dozens of agreements a month — with investors, partners, contractors. See how zipzipdoc speeds up every one of those steps.

SaaS founders: NDAs, partnership agreements and DPAs online without a lawyer

A SaaS startup closes agreements practically every day — an NDA before a demo call with a potential investor, a partnership agreement with an integrated tool, a contract with an external developer or designer, a GDPR data processing agreement for a new customer.

An external lawyer is expensive and slow. An in-house lawyer? You can afford one at Series A.

Legal framework for SaaS products in the EU

A SaaS product sold to EU customers must comply with multiple regulations simultaneously:

GDPR (Regulation 2016/679): a SaaS platform as a data processor must have a DPA (Data Processing Agreement) with every customer for whom it processes personal data. This is not optional — a missing DPA is a GDPR breach with fines up to 4 % of global annual turnover (Article 83).

eIDAS: when entering into subscription agreements electronically with EU customers, the electronic signature requirements of eIDAS apply. An AdES-signed subscription agreement is fully enforceable in all 27 EU member states.

Consumer rights (if B2C): the EU Consumer Rights Directive applies if you sell to individual consumers. 14-day right of withdrawal, mandatory pre-contract disclosure, clear pricing presentation.

For SaaS founders and developers, having these documents in order before the first paying customer is not bureaucracy — it is the foundation of a trustworthy product.

Documents a SaaS founder needs most often

• NDA — before every demo call with a potential investor or partner
• Contractor agreement — developer, designer, copywriter on a work-for-hire basis
• Partnership agreement — with a distributor, reseller or integration partner
• GDPR Data Processing Agreement (DPA) — mandatory for every EU customer who entrusts you with personal data
• Software development agreement — when you outsource development to an external firm

What a DPA must contain

Under GDPR Article 28, a DPA between the SaaS platform (processor) and its customer (controller) must specify:

1. Subject-matter, duration, nature and purpose of the processing.
2. Types of personal data and categories of data subjects.
3. Obligations and rights of the controller.
4. Processor’s obligations: process only on documented instructions; confidentiality; technical and organisational security measures; sub-processor provisions; assist the controller with data subject rights; deletion or return of data.
5. List of sub-processors (AWS, Stripe, SendGrid, etc.) with the customer’s general or specific authorisation.
6. Breach notification obligations (within 72 hours to the controller).

zipzipdoc includes an up-to-date DPA template for EU SaaS products.

How SaaS founders use zipzipdoc

1. Before a demo call they send an NDA in one click — the investor signs in 2 minutes
2. After agreeing terms with a contractor they generate a service agreement with an IP clause
3. Every new customer automatically receives a DPA alongside the subscription agreement

The entire archive is in the cloud, versioned, and exportable.

Why the IP clause in a developer contract is critical

If your external developer writes code without a written IP assignment agreement, legally it is still theirs. Templates in zipzipdoc include a standard IP assignment clause — AI adapts it depending on whether it is work-for-hire or a licence.

What it costs

The free plan covers the basics. For a SaaS team with multiple founders we recommend the Pro plan ($29/month) — unlimited documents, team roles, API access.

Related contract types: NDA — non-disclosure agreement · Partnership / shareholders’ agreement · Service agreement

Try zipzipdoc for your SaaS team →

Terms of service for SaaS: what must be in your subscription agreement

The subscription agreement is the contract between your SaaS and every customer. Unlike a physical product purchase, SaaS creates an ongoing relationship with evolving obligations on both sides. Here is what a well-structured SaaS subscription agreement must address.

Core commercial terms

• Subscription scope: exactly which product tier, features and usage limits are covered. Reference your pricing page for the specific plan but define the key parameters (number of seats, storage limits, API call limits) in the contract itself.
• Term and renewal: initial term (typically 1 month or 1 year), whether it auto-renews, and the notice period required to cancel before renewal.
• Price changes: how much notice you give before a price increase, and whether existing customers are locked at their current price for the current term.
• Payment terms: due date, acceptable payment methods, consequences of non-payment (typically: suspension of access after 14 days, termination after 30 days, data deletion after 60 days).

Licence grant and restrictions

The subscription agreement defines what the customer may and may not do with your software:

• Grant: non-exclusive, non-transferable licence to use the service for the customer’s internal business purposes.
• Restrictions: may not resell, sublicence, or offer the service to third parties as part of the customer’s own product; may not reverse engineer; may not use the service for illegal purposes or to process data in violation of applicable law.
• Acceptable use policy: reference your AUP for detailed prohibitions. The AUP should be incorporated by reference into the subscription agreement.

SLA and uptime commitments

If you offer an uptime SLA (Service Level Agreement), define it precisely in the contract:

• Uptime commitment: typically 99.5–99.9 % measured monthly, excluding scheduled maintenance.
• Measurement methodology: how is uptime calculated? From which monitoring location? What constitutes “downtime” (full outage vs. degraded performance)?
• Remedies: typically service credits (not cash refunds) as a percentage of the monthly fee, scaled by the severity of the outage.
• Exclusions: customer-caused outages, force majeure, third-party service failures are typically excluded.

Limitation of liability

This clause is critical for SaaS because your software is embedded in your customers’ operations. Without a clear liability cap, a customer claiming your platform caused them business loss could make an unlimited claim.

Standard SaaS limitation of liability:

• Cap: total liability limited to the fees paid in the 12 months preceding the claim.
• Indirect damages exclusion: liability excluded for lost profits, lost data (beyond restoration from backup), reputational damage, or consequential losses.
• Carve-outs: these caps typically do not apply to wilful misconduct, death and personal injury, or data protection breaches where greater exposure is required by law.

GDPR compliance for SaaS: the full documentation stack

A SaaS product serving EU customers needs a complete, current GDPR documentation stack. Missing any element exposes you to regulatory risk and loses enterprise deals that include a legal review.

The documentation stack

| Document | Who signs it | Purpose | |---|---|---| | Privacy Policy | Public (no signature) | Transparency obligation under GDPR Article 13/14 | | Cookie Policy | Public (no signature) | ePrivacy compliance; cookie banner references it | | Terms of Service / Subscription Agreement | Customer signs | Commercial relationship | | Data Processing Agreement (DPA) | Customer signs | GDPR Article 28 compliance | | Sub-processor List | Public (no signature) | Disclosed in the DPA; updated when changed | | Security Policy (if enterprise) | Customer signs or reviews | ISO 27001 compliance, enterprise security reviews |

Enterprise B2B customers routinely require all of the above before signing a subscription agreement. Having them ready — and signable in zipzipdoc — converts enterprise deals faster.

Sub-processor management

Your DPA will list your sub-processors (AWS, Stripe, Mailgun, Sentry, Intercom, etc.). Managing this list is an ongoing obligation:

• Notify customers before adding new sub-processors (typically 30 days’ notice)
• Maintain a public sub-processor list accessible via a URL (not just in the DPA itself)
• Allow customers to object to new sub-processors within the notice period
• Sign DPAs with each sub-processor yourself (your obligations as a controller toward your customers are mirrored by your obligations as a controller/processor with your sub-processors)

Frequently asked questions

Is a DPA required for every SaaS customer?

Yes, if you process their users’ personal data on their behalf. This covers virtually every B2B SaaS that stores, processes or transmits customer data. The DPA must be in place before processing begins. Some customers request the DPA before signing the subscription agreement — having a ready template closes deals faster.

What is the difference between the NDA and the DPA?

An NDA protects commercially confidential information (business plans, product roadmaps, pricing). A DPA is a GDPR-specific contract governing how you process personal data on a customer’s behalf. They serve different legal purposes and you may need both for a new enterprise customer.

Can I add sub-processors to my DPA after signing?

Yes, under a general authorisation model — you maintain a list of sub-processors and notify customers in advance of additions. Customers have the right to object. If using specific authorisation (each sub-processor requires individual approval), additions require customer sign-off. General authorisation is more practical for SaaS at scale.

How do I handle the right of withdrawal for B2C SaaS subscriptions?

EU Consumer Rights Directive gives B2C customers a 14-day right of withdrawal from distance-sold services. For SaaS, you can include a waiver clause: the customer confirms they consent to the service beginning immediately within the withdrawal period, and therefore waive their withdrawal right. This waiver must be documented — zipzipdoc includes it in B2C subscription agreement templates.

What happens to customer data when the SaaS subscription ends?

Your DPA must specify this. Standard practice: within 30 days of subscription termination, give the customer the ability to export their data; after 60 days, delete all customer data from production systems (with a certificate of deletion available on request). Backup retention may extend longer — define this in the DPA.