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

Obligations Concerning Personal Information Collection and Transfer Outside of Canada

First, before diving into the FAQ on the breach notice provisions of Bill 54, let’s take a quick look an amendment in Bill 54 that addresses the use of service providers outside of Canada for purposes of collecting or transferring personal information. Bill 54 added the following provision to the Act:

13.1(1) Subject to the regulations, an organization that uses a service provider outside Canada to collect personal information about an individual for or on behalf of the organization with the consent of the individual must notify the individual in accordance with subsection (3).

(2) Subject to the regulations, an organization that, directly or indirectly, transfers to a service provider outside Canada personal information about an individual that was collected with the individual’s consent must notify the individual in accordance with subsection (3).

(3) An organization referred to in subsection (1) or (2) must, before or at the time of collecting or transferring the information, notify the individual in writing or orally of (a) the way in which the individual may obtain access to written information about the organization’s policies and practices with respect to service providers outside Canada, and (b) the name or position name or title of a person who is able to answer on behalf of the organization the individual’s questions about the collection, use, disclosure or storage of personal information by service providers outside Canada for or on behalf of the organization.

While this provision does not require an individual’s consent to use a service provider outside of Canada, it does require certain notice of certain information to the individual prior to collecting or transferring personal information to such service providers. This specific information referenced in the Act can probably be put into an organization’s privacy policy. However, for organizations that have existing  non-Canadian service provider relationships, a process must be put in place to provide notice to individuals. This provision may also have implications with respect to Cloud computing. Some organizations in Canada using the Cloud may not know whether personal information is being transferred outside of the United States. As such, these organizations may have to examine their existing service provider relationships, including identifying subcontractors outside of Canada that service providers may be using.

FAQ on the Personal Information Protection Act’s Breach Notice Obligations.

What breach notification obligations are set forth in Alberta’s breach notice law?

There are actually two potential notification obligations in Alberta’s breach notice law. The primary obligation requires organizations to provide notice to Alberta’s Information and Privacy Commissioner (the “Commissioner”):

34.1(1) An organization having personal information under its control must, without unreasonable delay, provide notice to the Commissioner of any incident involving the loss of or unauthorized access to or disclosure of the personal information where a reasonable person would consider that there exists a real risk of significant harm to an individual as a result of the loss or unauthorized access or disclosure.

(emphasis supplied). In addition, organizations that suffer a breach may also have to provide notice to the impacted individuals:

37.1(1) Where an organization suffers a loss of or unauthorized access to or disclosure of personal information that the organization is required to provide notice of under section 34.1, the Commissioner may require the organization to notify individuals to whom there is a real risk of significant harm as a result of the loss or unauthorized access or disclosure (a) in a form and manner prescribed by the regulations, and (b) within a time period determined by the Commissioner.

(emphasis supplied). Two points jump out based on these duties. First, it appears that any notice obligation for individuals applies only to those individuals as to whom there is a “real risk of significant harm.” So with respect to a particular breach, this may involve only a subset of those individuals whose personal information was subject to loss or unauthorized access. Second, even if a real risk of significant harm does exist, there is no automatic mandatory reporting obligation to the impacted individuals. Rather, there is only a reporting obligation if the Commissioner requires reporting. At the end of the day however, depending on the regulations and procedures created by the Commissioner, this notification obligation may effectively become “mandatory.” In fact, subsection 37.1(3) requires the Commissioner to establish an “expedited process” for determining whether to require notification where the harm to the individual is “obvious and immediate.”

Differences against U.S. State breach notice laws:

• Regulator Involvement. The obvious difference between Alberta and most U.S. breach notice laws is that the primary notification obligation is to the regulators. In the U.S. the breach notice laws require notification to the impacted individuals, and some also require concurrent notification to the state regulators (e.g. state attorneys general). In addition, the U.S. breach notice laws typically do not give the regulators discretion as to whether to require notice to individuals.

• Harm Threshold. Like some state breach notice laws, Alberta’s law has a “harm” threshold built into it. While no U.S. breach notice law uses the “real risk of significant harm” terminology, some states do require a material risk of harm,  a material compromise, a material risk of identity theft, or similar. While it is difficult to compare harm standards, and more research would be necessary to get a clearer picture, it appears that the real risk of significant harm threshold is relatively high. The term does not appear to be defined in the Act itself, but perhaps the Commissioner will get an opportunity to clarify its meaning as it develops regulations and processes for managing the notifications it receives.

