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

What kinds of entities does the Act apply to?

The Act defines “covered entities” to mean any person engaged in interstate commerce that collects or stores data containing covered information or sensitive information.  However, section 601 of the Act limits the application of the Act to only those persons over which the Commission has authority pursuant to section 5(a)(2) of the FTC Act (Note:  this section previously indicated that the Act applied to all persons engaged in interstate commerce [which is in the definition of covered entity]; the error was noted by a reader and the correction made here). Covered entities do not include any divisions of Federal or state government or some entities that meet specified criteria (e.g. store less than 15,000 records; collect less than 12,000 records in a year, etc.; see definition of “covered entity” for more detail).

Observations:  Significantly, it does not appear that the definition of covered entity makes the traditional distinction between data owner/controller and service provider/processor. As such, service providers may be directly subject to the Act as a result of collection or storage of covered/sensitive information on behalf of their customers.

What kinds of information does the Act regulate?

The Act regulates “covered information” and “sensitive information.”

“Covered information” includes such information elements as first name or initial and last name, postal address, email address, telephone/fax number, government issued identification numbers (e.g. tax ID, driver’s license number, etc.), financial account numbers, credit/debit card number, access codes/passwords, “unique persistent identifiers” used to collect, store or identify information about a specific individual or create a profile (e.g. customer numbers, IP addresses, unique pseudonym), and any information collected, stored, used or disclosed in connection with the foregoing information. Section (B) of the definition also lists a number of important exclusions concerning certain business-related information.

“Sensitive information” means information associated with covered information of an individual that relates directly to the individual’s medical history or health, race or ethnicity, religious beliefs/affiliations, sexual orientation/behavior, financial information (income, assets, liabilities, etc.), a person’s geolocation information, unique biometric information or social security number.

Observations: The definitions of information regulated under the Act go well beyond any U.S. definition of personally identifiable information. For example, the “traditional” definition of PII normally requires first name and last name combined with additional information such as financial account numbers. The definition of “covered information” in the Act does not require such a combination – each data element stands on its own and may not need to be tied to or identify a specific person. If I, as an individual, had an email address that was wildwolf432@hotmail.com, that would would appear to satisfy the definition of covered information even if my name was not associated with it.

The definition of “sensitive information” echos similar definitions under the EU Data Protection Directive and other laws based on an EU Model. Interestingly, however, it also specifically includes geolocation information (which some believe may become a larger privacy issue with the prevalence of mobile computing and smartphones).

How does the Act promote transparency about the commercial use of information?

Section 101 of the Act purports to promote transparency by requiring covered entities to provide certain information about the covered entity’s information practices and the individual’s options with respect to such practices, including:

• the identity of the covered entity

• description of covered/sensitive information collected or stored by covered entity

• the specific purposes for which the covered entity collects and used the covered information, including how the covered entity customizes products/services/prices based on such information

• the specific purposes for which covered/sensitive information may be disclosed to third parties and the categories of third parties who may receive such information the choice and means for limiting the collection, use and disclosure of covered/sensitive information

• a description of the information any individual may request access to and the means for making such a request

• how the covered entity may merge, link or combine covered/sensitive information

• the retention schedule for covered/sensitive information including whether the entity will retain information permanently

• whether the individual can direct the deletion of information collected from or about the individual

• a reasonable means for individuals to contact the covered entities regarding their handing of covered/sensitive information

• the process by which the covered entity notifies individuals of material changes to its practices or policies

• a hyperlink to the FTC Commissioner’s online consumer complaint form or the FTC’s toll-free number for the Commissions Consumer Response Center

• the effective date of the privacy notice.

Observations: While much of the notice requirements of the Act parallel the Fair Information Privacy Principles, one could argue that the Act also includes notice elements that appear to go beyond such principles. These additional elements also appear to address current issues that some believe may pose privacy problems. For example, it is interesting that notice is required concerning where/how information will be merged or combined with other data. The retention schedule requirement is also interesting as it may address concerns that some have about some companies retaining data too long.

How must the notice required under the Act be provided?

Under section 102 of the Act, the notices described in the prior FAQ must be “concise, meaningful, timely, prominent, and easy-to-understand” in accordance with FTC regulations authorized under the Act that will be published later. Notices must be retained for six years from the later of the date the notice was issued or the date it was last in effect.

Is notice required for “in-person transactions”?

Under section 103 of the Act, it appears that the notice and information referenced above is not necessary for “in-person transactions” but only if the covered information is collected for an “operational purpose” (e.g.for the purpose of providing goods or services, managing operations, compliance with legal obligations or protection against risks and threats ) or if the covered entity is only collecting name, address, email or phone/fax and does not share the information or use that information to acquire additional information about the individual from third parties.

