SaaS: Legal and practical tips – from DPA to service level agreements

SaaS solutions form an important basis for many companies' business operations. For example, they enable documents to be processed and stored jointly, business processes and customer behaviour to be analysed, and accounting to be simplified. Depending on the industry, they can also form the basis for a company's own business model vis-à-vis its customers. However, the legal peculiarities and challenges associated with these solutions are as diverse as the fields of application themselves. In this blog article, we provide helpful legal and practical tips. We answer the most important questions in our FAQs.

What type of contract is SaaS?

The categorisation of Software as a Service (SaaS) contracts is sometimes controversial and depends on which SaaS component is being considered. The categorisation of a contract also impacts the legal regulations on general terms and conditions.

In practice, the SaaS operation – i.e. the provision of software or access to online services – most closely resembles a rental agreement under Section 535 of the German Civil Code (BGB). This is because SaaS services are provided in return for a fee. In this respect, it is an ongoing obligation, whereby the provider must ensure the usability of the SaaS. This classification is based on an older judgement by the Federal Court of Justice (BGH), which classified the provision of software (as ASP – 'Application Service Providing') as a rental agreement (BGH, 15 November 2006 – XII ZR 120/04).

However, if the SaaS operation is preceded by the implementation and migration of data, such as customer or partner databases, this service component is most likely to be categorised as a contract for work and services in accordance with Section 631 of the German Civil Code (BGB). This is because the successful implementation of the data is owed here, in order to enable effective use of the SaaS afterwards. This classification is also based on the BGH's view that software customisation should generally be categorised as a contract for work and services (e.g. BGH, 5 June 2014 – VII ZR 276/13).

For example, if training is provided due to the complexity of the SaaS application, this component of the service can most likely be regarded as a service contract in accordance with Section 611 of the German Civil Code (BGB). In this case, only the training itself is owed, not an explicit guarantee of success.

Services that are often included, such as maintenance and support for SaaS, must be assigned to a contract type depending on the individual case. This depends on whether maintenance and support are necessarily part of the rental agreement, whether a specific result is owed (such as rectifying a problem) or whether action is simply owed following a complaint about a problem. The contractual provisions are the starting point for this. It is important in this respect that the individual service components are clearly separated from each other, not least because the different legal categorisation entails significant differences with regard to the associated warranty rights.

What should be included in the service description for Software as a Service (SaaS)?

The service description defines the type, scope and quality of the service provided – in the case of SaaS, it specifies exactly what the software solution can and cannot do. To avoid misunderstandings and legal disputes about the exact scope of the service, it should be as precise as possible. From a legal point of view, it is advisable to set out the available services in detail, for example in an appendix to the contract.

Note that statements in advertising materials may also be used to assess the scope of services, so these should not exceed it. Caution should also be exercised with formulations such as 'assures', 'guarantees' and 'promises' if the intention is not to actually provide a guarantee. If the software solution has known errors, these should be transparently communicated in order to prevent them from becoming the basis for legal disputes. This is particularly important in rental contract law, where strict liability applies to defects that existed at the start of the grant of use (Section 536a (1) BGB). From the provider's point of view, this liability should be minimised.

What is included in a Service Level Agreement (SLA)?

An SLA typically forms a separate part of the service contract and refers to the service description. It defines the exact service content (service levels) and the legal consequences in the event of a breach. In simple terms, the SLA regulates the availability of the provided SaaS solution and issues relating to maintenance and support availability. The following components can be included in the SLA, for example:

• Definition of service disruption;
• Definition and explanation of how availability or uptime is measured (overall or per definable component of the application);
• Information on availability (e.g. '99% per month, excluding planned maintenance times') and planned maintenance times (e.g. '1 hour per month');
• Support and response times in the event of a disruption (e.g. 'within 24 hours');
• Recovery time and backups;
• Distribution of the burden of proof;
• Monitoring and reporting;
• Customer rights and possible contractual penalties;
• Termination options.

To what extent can liability be limited with SaaS?

As most SaaS contracts are pre-formulated, they are subject to GTC requirements. Unreasonably disadvantageous clauses are therefore not permitted. In particular, the provider cannot limit liability in the following cases:

• Intent
  
• Gross negligence
  
• Injury to life, limb or health.
  
• Malice
  
• Assumption of a guarantee (e.g. in the SLA).

On the other hand, liability can generally be limited in cases of simple negligence, unless particularly important obligations, known as 'cardinal obligations', are involved. According to established Federal Court of Justice case law, liability for breach of these obligations must cover at least the typical foreseeable contractual damage (the so-called 'foreseeability formula').

However, even if it is possible to exclude liability in principle, you should be very careful with blanket exclusions, as these are often ineffective in the following cases in particular:

• Indirect/direct damage
• Loss of profit
• loss of business
• In the event of data loss.

Is a data processing agreement (DPA) required?

Software as a Service generally constitutes order processing within the meaning of Art. 28 of the GDPR. Therefore, the user commissions the SaaS provider to process personal data, deciding on the purposes and main means of processing. Without further ado, the provider may not process the data for other purposes (e.g. its own business interests), at least within the scope of the DPA, and is therefore subject to a prohibition of use. These rules are set out in a data processing agreement (DPA), which major providers often make publicly available.

