InfoLawGroup LLP

View Original

Nevada's Security of Personal Information Law Post Four: Encryption and PCI Compliance Requirements

The following FAQs address the encryption and PCI compliance requirements of Nevada's Security of Personal Information Law, which were added pursuant to a recent amendment to the law.  The rest of the FAQ is linked to here.

 

(5) ENCRYPTION and PCI COMPLIANCE (SB 227 - Amendment to NRS 603A)

Does the Nevada Security Law mandate compliance with the Payment Card Industry Data Security Standard ("PCI")?

Yes, certain data collectors must comply with the "current" version of PCI.

Some observations:

  • PCI is always changing. One of the biggest problems with the PCI compliance requirement under the Security Law is that PCI is constantly being changed and updated. PCI is currently on version 1.2 (the third version in 4 years) and is currently soliciting comments concerning potential modifications. This literally makes the Security 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. Previously, non-compliance could result in a contract breach claim, but under the Nevada law it can result in an attorney general action and statutory liability.
  • 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 to questions. 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. This is a corollary to "PCI is ambiguous." PCI compliance is normally mandated by contract. 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 compliance 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 an interpretation that is not compliant, under the Nevada law that could result in a violation of law.
  • 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 neither the PCI standard nor the Nevada Security Law make any exception or allowance for this. As a result, on day one thousands of businesses are likely to be non-compliant with the Nevada law.

Who must comply with PCI under the Nevada Security Law?

Data collectors doing business in Nevada that accept a payment card in connection with the sale of goods and services.

Some observations:

  • Do service providers have an independent and direct obligation to comply with PCI under the Security Law? 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. The Nevada law, 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 a service provider "accepts a payment card in connection with a sale of goods or services." Could this language extend beyond the "merchant?" If the language read "accepts a payment card in connection with 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 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. The merchant may not ever receive any payment card data. Could this render the service provider directly responsible for complying with the Nevada Security Law? Without more research the answer is unclear.

  • No "data collector" status means no compliance obligations. Companies that do not maintain "personal information" are not "data collectors" under the Security Law, and are therefore not subject to the law. "Personal Information" under the law is defined to include first name or first initial and last name, in combination with any of the following data elements, when the name and data elements are not encrypted: (1) SS#; (2) driver's license number or identification card number; and/or (3) account number, credit card number or debit card number, in combination with a security code, password or access code that would permit access to the person's account. A business would not be a "data collector" in the following scenarios and therefore the Security Law would not apply to it:
  • An organization that accepts credit cards, but encrypts either the name or data elements (or both) does not have to comply with PCI under the Security Law because it is not a data collector. 2. An organization that for some reason does not maintain the first name/first initial of its customers it would not be a data collector. 3. An organization that does not maintain credit card numbers and security codes associated with those credit card numbers (assuming no SS# or driver's license/ID number is present) would not be a data collector. So a company that only maintained first/last name and credit card number, but not security codes (CVV, CVS, full stripe data, etc.) would not be a data collector subject to the law. Please note that just because a company is not a "data collector" under the Security Law does not mean that it does not have an independent contractual or common law obligation to comply with PCI. PCI applies typically to companies that have entered into a merchant agreement to accept payment cards where they store, transmit or process payment card data. The PCI standard can also be used to establish the standard of care in a negligence suit.

  • Nationwide Scope for Online Companies. Under this section of the Security Law the data collector must be "doing business" in Nevada. While this section may appear to create a smaller subset of companies, since the concept of "doing business" may include simply running a website that is accessible by Nevada residents, the practical effect may be a nationwide scope for many companies selling goods and services online.

What version of PCI must applicable data collectors comply with?

The Security Law indicates that applicable data collectors must comply with the "current" version of PCI. It is not clear whether this means the current version of PCI in existence at the time this bill went into law or the current version of PCI in existence at the time of a transaction involving payment card data. However, reference to due dates for PCI compliance set by PCI or the PCI Council suggest the latter.

An observation:

  • Ambiguity Concerning Setting PCI Compliance Dates. Compliance dates for PCI are set by the card brands, not the PCI Council. Moreover, there are no such dates in the PCI standard itself. Those dates are contained in each card brand's security program or operating regulations.

Does the Nevada Security Law require encryption of personal information transmitted electronically?

Yes, data collectors doing business in Nevada, that are not subject to PCI, may not transfer personal information outside of its secure systems through an electronic transmission unless encrypted.  Some exceptions exist (discussed below).

Does the Nevada Security Law require encryption of personal information on data storage devices?

Yes, data collectors doing business in Nevada, that are not subject to PCI, may not move a data storage device containing personal information beyond the logical or physical controls of the data collector or its storage contractor, if the personal information is not encrypted to ensure the security of the personal information.

What kind of encryption technologies and practices must be used to comply with this section?

To be compliant with the Security 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, whichhas 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.

In addition, 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.

What exceptions exist to the encryption requirements under the Nevada Security Law?

The electronic transmission encryption requirement does not apply to electronic voice transmissions or facsimile transmissions. None of the encryption requirements of the law apply to telecommunication providers conveying communications of other people. Finally these encryption requirements do not apply to 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.

If a data collector complies with the encryption requirements or the PCI mandate can it be held liable for a security breach involving personal information? (Does the Security Law provide a safe harbor)?

No, as long as the breach was not caused by the gross negligence or intentional misconduct of the data collector, its officers, employees or agents. Yes, it appears that the Security Law provides a limited safe harbor. However, it is uncertain how far this "safe harbor" extends.

Some observations:

  • Scope of "Safe Harbor" - Different Legal Theories. Some may argue that the safe harbor protects the organization from all damages no matter what legal theory is alleged (e.g. negligence, contract, fraud, etc.). Support for this theory can be found where the law references "gross negligence and intentional misconduct," which arguably implies that other theories of liability can be barred by the safe harbor. Others may contend that this safe harbor only extends to liability under the Nevada Security Law itself. The law does not explicitly clarify the scope of the safe harbor.
  • Scope of "Safe Harbor" - Choice of Law. Assuming the safe harbor does apply to legal theories above and beyond violations of the Security Law, can it be utilized to block liability if a case is brought in another State? This comes down to a choice of law analysis. If Nevada's law is deemed to be the choice of law then the Security Law safe harbor may bar liability. However, if Nevada law is not the law applied by a court, other claims will likely not be barred. It would not be surprising to see breach defendants transferring cases to Nevada and arguing for Nevada as choice of law in order to try to take advantage of the safe harbor.
  • PCI safe harbor easy to lose? As most PCI security professionals know, especially with respect to large organizations, it is not difficult to find a violation of one of the over 200 sections/subsections of PCI. Unfortunately the Security Law does not provide a safe harbor for "material" compliance with the law. As such, technical violations or minor violations, as well as interpretative differences, can result in a loss of safe harbor protection. The PCI incident response procedures can also pose risk that PCI compliance will not be found. Some companies therefore, may view the safe harbor as illusory.

Up Next: Blog Post Five: Remedies, Penalties and Enforcement

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.