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

The Interplay Between the Law’s PCI Compliance and Encryption Obligations

To understand the requirements of SB 227, it is important to first understand the interplay between the PCI obligations set forth in subsection 1. and the encryption requirements of subsection 2. Significantly, it appears that a data collector that complies with PCI (as required under subsection 1. of SB 227) need not comply with the personal information encryption requirements of subsection 2. This “either/or” dynamic creates a strange compliance situation.

Subsection 1. of SB 227 provides:

1. If a data collector doing business in this State accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the Payment Card Industry (PCI) Data Security Standard, as adopted by the PCI Security Standards Council or its successor organization, with respect to those transactions, not later than the date for compliance set forth in the Payment Card Industry (PCI) Data Security Standard or by the PCI Security Standards Council or its successor organization.

Subsection 2. of SB 227 provides:

2. A data collector doing business in this State to whom subsection 1 does not apply shall not:

(a) Transfer any personal information through an electronic, nonvoice transmission other than a facsimile to a person outside of the secure system of the data collector unless the data collector uses encryption to ensure the security of electronic transmission; or

(b) Move any data storage device containing personal information beyond the logical or physical controls of the data collector or its data storage contractor unless the data collector uses encryption to ensure the security of the information.
(emphasis supplied).

The current version of PCI (v 1.2.1 – July 2009 ) references encryption with respect to certain cardholder related data while stored and in transit. Section 3.4. of PCI requires companies to render a payment card’s PAN’(“Primary Account Number’”) unreadable, including through the use of strong encryption. Compliance under section 3.4 is also possible through other measures, including truncation, index tokens and pads, and “compensating controls.” Section 4.1. of PCI mandates the use of strong encryption of “cardholder data” during transmission over open or public networks. Cardholder data as defined under PCI includes PAN, Cardholder Name, Service Code, and Expiration Date as defined with respect to PCI.

However, the definition of “personal information” under the Law is much broader than “PAN” or “cardholder data” under PCI. Personal information includes information that is wholly unrelated to credit cards, including social security numbers, driver’s license numbers, identification card numbers and bank account numbers. PCI does not require encryption of these elements while transmitted electronically. Moreover, PCI does not require any personal information to be encrypted while stored. Rather, it only requires that the PAN be encrypted in storage (and even here encryption is not an absolute requirement -- PCI allows for other methods to render PANs unreadable and allows for "compensating controls"). Finally, since the encryption that happens around PCI relates to payment processing only, it does not appear that PCI-compliant companies would have to address encryption in other contexts, including for example e-mails containing personal information.

In short, PCI compliance allows an entity to avoid the obligation to encrypt personal information (except for "Cardholder Data") on data storage devices or while in transit, as required under subsection 2. of SB 227, and would appear to undermine the broader purposes of the Law. Stated differently, companies that are already PCI compliant would appear to have diminished obligations when it comes to encrypting Personal Information than those companies that are not subject to PCI.

Issues Surrounding the Law’s PCI Compliance Obligations

Nevada is the first state to incorporate the entire PCI Standard into law. The PCI Standard is an industry standard contractually imposed by the payment card networks on merchants and service providers that store, process or transmit cardholder data. In essence, the Nevada legislature has ceded its legislative authority to a group of private companies whose interests and concerns in creating and updating the standard may not be aligned with the goals of the Law. It has given PCI the weight of law, backed by attorney general enforcement and potential statutory liability, despite the fact that PCI is typically imposed in a negotiated contractual setting. As such, tying PCI to the Law raises several interesting issues and poses additional challenges:

• PCI is always changing. One of the biggest problems with the PCI compliance requirement under SB 227 is that PCI is constantly being changed and updated. PCI is currently on version 1.2.1 (the fourth version in four years) and is currently soliciting comments concerning potential modifications in 2010. This makes the Law a moving target. On a certain level this makes sense – the PCI standard and good security evolves as the risks and technology changes. However, from a compliance standpoint constant vigilance is required to ensure compliance. Under the Nevada law this is especially true since non-compliance can result in an attorney general action.

