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

In the case, Civ. (Tel Aviv) 1963-05-11 Malka v. Ava Financial, defendants moved for summary judgment against the plaintiff, user of their foreign exchange trading platform, on the basis of an English forum selection clause in a clickwrap contract. Plaintiff sued defendants for conflicts of interest and multiple violations of Israel’s financial trading regulations. Defendants, most of whom are Israeli residents, argued that the plaintiff entered into a contract with a British Virgin Islands company choosing English law and venue for any future litigation.

Plaintiff argued that the forum selection clause was “hidden” in an online contract whose terms he never read. In addition, he argued that such choice constitutes an “unfair term” in a contract of adhesion under the Standard Form Contract Act, 1982. Israeli Courts have broad powers to uphold, strike out, or amend unfair clauses in standard contracts (“blue pencil rule”). The Standard Form Contract Act enumerates a list of contractual provisions which are presumptively unfair, including unreasonable or unilateral forum selection (but not choice of law).

The court rejected the defendants’ reliance on the forum selection clause, effectively establishing Israeli jurisdiction over the case. An important factual holding is that plaintiff did not personally set up his online account on the defendants’ platform, but rather had it set up by an agent of the defendants. Consequently, plaintiff’s assertion of lack of knowledge of or consent to the forum selection clause held sway.

Regardless of the fact-specific holding, certain statements of the court are extremely important for non-Israeli companies entering into clickwrap or browsewrap agreements with Israeli customers. The court (Judge Ruth Ronen) stated that while "non est factum" arguments with respect to signed agreements must be interpreted restrictively, a party relying on a contract must produce a signed document evidencing the counterparty’s agreement. In an online setting, a party’s intent to enter into a contract can be established by showing that such party was informed of (i.e., read) the terms of the agreement and actively expressed his consent to be bound by them.

The court held that clickwrap agreements better evidence a consumer’s consent than browsewrap agreements. If clicking on a link is required to view the terms of the contract, such link must be featured prominently for consumers to see. (The court even states that in the online environment, viewing additional linked documents is easier than in the offline world).

The court held that a foreign forum selection clause is acceptable only where one of the parties to the agreement is non-Israeli (i.e., a contract between strictly Israeli parties should not point to a foreign forum). In this case, the court held (based on its factual holding above), that the plaintiff was not informed of and did not intend to agree to selection of a foreign forum. The court added that had the plaintiff agreed to such selection, defendants would still need to cross the hurdle of the Standard Contract Act; yet given the English choice of law clause, they would have been able to try to prove that under English law, a mechanism similar to Israel’s Standard Contract Act did not exist. Reading between the lines, it is evident that the court is readier to heed a foreign choice of law clause (the court assumes it would be enforceable in the present case) than a foreign forum selection provision.

This is an interesting case – another in a long line of jurisprudence, in Israel and abroad, discussing the enforceability of clickwrap contracts generally, and foreign choice of law and forum selection clauses in particular.

WP29 found that:

• With the help of geolocation technologies smart mobile devices can be tracked for purposes ranging from behavioral advertising to monitoring of children

• Because mobile devices are inextricably linked to their users, the travel patterns of the device provide a very intimate insight into the private life of the user, rendering the location data personal; specifically, "the combination of the unique MAC address and the calculated location of a WiFi access point should be treated as personal data."

• One of the main risks of location data processing is that the user is unaware that the device transmits the location data and to whom the information is provided

• There risk that the consent for certain applications to use location data is invalid because the information about the key elements of the processing is incomprehensible to the user, outdated or otherwise inadequate

• Because location data from smart mobile devices reveal intimate details about the private life of their users, the main applicable legitimate ground is prior informed consent

• Consent cannot be obtained through general terms and conditions; rather, consent must be specific for the different purposes that location data is collected, used or otherwise processed (e.g., profiling or behavioral targeting)

• If the purposes of the processing change in a material way, the data controller (i.e., the entity that determines the purposes and means of collecting, using or processing the data) must seek renewed specific consent of the individual

• By default, location services must be switched off

• An opt-out mechanism does not constitute an adequate mechanism to obtain informed user consent

• With respect to employees, employers may only adopt this technology when it is demonstrably necessary for a legitimate business purpose and the same purpose cannot be achieved with less intrusive means

• With respect to children, parents must judge whether the use of location data is justified in specific circumstances

• The consent should be limited in time; users should be asked for consent at least once a year

• Users must be able to withdraw their consent in a very easy way, without any negative consequences for the use of their device

• With regard to the mapping of WiFi access points, companies can have a legitimate interest in the necessary collection and processing of the MAC addresses and calculated locations of WiFi access points for the specific purpose of offering geolocation services; the balance of interests between the rights of the data controller and the rights of the user requires an opportunity for the user to easily and permanently opt out from the database, without providing additional personal data

• Users must be provided with clear, comprehensive and understandable for a broad, non-technical audience notice of the collection, use or other processing of geolocation data; the notice must be permanently and easily accessible; the validity of the user's consent is inextricably linked to the quality of the information about the data collection

• Third parties, such as browsers and social networking sites, have a key role to fulfill when it comes to the visibility and quality of the information about the processing of geolocation data

• Users have the right to access their location data in a human-readable format and to rectify and erase the data; users also have the right to access, rectify and erase profiles compiled based on their geolocation data

• Providers of geolocation applications or services should implement retention policies which ensure that geolocation data or profiles derived from such data are deleted after a justified period of time

