Info Law Group : Technology Lawyers & Attorneys : Information Law Group : Privacy, Security & Intellectual Property Law

A Short History of Cyber Insurance Coverage*

*This section ended up longer than I anticipated. If you already have a base knowledge of cyber coverage or don’t want to bother with some historical background, please skip ahead to this section: "Where Privacy and Security Risk Breaks Down in Cloud Computing Contracts"

In the early 2000s, just around the “DotCom Bust”, some insurers began developing a product designed to address the financial loss that might arise out of a data breach. This was a time where most “brick and mortar” companies were just beginning to leverage the economic potential of the Internet. At that time insurers wanted to target the big “dotcom” companies like Amazon, Yahoo, eBay, Google, etc., and other companies pioneering e-commerce and online retailing. At some point, somebody dubbed this type of insurance “cyber insurance.”

The early cyber policies included liability and property components. The liability coverages addressed claim expenses and liability arising out of a security breach of the insured’s computer systems (some early policies only covered “technical” security breaches, as opposed to policy violation-based security breaches). The property-related components covered business interruption and data asset loss/damage arising out of a data breach (during the holiday season many online retailers suddenly developed a tasted for business interruption coverage after realizing just how negatively their business would be impacted by a denial of service attack).  Additional first party coverages included cyber-extortion coverage and crisis management/PR coverage.

Unfortunately for the carriers, it was not easy to get people to understand the need for this coverage (and that is still a challenge today, but certainly a lesser challenge with all of the security and privacy news constantly streaming). Early on there were very few lawsuits and regulators were just beginning to consider enforcement of relatively new statutes like GLB and HIPAA.

Two things changed that made cyber insurance much more relevant. One was a rather sudden event, and the other more gradual.

First, in 2003, California passed SB1386, the world’s first breach notification law. The reality then (as now) is that companies suffer security breaches each and every day. Prior to SB1386, however, breaches of personal information simply went unreported. With SB1386 and the subsequent passage of breach notice laws in 45 other states (and now coming internationally), the risk profile changed for data breaches. Instead of burying the breaches, companies were required to incur significant direct expenses to investigate security breaches and comply with applicable breach notice laws, including the offering of credit monitoring to affected individuals (which is not legally required by existing breach notice laws, but is optionally provided by many companies or "suggested" by state regulators). As a result, the plaintiffs’ bar now had notice of security breaches and began filing class action lawsuits after big breaches (usually involving high-profile brand name organizations). As such, cyber insurance coverage went from coverage addressing a hypothetical risk of future lawsuits, to a coverage addressing real-life risk (and now we have lawsuits getting deeper into litigation and public settlements of these types of cases). Moreover, shortly after the passage of SB 1386 many cyber insurance policies began covering the direct costs associated with complying with breach notification laws, including attorney fees, forensic investigation expenses, printing and mailing costs, credit monitoring expenses and call center expenses.  Breach notification costs are direct and almost unavoidable after a personal information breach.  Regardless of lawsuit activity, a direct financial rationale for cyber insurance coverage now existed.

The other change that occurred more gradually over time, but which has had a significant impact concerning the frequency and magnitude of data breaches was organized crime. In the early 2000s hacking was more of an exercise in annoyance or a used for bragging purposes. Hackers at that time wanted their exploits talked about and know. They wanted credit for hacking into or bringing down a sophisticated company (or better yet a division of the Federal Government or military). As such, when an attack happened it was discovered and remediated, and that would be the end of it.

True criminals, of course, are less interested in such notoriety. In fact, when trying to steal thousands/millions of records to commit identity theft or credit card fraud it is much better to NOT be detected. Lingering on a company’s network taking information for months or years is a much more profitable endeavor. Recognizing that this type of crime is low risk (it can be performed from thousands of miles away in Eastern Europe with almost not chance of getting caught) and high reward, organized crime flooded into the space. And in this context the word “organized” is truly appropriate – these enterprises retain very smart IT-oriented people that use every tool possible to scale and automate their crimes. They leverage the communication tools on the Internet to fence their “goods” creating, for example, wholesale and retail markets for credit cards, or “eBay”-like auction sites to hawk their illicit wares (e.g. valuable information). The change in orientation described above has essentially resulted in a 24/7/365 relentless crime machine constantly attacking and looking for new ways to attack, and always seeming to be one step ahead of those seeking to stop them. That is why we read about security and privacy breaches practically every day in the newspaper.