What kind of information does the Alberta breach notice law apply to?

It applies to “personal information”, which is defined as follows:

“personal information” means information about an identifiable individual.

Differences against U.S. State breach notice laws:

• No residency requirement.  Unlike U.S. state laws, the residency of the individual does not matter. Personal information could relate to any individual whether a resident of Alberta or not. This could serve to limit the Commissioner’s jurisdiction to some degree. In the U.S. states, a state breach notice law could apply to a company with little to no “presence” in that state simply if they held personal information of a resident. Under Alberta’s law, there may need to be more traditional “doing business” jurisdiction for this law to apply. However, this jurisdictional issue is outside of the scope of this article (Michael Power, please weigh in if you would like/have the time).

• Less precise definition than U.S. breach notice laws.  In U.S. breach notice laws the definition of “personal information” or “personally identifiable information” is more precise: typically requiring first name/first initial and last name, in combination with some kind of a account number. The concept of “identifiable individual” is arguably a broader concept than PI or PII in the United States, and therefore there may be instances of reporting required under Alberta’s law that may not be required under U.S. law (on the argument that PI or PII was not at issue as defined under the U.S. breach notice law[s]).

How is a “security breach” defined that would trigger Alberta's breach notice law?

There is no formal definition for “security breach” or “breach of the security of the system.” Nonetheless, a security breach trigger is described in Alberta law as follows: “any incident involving the loss of or unauthorized access to or disclosure of the personal information.” However, a breach by itself does not trigger a reporting obligation unless “there [also] exists a real risk of significant harm to an individual.”

Differences against U.S. State breach notice laws:

• Actual Loss/Unauthorized Access/Disclosure. Under Alberta's law it appears that there must be an actual loss or unauthorized access to or disclosure of the personal information to activate the trigger. Many U.S. breach notice laws are triggered if there is a reasonable belief or suspicion of unauthorized access or acquisition. As anybody knows who has handled a breach, it is not entirely clear in some cases whether actual unauthorized access occurred (often there is circumstantial or tangential evidence of unauthorized access). If construed in this matter, the Alberta law may result in some breaches not being reported.

• Alberta's Loss Trigger.  Second, the Alberta law includes “loss” as a trigger. The classic example is a lost laptop. Under many/most U.S. statutes, loss of personal information is not a explicit trigger. Depending on the circumstances, under U.S. state breach notice laws, some organizations may argue that a lost laptop with personal information does not amount to a reasonable belief of unauthorized access. Alberta’s law takes that argument away (however, the harm threshold must still be met).

What is the risk of harm threshold under Alberta’s breach notice law, and how does it operate in terms of the individuals who must be notified?

As discussed above the risk of harm threshold for notification is a “real risk of significant harm.” This harm threshold appears to apply in two different ways under the Alberta law. Under section 34.1 if there is a security breach where a reasonable person would consider that there exists a real risk of significant harm to an individual, the organization must report to the Commissioner. Notice of the entire security incident to the Commissioner is required if a real risk of significant harm exists for a single individual impacted by the incident.

However, under section 37.1, notification is required only to those individuals to whom there is a real risk of significant harm as a result of the loss or unauthorized access or disclosure. This standard takes out the “reasonable person” test and appears to require actual an actual risk of harm. Moreover, notice is only required to those individuals as to whom a real risk of harm exists. So, if the organization reports a breach involving 1 million people and one may have reasonable suffered significant harm, it must report the entire breach to the Commissioner. However, it appears that the only individual that the organization must provide notice to is the individual as to whom an actual real risk of significant harm exists.

What notification obligations does an organization have if its service provider suffers a breach involving personal information?

The Alberta law applies to an organization that has personal information “under its control.” On its face, this control standard appears ambiguous when a service provider breach has occurred. If personal information is stored offsite on a service provider’s computer, but is accessible to an organization, is it under the “control” of the organization or the service provider (or both)? Unlike U.S. breach notice laws, Alberta’s law does not distinguish between the “owner” or “licensee” of personal information and the “service provider” (whose typical breach notice obligation under U.S. laws is to report the breach to the owner/licensee). This of course begs the next question.

What notification obligations does a service provider have if it suffers a breach involving personal information of its customers?

