How to Draft GDPR-compliant Data Processing Agreements (DPAs) for Cross-border Saas Contracts in France

To draft a GDPR-compliant data processing agreement (DPA) for a cross-border SaaS arrangement in France, the starting point should be the service itself rather than the template. A workable DPA needs to reflect how the platform operates in practice: what personal data the provider processes, which subprocessors support the service, what security framework applies, where data may be transferred, and how changes are managed over time.

SaaS services are typically standardised, multi-tenant environments serving multiple customers. The objective is therefore not to redesign the provider’s operating model for each contract, but to ensure that the DPA complies with the GDPR, accurately reflects the service and gives the customer meaningful protection where it matters.

This guide focuses on the issues that tend to matter most in practice: scope and roles, security, subprocessors, international transfers, breach response, audits and liability.

Key GDPR requirements for DPAs in France

The legal starting point is Article 28 GDPR, which sets out the minimum contractual requirements applicable where a processor handles personal data on behalf of a controller.

In France, these requirements apply alongside the Loi n°78-17 du 6 janvier 1978 and relevant CNIL guidance. There is no separate French DPA regime: Article 28 remains the contractual foundation, although additional French requirements may be relevant depending on the data, processing or sector involved.

The DPA should set out the subject matter and duration of the processing, its nature and purpose, the categories of personal data and data subjects, and the rights and obligations of the controller. It must also address documented instructions, confidentiality, security, subprocessors, data-subject rights, breach assistance, deletion or return of data, and audit rights.

The practical point is that these mandatory elements should not simply be copied into a template. They should reflect the service actually being provided.

Define the processing covered by the DPA

In a SaaS DPA, the starting point is usually clear: the provider processes certain personal data on behalf of the customer and therefore acts as processor for that processing.

The more useful exercise is to define precisely what falls within that processor relationship and identify any separate processing for which the provider may act in another capacity.

For customer data processed to provide the SaaS service, the customer will commonly act as controller and the provider as processor. The same provider may nevertheless process certain information separately, for example for account administration, billing, fraud prevention or compliance purposes, depending on the circumstances.

Maintenance, troubleshooting, analytics and service improvement also require context. SaaS platforms naturally need to be maintained, secured and improved over time, often for the benefit of their customer base as a whole. The relevant question is what the personal data is being used for and whether that activity falls within the customer’s documented instructions.

Where personal data is reused for a separate purpose determined by the provider, the parties should consider whether that processing falls outside the processor role and address it accordingly.

The same principle applies to AI functionality or model training: the analysis should follow the actual data use rather than assuming that all product improvement is either necessarily permitted or necessarily prohibited.

Data mapping and processing annexes

The DPA annex should reflect the processing accurately: categories of data subjects, types of personal data, processing activities, duration of processing and, where appropriate, retention and deletion arrangements.

For cross-border SaaS, it is also useful to make sure that the DPA, subprocessor information and transfer documentation are consistent with the provider’s actual hosting and support architecture.

The level of contractual scrutiny should also remain proportionate. A platform processing limited business contact data does not necessarily present the same risk profile as one processing large volumes of customer records, employee information or special-category data.

A scope clause might provide that the processor processes personal data only for the purpose of providing the services and in accordance with the controller’s documented instructions. The commercial drafting challenge is to define that purpose clearly enough to protect the customer while still giving the provider sufficient room to deliver, maintain and support the service.

Security measures: assess the provider’s framework rather than redesign it

Established SaaS providers will ordinarily operate a common security framework across their platform and customer base.

The customer’s task is therefore to understand those measures, assess whether they are appropriate to the data and risk involved, and ensure that the relevant commitments are properly incorporated into the contractual framework.

For a standardised, multi-tenant service, it will rarely be realistic or necessary for an individual customer to redesign the provider’s security architecture through the DPA.

The security documentation should typically address encryption, access controls, logging and monitoring, backup and resilience, secure development, and appropriate personnel-security measures.

Recognised standards and assurance frameworks can provide useful evidence. ISO/IEC 27001, SOC reports and, where relevant in a French context, ANSSI guidance may all inform the review.

A common and useful SaaS commitment is that the provider will not materially reduce the overall level of security during the contractual term, rather than attempting to freeze every individual technical control in place.

Security testing

Customers should also obtain appropriate comfort regarding the provider’s vulnerability-management and security-testing programme.

Depending on the service, this may include evidence of vulnerability scanning and penetration testing carried out by the provider or independent third parties.

In practice, SaaS providers commonly make available summary copies or executive summaries of penetration-test results, together with relevant certifications and assurance materials. This allows the customer to verify that testing takes place and understand material findings without exposing sensitive security information relating to a shared platform.

Subprocessors: general authorisation as the standard SaaS model