• If the developer of the device's operating system or a data controller of the geolocation infrastructure processes a unique number such as a MAC address or a UDID in relation to location data, the unique identification number may only be stored for a maximum period of 24 hours, for operational purposes

InfoLawGroup Says:

While the debate about mobile location data is in its infancy in the U.S. (see our blog post and Fox News interview), Europe has served up guidance that, it is fair to say, brings to life every nightmare of U.S. businesses working and innovating in this industry. It  is important to keep in mind that WP29 recommendations are not the law. As with any WP29 opinion, businesses need to monitor how the DPA will implement the guidance, if at all. I suspect that Apple and Google will be the first to face pressure from European data protection authorities to comply with the guidance. We will monitor how any enforcement action will play out. For now, U.S. business entering mobile location marketplace in Europe should strive to implement the opinion's requirements to the extent the requirements are feasible.

In this particular case, the court considered whether an employer may access employees' email messages and submit them as evidence in the course of court proceedings brought by the employee against the employer. Typically, an employer may wish to present evidence obtained from an employee's email account in an effort to dismiss the employee's claim of unlawful termination. However, the "fruit of the poisonous tree" evidence rule under Israel's Privacy Protection Act prohibits submission of evidence obtained through invasion of privacy.

Chief Judge Nili Arad delivered the National Labor Court's opinion on two appeals from District Labor Courts that reached inconsistent decisions regarding an employer's right to monitor employee emails. In its decisions, the court set out the following principles that will govern employee monitoring in Israel:

• An employer must establish a balanced policy for use of the corporate IT and email systems. The employer must bring the policy to the attention of its employees and must incorporate the policy into the employees' employment contracts.

• A clear line should be drawn in the application of monitoring policies between an email account allocated by the employer to an employee and an employee private email account, such as a web-based email account.

• An employer may allocate accounts to employees and designate them as (i) professional purposes accounts (permitting only business communications); (ii) dual purpose accounts (for both personal and business purposes); or (iii) personal accounts (to be used for personal communications only). 

• If an employer makes its employees aware of the company's email monitoring policy, the employer may monitor professional purpose accounts. However, if an employee uses his or her "professional" mailbox for personal email communications (even in violation of company policy), the employer may access the personal messages in that account only subject to the employee's explicit, informed and freely given consent, and only if the contents of such personal messages are unlawful or abusive.

• An employer may monitor and access personal messages in dual purpose and personal accounts only when: (i) there are unusual circumstances that justify access to the messages; (ii) the employer first uses less invasive tools that reveal the monitored employee's misconduct; (iii) the employee gives explicit, informed and freely given consent to the corporate monitoring policy and, specifically, to the monitoring of or access to his personal (not work related) messages; or (iv) the employee provides specific consent to each access by the employer to the contents of personal messages in a dual purpose account, or specific consent for any surveillance activity by the employer that includes access to a personal account, and to personal content in such account.

• An employer may not monitor or access an employee's private web-based email account, even if the employee uses workplace IT system to access the account and even if the employee consented to such access. An employee's private account may be accessed only subject to an appropriate court order (which courts in Israel rarely grant).

Applying these principles, the court granted the employees' motion to suppress the evidence in both cases because the court found that the employers obtained the evidence while unlawfully invading the privacy of their employees.

Action item:  Employers that have employees in Israel should review and, as appropriate, revise their employee monitoring policies to comply with the requirements set forth in the ruling. Special attention should be given to corporate monitoring policies, employment contracts, adequate consent processes and harmonizing corporate information security systems and policies with the new pro-privacy legal framework.

In Jerusalem, regulators and privacy advocates from around the world called for greater privacy protections. A few industry representatives who suggested that the industry was doing a good job protecting privacy seemed to be drowned out by regulators and privacy advocates, as well as other industry representatives who took a decidedly pro-consumer view of privacy protection, seeing it as a good business practice. Participants discussed boxing businesses that stray from certain principals of processing personal information in public shaming, investigations, privacy suits and enforcement actions. Aside from Facebook, businesses that are fueled by collecting, using and sharing personal information seemed significantly underrepresented in Jerusalem. These companies are critical players in the information economy to which speakers and panelists often referred, but their take on privacy remains largely unpopular with regulators and privacy advocates.

Seemingly on the other end of the privacy continuum was ad:tech at the Javitz Center in New York City. For many New York lawyers visiting the lower level of the Javitz Center must be an eerie experience because this is where thousands of us took the bar exam. Fortunately, this time the basement was not filled with endless rows of beige tables and matching folding plastic chairs. Instead, businesses from around the world working in interactive advertising and technology field were exhibiting their ability to track users’ online activities, build user profiles online and offline, combine personal information from multiple sources into sophisticated marketing profiles, and help advertisers target individuals ever more precisely. Many of the companies have built detailed databases containing the profiles of tens or hundreds of millions of consumers. Walking the isles of the exposition, I tried to imagine what the Jerusalem conference participants would think of ad:tech. My gut feeling was that they would think they were in a parallel universe. Here, far from walking on eggshells around privacy issues, talented and enthusiastic entrepreneurs (some of whom I met in person), arguably had no qualms about collecting and using personal information to create business value. Looking at the vibrant sea of colors and people that filled the space, and experiencing the excitement of business leaders who told me about their companies, it was hard to argue with the innovation and enormous value these businesses bring to the economy. It would be unfair to say that ad: tech exhibitors had no concern about privacy of the individuals whose personal information drives their businesses. But to what extent these businesses are focused on privacy concerns such as those raised in Jerusalem, is an open question.

