SaaS agreements – inherent risks and mitigation techniques

Benefits of the SaaS model

Under the SaaS delivery model the customer usually saves significant upfront costs. This is due to the fact that the SaaS customer does not need to pay a lump sum for a license or purchase any equipment for hosting the application and it also does not need an internal IT team to manage the underlying hardware. In addition, no installation is generally needed and hence there are no installation costs either. The customer obtains immediate access to the SaaS application as soon as it pays the corresponding subscription fee. Another clear benefit for the customer is the fact that the maintenance of the SaaS application is typically included in the subscription fee. Therefore, the customer will always benefit from using the latest updated version of the SaaS solution without having to perform any actions on its end or make any additional payments. This is due to the fact that the SaaS vendor is the one hosting and managing the application.

Other benefits of the SaaS model include its flexibility and scalability. The SaaS service is term-based and it is provided on a subscription basis. This approach not only reduces the upfront costs but also provides flexibility for the customer to not enter into a long-term relationship with the vendor before having evaluated the usefulness and the actual performance of the software. Additionally, a SaaS solution is typically easily scalable – additional new subscriptions or add-on services can be easily activated or deactivated with just a few mouse clicks.

 

Related risks and their mitigation

However, these mentioned benefits of the SaaS model come at a certain price. Inevitably, the SaaS model also brings certain inherent risks. SaaS customers need to be well aware of these risks and attempt to properly mitigate them during the negotiations phase of a SaaS agreement. This might prove to be challenging as usually the templates for SaaS services that are used for regulating the relations of the parties are drafted by the vendors. Naturally, those templates will reflect the vendor perspective when it comes to SaaS-driven contractual risks. Therefore, customers should be proactive during the negotiation process and not shy away from trying to renegotiate provisions that create unacceptable risk exposure for them.

The most significant customer risks in a typical SaaS setup stem from the inherent loss of control over customer data. As the SaaS vendor is the one who is hosting and managing the software it is also the vendor that is exerting control over the customer data that is processed by the SaaS solution. A prudent way for the customer to mitigate this risk is to insist on strict information security requirements and data privacy controls that are to be included as vendor obligations in the text of the SaaS agreement.

Accordingly, two key components of a SaaS agreement would be the data processing appendix and the information security appendix. Some exemplary measures that can reduce the risks for the availability, integrity and confidentiality of customer data would include data encryption, logical separation of customer data from other data, use of firewalls and malware protection tools, regular penetration testing, restriction of physical access to certain premises, use of multi-factor authentication and other relevant identity and access management tools.

 

 

In addition, the SaaS customer should also be able to verify the compliance of the vendor with the relevant data protection and information security obligations on the basis of audits covering the supplier systems, infrastructure and records or alternatively by way of audit reports issued by reputable third parties. When the results of those audits show certain inadequacies on the vendor side in terms of the measures for information security and data privacy, the customer should be entitled as per the contract to give recommendations with binding effect to the SaaS vendor to promptly remove those inadequacies. It is also recommended for customers prior to entering into an agreement with a SaaS vendor to check if that vendor has already obtained certain certifications proving compliance with information security and data protection requirements. These could include certificates in the area of information security and management (such as ISO 27001) or certifications for organizational controls related to operations and compliance when managing customer data (such as SOC 2).

Under the SaaS model, the customer cannot exert any control over the underlying infrastructure that is used by the SaaS provider for hosting the solution and the customer data. This makes it really important for enterprise customers to focus on a set of obligations for continuous back-ups and a robust disaster recovery model that need to be put in place by the cloud vendor so that the risks for data loss or service outages are mitigated. The disaster recovery solution should be located in a different data center and, ideally, in a different geographical location so that proper redundancy of the SaaS service can be ensured. A useful advice for EU-based companies would be to insist that the disaster recovery site is still within the boundaries of the European Union and the European Economic Area in order to avoid the burdens of the additional requirements for transfers of personal data to third countries.

Another factor for elevated risk exposure is determined by the fact that the SaaS vendor will usually have possession of customer data that belongs to a multitude of other customers and it will all be stored on its servers. Therefore, in case the measures for separation between customer data are inadequate, it could happen that one customer inadvertently gains access to data that belongs to another customer. This once again highlights the importance of putting in place robust data protection measures and information security requirements as part of a SaaS agreement.

 

 

When it comes to data ownership, it has to be underlined that the mere use of the SaaS delivery model and the fact that the SaaS vendor effectively exerts control over customer data should not lead to any changes in data ownership. Therefore, it shall be no surprise that SaaS customers often insist on having an explicit provision in the agreement stipulating that the vendor and its subcontractors would not acquire any rights whatsoever in customer data. It is also advisable for SaaS customers to try and negotiate a specific provision that requires the SaaS vendor to return all customer data after termination or expiry of the agreement within an agreed timeframe and in a specific format that is agreed by the parties.

A further critical point that should be mentioned is that under the SaaS model the supplier is allowed to unilaterally change and modify the SaaS solution during the course of the contract. This includes applying updates and upgrades and also modifying some of the functionalities of the SaaS solution. It is very important for SaaS customers to limit the risk that as a result of such modification some of the important functionalities of the solution which were initially present may be removed or hindered. Therefore, SaaS customers could insist on including a provision in the SaaS agreement stating that any modifications of the SaaS solution done by the vendor should not negatively affect its performance or the existing key functionalities.

Finally, as the SaaS model envisions that the software solution is hosted and managed by the vendor, the customer also has no direct control over the actual performance of the solution and its availability. However, there is one critical tool that customers can use to exert meaningful control over vendor performance and that is the Service Levels Agreement (SLA). This would be a separate addendum or section in the SaaS agreement which sets the required technical parameters for the performance of the SaaS solution. Those parameters could include among others the availability of the solution (the percentage of time the solution is up and running), the number of operations performed by the solution for a given time unit (for example, the number of processed transactions) or the required time for the SaaS solution to respond to a customer request. In case the SaaS vendor also provides support services to the customer, other relevant metrics in the SLA would be the response time (the time to respond to an incident) and the resolution time (the time to return the software solution back to normal operation state). It is recommended for customers to include service credits as part of the remedies for repeated or significant breaches of the SLA metrics by the SaaS vendor. Those credits are usually represented as a certain percentage of the due supplier fees that are to be invoiced. Thus, the cloud vendor would have a strong financial incentive to avoid any deviations from the agreed SLA metrics as these would erode its profit margins.