Developing an Information Security and Privacy Schedule for Service Provider Transactions
It is a very interesting time for information security and privacy lawyers. Information technology and the processing, storage and transmitting of sensitive and personal information is ubiquitous. At the same time (and likely as a result of this ubiquity) the legal risk and regulatory compliance environment poses increased threats and potential for significant liability. Finally, whether through cloud computing providers or traditional outsourcing of information technology functions (e.g. ASP, hosting and storage), to stay competitive and efficient, companies of all shapes and sizes are outsourcing their information technology functions to third party service providers. It is likely that adoption of these practices will increase at an increasingly faster rate.
This reality poses significant information security, privacy and legal challenges. Internal security and privacy professionals find themselves ceding control of significant decisions to third parties (“Service Providers”) concerning the implementation, maintenance, enhancement and enforcement of information security and privacy measures. Unfortunately, an organization’s legal risk and compliance obligations do not follow – in most cases they remain with the organization that chooses to outsource (the “Customer”). Of course on the Service Provider side, the main motivation is as follows: (1) secure revenue; and (2) void liability. These motivations often counter-oppose the goals of the company seeking to outsource.
These tensions play themselves out during the contract negotiations with Service Providers. It is at this juncture that the role of the Customer’s information security and privacy attorney, working closely with the Customer’s internal security and privacy professions, becomes increasingly important. To navigate these waters legal experience in the areas of data security and privacy law, contract drafting, litigation risk and negotiation tactics is crucial. However, as important, is a solid understanding of technology and substantive security and privacy matters, and how they relate to and interplay with the law. The net result is intense negotiations around the data security and privacy contract terms, which are often in the form of an information security and privacy schedule or exhibit (“InfoSec-Privacy Schedule” or “Schedule”).
In this two-part post, we explore the function and purpose of these Schedules and discuss how they might be drafted and used. Part One discusses the proactive nature of a Schedule and how it should be viewed as compliance document. Part Two details security incident response provisions that should be considered in a Schedule, and contract terms allocating risk of loss between the Customer and Service Provider.
The Multiple Functions of a Data Security and Privacy Schedule
InfoSec-Privacy Schedules serve multiple functions, some of which are for “consumption” outside of the contractual relationship. Schedules function in traditional ways by establishing the relative duties of the parties and transferring risk of loss. However, information security schedules are also “proactive” in nature in that they mandate the implementation of certain measures to prevent a security breach and comply with certain laws. In addition, Schedules serve a “compliance” function that comes into play in the event of a regulatory action or lawsuit.
Proactive Nature of an Info-Sec Privacy Schedule
InfoSec-Privacy Schedules are interesting because they require Service Providers to implement measures to (hopefully) prevent a security incident, and potential legal liability. Contrast this with a traditional non-disclosure agreement. For the most part, NDAs do not dictate how a Service Provider must protect the confidentiality of confidential information, but rather simply mandate that Service Providers not disclose or expose such information. If such exposure occurs, the Customer’s remedy is to sue the Service Provider.
In contrast, one of the overarching goals of the security schedule is to contractually increase the likelihood that the Service Provider is actively implementing measures and policies to prevent a confidentiality breach in the first instance. This outcome is advantageous for Customers: to never experience a security breach is much better than experiencing the breach and having the right to sue for breach of contract. This is especially true where a Customer’s ability to recover is limited by limitation of liability clauses, consequential damages disclaimers and the like (described more fully in Part Two of this series).
Overall, to the extent that the Service Provider essentially becomes an extension of the Customer’s internal security, the nature of these obligations makes sense. Of course, as discussed below, for both compliance and general operational risk purposes, the trick is consistency between the Customer’s internal security environment and the environments of its Service Providers.
The Infosec-Privacy Schedule as a Compliance Document
Another crucial purpose of an InfoSec-Privacy Schedule is its compliance function. When drafting a Schedule, lawyers should consider how the contract terms relate to specific requirements imposed by applicable information security and privacy laws, and reflect efforts to maintain “reasonable security.” In addition, many laws require Customers to contractually obligate Service Providers to maintain specific security and privacy measures, and the Schedule should reflect those obligations. Ultimately, lawyers negotiating these terms should ask themselves the following question:
If put before a privacy regulator in a regulatory action, or a judge or jury in a lawsuit, will the security and privacy terms in this document reflect efforts to achieve a compliant status and “reasonable security” under the law?
To address this point there are several items lawyers should consider in developing a Schedule:
- Security assessment process. Although the Schedule can serve as a useful document to support a Customer’s arguments in favor of compliance, it should typically be coupled with some sort of due security assessment or investigation. Conducting a security assessment of a Service Provider’s security measures allows the Customer to determine whether appropriate controls are in place and risk adequately mitigated. It also allows the Customer to get an idea whether specific compliance obligations can be met by the Service Provider’s systems and processing. Moreover, (as discussed below) the security assessment process can inform the Customer as to the specific requirements that should appear in the Schedule. This process should be documented so that the Customer has the ability to establish (in a regulatory or litigation context) that it properly vetted its Service Provider prior to allowing it to process, store or transmit sensitive information.
Without a due diligence process, the effectiveness of the Schedule to establish compliance will be diminished. A Schedule filled with hollow promises is not a good compliance tool. The best policy in this situation (as in many others) is to “trust, but verify” the Service Provider’s security and privacy measures.
- Reference specific information security and privacy laws. The Schedule should specifically reference those laws that the Service Provider must comply with. This can be done by using a definition for “Privacy Laws” or “Security Laws,” and indicating applicable laws within that definition. Using this approach Customers put Service Providers on notice concerning their obligations while being able to show regulators or other parties that they were specifically addressing applicable law.
- Customer’s internal control structure reflected in Service Provider’s security and privacy obligations. When outsourcing, for purposes of information security and privacy, a Customer should view their Service Provider as an extension of itself. Most Customers have gone through an extensive process of measuring their information security and privacy risk and implementing security and privacy measures to mitigate their risk to a reasonable level. The second sensitive information or systems are outsourced to a Service Provider, those internal measures no longer apply and the Customer is completely reliant on the Service Provider’s security measures.
Problems arise when the Service Provider’s measures provide less protection than the Customer's own internal controls. Allowing a Service Provider with weaker controls to handle sensitive information will be very difficult to defend in a litigation or regulatory context. As such, the Schedule should reflect a matching of risk and controls between the Customer and Service Provider, and the Service Provider’s security and privacy measures should meet or exceed those of the Customer.
- Specific controls relevant to the transaction. It may be necessary to specify specific security and privacy measures and policies that a Service Provider must have in place. For example, the Schedule might explicitly require 256-bit encryption of data at rest, or anti-virus protection. Some of these individual requirements may be dictated by specific obligations in laws, or just may be of special significance to the Customer in light of its internal infrastructure. Another approach is to tie the Service Provider’s existing security measures (assessed during the Customer’s security assessment process) to the Schedule (with requirements to update those measures, especially for long term contracts).
- Reasonable security. In addition to specific privacy and security measures, the Schedule should require an over-arching duty for the Service Provider to always maintain “reasonable security.” This duty should supersede all other security-related obligations, and reflect an ongoing obligation (as opposed to reasonable security just at the outset of the contract). As part of the general duty, the Schedule should also impose obligations to comply with industry standards. Note that industry standards may constitute reasonable security, but it is also possible that industry standards do not meet the level of reasonableness under the law. As such, the Service Provider’s reasonable security obligation should include industry standards, but not be limited to those standards.
- Assessment and enforcement rights. Things change: new vulnerabilities arise; safer security measures are developed; and Service providers can become lax or fall behind. This is especially true for long term contracts. Schedules should provide Customers with rights to conduct periodic security assessments to confirm compliance with the Schedule, regulatory compliance and whether reasonable security measures are being maintained in light of the existing risk environment. The Schedule can also require the Service Provider to give the Customer access to the Service Provider's own internal assessments or provide notice if it is in non-compliance with applicable standards or otherwise. If material non-compliance is found there should be contractual consequences, including the right to terminate the contract for cause.
These provisions serve two functions. First, just having the right to conduct an assessment can act as deterrent – Service Providers are more likely to stay compliant if they fear an assessment and contractual remedies. Second, they allow the Customer to understand the security and privacy risks they face, and whether the Service Provider is addressing these risks and achieving compliance with applicable laws. This second function is especially important for long term contracts where the risk environment is likely to change over time.
Please note that the need to address the issues above may vary depending on the nature of the transaction. Moreover, the relative bargaining power of the parties and the positions taken by the Service Provider may impact a Customer’s ability to get certain terms into a Schedule. Regardless, when drafting information security and privacy terms, thinking about how those terms might be viewed from a compliance standpoint is very important.
The Schedule serves other important functions beyond being created and used as evidence of compliance. In Part Two we address security incident response provisions and contract terms allocating risk of loss between the Customer and Service Provider.