SaaS platforms commonly rely on third parties for hosting, communications, monitoring, support and other parts of the service.

Because those suppliers often support a shared platform used by multiple customers, requiring individual approval each time a subprocessor changes is generally difficult to operate at scale.

Article 28 expressly permits general written authorisation for subprocessors. In SaaS arrangements, this is therefore commonly the appropriate model: the customer gives general authorisation, subject to transparency around the subprocessors used and a mechanism for dealing with additions or replacements.

Specific prior authorisation remains possible, but is generally more suited to genuinely bespoke processing arrangements.

Notice and objection

Where general authorisation applies, the provider should notify the customer of intended additions or replacements within the period specified in the DPA so that the customer has an opportunity to object.

In practice, objections are usually expected to be based on reasonable data-protection grounds.

The contract should also explain what happens if an objection is raised. A practical structure is for the provider to use reasonable efforts to address the concern, including by proposing a commercially reasonable alternative where available. If the issue cannot be resolved, the agreement may allow termination of the affected service or functionality.

That is generally more workable than an absolute veto over the provider’s wider supplier architecture.

Flow-down obligations

The DPA should require the provider to impose materially equivalent data-protection obligations on its subprocessors, insofar as relevant to the subcontracted processing.

The provider should remain responsible to the customer for the performance of the relevant obligations by those subprocessors.

From the customer’s perspective, this maintains a clear contractual route through the SaaS provider rather than requiring it to pursue suppliers further down the chain.

Keep the multi-tenant model in mind

A SaaS provider will often be delivering substantially the same platform, security framework, subprocessor architecture and operational processes to many customers.

That does not reduce the customer’s entitlement to a compliant DPA or meaningful contractual protection. It does, however, affect which requests can realistically be implemented for one customer.

The most productive negotiations therefore tend to focus on the points that materially affect risk: permitted uses of data, security commitments, transfer mechanisms, subprocessor transparency, breach response and liability.

International transfers: identify the mechanism first

For cross-border SaaS, one of the most important practical questions is simply: what mechanism permits the transfer?

Where the relevant recipient is covered by a European Commission adequacy decision, personal data may be transferred on that basis without an additional Article 46 safeguard.

For transfers to the United States, the EU-U.S. Data Privacy Framework provides an adequacy route for organisations certified under it. The parties should therefore check whether the relevant recipient is actually certified and whether the transfer falls within the scope of that certification.

Where adequacy applies, SCCs are not legally required in addition. Some customers nevertheless request them as additional contractual comfort or as a fallback if the adequacy basis later ceases to apply. That can be agreed commercially, but the drafting should distinguish between the mechanism legally relied upon and any additional protections the parties have chosen to include.

Where no adequacy decision applies, the European Commission’s Standard Contractual Clauses are commonly used. The appropriate module should be selected and the annexes completed so that they reflect the actual processing and subprocessor architecture.

Binding Corporate Rules may be relevant for intra-group transfers within multinational organisations, while Article 49 derogations should not generally be treated as the default mechanism for routine SaaS processing.

Separate arrangements may also be relevant for UK or Swiss-origin data, but those regimes should be kept distinct from the EU GDPR analysis.

Transfer Impact Assessments

Where the parties rely on an Article 46 safeguard such as the SCCs, they must consider whether the laws and practices of the destination country affect the effectiveness of that safeguard and whether supplementary measures are required.

In practice, this is commonly documented through a Transfer Impact Assessment.

The exporter is responsible for ensuring that the relevant transfer assessment is carried out and documented, but the exercise necessarily requires cooperation from the importer. The importer should provide reasonable assistance and information within its control, including relevant details concerning locations, safeguards, subprocessing arrangements and, where applicable, government-access considerations.

A practical TIA will generally:

1. identify the data being transferred, the recipient and destination;
2. identify the transfer mechanism;
3. assess the relevant law and practice of the destination country;
4. identify supplementary measures where required; and
5. document the conclusion and keep it under review where circumstances materially change.

The exercise should remain proportionate to the transfer actually taking place. The relevant analysis depends on the data, recipient, technical architecture and safeguards involved, not simply on the fact that the service has an international footprint.

The parties should also ensure that relevant onward transfers to subprocessors are appropriately covered. EU hosting alone does not necessarily answer the transfer question if personal data is made available to other entities outside the EEA for support or other processing.

Breach notification

A controller must notify the competent supervisory authority, CNIL in France, without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals.

The processor must therefore provide the controller with information promptly enough for the controller to assess and meet its own obligations.

The DPA should require notification without undue delay after the processor becomes aware of a breach. The parties may also agree a tighter contractual period, often 24 to 48 hours.

That shorter period is a contractual commitment, not the processor’s statutory GDPR deadline.