Observations:  Notably, the Act does not indicate that covered information needs to be collected solely for operational purposes. Based on the current wording, one could argue that if covered information was covered for both operational purposes and marketing purposes, it could fall under the “operational purposes” exception.

Are covered entities required to get consent from individuals for the collection and use of covered information?

Yes, under section 103 of the Act covered entities must provide “opt-out” consent in order to collect or use covered information (except for the collection or use of covered information for operational purposes). The Act indicates that a covered entity shall be considered to have obtained proper consent if it has provided the notice required under the Act, provides a reasonable means to exercise an opt-out right and decline consent; and the individual either affirmatively grants consent or does not decline consent.

The consent shall be considered permanent unless directed by the individual. However, the covered entity must provide an individual with a reasonable means to decline or revoke previously granted consent at any time.

A covered entity may also provide individuals with the ability to decline consent for specific uses of his or her personal information, but only if the individual has been given an opportunity to broadly opt-out of all collection and use of covered information.

May covered entities collection or use covered information as a condition of an individual’s receipt of a service or other benefit?

Yes, but only if: the covered entity has a direct relationship with the individual; the information is not shared with any third party without the express affirmative consent of the individual; the covered entity provides a clear, prominent and specific statement of the specific purposes for which covered information will be used; the individual provides consent by acknowledging such uses; and the individual is able to later withdraw consent.

Are covered entities required to get consent from individuals for the disclosure of covered information to third parties?

Yes. In general, a covered entity may not disclose information to a third party unless it has received express affirmative consent from the individual prior to disclosure. However, some exceptions apply.  For example, no such consent is necessary for joint marketing activities as long as the covered entity has entered into a contract with the third party that prohibits the disclosure of the information except as necessary to carry out the joint marketing relationship.

Are covered entities required to get consent from individuals for the collection, use or disclosure of sensitive information?

Yes. In general, under section 104 of the Act, a covered entity may not collect, use or disclose sensitive information to a third party unless it has received express affirmative consent from the individual.

Does the Act put any limitations or restrictions on behavioral advertising or tracking an individual’s Internet browsing activities?

Yes. Under section 104 of the Act, covered entities may not use software or hardware to monitor all or substantially all (a.k.a. “comprehensive online data collection”) of an individual’s browsing activity (or other significant Internet or computer activity), and may not collect, use or disclose information concerning that activity unless certain conditions are met.

Covered entities may engage in comprehensive online data collection if: they receive the express written consent of the individual or for the purpose of making such information accessible to the individual for the use by the individual.

Are there any exceptions to the consent requirements of the Act?

Yes, exceptions exist under section 106 of the Act.

Covered entities may disclose information to a service provider as long as it has obtained the initial consent to collect information and contractually prohibits the service provider from disclosing the information other than for purposes of carrying out the purpose for which the information was disclosed. However, the Act indicates that the covered entity remains responsible and liable for the protection of the information transferred to a service provider for processing.

Consent is also not required for collection, use or disclosure necessary for fraud detection, imminent danger or compliance with law.

In addition, consent under the Act is not necessary for the collection, use or disclosure of publicly available information. However, even publicly available information cannot be used by a covered entity for marketing purposes if the individual has opted out of such use.

Do covered entities have any obligation concerning the accuracy of information they collect, assemble or maintain?

Yes, section 201 of the Act requires covered entities to establish reasonable procedures to assure the accuracy of covered information or sensitive information they collect, assemble or maintain. This duty may be further fleshed out as section 201 requires the FTC to promulgate regulations to implement this section. Limited exceptions exist with respect to fraud databases and publicly available information.

Does the Act require the covered entity to provide individuals with access to covered information or sensitive information?

Yes, under section 202, covered entities are required to provide access to such information if such information may be used for purposes that could result in an adverse decision against the individual, including the denial of a right, benefit, or privilege. If the information could not reasonably result in an adverse decision, the covered entity is only required to provide a notice to the individual of the type of information the covered entity typically collects.

In addition, covered entities, upon request, must provide individuals with access to their personal files, but only if the entity stores such file in a manner that makes it accessible in the normal course of business.

However, none of the foregoing obligations apply to information retained for under 30 days.

Is there any time frame by which a covered entity must respond to a permitted access, correction or amendment request?

Yes, in general, under section 202(f), covered entities have thirty days from the receipt of such request to respond.

Does the Act impose any data security requirements with respect to covered information or sensitive information?

Yes, under section 302 of the Act each covered entity and service provider must establish, implement and maintain “reasonable and appropriate” administrative, technical and physical safeguards to:

• ensure the security, integrity, and confidentiality of the covered information or sensitive information it collects, assembles, or maintains