Fast-forward to present time. Cyber insurance is a much more established market with more carriers entering on a regular basis. There are primary and excess markets available for big risks, and companies of all sizes are looking at cyber more as a mandatory purchase rather than discretionary. As the world continues to change at seemingly light-speed and cyber risks increase (with the advent of hacktivism, social media and the consumerization of IT/BYOD ) the need for cyber is also growing. With competition pushing cyber insurance prices down, and significant security and privacy risk being retained by organizations, risk transfer is becoming very attractive (and from an overall big picture systemic point of view, spreading is risk is also attractive). Another area where cyber may help smooth out security and privacy risk is with cloud computing.

Where Privacy and Security Risk Breaks Down in Cloud Computing Contracts

As we have written extensively of in the past, Cloud computing raises significant privacy and security risks that are often difficult to hammer out in a Cloud computing negotiation (to the extent a Cloud customer gets a chance to negotiate at all). The net result of these contract negotiation difficulties and Cloud provider unwillingness in many cases to take on meaningful risk contractually, is that the risk is retained solely by the Cloud customer.  The following examples outline the privacy and security-related Cloud issues that impact the Cloud customer's risk:

• a Cloud provider failing to maintain reasonable security to prevent data breaches;

• a Cloud provider failing to comply with privacy and security laws applicable to the Cloud customer;

• a Cloud provider refusing to allow a Cloud customer to conduct its own independent forensic investigation of a data breach suffered by a Cloud provider;

• potential conflict of interests with respect a Cloud provider’s handling a data breach that may have been the fault of the Cloud provider, including failing to cooperate with its Cloud customers if that cooperation could adversely impact the Cloud provider;

• the Cloud customer’s potential obligation to comply with breach notice laws, including absorbing expenses for legal fees, forensic investigators, printing and mailing, credit monitoring and maintain a call center;

• lawsuits and regulatory actions against the Cloud customer because of Cloud provider security and privacy breaches, and the legal fees, judgments, fines, penalties and settlement costs associated with them; and

• Cloud providers seeking to leverage and data mine Cloud customer information being processed in the Cloud.

The justification used by Cloud providers to avoid responsibilities for these risks and the costs associated with them is essentially risk aggregation. Cloud providers maintain that, because they serve hundreds or thousands of customers on shared computing resources, a single attack could expose Cloud providers to liability from all of those customers at the same time. In fact, we already have one example involving a business interruption of a Cloud provider that demonstrates how multiple customers can be affected by a security breach. They also claim that independent forensic investigations by customers in the wake of a data breach are not possible because they cannot accommodate multiple customers at one time, and even if they could a forensic assessment would essentially expose each Cloud customer’s data to every Cloud customer conducting such an investigation.

Cyber Insurance: Addressing Retained Risk in the Cloud

So how does cyber insurance fit into this picture? As it currently stands, cyber insurance can be a very valuable tool for Cloud customers who are not able to get their providers to contractually take financial responsibility for security and privacy risk. Most cyber insurance policies cover data security and privacy breaches of not only the computer networks directly under the control of the insured, but also those computer networks operated by third parties for or on behalf of the insured. What this means in the Cloud context is that most cyber insurance policies may cover data breaches of the Cloud provider’s systems where the Cloud customer's/insured's data is stored and processed on those systems. This coverage will typically include most of the expenses listed above, including those direct expenses to comply with breach notice laws and costs to defend lawsuits and regulatory actions arising out of Cloud provider data breaches. As such, in the event a Cloud customer cannot get reasonable contract terms, assuming it has purchased the correct cyber coverage, it will have a fallback risk transfer and will not be retaining that risk solely on its own.