There clearly is a significant divide between how privacy was seen in Jerusalem and New York. I do not know if regulators, privacy advocates and the industry can easily bridge this divide on their own. I believe, however, that privacy lawyers can contribute significantly to building a bridge between these somewhat parallel universes. Privacy lawyers can do this in an old-fashion way, by helping the various stakeholders understand each other better.

Today, U.S. privacy lawyers are facing a complex legal landscape. While there are well-established privacy laws (for example, GLB, FCRA, HIPAA and state breach notification laws), overall, the privacy landscape is unstable and evolving, and combines many legal and non-legal challenges. A number of factors contribute to this complexity. For example, privacy is a hot topic that continuously garners publicity. Privacy advocacy groups and more recently journalists are on the lookout for privacy practices they deem unfair. As a result, companies’ privacy practices and mistakes are often exposed instantaneously to unpredictable results. Another factor is that personal information crosses national borders at the speed of light, whether between people and organizations sending and receiving information, or for processing in the cloud. This movement of data leads to overlapping claims of jurisdiction. On one of the panels in Jerusalem, for example, several European lawyers and regulators disagreed sharply about jurisdiction when offered a complicated fact pattern of data transfers to and from Europe. Even in the U.S., privacy laws are constantly evolving with states enacting privacy and information security statutes at an alarming rate, courts and regulators reinterpreting privacy rights, and regulators and industry groups issuing their own guidance. Privacy may seem like a minefield for which there is no map.

Privacy lawyers strive to survey and understand this minefield and translate it into a roadmap that helps businesses not only to avoid the mines, but to think about privacy in a positive way. We want our clients to know that privacy is not a prohibition against collecting and using personal information, but a commitment to collect and use the information in a fair and transparent manner. We help our clients be proactive in addressing privacy and understanding that privacy can and should be good for business. On the other hand, we help companies frame their business models, personal information processing activities and privacy programs in a manner that helps privacy regulators and privacy advocates view our clients’ businesses and privacy programs in a positive light.

On the issue of privacy compliance, participants agreed that Europe continues to be a difficult landscape to navigate in understanding the applicability of local data protection laws to personal data processing activities. At the same time, European panelists acknowledged that diverging views on jurisdiction may not be compatible with the fact that data flows do not know physical borders, and called for more uniformity among EU member states.

The topic of privacy enforcement generated great interest among conference participants. It continues to be a source of frustration for the industry and privacy practitioners. At the conference, panelists acknowledged limitations and inconsistencies of the various privacy enforcement regimes. For example, many of the European regulators are constrained by limitations on their investigative or enforcement authority or discretion as to which consumer complaints to address, as well as budgetary constrains. U.S. regulators appear to be taking privacy seriously. The conference was well-attended by representatives of a number of U.S. federal agencies, including the Federal Trade Commission, the State Department, Commerce Department, and the Department of Homeland Security. The FTC’s Director of the Bureau of Consumer Protection David Vladeck explained that the FTC is choosing its enforcement actions carefully to give guidance to the industry as to which practices the Commission considers unacceptable. The FTC’s expectation is that the industry will follow the guidance provided by its privacy enforcement actions. At the same time, the Commission is ready to increase enforcement if it believes that privacy compliance levels are unsatisfactory. Panelists also suggested that private action enforcement, such class actions in the U.S. and group actions in Europe, may be gaining steam, although the practice is still in its infancy.

At the conclusion of the conference, the commissioners took a step in increasing international cooperation on privacy matters by admitting the FTC into membership in the conference. The admission is a vote of confidence in the FTC’s authority and independence in enforcing privacy regulations. It is also without a doubt the result of the FTC’s increased cooperation with European data protection commissioners. According to the FTC’s David Vladeck, this joint work will continue.

There are many more lessons learned from the Jerusalem conference that we expect to mention in future posts, so please stay tuned.

European Context

The European Union’s venerable Data Protection Directive, adopted 15 years ago, has had a huge impact on data privacy and security practices in the European Union and in the countries outside the EU, ranging from Russia to Canada to Japan, that have adopted national data privacy laws strongly influenced by the Directive. The Directive’s comprehensive approach to personal information privacy, based on widely accepted principles of fair information practices, contrasts with the US approach of legislating conditions on the collection and use of personal information only in specific contexts such as Social Security Numbers, credit reporting, financial accounts, and electronic health records. While the two systems sometimes produce similar results, the mismatch between Euro-style comprehensive data privacy laws and the detailed but sectoral regulation in the United States creates some challenges for organizations that conduct business across borders.

The EU Directive (Articles 25 and 26) directs member states to prohibit the transfer of personally identifiable data to countries whose laws are not deemed sufficiently similar, unless some other approved means of assuring adequate protection is employed. One response to the problem of assuring privacy protection overseas was the adoption of EU-approved standard contract clauses or “model contracts,” which were recently updated to better address the trend toward outsourced subprocessing (including cloud computing). Another was the EU-US “Safe Harbor” framework developed jointly by the European Commission and the US Department of Commerce, under which American companies can publicly certify compliance with a standard set of Safe Harbor Privacy Principles approved by the European Commission and enforced by American regulators, predominantly the Federal Trade Commission.

