Lessons Being Learned about Cloud Computing
Dave and I recently spoke with Nymity regarding privacy and data security issues in cloud computing deals. You can read the interview here. We addressed a number of questions, including:
- What makes cloud computing different from computing in-house or "normal" IT outsourcing?
- What are the key benefits?
- What are the key risks?
- Should in-house lawyers and compliance, privacy and security officers be concerned?
- What do in-house lawyers and compliance, privacy and security officers look for to identify cloud computing activities?
- How do in-house lawyers and compliance, privacy and security officers quickly understand the new risks and implement controls to reduce these risks?
- What can in-house lawyers and compliance, privacy and security officers do to educate executive management?
- What does it look like when a company does a great job selecting a cloud vendor? What do they do up front before beginning the due diligence process? What do they do during the due diligence and contract negotiation processes? What risks do they mitigate? What controls do they put into place?
- What are important compliance, security and privacy elements for cloud contracts?
You can find some of our thoughts on these questions and more here.
Do the New EU Processing Clauses Apply to You?
A new set of EU standard contract clauses (“SCCs” or “model contracts”) for processing European personal data abroad came into effect on May 15, 2010. Taken together with a recent opinion by the official EU “Article 29” working group on the concepts of “controller” and “processor” under the EU Data Protection Directive, this development suggests that it is time to review arrangements for business process outsourcing, software as a service (SaaS), cloud computing, and even interaffiliate support services, when they involve storing or processing personal data from Europe in the United States, India, and other common outsourcing locations.
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.
Information Security Standards and Certifications in Contracting
When organizations contract for outsourced IT services, they look for assurances that the vendor will provide adequate security, often in the form of a security schedule or annex to the contract, or by reference to a widely accepted information security standard. In some cases, the customer insists as well on a certification or audit by an expert third party.
Business managers and lawyers often have only the vaguest notions of what these schedules, standards, and certifications mean. They rely on the organization’s IT staff or consultants for “the technical stuff.” But in the end it is the business managers and lawyers who determine what the organization needs, operationally and contractually. To do that well, they should have at least a basic understanding of the more common information security standards and certifications.
In contracting for IT services, it’s tempting to simply refer to an information security standard and perhaps require a warranty or third-party certification. But that is sometimes overkill, given the nature of the data and risks involved in the project. And in any event, the customer needs to know if the warranty or certification actually covers the measures that the customer would take itself to protect its business and manage its compliance and liability risks.
One Size Does Not Fit All
It is significant that information security laws and standards typically require a risk-based assessment of threats, harm, and mitigation measures, rather than prescribing, for example, a specific form of encryption for all protected data.
This suggests that customers and vendors should be realistic about assessing what the customer legitimately requires in the way of security for a particular project or application. We have seen outsourcing and cloud services contracts where the vendor’s standard contract offers only “reasonable and appropriate” security measures, with no details and no mention of who does what (and at whose expense) in the event of a suspected security breach. When you use free web apps to publish the schedule for your kid’s soccer team, you can live with terms of service that include the phrases “as is” and “as available.” An organization might need only minimal security and service level guarantees for a wiki or social networking application designed to facilitate online brainstorming, or for a software development “sandbox.” But if the outsourcing or cloud vendor is handling highly confidential information or mission-critical transactions, the customer should insist on stronger assurances and specify any particular compliance requirements for relevant functions such as processing credit card details, Social Security numbers, electronic health records, or HR data transferred from Europe. If the vendor cannot or will not offer sufficient details or assurances, the customer should look elsewhere, because the customer’s business, liability, and reputation are at stake.
Some large customers take this too far, however, routinely demanding security certifications that may add considerably to the cost of the contract or eliminate many potential vendors, in circumstances where there is little actual risk. I was recently involved in a contract for a software implementation project that entailed creating a specialized organizational database including photos and business contact information of the customer’s relevant personnel. Because the vendor would be required to work with some form of personal data (none of it sensitive or subject to personal information security or breach notice laws), the customer insisted, at the last minute, on including its “standard” personal information security annex. This included a provision for control by the customer, and indemnification by the vendor, in the event of a security breach involving the personal data. That makes some sense, since the customer, in the end, will be held accountable. The vendor was not concerned about this provision, however, since it would not be handling data covered by personal information security laws. But the annex also required the vendor to produce a SAS 70 Type II certificate, as well as a third-party certification of conformance to the ISO 27002 standard. These typically require tens of thousands of dollars and at least six months to obtain. A BPO vendor serving the financial services or government markets might already have this in place, but not a small firm of specialized IT consultants. In this case, it turned out that the cost of complying with these requirements would have exceeded the value of the contract. And all this to protect publicity photos and business contact details?
When conducting due diligence and contracting with an IT vendor, the customer should focus on the sensitivity of the data and functions at issue and then satisfy itself that the vendor will meet the classic “CIA” requirements for information security: confidentiality, integrity, and availability. Where those requirements are linked to legal standards, such as HIPAA compliance or contractual PCI-DSS obligations, the customer should call those out in the contract and make sure the vendor has the capability and commitment to meet them.
Information Security Standards and Certifications
There are some very specific published standards for security measures and devices, usually in areas where interoperability is required, such as chip cards, point-of-sale terminals, and WiFi. But customers are usually concerned more generally with a vendor’s security controls and procedures, and those are addressed in several widely used standards. These are typically risk-based, procedural approaches, essentially providing a checklist of issues and considerations that the organization is to take into account in selecting and monitoring security measures.
If a vendor asserts that it uses one of these security frameworks or standards, it indicates a level of awareness and sophistication about assessing security risks and implementing appropriate measures. But it does not reveal what measures the vendor has chosen to adopt, nor its track record in actually securing customer data. Customers should consider asking in addition for the vendor’s written information security policy or policies, and for contracts involving sensitive processing customers might ask as well for audit results or third-party certification.
Prompted by the focus on internal controls for financial reporting under the Sarbanes-Oxley Act (SOX), publicly traded companies in the US often employ CobiT, Control Objectives for Information and Related Technology, a standard framework for IT governance and information management controls published by the IT Governance Institute and the Information Systems Audit and Control Association (ISACA) . A vendor might refer to its use of the CobiT framework, but this offers little specific assurance about how the company secures customer data, and so it is generally not a sufficient point of reference for an IT contract.
US federal agencies are required under FISMA (the Federal Information Security Management Act of 2002) to refer to security standards and guidelines published by the National Institute of Standards and Technology in designing information systems and procuring IT services. Some of this guidance is general and largely procedural, prominently FIPS 200 (“Minimum Security Requirements for Federal Information and Information Systems”) and NIST Special Publication SP 800-53, "Recommended Security Controls for Federal Information Systems". Many government contracts refer to FIPS 200 and SP 800-53, as well as to more specific NIST guidelines on particular applications such as laptop security, voice over internet services, and secure data deletion. Some vendors familiar with the government market refer to relevant FIPS standards in their private-sector contracts as well. This can offer a high level of assurance to customers with relevant security needs.
Internationally, the most commonly referenced information security management standard is ISO 27002 (formerly ISO 17799), which has evolved from the BS 7799 standard developed by the UK government in the 1990s. ISO/IEC 27002:2005 (which can be purchased from ISO) is a code of best-practice recommendations for information security management. It contains recommended information security controls and objectives in twelve areas (risk assessment, security policy, security organization, IT asset management, HR security, physical and environmental security, communications and operations management, access controls, information systems acquisition and maintenance, business continuity, and compliance with relevant laws and policies). A contractual reference to ISO 27002 helps ensure that the vendor is aware of security management issues, but it does not indicate exactly what the vendor does to secure customer data or systems. Moreover, since it is a compilation of best practices rather than a statement of mandatory control procedures, ISO 27002, on its own, does not lend itself to certification or audit.
In circumstances where the customer requires greater assurance through third-party verification of security measures, the customer should consider requiring a certification of compliance with ISO 27001, which states management control requirements for information security management systems. ISO 27001 requires management to systematically assess the organization’s security risks and impacts, design and implement security controls to address unacceptable risks, and adopt management procedures to review and revise those controls over time. When an organization self-certifies compliance with ISO 27001, or obtains certification from a third party, it normally refers as well to ISO 27002, because that provides implementation guidance for the selected controls. Certification under ISO 27001 is typically a three-stage process of initial review of applicable systems and policies, a detailed compliance audit of the organization’s Information Security Management System (ISMS), and periodic (usually annual) reviews. In many countries, third-party certifications are provided by “accredited registrars” or “accredited certification bodies” recognized by a government-authorized accrediting body. In the US, the typical practice is to retain an information security consultant to conduct a security audit with reference to ISO 27001 and 27002. References to ISO 27001 / 27002 are common in international service contracts, although costly and time-consuming third-party certification is required in the minority of cases. ISO 27001 / 27002 seems to be catching on in the US as well, although it is still rare to see US contractual requirements for certification of compliance with ISO 27001.
The relatively new ISO 27005 (derived from BS 7799-3) deals specifically with security risk management in the outsourcing context. This is mostly seen in UK contracts so far, but it is becoming familiar among major outsourcing vendors in India, South Africa, and Jamaica.
In the regulated financial services industries in the US, it is common to require vendors to submit a SAS 70 service provider audit (AICPA Statement on Accounting Standards No. 70: Service Organizations). This usually addresses preventive and detective internal security controls, as well as business continuity. The SAS 70 Type II audit requires an evaluation of the effectiveness of security controls over the review period, usually six or twelve months. The equivalent in the UK is the AAF 01/06 "assurance report" (replacing FRAG 21/94) on internal controls for outsourced service providers. Similar forms for the assessment of service providers’ internal controls are published by the accounting and audit professional associations in Australia (Auditing Guidance Statement 1042 - Reporting on Control Procedures at Outsourcing Entities), Canada (CICA Handbook Assurance and Related Services 5900), Hong Kong (HKCPA Statements Auditing Practice Note 860.2), and Japan (Audit Standards Committee Report No. 18).
Traditionally required by bank and insurance regulators to control risks in outsourcing material operations to a service provider, the SAS 70 and its foreign equivalents are now sometimes used outside the financial sector, because it is an established method for obtaining third-party certification of security controls. The SAS 70 is most meaningful when the auditor tests control procedures based on a specified security framework or standard, such as ISO 27001 / 27001, CobiT, ITIL, BITS (banking industry standards), FIPS 200, or the AICPA Trust Principles, as well as on the organization’s written security policies.
For payment card data, banks and merchants must comply with the payment card industry’s global PCI DSS standard, and that should be referenced in any contract with a vendor handling such data. Where the customer needs stricter assurances, the contract can require submission of a PCI DSS Self-Assessment Questionnaire (SAQ) or a compliance assessment by a Qualified Security Assessor (QSA). (The PCI DSS standard requires independent QSA assessments for organizations handling more than a specified number of payment card transactions, while others need only prepare an SAQ.) Customers that are themselves required to obtain a periodic QSA assessment should require their relevant vendors to provide such an assessment, or participate in one conducted by the customer.
The Bottom Line
Customers and vendors need to be clear about security responsibilities. In many cases, this is facilitated by a reference to standards, but due diligence and contract drafting should not end there. Such references almost always need to be supplemented with specific requirements and policies concerning security measures for the particular kinds of data that the customer needs to protect, with express reference to any controlling laws or industry standards. Where the customer has especially sensitive or legally protected data, it should also consider contractual audit rights or a provision requiring the submission of a third-party certification or assessment of the vendor’s information security controls.
Cloud Providers Competing on Data Security & Privacy Contract Terms
I ran across an interesting article in PC World the other day concerning a head-to-head competition between Google Apps (Google's SaaS offering) and Microsoft's Office to provide certain day-to-day applications to the City of Los Angeles. The end result of this competition is that Google will be providing Google Apps (SaaS) to the City of Los Angeles (including at a minimum Gmail, Google Calendar, Google Talk, Google Docs, etc.). LA predicts that 60-80% of its staff will be able to use utilize those apps (LA reportedly is not forcing its staff to abandon Microsoft Office, but will not buy any new Office licenses)
However, interesting from a legal and business point of view is the apparent importance of Google's contract terms in the City's decision to choose Google's Cloud over Microsoft's Office.
On that issue the PC World article reported the following:
Google moved early to make this a contest over which company offers the best contract terms and legal protections in cloud environments. The city of Los Angeles, which may be Google's marquee government user, has been frank in disclosing details of its agreement. By the end of June, Los Angeles expects to complete a transition of some 30,000 employees to Google Apps.
In a sense, Kevin Crawford, Los Angeles assistant director of IT, is Google's de facto public sector evangelist. He doesn't market Google directly, but he answers questions from many other local government and state officials who want specifics about the city's deal with Google. Indeed, at the SaaScon conference on cloud computing and software as a service here this week, Crawford has been peppered with questions about the contract terms.
Los Angeles has been frank about the contract, which includes unlimited damages for a data breach, provisions allowing audits, guarantees that the data remain in the contiguous 48 states, and penalties if Google's services are unavailable for any longer than five minutes a month.
The contract also gives the city the right to cancel its contract with Google "for convenience," Crawford said.
Moreover, the contract reportedly includes specific data security and privacy controls and requirements and "unlimited damages" if Google breaches confidentiality obligations:
Los Angeles spent months negotiating a contract with Google that includes a provision providing the city with unlimited damages if its nondisclosure agreement (NDA) is breached by Google, said Kevin Crawford, the assistant general manager of IT for Los Angeles and the person who is managing the transition. That clause aims to protect the city from a third party claim if personal data is release, said Crawford.
Crawford said the most important clause in the contract requires that Google to encrypt the city's data and break it into pieces when it is at rest so that no one can get their hands on a full file. If hacker somehow accesses a file, he will only see "a whole bunch of gibberish," Crawford said. The contract also bars Google from viewing any data without permission from the city.
Los Angeles data will be administered from inside LA's firewall by city staffers through an administrative console built by Google, said Crawford. "We have control of our portion of the data," he said.
Moreover, the data must remain on systems within the continental U.S. That can be verified via auditing by the city, Crawford added.
"We're going to have a more secure system then we have today," said Crawford, noting that Google personnel does more work on security "than we could ever afford to do."
The Information Law Group has previously discussed the importance of data security, privacy and compliance in the Cloud context. This situation seems to validate the premise that Cloud providers are going to (and willing to) compete on these issues and the contract terms that relate to them.
From the InfoLawGroup's own recent experience, data security and privacy terms (and associated indemnities and shifting of risk of loss) have become much more important in IT outsourcing arrangements (whether Cloud or "traditional"). Lately it seems that right after price and service description/promises, significant time, effort and expense are being expended drafting and negotiating data security and privacy terms. In fact, because of the complexity of security and privacy, and associated laws, in InfoLawGroup's recent experience, these terms can take more time to settle out then more "basic" contract terms. Overall, the key reality at this juncture is that there is significant financial risk associated with poor data security and privacy and related regulatory requirements. In many cases, in terms of pure dollar amount this risk can dwarf the value of the contract (or the savings of the contract) if favorable contract terms are not negotiated.
One thing to note, having reviewed the Google contract (and the related Computer Science Corporation contract), which can be found at the end of this report, the scope of Google's contractual promises may not be quite as clear cut as described by LA officials (a breakdown of the Google data security and privacy contract terms will be the subject of a second post on this issue).
What does this mean for customers entering into Cloud (or other outsourcing) contracts?
So what does this all mean to companies looking to go into the Cloud and hoping for contract arrangements that offer protection? A lot. Organizations are giving up a great deal of control when they outsource into the Cloud, and only good contract terms can compensate for that loss of control. Unfortunately, many companies are focused on basic contract terms like price and often find themselves in a "take it or leave it" position when it comes to data security and privacy terms. In terms of timing, lawyers working on these contracts often find that the service provider is more or less "locked in" at the point where data security and privacy contract terms are first addressed. Oftentimes competitors have been eliminated and are no longer in the picture, and as a result the customer has little leverage to negotiate more favorable terms.
To be in a better position to negotiate favorable data security and privacy terms the current leverage dynamic needs to change. This LA-Google situation is a very favorable sign that service providers, if handled properly, are willing to negotiate on these terms in order to win a contract. However, customers must realize that most service providers are not going to approach a contract this way unless the customer creates an environment that provides it with leverage. To achieve this customers looking to enter into IT outsourcing arrangements (Cloud or otherwise) should consider the following:
- Approach multiple vendors. In many cases the only viable threat a customer has is to walk away to a competitor. If no competitors are in the picture then there is not realistic threat and no leverage exists. The problem is that many companies are attracted to a specific vendor, or other vendors don't quite have the same service offering as the preferred vendor. Nonetheless, rather than becoming blindly enamored with a particular vendor, organizations would be well-served to find and look at competing offerings (at least to get some negotiating leverage against the primary vendor).
- Address these issues at the "Request for Proposal" phase. Price and service offering description are the key components that go into a RFP, but considering the material financial risk posed by data security and privacy, why shouldn't those terms be highlighted in an RFP as well? Rather than getting locked-in to a service provider after the RFP phase, it is better to lock the service provider into the data security and privacy terms you desire at the outset. This is the time where the providers will be hungry and more willing to concede on issues. The RFP should include the specific security and privacy requirements the organization desires, as well as specific contract language that should be included in the contract. For companies that do a lot of IT outsourcing, these documents can be standardized and simply plugged into the RFP (which also has the benefit of creating consistency across the organization). If you don't have an RFP process, then you should. Adding data security and privacy requirements (and contract language) ♠changes the dynamic and makes the service provider compete on all aspects of the transaction.
- Keep competitors around. Rather than eliminating alternatives at the outset, keep other competitors around (even if their offering may not be 100% ideal). Again, the longer you can maintain your threat to walk away to a competitor, the stronger your position will be to achieve concessions. Moreover, the "less than ideal" competitors can start to look more attractive when your "ideal" service provider refuses to accept any responsibility for your data security or privacy.
- Pre-establish your positions and your fall-backs. It is important to predetermine your positions regarding data security and privacy risk and the contract terms your organization is willing to accept. Organizations that routinely enter into contracts implicating these issues should develop a security and privacy schedule that indicates specific controls that are required. The legal team should develop primary and secondary positions for confidentiality obligations, indemnification, limitations of liability, consequential damages disclaimers, compliance with privacy and security laws, and other related contractual requirements. These back-end contract terms can be folded into and made part of the RFP. They also provide for consistency across the organization and let the company understand and manage its exposure when using third parties to store, transmit or process data.
Conclusion
From the customer perspective, it is very encouraging to see a major Cloud provider willing to negotiate on data security and privacy contract terms in order to win business. However, it is likely that the result in this case was very much due to how Los Angeles handled the negotiation. Organizations that are concerned about these risks when they enter into the Cloud need to position their organization and the transaction in a manner that changes the leverage dynamic in their favor. Otherwise, they may find themselves at the end of a contract negotiation taking on enormous risk with little actual control over the risk.
Privacy's Trajectory
As many of our readers know, the International Association of Privacy Professionals (IAPP) will celebrate 10 years this Tuesday, March 16. In connection with that anniversary, the IAPP is releasing a whitepaper, "A Call For Agility: The Next-Generation Privacy Professional," tomorrow, March 15. Monday morning you can find the whitepaper here. I am honored that the IAPP has given me the opportunity to read and blog about the whitepaper in advance of its official release. Where exactly is privacy going in today's environment? What is the role of the privacy professional over the next 10 years? And, a lot of people I know and love (you know who you are) would ask, what in the world is a privacy professional anyway?
Of late, I have found myself reiterating, and getting a lot of positive feedback for, the following proposition: with data (massive amounts of it) as the new currency, the explosion in outsourcing to "trusted partners," and the growth of legal risks associated with an ever-expanding body of privacy and data security regulation, the role for professionals who understand privacy is becoming increasingly important. Further, such professionals are uniquely positioned to bring together various key stakeholders in an organization, including Information Security, Legal, IT, and various business units. Why? Because privacy professionals are, by virtue of what they do, multidisciplinary. And the growing opportunities for such professionals are inextricably intertwined with that quality. The IAPP has summed this up succinctly, and eloquently in its whitepaper, as follows:
The next 10 years will see more types of data collected from more people, and more privacy laws in more places. A deepening and broadening of data protection regulations in the industrialized world will spread to emerging markets and place a higher premium on legal and compliance acumen. In addition, an expansion of health information networks, smart grid networks and cloud computing platforms will make industry and technology expertise a more indispensable part of practicing privacy.
. . . the privacy professional’s success in the next decade will demand greater adaptability and most importantly, agility. The agile privacy professional is the next-generation privacy professional: an expert practitioner who is keenly attuned to cultural and regional distinctions as these continue to grow in an increasingly interconnected data economy; who can migrate and adapt to different roles within an organization and offer value at each; who exhibits both comfort and grasp of legal/compliance and technical disciplines; and who instills direction and leadership of privacy management within the organization.
The following analysis and discussion of the IAPP's whitepaper is completely my own. I think that the paper raises some incredibly important points about the need for privacy professionals to lead the way for more effective information governance. As an outside lawyer (with my own unique perspective), my key takeaway is the following -- privacy professionals must understand law AND technology, and must facilitate dialogue between those two disciplines and as between those disciplines, on the one hand, and the business side, on the other.
The importance of a "privacy professional" understanding both legal and technical disciplines cannot be overstated:
The central role of regulatory and IT drivers shaping the privacy profession almost ensures an ongoing need for privacy professionals to be conversant in not one, but both of these disciplines.
Regulation and "Reasonable Security"
I believe this is largely due to what the IAPP describes in the whitepaper as the "Second Wave of Regulation," which began in approximately 2003 with California's landmark data breach notification legislation, Civil Code section 1798.82 (for private entities), often called SB 1386. On the heels of that came 44 additional such state laws, DC, Puerto Rico, the Virgin Islands, and now some similar European legislation, as discussed in the whitepaper. And, with the light now shining on security risks and failures within private organizations, additional security standards and legislation began to emerge - most notably, as highlighted by the IAPP, the Payment Card Industry (PCI) Data Security Standard (DSS) and laws such as Nevada's (SB 227) that incorporate that Standard. For more on that, see Dave's posts here, here and here. Further, as noted in the whitepaper,
A number of factors have spurred North American (and particularly American) organizations to dedicate more resources to privacy process improvement: most notably, PCI DSS enforcement, FTC enforcement, and data breach notification.
Not discussed in the IAPP whitepaper in depth, but just as important, a number of states have crafted legislation designed to require "reasonable" security or safeguards to address security risks in a more proactive fashion, as opposed to the traditional reactive breach notification approach. Massachusetts, Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05, is of course the most recent, most detailed, and most well known, but many states require the same "reasonable security" (sometimes for all personal information, sometimes for just Social Security numbers), including, but not limited to, California (Civ. Code §§ 1798.81, 1798.81.5, and 1798.85), Arkansas (Code Ann. §4-110-104(b)), Colorado (Rev. Stat. Ann. §6-1-713), Connecticut (HB 5658), Maryland (Com. Law Code Ann. § 14-3503), Nevada, as mentioned above (Rev. Stat. § 603A.210 and SB 227), Oregon (Rev. Stat. § 646A.622), Rhode Island (Stat. § 11-49.2-2), Texas (Bus. & Com. Code Ann §§ 48.102(a) and 521.001, .052, .151) Utah (Code Ann. § 13-44-201), and Washington (Rev. Code Ann. §19.215.020 to .030). There are more, I could go on.
What in the world is "reasonable security"? A privacy professional who understands the law and traditional notions of negligence, various concepts of privacy (Fair Information Practice Principles, etc.) as embodied in different standards and legislation around the world (from EU to Australia), and the evolution of information security (as a technical matter) is ideally positioned to help assess what "reasonable security" means and determine what will be compliant, what will be legally defensible, what will be best practice, and what will be just good business. And such a privacy professional can facilitate discussions among stakeholders that speak somewhat different languages in this regard to reach solutions that are acceptable to all involved.
From Privacy to Information Governance
As a lawyer, I am also extraordinarily pleased to see, in the IAPP's whitepaper, a reference to the new ediscovery rules that came into play in the latter half of the 2000s, most notably the amendments to the Federal Rules of Civil Procedure in 2006. What does privacy have to do with ediscovery? Everything. As noted in the IAPP's whitepaper, the amended rules "increased the need for organizations to conduct data inventories and implement data-retention policies." How do you protect sensitive data (personally identifiable information, trade secrets, IP, etc.)? You figure out where it is first. And thus, as the IAPP points out, we start to see the "privacy" role evolve into an information governance role.
Speaking of information governance, let's return to technology. States the IAPP: cloud computing will set the pace for the next decade:
One of the clear directions of technology in the past 10 years as it pertains to personal data has been more—more types of data collected from more people in more ways, and shared with more entities. The emergence of cloud computing—essentially a new computing paradigm in which data is stored off-premises and by a range of third parties—sets the pace for the next decade. Short of a wholesale social movement to opt out of information technology and “go dark,” the conveniences and commercial benefits of more data collection and sharing seem to point in the direction of more. People will not 'go dark,' we estimate, because the utility of sharing information will continue to well exceed the risks of doing so.
Thus, the IAPP stresses the need for agility and identifies five strategies for action:
(1) Redefine the privacy role [information governance]; (2) Rotate through departments/business units; (3) Develop multi-cultural literacy; (4) Understand legal and technical disciplines; and, (5) Instill direction and leadership.
Bottom line? Proactive, multidisciplinary solutions to information governance that incorporate information technology savvy and that address compliance, legal defensibility, and best practices, are now and will become increasingly crucial to any organization that handles sensitive data. Privacy professionals are well positioned to lead those efforts. Congratulations to the IAPP on its 10th anniversary! I look forward to the next 10 years.
EU Adopts New Standard Contract Clauses for Foreign Processors
Last Friday, the European Commission adopted new "controller-processor" standard contractual clauses ("SCCs" or "model contract") to protect personal data transferred from Europe to a data processor located outside the EU/ EEA. Existing contractual arrangements are grandfathered, but any new contracts with data processors must include the new version of the SCCs.
The principal change from the 2002 controller-processor SCCs is that processing contractors are now obliged to obtain prior written consent from the customer before subcontracting any of the processing, and the subcontractor must be contractually bound to the same obligations that apply to the contractor.
Article 25 of the EU Data Protection Directive directs member states to prohibit the transfer of personal data to countries lacking similar legal protections, unless one of several limited exceptions applies or approved safeguards are in place. EU-approved standard contract clauses between the data "exporter" and data "importer" are a common means of legitimizing data transfers to locations outside the European Economic Area -- the European Union plus Iceland, Liechtenstein, and Norway. (SCCs are not used where the transfers are to a US company that participates in the international Safe Harbor program, or to a company relying on informed consent, nationally approved Binding Corporate Rules, or one of the other "derogations" under Article 26 of the Directive.)
The European Commission has approved two alternative sets of SCCs for use in transferring personal data to a data "controller" outside the EEA, and in 2002 the Commission approved a set of SCCs to be used when transferring data to a "processor." The distinction between controllers and processors is not always clear in practice, but the basic concept is that a controller makes decisions about what data to collect and how to use it, while a processor merely performs operations on data only on behalf of the controller and according to its instructions. Business process outsourcing in a non-EEA country such as the United States or India is a common context for using SCCs to protect employee and customer information or other personal data furnished by a European company.
The concern addressed in the new controller-processor SCCs is that processors today often subcontract some processing, storage, and technical support functions to third parties. This is particulary common in cloud computing, where several entities might be involved in handling and storing the data. The new SCCs are designed to ensure that the company that remains responsible as the data controller in Europe is informed about any proposed subcontracting, and that all parties handling the data are subject to the same obligations of confidentiality and security.
The full text of the decision and the new SCCs are not yet posted on the Commission's website. (They will ultimately appear on the "Model Contracts" page.) A Commission spokesman described the decision on Friday, however, as follows:
"According to the newly adopted Decision, where a data importer (processor) intends to subcontract any of its processing operations performed on behalf of the EU data exporter (controller), it must first obtain the prior written consent of the data exporter. The written contract will impose the same obligations on the sub-processor as those imposed on the data importer under the standard contractual clauses."
The Commission reportedly will not require companies with existing controller-processor SCCs to replace those agreements with the new SCCs. New processing agreements, however, must use the new set of controller-processor SCCs if they are to serve as a legal basis for data transfers outside the EEA.
Legal Implications of Cloud Computing -- Part One (the Basics and Framing the Issues)
I had the pleasure of hearing an excellent presentation by Tanya Forsheit on the legal issues arising out of cloud computing during the ABA Information Security Committee's recent meeting (at the end of July) in Chicago. The presentation resulted in a spirited debate between several attorneys in the crowd. The conversation spilled over into happy hour and became even more interesting. The end result: my previous misunderstanding of cloud computing as "just outsourcing" was corrected, and now I have a better appreciation of what "the cloud" is and the legal issues cloud computing raises.
Bottom line: this is not your father's outsourcing relationship, and trying to protect clients with contracts may be very difficult or impossible unless the cloud computing community begins to build standards and processes to create trust. This post is not for my tech/security friends, it is for the attorneys out there, especially the general counsel and transactional attorneys who draft terms for tech contracts (e.g. outsourcing contracts, ASP contracts, software licenses, etc.). So tech friends, please cut me some slack as I completely mangle proper terminology in order to try to explain this in plain English (and of course if I get something wrong, shoot me a comment or email so I can correct -- we attorneys need you on this one).
One final note to the attorneys out there: there is going to be incredible financial pressure on organizations to take advantage of the pricing and efficiency of cloud computing and if attorneys fail to understand the issues ahead of time there is a serious risk of getting "bulldozed" into cloud computing arrangements without time or resources to address some serious legal issues that are implicated.
(P.S. Special thanks to Tanya Forsheit, John Tomaszewski, Karen Worstell and Peter McLaughlin for the insight and debate).
What is Cloud Computing?
How about a picture to start off:
The National Institute of Standards and Technology (NIST) has provided a definition of cloud computing that is helpful, but not really in plain English. Moreover, it does not really help to illuminate the legal aspects of cloud computing. So here is my attempt.
From a user's perspective, when utilizing cloud computing, rather than data processing and storage occurring on an individual's laptop or desktop computer (or a company's internal network), it happens on computing platforms run by third parties (such as Google, Yahoo, Amazon, etc). Services that may be available through those cloud platforms include data storage (e.g., infrastructure as a service (IaaS)), application development/deployment (platform as a service (PaaS) and software hosting (e.g., software as a service (SaaS)). So rather than store data on an organization's own computer network, if purchasing IaaS, the data is stored on servers "in the cloud" and available on demand by the organization. Rather than installing and maintaining data/software on a network or desktop computer, the data/application is hosted on computers in the cloud and available on demand.
This can result in cost savings because companies using cloud services need not purchase their own infrastructure or software, need not hire people to maintain it, and need not regularly upgrade when necessary. In addition, cloud computing is highly and cheaply scalable. So rather than maintaining an over-capacity of computing power (e.g. extra servers only used for the holiday e-commerce rush) companies can maintain variable capacity levels to suit their immediate needs using the cloud. Moreover, utilizing the cloud will allow companies to take advantage of the best and latest technology since they will not have to disassemble and rebuild their entire IT infrastructure in order to upgrade. For more information on some of the technical aspects of cloud computing, please check out this white paper put out by Sun Microsystems.
That is all nice, and fairly understandable, but what IS the cloud? Right. Some analogies are in order. Think of airlines and how they sell seats. Sometimes seats are still available for a flight as the departure date gets closer and closer. From the airline's point of view it is better to sell those seats for a lower price then to let the plane take off with empty seats. As long as can sell the seat for a price that exceeds the cost of taking a passenger. Bring this same rationale to the e-commerce context. Amazon.com has huge server farms that can handle millions of transactions. During the 3 month holiday period its servers and processing abilities may be taxed to their limits because of high online sales volumes. Then of course, February rolls around and all those servers that hummed during the holiday season suddenly lay dormant. Yet Amazon still needs to maintain them so it can be ready for the next holiday rush. What to do? Rather than let that processing capacity go unused, why not sell it to third parties? Allow an application service provider to host its application on Amazon's computers for a price. Allow an organization to store and process data on Amazon's servers. In fact, since any additional funds received (above maintenance costs) are "gravy" perhaps Amazon could charge a lower price than other companies that provide capacity. This rationale can serve as a building block for companies to get into cloud computing.
The second rationale/building block is economies of scale. Going beyond the Amazon rationale of attempting to sell excess capacity that it had to have anyway, savvy IT companies began to realize that they could sell processing capacity as a business. In fact, computing processing prices have continued to drop more or less as predicted by Gordon Bell's corollary to Moore's Law. Beyond that, companies like Google have begun to realize that if they build massive server farms they can bring down their per unit of price for processing power even further. Moreover, with highly evolved technologies they realized they could create additional processing efficiencies and bring down the per unit price of processing even further. Based on these economies of scale, cloud platforms realized they could provide processing capabilities much cheaper than companies that did it all "in house."
Terrific, so how is this any different than a typical outsourcing relationship? Why is this a Cloud? One of the key differences between a traditional outsourcing relationship and cloud computing is where the data resides or is processed. For example, in the traditional outsourcing situation, a company looking to offload some of its data storage would create a dedicated data center and then sell the storage capacity to its clients. The data center might be in another country, but for the most part the client knew where its data was going and where it would be stored and processed.
Enter the cloud. In a cloud environment, geography can lose all meaning. Cloud platforms may not be able to tell "where" data is at any given point in time. Data may be dispersed across and stored in multiple data centers all over the world. In fact, use of a cloud platform can result in multiple copies of data being stored in different locations. This is true even for a "private cloud" that is essentially run by a single entity. What this also means is that data in the cloud is often transferred across multiple borders, which (as discussed below) can have significant legal implications.
It gets more complicated when you begin talking about the "public cloud" or "hybrid cloud" and interactions between cloud providers. In some public cloud set ups, the players in the cloud are essentially trading processing and storage capacity. So if Google has excess capacity at a given point and time, and Amazon or Amazon's clients need more capacity than Amazon can provide, it can buy some capacity from Google. Some refer to this as "surge computing." The analogy here is electricity companies and providers. In warmer climates during peak electricity demand times, the local power company may not be able to generate enough electricity to meet increased demand, and will have to purchase it from other companies who are not at full capacity. Under the cloud arrangement, data is like electricity, essentially fungible and able to be moved instantaneously to available servers and computation resources. In fact, cloud computing providers will begin charging for the cloud the same way electricity is charged: based on units of use (in this case computing cycles). So in the cloud, while the data may have started out on an Amazon server in the European Union, when handed off to Google it may be processed in the United States, China or some other country where Google has servers (in fact countries like China and India are very keen to get into this business since they think they can provide these services for even cheaper). Moreover, the parts of the data may be copied and sent for processing to other participants in the cloud. To the Amazon user all of this movement of data and processing across multiple borders involving multiple entities and even multiple copies of data is invisible. The Amazon user simply gets back the answer it expected when it began the processing transaction.
What are the legal issues?
Transborder Data Flow Triggering Legal Obligations in Multiple Jurisdictions. This sharing and transfer of data within the cloud, the inability for anybody to easily say where the data is or has been, is the key problem that creates legal issues. An obvious problem is transborder data flow. For example under the EU Data Protection Directive, unless they take certain steps, organizations are prohibited from transferring personal information to countries that do not provide the same level of protection with respect to personal information of EU residents (the United States is one such country). A company that does its processing in the cloud may be violating EU law if data goes to servers outside of the EU to prohibited countries. Unfortunately, contracts may not be too helpful because cloud providers will not be in any position to make any contractual promises to their clients because in many cases they cannot say which countries data will be transferred to or from. So how can companies seeking the efficiency and cost savings of the cloud utilize it if, by its very nature, it leads to potential legal compliance nightmares?
"Reasonable Security" Under the Law. Then there is the issue of "reasonable security" in the cloud computing context, and potential liability arising out of security breaches in the cloud. Generally speaking if a company outsources the handling of personal information to another company they may have some responsibility to make sure the outsourcer has some level of reasonable security to protect personal and confidential information. What happens when the could is utilized? Service providers using the cloud platform essentially rely on the security of each of the cloud participants receiving personal information. That could be name brand companies like Google who are likely to have some level of adequate security, but it could also be lesser players trying to engage in business as cheaply as possible and not implementing rigorous controls. The bottom line again is that the organization seeking to do business in the cloud has no way to even perform a due diligence of "the cloud" to ensure that adequate security is in place. Moreover, cloud companies and service providers that contract directly with such companies are not likely to make any contractual promises around security since they ultimately don't control it (or even know how good or bad it is within the cloud). Ultimately, the legal question is, what liability does a company face when there has been a security breach in the cloud that has resulted in the theft or harm of valuable or protected data?
Electronic evidence/e-discovery. Utilizing the cloud can be problematic in the litigation context. First off, when litigation ensues and a litigation hold is initiated, the organization will have to deal with a third party cloud provider in order to get at the information relevant to the litigation. It may not be easy for that provider to actually preserve the data that is needed for several reasons. For example, an organization may be using a third party software provider that itself utilizes the a cloud platform. The data subject to the litigation hold therefore may actually reside in the cloud and may not be readily accessible/preserved by the software provider. This could complicate gathering electronic evidence and responding to e-Discovery requests. Moreover, it could lead to spoliation of evidence. In addition, considering that multiple copies of data may be created, stored, recompiled, dispersed, reassembled and reused, the idea of what constitutes a "record" or a "document" for evidentiary purposes may be difficult to grapple with in the cloud.
What can lawyers do to address these issues?
Ultimately this is the big question. Can the law wrap its head around cloud computing (when frankly, the cloud computing industry itself is having difficulty defining key components of the business)? The first area to explore are contractual arrangements. Lawyers have been involved in outsourcing transactions for sometime, and have been able to address issues of relative risk between the parties. However, contracting may be much more difficult in the cloud environment because the players may not be in a position to make certain promises, and additional duties/obligations may destroy the cheap pricing model for cloud computing. In part two of this series, we dive more deeply into the legal issues around cloud computing and the necessary involvement of lawyers in this context with respect to contractual arrangements.