The DPA should be checked for compliance with the minimum standards set out in Art. 28 GDPR, before signing or using the SaaS. It is important to do this because the user is liable if they have not ensured compliance with the legal requirements, i.e. if the necessary technical and organisational measures (TOMs) for data processing are not in place, despite having a data protection-compliant DPA. Liability cannot be completely excluded under the GDPR.

Is the Privacy Shield judgement applicable?

For Software as a Service (SaaS) applications offered by US service providers, or for which European providers use US service providers for hosting (e.g. Amazon Web Services (AWS) and Microsoft Azure), the ECJ's ruling on the transfer of data to third countries such as the USA ('Schrems II') must also be observed. This means that it is necessary to check who processes the data, where, and under what contractual and technical conditions. This applies not only to data stored and processed in the USA, but also to data held by US service provider subsidiaries in the European Union, particularly in light of the US CLOUD Act.

The ECJ states that, if standard contractual clauses (SCCs) are used, additional measures (such as encrypting the data's content and managing the keys) must be reviewed and implemented to ensure an adequate level of data protection. This requires comprehensive advice.

Does SaaS require cookie management?

The current legal framework for the use of cookies and similar technologies must be observed when using software as a service. In its ruling on 'Planet49' (BGH judgement of 28 May 2020, reference I ZR 7/16), the BGH clarified that it expects the European ePrivacy Directive to be correctly implemented in Germany, and paved the way for the obligation to obtain consent for cookies and similar technologies by interpreting Section 15(3) sentence 1 TMG in line with the Directive. Following the BGH judgement, a new legal regulation will be introduced as part of the TMG reform.

However, even before this comes into effect, cookies and similar technologies may only be set or used in SaaS applications without consent if they are technically necessary for the operation of the SaaS solution. In the case of software as a service, this ultimately corresponds to the objective necessity for a contract in accordance with Art. 6 para. 1 lit. b GDPR. Therefore, tools for analysing usage or tracking users are probably not permitted in fee-based SaaS applications without consent.

Such optional tools may not be integrated 'through the back door' via contractual provisions in the general terms and conditions either. Consent obtained through a mandatory tick box when concluding the SaaS contract would also be inadmissible. This would only be possible for free SaaS applications if personal data were to be provided to a third party.

Is the SaaS provider responsible for carrying out upgrades?

The rental agreement for the SaaS application offered obligates the SaaS provider to carry out maintenance and repairs. This includes maintenance work such as bug fixing and security updates to ensure the SaaS is usable (i.e. fit for the purposes set out in the contract). However, unless this has been contractually agreed (e.g. automatic upgrade to the latest version), the provider is not obliged to further develop the SaaS through upgrades.

Can open source software be integrated into SaaS?

The extent to which open source can be integrated into a SaaS application depends on the software licence under which it was published. These often stipulate extensive limitations of liability, meaning the SaaS provider may be liable for errors due to the open source component of its SaaS. It is therefore important to check the software licence comprehensively.

To avoid liability issues relating to open source, it is advisable to clearly separate these components from the SaaS, for example by offering them as optional extras.

Is application documentation mandatory?

According to BGH case law, documentation on an application's functions is a primary performance obligation in the area of traditional software licensing and is therefore an 'essential, if not indispensable, contractual obligation' (BGH, 16/12/2003 – X ZR 129/01). With some reservations, such an obligation must also be affirmed for SaaS solutions. Whether the documentation for the SaaS application fulfils the legal requirements depends on its usefulness to the user. It can simply be made available online with the option to print it out. It is also important that the documentation is up to date and easy to understand. The necessary scope and content of the documentation depends on the respective SaaS application and user group.

What is the significance of the Digital Content Directive for SaaS?

The EU's Digital Content Directive covers contracts between companies and consumers (B2C) for the supply of digital content and services. The directive aims to standardise the legal framework within the EU, and its broad scope also covers software as a service (SaaS) applications for consumers. This includes health and sports apps, as well as applications for preparing tax returns, for example. Free SaaS applications financed by advertising are also covered, as personal data is expressly recognised as 'consideration' for digital content and services.

The Digital Content Directive identifies functionality, compatibility, accessibility, continuity and security as key performance characteristics. These should be benchmarked against the reasonable expectations of consumers and the usual characteristics of comparable digital content and services. Importantly, the Digital Content Directive stipulates an obligation to provide updates and reverses the burden of proof for a period of one year.

The directive must be transposed into German national law by 01/07/2021. The implemented regulations will then take effect on 01.01.2022. Companies offering digital content and services to consumers should familiarise themselves with the upcoming legal requirements and seek advice now.

Conclusion and recommendation

SaaS offers great potential, but it also presents some legal peculiarities and challenges. In particular, many aspects must be considered with regard to contractual categorisation, contract design, and service level agreements. Data protection issues must also be taken into account, such as the use of cookies and similar technologies, as well as the transfer of data to third countries, including the USA.

Overall, SaaS results in increased requirements for both providers and users. Legal advice is therefore recommended for all users and providers of SaaS. We would be happy to advise you on how to offer or use SaaS solutions in a legally and data protection compliant manner, and recognise contractual peculiarities.