Some data protection officials in Europe have questioned whether these legal alternatives have been wholly effective in assuring the confidentiality and security of personal information from Europe that is stored or processed in the United States or other countries. Social networking and the popularity of cloud computing models for outsourcing data storage and processing have heightened these concerns, since there is often less clarity about where personal data are stored and by whom. Such concerns underlie the recent pronouncements by the German data protection authorities.

Behind the Drama

Dr. Weichert shows a flair for drama in calling for the immediate end of Safe Harbor and characterizing cloud computing users as scofflaws. His press release on Safe Harbor acknowledges that his radical proposal is unlikely to be adopted because “nobody in the EU seems to have the courage” to disrupt the close economic relations with the US. He complains that Google, Facebook, and other American companies encourage millions of Europeans to share personal information, without effective supervision or recourse. Dr. Weichert wants to reopen negotiations on the Safe Harbor principles and at least strengthen the enforcement mechanisms. An upcoming EU consulting report on Safe Harbor is likely to provide some ammunition for that argument, as it reportedly criticizes the FTC for taking action against only seven companies in the ten-year history of Safe Harbor, despite thousands of complaints.

On cloud computing, Dr. Weichert points out that customers do not always know where their data resides and who is handling it, making it impossible to assure compliance with the notice, security, and transborder obligations of data controllers under the national laws transposing the EU Data Protection Directive. Individual data subjects are supposed to be informed of material facts concerning the processing of their data, and this is usually interpreted to mean, among other things, that they must be told if the data are being processed outside the EU in countries with dissimilar legal protections for personal information. In such cases, the data controller is also responsible for assuring an adequate level of protection through model contracts, Safe Harbor, binding corporate rules, informed consent, or other approved methods. Where a cloud services provider is acting as a “processor” of the data on behalf of the European customer or data “controller,” which is typical in cloud computing arrangements, the data controller has an obligation under the national version of Article 16 of the EU Directive to conduct due diligence in selecting a provider and engage the provider with a written agreement that (a) forbids the processor from acting on the data other than according to the controller’s instructions and (b) requires the processor to maintain appropriate technical and organizational security measures. Dr. Weichert questions whether this routinely happens when a customer signs up for cloud services that are, in fact, provided in a variety of changing locations and sometimes by layers of different companies providing hosting facilities or software as a service (SaaS) applications.

Putting the Criticism in Perspective
 

State and national data protection authorities in Europe remain legally obliged to allow data transfers to Safe Harbor companies in the US, as the Safe Harbor decision was adopted through a legislative procedure requiring approval by the European Commission, consultation with the European Parliament, and a weighted majority vote by the member state governments. Any revision of the Safe Harbor decision must follow a similar process, even assuming the US were willing to reopen discussions on the jointly administered program. Thus, modifying or terminating the program would require extensive debate and negotiation. Meanwhile, state or national authorities can legitimately confirm that a company is currently certified under Safe Harbor, but they cannot prohibit data transfers simply because the parties rely on Safe Harbor rather than model contracts or another legal basis for transborder data flows from Europe.

Moreover, the Safe Harbor program has successfully attracted nearly 2000 American companies, including those that represent some of the largest trans-Atlantic data flows, and it is now paralleled by a virtually identical US-Switzerland Safe Harbor Framework. US and European authorities meet periodically to discuss the program and coordinate efforts to promote and enforce it. The Department of Commerce and the FTC are both engaged with European data protection authorities in this process, and any perceived gaps in enforcement are likely to be addressed in this dialogue rather than in an overhaul of the Safe Harbor Privacy Principles themselves. In a public conference on Safe Harbor held in Washington last November, European data protection authorities expressed satisfaction that the program had raised the awareness of American companies handling European personal information and helped ensure compliance on the part of the European entities collecting and using the data.

Similarly, although several data protection authorities have highlighted potential compliance problems with cloud computing solutions, none have taken legal or administrative action to prevent European companies from using them (not even in Schleswig-Holstein). Dr. Weichert participates in the Düsseldorfer Kreis, where his office takes the lead on examining insurance industry issues, but the group has not issued an opinion on the application of transborder data protection mechanisms to cloud computing. His comments, which have not been officially endorsed by other regulators, should be viewed as a caution to European cloud customers rather than as a legal or enforcement opinion.

Lessons for Global Companies

The German state authorities' comments come at a time when national data protection authorities in Europe are debating precisely how the EU Data Protection Directive should be updated to reflect developments in technology and information practices since the Directive was adopted 15 years ago. The European Commission had announced its intention to review scores of written comments submitted in a recent consultative process and then propose legislative revisions later this year. But the national DPAs, meeting with the Commission last month, prevailed on the Commission to postpone any proposals until mid-2011, according to an August 2 announcement by CNIL, the French data protection commission, which was later confirmed by EU Commissioner Viviane Reding. The Commission and the national authorities are reportedly concerned about divergences in national approaches in implementing the Directive and want to examine how best to apply the general principles of the Directive in an increasingly global, networked, and distributed computing environment.

Global companies must continue to assure compliance (and market acceptance) as they collect consumer data from users in Europe and handle European employee data in centralized enterprise resource management systems or outsourced applications. Safe Harbor is an efficient and widely accepted option for the companies themselves and for many of their vendors, and cloud services are often practical and cost-effective. However, given the concerns of European authorities (and possibly of European consumers and legislators), companies should carefully consider how to implement these solutions in a compliant manner:

