Thoughts from the RSA Conference
As the partners of InfoLawGroup make our way through the sensory overload of the RSA Conference this week, I am reminded (and feel guilty) that it has been a while since I posted here. I have good excuses - have simply been too busy with work - but after spending several days in the thought-provoking environment that is RSA, I had to break down and write something. A few observations, from a lawyer's perspective, based on some pervasive themes:
- We all need to work together, and we can. Legal, Information Security, Privacy, Compliance, IT, and the affected business units. Now more than ever, it is essential that ALL the stakeholders join forces, as early as possible, to address security and privacy risks, assess and vet business deals, and put in place appropriate procedures - RFPs, due diligence, contract negotiation - to address the risks.
- Cloud, cloud, cloud, yada, yada, yada. Hold up - the technology is not new - but usage and the business model have changed dramatically. I have been having this argument with my information security and technology friends for months. OK, I get it. "Cloud" technology in some form or another has been around for 30 or 40 years. What is new is the massive scale, availability and changes in usage and the business model - in part driven by the economics. Guess what? Those business model changes make the legal risks even more pervasive. Going back to (1) above, all of the stakeholders need to be in the room (or on the phone or videoconference) discussing the issues BEFORE the decision is made to enter into a cloud arrangement. ANY cloud arrangement. Not after the RFP is issued. Not after IS does its due diligence. Not after the contract negotiations have begun. And not after the contract is inked. The same due diligence and attention to risks that would apply in a traditional outsourcing/offshoring relationship must be applied here, too. The cost savings are illusory if the short-term and/or long-term risks are significant. Think about the kind of data at issue. What are the risks? Evidence preservation, data security, breach response, enforcement rights, indemnification. And before we even get to those - can the data be transferred across borders in the first place? Think about it early. And then talk about it before decisions are made.
More after the jump.
Continue Reading...The Curious Case of EMI v. Comerica: A Bellwether on the Issue of "Reasonable Security"?
Security breaches in the online banking world continue to yield interesting lawsuits (you can read about three others in this post). The latest online banking lawsuit filed by Experi-Metal Inc. (“EMI”) against Comerica (the “EMI Lawsuit”) provides some new wrinkles that could further illuminate the boundaries of “reasonable security” under the law. Brian Krebs has a good article summarizing the case. In addition, bankinfosecurity.com has a recent article on this matter (in which yours truly was quoted). In this post we take a look at the EMI Lawsuit, consider some legal questions that the case raises, and analyze how it might impact the question of what constitutes “reasonable security” under the law.
Continue Reading...The Breach Notification Obligations in the Data Accountability and Trust Act
The Information Law Group has been following various Federal data security bills as they wind their way through the House and Senate. In December 2009, the Information Law Group commented on the passage of the Data Accountability and Trust Act ("DATA") by the House. I was recently asked by Data Protection Law and Policy (an excellent publication out of the UK focusing on data security and privacy issues) to take a closer look at the data breach obligations of the current version of DATA. The end result was my article entitled: "Potential changes to the US breach notice risk landscape".
Continue Reading...Developing an Information Security and Privacy Schedule for Service Provider Transactions (Part Two)
In Part One of this blog series, we looked at the proactive nature of a data security and privacy schedule ("Schedule"), and considered the compliance function of a Schedule. Part Two of this series discusses security incident response contract terms that should be considered for a Schedule. In addition, we look at more traditional "risk of loss" contract terms and how data security and privacy risks impact those terms.
Continue Reading...Developing an Information Security and Privacy Schedule for Service Provider Transactions
It is a very interesting time for information security and privacy lawyers. Information technology and the processing, storage and transmitting of sensitive and personal information is ubiquitous. At the same time (and likely as a result of this ubiquity) the legal risk and regulatory compliance environment poses increased threats and potential for significant liability. Finally, whether through cloud computing providers or traditional outsourcing of information technology functions (e.g. ASP, hosting and storage), to stay competitive and efficient, companies of all shapes and sizes are outsourcing their information technology functions to third party service providers. It is likely that adoption of these practices will increase at an increasingly faster rate.
This reality poses significant information security, privacy and legal challenges. Internal security and privacy professionals find themselves ceding control of significant decisions to third parties (“Service Providers”) concerning the implementation, maintenance, enhancement and enforcement of information security and privacy measures. Unfortunately, an organization’s legal risk and compliance obligations do not follow – in most cases they remain with the organization that chooses to outsource (the “Customer”). Of course on the Service Provider side, the main motivation is as follows: (1) secure revenue; and (2) void liability. These motivations often counter-oppose the goals of the company seeking to outsource.
These tensions play themselves out during the contract negotiations with Service Providers. It is at this juncture that the role of the Customer’s information security and privacy attorney, working closely with the Customer’s internal security and privacy professions, becomes increasingly important. To navigate these waters legal experience in the areas of data security and privacy law, contract drafting, litigation risk and negotiation tactics is crucial. However, as important, is a solid understanding of technology and substantive security and privacy matters, and how they relate to and interplay with the law. The net result is intense negotiations around the data security and privacy contract terms, which are often in the form of an information security and privacy schedule or exhibit (“InfoSec-Privacy Schedule” or “Schedule”).
In this two-part post, we explore the function and purpose of these Schedules and discuss how they might be drafted and used. Part One discusses the proactive nature of a Schedule and how it should be viewed as compliance document. Part Two details security incident response provisions that should be considered in a Schedule, and contract terms allocating risk of loss between the Customer and Service Provider.
Continue Reading...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.
Continue Reading...Data Integrity and Evidence in the Cloud
How does cloud computing affect the risks of lost, incomplete, or altered data? Often, the discussion of this question focuses on the security risks in transmitting data over public networks and storing it in dispersed facilities, sometimes in the control of diverse entities. Less often recognized is the fact that cloud computing, if not properly implemented, may jeopardize data integrity simply in the way that transactions are entered and recorded. Questionable data integrity has legal as well as operational consequences, and it should be taken into account in due diligence, contracting, and reference to standards in cloud computing solutions.
Continue Reading...Celebrating Data Privacy from A to Z
In honor of Data Privacy Day and its spirit of education, I thought it might be appropriate (and fun) to celebrate some (but certainly not all) of the A, B, Cs of Data Privacy. Would love to see your contributions, too!
A is for Advance Encryption Standard or AES, approved by NIST. Are you encrypting transmissions of sensitive data and portable storage devices? See more below.
B is for Breach Notification Laws, including the 45 state laws, District of Columbia, Puerto Rico, Virgin Islands, HITECH Act, and international regulations. (Also Behavioral Advertising.)
C is for . . . what to Choose? -- Contracts? Cloud Computing? How about California - the first state to enact a breach notification law, California Civil Code sections 1798.29, 1798.82 et seq. (SB 1386), and the first state Office of Privacy Protection
D is for Data Protection Authorities in the European Union
E is for the EU Data Protection Directive. Oh, and Encryption, of course. See above and below.
F is for Financial Institutions, regulated by (wait for it . . . after the jump . . .)
Continue Reading...Issuing Banks File Class Action Suit Against Acquiring Banks in Heartland Breach Matter
In an interesting development, a handful of issuing banks impacted by the Heartland breach have filed a class action lawsuit against two acquiring banks related to Heartland Payment Systems. According to this article, the issuing banks are unhappy with Heartland's proposed settlement with Visa. This appears and to be an attempted end-run around the proposed $60 million settlement with Visa. It also may demonstrate that issuing banks are not satisfied with the dispute resolution mechanisms under the Visa Operating Regulations (the Account Data Compromise Recovery process estimated the loss at $140 million, yet the settlement was for only $60 million), and their ability to be made whole under those mechanisms. We will have more analysis of the complaint at a later day. In light of the relative lack of success issuing banks have had in these types of cases, it will be very interesting to analyze the legal theories employed by the issuing banks and track the progress of this matter.
Is Your Organization's Red Flags Rule Identity Theft Prevention Program Ready for Primetime?
As our readers know, the FTC, after four extensions of the deadline, currently intends to begin enforcing the Red Flags Rule with respect to organizations subject to its jurisdiction on June 1, 2010. In the meantime, the Red Flags Rule remains in effect as to all financial institutions and creditors (and has been subject to enforcement by the banking regulators since November 1, 2008). Although a recent decision of the United States District Court for the District of Columbia, ABA v. FTC, brought lawyers outside the scope of the Rule, the Rule remains broad and covers a wide range of entities as "creditors." Creditors subject to the FTC's jurisdiction need to have their written Red Flags Rule Identity Theft Prevention Programs prepared, approved by the Board, and implemented by June 1. For more on the history and the requirements of the Rule, see my recent article, "The FACTA Red Flags Rule: A Primer," published in Bloomberg Law Reports – Risk & Compliance, reproduced here with the permission of Bloomberg. Read on . . .
