If privacy legislation gets passed by the Congress this year or next (although recent reports suggest a number of impasses between Republicans and Democrats), it might also contain language on data security standards. Such legislation would also likely direct the Federal Trade Commission (FTC) to conduct an Administrative Procedure Act (APA) rulemaking to promulgate regulations on privacy and data security. As most of the major bills provide that the FTC would use APA notice and comment procedure instead of the far lengthier Moss-Magnuson procedures, it is not far-fetched to envision FTC regulations on privacy and/or data security coming into effect, say, in the first year of the next Administration. However, what might FTC regulations on data security look like? Well, the FTC’s recent proposed update to the Safeguards Rule may provide a roadmap, but first a little background.
The “Financial Services Modernization Act of 1999” (P.L. 106-102) (aka Gramm-Leach-Bliley) required financial services regulators to promulgate regulations to “protect the security and confidentiality of…customers’ nonpublic personal information.” The FTC, among other regulators, were required to “establish appropriate standards for the financial institutions…relating to administrative, technical, and physical safeguards-
- (1) to insure the security and confidentiality of customer records and information;
- (2) to protect against any anticipated threats or hazards to the security or integrity of such records; and
- (3) to protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.”
The current Safeguards regulations were promulgated in May 2002 and reflect the thinking of the agency in the era before big data, widespread data breaches, smartphones, and other technological developments. Consequently, the regulations those financial services companies subject to FTC regulation under Gramm-Leach-Bliley now seem vague and almost permissive in light of best practices and requirements subsequently put in place for many entities. The current Safeguards rule is open-ended and allows the regulated entity the discretion and flexibility to determine what constitutes the “information security program” it must implement based on the entity’s “size and complexity, the nature and scope of your activities, and the sensitivity of any customer information at issue.” Covered entities must perform risk assessments to identify and ideally remediate foreseeable internal and external risks. Subsequently, the covered entity must then “[d]esign and implement information safeguards to control the risks you identify through risk assessment, and regularly test or otherwise monitor the effectiveness of the safeguards’ key controls, systems, and procedures.”
These regulations are not prescriptive and are more general in nature, or at least they seem so in retrospect. One would hope that any entities holding any modicum of sensitive consumer information is regularly and vigorously engaged in an ongoing practice of assessing and addressing risks. However, the repromulgation of the Safeguards rule suggest this may not be the case.
The FTC is using its very broad grant of authority under Gramm-Leach-Bliley to revisit the Safeguards Rule as part of its periodic sweep of its regulations. The FTC explained that when it issued the current Safeguards Rule in 2002 “it opted to provide general requirements and guidance for the required information security program, without providing detailed descriptions of what the information security program should contain.” The FTC claimed that“[i]t took this approach in order to provide financial institutions with the flexibility to shape the information security programs to their particular business and to allow the programs to adapt to changes in technology and threats to the security and integrity of customer information.” The FTC asserted its beliefthe new provisions “continue to provide companies with flexibility, they also attempt to provide more detailed guidance as to what an appropriate information security program entails.”
In the proposed changes to the Safeguards Rule, the FTC is calling for “more specific security requirements” that “will benefit financial institutions by providing them more guidance and certainty in developing their information security programs, while largely preserving that flexibility.” It is possible that in offering more detailed prescriptions that the FTC is responding to criticisms generally that its data security standards are vague. The FTC contends that the “proposed amendments provide more detailed requirements as to the issues and threats that must be addressed by the information security program, but do not require specific solutions to those problems.” The Commission claims “the proposed amendments retain the process-based approach of the Rule, while providing a more detailed map of what information security plans must address.”
The FTC explains
These amendments are based primarily on the cybersecurity regulations issued by the New York Department of Financial Services, 23 NYCRR 500 (“Cybersecurity Regulations”), and the insurance data security model law issued by the National Association of Insurance Commissioners (“Model Law”).The Cybersecurity Regulations were issued in February 2017 after two rounds of public comment. The Model Law was issued in October 2017. The Commission believes that both the Cybersecurity Regulations and the Model Law maintain the balance between providing detailed guidance and avoiding overly prescriptive requirements for information security programs. The proposed amendments do not adopt either law wholesale, instead taking portions from each and adapting others for the purposes of the Safeguards Rule.
However, the FTC does not merely lift provisions from each but rather uses these as guidelines in drafting its own regulations, and the agency picks, chooses, modifies and discards from the regulations. Going over the three sets of data security requirements and providing a detailed analysis is outside the scope of this article. Rather, I would like to hit some of the high points by way of illustrating both the FTC’s reliance on the two predecessor schemes and also to show how the agency’s thinking on what constitutes adequate data security has evolved since 2002.
The FTC’s proposed Safeguards rule would generally require covered entities to encrypt consumer’s personal information when at rest and in transit on external systems. Similarly, the use of multi-factor authentication would be required in most circumstances, and covered entities would need to engage in regular penetration testing.
As a threshold matter, the Commission defines what a “security event” is and how regulated entities must gear their data security to preventing or reducing the risk that a “security event” occurs. Under the currently effective regulations, there is no definition. The agency proposes that a “security event” will mean “an event resulting in unauthorized access to, or disruption or misuse of, an information system or information stored on such information system.” In the Federal Register notice, the FTC explained that “[t]his term is used in proposed provisions requiring financial institutions to establish written incident response plans designed to respond to security events and to implement audit trails to detect and respond to security events.”
The FTC would generally require “covered entities” to encrypt consumer information at rest or in transit subject to a significant exception. The agency’s reasoning seems to be that encryption would be used for sensitive consumer information and when it is not prohibitively difficult or expensive to do so. However, The NAIC model statute charges regulated entities to “[d]etermine which security measures…are appropriate and implement such security measures” including encryption whereas the NYDFS would require the use of encryption of nonpublic information at rest or transmitted by covered entities unless it has been determined doing either would be “infeasible,” a decision that the entity’s CISO may agree with. The FTC followed the NYDFS in substantial part and the language on the exemption to the requirement that encryption must be used follows word for word: “[t]o the extent you determine that encryption of customer information, either in transit over external networks or at rest, is infeasible, you may instead secure such customer information using effective alternative compensating controls reviewed and approved by your CISO.” It is not clear, moreover, under this loophole what would stop organizations regulated by the FTC to make this determination, for it appears the agency would have limited recourse in questioning the covered entity’s decision not to encrypt customer data. It is unclear if the FTC will keep this provision in the final regulation. In contrast, the NYDFS requires the CISO to revisit such decisions annually.
Tellingly, however, the FTC opted against the safe harbors the NAIC model statute offers if entities have encrypted the exfiltrated or accessed data and the encryption, process or key has not also been breached. The NYDFS also does not have such a safe harbor to what constitutes a security event that triggers the reporting and notification requirements. Nonetheless, the FTC lifts its definition for encryption almost word-for-word from the NAIC model statute.
Another new requirement for covered entities is the use of multi-factor authentication. The FTC’s draft regulations provide that “[i]n order to develop, implement, and maintain your information security program, you shall…[d]esign and implement safeguards to control the risks you identity through risk assessment, including…multi-factor authentication.” The agency defines multi-factor authentication as “authentication through verification of at least two of the following types of authentication factors:
- (1) Knowledge factors, such as a password;
- (2) Possession factors, such as a token; or
- (3) Inherence factors, such as biometric characteristics.”
The FTC explained that it “views multi-factor authentication as a minimum standard to allowing access to customer information for most financial institutions…[and] believes that the definition of multi-factor authentication is sufficiently flexible to allow most financial institutions to develop a system that is suited to their needs.” Nonetheless, “[t]he Commission seeks comment on whether this definition is sufficiently flexible, while still requiring the elements of meaningful multi-factor authentication.”
Like the NYDFS and NAIC standards, the FTC would require “information systems under the Rule to include audit trails designed to detect and respond to security events.” The agency uses a National Institute of Standards and Technology (NIST) definition of audit trail: “chronological logs that show who has accessed an information system and what activities the user engaged in during a given period.” The FTC noted that this standard will “not require any specific type of audit trail, nor does it require that every transaction be recorded in its entirety,” but, crucially, “the audit trail must be designed to allow the financial institution to detect when the system has been compromised or when an attempt to compromise has been made.” Also, the FTC will not require that audit trails be retained for any set period of time; rather, covered entities must hold them for a “reasonable” period of time. What should be the FTC’s expectations on maintaining audit trails that date back to “security event” that first occurred two years before it was discovered? Is two years a reasonable period of time to store audit rail materials?
Similarly, the draft Safeguards rule would “require financial institutions to take steps to monitor those users and their activities related to customer information in a manner adapted to the financial institution’s particular operations and needs.” The FTC noted that “[t]he monitoring should allow financial institutions to identify inappropriate use of customer information by authorized users, such as transferring large amounts of data or accessing information for which the user has no legitimate use.”
The FTC would bolster the current mandate that covered financial institutions “[r]egularly test or otherwise monitor the effectiveness of the safeguards’ key controls, systems, and procedures, including those to detect actual and attempted attacks on, or intrusions into, information systems.” The agency calls for “either ‘continuous monitoring’ or ‘periodic penetration testing and vulnerability assessments.’” However, in lieu of continuous monitoring, the FTC is willing to accept annual penetration testing and biannual vulnerability testing “reasonably designed to identify publicly known security vulnerabilities in your information systems based on the risk assessment.”
Finally, the FTC is proposing to carve out very small institutions that would otherwise fall within the scope of the rule because they “maintain relatively small amounts of customer information.” As a result, the draft Safeguards rule would exempt small covered entities from needing to:
- 314.4(b)(1), requiring a written risk assessment;
- 314.4(d)(2), requiring continuous monitoring or annual penetration testing and biannual vulnerability assessment;
- 314.4(h), requiring a written incident response plan; and
- 314.4(i), requiring an annual written report by the CISO.
The FTC articulated its belief that these are the requirements most likely “to cause undue burden on smaller financial institutions.”
The FTC seems to be balancing the expense imposed on these smaller institutions with presumably less resources for compliance against the mandate of Gramm-Leach-Bliley to safeguard customer records and information. But, on its face, the underlying statute does not seem to delegate authority to the FTC to exempt small entities unless the directive to “establish appropriate standards” can be read as a grant of discretion in how the agency meets this Congressional mandate (emphasis added).
And yet, putting aside that issue for the moment, one wonders why the agency drew the line at those institutions that “maintain customer information concerning fewer than five thousand consumers.” Is there a quantitative difference between the resources available to businesses of this size and those “maiantain[ing]” the consumer records and information of 7,500 or 10,000 or 20,000 consumers? Also, how exactly will maintain be construed? Will it be an annual average of the consumer information held by an institution? A monthly average? A threshold that an entity clears once and then the Safeguards’ requirements attach? The agency did not explain its thinking on this point.
Incidentally, the FTC actually split on the proposed Safeguards regulation with Commissioners Noah Joshua Phillips and Christine S. Wilson issuing a dissenting statement, in which they extol the virtues of the current rule and assert the proposed regulation “trades flexibility for a more prescriptive approach, potentially handicapping smaller players or newer entrants.” This may suggest a future FTC may not propose a similarly prescriptive approach for privacy and/or data security regulations under to be enacted legislation.
And yet, regardless of whether the FTC does proceed in this fashion,
might the agency’s thinking on what constitutes acceptable data security under the
powers granted by Section 5 of the FTC Act begin to resemble the more directive
regime under the Safeguards rule? Given that the agency has not exactly spelled
out what is “reasonable” data security, the general requirements for
encryption, multi-factor authentication, and penetration testing could well get
folded into what the FTC considers the sorts of practices entities will need to
use in order not to violate the ban on deceptive and unfair practices.
 In LabMD, Inc. vs. FTC, the Eleventh Circuit ruled against the FTC’s use of its Section 5 powers to enter into settlements requiring private entities to establish and maintain remedial, “reasonable” data security practices. The court held that such settlements are contrary to the FTC Act because they do not enjoin specific acts or practices and rather command entities to institute data security practices. The court also found that such settlements are ultimately unenforceable because they are vague as to what is a reasonable data security regime.