• Keep Safe Harbor certifications up to date (they must be renewed annually) and make sure they accurately disclose the range of data transfers to be covered

• Conduct the required annual assessment of Safe Harbor compliance

• Publish a Safe Harbor privacy policy with conspicuous provisions for resolving individual questions and complaints

• Verify that US vendors (including cloud service providers) are Safe Harbor certified, or alternatively use EU-approved standard contract clauses

• Keep European personal information, especially sensitive data, out of any cloud or outsourcing arrangements with vendors that cannot or will not confirm compliance, recognizing that some vendors refuse to divulge their locations or sub-contractors

• Follow Dr. Weichert’s advice (and ours) to include a Security Service Level Agreement, Information Security Schedule, or other specific security requirements in any outsourcing or cloud agreement that involves European personal data.
 

I reported in February about the European Union adopting a new set of SCCs to legitimize the transfer of European personal data to foreign processors. From May 15 onward, the new SCCs must be used unless there is another legal basis for the transfers, such as the EU-US “Safe Harbor” program.

Here is a summary of the impact of this EU decision, in the form of FAQs:

Why Use Standard Contract Clauses?

The EU Data Protection Directive requires national authorities to forbid the transfer of personal information to countries outside the European Economic Area (EEA) unless the data will be adequately protected by law or a specific derogation, such as approved SCCs or the individual’s informed consent, applies.

The United States, India, China, the Philippines, Jamaica, South Africa, and other common destinations for outsourced data services do not have similar data protection laws and are not deemed to provide an “adequate level of protection.” US companies that participate in the “Safe Harbor” framework for handling European personal data in the US, or sending it onward for processing in a third country, are treated as offering adequate protection. So are multinationals that implement Binding Corporate Rules (“BCRs”) approved by each of the relevant European countries for data transfers within a corporate group. But apart from transfers to Safe Harbor companies or in certain narrow contexts such as express consent or BCRs, offshoring arrangements involving personal data typically do not comply with European national data protection laws unless the company in Europe enters into a contract with the foreign vendor that includes EU-approved SCCs.

(It is also possible to seek approval from each relevant country for a unique set of contractual clauses, but this is an uncertain and time-consuming alternative that few organizations pursue.)

There are good reasons for a US company to consider Safe Harbor or BCRs, although these are beyond the scope of this article. But in any event, there will almost certainly be contexts in which neither Safe Harbor nor BCRs will cover all the data transfers that the company requires, such as data transfers outside the corporate group or directly from Europe to vendors outside the United States. In those cases, SCCs will typically be required.

What Countries Accept the EU SCCs?

EU-approved SCCs are ostensibly a passport for personal data from all 27 EU member states plus the other three EEA countries – Iceland, Liechtenstein, and Norway. However, one EU member state, Hungary, has not yet conformed its national law to routinely allow data transfers based on SCCs (or on Safe Harbor or BCRs, for that matter); individual consent is still required in most cases in Hungary.

Outside the EEA, Switzerland and Israel, which have similar data protection regimes, allow the transfer of personal data abroad if the companies use EU-approved SCCs. There are also instances where other non-EEA countries, such as Russia, have approved data transfers under contracts employing the EU SCCs, on a case-by-case basis.

This does not mean that a company can sign an agreement including, or annexing, SCCs and just start transferring personal data to an affiliate or vendor in the US or India. Unlike transfers to “adequate” countries such as Canada or to US Safe Harbor companies, data transfers under SCCs require notification to the data protection authorities (DPAs) in many European countries, and in some countries the transaction must await prior approval by the local DPA. In the UK, notice is effected simply by checking a box on an online registration form. In France, Spain, or The Netherlands, on the other hand, the European company must submit details and await an official response. In Germany, the internal data protection officer must approve the transfers, and approval may also be required from a works council or labor union if the outsourcing involves employee data.

If a company does not vary from the text of the EU SCCs and attaches a satisfactorily detailed annex describing the data transfers, including any special provisions for protecting sensitive categories of personal information, authorization should be forthcoming. But authorization often takes as long as three or four months in some countries. This should be factored into project and contract timing.

What Do the SCCs Provide?

One of two different versions of EU-approved “controller-controller” SCCs must be used if the data controller in Europe is transferring personal data to a foreign data controller, such as a parent, affiliate, or business partner that will make its own use of the data. For transfers to a processor that is merely handling the data on behalf of a European data controller, the newly adopted version of “controller-processor” SCCs must be employed.

The SCCs, which must be made available to the authorities and affected individuals on request, identify the “data exporter” in Europe and the “data importer” overseas. In contracts with processors, the processor must agree to follow the instructions of the data controller and maintain the confidentiality and security of the data. In the case of contracts between data controllers, each of which can use the data for its own purposes, the relevant SCCs allow the parties to select the governing European data protection law or a minimum set of data privacy principles.

SCCs provide for third-party beneficiary liability to the affected individuals and allow the data exporter to terminate the entire data transfer agreement if the data importer fails to comply with the SCCs. The SCCs also require the parties to annex a description of the covered data transfers in a prescribed format.

What’s Different about the New Processing SCCs?

The chief difference between the new controller-processor SCCs and the prior version published in 2001 is that the new SCCs take account of the trends to subcontract storage, technical support, or specific processing functions to third parties. When such “subprocessing” is contemplated, the new SCCs require the vendor to obtain the customer’s consent to subprocessing and execute written agreements with the subprocessors placing them under the same obligations to protect the personal data. The customer is also required to maintain a list of such subprocessing agreements and make it available on request to the data protection authorities, who may audit any subprocessing.

