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

Social Media = Social Engineering

One of the biggest social media security risks reveals itself in the name of the medium itself: social media yields social engineering. In short, when it comes to social media attacks, an organization’s own employees may be its worst enemy. Fraudsters leverage the central component of social media that makes it so attractive: trust between “friends.” Social media users may be tricked into downloading applications infected with malware because a posting was “recommended” by a friend. For example, almost immediately after Osama Bin Laden was killed by U.S. troops, one Facebook scam inserted malware on computers using a malicious (and false) link to the “real” Osama Bin Laden dead body photo that looked like it was posted on a friend’s wall. In addition, some scams have used messaging capabilities within social media platforms to initiate computer attacks.  Unfortunately, if a company's employee is scammed and downloads malware from a social media network to the company network, it may be the company that faces legal liability.

In addition, fraudsters use the trust users place in the social media platform itself to effectuate security breaches. For example, most would feel fairly comfortable clicking on an advertisement displayed on Facebook. However, in some cases that click could result in a “malvertisement” infection.

Another common attack technique is phishing. Criminals create fake email notices that appear to come from social media sites. Unsuspecting users that click on links in these emails may end up providing sensitive information to fake websites that look like the social media site they belong to, or downloading malware onto a company’s system.  Unfortunately, even an employee just giving up his or her personal social media passwords can be risky for a company. Many individuals use the same passwords at multiple sites and disclosing a social media password could also amount to providing the password to the network of an employee’s employer.

There is increasing evidence that criminals are using social media to target key company personnel in order to burrow into company networks and steal trade secrets and other sensitive information.  The wealth of personal information users share on social media sites provides ammunition for such attacks. Fraudsters can gather details about a user before engaging in an attack (e.g. employer, address, phone number, friends, affiliated companies, etc.) and then use the details to target the attack specifically at the individual(s) (such as a phishing email).  In fact, this very technique appears to have been used in one of the biggest breaches of 2011, the RSA breach.

With regard to legal risk, companies suffering a breach arising out of social media face the same risks for any security breach. If malware infects a system or an employee is tricked into providing his or her login-credentials, and confidential or personal information is stolen, the employer may face lawsuits or regulatory scrutiny.  Actions alleging breaches of NDAs may also come from third parties whose trade secrets or other confidential information a company holds. Moreover, if personal information is accessed or acquired due to the social media security breach, notification may be necessary and related costs would have to be incurred by the employer.

Social Media Spoofing and Hijacking

Companies may also face legal liability for failing to detect and notify social media users of scams associated with the company’s social media site or key personnel with social media presences. If an organization becomes aware of a spoofed fan page that looks like its own, or a criminal disseminating a malware-infested social media application that looks like it is sponsored by the organization, legal repercussions could arise. Similarly, fraudsters could create fake profiles of key company personnel in order to commit crimes.

Security and legal risks can also arise if hackers are able to take over a company’s fan page or social media profiles of key company personnel. By creating a fake fan page or profile, or hijacking an existing fan page or profile, fraudsters could send out messages with malware to all of the individuals who joined the fan page or trick customers into disclosing sensitive information.  From the legal risk perspective, while case law is sparse, companies that fail to have fake fan pages removed or that fail to warn their customers of scams that look like they come from the company, could face legal liability.

Confidential Information Leakage

Another important business and legal risk arises out of potential confidential information leakage on social media sites.

Imagine a company that is heavily reliant on traditional sales methods and has built up a customer list (a trade secret) with key, difficult-to-find contacts. Oftentimes, companies like this rely on key sales people to bring in large portions of their revenue. Perhaps seeking to be on top of modern marketing practices some of these salespeople establish LinkedIn accounts, and naturally begin linking to dozens or perhaps hundreds of friends, colleagues and customers. On LinkedIn, if settings are not set properly, all of the contacts related to these key salespeople could be publicly viewable. That being the case, it would not be difficult for a competitor to simply view and record those contacts, thereby potentially exposing the company’s customer list and key customer contacts.

Take it one step further. Suppose one of the key sales persons leaves with the customer list and the company sues alleging misappropriation of trade secret. One of the elements for establishing a trade secret are efforts to keep the secret confidential. However, by allowing the sales person to display all of his contacts on LinkedIn, has the company effectively failed to maintain that confidentiality and lost its trade secret protection?

In 2010, we saw an Eastern District of New York case that looked at this issue and ruled that trade secret protection was unavailable for a company where the customer list information at issue could be readily ascertained using sites like Google and by viewing LinkedIn profiles. In contrast, in 2011, the court in Syncsort Incorporated v. Innovative Routines, International, Inc., looked at the issue of whether a trade secret posted on the Internet loses its protection. While the court ruled that trade secret protection was not lost under the facts of Syncsort (where only a portion of the trade secret was available for a limited time), it appears that a different set of facts could yield a decision going the other direction.

The inadvertent disclosure of confidential information by employees may also be problematic for organizations. This problem can arise when employees mistakenly or unknowingly disclosing sensitive information. For example, in September 2011 a Hewlett-Packard executive updated his LinkedIn status and revealed previously undisclosed details of HP's cloud-computing services. If he had instead posted confidential information about one of HP’s clients it may have resulted in legal liability. Moreover, for publicly-traded companies, certain inadvertent disclosures of financial information could lead to violations of securities laws and regulations.

Even if confidential information is not directly put into a single status update or other post, the aggregated social media postings of multiple employees could yield valuable competitive information. Companies (on their own or through third party service providers) are actively data mining social media sites with the hope of gathering enough bits and pieces of information to provide a competitive edge. Employees may be unwittingly posting what they think is a single piece of non-sensitive data.  However, when combined with multiple data points from other employees and sources, those innocent disclosures could suddenly reveal company or client confidential information.

Conclusion

In summary, the key security-related legal concerns associated with social media start with the fact that social media provides a rich target environment for criminals. Social media users are literally volunteering information that may be sensitive, and the disclosure of which could lead to legal risk. The culture of sharing present on social media sites itself can lead to over-disclosure by employees, and the pure volume of data that can be mined from social media sites may allow competitors and criminals to connect-the-dots to reveal confidential or sensitive information. Moreover, the sense of trust that comes with social media environments provides an opportunity for criminals to breach security. People may be tricked into providing certain information or downloading malware because they think they are having legitimate communications with colleagues or friends. Finally, the ability to easily spoof or create fake sites or pages in social media sites that look legitimate can lead to increased security risk. With this increased security risk, comes increased legal and liability risk (in an area of law that is very unsettled in terms of who can be liable for a security breach, and to what extent).

How can these risks be addressed and mitigated? First, it is key to understand the social media environment and how the various social media platforms work.  The unique characteristics of a particular social media platform may present risks specific to that platform. Second, organizations need to develop a social media strategy to maximize their leveraging of social media while minimizing risk (Are employees allowed to use their social media sites from work computers? Can they talk about the company and its plans on social media sites? What company information can they share on social media sites? Should only a handful of marketing-oriented employees be allowed to post about or on behalf of an organization? Can the company monitor social media usage?) Once strategy is developed, social media policies need to be drafted to reflect the strategy and address risks. In the security context, a big part of minimizing risk is educating and training employees and providing guidance on how to avoid or minimize it.  Technology solutions may also exist that can allow for monitoring and tracking of social media usage by employees. Ultimately, however, like social media itself, it comes down to people -- risk can only be addressed appropriately if the individuals using social media are equipped to identify and mitigate against it.

What is Social Media?

For a phenomenon that is taking over the world, one would think that the meaning of social media would be clear. While that may not be the case, we are not going to belabor the issue in this post. Instead we will simply use the definition generated by Wikipedia (itself a form of social media that relies on the collective efforts of its users to come up with the “right” answer): 

Social media are media for social interaction, using highly accessible and scalable publishing techniques. Social media use web-based technologies to turn communication into interactive dialogue.

Examples of websites and internet activities that fall into this definition include: LinkedIn, Facebook, Twitter, Digg, Delicious, StumbleUpon,Foursquare, blogging platforms (e.g. WordPress, Drupal, etc.), Wikipedia, bulletin boards (e.g. phpbb.com), Quora and YouTube.

The InfoLawGroup is a heavy user of social media, and the best way that I have been able to explain our social media is by analogy: social media is like a wide-ranging conversation that can be with the entire world, or on a very intimate level with a single individual, and often both. Social media provides a mechanism for finding communities of like-minded (or not) individuals interested in particular topics (and sub-topics).    InfoLawGroup uses social media to engage in conversation concerning issues that are important and interesting to us (and others), and by engaging in that conversation in a meaningful way, others begin to recognize and value our input (and we in turn discover experts, influencers, and valuable information resources). Based on our experience, the key attributes of a successful social networking include clear communication, multi-party interaction, trust and intimacy. 

How is Social Media Used?

So your organization wants to “use” social networking. Why? For many organizations considering the use of social media a vague idea may exist that they “should” be doing that. However, clear organizational goals may not exist concerning the use of social media. As a threshold issue, before even considering specific legal issues, organizations must have a clear idea of why they want to use social media.    Companies should identify the business process or organizational strategy they are seeking to advance by the use of social networking. They should be able to establish goals and metrics in order to measure success and allow for the adjustment of their strategy if it is not proving successful.   Of course, when the question of why is answered, then the question of “how” must be addressed (and often the two questions must be considered together).

The process of developing a social media strategy tied to specific business processes and goals will enlighten companies as to the legal implications of their use of social networking. While there may be certain legal concerns baked into “social media” in general, many of the legal risks will arise based on the specific business process and goals surrounding the use of social media. In addition, the characteristics of the social media platform(s) an organization chooses to leverage may also impact the legal risks faced by the organization.

While there are as many social media strategies as there are organizations seeking to employ them (in fact, there are certainly many more), we have laid out some “use cases” that will help us explore the legal implications of social media:

• Direct Interaction. Direct interaction (with customer, "influencers," media, colleagues, etc.) is really the most basic use of social media, it involves an organization using social media to communicate and interact with the general social media population (or subsets of that population).    This would happen on various social media platforms such as Facebook, LinkedIn and Twitter, or through a weblog.   However, the approach organizations employ to interact may vary, and as discussed later, the differences in approach could impact the legal risks associated with social media. Some approaches for direct interaction include the following: (a) allowing an organization’s general employee population to go out and interact on behalf of the company with little instruction or supervision; (b) allowing an organization’s general employee population to go out and interact on behalf of the company with strict instructions and supervision; (c) identifying a small dedicated group to interact on social media on behalf of the company, including potentially the use of “corporate profiles” not tied to any individual person; and (d) hiring a third party marketing company to interact on social media pursuant to a specific marketing strategy.

• Company Page/Fan Site. Some social media platforms allow organizations to create “fan pages” (e.g. Facebook) or company pages (LinkedIn). In essence these types of pages/site allow an organization to set up a centralized presence or "destination" within a social media platform.   Interested individuals can then join or follow postings that occur on the organization’s fan page/site, and those visitors can themselves post and interact on the fan page or site. This allows for interaction in a more centralized fashion.

• Social Media Applications. Some social media platforms may allow organizations to create applications that can be plugged into the social media platform. For example, a mortgage broker with a presence on Facebook could hire an application developer to develop a mortgage interest rate calculator application that Facebook users could operate. This would essentially provide an advertisement for the mortgage company and create goodwill amongst potential customers. In addition, when the application is downloaded by a user, the mortgage company would then get access to certain personal information that is part of the user’s profile. This information can be valuable for targeting prospective customers and data mining purposes.

• Blogging. While it may not be obvious to everybody, most blogs constitute social media.   Blogs that allow for comments and interaction between the blogger and his readers (and interaction between the readers themselves) are social media. This interaction typically occurs in the “comments” section of a blog. In addition, many organizations use their blog as the kernel for interaction in other social media platforms. So, an organization with a blog might do a post and tweet it on Twitter, cross-post it on their Facebook fan page and post it in a LinkedIn Group, in order to drive traffic to the company’s blogpost (and ultimately website, product or service).