• PCI is ambiguous. Unfortunately the PCI standard is ambiguous as written in many sections and as applied in many circumstances. This is due in part to the one-size-fits-all nature of the standard. The problem is exacerbated, however, because there are multiple sources of interpretation, including the PCI Council, merchant banks, the card brands and qualified security assessors. Even within the PCI Council itself multiple methods of interpretation exist, including guidelines, FAQs, prioritized approaches, and email answers provided by the PCI Council provided on an ad hoc basis. Moreover there is no set interpretative hierarchy between potentially competing interpretations. For example it is not clear whether PCI Council guidance document would trump an FAQ, or the interpretation of a merchant bank.

• PCI is contractual in nature. Typically a merchant will enter into a “merchant agreement” with a merchant bank or processor so it can accept credit cards. That merchant agreement will mandate that the merchant comply with PCI. If there is an ambiguity, since the merchant’s obligations are derived by contract, naturally the “best” source to resolve those ambiguities is with the merchant bank that is party to the agreement. If the merchant bank “gets it wrong” or agrees to a PCI interpretation that is not compliant, while it may have sufficed for the contractual relationship, under the Law it could result in a legal violation.

• PCI is one-size-fits-all. PCI is made up of over 200 individual requirements/sub-requirements. For small businesses it may be difficult, if not impossible, to comply with (from a resource standpoint). Yet the Law does not make any exception or allowance for this. As a result, on day one many businesses (especially smaller and medium companies) are likely to be non-compliant with the Nevada law.

• New independent and direct duty for service providers to comply with PCI? Typically, under the PCI regulatory scheme, service providers that store, handle or transmit cardholder only have a direct obligation to comply with PCI if they are contractually required to do so. They have no independent legal duty to comply with PCI under normal circumstances. SB 227, however, may provide a direct duty for service providers to comply with PCI. Service providers appear to fall into the definition of “data collectors” because they typically “handle, collects, disseminates or otherwise deals with nonpublic personal information.”  The issue becomes whether, under subsection 1. of SB 227, a service provider storing, processing or transmitting cardholder data for another “accepts a payment card in connection with a sale of goods or services.” If the language in subsection 1. read “accepts a payment card for a sale of its goods or services,” then it would appear to be limited to merchants. However, the “in connection” language arguably extends the duty to service providers. For example, some might argue that payment gateways directly “accept” payment card numbers from customers online on behalf of merchants in connection with the merchant’s sale of goods and services.

Issues Surrounding the Law’s Encryption Obligations

The Encryption Obligations: Electronic Transmission and Data Storage Devices.

If a data collector doing business in Nevada does not have an obligation under subsection 1., then it must comply with the encryption requirements of subsection 2. SB 227 requires encryption in two areas: personal information transmitted electronically (subsection 2.(a) of SB 227) and encryption of personal information stored on certain data storage devices (subsection 2.(b) of SB 227).

A data collector doing business in Nevada, subject to exceptions discussed below, may not transfer personal information outside of its secure systems through an electronic transmission, unless encrypted. Again, a drafting quirk may pose some interesting interpretations of this obligation. By using the term “secure system” (undefined), it appears that this encryption requirement does not apply to personal information transmitted from an “insecure system.” Note that the probable intent of the “secure system” language was to eliminate the need to encrypt personal information while in transit within the internal networks of an organization (or at least that is one interpretation).

Drafting mistakes aside, SB 227 sets forth some significant exceptions to this encryption requirement. The electronic transmission encryption requirement does not apply to:

• electronic voice transmissions or facsimile transmissions;

• telecommunication providers conveying communications of other people; or

• data transmissions over secure private communications channel for: (1) approval or processing of negotiable instruments, EFT transfers or similar payment methods; (2) issuance of reports regarding account closures due to fraud, substantial overdrafts; or (3) abuse of ATM machines or related information regarding a customer.

Data collectors must also encrypt data stored on a data storage device if the device goes beyond the logical or physical controls of the data collector or its data storage contractor. The concept of going beyond the physical controls (e.g. facilities of the data collector) is fairly clear. However, it is uncertain exactly what the intent is behind the “logical controls” reference. It could mean that if the data storage device is protected by the same “logical controls” as data storage devices that are part of the data collector’s internal networks, then encryption is not required.   Or it could be tying back into the concept of secure internal environments.  However, more research is necessary to ascertain how the “logical control” reference should be interpreted.

The Encryption Standard.

To comply with the Law, data collectors must use an encryption technology that renders such personal information indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data, which has been adopted by an established standards setting body, including for example, the Federal Information Process Standards published by the National Institute of Standards and Technology.