Is there a catch? Not really currently, except of course the premium that must be paid and the fact that most cyber insurance policies have a self-insured retention that must be satisfied by the insured before the carriers is required to pay. However, there may be longer term problems that arise for the carriers.

At this point, whether they like it or not, carriers whose cyber insurance policies cover security and privacy breaches of third party service providers are already beginning to aggregate their risk when it comes to Cloud providers. Imagine a world with a relatively small number of Cloud providers serving a much larger customer base (to some degree we may already live in such a world considering the dominance of Google, Amazon, Rackspace and other big cloud players). Many insureds/Cloud customers are going to be dealing with this relatively small number of Cloud providers. For example, I am sure that for most cyber insurance companies, if they were to check their books, would find that many of their insureds already use the same Cloud providers and/or other third party service providers to store and process the insureds’ data. Further consolidation of Cloud provider, should that occur, will only increase the aggregation of risk.

However, as long as cyber insurance is more widely adopted, the aggregation risk may be manageable. The entire purpose of insurance is to spread the risk across a wide community of insureds, and by doing so hopefully individual insureds that experience a breach are not catastrophically impacted. At the same time carriers can build reserves and achieve reasonable profits. The long term question is whether there are enough insureds purchasing cyber insurance to spread the risk and allow for the building of reserves to cover a breach of a major cloud provider that impacts a wide audience of insureds.

We probably are not there yet, and unless demand increases, we may not get there. One thing that may happen, perhaps, is a push from the Cloud provider/customer community to somehow make cyber insurance more of a mandatory condition of doing business in the Cloud. Time will tell as to whether the cyber insurers view this aggregation issue as serious, and whether they will take steps to mitigate it (hopefully those steps will not involve narrowing the coverage). In the meantime, companies that are going deep into the Cloud should quantify the risk they are retaining and seriously consider Cyber insurance coverage. The price may be right, and the peace of mind priceless.

Security Incident Response Planning

As mentioned above, a Customer should think of a Service Provider’s security as an extension of its own internal security. This applies not only to the controls the Service Provider maintains, but also how a Service Provider responds to a security incident. The key here is to impose obligations on the Service Provider that provide the Customer with the most control possible in responding to, and mitigating the impact of, a security incident.  In addition, in the event litigation or a regulatory action is a possibility, Customers should attempt to secure rights that allow them to collect and preserve evidence relevant to their defense (or in some cases a suit against the Service Provider).

On the front end, Customer should investigate the Service Provider’s security incident response procedures. In particular, the Customer should ask:

• Does the Service Provider have controls and policies in place to detect an incident?

• Once detected is there a chain of communication that escalates the incident to appropriate personnel?

• Are there procedures for ascertaining the risk and potential impact posed by a security incident?

• What processes exist to allow for the quick remediation of a security breach?

Moreover, since a forensic analysis or security assessment will often be necessary post-breach, the Customer should investigate what information is retained by Service Provider, and the Schedule should obligate the Service Provider to retain certain information that may be relevant to a breach (e.g. logs, error reports, planning documents, security policies, etc.)

Beyond that the Customer should consider how the Service Provider and Customer will interact in the event the Service Provider suffers a security breach impacting the Customer’s information, systems or ability to conduct business. The Schedule should require the Service Provider to identify an incident response coordinator to serve as the communication point for the Customer. Communication obligations can also include a point of contact within Customer’s organization, including in some instances a security breach emergency "hotline" phone number. The Schedule may include “deadlines” for providing notice of security breaches to the Customer (e.g. “immediately” or “within twenty-four hours” of discovery, etc.). The Schedule should include a general cooperation clause, and where appropriate specific incident response procedures between the Service Provider and Customer.

In addition, the Schedule should require the Service Provider to provide reports and information concerning the security incident, including information concerning what went wrong, what information or systems were impacted, and the remediation taken and planned by the Service Provider. The Schedule should also provide the Customer with the ability to conduct its own independent forensic analysis and security assessment after a breach. Since litigation or regulatory action is possible after a breach, the Schedule should include mechanisms for initiating a litigation hold and preserving information that may be relevant in a litigation context, as well as procedures for responding to information requests by regulators or litigants.