• protect against any anticipated threats, reasonably foreseeable vulnerabilities, or hazards to the security or integrity of such information; and

• protect against unauthorized access to or use of such information and loss, misuse, alteration, or destruction of such information.

The Act requires the FTC to promulgate regulations to implement this section.

Does the Act require covered entities to conduct any risk assessment with respect to its information handling practices?

Yes, under section 302 of the Act covered entities are required to conduct an assessment of the risks to individuals raised by its collection, use and disclosure of covered information or sensitive information prior to engaging in such activities (or if it believes there is a reasonable likelihood that it will engage in such activities), but only if such activities will involve more than 1 million individuals.

Does the Act require any audits or assessments?

Yes, covered entities must conduct periodic assessments to evaluate whether the covered/sensitive information it has collected remains necessary for the purposes described at the time of collection, and whether the covered entities’ ongoing collection practices remain necessary for legitimate business purposes.

Does the Act limit how long a covered entity can retain covered/sensitive information?

Yes, under section 303 of the Act covered entities may retain covered/sensitive information for only as long as necessary to fulfill a legitimate business purpose or comply with a legal requirement.

Coming up next in Part Two:  the “Safe Harbor” outlined in the Act, various exemptions for de-identified information and application and enforcement of the Act.

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.

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.
 

(3) SECURITY BREACH NOTICE (NRS 603A.220) What triggers the security breach notice obligations under the Security Law?

In order for the breach notice requirements to be triggered under the Security Law two general events must occur (with some sub-requirements discussed further below). First, there must have been a "breach of the security of the system data" discovered by a data collector or notified to a data collector. Second, "personal information" must have actually been acquired by an unauthorized person, or was "reasonably believed to have been acquired" by an unauthorized person. Some observations:

• "Reasonably believed" acquisitions. In some cases it may be very unclear as to whether any actual "acquisition" by an unauthorized person occurred. Forensic assessment may not yield enough information to reach a definitive conclusion on that issue. Nonetheless, if there is evidence of possible acquisition that outweighs contrary evidence, then reporting requirements may still apply under the "reasonably believed" standard. This standard is likely viewed as an objective standard - so even if the data collector subjectively believed that no acquisition occurred that belief would be tested against the available evidence with respect to the incident.

• Duty to investigate. Let's assume that an organization discovers a security breach, but the initial facts it receives do not provide any indication as to whether personal information was acquired by an unauthorized person. What if the company plugged the security hole and conducted no further investigation as to the question of acquisition? Is this permitted? Technically the answer appears to be 'yes.' That law does not impose any explicit duty to investigate whether personal information was acquired. As such, an organization could take the position that it never formed a reasonable belief of unauthorized acquisition, because it had no evidence of such acquisition. Whether this would hold up in court is another story, as some would argue that this complies with the letter of the law, but defeats its spirit. Moreover, the concept of "reasonable belief" may be argued to imply a reasonable investigation in order to form a belief one way or another.

What constitutes a security breach under the Nevada Security Law?

The Security Law sets forth a somewhat convoluted definition for "security breach." "Breach of the security of system data" is defined as: "unauthorized acquisition of computerized data that materially compromises the security, confidentiality or integrity of personal information maintained by the data collector." Some observations:

• No reference to systems. The security breach definition does not require breach of a particular network or system. Rather it focuses on unauthorized acquisition of computerized data. As such, it appears that it does not matter from which systems the data is taken as long as the data collector is "maintaining" the data. This would appear to include, for example, theft of a lap top, portable storage device or smart phone from an employee's car.

• 2-step process. Acquisition of computerized data containing personal information alone does not constitute a breach. In addition, there must be a material compromise of the security, confidentiality or integrity of personal information. In the event a thief could not get to the personal information (e.g. encryption or perhaps some sort of strong access control) then the Security Law would not be triggered.

• Material compromise. It is unclear how the concept of materiality is intended to work under this definition. For example, it seems that the security or confidentiality of personal information is either compromised or not compromised. Moreover, since the definition of personal information already requires a combination of first/last name and account numbers, it would seem that materiality is already built in. This reference may also refer to the volume of personal information exposed, but it is far from clear what the intent is.

What events must transpire for a notification duty to be triggered under the Security Law?

Unfortunately the definitions and requirements of the Security Law are somewhat convoluted. Breaking down the definition of "breach of the security of system data" and the trigger in section NRS 603A.220, it appears that the following events must occur:

(1) unauthorized acquisition of computerized data; AND

(2) a resulting material compromise of the security, confidentiality or integrity of personal information; AND

(3) discovery or notification of (1) and (2) by the data collector; AND

(4) a determination that unencrypted personal information of a Nevada resident was acquired by an unauthorized person; OR

