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

Background

This matter revolves around a couple sections of Michigan’s version of the Uniform Commercial Code, in particular MCLA 440.4702(2), which provides in relevant part:

(2) If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer. The bank is not required to follow an instruction that violates a written agreement with the customer or notice of which is not received at a time and in a manner affording the bank a reasonable opportunity to act on it before the payment order is accepted. (emphasis supplied)

MCLA 440.4702(3) explains how “commercial reasonableness” is to be determined under MCLA 440.4702(2):

(3) Commercial reasonableness of a security procedure is a question of law to be determined by considering the wishes of the customer expressed to the bank, the circumstances of the customer known to the bank, including the size, type, and frequency of payment orders normally issued by the customer to the bank, alternative security procedures offered to the customer, and security procedures in general use by customers and receiving banks similarly situated. A security procedure is deemed to be commercially reasonable if (i) the security procedure was chosen by the customer after the bank offered, and the customer refused, a security procedure that was commercially reasonable for that customer, and (ii) the customer expressly agreed in writing to be bound by any payment order, whether or not authorized, issued in its name and accepted by the bank in compliance with the security procedure chosen by the customer. (emphasis supplied).

Finally, the definition of “security procedure” under MCLA 440.4701 is relevant in this context:

“Security procedure” means a procedure established by agreement of a customer and a receiving bank for the purpose of: (i) verifying that a payment order or communication amending or cancelling a payment order is that of the customer, or (ii) detecting error in the transmission of a the content of the payment order or communication. (emphasis supplied)

In short, what these laws do is assign the risk of loss with respect to payment orders that may not have been actually initiated by the customer. Even if a payment order is initiated by a criminal that payment order will be deemed effective under the law as long as the requirements of MCLA 440.4702(2) are satisfied. If those requirements are satisfied, the losses may fall on the banking customer rather than the bank (at least with respect to this particular law – there may be other theories of liability that could apply).

Comerica’s Motion for Summary Judgment

The following summarizes the main arguments put forth by Comerica in its motion for summary judgment ("MSJ").

• Comerica’s security procedure was commercially reasonable as a matter of law.

Comerica had established two-factor authentication using RSA secure token technology for its online banking. In order to access its online banking account EMI was required to input a user ID, password and PIN number generated from the RSA token(s) posesed by EMI (the PIN is randomly generated and changed every sixty seconds). Comerica maintains that EMI agreed that this security scheme was commercially reasonable. Support for this contention is found in the NetVision Wire Transfer Agreement entered into by EMI, which provided:

Customer [EMI] agrees that the selected Security Procedures are commercially reasonable for the type of entries which Customer may transmit to Bank, and Customer shall hold Bank harmless for any action taken in reliance upon the use of the Security Procedures.

Comerica also argues that 2-factor authentication is the same security it uses for its high volume wire transfer customers (i.e suggesting that it was providing more security than would normally be afforded to a low volume customer like EMI).

Key to its argument is the language of MCLA 440.4702(3)(i) italicized and bolded above. Comerica argues that it offered EMI the ability to require up to two users to confirm every wire transfer payment order made by an EMI employee (the evidence for this offer is an affidavit from a Comerica VP indicating that she told EMI’s online account administrator about this security option). Following the relevant language in MCLA 440.4702(3), Comerica argues that EMI was offered this security option, but refused it, and therefore the two-factor authentication that EMI used is automatically “deemed” commercially reasonable.

• Comerica followed the security procedure EMI agreed to use and acted in good faith

Comerica argues that there is no evidence suggesting that it failed to follow its security procedures consistent with MCLA 440.4702(3)(ii), and it maintains that it acted in good faith accepting the fraudulent payment orders. Specifically, Comerica indicates it followed the two-factor authentic procedure that had been established. It also uses this argument to support its position that it acted in good faith. In addition, Comerica points to the assistance it provided EMI in recovering a large portion of the transferred funds as evidence of its good faith.

• EMI admitted it was the source of the security breach

Comerica also argues that EMI was responsible for keeping passwords and PINs confidential, and that its actions resulted in the breach when it provided the information to the phishing attacker. To support this argument, Comerica sites a comment to UCC section 4A-203 which states:

The burden on the customer is to supervise its employees to assure compliance with the security procedure and to safeguard confidential security information and access to transmitting facilities so the security procedure cannot be breached.

EMI’s Response to Comerica’s Motion for Summary Judgment

EMI sets forth several arguments as to why it believes that summary judgment is unwarranted. As a reminder, the general rule is that motion for summary judgments should be granted only if there is no genuine issue as to any material fact (such that judgment is appropriate as a matter of law). Focusing on MCLA 440.4702(2) and the definition of “security procedure” under MCLA 440.4701, EMI sets forth four arguments contending that genuine issues of material fact do exist (making summary judgment inappropriate).

• EMI never agreed to the RSA Token security procedures, therefore they are not “security procedures” as defined under MCLA 440.4701