Where the full facts are not yet known, the agreement should allow information to be provided in phases. Requiring a completed investigation before initial notification would be difficult to reconcile with a short reporting period.

It is also useful to distinguish between a wider security incident and a Personal Data Breach. A customer does not necessarily need notification of every unsuccessful security event, but it does need timely information when personal data processed on its behalf is affected.

Audit rights: verification should reflect the SaaS model

Article 28 requires processors to make available the information needed to demonstrate compliance and to allow for and contribute to audits, including inspections.

For cloud-based, multi-tenant SaaS services, routine verification commonly takes place through the provider’s existing documentation, independent certifications, audit reports and responses to reasonable information requests.

That can provide meaningful assurance while protecting the confidentiality and security of the platform and other customers.

Further audit rights should remain available where the existing evidence is insufficient, for example following a material personal data breach, where required by a regulator, or where a specific and substantiated compliance concern arises.

The clause should therefore address scope, frequency, notice, confidentiality, costs and the need to minimise unnecessary disruption.

Liability and the main SaaS agreement

The DPA should not be negotiated in isolation from the main SaaS agreement.

The parties should understand which liability cap applies to the DPA, how any indemnities interact with that cap, what termination rights exist and which document prevails in the event of conflict.

Processors commonly seek to cap liability by reference to fees paid, while customers may seek different treatment for certain data-protection or security failures.

Depending on the data, the service and the parties’ bargaining position, a higher “super-cap” for specified privacy or security claims can provide a practical compromise.

Before debating the amount of the cap, however, the parties should identify what actually falls within it. DPA breaches, confidentiality issues, security incidents, indemnities and subprocessor failures do not necessarily need to be treated identically.

The DPA should also be checked against the main agreement for consistency on security commitments, termination, return or deletion of data, audit costs and order of precedence.

AI-enabled SaaS: keep the DPA focused on personal data

Where the SaaS platform incorporates AI functionality, the first DPA question is whether and how personal data is used by that functionality.

If personal data is processed solely to provide the contracted feature, that use should be reflected in the processing instructions. If data is also reused for a separate purpose, such as certain model-training activities, the parties should consider the appropriate role allocation and wider GDPR implications.

Not every issue arising from an AI-enabled service belongs in the DPA. The DPA should remain focused on personal-data processing, while broader questions concerning AI functionality, outputs, regulatory allocation, performance or change management may sit more naturally in the main SaaS agreement or a dedicated AI schedule.

Practical DPA negotiation checklist

The following points form the backbone of a robust SaaS DPA:

• Scope and instructions: define the processing clearly and identify any separate provider processing.
• Processing annex: ensure it reflects the actual service, data and data subjects involved.
• Security: rely on appropriate Article 32 commitments supported by the provider’s existing technical and organisational measures.
• Subprocessors: use general authorisation where appropriate, with notice, objection rights and materially equivalent flow-down obligations.
• International transfers: rely on adequacy where available or an appropriate Article 46 mechanism such as the SCCs.
• Transfer assessment: complete a TIA where required, with reasonable assistance from the importer.
• Breach notification: provide for prompt notification and staged information where necessary.
• Audit rights: use certifications, reports and documentation as the usual first line of verification, with further rights where justified.
• Return and deletion: address end-of-term handling, including realistic backup and deletion cycles.
• Main-agreement interface: check precedence, liability, termination, security and exit provisions.
• Liability: calibrate caps, carve-outs and indemnities to the actual service and risk.
• AI and data reuse: clarify how personal data may be used by AI functionality and address separate processing in the appropriate contractual document.

Conclusion

A strong SaaS DPA is not necessarily the one containing the greatest number of bespoke obligations. It is one that accurately reflects the processing, complies with Article 28, gives the customer meaningful visibility and protection, and remains workable within the provider’s operating model.

In practice, the key questions are straightforward: what data is being processed, which subprocessors are involved, what security framework applies, which transfer mechanism is relied upon, how changes will be notified, and what remedies apply if something material changes or goes wrong.

The objective is a DPA that is GDPR-compliant, commercially proportionate and capable of working in practice for both sides of the SaaS relationship.

This content is for informational purposes only and does not constitute legal advice. Consult a qualified lawyer for tailored advice.

Sources

1. Regulation (EU) 2016/679 (GDPR), consolidated text (EUR-Lex)
2. Loi n°78-17 du 6 janvier 1978 (Loi Informatique et Libertés) (Legifrance)
3. Commission Nationale de l’Informatique et des Libertés (CNIL)
4. European Data Protection Board (EDPB), Guidelines & Recommendations
5. European Commission, Standard Contractual Clauses (SCCs)
6. Court of Justice of the European Union, Schrems II (C-311/18) (CURIA)
7. Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI)
8. Regulation (EU) 2024/1689 (Artificial Intelligence Act).