Here are some examples where these changes will typically involve more investigation and documentation than previously:

• An outsourcing vendor in the US plans to have some contracted functions performed by its affiliates in India or China.

• A cloud computing vendor aggregates services and hosting provided by a network of third parties.

• A parent company in the US, which has been providing technical support to European affiliates under SCCs, plans to outsource some support functions to vendors.

Are Existing Vendor Contracts Grandfathered?

Yes. Contracts in place before May 15, using the older version of EU-approved processing SCCs, may continue without revision until they expire, or until the nature of the data transfers changes materially or the vendor seeks to add a subprocessor.

Should We Use the Controller or Processor SCCs?

Sometimes it’s hard to tell which SCCs to use, because it is a factual question whether the data importer is in some respects acting as a controller of the data as opposed to acting as a mere processor. Simply saying in the contract that the data importer is only a processor may not preclude a different opinion by the authorities or the courts.

A parent company in the US, for example, may support global communications and ERM functions on behalf of its European subsidiaries, similar to what an unrelated outsourcing vendor might provide. But if the US parent also has access to the European data for its own purposes – such as corporate planning, career development and succession planning, and perhaps global insurance, audit, or legal functions – the US parent looks more like a data controller with respect to those purposes. Thus, a US parent company might be viewed as both a controller and a processor of European data.

Similarly, a global company may retain a benefits provider, perhaps to manage an employee stock option program or administer a pension fund. To the extent that the benefits provider simply performs functions at the employer’s behest, it appears to be a processor. But if the benefits provider also markets and provides additional services directly to the employees, it seems to be taking on the role of a controller.

In most European countries, the parties could safely rely on the controller-controller SCCs in such cases of mixed use. However, DPAs (especially in Greece) sometimes insist on separating the functions and require the data importer to sign two SCCs, one as a controller and the other as a processor. European Commission staff reports have occasionally noted the potential ambiguities in this, and other, applications of the controller and processor concepts, but as yet there is not a uniform and predictable approach to the problem.

The EU Data Protection Directive primarily regulates data controllers. A controller is defined in Article 2 of the Directive as the natural or legal person or public agency that “alone or jointly with others” determines “the purposes and means of processing” personal data. A processor is a natural or legal person or agency that processes data on behalf of a controller. “Processing” is defined very broadly in the Directive to include collection, use, storage, manipulation, disclosure, disposal, and virtually any other action with personal data. A controller can decide either to process personal data itself or delegate some or all processing activities to a processor. International data transfer agreements using SCCs always involve a data controller in Europe transferring personal data to either a controller or processor abroad.

In February, the Article 29 Data Protection Working Party, comprised of data protection officials from the European Commission and each of the member states, issued Opinion 1/2010 on the concepts of “controller” and “processor.” The concepts are important, of course, not only in choosing which SCCs to use in international transfers, but more importantly in deciding who has ultimate responsibility for protecting and properly using personal data, and which country’s law applies.

The Article 29 Working Party Opinion identifies controllers as the entities that decide to have some personal data processed for their own purposes. It recognizes that multiple parties (such as a parent company and its affiliates or business partners) may collectively decide which data elements are needed and how they will be handled. They need not have equal voices in those decisions, and their respective responsibility and liability may be limited to their own decisions. The Working Party also concluded that a processor may have some discretion in determining “the most suitable technical and organizational means” to accomplish delegated processing, without becoming a controller.

The Opinion, in my view, supports the conclusions that many global companies have reached, that parent and affiliate companies in a group usually should be considered joint controllers of employee and customer data used for a variety of purposes within the group, and that third-party outsourcing vendors remain merely processors even if they propose and implement decisions about the means of processing, based on their expertise. When struggling with the controller/processor distinction, organizations should ask the basic questions, “who wants this personal data, and why?” as a guide to recognizing who is ultimately responsible for the data and who is merely crunching it on their behalf. Among other things, the answers to those questions will determine which set of SCCs to use for international data transfers.
 

As readers of this blog are no doubt aware, security breach notice laws have proliferated in the United States since California’s SB 1386 came into effect in 2003. Forty-five states, the District of Columbia, Puerto Rico, the Virgin Islands, and the US federal government (with respect to medical and financial data) have established obligations to notify potentially affected individuals, and sometimes relevant authorities, when there is reason to believe that the security of certain kinds of personal information has been compromised.

The focus in the US has been on the kinds of information most likely to be abused for purposes of identity theft and fraud. The “standard set” of personal information covered by state breach notice laws is limited to unencrypted, name-linked Social Security Numbers, driver’s license or other official state identification numbers, and bank account or payment card numbers (if the access code is compromised as well). The federal HITECH Act requires notice in many cases where personally identifiable medical information has been compromised, and several states require notice of security breaches involving health-related information or other data elements beyond the “standard set,” ranging from date of birth and mother’s maiden name to employer and tribal ID numbers.

American companies, nonprofits, and public entities are becoming familiar with breach notice obligations and consequences in the US, but some of the same security incidents also compromise data concerning individuals residing in other countries, most commonly Canada. US-based enterprises often ask how a data leak including protected information about Canadians should be handled.

