DPA (Data Processing Agreement): a complete guide for SaaS startups

Why your SaaS startup needs a DPA from its first customer

A Data Processing Agreement (DPA) is the contract that provides the legal framework for processing personal data by a SaaS startup as a processor on behalf of its customers acting as controllers. It is mandatory under Article 28 of the GDPR and applies extraterritorially whenever at least one user is in the EU (Article 3 GDPR, EUR‑Lex).

In practice, without a compliant DPA, your SaaS risks losing B2B purchases, enhanced audits and administrative penalties (up to 4% of worldwide turnover for a serious GDPR breach, CNIL). Conversely, a clear, workable DPA smooths sales, reassures customers’ DPOs and accelerates investor due diligence.

For a consistent approach, align the DPA with your GDPR privacy policy and your record of processing activities.

Roles and responsibilities: controller vs processor

The GDPR distinguishes the controller (your B2B customer, which determines purposes and means) from the processor (your SaaS, which processes data on its behalf). EDPB guidelines explain these concepts and the classification criteria (EDPB, Guidelines 07/2020).

Your DPA must accurately reflect this division of roles, specify that you use data only on documented instructions from the customer, and describe respective responsibilities for security, individuals’ rights and international transfers.

Essential clauses for an Article 28 GDPR-compliant DPA

Article 28(3) GDPR requires specific particulars. At a minimum, your DPA must cover:

• Subject matter, duration, nature and purposes of processing; types of data and categories of data subjects ; obligations and rights of the controller.
• Documented instructions from the customer and the SaaS provider’s right to flag unlawful instructions (information without delay, Art. 28(3)).
• Confidentiality and undertakings by persons authorised to process data.
• Appropriate technical and organisational security measures (Art. 32 GDPR: encryption, resilience, logging, testing, etc., EUR‑Lex).
• Use of subprocessors (processing chains): conditions, prior specific or general authorisation, and the initial processor’s liability (Art. 28(2) and (4)).
• Assistance to the customer with rights requests (access, erasure, objection, etc.), data protection impact assessments (DPIAs) and prior consultations (Art. 28(3)(e) and (f), read with Art. 35‑36).
• End of contract: deletion or return of data at the customer’s choice, including certified erasure and backup deletion (Art. 28(3)(g)).
• Audits and information: making available the information necessary to demonstrate compliance and an audit right (art. 28(3)(h)).
• Breach notification to the customer without undue delay (Art. 33(2) GDPR), with minimum content (facts, impacts, measures taken).

CNIL and the EDPB emphasise that a DPA must be specific, make concrete choices and reflect effective measures, not merely copy generic wording (CNIL — general guidance; EDPB).

Good practice to formalise in schedules

• Schedule 1 — Processing description: product modules involved, flows, retention periods and legal bases defined by the customer.
• Schedule 2 — Security measures: encryption at rest/in transit, MFA, key management, vulnerability management, access reviews, tested backups, business continuity/disaster recovery plan, penetration tests and ISO 27001/SOC 2 compliance where available.
• Schedule 3 — List of processors: hosting, analytics, email marketing, support, monitoring; location, role and safeguards.

Managing subprocessors

Article 28 allows two arrangements:

• Specific authorisation: the customer approves each provider individually.
• General authorisation: you maintain an up-to-date public list, notify changes 30 days in advance and offer a reasonable right to object. This model is widely used in SaaS.

In all cases, you remain fully liable to the customer for your subprocessors’ failures (Art. 28(4)). Carry over identical GDPR obligations into your processing contracts and check safeguards (audits, certifications, data location).

Security and data breaches: what the 72-hour rule actually says

An important distinction: the controller notifies the supervisory authority within 72 hours of becoming aware of the breach (Art. 33(1) GDPR, EUR‑Lex). The processor, for its part, must notify the customer without undue delay after detecting the incident (Art. 33(2)).

Operationally, set a notification SLA (e.g. 24 business hours), reporting channels (dedicated security address), minimum content (timeline, affected systems, data categories, containment measures) and an escalation process.

Transfers outside the EU: 2021 SCCs, TIA and Data Privacy Framework

If subprocessors or teams access data from a third country, put safeguards around the transfer. The main options are:

• The Commission’s Standard Contractual Clauses 2021/914, with a transfer impact assessment (TIA) and supplementary measures if necessary (EUR‑Lex, Decision 2021/914 ; EDPB, Recommendations on supplementary measures).
• EU‑US Data Privacy Framework for transfers to certified US entities (Adequacy Decision 2023/1795).