This is the flip-side of the question posed above. Service providers may be hard pressed to argue that they were not in “control” of personal information provided by their customers, and therefore may have an independent duty to notify under the Commissioner and possibly the impacted data subjects. Again, this is less clear than U.S. laws that only require service providers to report the breaches to their customers (a.k.a data owners/licensees;  although some have argued that ambiguity exists as to the meaning of data "licensee" under U.S. laws).

Under Alberta’s breach notice law, do the notification obligations apply to personal information that is encrypted?

Unlike most U.S. laws there is no specific reference to encryption under Alberta’s breach notice law, and therefore no explicit encryption safe harbor. However, practically speaking, the definitions and triggers in Alberta’s law may preclude notice obligations with respect to encrypted personal information. For example, organizations may argue that, with respect to encrypted personal information, a reasonable person would NOT consider that there exists a real risk of significant harm to an individual whose personal information was lost or subject to unauthorized access.

Conclusion

Alberta's breach notice provisions are very interesting, especially when compared and contrasted against the approach of U.S. states.  It will be even more interesting to see if Alberta's law becomes the model for other provinces, and whether it will have a similar impact on Canadian organizations as it did in the United States.
 

Security Incident Response Planning

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

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

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

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

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

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

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

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

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

Risk of Loss

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

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

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

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

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

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

Conclusion

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

It is possible that we will see more lawsuits by merchants against service providers, payment processors, and application/point-of-sale system providers in the coming months and years. Part of the reason is that the PCI regulatory system imposes a form of “strict liability” on merchants that suffer a security breach. Fines, penalties and the availability of recovery processes are contingent (in part) on whether or not a merchant was PCI-compliant at the time of the breach (see e.g. Visa’s ADCR). Thus, when a Qualified Incident Response Assessor ("QIRA") comes in after a credit card breach to do an audit one of its main tasks (if not its primary goal) is to ascertain whether the merchant was PCI-compliant. 

Lost in the shuffle sometimes, however, is the issue of “causation.” The question that is not being asked is whether or not PCI compliance would have prevented the breach, or whether the lack of PCI-compliance was the cause of the breach. In other words would PCI-compliance have made a difference. In some cases the answer is obvious. For example, if a merchant is holding onto sensitive authentication information, clearly PCI compliance (which requires the deletion of such data after a transaction) would have precluded a payment card breach. In other situations, however, the answer might not be as clear cut.

Moreover, even where a merchant is found not PCI compliant, the question still remains whether any other party was fully or partially responsible for the breach itself.   Was the merchant’s payment application the source of the breach? Was the merchant working with a service provider, gateway or processor that could have been the source of a virus or attack by a hacker? Unfortunately, with their focus on PCI compliance, a QIRA may not have cause to investigate further into these possibilities (and a separate forensic assessment by an independent forensic firm may be necessary). In fact, I have seen an audit report where the auditor literally indicated that it could not determine how malware got onto a merchant’s system or whether cardholder data ever left (and in the report decided to speculate that it may have been porn or file sharing sites).

Beyond the entities involved in storing, processing or transmitting payment cards, merchants may also begin to target companies assisting their efforts to achieve and validate compliance with PCI. Consultants that help merchants become PCI compliant or remediate PCI violations may be targets if they make a mistake. Moreover, as Savvis shows, qualified security assessors that make mistakes in their validation of PCI compliance are also potential defendants.

Despite sometimes having a variety potential targets to recover from, merchants still face obstacles to actual recovery post-security breach. The biggest obstacles are the contracts that merchants enter into with the entities mentioned above. In most cases these contracts contain terms that effectively limit the liability of these entities and make it very difficult to recover under any theory of recovery. 

So is there an answer for merchants to these contract clauses? Thinking ahead might make all the difference in this case. When entering into a contract with any of the various entities described above, at the Request for Proposal phase, merchants should make indemnification and other favorable contract terms (e.g. no limit of liability/disclaimer of consequential damages for security breaches) part of the bidding process. Merchants' propsective service providers, assessors and application providers should be forced to compete on the issue of taking responsibility when they are fully or partially at fault for a security breach or inaccurate/improper PCI validation.  Proper levels of cyber insurance should be in place to allow merchants to recover if there is a breach.   If merchants don’t take these steps early on and in a disciplined fashion they may find themselves holding the bag even in situations where others may have contributed to their security breach.

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.