While I am not a Canadian lawyer, I have had occasion to help clients determine how to address international data leaks, often with assistance from qualified Canadian counsel. Here are some important background facts and guiding principles gleaned from these experiences and from recent developments in Canadian law and official guidance:

PIPEDA and Provincial Privacy Laws

While Canada has not (yet) adopted federal breach notice legislation, relevant obligations are found in the federal Personal Information Protection and Electronic Documents Act (“PIPEDA”), which came fully into effect in 2004. PIPEDA’s Schedule 1 states ten “fair information principles” articulated by the Canadian Standards Association (CSA) for the collection, use, or disclosure of personal information. Unlike the American approach of protecting only specific kinds of personal information, PIPEDA defines personal information broadly as any information about an identifiable individual except business contact information.

PIPEDA applies to federal works, undertakings, or businesses (“FWUBs,” notably banks, telecommunications firms, transportation companies, and enterprises operating in the territories), as well as to inter-provincial and international commercial activities and to commercial activities within provinces that have not enacted similar privacy legislation.

However, under Canada’s constitution, employment matters are traditionally left to provincial law, so PIPEDA normally does not govern an employer’s handling of employee data unless the employer is an FWUB. Provincial law rather than PIPEDA also applies if the federal Governor in Council determines that provincial legislation is “substantially similar” to PIPEDA and incorporates the CSA fair information principles. So far, Alberta and British Columbia have enacted personal information protection acts (“PIPAs”) based on PIPEDA, and Quebec has an older personal data protection statute based on broadly similar principles. Ontario enacted a Personal Health Information Protection Act in 2004 modeled on PIPEDA’s approach to personal information, although the act concerns only health-related information. These four laws have been deemed “substantially similar” to PIPEDA.

The federal and provincial privacy commissioners are authorized to investigate compliance issues, including security breaches, as well as offering interpretation and guidance on the application of privacy laws. The commissioners may refer suspected violations to prosecutors. The commissioners’ guidance documents are not legally binding, but they serve to establish “best practices” in industry and are likely to be influential in court.

So, an American company suffering a data leak involving Canadian consumers normally looks to PIPEDA and guidance from the federal Privacy Commissioner, because the company is typically engaged in international or inter-provincial commerce. To the extent that the data leak involves Canadian employee data, the American company normally looks to provincial law, and only Alberta, British Columbia, and Quebec have PIPAs (and guidance from provincial privacy commissioners) governing employee privacy. If the incident involves health information in Ontario, the Ontario Personal Health Information Protection Act generally applies. (As in the US, there may also be liability for a security incident under tort or contract law, but the focus here is on laws and guidance concerning breach notice.)

Is Breach Notice Required under Canadian Privacy Laws?

PIPEDA does not explicitly address security breach notice to affected individuals or to the relevant privacy commissioner. However, PIPEDA (like the provincial PIPAs) regulates the authorized “collection, use or disclosure” of personal information, and lost or stolen personal information may be deemed an unauthorized collection or use of data, or, from the perspective of the responsible organization, an unauthorized “disclosure” of personal information.

Specifically, PIPEDA holds an organization “responsible for personal information under its control” (Sch. 1, sec. 4.1) and requires the organization to designate one or more individuals who are “accountable” for the organization’s compliance (Sch. 1, secs. 4.1.1, 4.1.2). The Act requires the organization to ensure a comparable level of protection, contractually or by other means, when the information is handled by a third party (Sch. 1, sec. 4.1.3). The consent of the individual is required for the collection, use, or disclosure of personal information, except where consent would be “inappropriate” (Sch. 1, sec. 4.3). Personal information is not to be used or disclosed for purposes other than those for which it was collected, except with consent or as required by law (Sch. 1, sec. 4.5). Organizations must protect personal information with “security safeguards appropriate to the sensitivity of the information” (Sch. 1, sec. 4.7). A security breach might be viewed as a violation of any or all of these principles.

PIPEDA does not explicitly include a requirement to notify privacy commissioners or individuals of instances of noncompliance. Organizations are not required to register or report to privacy commissions, as in many European countries, although PIPEDA (like the provincial PIPAs) empowers the privacy commission to “audit” the personal information management practices of any organization if the commission has “reasonable grounds” to suspect a violation (PIPEDA sec. 18). The “openness” principle of PIPEDA and the provincial PIPAs directs organizations to make their personal information “policies and practices” readily available to individuals (PIPEDA Schedule 1, sec. 4.8), and the law provides that organizations must have procedures for receiving and responding to requests for information and complaints (Sch. 1, secs. 4.9, 4.10). Arguably, this may imply openness about known, substantial security failures, and it certainly means that the organization must have procedures in place for fielding any questions about an announced or suspected security breach involving personal information.

Privacy Commissioner Guidelines

Following widely publicized data breaches at a unit of the Canadian Imperial Bank of Commerce and Canadian subsidiaries of the US-owned TJX retail group, the federal Privacy Commissioner, in collaboration with the Privacy Commissioners of Alberta, British Columbia, and Ontario, issued a document entitled “Key Steps for Organizations in Responding to Privacy Breaches” (the “Guidelines”) in late 2007. The Guidelines define a breach as “an unauthorized access to, or collection, use or disclosure of, personal information.” “Unauthorized” refers to an act in violation of PIPEDA or similar provincial legislation, thus tying security breaches to compliance with the laws for which the privacy commissions are responsible. The Privacy Commissioner of Ontario issued similar guidance for health information custodians under the Ontario Personal Health Information Protection Act.