(5) the existence of a reasonable belief that such personal information was acquired by an unauthorized person.

Some observations:

• Prerequisites. It appears that steps (1) through (3) are required before (4) and (5) come into play. If a "breach of the security of system data" as defined never occurs (see steps (1) and (2)) it cannot be discovered and you never get to (4) and (5) as part of your analysis. Moreover, obviously if there is no discovery or notification of the "breach of the security of system data" (step 3), then steps (4) and (5) cannot exist.

• Contradictory requirements concerning "reasonable belief" of acquisition. Steps (2) and (5) may be somewhat contradictory. Step (2) requires a determination as to whether a material compromise has occurred. There is no language indicating a trigger where the data collector has a "reasonable belief" that personal information has been compromised. In other words only if there has been an "actual" compromise of personal information will a "breach" have occurred (according to the definition of "breach of the security of system data"). For example, assume a laptop with personal information is stolen. Certainly there has been unauthorized acquisition of computerized data, but there may be no way to determine whether there has also been a material compromise of the security, confidentiality or integrity of personal information. Therefore, it would appear that one could reasonably argue that the data collector could not ascertain whether a "breach of the security of system data" existed, and therefore never "discovered" such a breach. That data collector would not even get to step (5) (which requires reporting if there is a reasonable belief of unauthorized acquisition) since step (2) is a pre-requisite to steps (4) and (5). Again, this is a very technical argument and it may be difficult to argue in court.

Who must provide notice of a security breach under the Nevada Security Law? And to whom?

Any data collector that owns or licenses computerized data which includes personal information must disclose a breach of that personal information to the Nevada resident that was impacted. Data collectors that have received computerized personal information from and owner or licensee (e.g. service providers) of computerized data must provide notice of a breach impacting computerized personal information immediately after discovering the breach. However, if a data collector is subject to and complies with the privacy and security provisions of the Gramm-Leach-Bliley Act, 15 U.S.C. §§ 6801 et seq., it is deemed in compliance with the Security Law and apparently need not comply with its requirements (although those subject to GLB should already have breach notice response programs in place). Some observations:

• Application to service providers. "Data collector" as defined makes no distinction between "data owners/controllers" and "service providers." Both fall into the definition of data collector as long as they are handling personal information.

• Service providers as "licensees" of personal information. Data controllers often use service providers to process personal information for on behalf of the data controller. In fact, in some cases the personal information may initially be provided directly to the service provider (e.g. data hosting or application service providers). Typically most interpret "ownership and licensing" of personal information to mean that the data controller (the company seeking to collect and use the data on the front-end of a transaction for its own purposes) is the party responsible for notice, even if the data controller's service provider was the entity that suffered the actual breach. This view is buttressed by the requirement in the Security Law that service providers provide owners and licensees immediate notice of a breach. However, it is possible for a service provider to also be considered a "licensee" of computerized data containing personal information. Service provider agreements often provide the service provider with a limited license to use data including personal information for purposes of processing on behalf of the original data owner. Even if not explicit, service providers may have an implied license to use computerized personal information for the limited purposes of processing a transaction for the data controller. It is not clear from the language of the statute whether a data collector must have received a license directly from the individual providing personal information, or whether a service provider's potential status as a "sub-licensee" of personal information creates a direct duty to report to Nevada residents.

Do the Security Law's breach notice obligations apply to "hard copies" or paper records?

No, breach notice obligations under this subsection of the Security Law only relate to computerized data which includes personal information. However, other sections of the Security Law (such as the record destruction section (603A.200) and the security measure section (603A.210)) apply to "records," which would appear to include hard copies/paper records.

Who how soon must notice be provided under the Nevada Security Law?

Following discovery of a breach and acquisition by an unauthorized person (or the establishment of a reasonable belief of such acquisition), "owners" and "licensees" must provide notice to the relevant individuals "in the most expedient time possible and without unreasonable delay." However, notification can be delayed if a law enforcement agency determines that the notification will impede a criminal investigation. Service providers that suffer a breach must provide notice to the owner or licensee of the personal information immediately following the discovery of a breach resulting in acquisition by an unauthorized person, or reasonably believed unauthorized acquisition.

Besides, Nevada residents and the owner or licensee of computerized personal information, are there any other parties to whom data collectors must provide notice?

If a data collector determines that notification is required under the Security Law to be provided to more than 1,000 persons at any one time, the data collector shall also notify, without unreasonable delay, any "consumer reporting agency that compiles and maintains files on consumers on a nationwide basis" (as that term is defined in 15 U.S.C. § 1681a(p)), of the time the notification is distributed and the content of the notification.

Up Next: Blog Post Three: Required Security Measures.

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