Risk of Loss

While most of the items discussed above are rather unique to the information security and privacy realm, risk of loss provisions are common to most contracts. These terms include warranty disclaimers, consequential damages disclaimers, limitation of liability clauses and indemnification clauses. Risk of loss terms should also address information security and privacy risk.

First, it is not unusual for a security incident to yield “consequential damages” in addition to “direct damages," including loss of profits, lost customers, attorney fees, breach notice costs and other similar costs. If the overall contract contains a consequential damages disclaimer, the Customer should endeavor to get an exception for consequential damages arising out of a security incident and/or breach of the Schedule.

Second, the Customer’s damages arising out of security incident can be enormous. They can include loss of profits, expenses to defend litigation (often multiple lawsuits for large breaches), regulatory defenses, damages, fines and penalties arising out of litigation, costs to provide notice to individuals whose personal information was breached, credit monitoring expenses, call center expenses and third party forensic analysis expenses. If a limitation of liability clause is in the contract, Customers should consider whether the liability cap would be sufficient to make them whole in the event of a security breach. If not, Customers should attempt to negotiate an exception to the limitation of liability (or perhaps a different limit of liability) for loss arising out of security incidents or breaches of the Schedule.

Last, enhanced indemnification/reimbursement language should be considered. As discussed throughout, it is not unusual for litigation or a regulatory action to arise out of a security incident. In the event the a breach of the Service Provider leads to litigation a regulatory action, the Schedule should include an indemnification or reimbursement clause that pays for the defense of these actions and indemnifies Customer for all damages, fines, penalties and other costs arising out of such actions.

In addition, the Schedule should also include a duty for the Service Provider to indemnify (or pay for) certain breach notice-related expenses. To date approximately 45 states have passed breach notice laws that require companies to provide notice to individuals whose person information may have been compromised. There are many expenses that arise out of the legal requirement to provide notice, including forensic expenses, attorney fees and mailing costs. In addition, some Customers may also want to provide affected individuals with a call center and credit monitoring. Many of these expenses have a “multiplier” component that can result in enormous damages. For example, one year of credit monitoring could cost anywhere from $10 to $360 per year per individual. If credit monitoring is provided to 1 million affected individuals a low-end estimate of the cost would be about $10 million. Therefore, the Customer should attempt to include language in the Schedule that requires the Service Provider to pay for or indemnify the Customer for these costs as well. If possible, all such indemnification costs should be outside the limit of liability.

Finally, organizations should consider another method for transferring risk of loss: insurance. “Cyber” insurance is available that can cover many of the types of loss that arise out a security or privacy breach, including loss of income, remediation expenses, data restoration, attorney fees, damages, fines and penalties, forensic expenses, breach notice expenses, credit monitoring expenses and call center expenses. The Schedule should require the Service Provider to carry both errors and omissions and “cyber” risk coverage with appropriate limits of liability. The Customer should attempt to mandate that it be named as an additional insured under the Service Provider’s policy (this option, however, may not be available as it will depend on whether the insurer is willing to provide “additional insured” coverage). In addition, Customers should consider purchasing their own cyber policy to provide direct coverage. Many carriers will provide coverage to the Customer for security and privacy breaches arising from a Service Provider security incident.

Conclusion

An information security and privacy schedule that sets forth Service Provider security and privacy obligations, and Customer rights with respect to the same, is an increasingly important and necessary part of an information technology, outsourcing or cloud computing transaction. Lawyers charged with developing such terms should be aware that Schedules serve several simultaneous purposes that are specific to the compliance and liability risk associated with data security and privacy. As a final point, the Schedule is a classic example of where “hybrid” knowledge of the law and security is required. A large part of the Schedule involves “translating” legal compliance and risk issues in a manner that can be understood by security and privacy professionals (and vice versa). As such lawyers should work closely with their client’s information security and privacy teams to develop security assessment processes, draft the terms of a Schedule, and negotiate Schedule terms with Service Providers.

