Data Security Provisions and SaaS Master Service Agreements: Part I of II

Software as a service (or SaaS) providers hosting and processing customer or vendor data for other businesses increasingly find themselves having to address customer demands that the controlling master service agreement (MSA) include heightened data security covenants for certain sensitive data—which potentially includes personally identifiable information of the customer’s customers, vendors, and employees. These data security provisions go beyond customary confidentiality covenants whereby a party agrees not to misuse or disclose the other’s information and to protect it as though it were its own.

The data security provisions at issue tend to specify in detail minimum technical and physical security measures which the service provider must promise to deploy. They generally include separate notice, investigation, and indemnification obligations in the event of a data security breach—often, at least as initially proposed, without any demonstrable fault on the part of the SaaS provider.

The degree to which any particular data security provision is appropriate or realistic depends on the specific type of information to which it applies, the definition of “data security incident,” the specific obligations that arise in the event of a data security breach—including whether financial liability is capped or uncapped, the commercial value of the contract to the service provider, and, ultimately, the relative negotiating leverage between the business customer and the service provider.

Part I of this two-part post considers the types of data protected by the heightened data security provisions and looks at a high level at what heightened data security requirements consist.

A. What Types of Data Specifically is to be Protected by Heightened Data Security Provisions?

Where the business customer has the leverage, it tends to cause the parties contract to using its “standard” inbound MSA. At one extreme, such MSAs seek to apply the heighten data security provisions to “confidential Information” defined in the traditional sense of capturing the broad confidential information subject to nondisclosure and nonuse obligations under the agreement’s general confidentiality provisions. This may include defining “customer data” as all information provided, or caused to be provided, by the customer to the service provider, incorporating “customer data” within the defined term “confidential information,” and then applying the heightened data security provisions to all “confidential information.”

Because the financial risk from a data security breach for the customer, however, varies depending on the character of the data involved, a service provider generally can refocus the heightened data security provisions (encryption of data at rest, etc.) as properly protecting a smaller subset of information more sensitive than general confidential information. For most applications that subset includes personally identifiable information, credit card information, and HIPAA data. Finding a balance that works for both parties, however, often prolongs negotiations, involves matching the right scope of sensitive information with the right set of protective requirements, and requires carefully defined terms for different sets of sensitive information.

B. What are Heightened Data Security Provisions?

Heightened data security provisions generally require the that the service provider promise to observe protocols for both the physical protection of data storage and processing equipment at applicable physical locations (restricted access, locks, badges, etc.), and the application of technical security requirements to protect data through, for instance, encryption of data at rest and in transit, firewalls, specific authentication and access controls, and, possibly obtaining organizational audits (such as SSAE 16 Soc 1 type I and type II reports, SSAE 16 Soc 2 reports), and/or complying with third party standardized protocols such as the PCI Standard (Payment Card Industry Data Security Standard of the PCI Security Standards Council found at https://www.pcisecuritystandards.org/).

The larger (more bureaucratic customer) tends to present a security addendum consisting of five to ten pages, which, more often than not, employs “belt and suspenders” drafting: stating both broad standards for the set of data protection obligations, and, then listing specific minimum technical requirements that must be implemented under headings such as Security Architecture; Network Security; Physical Security; Authentication; Authorization and Access Control; Audit Logs; Application Security; and Web Application Security.

Revising the specific minimum technical standards usually involves an exercise where the service provider’s CTO or VP Engineering is asked to identify, preferably as a rough redline, the technical requirements with which the service provider is not compliant. This is followed by conversation to elicit any available explanation for why such technical requirements are not necessary or appropriate within the context of the service provider’s platform and service, or what explanation is available to mitigate the absence. This may, for example, be as simple as observing that the PCI Standard does not logically apply because the service provider does not process credit card information. Or, because SSAE 16 audits are known to be expensive and can take six to nine months to complete, an emerging service provider which has not obtained the requested SSAE 16 audit may be willing to commit to deliver a copy of the requested report by a specified future quarter.

In contrast to specified minimum technical requirements, the following is an example of a paragraph (from a “long form” customer security addendum) that seeks to impose data protection obligations through broad covenants:

“Service Provider hereby warrants, represents and covenants that, as of the Addendum Effective Date, it has and will at all times during the term of the Agreement, maintain a comprehensive written information security program that complies with applicable Privacy Laws (as defined below). Service Provider’s information security program shall include appropriate administrative, technical, physical, organizational and operational safeguards and other security measures that ensure (a) the safeguarding of Personal Information contained in both paper and electronic records; (b) the security and confidentiality of Personal Information in a manner consistent with applicable industry standards; (c) protection against anticipated threats or hazards to the security or integrity of Personal Information; and (d) protection against any actual or suspected unauthorized Processing, loss, use, disclosure or acquisition of or Access to any Personal Information (hereinafter “Information Security Incident”).” (emphasis added).

In fairness, it is highly unlikely that any organization that receiving and processing large volumes of data from thousands of remote authorized users accessing web-applications can “ensure” the protection against “any actual or suspected unauthorized Processing, loss, use disclosure or acquisition of or Access to any Personal Information.” This renders the above paragraph’s use of the words “warrant” and “ensure”—the most common usage of which mean “guaranty”—highly problematic, and they are best avoided.

More often than not the persons negotiating for the customer can agree that the service provider will not be required to guaranty something which is unattainable, or to represent as extant a state of facts which, in good faith, the service provider does not believe to exist and is not commercially feasible. So one is generally able to replace words of guaranty with those of promise and intention to achieve, as in “Service Provider’s information security program shall include …security measures reasonably intended to achieve (a) the safeguarding of Personal Information ….” This works best, however, where both parties have comfortably found common ground on the defined specified minimum technical requirements which will apply.

Part II of this two-part post will discuss obligations imposed by heightened data security provisions in the event of data security breach.