Encryption under the law also requires sound key management processes and safeguards. Specifically, data collectors must utilize appropriate management and safeguards with respect to cryptographic keys in order to protect the integrity of its encryption process. The data collector’s key management procedures and safeguards must be consistent with guidelines set forth by an established standards setting body, including for example, the National Institute of Standards and Technology.

While one might quibble with the requirement that the encryption technology render personal information indecipherable (all encryption is theoretically capable of being broken), the reference to FIPS and NIST standards provides solid guidance. However, the Law does not indicate what constitutes an “established standards setting bodies” in the event a data collector would like to use an encryption standard that is not based on FIPS or NIST.

The SB 227 Amendment’s “Safe Harbor”

While SB 227 arguably imposes significant encryption obligations on certain data collectors (at least those that are not already PCI-compliant), it also provides a “reward” for companies that meet its mandates. Subsection 3. of SB 227 provides a “safe harbor”:

3. A data collector shall not be liable for damages for a breach of the security of the system data if:
(a) The data collector is in compliance with this section; and
(b) The breach is not caused by the gross negligence or intentional misconduct of the data collector, its officers, employees or agents.

This “safe harbor” may provide significant protection to compliant companies that suffer a personal information breach, even beyond the Law itself. Some may argue that the safe harbor protects the organization from all damages no matter what context or theory of liability (e.g. common law negligence, contract, negligent misrepresentation, etc.). Support for this theory can be found where SB 227 references a very limited list of liabilities theories (“gross negligence and intentional misconduct”), which arguably implies that other theories of liability can be barred by the safe harbor. Moreover, since the Law itself does not explicitly provide any damage remedy against a data collector that suffers a security breach, it would appear to be referring to liability outside of the Law.

For example, assume the case of a merchant that suffered a payment card breach. It would typically have a contract in place whereby it agreed to indemnify its merchant bank in the event of a payment card breach. Under SB 227, as long as the merchant was PCI compliant at the time of the breach (and therefore compliant with subsection 1. of SB 227), it could argue that it should be immune from contractual liability. This is significant because there is no legal mechanism currently in place under PCI that provides this legal protection. Please note that this argument is far from settled and additional research and analysis is necessary in order to validate the intent of Nevada’s legislature.

Beyond its potential broad scope, the safe harbor language in SB 227 arguably creates some incongruities between SB 227 and the Law. For example, the Law requires data collectors to implement certain “reasonable” security measures around personal information, which typically include measures beyond encryption (e.g. background checks, firewalls, virus protection, security policies, etc.). However, the safe harbor applies to all security breaches as long as the data collector complied with SB 227, even if it implemented “unreasonable” (but not “grossly negligent”) security.

An illustration may assist here. Assume a data collector made a mistake in configuring its firewall, which allowed a hacker to steal one million unencrypted personal information records while in transit on the data collector’s internal systems. One might argue that this data collector violated the section of the Law requiring “reasonable security measures” by providing such access. Nonetheless, as long as the data collector complied with SB 227 by encrypting data in transit externally or in data storage devices taken off premises, and it was not grossly negligent, it appears it would not be liable for the security breach under the Law (and otherwise). In other words, with the safe harbor, the requirements of SB 227 could be argued to override more stringent requirements of the Law around security.

Conclusion

Nevada’s Security of Personal Information Law, including the SB 227 Amendment, may pose some challenges for organizations. Its scope is arguably wider than Nevada companies because it appears to apply to any business that stores or processes personal information of Nevada residents, even those without a physical presence in Nevada. It employs a one-size-fits all approach that requires either PCI compliance or encryption of data in transit or on data storage devices, regardless of feasibility, or the resources or sophistication of the company. Moreover, by incorporating the payment card industry’s data security standard directly into the law, it gives PCI “the force of law.” This may be problematic for several reasons, the least of which is that PCI is frequently amended and presents a “moving target,” and is often ambiguous as written and as applied.

However, in addition to the new obligations posed by SB 227, it may offer some benefits and protection to organizations. First, companies that are already PCI compliant do not need to go the extra step under SB 227 and encrypt personal information in transit or on data storage devices. This is true despite the fact that the encryption requirements of PCI are limited in scope. Second, SB 227 provides a safe harbor that arguably bars liability arising out personal information security breaches that were not intentional or grossly negligent. In all, it will be interesting how companies react to the Law, how it is enforced by regulators, used by litigants involved in security breach litigation, and interpreted by courts.

(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