According to the federal Guidelines, an organization that becomes aware of an unauthorized access to personal information should consider the following steps and implement them to the extent necessary to mitigate harm:

1. Breach containment and preliminary assessment (shutting down systems, recovering records, designating a lead investigator, determining who needs to be notified inside and outside the organization, notifying the police of suspected criminal activity, preserving evidence)

2. Risk evaluation (kinds of data involved, causes and risk of further exposure, number and names of affected individuals, who received access to the data and what kind of harm could result)

3. Notification (see below)

4. Prevention of future breaches (security audit, assessment of policies, employee training)

Notification is to be determined on a case-by-case basis including the following factors:

• Individuals should be notified if the breach poses a risk of personal harm, including physical injury, identity theft, fraud, financial loss, loss of business or employment opportunities, humiliation, or damage to reputation or relationships.

• Individuals should be notified “as soon as possible” following assessment and evaluation of the breach.

• The preferred form of notification is direct – by phone, email, or postal mail. Indirect methods (such as media announcements) are appropriate only where direct notification could cause further harm.

• The organization with a direct relationship with the individuals should normally be the one to notify them.

• Notices should generally include descriptions of:

o The incident
o The information compromised
o Actions taken by the organization to mitigate harm
o Resources to help the individuals take protective measures.

• Notification may also be appropriate to other parties such as
 

o Privacy commissioners
o Police
o Licensing or other regulatory bodies
o Affiliates or business units
o Trade unions
o Third-party contractors affected by the breach
o Insurers
o Credit card issuers.
 

Unlike American breach notice statutes and regulations, which are legally enforceable, the Guidelines themselves do not have the force of law. Canadian lawyers emphasize, however, that courts are likely to defer to the expert commissions and consult the Guidelines in deciding whether an organization suffering a security breach has violated PIPEDA or a provincial PIPA, or whether the organization has met contractual expectations or a duty of reasonable care under tort law.

Other notable differences between the Canadian approach and US breach notice laws:

• Scope: US laws require breach notice for only certain kinds of unencrypted personal information, with an emphasis on preventing ID theft or protecting medical data. Canada’s PIPEDA and provincial PIPAs cover all personally identifiable information and all forms of harm.

• Encryption: Unlike US laws, Canada’s PIPEDA and PIPAs, as interpreted by privacy commissioners, do not expressly offer a “safe harbor” for encrypted data. However, encryption presumably should be taken into consideration in determining whether there has been “unauthorized access” to the data and whether there is a material risk of future harm.

• Notice to authorities: Some US laws mandate notice to specified authorities, such as law enforcement, regulatory, or consumer protection agencies. The Canadian laws are silent on this, but the Guidelines “encourage” organizations to report to the relevant privacy commission(s) and, where appropriate, to police and regulatory authorities and affected third parties.

• Notice to individuals: US laws make breach notice mandatory under specified conditions, while the Canadian Guidelines simply list factors to consider in determining whether notice is necessary.

• Form of notice: The Guidelines show a strong preference for direct notice to the affected individuals, delivered by the party with the closest relationship to the individuals. Many of the US breach notice laws permit (or require) mass media announcements where large numbers of individuals are involved or it is “impractical” to notify individuals directly.

Ontario’s Personal Health Information Protection Act

Although Ontario has not yet enacted a comprehensive PIPA, its Personal Health Information Protection Act already includes breach notice requirements for custodians of personal health information (sec. 12(2)):

“a health information custodian that has custody or control of personal health information about an individual shall notify the individual at the first reasonable opportunity if the information is stolen, lost, or accessed by unauthorized persons.”

The Act appears to hold a health information custodian in Ontario responsible for breach notice regardless of where the breach occurs.  A security breach at an American affiliate or service provider, for example, could trigger notice obligations on the part of the Canadian health information custodian.
 

Alberta’s Bill 54

While the federal government continues to consider proposed PIPEDA amendments, including provisions that would introduce specific breach notice requirements, the province of Alberta has gone ahead with Bill 54, amending Alberta’s PIPA. The bill, adopted by the legislature last year, has already received Royal Assent and will come into force on proclamation, which is likely to occur in the near future.

Bill 54 is significant for companies operating in Alberta or otherwise handling data concerning Alberta customers or employees. It increases penalties for noncompliance, imposes a duty to destroy personal information when it is no longer needed, and requires notice to individuals before transferring personal information to a foreign service provider, a practice that must also be described in the organization’s personal information management policies and procedures.
 

Importantly, Bill 54 also requires an organization to notify the Privacy Commissioner of Alberta if personal information under its control is lost, accessed, or disclosed to a third party without authorization and if “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.” The details to be included in such a notice will be prescribed by regulation, and the Commissioner may request additional information concerning the breach.

Once notified, the Privacy Commissioner is authorized to require that the organization provide notice to affected individuals, under terms and conditions that the Commissioner deems appropriate in the circumstances, following an “expedited” procedure. The law expressly permits organizations to notify individuals on their own initiative, but the Commissioner may require additional notice.

If Alberta’s new law is a good indicator of where federal and provincial legislation is headed, companies can expect that significant data breaches in the future will typically involve a prompt notice to the relevant privacy commissioner(s) and some colloquy with their offices before sending notices to individuals in Canada. This represents a level of official involvement beyond what is common in the United States outside the investigation of potentially criminal acts of theft or fraud.

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.