• Social Plug-ins. Many social media platforms provide “widgets” or “plug-ins” that can be put into a website to allow the content of the website to be commented upon and shared within the social media platform. The plug-in may be in the form of a “button” that allows a website visitor to “like”  particular content and have their preference posted in Twitter, Facebook or Digg. Some social medial platforms may be seamlessly integrated into a website in such a manner that makes it virtually invisible. Using these plug-ins can help` spread an organization’s message to a much wider audience and drive traffic to the organization’s website.

• Log-In Credentials. Another interesting way social media platforms are being utilized is to allow website visitors to login to an organization’s website employing the log-in credentials they use to gain access to a social media platform. Under this scenario an organization with a website could allow visitors to access the company's website by logging into their Facebook or Twitter account using the same username and password (this is achieved by utilizing the social media platform’s API). The organization benefits in several ways by employing this practice. First, the visitor gets to avoid setting up a new username and password specific to the website, which can be viewed as time-consuming by some visitors. Second, the user is less likely to forget a username/password from a frequently-used social media platform, and this makes logging in very easy. Last, by linking to the social media platform’s authentication credentials, the organization is able to obtain certain personal information about that visitor that is available on the social media platform.

The forgoing use case scenarios are surely the tip of the iceberg, and new social media platforms and strategies are being developed every day.   It is in this dynamic environment that organizations must analyze and understand the legal risks associated with the use of social media.

Social Media Legal Issues

As we work through the various legal implications of social media it hopefully will become increasingly clear that context is very important. While we can (and will) talk about broad categories of legal risks that apply to most (or all) social media, a basic formula can be used to identify and analyze the specific legal risks of a particular social media use. The social media legal risk “formula” can be summarized as follows:

• the inherent characteristics/capabilities/limitations of the social media platform to be leveraged, PLUS

• the organization’s specific intended social media strategy and uses, REVEALS

• the relevant legal issues and level of legal risk present.

With this formula in mind we turn to a short summary of the social medial legal issues that InfoLawGroup will be exploring in detail as part of its multi-part blog series.

Information Security Legal Risk

Organizations that employ social media face several information security legal issues.   These legal risks can be broken down into three broad categories: (1) potential liability due to a breach of the organization’s security as the result of an attack originating through the use of social media; (2) potential legal risk associated with social engineering and spoofing attacks against users or “fans” of an organization’s social media presence, persona or application; and (3) legal consequences of leakage of third party confidential information as a result of social media use.

As might be expected organized crime views social networks as fertile ground for committing fraud. One of the biggest risks is in the name of the medium itself.  Social media yields social engineering. Fraudsters leverage the central component of social media that makes it so attractive: trust between “friends.” As such social media users are tricked into downloading applications infected with malware because it was “recommended” by a friend, or they click on the link of the “real” Osama Bin Laden dead body photo that looks like it was posted on a friend's wall (and a computer attack occurs), or they visit a site that looks like a brand name company’s fan page and are enticed to provide some of their personal information to criminals. The direct risk to an organization allowing its employees to use social media on company computers is obvious: if malware from social media infects a company computer and steals personal information, credit card numbers or trade secrets, the company may have to provide notice of a security breach and could face lawsuits and regulatory actions arising out of the breach.

Companies may also face liability for failing to detect and notify social media users of scams associated with the company’s name or site. If an organization becomes aware of a spoofed fan page that looks like its own, or a criminal disseminating a malware-infested social application that looks like it is sponsored by the organization, legal repercussions could arise. In the email context we are already aware of lawsuits involving phishing that allege that the defendant should have been aware of scam emails sent to their customers, and should have warned those customers of the scam.

Finally, social media sites and the activities of multiple users for or on behalf of an organization could result in information leakage. If that leakage involves confidential information or trade secrets of an organization’s customer, or perhaps certain financial disclosures in violation of securities laws, liability could arise. The risk of confidential information leakage was recently on display involving the use of LinkedIn.  This risk can also be indirect in its nature, and there are several social media corporate intelligence companies that will data mine and aggregate information about competitors in order to discover leaked secrets, plans and trends.

Privacy

For many companies the Holy Grail of social media is in depth and detailed personal information about their current and would-be customers. Social media provides a platform for much more interactive and intimate communications between companies and their customers. In turn companies seek to use this knowledge to sell their products and services back to these customers (in a way that does not erode the trust relationship that is often gained in the social media context).   Social media platforms enable the gathering of information, including personal information, in ways that were unimaginable only a few years back.   Companies leveraging social media, depending on the platform, can gain access to this personal information. This raises a host of privacy concerns that could increase legal risk. Most social media sites have terms and conditions that may result in legal liability if an organization’s collection or use of personal information violates those terms.    Laws such as COPPA may have applicability with respect to an organization’s “fan” page.    Finally, to what extent do an organization’s privacy policies apply, if at all, to its social media activities?   All of these issues will become increasingly important as use of social media becomes the norm.

IP Infringement

Social media sites allow users and companies to post content, including content that may be copyrighted or trademarked. Posting can be performed not only by employees of organizations using social media, but also fans and visitors to a company’s social media site. Organizations may face infringement claims (direct or based on vicarious liability) due to copyrighted or trademarked materials being posted by them or by third parties.

Disparagement and Defamation

Social media environments provide a forum for defamatory statements to be made about individuals, and disparaging remarks to be made about companies' products and services. Organizations with overzealous employees attempting to get a leg up on competitors may post comments or remarks that may not be fully accurate or true about an individual or a competitor’s products or services. This could lead to a potential lawsuit and liability. Social media sites and blogs that allow comments may also involve such statements made by third parties over which the organization has little to no control. While defenses may exist, including potentially Section 230 of the Communications Decency Act, this area of law is notoriously fact specific and varies by jurisdiction, and it could pose problems for companies.

Employment Law Issues

The use of social media in the employment context raises a lot of tricky legal issues. First, many organizations use social media to vet candidates for employment and as part of background checks. The information obtained from a social media site may constitute a “consumer report” under the Fair Credit Reporting Act and similar state laws, and employers may have to obtain an individual’s consent before accessing such information (or may be prohibited from using that information to make employment decisions). During employment, the issue is to what extent an employee may have privacy rights concerning its use of social media while at work, and to what extent the employer may monitor such activities. Overzealous employers that create fake social media accounts to monitor social media activities of their employees could also raise legal issues, including issues under the Stored Communications Act, which is part of the larger Electronic Communications Privacy Act. Finally, using social media activities as the basis for firing or taking disciplinary action against employees may run afoul of the law. Recently, there have been a series of “Facebook Firings” where the National Labor Relations Board has alleged that and employer’s action violated the National Labor Relations Act.

Advertising Law

Organizations that use social media to promote their products and services should also be concerned about advertising laws. For example, some social media activities may amount to a contest or sweepstakes and may need to have appropriate disclaimers and notices. In addition, for social media sites that allow users to rate products or services, an employee that “rates up” the products or services of his or her company may violate advertising laws concerning testimonials and endorsements.

Electronic Discovery and Evidence

Social networks are brimming with social interactions and information generated by and about those interactions. That information may be highly relevant in a litigation context, and the parties in a litigation may seek to obtain this information via discovery or subpoena. Questions arise as to whether obtaining this information for use in court is permissible in light of potential privacy concerns. On the flipside, when litigation begins, how should lawyers advise their clients concerning the preservation of information on social media sites, and what kind of problems may arise if a litigant fails to preserve social media information.

Drafting a Social Media Policy

In the final part of this series, we will take a closer look at one of the key controls to address the legal risk associated with the use of social media:  the social media policy. We will look at the key elements and issues that should be addressed in a social media policy, and identify strategies for dealing with this risk. In addition, we will discuss some new technological controls that companies are developing to help organizations understand, monitor and manage social media use and legal risks. Overall, there is much more to come on this topic. Stay tuned! 

In addition, the survey revealed that a “majority of cloud computing providers surveyed do not believe their organization views the security of their cloud services as a competitive advantage. Further, they do not consider cloud computing security as one of their most important responsibilities and do not believe their products or services substantially protect and secure the confidential or sensitive information of their customers.”

The report surveyed 103 cloud service cloud providers in the U.S. and 24 in six European counties (UK, Germany, France, Netherlands, Spain and Italy), broken down by providers in SaaS (55%), IaaS (34%) and PaaS (11%). The cloud providers range in size, offerings and scale. The U.S. sample was composed of 42% having less than 1,000 employees, and 58% having from 1,001 to 5,000 employees up to organizations with more than 75,000 employees.

The report states its “Key Finding” that:

[P]roviders of cloud computing resources are not focused on security in the cloud. Rather, their priority is delivering the features their customers want such as low cost solutions with fast deployment that improves customer service and increases the efficiency of the IT function. As a result, providers in our study conclude that they cannot warrant or provide complete assurance that their products or services are sufficiently secure.

These results have sparked vigorous debate and questions on the report itself (i.e., here). It should be noted that the an entire page of qualifications and caveats is provided, including listing the issues of: non-response bias, sampling-frame bias, and the problems inherent in self-reported results.

Also, the report clearly states that “Sixty-five percent of cloud providers in this study deploy their IT resources in the public cloud environment, 18 percent deploy in the private cloud and 18 percent are hybrid.” The large numbers of public cloud providers undoubtedly skewed the results, and the security provisions of public cloud providers are by and large not acceptable for any corporate entity whose data consist of sensitive information, PII, PHI or similar such information, with a further observation that private cloud providers “appear to attach more importance and have a higher level of confidence in their organization’s ability to meet security objectives than providers of public and hybrid cloud solutions.”  It would have been useful had the surveyed providers been further broken down as to public, hybrid and private cloud offerings.

The study further reports that the majority of cloud providers surveyed “admit they do not have dedicated security personnel to oversee the security of cloud applications, infrastructure or platforms.”

If accurate overall in the industry, the cloud provider landscape is in need of serious change.

One bit of somewhat good news the survey revealed is that “about one-third of the cloud providers in our study are considering such solutions [providing additional security] as a new source of revenue sometime in the next two years.” Better late than never, I suppose, but I expect various forward looking cloud providers to push that timeframe up as a distinct competitive advantage (i.e. see IBM's recent cloud announcements, here).

Breaking Down the Details

Another of the report’s conclusion is that “the focus on cost and speed and not on security or data protection [in cloud offerings] creates a security hole.” This potential “security hole” is a prime reason we advise clients, in certain circumstances, to be prepared to walk away from cloud providers under consideration if adequate and legally defensible security measures cannot be adequately negotiated and contractually provided for.

The report also states that “cloud providers are least confident about the following security requirements:

• Identify and authenticate users before granting access
• Secure vendor relationships before sharing information assets
• Prevent or curtail external attacks
• Encrypt sensitive or confidential information assets whenever feasible
• Determine the root cause of cyber attacks

These are serious security concerns any way you slice it.

But what are some actual hard numbers in the report? The report is worth a read, and at only 26-pages with numerous charts and table, makes for quick scanning, but some of the results, if again representative, are jaw dropping.

For instance, Table 2: Enabled security technologies deployed by cloud providers notes some truly concerning items. The percentages reflect technologies presently used or that will be deployed in the next 12 months. US & Europe results combined. Only 31% of cloud providers surveyed utilize an “ID & credentialing system” and only 43% use or plan to use in the next 12 months “encryption for data at rest” while 58% state they use or plan to use “encryption for data in motion.” The report summarizes that “[t]he enabling security technologies least used by US and European providers in the cloud computing environment are:

• Single sign-on
• Data loss prevention
• Correlation or event management
• Access governance systems
• Encryption for wireless communication

The Takeaway

The fundamental takeaway from the Ponemon study is that cloud security is very much a work in progress, and that any cloud initiative or plan for corporate cloud usage needs serious due diligence by representatives from business, IT and legal working in conjunction.

Please feel free to contact me or any or the attorneys at the InfoLawGroup to discuss your own cloud scenarios or the legal issues and risks raised by moving to the cloud.
 

Colorado HB 11-1225 – An Information Security Carrot

Regulation is achieved via the “carrot” or the “stick” (and sometimes both). This is true in the information security context as well. For example, to incentivize encryption of personal information, breach notice laws use a stick: those that fail to encrypt may have to provide notice to affected individuals in the event of a security breach. In the credit card breach context, a Washington state law provides banks with a stick (e.g. the right to seek fraud and reissuance expenses from breached merchants), but also provides those merchants with a shield to block that stick (e.g. validation of PCI compliance blocks a bank’s ability to recover). In HB 11-1225, Colorado state legislator, Dan Pabon, apparently wants to give the carrot a chance. In the process, I am told that part of the goal is to make Colorado the “Delaware” of data storage. Here is how it works.

Immunity from Liability. Under HB 11-1225, if certain conditions are met (discussed below) a person or entity operating in Colorado that owns, licenses or maintains computerized data that includes “personal information” shall not be liable for civil damages resulting from a breach of data security due to its acts or omissions that are in good faith, and not grossly negligent or willful and wonton.  So essentially, this would provide immunity from negligence claims. In order to receive this protection, two conditions must be satisfied: (1) the breach must have been caused by an unauthorized third party, or an employee or agent acting outside the scope of his employment; and (2) the person or entity must have been certified by a “qualified information technology auditor or assessor” as having used “best practices of data security and meeting information technology standards” established by an authorized state entity.

Rebuttable Presumption of Non-Negligence. Even if a breached organization has not been certified as compliant with best practices/information technology standards, it can achieve certain protections under the bill. In court, an organization can establish a rebuttable presumption that it was not negligent if it can produce evidence that the organization implemented best practices and was compliant with technology security standards established pursuant to the bill.

Consumers’ Right to Petition Court for Subpoena. The bill provides persons whose personal information was compromised or who are victims of a computer crime, to seek a petition from a court impelling the breached organization or any third party to produce “any” information concerning the unauthorized access to personal information or the computer crime. This information may be obtained in order to facilitate the detection, apprehension and prosecution of the computer crime or breach.

Key Definitions. “Personal information” as defined under the bill is broader than definitions in most breach notice laws. One defined category of personal information is information that can be used, alone or in conjunction with any other information, to obtain cash, credit, property, services, or any other thing of value, or to make a financial payment, including personal identification number, credit card number, banking card number, checking account number, etc. Personal information is also defined as information that can be used, alone or in conjunction with other information, to identify a specific individual, including name, date of birth, social security number, government ID, passport number, etc.

In order to be a “qualified information technology auditor or assessor” one must be certified by a nationally recognized organization or association as having expertise in data security, and cannot have any convictions involving moral turpitude offenses. The bill indicates that the CIO of the State of Colorado is required to establish an entity to maintain a list of the nationally recognized IT associations that may certify a person’s qualifications in data security systems for purposes of the bill.

Establishing Best Practices and Information Technology Security Standards. One of the key challenges for implementing this HB 11-1225 (should it become law in its current form) is going to be the establishment of best practices and IT security standards. On this issue the bill requires the CIO of the State of Colorado to create an “entity” to establish these best practices and standards for commercial entities and persons that own, license or maintain computerized data that includes personal information. The bill does not provide additional guidance as to how those best practices shall be determined, or whether there will be one set of best practices that will apply to all entities (regardless of size, complexity or resources).

Analysis and Observations

Novel approaches to information security and privacy legislation are, of course, welcomed. The questions remain, however. Will it work? Will it pass? Unclear at this point. Below are a few observations pertaining to these questions.

• Does a duty exist to safeguard personal information under common law negligence principles? Surprisingly, at this point we have very little case law directly on point that delves into this issue. However, a recent Illinois appellate court recently ruled that a common law duty to safeguard personal information did not exist. In contrast, we are aware of cases that did find a duty to secure personal information, but both were in the banking context and were arguably based mainly on the expectations that arise in that context (e.g. banking customers are specifically providing their money to banks for safeguarding, among other reasons). If indeed, no case law establishing such a duty exists in Colorado, the question becomes whether the existence of a law providing immunity for negligence implies that the duty exists. Worse (from the company point of view), it is possible that the best practices established under the bill could end up establishing a standard of care, in and of themselves (where one may arguably not exist).

• Even if such a duty does exist, do the “good faith” and “gross negligence “exceptions” effectively eat the immunity? In the wake of a data breach where a plaintiff’s attorney has filed a lawsuit, you can bet that any and all potential theories of liability will be alleged. That of course may include allegations of gross negligence and “bad faith.” One of the benefits of HB 11-1225, assuming only a negligence claim is alleged, would be the ability of defendants to have lawsuits dismissed early, perhaps in a motion to dismiss or motion for summary judgment phase. However, if gross negligence, bad faith or other non-negligence claims are alleged, the plaintiff may have a better chance to get past early motions to dismiss. If that is the case, plaintiffs will still have litigation leverage (regardless of whether they have a truly winning case).  In fact, we are aware of one case in Federal court in Michigan that allowed a case to go to trial based on the issue of "good faith" behavior in the context of security. These “exceptions,” therefore, could undermine the effectiveness of the immunity granted in HB 11-1225. Of course, much more research is necessary to look into these issues.

• Is the jurisdictional scope of the immunity too narrow? At this stage in the game a large percentage of companies, big and small, conduct business with residents of more than one state (and in many cases all 50 states), and even with people residing outside of the United States. While HB 11-1225 may provide immunity from negligence claims for cases contained in Colorado, it may not help with lawsuits, for example, filed in other jurisdictions or Federal court where Colorado law is not the choice of law. So, if the goal of the law is to become the "Delaware of data storage", it may not be effective to shield companies that deal with personal information from non-Colorado states.  That all said,  there may be jurisdictional arguments that would preclude plaintiffs residing in other states from pursuing a company storing data in Colorado (although making and prevailing in such arguments in court can be an expensive process in and of itself). In addition, a choice of law provision in contracts with out-of-state counter parties might also do the trick to keep the immunity intact.

• Can the “entity” established by the State actually establish best practices that can work universally and result in good security? Legislating security controls is not an easy task. Two general approaches are used typically. One approach does not require specific controls, but rather mandates “reasonable” “adequate” “comprehensive” or “appropriate” security. The other method is more prescriptive in its approach, and seeks to require specific controls that certain entities must implement (e.g. Massachusett’s and Nevada’s personal information security laws). The risk of a prescriptive approach is the “check list” mentality whereby organizations simply address the specific requirements and don’t actually worry about truly securing themselves (this is a criticism of PCI, the ultimate prescriptive standard). However, even those taking a prescriptive approach may reference various risk factors that relate to the sensitivity of the data and the size, complexity and resources of the company trying to comply. The challenge for the entity developing these best practices is to provide enough clarity/certainty so companies have confidence that they are truly in the safe harbor, and yet to provide enough flexibility to allow companies of all shapes and sizes to get into the safe harbor in a relatively cost-efficient and realistic fashion. The failure to solve this problem could undermine the efficacy of the legislation if it is perceived to be unfair or discriminatory to small and medium-sized businesses who may have neither the expertise nor resources to implement a highly prescriptive set of controls.
   
• A Shift of Liability to the Auditors? On the one hand, this bill may serve as a business bonanza for IT security auditors who are called into validate compliance with the best practices laid out by the act. On the other hand, a mistake in validating the compliance of a company that suffers a breach could potentially lead to a lawsuit against not only the breached company, but the auditor as well. While a third party affected individual may have difficulty holding an IT security auditor liable without a contract, precedent may exist by analogy to accountants. Moreover, there is at least one known case (Merrick Bank v. Savvis) where an IT assessor (in this case a payment card security assessor) was sued by a party that allegedly relied on its compliance findings. So, from a “passability” point of view, does the IT security assessment community get on board or do they demand some of their own immunity in exchange for supporting this bill?

Conclusion

Overall, Representative Pabon’s bill represents a very interesting approach to data security regulation, and we applaud his efforts and creativity. There may be some hurdles to overcome to see this passed, and a vigorous debate on its mechanics is necessary. We will keep you up to date on its progress.
 

“Zombie” flash cookie online tracking lawsuits. A series of class action lawsuits have been filed against marketing companies (e.g. Clearspring Technologies, Inc., Quantcast Corporation, and Specific Media, Inc.) for using “flash cookies” to track website visitors as they surf the web. These flash cookies, also known as "zombie cookies," are capable of reinstalling themselves even if purposefully deleted by the user. Several brand name clients of the marketing companies were also named as defendants in the lawsuits. By the end of 2010, some of these lawsuits had settled for millions of dollars. A copy of one of the complaints can be found HERE. It alleges a series of data privacy and security violations, including violations of the CFAA, ECPA, Video Privacy Protection Act and various California laws. 02.08.11 UPDATE:  another lawsuit filed in New York. 03.11.11 UPDATE:class action filed in filed against Amazon.com in Washington. More HERE.

HTML5 mobile online tracking lawsuit. A class action lawsuit was filed against Ringleader Digital alleging privacy violations arising out of its use of HTML5’s client-side database storage capabilities to track users of mobile devices as they surfed the Internet. Similar to the flash cookie lawsuits, plaintiffs allege that the HTML5 tracking capabilities returned even if users were able to delete the HTML5 database engaged in the tracking. A copy of the complaint can be found HERE. It alleges a series of data privacy and security violations, including (among others) violations of CFAA and various California laws.

History sniffing online tracking lawsuit. In two separate lawsuits an online advertising company (Interclick) and a pornography website (YouPorn) were sued for engaging in a practice known as “history sniffing.” History sniffing involves obtaining data about a user’s web surfing by secretly accessing the web history data stored by most commonly used browsers. This browsing history data is then used to create profiles about the user’s online behavior and visits to websites across the Internet. The complaint against Interclick can be found HERE. The compliant alleges (among others) violations of the CFAA, ECPA, violations of various New York laws and trespass to chattels.

Deep packet inspection online tracking lawsuit. In December 2010 a Federal District Court in Montana refused to dismiss the CFAA claim against an ISP that had allowed an advertising company to engage in “deep packet inspection.” EPIC describes deep packet inspection in relevant part as follows:

Deep packet inspection is a computer network packet filtering technique that involves the inspection of the contents of packets as they are transmitted across the network. . . Deep Packet Inspection can be used to determine the contents of all unencrypted data transferred over a network. Since most Internet traffic is unencrypted, DPI enables Internet Service Providers to intercept virtually all of their customers' Internet activity, including web surfing data, email, and peer-to-peer downloads.

A copy of the court’s order denying in part and granting in part, the defendant’s motion to dismiss, can be found HERE.

Data aggregation and social media/application privacy lawsuits. Social media giant Facebook, social media application designers (such as Zynga), and a data broker (Rapleaf) were sued for their handling of personal information obtained from Facebook users. The plaintiffs allege that the defendants impermissibly shared the personal information of Facebook users with advertisers and marketing companies, including unique Facebook ID numbers that could be combined with other information to create user profiles. The complaint can be found HERE. It alleges (among others) violations of ECPA, the Stored Communications Act, and various California laws, and breach of contract. 03.11.11 UPDATE: class action filed against Netflix in California.

Apple iPhone/iPad Privacy Lawsuit. Apple was sued in the waning days of 2010 for allegedly allowing application makers for its popular iPad and iPhone to obtain and transmit personal information about users' activities. The complaint alleges that Apple’s iPad and iPhone are encoded with identifying devices that allow advertising networks to track applications users download, monitor their use and sell personal information of users. Also named are several application providers that allegedly provided their users’ personal information to advertisers. A copy of the compliant can be found HERE. It too alleges (among others) violations of the CFAA, ECPA and various California laws. Some believe that claims set forth in this lawsuit could impact Google in the future. 02.08.11 UPDATE:  Another class action filed against Apple in California.

01.21.11 UPDATE -- Canadian Class Action Against Google

We have identified a rare beast indeed:  a Canadian class action privacy lawsuit against Google (arising out of Google Buzz).  More HERE.  Will try to get the pleadings... stay tuned.

Conclusion

Based on the foregoing it should be apparent that there has been a significant increase in the volume of privacy lawsuits recently filed and being litigated. In addition, with significant settlements on the books (e.g. Google Buzz for $8.5 million; Facebook Beacon for $9.5 million; Quantcast for $2.4 million) it is likely that privacy-related lawsuits will become more attractive to the plaintiffs' bar.

It also should be noted that many/most of the lawsuits cited above involve online behavioral tracking. Moreover, not only are the social media companies and advertising networks being sued, “brand name” organizations are being brought into these suits if they participated in an advertising network or used a behavioral advertising services.  Based on these suits, it appears that privacy-related legal risk and liability potential is at a cross-road, and will likely increase going forward (at least in terms of litigation costs and settlements, and perhaps someday in the form of judgments and adverse case law).

Action Item.  At this stage companies that handle personal information, especially those that provide online behavioral advertising services, and those that purchase such services or participate in behavioral advertising, should consider an audit and risk assessment of their policies, processes and activities in order to reduce privacy-related legal risks. In fact, it is likely that some companies are not even aware that they are participating in online advertising networks that track users, or if they are aware they may not understand how their providers collect and use personal information. Preparation on privacy and security issues ahead of time is key in order to reduce risk and increase the likelihood of a favorable outcome should an organization find itself in a lawsuit.  Moreover, if a lawsuit arises, understanding the substantive privacy issues that it raises is crucial.  Again, we have blinked, and the privacy and security legal landscape looks very different.
 

A federal agency, the Institute for Access to Information and Data Protection (IFAI), will provide interpretive guidance and supervise compliance with the new law. IFAI will investigate complaints and inquiries and may launch investigations on its own initiative. In addition to administrative sanctions including warnings and fines, the law contemplates criminal prosecution of violators, with more substantial fines and the possibility of imprisonment for those responsible for a security breach or for fraudulent or deceptive collection and use of personal data.

The Law regulates private parties that “process” personally identified or identifiable data, with exceptions for credit reporting agencies (which are already covered by separate legislation) and individuals recording data exclusively for personal use. Definitions largely track those of the EU Data Protection Directive, including a very broad definition of “processing” that includes any collection, use, storage, or disclosure of data. The Law also uses the concepts of “data controller” and “data processor” as found in the EU Directive, respectively signifying entities that decide to process personal data and entities that carry out processing on their behalf.

The Law departs from the EU Directive, however, in reflecting the habeas data concept found in several Latin American constitutions and statutes: the individual to whom personal data relates is treated as the “data owner.” The individual’s legal rights derive largely from this concept of ownership and the associated right to control whether and how personal data is used.

“Sensitive data” gets some additional protections under the Law, as it does in Europe. As defined in the Law, sensitive data denotes information that touches on the most intimate aspects of a person’s life or involves a serious risk of discrimination. This includes but is not limited to “special categories” of data listed in the EU Directive: race or ethnicity, health, sexual preference, religious or philosophical beliefs, political views, and trade union membership. The Mexican law expressly adds genetic data to this list but does not include special treatment for criminal records as the EU Directive does.

The Law incorporates eight general principles that data controllers must follow in handling personal data: legality, consent, notice, quality, purpose limitation, fidelity, proportionality, and accountability. The Law also addresses data retention: personal data must be deleted when no longer necessary for the purposes set out in the privacy notice and applicable law.
 

Notice and Consent

Data controllers must furnish a privacy notice indicating what data is collected and for what purposes. If the data is collected directly from the individual, the privacy notice must be delivered at the same time (if not earlier) and in the same format. If the data is collected electronically, however, the data controller can choose to give only the identity and purposes of collection and a mechanism for obtaining the full privacy notice. Where the data has not been collected directly from the individual, the data controller must still provide a privacy notice and notification of changes in the privacy notice.

Data controllers can request authorization from IFAI to forego some or all of the notice requirements where, for example, the data collection is old or the cost of providing notice would be disproportionate.

The privacy notice must include the identity of the data controller, the purposes of processing, the individual’s options for limiting use or disclosure of the data, the procedures for access and correction by the individual, any contemplated transfers of the data, and procedures for notifying individuals about any subsequent changes in the privacy notice. The notice must expressly state if it concerns any sensitive data.

Consent usually can be tacit (opt-out) so long as there is sufficient notice. However, processing sensitive data or information about personal finances and assets requires express consent (opt-in); this must be recorded in writing (or electronically with authentication) in the case of sensitive data.

Consent is not required if

• the data controller is legally obliged to process the information
• the data is publicly available
• the data has been anonymized
• the data is necessary to fulfill obligations under a legal relationship between the data controller and the individual (such as employment or payment processing)
• there is an emergency that could harm the individual
• a health care professional needs the data to provide medical attention and the individual cannot give consent
• a competent government body issues a resolution waiving the consent requirement.
 

Security and Breach Notice

Data controllers are responsible for maintaining physical, technical, and administrative security measures to protect personal data from loss, alteration, and unauthorized disclosure or use. The measures must at least equal those taken to protect the data controller’s own information. Potential harm, the likelihood of security breaches, the sensitivity of the data, and technological developments are all to be taken into account in crafting appropriate security measures.
Security breaches that “materially” affect property or personal rights must be reported immediately to the affected individuals.

Data Transfers

Transferring personal data to a third party (other than for processing on behalf of the data controller) will typically require an agreement that the transferee will assume the same obligations as found in the privacy notice provided by the transferor. A data transfer requires the consent of the individual except where the transfer

• is pursuant to a law or treaty
• is necessary for medical purposes
• is made to a parent company or affiliate “operating under the same internal processes and policies” (Art. 37 (III))
• is necessary to fulfill a contract in the interest of the individual
• is necessary or legally required to protect a public interest or in the administration of justice
• is necessary to exercise a judicial claim or defense
• is necessary to maintain a legal relationship between the data controller and the individual.

The Law does not establish a formal procedure for approval of foreign data transfers. It appears that data controllers should be able to move data within a corporate group without individual consent, inside and outside Mexico, so long as the parent or affiliate does not handle the data in a manner contrary to the privacy notice furnished by the affiliate in Mexico.

Impact on US Companies

Many US companies have subsidiaries or distributors in Mexico, and data concerning Mexican employees, customers, and business contacts is often transferred to the US company for recordkeeping, contract fulfillment, business planning, market analysis, and other management purposes. Privacy notices in Mexico should mention these purposes and transfers, and the Mexican company may need to obtain opt-in consent in the case of sensitive and financial information. The US company must then handle data consistently with the privacy notice delivered by the Mexican affiliate or distributor, to avoid creating problems for the Mexican firm. For unrelated companies, data transfers should be covered by contractual terms that specify the relevant restrictions and provide for notice to the individuals unless an exception applies.

US companies also often contract with Mexican firms for Spanish-language call centers, customer support services, or outsourced data processing. Once customer data is processed by the Mexican company, it is subject to the Law, regardless of the location of the customers. US companies using such services in Mexico may expect that their vendors will increasingly refer in contracts to their own obligations under the Law and may require cooperation from the US companies in responding to privacy-related complaints and security breaches in Mexico.

Corporate groups operating in Mexico or using data-centric services in Mexico will need to stay abreast of IFAI decisions and changing business practices resulting from the new Law.
 

Author’s Note: Wow, this blogpost became very long. I did not realize how difficult it would be to try to explain complex risk of loss provisions in something closer to plain English. This post is may be difficult to wade through. However, it contains a good deal of valuable information (or at least I think so anyway). In short, these are the types of issues that are best explained orally. So if you would like to discuss these matters, feel free to contact me at 303.325.3528. Also, I will respond to comments here on the blog if you have any questions. Thanks – Dave.

Risk of Loss Contract Terms Primer

This is just a very quick general primer concerning the risk of loss terms that often appear in contracts:.

• Limitation of Liability Clauses. Limitation of liability clauses (“LOLs” for short) are fairly straightforward. They simply set the cloud provider’s monetary cap for loss or damages owed to the customer under the contract. The amount of the cap often relates to the revenue or income being generated by the service provider (e.g. liability is limited to the amount of fees earned over the prior twelve month period by the service provider). Most limits of liability purport to limit liability for any liability arising out of the services provided under the agreement, whether such liability arises out of the contract, tort or statute. Significantly, even if a customer is able to get favorable privacy and security terms from a cloud provider, they may only be able to recover up to the LOL should the provider breach those terms. Also important, cloud contracts may have exceptions to the LOL that allow the customer to recover for certain types of losses, including for example, confidentiality breaches and indemnification-related losses.

• Warranty Disclaimers. Service providers may provide certain warranties concerning their services, but then typically desire to disclaim all other warranties and guarantees concerning their services. The reason is obvious; they do not want to be held to a higher standard of care that a warranty may encompass. Service providers want to also avoid liability for implied warranties because of uncertainty and legal risk associated with potential warranties their services may imply. Customers desire to get as many warranties as possible, and to have loss arising out of warranty breaches of those warranties not be subject to contractual limitations of liability.

• Consequential Damages Disclaimers. Many Cloud contracts will contain clauses whereby the service provider disclaims any liability for “consequential damages.” Examples of consequential damages include loss of profits, loss of use of goods and reputation loss. While these examples are more straightforward it is often difficult to ascertain whether a particular loss constitutes consequential damages (not recoverable if disclaimed properly) versus “direct damages” (recoverable). For example, some Cloud providers may argue that breach notice costs or fines or penalties arising out of a security breach in violation of a contract may constitute consequential damages, and therefore be disclaimed and not recoverable by a customer.

• Indemnification Clauses. Certain actions by a Cloud provider, such as a security breach or non-compliance with a security or privacy law, could lead to certain losses suffered by the customer, including lawsuits, claims, regulatory actions and the incurring of breach notice expenses, forensic expenses or attorney fees. Indemnification clauses allow the indemnitee to recover losses associated with these types of claims and expenses from the indemnitor.

In this context for example, a Cloud provider might agree to indemnify a customer for lawsuits by the customer’s consumers who were impacted by a security breach suffered by the Cloud provider. The indemnification clause may require the service provider to pay for the cost to mail notice to individuals impacted by a security breach as dictated by breach notice laws. Note that indemnification clauses may be subject to a contract’s LOL if the clause does not include a carve-out or exception for indemnification obligations.

Now let's look at how these contract terms are used in the CSC and Google contracts.

Risk of Loss Terms in the CSC Contract

It appears that LA was able to obtain some favorable risk of loss terms, including unlimited liability for CSC with respect to certain loss elements related to security and privacy breaches. Significantly, CSC has agreed to be responsible for certain liabilities that may arise from Google’s (its subcontractor) acts, errors and omissions. Nonetheless, some interpretative issues exist arguably limit CSC’s obligations.

Warranties and Warranty Disclaimer

CSC provides some generic warranties in the CSC Contract (e.g. such as warranting that they are duly incorporated and in good standing), but also provides two additional warranties relevant to data security and privacy, including a warranty to comply with all laws and regulations “applicable to the performance by it of it is obligations under the Contract” (section 5.1.5), a warranty to use commercially reasonable virus detection software with respect to the software licensed under the CSC Contract, and a warranty to refrain from intentionally including computer viruses in the licensed software. CSC disclaims all warranties beyond those explicitly set forth in Section 5 of the CSC Contract.

While these warranties are substantive and provide the City of LA with a basis to claim breach of contract or breach of warranty if CSC violates them, any loss that arises out of a warranty breach is subject to and capped by the limitation of liability clause in the CSC Contract (discussed below). This raises an important point for customers negotiating Cloud contracts – you may fight hard and negotiate for a long time on substantive obligations such as warranties, but unless you get an exception to the LOL for breaches of warranties, your ability to fully recover loss for breach of warranty may be limited. 

Consequential Damages Disclaimer

Section 15.1. of the CSC Contract sets forth a fairly typical consequential damages disclaimer, which purports to relieve CSC of any liability arising out of “special, indirect, consequential or incidential losses or damages.” There are, however, two issues that jump out from the clause.

First, the clause also disclaims any liability for “penalties.” Penalties can arise in the security/privacy context out of contractual arrangements (e.g. fines and penalties imposed by Visa due to a payment card data breach) or regulatory actions (e.g. fines and penalties imposed by regulators due to violations). While some may argue that fines and penalties are “direct damages,” one could argue that this CSC clause pulls “penalties” out of the consequential/direct damages dichotomy and puts them in a separate category of loss that CSC is not responsible for.

Second, CSC’s disclaimer specifically references “lost or damaged data” as a consequential damage. As such, in the event of a security breach involving personal, CSC may argue that it has no liability to the extent such breach involved “lost or damaged data.”

Notably there are no exceptions to the consequential damages disclaimer, which may be problematic for the City. For example, assume that LA gets sued after a security breach involving credit cards and is required to pay a penalty to a card brand. Despite the indemnification language, CSC might take the position that it is not responsible for such penalty.

Indemnification

The CSC Contract contains several indemnification clauses whereby CSC agrees to indemnify LA under certain circumstances. We will focus on those related to security and privacy, which are set out in sections 15.5.2 an 15.5.3 of the CSC contract. Section 15.5.2, provides as follows:

In addition, Contractor undertakes and agrees to defend, indemnify and hold harmless City [ . . .] from and against all third party suits and causes of action, claims, losses, demands and expenses, including but not limited to, attorney’s fees and costs of litigation, damage or liability of any nature whatsoever, that [CSC or its Subcontractor] have breached its obligations to City under Section 10 (Confidentiality and Proprietary Rights) only with respect to the disclosure of such End User’s information and to the extent such disclosure is the result of actions predominantly attributable to (as agreed by the parties, said agreement, not to be unreasonably withheld) [CSC or its Subcontractors]

In addition, section 15.5.3 requires CSC to indemnify LA for similar loss elements arising out of “lost City Data.” Such indemnification obligations appear unlimited with respect to events occurring within 30 days after LA’s full and final acceptance of the services, and are capped at $7.7 million after that 30 day period.

Limitation of Liability

Section 15.1.2 sets forth an interesting limitation of liability clause. The limitation of liability under the CSC contract actually changes over time during the contract. During the first 12 months the LOL is $2.1 million, for months 13-24 the LOL is $1.4 million, for 25-36 it is $1.4 million, etc. through the end of the 60 month contract. What is somewhat unclear is whether the LOL’s for each year are cumulative. 15.1.2 does indicate a $7.7 million "total", but that may be for the entire contract not a given year. For example, the total for months 25-36 is $4.9 million, but the LOL for those months is $1.4 million. Does that mean that the most the company can recover during those months is $1.4 million, or can they recover up to the total of $4.9 million in that year? Not clear.

The scope of this LOL is also arguably unclear. For example, does this LOL apply to liability that arises out of breach of contract only, or does it also limit liability for torts outside of the contract such as negligence or fraud? Many LOLs that I have seen specifically indicate that the LOL applies to contract, tort, statute or any other theory of liability.

As part of the limitation of liability section, 15.1.3.1 sets forth a liquidated damages provision that allows LA to recover $10,000 for an incident involving a breach of confidentiality obligations by CSC. Incident in this case means “all disclosures of City Data to unauthorized recipients arising from the same specific cause or causes.” This provision does not apply to confidentiality breaches by Google or its subcontractors. The contract gives the City the ability to waive this provision and seek actual damages.

Significantly, CSC’s indemnification obligations in section 15.5 are not subject to the LOL. This means that CSC’s indemnification obligations under 15.5.2 (for breach of confidentiality) are unlimited. CSC’s indemnity obligations for “lost City Data” under 15.5.3 are also not subject to the staggered LOL in 15.1.2.  Rather, as mentioned above, section 15.5.3 has its own built in $7.7 million LOL. In addition, under 15.1.3., liability for breach of any confidentiality obligation is not subject to the limitation of liability under 15.1.2. All other provisions, breaches, liabilities and losses are purportedly subject to the LOL.

Observations

The risk of loss terms in the CSC Contract raise several issues related to privacy, security and legal compliance. The following matters suggest that CSC is accepting a broad range of liability:

• Google is defined as a CSC “Subcontractor.” Therefore, as respects indemnification for a breach of confidentially obligations or for lost City Data, CSC would be responsible to pay for Google’s act or error.

• CSC’s Indemnification Obligations for End User Information Confidentiality Breaches are Unlimited. The LOL in the CSC contract explicitly exempts CSC’s indemnification obligations under 15.5.2 from the damage cap of the LOL.

• "Direct Damages" for Breach of Confidentiality Obligations are Unlimited. Section 15.1.3, specifically indicates that the contract’s LOL does not apply to breaches of confidentiality obligations. However, as mentioned in Part One, some service providers might take the position that a third party accessing and stealing data is not an “affirmative disclosure” by CSC or its Subcontractors (e.g. CSC did not consciously disclose such information).  Moreover, since CSC attempts to disclaim liability for "lost or damaged data," the scope of "direct damages" arising out of a security breach may be limited.

The following issues are potential limiting factors with respect to the liability accepted by CSC under the contract:

• No CSC Liability for "lost or damaged data”.  As mentioned above, the consequential damages disclaimer explicitly includes “lost or damaged data” as part of consequential damages.  While awkwardly drafted, this provision may essentially eliminate CSC liability for some data security breaches.  However, depending on the definition of "lost" in the security breach context, the scope of this limitation may be narrow.

• No Indemnification for Failure to Implement Security. There are no explicit indemnification obligations with respect to CSC’s information security obligations set forth in section 11 of the CSC contract, and any recovery by LA would be argued to be limited by the LOL and the consequential damage disclaimer.

• No Indemnification for Breaches of Privacy and Security Laws. There is no explicit obligation to indemnify the City should CSC or its Subcontractors violate a security or privacy law.

• Breaches of Warranty are Subject to the LOL. In some service provider contracts, a breach of warranty may not be limited by the limitation of liability clause. Not so for purposes of the CSC contract.

• No Explicit Security Breach Indemnification and the Meaning of “Disclosure”. In Section 15.5.2, there is no explicit indemnification for a security breach that involves a third party gaining unauthorized access to City Data. While there is indemnification for “disclosure” of End User data, as mentioned in Part One, some service providers might take the position that a third party accessing and stealing data is not an “affirmative disclosure” by CSC or its Subcontractors (e.g. CSC did not consciously disclose such information).

• No Explicit Security Breach Indemnification and the Meaning of “Lost.” Section 15.5.3 also provides indemnification for “lost City Data,” and that could arguably encompass a security breach situation (or at least a subset thereof). However, some might argue that data taken by a third party is not “lost.” If a copy of the data remains, has it been “lost?” Does “lost” apply only to situations such as lost laptops with data on them, such that the data is irretrievable? The City could have clarified CSC's obligation by inserting into the contract references to unauthorized access or use of City Data, and perhaps stolen or unauthorized copying of data.

• Breach Expense Elements. There is no explicit indemnification for breach notice expenses, forensic expenses, credit monitoring expenses or call center expenses (although such expenses could be argued to be included as indemnifiable expenses in general).

• Mutual Agreement for Indemnification for Confidentiality Breaches. CSC's indemnification obligations in section 15.5.2 may be hard for LA to enforce because it requires that CSC and LA mutually agree that the disclosure of End User information was “predominantly attributable” to CSC and its Subcontractors. While there is a reasonableness standard built into that mutual agreement requirement, the practical reality is that it might be difficult to get CSC agree to indemnify, especially if large amounts of money are at issue.

• Indemnification for Confidentiality Breaches Limited to End User Data. Rather than indemnifying for breaches involving any City Data, section 15.5.2 only applies to “End User’s information.” The term “End User” appears to have been pulled from the Google Contract (which is attached as an exhibit to the CSC Contract) and is defined as the individuals the City permits to use the Services.

The scope of “End User information” is not clear. For example, End User information might refer to the personal information of Google’s SaaS users that they input in order to use the software (e.g the name and particulars of City employees that use Google’s SaaS). In that case it might not include, for example, a database sent by LA employees using the software containing the personal information of City residents. It would probably have been better from the City’s point of view to define that term, or to have used a broader term such as “protected information” as set defined in Section 11 of the CSC Contract.

Risk of Loss Terms in the Google Contract

The Google Contract also has its own risk of loss contract language. While the Google contract has some of the same provisions as the CSC Contract, some of Google’s risk of loss terms are actually simpler and more straightforward. Overall, the Google Contract does provide unlimited liability for security and privacy breaches in some circumstances, and actually may provide slightly more protection to LA (as compared to the CSC contract).

Warranties and Warranty Disclaimer

Google provides some very basic warranties, which are not really related to security or privacy. Google does, however, warrant that it will comply with its service level agreement, which relates to availability aspects of security. All other warranties are disclaimed.

Consequential Damages Disclaimer

Section 14.1 of the Google Contract disclaims “consequential damages” as follows:

NEITHER PARTY WILL BE LIABLE UNDER THIS AGREEMENT FOR LOST REVENUES OR INDIRECT, SPEICAL, INCIDENTIAL, CONSEQUENTIAL, EXEMPLARY OR PUNITIVE DAMAGES, EVEN IF THE PARTY KNEW OR SHOULD HAVE KNOWN THAT SUCH DAMAGES WERE POSSIBLE AND ENVE IF DIRECT DAMAGES DO NOT SATISFY A REMEDY.

Significantly, however, section 14.3. of the Google Contract indicates that the consequential damages disclaimer does not apply to breaches of confidentiality obligations or indemnification obligations.

Indemnification

Section 13.2.3 of the Google Contract contains an indemnification clause that is very similar (if not exact) to the version contained in section 15.5.2 of the CSC Contract, which provides indemnification for breaches of section 7 of Google’s Contract (Confidential Information section), but only with respect to disclosure of End User information, and only if the Google and LA mutually agree that the disclosure was “predominantly attributable” to Google (or its subcontractor).

Section 13.2.4 of the Google Contract also contains a provision providing indemnification for “lost Customer Data” (again similar to/same as section 15.5.3 of the CSC Contract). Liability is unlimited for indemnification under 13.2.4 until 30 days after the City has accepted the services, and thereafter is capped at $7.7 million.

Limitation of Liability

The limitation of liability clause of the Google Contract provides as follows:

NEITHER PARTY MAY BE HELD LIABLE UNDER THIS AGREEMENT FOR MORE THAN THE AMOUNT PAID BY CUSTOMER TO RESELLER DURING THE TWELVE MONTHS PRIOR TO THE EVENT GIVING RISE TO THE LIABILITY.

However, section 14.3. of the Google Contract indicates that the LOL does not apply to breaches of confidentiality obligations or indemnification obligations.

In addition, this LOL may arguably relate only to liability for breach of the Google Contract (“this Agreement”). The LOL does not specifically indicate that liability is limited for torts outside of the contract such as negligence or fraud, or violations of statutes.  As such, if LA sued Google under a negligence theory some might argue that Google is not protected by this LOL.

Observations

The risk of loss terms in the Google Contract raise several issues related to privacy, security and legal compliance. The following matters suggest that Google is accepting a broad range of liability in the Google Contract:

• Direct Damages and Consequential Damages Unlimited for Breaches of Confidentiality Obligations.  Breaches of confidentiality obligations under the Google Contract are not subject to the LOL, and therefore Google's liability arising out of such breaches is  potentially unlimited. Note, however, that there may be some “natural limits" with respect to consequential damages that may apply (e.g. foreseeable loss). On its face, the Google Contract is broader in terms of the liability Google has explicitly agreed to for confidentiality breaches.  Nonetheless, the true scope of Google's liability depends on the meaning of confidentiality breach under the Google Contract (discussed further below).

• Google’s Indemnification Obligations for Confidentiality Breaches are Unlimited. If Google’s indemnity obligation is triggered, it is not limited by the LOL in Google's Contract. However, as discussed below, the scope of those indemnification obligations may be limited, and it may be difficult to actually trigger those obligations.

• Broader Confidentiality Obligations? Unlike the CSC contract, Google's confidentiality obligations also explicitly require Google to “protect” LA’s confidential information using the same standard of care that Google uses to protect its own confidential information (and in no event less than reasonable care). This is in addition to an explicit duty to “not disclose” LA’s confidential information (by the way, Confidential Information as defined explicitly includes “Customer Data.”).  The addition of this explicit duty to protect arguably would encompass a security breach where a third party was able to obtain or access LA’s data stored or processed by Google. Ironically, CSC might use Google’s explicit reference to this protection obligation to argue that its obligations were limited to “disclosure” (in the affirmative sense of giving away confidential information). However (as discussed), based on the same logic set, Google may have an argument that is indemnification obligations for confidentiality breaches are limited to "dislcosures."

The following identifies potential limiting factors with respect to the liability accepted by Google under the contract:

• No Indemnification for Breaches of Privacy and Security Laws. There is no explicit obligation to indemnify the City should Google or its subcontractors violate a security or privacy law.

• No Explicit Security Breach Indemnification and the Meaning of “Disclosure” in 13.2.3. There is no explicit indemnification for a security breach that involves a third party gaining unauthorized access to the City’s data. Moreover, the indemnification clause set forth in 13.2.3 relates only to the “disclosure” of End User information, as mentioned in Part One, some service providers might take the position that a third party accessing and stealing data is not a “affirmative disclosure” by Google. This argument might be buttressed by the fact that the Confidentiality section of the Google contract also references a duty to “protect,” but that duty is not referenced in the indemnification clause.

• Indemnification for Confidentiality Breaches Limited to "End User information". Rather than indemnifying for breaches involving any Customer Data (a term defined int the Google Contract), section 13.2.3 only applies to “End User’s information” (an undefined term). While the term “End User” is defined as the individuals the City permits to use the Services, the meaning of “End User information” is not clear. However, the definition of “Customer Data” which was  not used in the indemnification clause, arguably provides some indication as to the meaning of “End User information”:

“Customer Data” means all data and information provided by End Users via the sign-up process for the Services, as well as data, including email, documents, spreadsheets, presentations, and videos provided, generated, transmitted or displayed via the Services by Customer, or Reseller on behalf of Customer.

If Google wanted to argue for the limitation of its indemnification obligations, it might point to the Customer Data definition and maintain that “End User information” means the information End Users provide during the sign-up process (e.g. basically LA employee and contractor personal information). Google could argue that the data provided, generated or transmitted via the services is not End User information. This information could include, for example, personal information in a data base of LA residents that is sent in an email via Google's SaaS. Google would claim that if it intended to provide indemnification for confidentiality breaches involving this type of information it would have used the term Customer Data instead of “End User information” in the indemnification clause. The bottomline is that LA could have taken away any ambiguity simply by demanding indemnification with respect to Customer Data; they did not, so that uncertainty will linger.  Note that this could impact the scope of CSC's indemnification obligation since it refers to "End User information" as well.

• Mutual Agreement for Indemnification for Confidentiality Breaches. Section 13.2.3 may be hard for LA to enforce because it requires Google and LA to mutually agree that the disclosure of End User information was “predominantly attributable” to Google or its subcontractors. While there is a reasonableness standard built into that mutual agreement requirement, the practical reality is that it might be difficult to get Google agree to indemnify, especially if millions of dollars are at issue.

• No Explicit Security Breach Indemnification and the Meaning of “Lost.” This is basically the same issue discussed above concerning the CSC Contract. The Google Contract also provides indemnification for “lost Customer Data,” but again some might argue that data taken by a third party is not “lost.” If a copy of the data remains, has it been “lost?” Does “lost” apply only to situations such as lost laptops with data on them, such that the data is irretrievable? References to “unauthorized access” or “unauthorized use” of Customer Data, and perhaps stolen data may have expanded these indemnification obligations to cover security breach situations.

• Breach Expense Elements. There is no explicit indemnification for breach notice expenses, forensic expenses, credit monitoring expenses or call center expenses (although such expenses could be argued to be included as indemnifiable expenses in general).

Conclusion

So now that we arrive at the end of this blog series it is worthwhile to go back to the beginning. One of the goals of this series to was to validate reports that LA had convinced Google to be responsible for unlimited liability arising out of security breaches. At the end of the day, it appears that this statement is true at least with respect to some “security breaches,” but with many caveats and limitations.

It appears that Google has provided unlimited liability for direct and consequential damages for security breaches that are violations of the confidentiality obligations. While CSC’s obligations are arguably limited to unauthorized disclosures, Google could be in violation of its confidentiality breaches if it fails to protect LA’s information using the same standard Google employs internally and/or reasonable care (note that many would argue that "disclosure" includes this protection obligation, so CSC's obligations may be similar). So, with respect to the specific "protection" obligation, unlimited liability is available from Google for security breaches only if LA can establish that Google failed to protect LA’s information the same way Google protects its own or if Google used less than “reasonable care.” In other words, Google is not automatically liable for all of LA’s loss arising out of a security breach under this protection prong (note again, arguments may exist with respect to Google's disclosure obligations).

It is also possible for LA to get unlimited indemnity for City data “lost” (e.g. a lost laptop with personal information on it) due to acts or CSC or Google within 30 days of Google’s services being finally accepted by the City. It may also be possible (but is less likely) to get unlimited liability indemnification arising out of breaches of confidentiality involving “End User information.” This will depend, however, on the meaning of “disclosure” and “End User information.”   It will also require CSC and/or Google to essentially consent (e.g. mutually agree) to provide such indemnification (in my book this is not really a workable indemnification scenario, especially for big breaches where a lot of money is on the line;  CSC and Google are not likely to provide consent and there is no additional contract remedy if such consent is unreasonably withheld).

One final note, LA does have an advantage in terms of risk of loss because it has separate contracts with CSC and Google. As such, it can go after each company should a security or privacy breach occur. Moreover, even if a LOL applies, it may be able to collect from both Google and CSC (effectively doubling the LOL that is applicable to this transaction).

Thanks for reading through this series (assuming you made it this far). If you have any questions, you can contact me at 303.325.3528 or via email at dnavetta@infolawgroup.com

On that issue the PC World article reported the following:

Google moved early to make this a contest over which company offers the best contract terms and legal protections in cloud environments. The city of Los Angeles, which may be Google's marquee government user, has been frank in disclosing details of its agreement. By the end of June, Los Angeles expects to complete a transition of some 30,000 employees to Google Apps.

In a sense, Kevin Crawford, Los Angeles assistant director of IT, is Google's de facto public sector evangelist. He doesn't market Google directly, but he answers questions from many other local government and state officials who want specifics about the city's deal with Google. Indeed, at the SaaScon conference on cloud computing and software as a service here this week, Crawford has been peppered with questions about the contract terms.

Los Angeles has been frank about the contract, which includes unlimited damages for a data breach, provisions allowing audits, guarantees that the data remain in the contiguous 48 states, and penalties if Google's services are unavailable for any longer than five minutes a month.

The contract also gives the city the right to cancel its contract with Google "for convenience," Crawford said.

Moreover, the contract reportedly includes specific data security and privacy controls and requirements and "unlimited damages" if Google breaches confidentiality obligations:

Los Angeles spent months negotiating a contract with Google that includes a provision providing the city with unlimited damages if its nondisclosure agreement (NDA) is breached by Google, said Kevin Crawford, the assistant general manager of IT for Los Angeles and the person who is managing the transition. That clause aims to protect the city from a third party claim if personal data is release, said Crawford.

Crawford said the most important clause in the contract requires that Google to encrypt the city's data and break it into pieces when it is at rest so that no one can get their hands on a full file. If hacker somehow accesses a file, he will only see "a whole bunch of gibberish," Crawford said. The contract also bars Google from viewing any data without permission from the city.

Los Angeles data will be administered from inside LA's firewall by city staffers through an administrative console built by Google, said Crawford. "We have control of our portion of the data," he said.

Moreover, the data must remain on systems within the continental U.S. That can be verified via auditing by the city, Crawford added.

"We're going to have a more secure system then we have today," said Crawford, noting that Google personnel does more work on security "than we could ever afford to do."

The Information Law Group has previously discussed the importance of data security, privacy and compliance in the Cloud context.  This situation seems to validate the premise that Cloud providers are going to (and willing to) compete on these issues and the contract terms that relate to them. 

From the InfoLawGroup's own recent experience, data security and privacy terms (and associated indemnities and shifting of risk of loss) have become much more important in IT outsourcing arrangements (whether Cloud or "traditional").  Lately it seems that right after price and service description/promises, significant time, effort and expense are being expended drafting and negotiating data security and privacy terms.  In fact, because of the complexity of security and privacy, and associated laws, in InfoLawGroup's recent experience, these terms can take more time to settle out then more "basic" contract terms.  Overall, the key reality at this juncture is that there is significant financial risk associated with poor data security and privacy and related regulatory requirements.  In many cases, in terms of pure dollar amount this risk can dwarf the value of the contract (or the savings of the contract) if favorable contract terms are not negotiated.

One thing to note, having reviewed the Google contract (and the related Computer Science Corporation contract), which can be found at the end of this report, the scope of Google's contractual promises may not be quite as clear cut as described by LA officials (a breakdown of the Google data security and privacy contract terms will be the subject of a second post on this issue).

What does this mean for customers entering into Cloud (or other outsourcing) contracts?

So what does this all mean to companies looking to go into the Cloud and hoping for contract arrangements that offer protection?  A lot.  Organizations are giving up a great deal of control when they outsource into the Cloud, and only good contract terms can compensate for that loss of control.  Unfortunately, many companies are focused on basic contract terms like price and often find themselves in a "take it or leave it" position when it comes to data security and privacy terms.  In terms of timing, lawyers working on these contracts often find that the service provider is more or less "locked in" at the point where data security and privacy contract terms are first addressed.  Oftentimes competitors have been eliminated and are no longer in the picture, and as a result the customer has little leverage to negotiate more favorable terms.

To be in a better position to negotiate favorable data security and privacy terms the current leverage dynamic needs to change.  This LA-Google situation is a very favorable sign that service providers, if handled properly, are willing to negotiate on these terms in order to win a contract.  However, customers must realize that most service providers are not going to approach a contract this way unless the customer creates an environment that provides it with leverage.  To achieve this customers looking to enter into IT outsourcing arrangements (Cloud or otherwise) should consider the following:

• Approach multiple vendors.  In many cases the only viable threat a customer has is to walk away to a competitor.  If no competitors are in the picture then there is not realistic threat and no leverage exists.  The problem is that many companies are attracted to a specific vendor, or other vendors don't quite have the same service offering as the preferred vendor.  Nonetheless, rather than becoming blindly enamored with a particular vendor, organizations would be well-served to find and look at competing offerings (at least to get some negotiating leverage against the primary vendor).

• Address these issues at the "Request for Proposal" phase.  Price and service offering description are the key components that go into a RFP, but considering the material financial risk posed by data security and privacy, why shouldn't those terms be highlighted in an RFP as well?  Rather than getting locked-in to a service provider after the RFP phase, it is better to lock the service provider into the data security and privacy terms you desire at the outset.  This is the time where the providers will be hungry and more willing to concede on issues.  The RFP should include the specific security and privacy requirements the organization desires, as well as specific contract language that should be included in the contract.  For companies that do a lot of IT outsourcing, these documents can be standardized and simply plugged into the RFP (which also has the benefit of creating consistency across the organization).  If you don't have an RFP process, then you should.  Adding data security and privacy requirements (and contract language) ♠changes the dynamic and makes the service provider compete on all aspects of the transaction.

• Keep competitors around.  Rather than eliminating alternatives at the outset, keep other competitors around (even if their offering may not be 100% ideal).  Again, the longer you can maintain your threat to walk away to a competitor, the stronger your position will be to achieve concessions.  Moreover, the "less than ideal" competitors can start to look more attractive when your "ideal" service provider refuses to accept any responsibility for your data security or privacy.

• Pre-establish your positions and your fall-backs.  It is important to predetermine your positions regarding data security and privacy risk and the contract terms your organization is willing to accept.  Organizations that routinely enter into contracts implicating these issues should develop a security and privacy schedule that indicates specific controls that are required.  The legal team should develop primary and secondary positions for confidentiality obligations, indemnification, limitations of liability, consequential damages disclaimers, compliance with privacy and security laws, and other related contractual requirements.  These back-end contract terms can be folded into and made part of the RFP.  They also provide for consistency across the organization and let the company understand and manage its exposure when using third parties to store, transmit or process data.

Conclusion

From the customer perspective, it is very encouraging to see a major Cloud provider willing to negotiate on data security and privacy contract terms in order to win business.  However, it is likely that the result in this case was very much due to how Los Angeles handled the negotiation. Organizations that are concerned about these risks when they enter into the Cloud need to position their organization and the transaction in a manner that changes the leverage dynamic in their favor. Otherwise, they may find themselves at the end of a contract negotiation taking on enormous risk with little actual control over the risk.

The next 10 years will see more types of data collected from more people, and more privacy laws in more places. A deepening and broadening of data protection regulations in the industrialized world will spread to emerging markets and place a higher premium on legal and compliance acumen. In addition, an expansion of health information networks, smart grid networks and cloud computing platforms will make industry and technology expertise a more indispensable part of practicing privacy.

. . . the privacy professional’s success in the next decade will demand greater adaptability and most importantly, agility. The agile privacy professional is the next-generation privacy professional: an expert practitioner who is keenly attuned to cultural and regional distinctions as these continue to grow in an increasingly interconnected data economy; who can migrate and adapt to different roles within an organization and offer value at each; who exhibits both comfort and grasp of legal/compliance and technical disciplines; and who instills direction and leadership of privacy management within the organization.

The following analysis and discussion of the IAPP's whitepaper is completely my own.  I think that the paper raises some incredibly important points about the need for privacy professionals to lead the way for more effective information governance.  As an outside lawyer (with my own unique perspective), my key takeaway is the following -- privacy professionals must understand law AND technology, and must facilitate dialogue between those two disciplines and as between those disciplines, on the one hand, and the business side, on the other.

The importance of a "privacy professional" understanding both legal and technical disciplines cannot be overstated:

The central role of regulatory and IT drivers shaping the privacy profession almost ensures an ongoing need for privacy professionals to be conversant in not one, but both of these disciplines.

Regulation and "Reasonable Security"

I believe this is largely due to what the IAPP describes in the whitepaper as the "Second Wave of Regulation," which began in approximately 2003 with California's landmark data breach notification legislation, Civil Code section 1798.82 (for private entities), often called SB 1386.  On the heels of that came 44 additional such state laws, DC, Puerto Rico, the Virgin Islands, and now some similar European legislation, as discussed in the whitepaper.  And, with the light now shining on security risks and failures within private organizations, additional security standards and legislation began to emerge - most notably, as highlighted by the IAPP, the Payment Card Industry (PCI) Data Security Standard (DSS) and laws such as Nevada's (SB 227) that incorporate that Standard.  For more on that, see Dave's posts here, here and here. Further, as noted in the whitepaper,

A number of factors have spurred North American (and particularly American) organizations to dedicate more resources to privacy process improvement: most notably, PCI DSS enforcement, FTC enforcement, and data breach notification.

Not discussed in the IAPP whitepaper in depth, but just as important, a number of states have crafted legislation designed to require "reasonable" security or safeguards to address security risks in a more proactive fashion, as opposed to the traditional reactive breach notification approach.  Massachusetts, Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05, is of course the most recent, most detailed, and most well known, but many states require the same "reasonable security" (sometimes for all personal information, sometimes for just Social Security numbers), including, but not limited to, California (Civ. Code §§ 1798.81, 1798.81.5, and 1798.85), Arkansas (Code Ann. §4-110-104(b)), Colorado (Rev. Stat. Ann. §6-1-713), Connecticut (HB 5658), Maryland (Com. Law Code Ann. § 14-3503), Nevada, as mentioned above (Rev. Stat. § 603A.210 and SB 227), Oregon (Rev. Stat. § 646A.622), Rhode Island (Stat. § 11-49.2-2), Texas (Bus. & Com. Code Ann §§ 48.102(a)  and 521.001, .052, .151) Utah (Code Ann. § 13-44-201), and Washington (Rev. Code Ann. §19.215.020 to .030).  There are more, I could go on.

What in the world is "reasonable security"?  A privacy professional who understands the law and traditional notions of negligence, various concepts of privacy (Fair Information Practice Principles, etc.) as embodied in different standards and legislation around the world (from EU to Australia), and the evolution of information security (as a technical matter) is ideally positioned to help assess what "reasonable security" means and determine what will be compliant, what will be legally defensible, what will be best practice, and what will be just good business.  And such a privacy professional can facilitate discussions among stakeholders that speak somewhat different languages in this regard to reach solutions that are acceptable to all involved.

From Privacy to Information Governance

As a lawyer, I am also extraordinarily pleased to see, in the IAPP's whitepaper, a reference to the new ediscovery rules that came into play in the latter half of the 2000s, most notably the amendments to the Federal Rules of Civil Procedure in 2006.  What does privacy have to do with ediscovery?  Everything.  As noted in the IAPP's whitepaper, the amended rules "increased the need for organizations to conduct data inventories and implement data-retention policies."  How do you protect sensitive data (personally identifiable information, trade secrets, IP, etc.)?  You figure out where it is first.  And thus, as the IAPP points out, we start to see the "privacy" role evolve into an information governance role.

Speaking of information governance, let's return to technology.  States the IAPP: cloud computing will set the pace for the next decade:

One of the clear directions of technology in the past 10 years as it pertains to personal data has been more—more types of data collected from more people in more ways, and shared with more entities. The emergence of cloud computing—essentially a new computing paradigm in which data is stored off-premises and by a range of third parties—sets the pace for the next decade. Short of a wholesale social movement to opt out of information technology and “go dark,” the conveniences and commercial benefits of more data collection and sharing seem to point in the direction of more. People will not 'go dark,' we estimate, because the utility of sharing information will continue to well exceed the risks of doing so.

Thus, the IAPP stresses the need for agility and identifies five strategies for action:

(1) Redefine the privacy role [information governance]; (2) Rotate through departments/business units; (3) Develop multi-cultural literacy; (4) Understand legal and technical disciplines; and, (5) Instill direction and leadership.

Bottom line?  Proactive, multidisciplinary solutions to information governance that incorporate information technology savvy and that address compliance, legal defensibility, and best practices, are now and will become increasingly crucial to any organization that handles sensitive data.  Privacy professionals are well positioned to lead those efforts.  Congratulations to the IAPP on its 10th anniversary!  I look forward to the next 10 years.

In summary, my article discusses some of the similarities and differences between the current state-created breach notice regime and the system set forth under the proposed DATA law.  DATA is interesting because it appears to create counter-opposing breach notice incentives.  On the one had, there are mechanisms that could lead to less breach reporting, including:

• a "risk of harm" standard that is likely higher than many existing State laws;

• preemption of existing state law, which eliminates the "least common denominator" approach taken with respect to existing state law; and

• mandating call center and credit monitoring costs (e.g. these costs may be significant, and therefore encourage non-compliance, especially if enforcement is lax)

On the other hand, DATA allows for the imposition of civil penalties of up $11,000 per violation (capped at $5 million). Each failure to send the required notification to an affected individual is treated as a separate violation.  Depending on how vigorously the law is enforced, the risk of significant civil penalties is likely to encourage compliance.

How these factors would play out is unclear and up for debate.  However, what is even more unclear is whether DATA will ever be made into a law.  The Senate is working on a similar bill, and assuming it passes the Senate it would still have to be reconciled with the House version.  Consumer advocates will likely have concerns about the higher risk of harm threshold in the law.  On the business side, I anticipate great resistance to call center and credit monitoring as mandatory costs.  Moreover, the penalties for non-compliance may be problematic, especially for smaller and medium organizations.  As such, should DATA become a law, it is likely to differ from this version.

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.

Plaintiffs’ Allegations

In general, these matters involve a fairly consistent general set of allegations: 

• the bank allowed a small business to utilize online banking, including ACH transfers;
• nefarious third parties somehow gained access to the plaintiffs’ online banking account (e.g. login credentials such as username, password, “secret question”, etc.), which allowed them to use the online banking system to transfer (a.k.a. steal) funds out of the plaintiffs' bank account;
• the bank failed to provide notice to the plaintiffs of unusual or suspicious activity; and
• the bank’s security measures did not prevent the fraudulent transfers and were not commercially reasonable.

In addition, the following facts were alleged in one or more of the three cases:

• the bank failed to block a transfer request from an IP address that was previously unused by the plaintiff (e.g. an IP address was different than typically used by the plaintiff);
• the bank did not utilize multifactor-factor authentication (e.g. “token-based” authentication or fax confirmation);
• the allowable daily transfer limit vastly exceeded the plaintiffs’ average/maximum daily transfers (e.g. in PATCO, the daily maximum limit was $750k, but the most PATCO ever needed to transfer was $36.6k);
• the funds were transferred to individual accounts to which the plaintiffs had never transferred funds before; and
• despite having been informed of unauthorized transactions by the plaintiff, the bank did not close the account in order to prevent more fraudulent transactions (JMT case only).

Alleged Legal Theories

Based on these facts the plaintiffs asserted various causes of action against the banks relating to security practices. In both PATCO and JMT, the plaintiffs referenced the bank’s failure to comply with section 4A-202 (ISSUE AND ACCEPTANCE OF PAYMENT ORDER) of the Uniform Commercial Code (in PATCO the plaintiffs cited MRSA 4-1202 and in JMT they cited RS 10:4A-202). Under 4A-202, as long as the bank and its customer have agreed that the customer will be verified pursuant to a “security procedure”, a payment order received from the customer will be considered an effective order by the customer, whether it was actually authorized by the customer, but only if the security procedure was “commercially reasonable” and followed by the bank.   In PATCO, for example, the plaintiffs alleged that 4A-202 had been violated for the following reasons:

• failure to offer/use multi-factor authentication to authenticate the plaintiffs’ identity for online transactions;
• use of an unreasonably low trigger for “challenge question” authentication;
• failure to provide and IP address block that would block orders originating from unapproved IP addresses;
• failure to detect fraud because the amounts of the payments were the largest ever made under the account, were sent to accounts to which funds had never been transferred, originated from an IP address that had never previously been used and occurred on days that the plaintiff normally did not may payments;
• failure to offer a dual control option requiring two people to log on in order to complete a payment transaction;
• allowing a transfer limit that exceeded the needs of the plaintiff;
• failure to manually review ACH payment batches prior to submission for payment; and
• failure to provide email alerts concerning unusual transactions.

In addition to a UCC violation, all of the cases included allegations of negligent security and breach of contract. In Shames-Yeakel, the plaintiffs alleged that the bank’s failure to implement multi-factor authentication did not comply with a document put out by the Federal Financial Institutions Examination Council (“FFIEC”) entitled “Authentication in an Internet Banking Environment” (the FFIEC Report), and therefore presented questions of fact as to negligence. The JMT plaintiff, in support of its negligence claim, alleged a failure to meet the security standards of “similarly situated” national banks,  a failure to implement security procedures that were “commercially reasonable,” and a failure of the bank to comply with its own existing security procedures.

The Judgment on the Shames-Yeakel Motion for Summary Judgment

While the PATCO and JMT complaints have not yet been tested on motion, the Shames-Yeakel plaintiffs have survived a summary judgment motion. In addition to other statutory claims that were particular to the fact pattern at hand, and relevant to this blogpost, the plaintiffs alleged that the bank was negligent in failing to protect the plaintiffs’ online account, and in particular breached its duty to sufficiently secure its online banking system. 

As such, the threshold question the court addressed was whether a duty to “sufficiently secure” its online banking existed for the Bank.   On that point, the court extrapolated a duty to secure based on a bank’s general duty to refrain from disclosing its customer’s information:

A number of courts have recognized that fiduciary institutions have a common law duty to protect their members’ or customers’ confidential information against identity theft. Although this court could not find an Indiana case addressing the matter, Indiana courts have held that a bank “has a duty not to disclose information concerning one of its customers unless it is to someone who has a legitimate public interest.” If this duty not to disclose customer information is to have any weight in the age of online banking, then banks must certainly employ sufficient security measures to protect their customers’ online accounts.

(citations omitted; emphasis added). Apparently, according to the court, the bank-defendant did not dispute the existence of a duty to protect the plaintiffs’ account from fraudulent access. However the bank did contest the plaintiffs’ allegations that the bank breached its duty and that the breach caused harm to the plaintiffs.

On that issue, the court focused on the FFIEC Report. According to the court, the FFIEC  Report indicated that single-factor identification was “inadequate” for securing online transactions of financial institutions. Moreover, a vice president of the bank admitted that the bank did not implement additional security measures beyond single factor identification until after the breach at issue. Thus, the court held that a reasonable finder of fact could potentially conclude that the bank breached its duty. Moreover, since the bank had not reimbursed the plaintiffs for their economic loss, the court ruled that a jury could find that the bank’s failure to secure caused such economic loss (as well as mental and emotional anguish).

Analysis

The Shames-Yeakel case (as well as potentially the PATCO and JMT down the line) is very interesting from a data security breach liability perspective. First, most data breach cases (typically involving suits by consumers or banks issuing credit cards) are dismissed early on for lack of damages or based on the economic loss doctrine. With online banking the damage component is clear (e.g. lost money) and since the main loss of money arguably constitutes “direct damages” (rather than purely economic damages), the economic loss doctrine may not bar an action. As such the court must rule on substantive issues such as the existence a duty to provide “reasonable security” and whether that duty was breached and caused damages. This is what happened in Shames-Yeakel.

The approach taken by Shames-Yeakel was also very interesting. In essence, the Court took a non-binding, completely voluntary “guidance” document and allowed it to serve as the standard of care for “reasonable security” in this context. This FFIEC Report was not an official “standard” and did not reflect any statutory requirements (for purposes of establishing a negligence per se theory). I am sure that the FFIEC and other bodies have put out a lot of papers (formal and informal) on various security and privacy issues, and if other courts are willing to accept these guidance documents as establishing standards (or better stated creating a question of fact for juries) then defendants of data breach cases may  face some significant liability in the future. While this particular FFIEC Report may be the appropriate benchmark in this case, I would have liked to see the court explain its rationale in more detail for converting this guidance document into the standard of care (e.g. Why this particular document? What other kinds of documents reports may establish the standard? If it was a report from a non-governmental body would it have the same weight? Must the standard reflect some sort of consensus? What opposing guidance or opinions exist, how much weight are they given in determining or discarding a particular alleged standard?, etc.)

Beyond the court’s decision to arguably elevate the importance of the FFIEC Report, it is not even clear that the report stands for the very broad proposition that single-factor authentication for online banking is inadequate. The following excerpt from the FFIEC Report summarizes the authors' views on the inadequacy of single-factor identification:

The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Financial institutions offering Internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services. Account fraud and identity theft are frequently the result of single-factor (e.g., ID/password) authentication exploitation. Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

Note that the FFIC Report indicates that single-factor authentication may be inadequate if it is the only control mechanism or where a risk assessment indicates that the use of single-factor authentication is inadequate. The FFEIC Report then lists layered security or multi-factor authentication as potentially compensating for single-factor authentication (while I will let my security friends weigh in on this issue, as well as identify other potential compensating controls). In short, the FFEIC Report on its face seems to indicate that it is possible to utilize single-factor authentication with other controls such that risk is adequately mitigated. In contrast, the court in Shames-Yeakel stated the following: 

In [the FFEIC Report] the Council described single-factor identification (username/password) as “inadequate” to secure the online transactions of financial institutions. 

Despite overstating the conclusion of the FFIEC report, however, overall the court’s decision to deny the motion for summary judgment may be okay. It is likely that both parties have contradictory expert testimony on the issue of reasonable security. Second, some testimony existed from the bank's vice president hat appears to establish that only single-factor authentication was used by the bank (although this seems contradicted by the banks’ expert testimony that the bank employed reasonable security measures). Moreover, in general, whether single-factor authentication plus additional security adequately reduced the risk appears to be a factual question. I think the court could have come out with the same ruling without overstating the conclusions of the FFIEC report simply by accurately citing the FFIEC report, the vice president’s testimony, and indicating that both sides had contradictory opinions on the overall issue of whether the bank’s security was reasonable. 

Conclusion

The Shames-Yeakel ruling highlights potential significant difficulties for defendants if plaintiffs are able to proceed past the motion to dismiss phase in a data breach lawsuit. Despite the court’s inaccurate description of the FFIEC Report, when the question of whether security controls were adequate to reduce risk to an appropriate level is posed, it will be difficult for defendants to win on summary judgment. Like many other types of lawsuits, it will come down to a “battle of the experts”, and for these cases a “battle of the standards” (e.g. which standards should the defendant have complied with and did they comply with them). As such, for data breach defendants the pleadings phase will be where the street brawl will take place. Defendants will want to (and should) aggressively attack the early “questions of law” (e.g. does a duty exist at all, did the plaintiff suffer legally cognizable harm). If plaintiffs can get past this phase, it seems that it will be a challenge for defendants to win a motion for summary judgment and avoid the prospect of a jury trial (I think, for many data breaches, causation will be the most likely candidate for a defendant victory on summary judgment).

Dark Opaque Storm Clouds or White Fluffy Transparent Clouds?

When it comes to relationships is the Cloud more like a dark storm cloud that one cannot peer into, or is it more like a fluffy, light and transparent cloud that allows one to see what is happening within? Unfortunately, the current forecast in some areas is for dark Clouds that make it difficult for Cloud Users to understand exactly with whom they are dealing and who is storing and processing their data.   Transparency may be elusive and the very nature of the Cloud computing architecture may be the cause of this. In other words, even if an attorney wants to discover who is actually processing their data, the nature of the Cloud may make it very difficult for Cloud providers to provide definitive information on that point. This is in stark contrast to most traditional outsourcing relationships involving a single vendor and dedicated computing resources or software.

Moreover, even if all the Cloud players are known, it may be difficult for Cloud Users to manage and shift responsibility to a party that it has no direct relationship with, and no direct contractual legal rights or remedies. 

In a traditional dedicated outsourcing model (e.g. web or data hosting, ASP model, etc.) organizations often deal with a single service provider that provides computing resources. That service provider typically would own or control the computing resources that support the outsourcing transaction. Oftentimes those computing resources would be dedicated solely to a particular client. To clarify and solidify this one-to-one relationship the outsourcing contract might have a clause prohibiting the use of sub-contractors to provide the services. In terms of legal risk, the organization utilizing the service provider would be able to conduct its due diligence (e.g. privacy compliance, “reasonable security,” etc.) on a single entity. Moreover, the organization would be able to negotiate a contract shifting risk between it and the service provider knowing that the service provider in essence directly “controlled” the risk by virtue of its control of the computing environment. Even in cases where a service provider uses a sub-contractor, in the typical case, the organization could fairly easily discover the identity of that party and perform its due diligence. More rare are instances of generic unidentified sub-contractors, or sub-contractors utilizing sub-sub-contractors.

Relationships in the Cloud: Who is processing my data?

It can be very different in the Cloud (click here to view one version of the Cloud landscape). This is not to say that Cloud relationships are not/cannot involve one-to-one relationships like traditional outsourcing. They can. At the base of the Cloud stack, it would not be unusual for IaSS providers to have direct relationships with some of their end-clients. For example, if an organization contracts directly with Amazon Web Services, a Cloud Platform (Infrastructure as a service – IaaS), to allow the organization to build its computing resources in Amazon’s Cloud, it would have a degree of confidence that it was dealing with the party that directly controlled and was responsible for maintaining the Cloud Platform. However, there are service-oriented organizations (integrators) that will actually help to build computing resources on a particular Cloud Platform. In that case a client would not necessarily have a direct relationship with the Cloud Platform, and yet would be subject to the limitations and problems of the Cloud Platform.

The problem is more prevalent as one moves up the Cloud stack. Companies that offer software as a service (SaaS) may have built their application within a particular Cloud Platform (examples can be found here, here, here, here and here). The Cloud User again would typically be dealing solely with the SaaS provider despite the fact that the Cloud User’s data is actually being stored and processed (in part or whole) by the Cloud Platform (at the PaaS or IaaS layer). In fact, it is possible that a particular Saas may actually serve its application on multiple Cloud Platforms. Those Cloud Platforms again are one step removed from the Cloud User and each may pose different legal risks. For example one Cloud Platform may have servers across the globe thereby potentially exposing a Cloud User to multiple privacy laws in various jurisdictions, while another may be purely domestic (thereby limiting the jurisdictions to which it the Cloud User may be exposed). In fact, there may be significant economic incentives for SaaS providers to switch between Cloud Platforms that are more efficient or less expensive (thereby improving the SaaS profit margin).

To make the situation more complex, it is also possible for a particular SaaS to use more than one Cloud Platform for an individual Cloud User client. In these cases, data processing might alternate between multiple Cloud Platforms (either because it provides for better efficiencies or perhaps a particular Cloud Platform provides the SaaS with a better price/profit margin). Again, in the legal context this can be problematic. If a SaaS decides to move processing to a Cloud Platform with weak security for example, it could significantly increase the liability risk of a Cloud User if the platform suffers a security breach. It would be very difficult to perform adequate “due diligence” where data is constantly shifting between multiple Cloud Platforms.

Cloud Service Aggregators

Unfortunately, this may be just the tip of the iceberg. In the foregoing example the Cloud User was at least dealing with a single Cloud SaaS provider on the front end. This would not be the case when dealing with Cloud service aggregators. Aggregators essentially bundle (and possibly integrate) multiple SaaS services into a “single” service (examples of aggregation models are here and here). For example, one could envision an aggregator bundling multiple Cloud SaaS offerings for use by travel agents (you can search for examples of SaaS providers serving industry verticals here). The bundle might include a customer relationship management application, a booking and reservations application, a credit card processing application, a billing platform, an international time zone translator application and an electronic signature/e-commerce application. To the Cloud User this bundle would appear to be a single seamless consolidated application. 

The reality is that each of the applications may be operated or created by separate SaaS providers. It is also possible that each of these SaaS providers might serve their application on a different Cloud Platform. There may be variations in each application in terms of reliability and security. Moreover, as discussed above each SaaS provider might be using multiple Cloud Platform’s and that use may not remain static (e.g. it’s a moving target). While aggregation models appear to be just gaining traction they could become more prominent going forward, and legal and security/privacy impacts of these models need to be carefully scrutinized.

The Legal Conundrum

The scenario described above poses significant legal challenges for Cloud Users’ transactional and compliance counsel (as well as security and privacy professionals). Due diligence and contracting are potentially much more difficult when the Cloud is involved.

In some cases the Cloud User may be two or three levels removed from the organizations actually processing and storing the Cloud User’s data.   For example, without a direct relationship with the lowest level Cloud Providers, organizations will not be able to directly analyze compliance issues around privacy and security compliance and reasonableness. As such Cloud Users will have to somehow confirm that the direct party they are dealing with engaged in proper due diligence. It almost becomes a meta analysis: due diligence might involve a Cloud User analyzing whether a Cloud Provider’s due diligence process itself was adequate. This would likely include receiving any reports or other types of analysis performed by the higher and lower level Cloud Providers.  As discussed below it should also include a review of the contracts the higher layer Cloud Provider has with the level below it. 

Of course it more than two levels are involved or there are multiple service providers or Cloud Platforms involved on a particular level, one must have confidence that each of the players also performed adequate due diligence on the providers it utilizes, and so on. So in essence, the Cloud User would be seeking to somehow validate that the Cloud Provider performed adequate due diligence of the due diligence process of the Cloud providers in the level immediately below it. In essence, the Cloud User would want to see a “Chain of Due Diligence.”   This requires that the providers on each level of the chain think ahead and anticipate the needs of the Cloud provider or Cloud User in the layer immediately above it.

Another example to illustrate the point involves incident response contract terms. What happens when the Cloud transaction involves multiple layers and the lower layer suffers a data security breach exposing the PII of the Cloud User’s data? What happens when the Cloud User needs to implement a litigation hold to preserve data where the data resides in the lowest layer of the Cloud?

In a typical direct outsourcing relationship, the outsourcer and its client would build processes in to address these issues and the contract would provide for particular rights and remedies. While similar contractual rights and obligations may be built into a Cloud transaction, it is not clear how useful they would be when multiple layers are involved. For example, if a SaaS built on a Cloud Platform has itself failed to obtain certain rights and abilities to forensically analyze and preserve data processed in the Cloud Platform, the Cloud User may not be able to adequately build defenses in a security breach context or implement an effective litigation hold (regardless of what the contract between the SaaS and Cloud User provides).

A final example: data retention and destruction policies. What if the SaaS provider is working on a Cloud Platform that creates residual copies of data that the Cloud User has a legal obligation to delete? What if the SaaS provider works with a Cloud Platform that does not have the technology or capability to properly wipe data? Even if the Cloud Platform has these capabilities, what if the SaaS provider has not negotiated for the right to obtain these services? Again, to make this work it is incumbent on the SaaS provider to anticipate the end Cloud User’s needs and to only work with Cloud Platforms (or other Cloud providers) that have the capability (and willingness) to meet those needs.

Conclusion

We are very much at the start of the Cloud computing phenomenon, and luckily we have an opportunity to proactive identify and attack these issues now. However, it appears that Cloud is gaining significant momentum and time is running short to address these matters.  While the ultimate “solutions” will take time to develop, legal counsel (and the legal community as a whole) should begin developing strategies and approaches for handling Cloud transactions.

A key factor (and crucial first step) in addressing Cloud legal risk for a particular transaction is understanding the relationships of the Cloud. Legal counsel (with a huge assist from IT and security) should consider taking steps to achieve this understanding and limit risk, including without limitation: 

• Insist on and acheive transparency. Don’t allow the Cloud to be a black-box storm cloud. Identify the Cloud players involved in a transaction, identify where they process the Cloud User’s data, map the data flow between Cloud players and determine whether the Cloud players are static or dynamic (e.g. can/will the Cloud players change in the middle of the contract). Do this early so the organization does not need to play catch-up.

• Develop due diligence strategies and procedures, and follow and document them. Primary Cloud relationships should be directly scrutinized. Moreover, the due diligence processes of Cloud providers relying on lower layer Cloud providers should be analyzed to determine if they are adequate. Any validations (e.g compliance with standards such as ISO 270001 or SAS 70s II) or relevant reports from the various players should be obtained. The capabilities, limitations and processes of lower layer Cloud providers should be explored to ensure that they can satisfy the Cloud User’s legal obligations and do not pose additional, unanticipated legal risk or obligations.

• Confirm that Cloud providers have contractual rights to do what you need them to do. Contractually requiring an Cloud aggregator or SaaS provider to retain data, or obtaining the right to audit the security protecting the Cloud User’s data, is meaningless if the aggregator or SaaS itself does not have such rights with respect to lower layer Cloud providers. Cloud Users do not want to find this out when they have a need to exercise their contract rights (e.g. when a regulatory action, privacy breach of lawsuit happens). As such, it is important to analyze the contracts a higher level Cloud provider has with the Cloud providers it relies on to make sure the necessary rights flow through the contract chain.

• Think Way Ahead – Contractual Requirements Should be Part of the Request for Proposal Phase. Obviously performing a proper due diligence can be very time consuming, especially when multiple layers of Cloud providers are involved. It is much more difficult to achieve due diligence when the Cloud transaction has moved forward significantly (e.g. the competitors have been told they are no longer being considered and negotiations on key terms, like price, have occurred). The time to address these issues is in the RFP process. Organizations should plan ahead and identify the criteria necessary for the company and have Cloud providers confirm that they meet the criteria in their response to a RFP. At this point in time, I recommend that RFPs actually identify legal contract terms (e.g. indemnification, exceptions to limits of liability and consequential damage disclaimers) that Cloud vendors must agree to in order to get the business. Not only does this save time, but it also creates a competitive incentive for Cloud providers to take on more risk (so that they can win the business). 

What is Cloud Computing?

How about a picture to start off:

The National Institute of Standards and Technology (NIST) has provided a definition of cloud computing that is helpful, but not really in plain English.  Moreover, it does not really help to illuminate the legal aspects of cloud computing. So here is my attempt.

From a user's perspective, when utilizing cloud computing, rather than data processing and storage occurring on an individual's laptop or desktop computer (or a company's internal network), it happens on computing platforms run by third parties (such as Google, Yahoo, Amazon, etc). Services that may be available through those cloud platforms include data storage (e.g., infrastructure as a service (IaaS)), application development/deployment  (platform as a service (PaaS) and software hosting (e.g., software as a service (SaaS)). So rather than store data on an organization's own computer network, if purchasing IaaS, the data is stored on servers "in the cloud" and available on demand by the organization. Rather than installing and maintaining data/software on a network or desktop computer, the data/application is hosted on computers in the cloud and available on demand.

This can result in cost savings because companies using cloud services need not purchase their own infrastructure or software, need not hire people to maintain it, and need not regularly upgrade when necessary.  In addition, cloud computing is highly and cheaply scalable.  So rather than maintaining an over-capacity of computing power (e.g. extra servers only used for the holiday e-commerce rush) companies can maintain variable capacity levels to suit their immediate needs using the cloud.  Moreover, utilizing the cloud will allow companies to take advantage of the best and latest technology since they will not have to disassemble and rebuild their entire IT infrastructure in order to upgrade.  For more information on some of the technical aspects of cloud computing, please check out this white paper put out by Sun Microsystems.

That is all nice, and fairly understandable, but what IS the cloud? Right. Some analogies are in order. Think of airlines and how they sell seats. Sometimes seats are still available for a flight as the departure date gets closer and closer. From the airline's point of view it is better to sell those seats for a lower price then to let the plane take off with empty seats. As long as can sell the seat for a price that exceeds the cost of taking a passenger. Bring this same rationale to the e-commerce context. Amazon.com has huge server farms that can handle millions of transactions. During the 3 month holiday period its servers and processing abilities may be taxed to their limits because of high online sales volumes. Then of course, February rolls around and all those servers that hummed during the holiday season suddenly lay dormant. Yet Amazon still needs to maintain them so it can be ready for the next holiday rush. What to do? Rather than let that processing capacity go unused, why not sell it to third parties?  Allow an application service provider to host its application on Amazon's computers for a price. Allow an organization to store and process data on Amazon's servers.  In fact, since any additional funds received (above maintenance costs) are "gravy" perhaps Amazon could charge a lower price than other companies that provide capacity. This rationale can serve as a building block for companies to get into cloud computing.

The second rationale/building block is economies of scale. Going beyond the Amazon rationale of attempting to sell excess capacity that it had to have anyway, savvy IT companies began to realize that they could sell processing capacity as a business. In fact, computing processing prices have continued to drop more or less as predicted by Gordon Bell's corollary to Moore's Law. Beyond that, companies like Google have begun to realize that if they build massive server farms they can bring down their per unit of price for processing power even further. Moreover, with highly evolved technologies they realized they could create additional processing efficiencies and bring down the per unit price of processing even further. Based on these economies of scale, cloud platforms realized they could provide processing capabilities much cheaper than companies that did it all "in house."

Terrific, so how is this any different than a typical outsourcing relationship?  Why is this a Cloud? One of the key differences between a traditional outsourcing relationship and cloud computing is where the data resides or is processed.  For example, in the traditional outsourcing situation, a company looking to offload some of its data storage would create a dedicated data center and then sell the storage capacity to its clients.  The data center might be in another country, but for the most part the client knew where its data was going and where it would be stored and processed.

Enter the cloud.  In a cloud environment, geography can lose all meaning.  Cloud platforms may not be able to tell "where" data is at any given point in time.  Data may be dispersed across and stored in multiple data centers all over the world.  In fact, use of a cloud platform can result in multiple copies of data being stored in different locations.  This is true even for a "private cloud" that is essentially run by a single entity.  What this also means is that data in the cloud is often transferred across multiple borders, which (as discussed below) can have significant legal implications.

It gets more complicated when you begin talking about the "public cloud" or "hybrid cloud" and interactions between cloud providers.  In some public cloud set ups, the players in the cloud are essentially trading processing and storage capacity.  So if Google has excess capacity at a given point and time, and Amazon or Amazon's clients need more capacity than Amazon can provide, it can buy some capacity from Google.  Some refer to this as "surge computing." The analogy here is electricity companies and providers.  In warmer climates during peak electricity demand times, the local power company may not be able to generate enough electricity to meet increased demand, and will have to purchase it from other companies who are not at full capacity.  Under the cloud arrangement, data is like electricity, essentially fungible and able to be moved instantaneously to available servers and computation resources.  In fact, cloud computing providers will begin charging for the cloud the same way electricity is charged:  based on units of use (in this case computing cycles).  So in the cloud, while the data may have started out on an Amazon server in the European Union, when handed off to Google it may be processed in the United States, China or some other country where Google has servers (in fact countries like China and India are very keen to get into this business since they think they can provide these services for even cheaper).  Moreover, the parts of the data may be copied and sent for processing to other participants in the cloud.  To the Amazon user all of this movement of data and processing across multiple borders involving multiple entities and even multiple copies of data is invisible.  The Amazon user simply gets back the answer it expected when it began the processing transaction.

What are the legal issues?

Transborder Data Flow Triggering Legal Obligations in Multiple Jurisdictions. This sharing and transfer of data within the cloud, the inability for anybody to easily say where the data is or has been, is the key problem that creates legal issues.  An obvious problem is transborder data flow.  For example under the EU Data Protection Directive, unless they take certain steps, organizations are prohibited from transferring personal information to countries that do not provide the same level of protection with respect to personal information of EU residents (the United States is one such country).  A company that does its processing in the cloud may be violating EU law if data goes to servers outside of the EU to prohibited countries.  Unfortunately, contracts may not be too helpful because cloud providers will not be in any position to make any contractual promises to their clients because in many cases they cannot say which countries data will be transferred to or from.  So how can companies seeking the efficiency and cost savings of the cloud utilize it if, by its very nature, it leads to potential legal compliance nightmares?

"Reasonable Security" Under the Law. Then there is the issue of "reasonable security" in the cloud computing context, and potential liability arising out of security breaches in the cloud.  Generally speaking if a company outsources the handling of personal information to another company they may have some responsibility to make sure the outsourcer has some level of reasonable security to protect personal and confidential information.  What happens when the could is utilized? Service providers using the cloud platform essentially rely on the security of each of the cloud participants receiving personal information.  That could be name brand companies like Google who are likely to have some level of adequate security, but it could also be lesser players trying to engage in business as cheaply as possible and not implementing rigorous controls.  The bottom line again is that the organization seeking to do business in the cloud has no way to even perform a due diligence of "the cloud" to ensure that adequate security is in place.  Moreover, cloud companies and service providers that contract directly with such companies are not likely to make any contractual promises around security since they ultimately don't control it (or even know how good or bad it is within the cloud).  Ultimately, the legal question is, what liability does a company face when there has been a security breach in the cloud that has resulted in the theft or harm of valuable or protected data?

Electronic evidence/e-discovery. Utilizing the cloud can be problematic in the litigation context.  First off, when litigation ensues and a litigation hold is initiated, the organization will have to deal with a third party cloud provider in order to get at the information relevant to the litigation.  It may not be easy for that provider to actually preserve the data that is needed for several reasons.  For example, an organization may be using a third party software provider that itself utilizes the a cloud platform.  The data subject to the litigation hold therefore may actually reside in the cloud and may not be readily accessible/preserved by the software provider.  This could complicate gathering electronic evidence and responding to e-Discovery requests.  Moreover, it could lead to spoliation of evidence.  In addition, considering that multiple copies of data may be created, stored, recompiled, dispersed, reassembled and reused, the idea of what constitutes a "record" or a "document" for evidentiary purposes may be difficult to grapple with in the cloud.

What can lawyers do to address these issues?

Ultimately this is the big question.  Can the law wrap its head around cloud computing (when frankly, the cloud computing industry itself is having difficulty defining key components of the business)?  The first area to explore are contractual arrangements.  Lawyers have been involved in outsourcing transactions for sometime, and have been able to address issues of relative risk between the parties.  However, contracting may be much more difficult in the cloud environment because the players may not be in a position to make certain promises, and additional duties/obligations may destroy the cheap pricing model for cloud computing.  In part two of this series, we dive more deeply into the legal issues around cloud computing and the necessary involvement of lawyers in this context with respect to contractual arrangements.