MCLA 440.4702(2) only applies to “security procedures” as defined under MCLA 440.4701. EMI contends that it never agreed to the RSA token security procedures, and therefore MCLA 440.4702(2) is not applicable.

This argument rests on the allegation by EMI that Comerica switched wire transfer services, and EMI never agreed to the security procedures for the new services. EMI argues that it had entered into an agreement for NetVision Wire Transfer Services in November 2003. As mentioned in Comerica’s MSJ, EMI signed the agreement for NetVision services that included a specific agreement by EMI that Comerica was using commercially reasonable security. The authentication security for NetVision was a “digital certificate” process.

However, in May 2008 Comerica apparently changed to “TMC Web wire transfer services,” which used the RSA token security. EMI contends that it never entered into a written agreement for the new TMC Web services, never agreed to the RSA token security, and never agreed that such security was commercially reasonable. EMI also argues that it was not a signatory to various other documents referenced by Comerica, including an online banking user guide and Comerica’s Treasury Management Services Master Agreement (both of which provided more information concerning Comerica's security procedures).

Finally, EMI disputes Comerica’s contention that EMI’s use of wire transfer services constitutes acceptance of the RSA token security procedures. According to EMI, it actually never sent a wire transfer using the TMC Web wire service that utilized the RSA token security, and therefore it never accepted this security procedure. Since the RSA token security was never “agreed to” by EMI, it contends that MCLA 440.4702(2) does not apply or shift the risk of loss to EMI, and that Comerica is responsible.

• Genuine issues of material fact exist as to whether Comerica’s RSA token security was “commercially reasonable”

EMI disputes Comerica’s contention that the RSA token security should be deemed reasonable under MCLA 440.4702(3). As summarized above, under that section if a customer refuses a security procedure that was commercially reasonable, but the customer agrees to another security procedure, the latter procedure is deemed commercially reasonable. This is basically a timing argument supported by dueling affidavits.

EMI claims that, at the time the TMC Web wire service was initiated, it was never advised that it could require approval from two authorized users prior to wire transfer, nor did Comerica offer additional security procedure options in connection with TMC Web services. This argument also rests on the prior EMI argument that it never entered into an agreement concerning the security of the TMC Web wire services in the first instance.

EMI then takes on the substance of "commercially reasonable security" using expert witness testimony. EMI’s expert contends that secure token technology was known to be lacking in any reasonable defense to a “man-in-the-middle” phishing attack. EMI’s expert opines that secure token technology has been unacceptable for banking logins since 2003. EMI’s expert also argues that Comerica’s particular implementation of this security was flawed based on prior practices of Comerica. In particular, with respect to the Netvision wire services that predated the TMC web wire services, Comerica allegedly regularly sent EMI unsolicited emails that lead to links requesting confidential login information. Essentially Comerica's prior practice caused EMI personnel to be off guard when the phishing attack came in.

EMI also takes issues with the warnings that Comerica sent out concerning phishing attacks. It points to Comerica’s April 28, 2008 communication in which Comerica indicated that it would never ask for confidential information in an email. EMI contends that the very next day it received an email from Comerica asking EMI to provide confidential login information.

Finally, EMI argues that the RSA token based security used by Comerica was not commercially reasonable because Comerica did not also implement security protection related to transaction verification and verifying wire transfers initiated after the initial login. In other words, EMI contends that an online banking system that allows unfettered wire transfers after a single successful login is not commercially reasonable. Had the token generated PIN been required for each wire transfer (e.g. the RSA token generates a new random number every sixty seconds), then the bad guys would have been stopped after the first fraudulent wire transfer (instead of being able to do 93 separate wire transfers for a total of $1.9 million).

• Genuine issues of material fact exist as to whether Comerica accepted payment orders in good faith and in compliance with the security procedures

EMI first argues that Comerica failed to accept the payment orders in good faith because it allowed 47 wire transfers to happen within a few hours even though EMI had only made two wire transfers in the prior two years. Moreover, EMI argues that Comerica’s lack of good faith is evidenced because it allowed 46 wire transfers to go through after EMI notified Comerica that EMI had not initiated the transfers. EMI also maintains that the failure to implement a simple fraud scoring system or fraud monitoring program to stop these types of wire transfers was evidence of a lack of good faith.

Comerica’s Reply to EMI’s Response

Comerica also filed a reply brief to address the arguments set forth in EMI’s response to the MSJ. This section summarizes Comerica’s arguments.

• The NetVision and TM Connect Web wire services were the same service governed by the 2003 NetVision contract

Comerica attempts to nullify EMI’s argument that it never entered into an agreement for security procedures related to TM Connect Web wire services. It contends that NetVision and TM Connect are the same systems. Comerica argues it simply changed the name of its online banking system. Comerica argues that the “Services” governed by the 2003 NetVision contract were the same and that all of EMI’s online transactions were subject to that contract. Comerica notes that the NetVision contract incorporates Comerica’s Treasury Management Services Master Agreement and a related user guide which Comerica uses to buttress its MSJ.

The NetVision contract also allows Comerica to update its security procedures, and indicates that after notice is provided by Comerica to EMI, EMI’s use of the services constitutes acceptance of the new security procedure. While EMI did not use wire transfer services until after NetVision changed its name to TM Connect Web, it had received wires from outside parties. Comerica contends that EMI’s continued receipt of wire transfers it its account constitutes use of the services and acceptance of the RSA token based security procedures for outgoing wire transfers. Of course EMI's acceptance is crucial if Comerica wants to rely on the risk-transfer mechanism set forth in MCLA 440.4702(2).

• Under MCLA 440.4702(3) the issue of the “commercial reasonableness” of a security procedure is a question of law, not fact

On this issue, Comerica points to the explicit language of MCLA 440.4702(3) which indicates that “commercial reasonableness of a security procedure is a question of law.” As such the court can decide that issue on a motion for summary judgment. Comerica contends that EMI acknowledged that Comerica’s security procedures were commercially reasonable in the NetVision agreement, making appropriate summary judgment in Comerica's favor.

• Comerica followed its procedures and acted in good faith

Comerica contends that it followed the procedures in place for online banking and denies that other procedures, such as requiring the initiation of wire transfers by phone call, were relevant. It attempts to counter EMI’s arguments concerning good faith by noting that it was not physically possible to stop some of the wire transfers after EMI informed Comerica that those transfers were not authorized. Moreover, Comerica argues that when it was able to stop or recall wire transfers it did so despite not being bound to do so, and ultimately decreased the loss from $1.9 million to $560,000.

Finally Comerica addressed EMI arguments concerning prior Comerica requests for confidential information via email. It argues that those emails did not send the user back to a Comerica website, but rather to a website hosted by their security vendor, Verisign. Secondly, the information that was requested was not online banking login credentials, but rather an ID/PIN sent each year for the sole purpose of renewing EMI’s digital certificate. As such, Comerica’s warning that it would never ask for online banking credentials via email was not untrue as EMI suggested.

Conclusion

These cases always get interesting when a little discovery ensues and the litigants begin digging into the relevant documents and contracts. As you can see, there is a lot going on here that has little do with actual security, and more to do with procedural issues around security acceptance, contracting and the UCC. Nonetheless, on some level the issue of commercially reasonable security will have to be addressed (either by the court on this motion for summary judgment) or later in proceedings by the ultimate trier of fact.

What can be gathered from this case and this MSJ is the importance of contracts in this context, and apparently the importance of contract timing issues and clear indications of “accepting” security procedures related to online banking. While there is a paper trail here with some favorable contract language, the record does look muddied, and this can make it more difficult to win at this stage of litigation.  Had the bank thought it through in more detail it probably could have created a more solid record to back its arguments. For instance, while contracts incorporating other documents that are constantly changing may be efficient, they may lack the same degree of acceptance as compared to requiring a new contract or other document certifying acceptance. Based on the dueling arguments, it is difficult to determine exactly where the court will come down on this motion for summary judgment. I believe that oral arguments are scheduled and thereafter we will get a written opinion from the court. Until then, have fun breaking these documents down and feel free to ask any questions you may have in the comments.

The Allegations

On a general level the EMI Lawsuit involves a basic fact pattern that is similar to several online banking security breach cases: criminals were able to obtain the login credentials of a bank’s business customer and wire transfer large sums of money from the customer’s account (in the EMI lawsuit approximately $560,000 was allegedly wired). Like other online banking cases, the bank in this case (Comerica) did not reimburse EMI for the unauthorized wire transfers, and this lawsuit was eventually filed.

However, the EMI Lawsuit differs in two substantial ways from the online banking cases InfoLawGroup previously reported on. First, unlike the other online banking breach suits, in the EMI Lawsuit, Comerica had implemented (and EMI was using) 2-factor authentication.  In particular, Comerica had implemented a token-based 2-factor system. It appears that Comerica online banking customers where provided with a physical token that generated random numbers at various regular time intervals (e.g. the token number was always changing at regular interval). To utilize online banking, Comerica customers would have to input their username and password as well as the random number showing on their token. Without all three pieces of information, logging into Comerica's online banking would not be possible.

Second, in other the lawsuits, it was not known (or at least unclear from the compliant) how the criminals obtained the banking customer’s online banking credentials. In the EMI Lawsuit, however, the bad guys allegedly obtained EMI’s login credentials through a “phishing attack.”  EMI alleges that one of its employees was tricked into giving those login credentials to the criminals via a spoofed email that purported to be from Comerica. This fake email was allegedly similar to those sent by Comerica to EMI in the past.  Apparently the EMI employee would have provided not only user name and password, but also the random number from the token. The complaint alleges that the thieves were able to conduct about 97 money transfers over a period of approximately 6 ½ hours.

Analysis

This case raises several interesting legal issues. In fact, this case could ultimately illuminate how courts view the scope of a “reasonable security” duty.

Existence and Scope of a “Reasonable Security” Duty.

One of the issues that will be key in this case is whether the bank has a legal duty to prevent these types of phishing attacks. The Shames-Yaekel case has recognized a general duty to protect a customer's online banking accounts. In that case, however, it is unclear how the bad guys obtained the banking customer's online credentials. This case is a little different because phishers were able to trick the customer into volunteering its online banking credentials. Assuming a general duty exists, the question is whether that duty extends to preventing (or reducing the risk of) its customers from being duped by social engineering attacks like phishing.

On that issue, In the EMI Lawsuit (like many of the other online banking lawsuits) the plaintiffs allege that Comerica failed to comply with the “commercially reasonable” security procedure requirement under Michigan’s version of UCC 4A202 (MCLA 440.4702(2)), which provides in relevant part:

(2) If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer. The bank is not required to follow an instruction that violates a written agreement with the customer or notice of which is not received at a time and in a manner affording the bank a reasonable opportunity to act on it before the payment order is accepted.

Subsection (3) explains how “commercial reasonableness” is to be determined under MCLA 440.4702(2):

(3) Commercial reasonableness of a security procedure is a question of law to be determined by considering the wishes of the customer expressed to the bank, the circumstances of the customer known to the bank, including the size, type, and frequency of payment orders normally issued by the customer to the bank, alternative security procedures offered to the customer, and security procedures in general use by customers and receiving banks similarly situated.

Significantly, the existence of a duty and whether Comerica's security procedures were commercially reasonable under MCLA 440.4702(2)) are questions of law, and will be decided by the Court, not a jury. Also of note, some of the plaintiffs’ allegations track to the factors laid out in MCLA 440.4702(3), including allegations that EMI had only performed two wire transfers in the two years prior to the attack.  From a legal standpoint, assuming this case does not settle, since this is a question of law, we could see some actual briefings and a court decision on the issue of reasonable security.

One of the factors that courts look to in order to determine whether a duty exists and its scope is forseeability -- was this attack and/or the resulting harm foreseeable by the bank? In fact, EMI alleges that the secure token technology was one that was already known to fail. On this issue, in general, we know that phishing attacks have been around for awhile. We also know that banks and other organizations have developed approaches to try to prevent these types of attacks. Finally, security professionals tell me that use of phishing to foil two-factor authentication is also a risk that has been discussed in the past. In fact, a similar phishing attempt spoofing a Citibank online banking portal was reported back in 2006.  As such, we will likely see significant arguments from both sides on this issue.

“Reasonableness,” Industry Standards and Tug Boats

This case is interesting because Comerica was actually using 2-factor authentication. In the Shames-Yeakel matter, the court ruled that the failure of the bank to use two-factor authentication as suggested by FFIEC guidance created a question of fact appropriate for a jury. Thus, unlike Shames-Yeakel and other online banking cases, at least with respect to authentication, it appears that Comerica was meeting what some would call the "industry standard.”

However, at this point in time it is possible that a court could rule that 2-factor authentication only serves as a floor, and industry standards for online banking security may have evolved further. In other words, to the extent this “man in the middle” type of attack was known and there are methods for addressing it (especially in the phishing context), the “industry standard” for online banking may be 2-factor authentication PLUS other security measures. Again, plaintiffs allege several other measures they believe should have been in place, including verifying the computer sending the wire transfer instructions, security testing and fraud monitoring programs.  The key issue here will be determining what other similar banks are doing to address this risk.

Moreover, even if 2-factor authentication is considered the “industry standard,” under the law an entire industry may not be implementing reasonable security. The rationale for this was explained by Judge Learned Hand in the famous (for first year law students at least) T.J. Hooper case. In T.J. Hooper, the plaintiffs were shipping two barges full of cargo when the ships encountered a storm. The barges were accompanied by two tugboats owned by the defendants. Unfortunately the tugs were unable to safely pull the barges from the storm and the cargo they carried was lost. The plaintiffs asserted that the defendants were negligent because their tugboats were not equipped with effective radio sets capable of receiving warning of the storm. The defendants argued that they did not owe the plaintiffs a duty to carry such a radio because they were a new technology and it was not a common practice in the tugboat industry to carry such radios. Judge Learned Hand disagreed:

Indeed in most cases reasonable prudence is in fact common prudence, but strictly it is never its measure. A whole calling may have unduly lagged in the adoption of new and available devices. . . . Courts must in the end say what is required. There are precautions so imperative that even their universal disregard will not excuse their omission.

What is the import of this? Under the law for purposes of negligence, a defendant can avoid liability even if a plaintiff suffered harm as long as the defendant did not breach its duty of care. In this context if the bank's security measures where "reasonable" under the law it would not be liable. I think the fact that the bank used 2-factor authentication and can point to the FFIEC guidance will help its cause in this respect. Nonetheless, it is possible the court will rule either that industry standards have evolved further or that the entire online banking industry was “lagging” behind in its reliance on 2-factor authentication. From a legal perspective it will be very interesting to watch the court’s analysis on the issue of reasonableness as it relates to industry standards (and hopefully it will provide more guidance for lawyers and banks going forward).

What about EMI’s fault?

There is a concept in the law called contributory negligence (or comparative negligence). You can read more about it here. Essentially this concept recognizes that a plaintiff (the bank customer in this case) may have also been negligent and may have contributed to the harm it allegedly suffered. In some States if the plaintiff was more than 50% responsible, it would be barred from any recovery. Other states, including Michigan (where the EMI Lawsuit was filed) employ a “modified comparative negligence” approach. Using this approach, if the plaintiff was 60% negligent and the bank 40%, the bank would be responsible for only 40% of the plaintiff's loss. I think there is likely a good argument to be made that EMI should bear some of the responsibility for the unauthorized use of their online banking accounts. In fact, if you read Comerica’s answer to EMI’s complaint you will see that Comerica appears to be taking that position:

16. Denied that the alleged website “appeared to be a Comerica website” to any reasonably alert person who was responsible for safeguarding EMI’s financial records and digital credentials.

26. Denied that any perpetrators infiltrated EMI’s bank accounts. Valid credentials assigned to an EMI employee were used to authenticate a logon for purposes of online banking transactions. If some unknown criminals used those credentials, rather than the EMI employee to whom they had been entrusted, this was caused solely by the actions of that EMI employees.

Whether EMI bears some responsibility will be a very fact-intensive inquiry that will include an analysis of the spoofed email, Comercia's previous practices concerning requests for login-credentials and the actions and decision-making process of the employee that provided the credentials to the criminals.

Conclusion

In general, I believe that these online banking cases have more legs than other types of security breach lawsuits because the plaintiffs have suffered actual damages/harm. Evidence of this is the Shames-Yeakel case, which proceeded past a motion for summary judgment. Contrast this with the numerous security breach cases brought by consumers that have been dismissed relatively early in litigation. In those cases, the plaintiffs whose information was stolen have argued that they suffered harm because they had to pay for credit monitoring. Courts have more or less consistently rejected this argument. For online banking cases, plaintiffs don’t have that problem. In this case the plaintiff is out hundreds of thousands of dollars, so damages are clear.

So if a plaintiff can get past the motion to dismiss phase on the issue of damages, do the defendants have an opportunity to get a summary judgment (rather than risk having to present their case to a judge and jury – something every company likes to avoid, if possible). The problem for banks is that the issue of whether a bank’s security measures were “reasonable” is likely a “question of fact.” Courts are typically not willing to grant summary judgment where questions of fact exist for a jury to decide.

That said, this case is a little different than those in my other blog post because of the phishing issue and because the issue of commercial reasonableness is a question of law under MCLA 440.4702(2). Whether a duty exists under the law is typically a question of law that Courts (as opposed to juries) typically decide. I think there will be a battle at both the pleading and summary judgment phase with the banks trying to argue that they have no duty under the law to prevent their customers from being duped and that their practices were commercially reasonable 440.4702(2).  If Comerica does not win these argumenst then this case could go to a jury, which poses legal risk.

The Multiple Functions of a Data Security and Privacy Schedule

InfoSec-Privacy Schedules serve multiple functions, some of which are for “consumption” outside of the contractual relationship. Schedules function in traditional ways by establishing the relative duties of the parties and transferring risk of loss. However, information security schedules are also “proactive” in nature in that they mandate the implementation of certain measures to prevent a security breach and comply with certain laws. In addition, Schedules serve a “compliance” function that comes into play in the event of a regulatory action or lawsuit.

Proactive Nature of an Info-Sec Privacy Schedule

InfoSec-Privacy Schedules are interesting because they require Service Providers to implement measures to (hopefully) prevent a security incident, and potential legal liability. Contrast this with a traditional non-disclosure agreement. For the most part, NDAs do not dictate how a Service Provider must protect the confidentiality of confidential information, but rather simply mandate that Service Providers not disclose or expose such information. If such exposure occurs, the Customer’s remedy is to sue the Service Provider.

In contrast, one of the overarching goals of the security schedule is to contractually increase the likelihood that the Service Provider is actively implementing measures and policies to prevent a confidentiality breach in the first instance. This outcome is advantageous for Customers:  to never experience a security breach is much better than experiencing the breach and having the right to sue for breach of contract. This is especially true where a Customer’s ability to recover is limited by limitation of liability clauses, consequential damages disclaimers and the like (described more fully in Part Two of this series).

Overall, to the extent that the Service Provider essentially becomes an extension of the Customer’s internal security, the nature of these obligations makes sense. Of course, as discussed below, for both compliance and general operational risk purposes, the trick is consistency between the Customer’s internal security environment and the environments of its Service Providers.

The Infosec-Privacy Schedule as a Compliance Document

Another crucial purpose of an InfoSec-Privacy Schedule is its compliance function. When drafting a Schedule, lawyers should consider how the contract terms relate to specific requirements imposed by applicable information security and privacy laws, and reflect efforts to maintain “reasonable security.” In addition, many laws require Customers to contractually obligate Service Providers to maintain specific security and privacy measures, and the Schedule should reflect those obligations. Ultimately, lawyers negotiating these terms should ask themselves the following question:

If put before a privacy regulator in a regulatory action, or a judge or jury in a lawsuit, will the security and privacy terms in this document reflect efforts to achieve a compliant status and “reasonable security” under the law?

To address this point there are several items lawyers should consider in developing a Schedule:

• Security assessment process. Although the Schedule can serve as a useful document to support a Customer’s arguments in favor of compliance, it should typically be coupled with some sort of due security assessment or investigation. Conducting a security assessment of a Service Provider’s security measures allows the Customer to determine whether appropriate controls are in place and risk adequately mitigated. It also allows the Customer to get an idea whether specific compliance obligations can be met by the Service Provider’s systems and processing.  Moreover, (as discussed below) the security assessment process can inform the Customer as to the specific requirements that should appear in the Schedule. This process should be documented so that the Customer has the ability to establish (in a regulatory or litigation context) that it properly vetted its Service Provider prior to allowing it to process, store or transmit sensitive information.

Without a due diligence process, the effectiveness of the Schedule to establish compliance will be diminished. A Schedule filled with hollow promises is not a good compliance tool. The best policy in this situation (as in many others) is to “trust, but verify” the Service Provider’s security and privacy measures.

• Reference specific information security and privacy laws. The Schedule should specifically reference those laws that the Service Provider must comply with. This can be done by using a definition for “Privacy Laws” or “Security Laws,” and indicating applicable laws within that definition. Using this approach Customers put Service Providers on notice concerning their obligations while being able to show regulators or other parties that they were specifically addressing applicable law.

• Customer’s internal control structure reflected in Service Provider’s security and privacy obligations. When outsourcing, for purposes of information security and privacy, a Customer should view their Service Provider as an extension of itself. Most Customers have gone through an extensive process of measuring their information security and privacy risk and implementing security and privacy measures to mitigate their risk to a reasonable level. The second sensitive information or systems are outsourced to a Service Provider, those internal measures no longer apply and the Customer is completely reliant on the Service Provider’s security measures.

Problems arise when the Service Provider’s measures provide less protection than the Customer's own internal controls.  Allowing a Service Provider with weaker controls to handle sensitive information will be very difficult to defend in a litigation or regulatory context. As such, the Schedule should reflect a matching of risk and controls between the Customer and Service Provider, and the Service Provider’s security and privacy measures should meet or exceed those of the Customer.

• Specific controls relevant to the transaction. It may be necessary to specify specific security and privacy measures and policies that a Service Provider must have in place. For example, the Schedule might explicitly require 256-bit encryption of data at rest, or anti-virus protection. Some of these individual requirements may be dictated by specific obligations in laws, or just may be of special significance to the Customer in light of its internal infrastructure. Another approach is to tie the Service Provider’s existing security measures (assessed during the Customer’s security assessment process) to the Schedule (with requirements to update those measures, especially for long term contracts).

• Reasonable security. In addition to specific privacy and security measures, the Schedule should require an over-arching duty for the Service Provider to always maintain “reasonable security.” This duty should supersede all other security-related obligations, and reflect an ongoing obligation (as opposed to reasonable security just at the outset of the contract). As part of the general duty, the Schedule should also impose obligations to comply with industry standards. Note that industry standards may constitute reasonable security, but it is also possible that industry standards do not meet the level of reasonableness under the law. As such, the Service Provider’s reasonable security obligation should include industry standards, but not be limited to those standards.

• Assessment and enforcement rights. Things change: new vulnerabilities arise; safer security measures are developed; and Service providers can become lax or fall behind. This is especially true for long term contracts. Schedules should provide Customers with rights to conduct periodic security assessments to confirm compliance with the Schedule, regulatory compliance and whether reasonable security measures are being maintained in light of the existing risk environment. The Schedule can also require the Service Provider to give the Customer access to the Service Provider's own internal assessments or provide notice if it is in non-compliance with applicable standards or otherwise. If material non-compliance is found there should be contractual consequences, including the right to terminate the contract for cause.

These provisions serve two functions. First, just having the right to conduct an assessment can act as deterrent – Service Providers are more likely to stay compliant if they fear an assessment and contractual remedies. Second, they allow the Customer to understand the security and privacy risks they face, and whether the Service Provider is addressing these risks and achieving compliance with applicable laws. This second function is especially important for long term contracts where the risk environment is likely to change over time.

Please note that the need to address the issues above may vary depending on the nature of the transaction. Moreover, the relative bargaining power of the parties and the positions taken by the Service Provider may impact a Customer’s ability to get certain terms into a Schedule. Regardless, when drafting information security and privacy terms, thinking about how those terms might be viewed from a compliance standpoint is very important.

The Schedule serves other important functions beyond being created and used as evidence of compliance.  In Part Two we address security incident response provisions and contract terms allocating risk of loss between the Customer and Service Provider.

Spain already requires encryption for personal financial data, as well as for the “sensitive” categories of data as defined in the EU Data Protection Directive (race, health or sexual life, trade union membership, political or religious opinion). Italy requires a written security policy for certain categories of sensitive data (including biometrics and geolocation tracking, both sometimes used in security badging system, and consumer profiling); the policy must specifically address encryption. France, Austria, and Belgium request information about encryption in their standard declaration forms for personal data processing activities, and official guidance in those countries cautions companies to address encryption in their written security policies. Switzerland’s federal data protection commission encourages multinationals to encrypt SSNs and other risky personal data in transmissions to outsourcing vendors or to parent or affiliate companies abroad. The Information Commissioner in the United Kingdom has threatened enforcement measures against companies and agencies that fail to secure personal data on laptops. Japan’s Financial Supervisory Agency has similarly issued warnings to financial institutions to encrypt financial data in transmission and on laptops.

Thus, on the international scene, encryption is becoming a mandatory checklist item to establish “reasonable” security for sensitive categories of data, with “sensitive” defined more broadly than the limited data categories covered by US federal and state laws. Unlike the trend in US laws and regulations, there is seldom a specific reference to government or industry encryption standards. However, it would be difficult to defend an organization’s security measures for sensitive data as “reasonable” without reference to such standards or industry practices.

Security Breach Notification Laws

Outside the US, Japan has also formalized breach notice requirements. These are not consistent; they vary according to the regulations or recommendations of the relevant ministry – with regard, for example, to the number of files or the categories of data that trigger notification to either the public or to the ministry. Many companies are subject to overlapping ministerial jurisdiction and so tend to follow the stricter standards of the Financial Services Agency or the Ministry of Economy, Trade, and Industry (METI) in the event of a data breach. Thus, in both the US (because of varying state laws) and Japan (because of different standards among supervisory authorities), there is not a uniform approach to data breach notice.

Initially, privacy and data protection officials in the European Union, Canada, Australia, and other jurisdictions with comprehensive data protection laws rejected the US trend toward breach notice laws. Some argued that these were an inadequate solution to the problem of ID theft, focusing only on transparency rather than ensuring minimum levels of acceptable security. Others argued that special breach notice laws should not be necessary. Existing data protection laws already require notice to individuals when personal data are transferred to another “data controller,” and thus notice should be given when an unauthorized “controller” takes possession of the data. Moreover, where notification to the data protection authorities is routinely required (as in many European countries that require “registration” of personal data processing activities with a supervisory authority), a data controller is typically obliged to notify the authorities concerning any material changes – such as the failure of its notified security program and the unintended transfer of protected personal data to a third party.

Despite these provisions of current data protection laws, enterprises outside the US and Japan for the most part have less commonly given notice of data breaches involving personal data. Data protection authorities have contacted some enterprises when breaches were discovered and in some cases have publicly condemned the enterprise for failing to warn individuals affected by a data breach. In 2008, for example, the UK Information Commissioner sent an Enforcement Notice to retailer Marks & Spencer, criticizing the company for failing to notify affected individuals when a laptop containing unencrypted personal data on 26,000 pension plan participants was stolen in a burglary. Sectoral regulators have in some instances imposed sanctions for large-scale breach events. The UK Financial Services Authority (FSA), for example, fined Nationwide Building Society nearly $2 million in 2007 following a stolen laptop incident compromising unencrypted customer data.

Partly because of such episodes, there is renewed interest abroad in adopting data breach notification or “data leak” laws that would require notice to affected individuals (and typically to the authorities as well) where unencrypted personal data is lost or stolen. Such proposals are under consideration in Canada and Australia as well as in the UK and several other European countries. Proposed amendments to the EU Directive on Privacy and Electronic Communications (the “E-Privacy Directive") would require breach notice by providers of electronic communications services. The scope of this term is still debated; it might include employers, universities, and even owners of apartment buildings. The current proposal would make an exemption from the obligation to notify where “appropriate technological measures” (such as encryption) were applied to the data. As in most US laws, the proposal does not specify a particular kind of encryption that qualifies for the exemption. Relying on widely accepted industry and government standards is one way, however, to establish a defensible approach to both security and breach notification.
 

(4) REQUIRED SECURITY MEASURES (NRS 603 A.210)

What security measures must data collectors implement and maintain while maintaining records containing personal information?

Data collectors that maintain records that contain personal information must implement and maintain reasonable security measures to protect those records from unauthorized access, acquisition, destruction, use, modification or disclosure. Some observations

• Objective standard. The use of the word "reasonable" to describe required security measures suggests an objective standard in assessing whether a company has complied with the Security Law. In short, it may not be enough if a company "subjectively" believes that it has good security measures (even if that belief is "true"). Security measures under this law will be measured against an "objective" standard based on the circumstances of the data collector, the threat environment, available technology, etc. In practical terms, if a lawsuit is filed, the plaintiffs will retain an expert who will likely provide a counter-opposing view as to the reasonableness of the data collector's controls (if that is an issue in the case). The data collector will have counter that opinion with "objective" evidence.

• Reasonableness - Adherence to Industry Standards May Not Be Enough. If "reasonableness" is viewed in a similar fashion as under common law negligence, complying only with industry standards may be inadequate. Judge Learned Hand's ruling in the T.J. Hooper case demonstrates this rationale:

Indeed in most cases reasonable prudence is in fact common prudence, but strictly it is never its measure. A whole calling may have unduly lagged in the adoption of new and available devices....Courts must in the end say what is required. There are precautions so imperative that even their universal disregard will not excuse their omission.

In short, doing what the industry does may not be enough if the industry is lagging behind the security risk curve.

• Risk-Based Reasonableness. Again, in another nautical-oriented lawsuit, Judge Learned Hand famously put forth the following legal concept:

Since there are occasions when every vessel will break from her moorings, and since, if she does, she becomes a menace to those about her; the owner's duty, as in other similar situations, to provide against resulting injuries is a function of three variables: (1) The probability that she will break away; (2) the gravity of the resulting injury, if she does; (3) the burden of adequate precautions. Possibly it serves to bring this notion into relief to state it in algebraic terms: if the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B < PL.

Under this legal doctrine, an analysis of the risk posed by having or not having particular security measures is required to determine what security measures are "reasonable." In simplistic terms, low-cost security measures that mitigate a lot of risk (e.g. virus protection might be one) are necessary, while high cost security measures that mitigate a little risk may not be. The difficult part is determining the security measures that fall in the middle.

• Considerations in analyzing "reasonable" security measures. Compliance with industry standards and risk-based security controls can assist a company in achieving "reasonable" security measures. If attempting to comply with industry standards, companies should consider not only the industry on the whole, but also similar peers and sub-groups within the industry. For example, while my local credit union and Citibank may be in the same industry (financial industry), "reasonable" industry security measures for Citibank likely differ from the smaller credit union. While a baseline may exist for all financial institutions, larger and more wealthy banks like Citibank may have to match up to similar financial titans (Bank of America, HSBC, etc.). In addition, organizations should consider complying with general security standards like ISO 27001, CoBit and others. If laws exist within a particular industry (such as GLB, HIPAA, FERPA) that establish security laws they should also be considered part of the "reasonableness" equation. The more a company can point to relevant standards or laws they have complied with, the stronger their arguments for reasonableness.

• Retain Security and Legal Expertise and Develop Positions. Since the issue of reasonableness in many cases will come down to a battle of security and legal experts, organizations should develop their positions ahead of potential security breaches or other situations likely to lead to litigation. This includes having developed a position that is defensible from both a security and legal standpoint. In many cases, the data collector will have to retain a security professional to provide expert testimony. If security and legal positions are developed prior to a breach, and hopefully under attorney-client privilege, they can be ready for use after a security breach in the defense of a lawsuit.

If a data collector discloses personal information to a service provider, does the service provider have a direct and independent duty to implement and maintain the reasonable security measures required under the Security Law?

Since data collectors are defined based on whether they maintain personal information, a service provider that maintains personal information appears to have a direct and independent duty under the Security Law to implement reasonable security measures. In addition, the Security Law requires a data collector disclosing personal information to a service provider to enter into a contract obligating the service provider to implement and maintain reasonable security measures. Finally, for all intents and purposes, service providers handling payment card data may have to comply with PCI to the extent that it is considered the industry standard, which informs on the issue of "reasonableness."

Do data collectors need to comply with the law's reasonable security requirements if they are already compliant with another state or federal law mandating reasonable security measures?

No, as long as the other applicable security law provides greater protection to records that contain personal information of Nevada residents and the data collector is compliant with that law. In such a case, the data collector is deemed in compliance with this subsection of the Nevada Security Law. However, organizations must conduct a careful legal and security analysis to determine whether other laws actually match up to the protections required under Nevada's Security Law.

Up Next: Blog Post Four: Encryption and PCI Requirements

Please note, while I am an attorney this post does not in any way constitute legal advice or a legal opinion, and should not be relied upon to take any action or be the basis for any inaction. The this law is complex and additional research is necessary. If you are interested in a full legal analysis please contact me directly at djn@davidnavetta.com