Your DPA must specify the transfer tool used, refer to the subprocessor list and require a TIA update following a material change. For operational guidance, see our dedicated guide to transfers outside the EU and post-Schrems II SCCs.

DSA and Data Act: implications for SaaS in 2025/2026

The Digital Services Act (DSA) primarily targets intermediary services (hosting providers, platforms): notice-and-takedown obligations, handling reports and algorithmic transparency for certain categories (Commission — a guide to the DSA). If your SaaS hosts user-provided content, establish a contractual link: a DPA for personal data and terms of use/hosting agreement for DSA obligations.

The Data Act harmonises data access and sharing and governs portability and cloud switching (lower exit charges, interoperability). Anticipate these rules in your contracts and DPA to avoid friction in 2025 (CNIL – Data Act).

Recommended structure for a SaaS DPA

1. Definitions and parties (include the controller/processor relationship).
2. Subject matter and duration (reference to the main contract, modules covered).
3. Processing carried out (purposes, nature, data types, categories of individuals).
4. Customer instructions and a mechanism for challenging unlawful instructions.
5. Confidentiality and training of authorised staff.
6. Security measures (Art. 32) and governance (MFA, encryption, incident management, testing, audits, certifications, quarterly access reviews, logging, network segmentation).
7. Subprocessors: general authorisation with a right to object, an up-to-date list and accountability throughout the chain.
8. GDPR assistance (individuals’ rights, DPIAs, CNIL consultation if needed).
9. Data breaches: notification without undue delay, SLA, channels and cooperation.
10. International transfers: SCCs 2021/914, TIA, DPF where applicable and supplementary measures.
11. Audits: prioritise documentary audits (SOC 2/ISO reports, penetration tests), followed by regulated on-site audits.
12. Return/deletion of data at contract end (e.g. CSV/JSON export + deletion within 60 days).
13. Documentation and liability: keeping records current, evidence of compliance and a liability limitation coordinated with the main contract.

Examples of useful wording

• Breach notification: “The Processor shall notify the Customer without undue delay and no later than 24 business hours after discovering any personal data breach…”
• General authorisation of subprocessors: “The Processor shall maintain a public list of subprocessors. Any change shall be notified 30 days before implementation. The Customer may object on legitimate grounds…”
• End of contract: “At the Customer’s choice, the Processor shall return the data in a structured format (CSV/JSON) and delete all copies, including backups, within 60 days, then issue an erasure certificate…”

DPA compliance checklist for SaaS

• Clearly identify whether you act as a processor (B2B) and map processing activities.
• Draft a DPA before any processing, with detailed schedules (description, security, subprocessors).
• Implement and document security measures (Art. 32): encryption, MFA, access reviews, tested backups, vulnerability management and regular penetration tests.
• Establish an incident process and a customer notification SLA (without undue delay), RACI roles and crisis simulations.
• Manage subprocessors: register, due diligence, 30-day notices, objection mechanism and back-to-back contracts.
• Safeguard transfers outside the EU: SCCs 2021/914, TIA, supplementary measures and DPF where applicable.
• Provide for auditability: SOC 2 reports, ISO 27001, attestations, bug bounty/penetration tests.
• Align the DPA, SaaS agreement and terms of sale/use (retention periods, portability, exit/data-return arrangements).
• Update for the Data Act (portability, cloud switching) and, where relevant, coordinate with the DSA (moderation, transparency).
• Train teams and keep documentation ready for a CNIL inspection.

Common mistakes to avoid

• Copying a generic template that does not match your actual architecture (a risk during audits). On operations, also see how to automate contract management to reduce versioning errors.
• Confusing the 72-hour rule (customer to authority) with the processor’s obligation (without undue delay to the customer).
• Forgetting indirect transfers (24/7 support outside the EU, administrator access).
• Unlimited audits without a framework (frequency, notice, confidentiality, cost allocation).
• An outdated subprocessor list or no objection mechanism.

How to negotiate with an enterprise customer

• Audits: propose an audit ladder (compliance reports, structured Q&A, then an on-site audit if there are serious grounds).
• Incident SLA: commit to 24 business hours for the initial notification and updates every 48 hours until closure.
• Exit/data-return arrangements: provide self-service export plus paid assistance if needed; align with the Data Act’s approach.
• Subprocessors: general authorisation with a targeted right to object (legitimate grounds, no blanket objection).