The Breach Notification Obligations in the Data Accountability and Trust Act
The Information Law Group has been following various Federal data security bills as they wind their way through the House and Senate. In December 2009, the Information Law Group commented on the passage of the Data Accountability and Trust Act ("DATA") by the House. I was recently asked by Data Protection Law and Policy (an excellent publication out of the UK focusing on data security and privacy issues) to take a closer look at the data breach obligations of the current version of DATA. The end result was my article entitled: "Potential changes to the US breach notice risk landscape".
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.
Are We Living in a Post-Disclosure, Opt-In World?
Today's New York Times Media Decoder Blog features an "on-the-record" discussion with Federal Trade Commission chairman Jon Leibowitz and Bureau of Consumer Protection chief David Vladeck. The question presented: "Has Internet Gone Beyond Privacy Policies?" The FTC (and Congress, for that matter) continue to signal that change may be imminent in the world of online privacy policies and traditional notions of opt-out consent.
The dilemma remains - if consumers don't want to read privacy policies, what would constitute true notice and consent? And, in the Web 2.0 world with consumers' insatiable appetite for on-demand, customized and interactive content, how can that process be handled in a manner that is both meaningful and consumer-friendly? What do consumers really want? And are their expectations regarding privacy simply inconsistent with the modern realities of social networking? Just yesterday, the blogosphere was abuzz with news of the Facebook CEO's comments at the Crunchies Awards that "[p]eople have really gotten comfortable sharing more information and different kinds but more openly and with more people."
At the end of the day, the real question (and answer) may have more to do with what constitutes "personal information," what consumers "reasonably" expect in today's world, and whether the sharing and use of certain kinds of information should be regulated.
In our current legal structure, even though such information flows around the world at breakneck speed, the definition of personal information ultimately depends on where you reside - and that, in turn, has grown out of social and cultural expectations. In the United States this has traditionally meant information that can be used to identify and victimize you (i.e., identity theft) - Social Security number, financial account number, and now, to a growing extent, medical information - although, in some new state statutes, the definition is much more broad. In Europe, the answer, for cultural and historical reasons, continues to be much more expansive, encompassing just about anything that can identify an individual.
So when an individual shares information on Facebook about his or her favorite music, or holiday plans, or the color of a piece of clothing, does that constitute "personal information"? What are consumers' reasonable expectations about how that information, if disclosed publicly -- or not so publicly (e.g., to one's "friends") -- should be used? And should the government regulate the sharing and use of such information by data brokers, social networks, cloud computing vendors, and advertisers?
Last year, the FTC introduced self-regulatory principles for behavioral advertising, but issued a warning that advertisers had one last chance before the FTC would take further steps to regulate. Has that time come? Mr. Vladeck told the New York Times today that the FTC will issue a report in June or July. Chairman Leibowitz said:
I have a sense, and it’s still amorphous, that we might head toward opt-in.
What would such opt-in look like and how would it operate? Is any opt-in solution manageable in the online world? Can any proposed model keep up with rapid changes in technology and consumer expectations? And will this focus on online privacy issues affect and/or eclipse the progress of the many pending federal data security and breach notification bills?
We shall see.
Compliance as a Service (CaaS): The Enabler Role of Legal, Security and Privacy Professionals
Cloud computing promises incredible benefits for companies looking for inexpensive and scalable computing solutions without the need to do it all themselves (or the costs or personnel). However, as foreshadowed in the InfoLawGroup’s “Legal Implications of Cloud Computing” series (see Part One, Part Two and Part Three) data security, privacy and legal compliance issues are beginning to cause great concern. Stories like this highlight these concerns. High profile information security snafus (fairly or unfairly) have also stoked the fire: Rackspace power outage, Amazon denial of service attack, and the Sidekick Data Loss. Data leakage is maybe problematic as well based on Cloud architecture. In fact, the InfoLawGroup has encountered some companies that are taking a pass on cloud computing (“v. 1.0”) because of regulatory, privacy and security concerns. Do these compliance concerns threaten the Cloud computing model or potentially reduce the cost benefits it promises?
The answer to this question is not clear at this early stage. However, what is becoming clearer is that attorneys, privacy experts and security professionals will increasingly (hopefully) become part of the solution. On one hand, this group of professionals act as organizational gatekeepers when it comes to implementing new IT arrangements such as Cloud. To the dismay of IT managers and business interests, they may have to say “no” to certain Cloud transactions. On the other hand this group will increasingly act as enablers to Cloud vendors by helping them understand their clients’ legal, security and privacy concerns, and providing them with the ability to design their Cloud and services in a manner that addresses those concerns. This activity will take place well before the transaction phase, and its purpose is to create a Cloud that moves the gatekeepers away from “no.” This post explores the enabling role that these professionals will likely play in the coming months and years.
Understanding the End Client/Users Applicable Compliance Issues
The adoption of Cloud computing faces significant potential push-back from legal, privacy and data security stakeholders within an organization. For Cloud to be accepted by certain organizations and industry segments the Cloud solution must address legal, data security and privacy concerns. In essence, by baking compliance into the Cloud, service providers are providing “compliance as a service” (CaaS).
It is important for Cloud service providers to be proactive in this regard. Cloud providers that take the time to understand their clients’ needs ahead of time (as well as the needs of their clients’ clients or users) may gain a competitive advantage against “generic clouds.” If these Cloud providers can implement an architecture that addresses specific client needs and/or provides clients with tools or mechanisms to address these needs, they should rise to the top. Of course, price will also remain a major (the major) factor in a purchase decision. The challenge will be balance: “customizing” Clouds or building in additional features costs money, if these costs materially overwhelm the promised cost savings or functionality of the Cloud then it will not be a viable business opportunity. However, if providers don’t adequately address compliance issues, Cloud services may not be implemented in the first instance. Cloud providers must thread this needle.
A key activity for Cloud providers will be understanding the regulatory, privacy and compliance environments of their clients and end users, and providing Clouds with the infrastructure and tools to meet those needs. Lawyers, security pros and privacy vendors can help Cloud providers (and will be necessary to) achieve this. The legal, privacy and security concerns may vary depending on the industry, the specific activities of the organization, the data being processed and the regulatory environments that impact the company. While there may be commonalities and overlap between different types of organizations, the Cloud services will still have to address the differences that may exist. Ultimately, this may lead to “vertical clouds”: Cloud providers specializing in certain industry verticals that may have different needs or concerns (e.g. banking, healthcare, retail, etc). In fact, this is already beginning to happen (see. e.g. Legal Cloud, FedCloud, athenahealth, bankserv and Rackspace PCI Compliant Cloud).
Creating Transparency
Once the specific legal, security and privacy concerns of clients are understood, Cloud providers will have to go one step further and build transparency into their process to enable potential clients to efficiently perform their due diligence so they can enter into, draft and negotiate Cloud agreements. Again, this is where legal can serve in an enabling role. By understanding the end-client’s compliance issues, cloud providers can make it easier and more transparent for clients to get the information they need to have confidence that their concerns have been addressed by the Cloud provider. Vendor lawyers helping with the design of the Cloud will have to anticipate where transparency is needed, how to most efficiently achieve that transparency, and what information to disclose to clients to smooth through the due diligence and contract negotiation process. Examples of areas where more transparency will likely be needed include:
- Relationships in the Cloud (Who is processing, transmitting and storing the Cloud purchaser’s information?)
- Security policies, procedures and controls (What controls are in place in the Cloud? What security standards [e.g. ISO 27001] have Cloud providers met? Do the controls meet the standard of reasonable security for the purchaser of Cloud services? Are the Cloud provider’s controls consistent with and compatible with the Cloud client's internal security framework? )
- Information handling practices and privacy (What can the Cloud provider do with personal information? What does it plan to do with personal information? Are the Cloud provider’s practices consistent with applicable privacy laws and the Cloud purchaser’s own privacy policy?)
- Geography (Where is the data being stored and processed? What jurisdiction’s laws may be triggered based on the location and cross-border transfer of personal information? Will export restrictions be violated? Will governmental bodies be able to obtain information that flows through their country?)
- Incident response, data preservation and electronic discovery (What procedures are in place to respond to an incident suffered by the Cloud provider? What obligations does the Cloud provider have when it suffers an incident? What information will the Cloud provider provide to the purchaser concerning a security incident? How will a Cloud provider coordinate with a Cloud purchaser in the event of an incident? How will a litigation hold be initiated with respect to data stored or processed by a Cloud provider? How can data be preserved when on the Cloud provider’s systems? What measures are in place to establish the integrity and authenticity of a “document” stored in the Cloud?)
- Service level agreements (Can the Cloud vendor meet SLAs that are appropriate to its clients’ needs? Is the Cloud provider using third party Cloud provider to provide services, and has the former secured contractual rights consistent with the applicable SLA?)
Standards in the Cloud
Going forward, especially where multiple tiers of Cloud providers are involved and/or data is being transferred between multiple Clouds, “universal” standards may develop that could create more transparency. Rather than an ad hoc approach requiring potential Cloud clients to individually investigate compliance aspects of each Cloud provider, it is possible that generally accepted privacy and security standards may develop. Similar to the PCI approach, Cloud providers would certify their compliance with such standards and provide Cloud clients with proof of certification. This could provide more transparency and make the due diligence process more efficient. Moreover, it provides a benefit to Cloud providers: they can certify to the standards once and simply provide proof rather than having each of their clients perform a separate due diligence procedure or assessment for every transaction.
Conclusion
The opportunity for lawyers, security professionals and privacy experts to play a positive role in enabling Cloud offerings is very exciting. Rather than playing their traditional spoiler roles, assuming Cloud providers think proactively, these professions can actually help the Cloud model mature. Moreover, in some cases, early adopters creating customized Clouds that provide “CaaS” may actually achieve a competitive advantage. The end result of CaaS, if done properly, are cost-effective Cloud services that provide all the benefits that have been touted, while reducing legal, privacy and security risk to an acceptable level.
Legal Implications of Cloud Computing -- Part Three (Relationships in the Cloud)
While there is much debate on the IT side as to whether Cloud computing is revolutionary, evolutionary or “more of the same” with a snazzy marketing label, in the legal context, Cloud computing does have a potential significant impact on legal risk. Part three of our ongoing Cloud legal series explores the relationships in the Cloud, and the potential legal implications and impacts suggested by them (if you would like, for context, you can read Part One [the Basics and Framing the Issues] and Part Two [Privacy and the Cloud] of the series.
In the legal world, some take the position that Cloud is no different than “outsourcing”. Unfortunately, making that comparison reveals a misunderstanding of the Cloud and its implications. It is sort of like saying that running is no different than running shoes. Like “running,” outsourcing is a general term describing an activity. In this case the activity involves organizations offloading certain business processes to third parties. Cloud computing (like “running shoes”) is a “new” method for leveraging existing technologies (and technological improvements that have occurred in the past 20 years) that can be used by outsourcers to provide their services more effectively and cheaply (as running shoes represents a technology that can be used to achieve the activity of running more efficiently). In other words, one can outsource utilizing a Cloud architecture provided by a third party, or by using a more traditional dedicated third party hosted technology solution. Both are different technologies or methods for achieving the same activity: outsourcing of business processes.
For lawyers analyzing outsourcing to the Cloud the question is whether the technology, operational aspects and various relationships of a given Cloud transaction create new legal issues or exacerbate known legal problems. To illuminate this question, this post explores the relationships that exist between organizations outsourcing in the Cloud (“Cloud Users”) and those providing services in the Cloud. Coincidentally (or maybe not so much) understanding these relationships is crucial for attorneys that need to address legal compliance risk and draft contracts to protect clients entering into the Cloud.
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).
Legal Implications of Cloud Computing -- Part Two (Privacy and the Cloud)
Last month we posted some basics on cloud computing designed to provide some context and identify the legal issues. What is the cloud? Why is everyone in the tech community talking about it? Why do we as lawyers even care? Dave provided a few things for our readers to think about -- privacy, security, e-discovery.
Now, let's dig a little deeper.
I am going to start with privacy and cross-border data transfers. Is there privacy in the cloud? What are the privacy laws to keep in mind? What are an organization's compliance obligations? As with so many issues in the privacy space, the answer begins with one key principle -- location, location, location. For those of you who prefer to listen, check out my recent webinar on International Regulatory Issues in the Cloud, or you can download the slides (PPTX). For everyone else, read on after the jump.
In the world of the cloud, location appears to be irrelevant. In the cloud, data effortlessly flows around the globe, ignoring boundaries and time zones, and magically appears on demand. Not surprisingly, the existing legal structure is far from prepared for the reality of existing technology. Every jurisdiction has its own laws, and its own compliance requirements. As that data instantaneously circumnavigates the globe, it may already be too late to comply with privacy laws in every jurisdiction.
You have undoubtedly heard that the laws of this country are like a patchwork quilt. They have popped up in certain sectors (financial, health) and with respect to certain types of sensitive information (e.g., kids' data). There are federal laws like Gramm-Leach-Bliley (applicable to financial institutions), HIPAA (applicable to health care providers and others dealing with health information and related entities), COPPA (applicable to data of children under 13 collected online), and the USA Patriot Act (may be applicable to foreign companies that work with cloud providers that allow data to reside in or flow through the US). In addition, we have a panoply of state laws requiring notification in the event of a breach of sensitive information and, in some cases, requiring the implementation of safeguards to protect sensitive information and/or secure disposal of such information.
By contrast, the European Union has a comprehensive privacy framework, the EU Data Protection Directive. Each member state has its own unique law implementing the Directive. The most notable thing about the EU Directive and member state laws for purposes of cloud computing is this -- in the absence of specific compliance mechanisms, the EU prohibits (yes, you read correctly, prohibits) the transfer of personal information of EU residents out of the EU to the US and the vast majority of countries around the world.
What does this mean for cloud computing? If you want to put data in the cloud that includes personal information of EU residents (and that might be something as simple as an email address or employment information), and the data will flow from the EU to almost anywhere in the world, you cannot simple throw the data in the cloud and hope for the best. You need to have, at a minimum, one or more of the following:
- International Safe Harbor Certification (which allows data transfer from the EU to the US, but not from the EU to other countries);
- model contracts (which allow data transfer from the EU to non-US countries, but do not always work well with multi-tiered vendor relationships); or
- Binding Corporate Rules (which are designed for a multinational company and therefore may not function well for cloud provider relationships).
So what, what does this tell us? All of the stakeholders within an organization should be part of the cloud discussion and due diligence -- IT, legal, information security, and all of the relevant business groups. And those stakeholders, in investigating a potential cloud relationship and in negotiating the terms of a relationship with a cloud provider, should consider and pose the following questions internally and to the vendor long before any contract is signed:
- What kind of data will be in the cloud?
- Where do the data subjects reside?
- Where will the data be stored?
- Where are the servers?
- Will the data be transferred to other locations and, if so, when and where?
- Can certain types of data be restricted to particular geographic areas?
- What is our compliance plan for cross-border data transfers?
Is that the end of the inquiry? No, it is just the tip of the iceberg, but it is a good start.
Legal Implications of Cloud Computing -- Part One (the Basics and Framing the Issues)
I had the pleasure of hearing an excellent presentation by Tanya Forsheit on the legal issues arising out of cloud computing during the ABA Information Security Committee's recent meeting (at the end of July) in Chicago. The presentation resulted in a spirited debate between several attorneys in the crowd. The conversation spilled over into happy hour and became even more interesting. The end result: my previous misunderstanding of cloud computing as "just outsourcing" was corrected, and now I have a better appreciation of what "the cloud" is and the legal issues cloud computing raises.
Bottom line: this is not your father's outsourcing relationship, and trying to protect clients with contracts may be very difficult or impossible unless the cloud computing community begins to build standards and processes to create trust. This post is not for my tech/security friends, it is for the attorneys out there, especially the general counsel and transactional attorneys who draft terms for tech contracts (e.g. outsourcing contracts, ASP contracts, software licenses, etc.). So tech friends, please cut me some slack as I completely mangle proper terminology in order to try to explain this in plain English (and of course if I get something wrong, shoot me a comment or email so I can correct -- we attorneys need you on this one).
One final note to the attorneys out there: there is going to be incredible financial pressure on organizations to take advantage of the pricing and efficiency of cloud computing and if attorneys fail to understand the issues ahead of time there is a serious risk of getting "bulldozed" into cloud computing arrangements without time or resources to address some serious legal issues that are implicated.
(P.S. Special thanks to Tanya Forsheit, John Tomaszewski, Karen Worstell and Peter McLaughlin for the insight and debate).
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.
Maine Privacy Law Applies Stringent Limits to Collection of Personal Information of Minors
A new Maine law gets serious about data collection and marketing to minors. The key portion of the law:
§ 9552. Unlawful collection and use of data from minors 1. Unlawful collection. It is unlawful for a person to knowingly collect or receive health-related information or personal information for marketing purposes from a minor without first obtaining verifiable parental consent of that minor's parent or legal guardian. 2. Unlawful use. A person may not sell, offer for sale or otherwise transfer to another person health-related information or personal information about a minor if that information: A. Was unlawfully collected pursuant to subsection 1; B. Individually identifies the minor; or C. Will be used in violation of section 9553. § 9553. Predatory marketing against minors prohibited A person may not use any health-related information or personal information regarding a minor for the purpose of marketing a product or service to that minor or promoting any course of action for the minor relating to a product. Use of information in violation of this section constitutes predatory marketing.
The law provides for a private right of action with possible recoveries up to $750 per violation in damages, as well as civil penalties:
3. Civil violation; penalty. Notwithstanding the penalty provisions of Title 5, section 209, each violation of this chapter constitutes a civil violation for which a fine may be assessed of: A. No less than $10,000 and no more than $20,000 for a first violation; and B. No less than $20,000 for a 2nd or subsequent violation
The law takes effect on September 12, 2009.
Johnson, et al. v Microsoft: Court Docs on Motion Ruling IP Address Does Not Equal PII
For those interested in digging deeper into the recent ruling in the UNITED STATES DISTRICT COURT FOR THE WESTERN DISTRICT OF WASHINGTON, SEATTLE DIVISION that IP addresses do not constitute "personally identifiable information," I have complied all of the relevant pleadings, motions, and response/reply/surreply briefs for your viewing pleasure....
- 2nd Amended Complaint
- Microsoft's Motion for Summary Judgment
- Plaintiffs' response to MSJ
- Microsoft's reply to plaintiffs' response
- Plaintiffs' surreply to Mircosoft's reply
- Court Order Granting MSJ (holding IP address is not PII)
For some more interesting reading on this issue, check out Truste's Amicus Brief in the Klimas case. How about some insightful comments in this blog to save me some reading time!
By the way, how to advise clients doing business in both the United States (where at least some courts dont consider IP as PII) and EU (where IP is considerd PII)?
EU Data Protection Directive May Apply to Certain "Users" of Social Networking Sites
It is a little vague, but according to this report it appears that simply using a social networking website may subject certain individuals and organizations to the requirements of the EU Data Protection Directive (e.g. notice, consent, etc.). Essentially, if your purpose for being a user is not "personal" then you could be subject to the EU Directive. Stated differently, if you use a social networking site to advance commercial, political or charitable goals your activities as a user may be regulated by the EU Directive.
Scroll down to section 3.1 ("Who is a Data Controller"). Which indicates:
A growing trend of SNS is the "shift from "Web 2.0 for fun" to Web 2.0 for productivity and services" where the activities of some SNS users may extend beyond a purely personal or household activity, for example when the SNS is used as a collaboration platform for an association or a company. If an SNS user acts on behalf of a company or association, or uses the SNS mainly as a platform to advance commercial, political or charitable goals, the exception does not apply. Here, the user assumes the full responsibilities of a data controller who is disclosing personal data to another data controller (SNS) and to third parties (other SNS users or potentially even other data controllers with access to the data). In these circumstances, the user needs the consent of the persons concerned or some other legitimate basis provided in the Data Protection Directive.
Typically, access to data (profile data, postings, stories.) contributed by a user is limited to self-selected contacts. In some cases however, users may acquire a high number of third party contacts, some of whom he may not actually know. A high number of contacts could be an indication that the household exception does not apply and therefore that the user would be considered a data controller.
It seems possible that for a business with a Facebook fan page, the simple act of making "personal information" available (e.g. a link to a person's profile that shows a birthday) might be subject to the act? If basic user "activities" in a social networking service require compliance with EU Data Protection Directive, how can these services work in Europe? What other activities might subject an individual or company users to EU privacy laws?
Prior to embarking on a full blown Web 2.0 business strategy, any company or individual user of a social networking site that will come into contact with European personal information should carefully analyze their activities surrounding and use of personal information and consider whether they are subject to the EU Directive.
FTC Releases Online Behavioral Advertising Principles
Online Behavioral Advertising Moving the Discussion Forward to Possible Self-Regulatory Principles
More to come after reviewing it. Happy hunting!
Stollenwerk v. Tri-West Health - Rise of the Phoenix?
Ninth Circuit Partially Reverses Motion for Summary Judgment on Issue of Damages in Data Breach Case
One of the biggest obstacles for consumer plaintiffs in personal data breach lawsuits has been establishing the "damages" element for a negligence claim. Several courts have dismissed such suits ruling that plaintiffs could not provide sufficient evidence that they suffered an injury as the result of a data breach. Ironically one of landmark cases against establishing damages, Stollenwerk v. Tri-West Health Care Alliance (D. Ariz. 2005), may give plaintiffs' attorneys some additional ammunition. The United States Court of Appeals for the Ninth Circuit ("Appellate Court") recently ruled on the Stollenwerk appeal and provided the plaintiffs with a partial victory on the issue of proving damages that could clarify the liability landscape for data breach lawsuits (see Stollenwerk v. Tri-West Health Care Alliance (9th Cir. November 20, 2007). The ruling may allow more data breach suits involving victims of actual identity theft to get in front of a jury and achieve more favorable settlements.
Stollenwerk Background & District Court's Ruling
In December 2002, Tri-West Healthcare Alliance ("Tri-West"), a contractor managing a large government health insurance program, suffered a burglary that resulted in the theft of computer hard drives containing the personal information of the program's members (mainly military personnel). Three individuals brought a class action lawsuit against Tri-West in the U.S. District Court of Arizona ("District Court") alleging numerous claims, including common law negligence. One of the plaintiffs (William Brandt - hereinafter "ID Theft Plaintiff") alleged that unknown individuals used his personal information after the burglary to open (or attempt to open) unauthorized credit accounts in his name (e.g. identity theft). The two other plaintiffs (Michael Stollenwerk and Andrea DeGatica - hereinafter "Credit Monitoring Plaintiffs"), while not alleging they suffered identity theft, alleged that they needed to purchase credit monitoring services and identity theft insurance to prevent potential future identity theft.
In its September 2005 opinion, the District Court dismissed all of the plaintiffs' claims on the grounds that they could not establish that they suffered any injury as a result of the Tri-West data breach. The Credit Monitoring Plaintiffs attempted to analogize financial credit monitoring expenses to medical monitoring expenses in "toxic tort" cases (e.g. asbestos lawsuits where otherwise healthy individuals exposed to asbestos paid doctors to monitor their health prior to any adverse affects manifesting). The District Court indicated that enhanced risk of future injury is generally insufficient to establish a negligence claim, but in the case of toxic tort lawsuits an exception was justified because of the importance of preserving public health. In addition, since the plaintiffs could not establish that the target of the burglary was their personal information (as opposed to the physical hard drives themselves), the court ruled that the Credit Monitoring Plaintiffs failed to provide evidence that such information was significantly exposed or that plaintiffs were at significantly increased risk of suffering identity fraud.
The District Court also dismissed the negligence claim of the ID Theft Plaintiff. Although the plaintiff suffered identity theft on several occasions six weeks after the burglary, the Court held that the circumstantial timing of the burglary and identity theft was insufficient evidence that the burglary was the cause of such theft.
The Appellate Court's Decision
In November 2007, the Appellate Court reversed the District Court's decision concerning the ID Theft Plaintiff, but upheld the lower court's ruling on the Credit Monitoring Plaintiffs.
The Credit Monitoring Plaintiffs
With respect to the Credit Monitoring Plaintiffs, the 9th Circuit agreed that the analogy to toxic tort cases was not justified because credit monitoring does not directly involve health and human safety. However, the court did not reject the analogy entirely, noting that:
"In both circumstances the individual may manifest more obvious injury, such as identity fraud or disease, after some period of time, and in neither instance is the later manifestation of patent injury guaranteed, although the certainty with which such a development may be anticipated may be greater for toxic torts."
The Appellate Court also noted that under the facts of this case, even if the toxic tort analogy were apt, the Credit Monitoring Plaintiffs had not established the requisite elements to support their claim, including: (1) significant exposure of sensitive personal information; (2) a significantly increased risk of identity fraud as a result of that exposure; and (3) the necessity and effectiveness of credit monitoring in detecting, treating, and/or preventing identity fraud. The Court held that the plaintiffs did not provide sufficient evidence that their personal data was targeted or accessed. Moreover, the Court indicated that the plaintiffs' expert failed to objectively quantify the reduction of risk that would result from credit monitoring.
The ID Theft Plaintiff
The Appellate Court's opinion was much more forgiving for the ID Theft Plaintiff. In this case, the ID Theft Plaintiff allegedly was the victim of identity theft on six occasions after the burglary of Tri-West's hard drives. The Court did not make a distinction between "attempts" to open accounts and successful account openings - the Court appeared to conclude that both constituted identity theft. Significantly, the Court's opinion appears to simply accept that "identity theft" constitutes an injury, and instead focused on whether the ID Theft Plaintiff established that the burglary was the proximate cause of the identity theft.
On the issue of causation, to survive a motion for summary judgment, the plaintiff needed provide evidence from which a reasonable jury could conclude that ID Theft Plaintiff's injuries were the result of the burglary rather than other causes. Direct or circumstantial evidence is permitted, but this plaintiff was only able to offer circumstantial evidence, including:
- Possession: the ID Theft Plaintiff provided Tri-West with his information;
- Type of Information: the personal information stored on the Tri-West hard drives is the type of information that can be used to open credit card accounts;
- Timing -- Identity Theft Incidents: the six alleged identity theft incidents all occurred after burglary, and the first began about six weeks after the burglary (the last happened about 3 - 4 months after the burglary);
- Timing - Prior Incidents: the plaintiff had never suffered identity theft prior to the burglary (despite having his wallet stolen five years earlier); and
- Limited Opportunities for Other Causes: the plaintiff testified that he had never transmitted his personal information over the Internet and that he shreds all mail in the form of credit card applications, approvals and pre-approvals.
The 9th Circuit ruled that this circumstantial evidence on the issue of causation was sufficient for purposes of summary judgment and reversed the District Court's grant of summary judgment to the Defendants.
Conclusion
The Stollenwerk decision is largely a mixed bag for both plaintiffs and defendants. The 9th Circuit's decision is good for defendants because it largely validates that the purchase of credit monitoring services or insurance to decrease the likelihood of potential future identity theft is not sufficient to establish damages for purposes of a negligence lawsuit. This ruling most likely decreases the risk of successful class action lawsuits involving massive numbers of plaintiffs whose personal information is exposed in a data breach. However, because its decision was based mainly on public policy grounds, and because it noted some similarities between toxic tort injuries and data breach injuries, the Court appeared to leave the door open a little for plaintiffs to make the toxic tort analogy in other jurisdictions.
The Court's ruling was favorable for plaintiffs that actually suffer identity theft after a data breach situation The Court was lenient in its acceptance of purely circumstantial evidence -- most of the evidence provided was very loosely tied to the actual burglary. As a result of this ruling, plaintiffs that were the victims of identity theft will have a better chance to get their case in front of a jury in the 9th. On the flip side, since it appears that most data breaches never actually result in identity theft (see GAO Report (June 2007)), plaintiffs' lawyers may find it difficult to establish large classes that make these suits financially attractive to pursue. In all, this decision and other cases dismissing breach data cases seem to indicate that successful and severe consumer litigation (e.g. large successful class action suits) is still elusive for the plaintiffs' bar Circuit, which increases both the likelihood of success in litigation and the leverage plaintiffs will have to force a settlement.
