SaaS subprocessors: how to frame them in the agreement

Subprocessing in a SaaS agreement raises fundamental questions of liability and compliance. A SaaS vendor rarely operates alone: it typically relies on subprocessors for hosting, maintenance and data management. Framing these relationships properly is essential. An agreement that does not address subprocessing can expose both the vendor and the customer to significant contractual and legal risk.

Two types of SaaS subprocessors

Not all subprocessors are equivalent in a SaaS context. A distinction must be drawn between:

• Project-specific subprocessors: engaged for a specific task at the customer’s request. Their involvement typically requires the customer’s prior approval.
• General subprocessors: service providers used across the entire customer base (e.g. cloud infrastructure provider, monitoring provider). It is impractical to obtain individual customer authorisation for each of these, which is why a notification mechanism exists.

This distinction has a direct impact on how the agreement should be drafted.

Subprocessing and personal data: an additional layer of compliance

Where a subprocessor processes personal data, the GDPR imposes specific obligations regarding the transfer of data between the SaaS vendor and the subprocessor. This requires:

• A strict contractual framework through a Data Processing Agreement (DPA).
• An obligation to inform the customer about subprocessors with access to personal data.
• Appropriate security measures to ensure data confidentiality and integrity.

A critical point: a customer’s refusal of a subprocessor must not block the entire SaaS service. Without proper safeguards, a single customer could prevent a platform-wide migration by raising an objection — creating both legal and operational risk for the vendor.

Framing subprocessors in the SaaS agreement

A SaaS service depends on an ecosystem of providers. The agreement should:

• List the critical subprocessors: essential services (hosting, backup, support) and subprocessors to whom personal data is transferred must be identified.
• Specify the procedure for changing subprocessors: a notification mechanism, with or without a right of objection.
• Define security and compliance commitments: the vendor must ensure that its subprocessors comply with the GDPR and applicable standards.

For a broader perspective on SaaS contract audits, which include subprocessor verification.

Prior authorisation or notification?

The central question is whether customer authorisation is required. For a project-specific subprocessor, the agreement may require formal approval. For a general subprocessor, however, requiring specific prior authorisation is unrealistic.

The standard market practice is prior notification — sometimes referred to as general authorisation. The customer is informed of the change and has a defined period to raise an objection. If the customer objects, it cannot block the integration of the subprocessor, but may invoke a termination right if one is contractually provided.

A poorly drafted provision can create legal uncertainty:

• If it requires authorisation for all subprocessors, it blocks any technical evolution of the SaaS.
• If it provides no transparency, the customer loses all control over the outsourcing of services.
• If it does not specify the consequences of an objection, a single customer could block a critical migration affecting the entire customer base.

Consequences of an inadequate framework

Unclear management of subprocessors can lead to customer disputes, GDPR compliance failures, commercial instability, and operational risk if a single customer can block a migration necessary for the entire platform. The security of the SaaS agreement also depends on the quality of the subprocessing framework.

Best practices for securing your agreements

• Include a list of key subprocessors in the agreement annexes.
• Implement a notification mechanism for changes.
• Set a reasonable objection period (e.g. 15 days).
• Frame the right of termination in the event of disagreement.
• Include a provision specifying that a customer’s refusal of a subprocessor cannot prevent the evolution of the service for the entire customer base.

For an overview of the key provisions in a SaaS agreement, see the SaaS contracting guide.

Conclusion

A SaaS must evolve, and subprocessor management should not be an obstacle to that evolution. The right balance between flexibility and security must be found. If you need to review your subprocessing provisions, book a call.

‍