Today, most businesses use some form of software platform or other similar technology, whether as part of their core product or service offerings or internal operations or processes. While the term “software” may to some imply the traditional program and operating information that one downloads onto a computer or a network, software as a service, also known as “SaaS,” has become an increasingly popular method of software delivery for technology providers and their customers. Under a typical SaaS arrangement, the provider remotely hosts and manages software applications which are made available to customers over the internet or a private network.

To many businesses, this difference between “traditional” software and SaaS is virtually (pun intended) seamless, at least at first glance. But the use of a SaaS platform over a traditional software model inserts several new layers of risk about which SaaS providers and their customers should be aware. The parties to a SaaS transaction can attempt to mitigate these issues and risks by virtue of the agreement between them regarding delivery of the SaaS. In some cases, the terms upon which a SaaS provider delivers its services are set forth in a “click-through” document to which a user agrees prior to accessing the technology. In these cases, and unless the customer has some leverage, there is typically little to no negotiation regarding the terms, which are often one-sided in favor of the provider. In other cases, however, such as those involving narrowly tailored, enterprisewide, or otherwise more complex platforms, the bargaining power between the parties is typically more even handed, and the terms upon which a SaaS provider delivers its services are often set forth in a separate SaaS agreement or something similar. Here, certain key areas of the SaaS terms can and should often be heavily negotiated. Some of these issues are described below.

• Technical Specifications. While important for any product or service offering, technical specifications in the context of SaaS are often cast by the wayside. But defining appropriate technical specifications is crucial for establishing expectations between the parties and avoiding disputes down the road. This is especially true where the SaaS will be customized to the customer's business or processes. So, the SaaS agreement should contain technical specifications that adequately (and specifically) describe the expected functionalities of the SaaS. In most instances, the technical specifications provide the measure against which performance by the SaaS will be measured, whether by virtue of the acceptance testing process (if any), or predefined warranties or service levels.
• Warranties and Service Levels. The extent of negotiations with regard to warranties and service levels is almost always a function of how critical the SaaS is to a particular customer's business operations. Essentially, if unavailability of the SaaS means significant impediment to the effective or efficient operation of a customer's business or internal processes, then the customer would likely (and reasonably) demand warranties and service level guarantees more robust than would a customer which would not be similarly affected. In either case, however, the SaaS agreement can and should address how the parties will handle unavailability or otherwise “bad” service.
• Ownership and Protection of Data. Because SaaS providers will remotely host and make the SaaS available over the internet or a private network, customer data might also be hosted remotely and transferred over the internet or across a private network. Ownership of data, including customer data, any data derived from customer data, and any data otherwise produced by the SaaS, should always be clearly defined. And depending on the sensitivity of customer data, it might also be appropriate to address storage, transmission, restrictions on access and other security requirements.
• Data Conversion and Transition. If customer data will be imported into the SaaS, the parties will need to consider whether customer data from legacy systems can be directly imported. If it cannot, then the SaaS agreement should address data conversion, including each party's responsibility for associated costs. The agreement might also address the provider's obligations (if any) on termination with respect to data, such as the obligation to return or destroy it. Where data must be returned, the agreement should also specify the format in which it will be provided.
• Indemnity and Limitation on Liability. Indemnities and limitations on liability are relevant for purposes of any significant commercial transaction, and the same is true in the context of a SaaS. Here, the most often covered issues include intellectual property infringement and, if the SaaS provider will host or otherwise store customer data that is confidential or proprietary, security breaches. Regardless of the scope of each party's indemnification obligations, these provisions can and should be read together with the agreement's limitation on liability provisions, which serve to limit one or both party's total liability under the agreement.

Of course, the above list is nonexhaustive, and it is important to remember that each situation is different and will require its own, unique approach. In any event, when providing or procuring SaaS services, all business owners should be sure to consider the above-listed issues, among others. Without doing so, a party to a SaaS transaction could find itself locked into a unfavorable arrangement or, in the worst case scenario, subject to an unreasonable degree of risk or liability.

Stephanie Quiñones is a member of Gunster's corporate and technology & entrepreneurial companies practice group. She regularly counsels entrepreneurs and in-house counsel with business, technology, IP licensing, internet/social media and privacy issues. Contact her at [email protected].