A white-label SaaS agreement allows a SaaS vendor to make its software solution available to a third party (the customer) who then markets it under its own brand, without revealing the identity of the underlying provider to end users. This model offers significant commercial advantages, but requires particular care on several legal points. Here are the key elements to include in order to effectively secure your white-label SaaS contracts.

1. Defining the white-label concept in the agreement

The first essential step is to define precisely what “white label” means in the agreement, for example:

“Provision of the SaaS Solution for use under the Customer’s brand, without any mention of the Vendor to end users.”

It is critical to specify that the agreement covers exclusively a licence to use the SaaS platform, intended to be marketed by the customer to its own users.

2. Adapting the usage rights

The agreement must clearly set out the rights granted to the customer:

  • A non-exclusive, non-transferable licence, potentially limited to a territory or worldwide.
  • Customisation rights (name, logo, colours, URL).

The key difference from a standard SaaS agreement lies in the customisation layer, which is not available in a standard SaaS offering. For an overview of clauses typically found in a SaaS agreement, see the SaaS contracting guide.

3. Customer obligations

The customer’s obligations must be clearly defined, including:

  • A prohibition on presenting itself as the original developer of the solution (full transparency is not required, except in relation to personal data subprocessing, but should not go beyond that).
  • A prohibition on modifying the source code or engaging in any reverse engineering.
  • An obligation to comply strictly with the uses authorised under the agreement.

4. End-user access

Two approaches may be considered:

  • Option 1: the vendor contracts only with the customer, who assumes all responsibility towards end users.
  • Option 2: the vendor imposes certain obligations directly on end users through clearly referenced Terms of Use.

Whichever option is chosen, a clause must provide that the customer bears sole responsibility for the acts of its end users.

The choice between these two options has practical consequences. Under option 1, the customer handles all support and complaints from end users on its own: the vendor has no contractual relationship with them, which simplifies management but exposes the customer in the event of a problem. Under option 2, the vendor retains direct control over certain terms of use, which is useful where regulatory obligations (particularly the GDPR) require transparency regarding the identity of the technical subprocessor. This is also the preferred option where the service processes sensitive data or where the vendor wishes to frame its liability directly.

5. Intellectual property

This section must explicitly state:

  • The vendor’s exclusive ownership of the solution, even when rebranded.
  • That no intellectual property rights are transferred through customisation.
  • Strict controls on the use of trademarks and logos.

The customer owns only the brand elements that it integrates into the solution during configuration.

6. Support and maintenance

The agreement should clearly define:

  • Who is responsible for end-user support (the customer or the vendor).
  • Response times, service levels (SLA) and support procedures.

In most cases, the customer handles first-line support and the vendor provides second-line support. The vendor typically has no direct interaction with end users.

7. Personal data protection

This critical section must specify the respective roles:

  • Customer: generally the data controller.
  • Vendor: the data processor.

A detailed Data Processing Agreement (DPA) must be included, along with the customer’s obligations to inform its end users. The vendor will be disclosed as a GDPR subprocessor.

8. Liability and warranty

  • The vendor’s liability towards end users should be expressly limited.
  • An indemnification clause should be included in the event that the customer’s or its end users’ conduct causes loss to the vendor.

The objective is to create a clear separation between the vendor’s obligations (providing the technical platform) and the customer’s obligations (delivering the adapted solution to its own clients, for its own commercial purposes). This framework is similar to an indirect sales arrangement, with an additional layer relating to branding.

9. White-label pricing

The pricing model in a white-label agreement differs materially from a standard SaaS subscription. The vendor typically charges a wholesale price to the reseller, who then applies its own margin to end users. The agreement should set out the pricing structure (per-user fee, monthly flat rate, volume tiers) and make clear that the vendor may not impose a fixed resale price — the reseller retains full control over its commercial pricing. This issue is closely connected to the broader topic of variable billing in SaaS, with an additional layer of complexity arising from the distribution chain.

Conclusion

A white-label arrangement creates a three-tier contractual chain — vendor, reseller, end user — where each party must know exactly what it can and cannot do. The more precisely the agreement allocates roles and responsibilities, the lower the risk of disputes. If you are considering offering your SaaS on a white-label basis or distributing it through a partner, book a call.

Other posts


Blog image
SaaS Exit Fees Under the Data Act: What You Can Challenge

The Data Act limits what SaaS vendors can charge when you switch providers. Permitted fees, prohibited charges, and the 2027 deadline explained.

Blog image
How to Terminate a SaaS Agreement Under the Data Act: Practical Guide

Stuck in a SaaS contract your company no longer needs? The EU Data Act gives you a legal right to switch providers. Eligibility, process, and pitfalls.

Let's build together to grow your business