Last October, a Nevada law took effect that requires encryption of all personal information in transit. Perhaps in response to criticisms of that law, Nevada just updated the law—and added a PCI compliance requirement.
The new law repeals the previous encryption statute, and adds a new one to Nevada Revised Statutes section 603A. The previous law was criticized for not clearly defining “encryption;” the new law tries to fix that by defining encryption as something adopted by NIST or any other “established standards setting body”:
(b) “Encryption” means the protection of data in electronic or optical form, in storage or in transit, using:
(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and
(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.
Although “adopted” is not necessarily the word I’d use to describe FIPS approval of encryption protocols, the Nevada legislators should get credit for paying some attention to key management.
Unfortunately, Nevada did not do so well when it decided to add a PCI DSS requirement to the law. Unlike Minnesota, which requires compliance with a specific narrow provision of PCI DSS, Nevada simply mandated compliance with the whole standard:
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.
In computer programming lingo, that’s PCI by reference, and it’s a huge delegation of power by the Nevada legislature to the PCI Standards Council. The PCI Standards Council is not elected, nor is it appointed by elected officials. Giving the force of law to anything the PCI Standards Council says raises constitutionality questions. At least the law said “with respect to those transactions,” so the PCI Standards Council only has the power to enact laws related to payment processing. If the Standards Council decides that all payment processors must pay the Standards Council $1 billion per year, that would only have the force of Nevada law if the payments are related to transactions. Maybe.
The other problem with the new law is that still applies to any “data collector doing business in” Nevada. It does not apply only to transactions through Nevada, or to transactions involving Nevada residents, but to anyone with business in Nevada. Suppose my business is located in Missouri, but sets up a booth at a Las Vegas trade show every year. Is that “doing business” in Nevada? Are my Missouri-only transactions now subject to the Nevada law?
Nevada’s law lacks the penalties prescribed in Minnesota’s law. The Minnesota law allows card issuers to recover the cost of replacing cards due to a data breach; Nevada’s law includes no such provision. Instead, the penalties for not complying with PCI DSS are the same as for a data breach: the breached entity can sue the data thief, and the attorney general can get an injunction against anyone violating the statute.
Even without that penalty, however, the official codification as a statutory requirement could make PCI DSS the basis of a negligence per se claim. When it applies, negligence per se allows a plaintiff to skip the whole “reasonable person” evaluation of a standard of care in a negligence suit by pointing to a statute. For example, a pedestrian hit by a driver running a red light could point to the statutes requiring people to obey traffic signals as showing that the driver was negligent per se. The statutory PCI DSS requirement might do the same thing for that standard: allow plaintiffs to say that PCI DSS itself establishes the standard of data security due care. In practice, however, it may not matter, because plaintiffs have had too much problem showing cause-in-fact and harm to ever reach the standard-of-care questions.
Even so, the PCI DSS requirement-by-reference is troubling, and a little sloppy. Legislating technology is hard: write something that’s too general, and it can become meaningless; write something that’s too specific, and you have to re-write the law every year. But that’s no excuse for giving up by pointing to a private standard and saying, “do that.”