With heightened liability and compliance risks associated with handling protected categories of data, it is becoming more common to see contractual requirements holding vendors accountable for information security or requiring them to conform to a specified information security standard. Formerly, certification requirements were largely confined to contracts procuring data processing services for government agencies, financial services firms, and healthcare providers. Now, such provisions are appearing in a wide variety of outsourcing, cloud computing, software as a service (SaaS), infrastructure as a service (IaaS), and consulting contracts where the vendor will be processing or storing Social Security Numbers (SSNs), payment card or bank account details, medical information, or virtually any personal data from Europe, Canada, or other jurisdictions with more comprehensive data protection laws.

Often, the contract requires a self-certification of conformance with a particular set of information security safeguards and control procedures, such as the Payment Card Industry Digital Security Standard (PCI DSS) for credit and debit card data, ISO 27001/27002 (formerly ISO 17799), or the US government’s NIST 800 series of Federal Information Processing Standards (FIPS). But many contracts go beyond representations, warranties, or conditions concerning information security and require the vendor to submit a third-party expert assessment or audit of the vendor’s security practices.

Security audits can be costly and time-consuming, and an audit requirement may or may not be reasonable given the type and amount of data at issue. On the other hand, a neglected or casually performed self-assessment can result in contract termination, denial of insurance claims, or the shifting of liability following a security breach incident.

How well do lawyers drafting or vetting contracts know what their clients need, or what they are committing to, when it comes to the clauses or annexes detailing the parties’ information security obligations? Despite the sometimes mind-numbing acronyms and technical content, lawyers and business managers need to have a basic understanding of what is entailed with the more common forms of information security clauses and certifications. This will also help them determine which are the most useful and appropriate standards, representations, and certifications for a particular services contract.

Common Information Security Clauses

Confidentiality and nondisclosure provisions typically include a definition of “Confidential Information” accompanied by nondisclosure obligations. The definition usually amounts to “proprietary,” nonpublic information that could be legally protected as trade secrets or confidential commercial information. Sometimes the definition specifically includes “personal information” shared between the parties, such as customer and employee data or marketing lists, which may be both proprietary and protected by privacy laws. Typically, the clause obliges the parties to protect each other’s Confidential Information in the same manner that they customarily protect their own Confidential Information (“the same care and discretion” is a common formulation).

A simple, reciprocal confidentiality obligation works well where the parties have similar interests and capabilities in information protection. However, if one of the parties is relatively inexperienced or lacks sufficient resources or motivation, it may not be satisfactory to rely on such a provision without naming (or attaching) any special security requirements that apply to some of the data, or referring contractually to a widely accepted security standard.

Personal Information Security Clauses

Many contracts involving the sharing of protected categories of nonpublic personal information now also include a Personal Information or Personal Data provision. This is typically designed to help ensure compliance with any applicable privacy laws or standards, such as the federal HIPAA and HITECH acts governing medical data in the US, state personal information security and breach notice laws, and data protection legislation outside the US. The clause will often require the parties to implement “reasonable and appropriate” security measures to protect either defined categories of personal data or, more broadly, any personally identified or identifiable information (“PII”) furnished in connection with contract fulfillment.

The clause may refer generally to compliance with “any applicable laws and standards,” but it is prudent to add a specific reference to any particular information security regimes that are known to apply, such as PCI DSS (payment cards), HIPAA and HITECH (medical records), GLBA (financial accounts), FCRA (consumer reports), national laws based on the EU Data Protection Directive, or the Massachusetts personal information security requirements contained in Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05. This helps ensure that the parties understand the operational security requirements and avoids disputes about precisely what was required of the vendor.

Related provisions that may appear in this clause or separately include those relating to indemnification in the event of a security breach or abuse of personal information, insurance to cover such events, notice obligations in the event of a suspected breach of security, and a duty to cooperate in the investigation and resolution of security incidents involving protected personal information. Depending on the sensitivity of their consumer, employee, or government relations, some customers insist on a provision that allows them, or their designated experts, to control the investigation and any notifications to affected individuals or to law enforcement or regulatory bodies, even if the vendor is responsible for some or all of the related costs. Occasionally, the personal information clause will expressly deny any intent to create third-party beneficiary rights for the individuals who are the subjects of the data. This is not possible, however, in the case of European personal data transferred abroad under EU-approved standard contract clauses, as mentioned below.

The personal information clause may also include reference to a specified information security standard and possibly to a required third-party certification. The more common forms of these will be discussed in the next posts in this series.

Clearly, the personal information provisions of the contract can involve substantial risks and costs. The vendor should be careful to understand the requirements and not commit to more than it can perform (or afford). The Customer needs to exercise due diligence in ascertaining that the vendor has the technical and financial capability to perform as required, since the customer may be held accountable in any event by courts, regulators, and the public.

Transborder Personal Data Transfer Agreements

Personal data from the European Union, European Economic Area (the EU plus Norway, Iceland, and Liechtenstein), and other jurisdictions (such as Switzerland and Russia) with laws based on the EU Data Protection Directive are usually covered as well by a transborder data transfer clause. This may refer to the receiving party’s obligations as a data “controller” under laws based on the EU Directive, including obligations to provide notice and access and to secure the data with appropriate “technical and organizational” measures proportionate to the privacy risks inherent in handling the data at issue. If the receiving party is a mere “processor” under EU law, it is mandatory for the contract to include an “Article 17” clause (usually under the heading “Personal Data” or “Data Protection”) to the effect that (a) the processor will handle the data only according to instructions from the data controller and (b) the processor will employ “technical and organizational” security measures equivalent to those required of controllers. (Note that Article 17 clauses are required in contracts between controllers and processors even if the personal data remain in the EU / EEA.)

Whether a party receiving European personal data outside the EU / EEA is a controller or a processor, it must have a legal basis for receiving the data. The data may be received in any of the handful of countries deemed by the EU to afford an “adequate” level of protection, such as Switzerland and Canada (to the extent that the data are protected by the Canadian federal PIPEDA act). Data from EU / EEA countries, Switzerland, and Israel may also be received lawfully in the United States by a company that participates in the International Safe Harbor program. Otherwise, the transfer of such data must be covered by informed consent or another of the accepted “derogations” under Article 26 of the EU Directive. The most common of these are EU-approved standard contract clauses (or “model contracts”) and, more recently, nationally approved binding corporate rules (BCRs).

The EU standard contract clauses typically appear in a separate document or annex, with mandatory terms and a description of the data transfers according to EU requirements. There are only a few approved options in the terms themselves, but the descriptive annex must be carefully drafted to cover all of the contemplated data categories, uses, and recipients. The current sets of EU-approved standard contract clauses do not require a detailed description of security measures, but they do require reference to any special measures that must be taken to safeguard “sensitive” data. (In the EU context, sensitive data refers to information concerning race or ethnicity, health or sex life, religious beliefs, political or trade union activity, and, depending on the country, criminal history, national ID numbers, civil judgments, and any other categories of data deemed especially risky under national law or regulations). In some countries, such as France and the Netherlands, the data transfer agreement and descriptive annex must be submitted for review by a national data protection authority (DPA). DPAs have been known in some instances to request more information about the security measures to be employed (such as encryption), particularly where sensitive data are involved, and they may require that these be included in the data transfer agreement. This information is not made public, however, lest it compromise the security measures.

Several other jurisdictions with comprehensive data protection laws (such as Argentina, Australia, Canada, Dubai, Israel, and Japan) require “reasonable” or “appropriate” security measures proportionate to the risks; they also require or recommend contractual safeguards when transferring personal data to the US, India, and other jurisdictions lacking similar data privacy laws. So far, these countries have not specified security standards or detailed requirements that must be reflected in the data transfer agreement.

***

In the following posts in this series, we will look at the more common information security standards and certifications that may be included in service contracts.