Standards for Safeguarding Customer Information

Federal RegisterDec 9, 2021

Ask Donna

What actually matters in this document.

Text

FEDERAL TRADE COMMISSION

16 CFR Part 314

RIN 3084-AB35

Standards for Safeguarding Customer Information

AGENCY:

Federal Trade Commission.

ACTION:

Final rule.

SUMMARY:

The Federal Trade Commission (“FTC” or “Commission”) is issuing a final rule (“Final Rule”) to amend the Standards for Safeguarding Customer Information (“Safeguards Rule” or “Rule”). The Final Rule contains five main modifications to the existing Rule. First, it adds provisions designed to provide covered financial institutions with more guidance on how to develop and implement specific aspects of an overall information security program, such as access controls, authentication, and encryption. Second, it adds provisions designed to improve the accountability of financial institutions' information security programs, such as by requiring periodic reports to boards of directors or governing bodies. Third, it exempts financial institutions that collect less customer information from certain requirements. Fourth, it expands the definition of “financial institution” to include entities engaged in activities the Federal Reserve Board determines to be incidental to financial activities. This change adds “finders”—companies that bring together buyers and sellers of a product or service—within the scope of the Rule. Finally, the Final Rule defines several terms and provides related examples in the Rule itself rather than incorporates them from the Privacy of Consumer Financial Information Rule (“Privacy Rule”).

DATES:

Effective date:

This rule is effective January 10, 2022.

Applicability date:

The provisions set forth in § 314.5 are applicable beginning December 9, 2022.

FOR FURTHER INFORMATION CONTACT:

David Lincicum (202-326-2773), Katherine McCarron (202-326-2333), or Robin Wetherill (202-326-2220), Division of Privacy and Identity Protection, Bureau of Consumer Protection, Federal Trade Commission, 600 Pennsylvania Avenue NW, Washington, DC 20580.

SUPPLEMENTARY INFORMATION:

I. Background

Congress enacted the Gramm Leach Bliley Act (“GLB” or “GLBA”) in 1999.

1

The GLBA provides a framework for regulating the privacy and data security practices of a broad range of financial institutions. Among other things, the GLBA requires financial institutions to provide customers with information about the institutions' privacy practices and about their opt-out rights, and to implement security safeguards for customer information.

1

Pubic Law 106-102, 113 Stat. 1338 (1999).

Subtitle A of Title V of the GLBA required the Commission and other Federal agencies to establish standards for financial institutions relating to administrative, technical, and physical safeguards for certain information.

2

Pursuant to the Act's directive, the Commission promulgated the Safeguards Rule (16 CFR part 314) in 2002. The Safeguards Rule became effective on May 23, 2003.

2

See

15 U.S.C. 6801(b), 15 U.S.C. 6805(b)(2).

The current Safeguards Rule requires a financial institution to develop, implement, and maintain a comprehensive information security program that consists of the administrative, technical, and physical safeguards the financial institution uses to access, collect, distribute, process, protect, store, use, transmit, dispose of, or otherwise handle customer information.

3

The information security program must be written in one or more readily accessible parts.

4

The safeguards set forth in the program must be appropriate to the size and complexity of the financial institution, the nature and scope of its activities, and the sensitivity of any customer information at issue.

5

The safeguards must also be reasonably designed to ensure the security and confidentiality of customer information, protect against any anticipated threats or hazards to the security or integrity of the information, and protect against unauthorized access to or use of such information that could result in substantial harm or inconvenience to any customer.

6

3

16 CFR 314.2(c).

4

16 CFR 314.3(a).

5

16 CFR 314.3(a), (b).

6

16 CFR 314.3(a), (b).

In order to develop, implement, and maintain its information security program, a financial institution must identify reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information that could result in the unauthorized disclosure, misuse, alteration, destruction, or other compromise of such information.

7

The financial institution must then design and implement safeguards to control the risks identified through the risk assessment, and must regularly test or otherwise monitor the effectiveness of the safeguards' key controls, systems, and procedures.

8

The Rule also requires the financial institution to evaluate and adjust its information security program in light of the results of this testing and monitoring, any material changes in its operations or business arrangements, or any other circumstances it knows or has reason to know may have a material impact on its information security program.

9

The financial institution must also designate an employee or employees to coordinate the information security program.

10

7

16 CFR 314.4(b).

8

16 CFR 314.4(c).

9

16 CFR 314.4(e).

10

16 CFR 314.4(a).

Finally, the current Safeguards Rule requires financial institutions to take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards for customer information and require those service providers by contract to implement and maintain such safeguards.

11

11

16 CFR 314.4(d).

II. Regulatory Review of the Safeguards Rule

On September 7, 2016, the Commission solicited comments on the Safeguards Rule as part of its periodic review of its rules and guides.

12

The Commission sought comment on a number of general issues, including the economic impact and benefits of the Rule; possible conflicts between the Rule and state, local, or other Federal laws or regulations; and the effect on the Rule of any technological, economic, or other industry changes. The Commission received 28 comments from individuals and entities representing a wide range of viewpoints.

13

Most commenters agreed there is a continuing need for the Rule and it benefits consumers and competition.

14

12

Safeguards Rule, Request for Comment, 81 FR 61632 (Sept. 7, 2016).

13

The 28 public comments received prior to March 15, 2019, are posted at:

https://www.ftc.gov/policy/public-comments/initiative-674.

14

See, e.g.,

Mortgage Bankers Association

(

comment 39, NPRM); National Automobile Dealers Association (Comment 40, NPRM); Data & Marketing Association (comment 38, NPRM); Electronic Transactions Association (comment 24, NPRM); State Privacy & Security Coalition (comment 26, NPRM).

On April 4, 2019, the Commission issued a notice of proposed rulemaking (NPRM) setting forth proposed amendments to the Safeguards Rule (the “Proposed Rule”).

15

In response, the Commission received 49 comments from various interested parties

including industry groups, consumer groups, and individual consumers.

16

On July 13, 2020, the Commission held a workshop concerning the proposed changes and conducted panels with information security experts discussing subjects related to the Proposed Rule.

17

The Commission received 11 comments following the workshop.

18

After reviewing the initial comments to the Proposed Rule, conducting the workshop, and then reviewing the comments received following the workshop, the Commission now issues final amendments to the Safeguards Rule.

15

FTC Notice of Proposed Rulemaking, 84 FR 13158 (April 4, 2019).

16

The 49 relevant public comments received on or after March 15, 2019, can be found at

Regulations.gov

.

See

FTC Seeks Comment on Proposed Amendments to Safeguards and Privacy Rules, 16 CFR part 314, Project No. P145407,

https://www.regulations.gov/docket/FTC-2019-0019/document.

17

See

FTC, Information Security and Financial Institutions: An FTC Workshop to Examine Safeguards Rule Tr. (July 13, 2020),

https://www.ftc.gov/system/files/documents/public_events/1567141/transcript-glb-safeguards-workshop-full.pdf

[hereinafter Safeguards Workshop Tr.].

18

The 11 relevant public comments relating to the subject matter of the July 13, 2020, workshop can be found at

https://www.regulations.gov/document/FTC-2020-0038-0001.

This document cites comments using the last name of the individual submitter or the name of the organization, followed by the number based on the last two digits of the comment ID number.

III. Overview of Final Rule

As noted above, the Final Rule modifies the current Rule in five primary ways. First, the Final Rule amends the current Rule to include more detailed requirements for the development and establishment of the information security program required under the Rule. For example, while the current Rule requires financial institutions to undertake a risk assessment and develop and implement safeguards to address the identified risks, the Final Rule sets forth specific criteria for what the risk assessment must include, and requires the risk assessment be set forth in writing. As to particular safeguards, the Final Rule requires that they address access controls, data inventory and classification, encryption, secure development practices, authentication, information disposal procedures, change management, testing, and incident response. And while the Final Rule retains the requirement from the current Rule that financial institutions provide employee training and appropriate oversight of service providers, it adds mechanisms designed to ensure such training and oversight are effective. Although the Final Rule has more specific requirements than the current Rule, it still provides financial institutions the flexibility to design an information security program appropriate to the size and complexity of the financial institution, the nature and scope of its activities, and the sensitivity of any customer information at issue.

Second, the Final Rule adds requirements designed to improve accountability of financial institutions' information security programs. For example, while the current Rule allows a financial institution to designate one or more employees to be responsible for the information security program, the Final Rule requires the designation of a single Qualified Individual. The Final Rule also requires periodic reports to boards of directors or governing bodies, which will provide senior management with better awareness of their financial institutions' information security programs, making it more likely the programs will receive the required resources and be able to protect consumer information.

Third, recognizing the impact of the additional requirements on small businesses, the Final Rule exempts financial institutions that collect information on fewer than 5,000 consumers from the requirements of a written risk assessment, incident response plan, and annual reporting to the Board of Directors.

Fourth, the Final Rule expands the definition of “financial institution” to include entities engaged in activities the Federal Reserve Board determines to be incidental to financial activities. This change brings “finders”—companies that bring together buyers and sellers of a product or service—within the scope of the Rule. Finders often collect and maintain very sensitive consumer financial information, and this change will require them to comply with the Safeguards Rule's requirements to protect that information. This change will also bring the Rule into harmony with other Federal agencies' Safeguards Rules, which include activities incidental to financial activities in their definition of financial institution.

Finally, the Final Rule includes several definitions and related examples, including of “financial institution,” in the Rule itself rather than incorporate them from a related FTC rule, the Privacy of Consumer Financial Information Rule, 16 CFR part 313. This will make the rule more self-contained and will allow readers to understand its requirements without referencing the Privacy Rule.

IV. Section-by-Section Analysis

General Comments

The Commission received 49 comments in response to the NPRM for the Proposed Rule, from a diverse set of stakeholders, including industry groups, individual businesses, consumer advocacy groups, academics, information security experts, government agencies, and individual consumers. It also hosted a workshop on the Proposed Rule, which included approximately 20 security experts. Some of the comments simply expressed general support

19

or general disapproval

20

of the Proposed Rule. Many, however, offered detailed responses to specific proposals in the NPRM. In general, industry groups were opposed to most or all of the Proposed Rule, and consumer advocacy groups, academics, and security experts were generally in favor of the amendments. The comments and workshop record are discussed in the following Section-by-Section analysis.

19

See

Encore Capital Group (comment 25, NPRM); Justine Bykowski (comment 12, NPRM); “Peggy from Bloomington, MN” (comment 13, NPRM); “Anonymous” (comment 20, NPRM).

20

“Jane Q. Citizen” (comment 14, NPRM).

Sec. 314.1: Purpose and Scope

The Purpose and Scope section of the current Rule generally states the Rule implements the Gramm-Leach-Bliley Act and applies to the handling of customer information by financial institutions over which the FTC has jurisdiction. In its NPRM, the Commission proposed adding a definition of “financial institution” modeled on the definition included in the Commission's Privacy Rule (16 CFR part 313) and a series of examples providing guidance on what constitutes a financial institution under the Commission's jurisdiction. Other than expanding the definition of “financial institution” as discussed below, the new language was not meant to reflect a substantive change to the Safeguards Rule; rather, it was meant to allow the Rule to be read on its own, without reference to the Privacy Rule.

21

The Commission received no comments that addressed this section specifically, and

the Commission adopts the language of the Proposed Rule in the Final Rule.

22

21

In a separate final rule, published elsewhere in this issue of the

Federal Register

, the Commission is amending the Privacy Rule to reflect changes made by the Dodd-Frank Act, limiting that rule to certain auto dealers. Through that proceeding, the Commission is also removing examples of financial institutions from the Privacy Rule that are no longer covered under the rule in the wake of these changes.

22

Several commenters addressed the change to the definition of “financial institution.” Those comments are addressed in the discussion of the definition of “financial institution” below.

Sec. 314.2: Definitions

The Proposed Rule added a number of definitions to § 314.2. The Proposed Rule also retained paragraph (a), which states terms used in the Safeguards Rule have the same meaning as set forth in the Privacy Rule.

The American Council on Education (ACE) suggested all terms from the Privacy Rule, such as “consumer,” “customer,” and “customer information,” be included in the Final Rule in order to make the Final Rule easier for regulated entities to understand.

23

On the other hand, HITRUST recommended no definitions from the Privacy Rule be duplicated in the Safeguards Rule, reasoning that in the event of a need to amend the terms, it would require the amendment of two rules rather than one.

24

23

American Council on Education (comment 24, NPRM), at 7.

24

HITRUST, (comment 18, NPRM), at 2.

The Commission is persuaded including all terms from the Privacy Rule within the Safeguards Rule will improve clarity and ease of use. Accordingly, the Commission has determined to delete paragraph (a), since it is no longer necessary to state all terms in the Safeguards Rule have the same meaning as in the Privacy Rule. It also adds the Privacy Rule definitions of “consumer,” “customer,” “customer relationship,” “financial product or service,” “nonpublic personal information,” “personally identifiable financial information,” “publicly available information,” and “you” to the definitions in the Final Rule. No substantive change to these definitions is intended.

Authorized User

The Proposed Rule added a definition for the term “authorized user” as paragraph (b). Proposed paragraph (b) defined an authorized user of an information system as any employee, contractor, agent or other person that participates in your business operations and is authorized to access and use any of your information systems and data. This term was used in § 314.4(c)(10) of the Proposed Rule, which required financial institutions to implement policies to monitor the activity of “authorized users” and detect unauthorized access to customer information.

The Commission received one comment on this proposed definition from the National Automobile Dealers Association (NADA), which suggested the term “authorized user” was used inconsistently and was too vague.

25

NADA pointed out while “authorized user” is a defined term, the term “authorized individual” was used in proposed § 313.4(c)(1) (addressing access controls for information systems) and (c)(3) (addressing access controls for physical data). NADA also argued the inclusion of “other person that participates in the business operations of an entity” within the definition of “authorized user” was unclear and created ambiguity in its application.

26

25

National Automobile Dealers Association (comment 46, NPRM), at 11-12.

26

National Automobile Dealers Association (comment 46, NPRM), at 11-12.

The Commission agrees with NADA's points, and, in response, modifies the Final Rule in two ways. First, the Final Rule replaces the term “authorized individual” with “authorized user” in § 313.4(c)(1). As described further below, because the Final Rule combines § 313.4(c)(3) with § 313.4(c)(1), there is no need to make a corresponding change to that section.

Second, because the Commission agrees the ambiguities in the definition of “authorized user” from the Proposed Rule could create confusion, it makes several changes to the definition. It deletes the phrase “other person that participates in the business operations of an entity.” The Commission agrees this phrase was vague. The Commission had intended it to cover any person the financial institution allows to access information systems or data, including, for example, “customers” of the financial institutions. For the purpose of controlling authorized access and detecting unauthorized access (which is where the definition of “authorized user” appears), financial institutions should monitor anomalous patterns of usage of their systems, not only by employees and agents, but also by customers and other persons authorized to access systems or data. To clarify this point, the Commission adds “customer or other person” to the definition of “authorized users.”

The Commission intends that the definition of “authorized users” should include anyone who the financial institution authorizes to access an information system or data, regardless of whether that user actually uses the data. Thus, for clarity, the Commission has deleted the requirement that the authorized user be authorized

to use

the information system or data. Finally, the definition of authorized user should include users who can access both “information systems and data” and users authorized to access either information systems

or

data. Accordingly, for clarification purposes, the Commission modifies the definition of authorized user in the Final Rule as any employee, contractor, agent, customer or other person that is authorized to access any of your information systems or data.

Security Event

In proposed paragraph (c), the Commission defined security event as an event resulting in unauthorized access to, or disruption or misuse of, an information system or information stored on such information system. This term was used in provisions requiring financial institutions to establish a written incident response plan designed to respond to security events. It also appeared in the provision requiring the coordinator of a financial institution's information security program to provide an annual report to the financial institution's governing body; the required report must identify all security events that took place that year.

Commenters expressed three main concerns with this definition. The first relates to whether the term “security event” should be expanded to instances in which there is unauthorized access to, or disruption or misuse of, information in physical form, as opposed to electronic form. The Proposed Rule used the term “security event” instead of “cybersecurity event” to clarify that an information security program encompasses information in both digital and physical forms and that unauthorized access to paper files, for example, would also be a security event under the Rule. The Money Services Round Table (MSRT), however, noted despite the use of the more general “security” in the defined term, the definition itself is limited to events involving information systems.

27

The Commission agrees this creates a contradiction. Accordingly, the Final Rule includes the compromise of customer information in physical form in the definition of “security event.”

27

Money Services Round Table (comment 53, NPRM), at 5 n.14.

Second, some industry groups argued a “security event” should occur only when there is “unauthorized access” to an information system, not in cases in which there has been a “disruption or misuse” of such systems (

e.g.,

a ransomware attack).

28

These

commenters argued the disruption or misuse of information systems is not directly related to the protection of customer information and is, therefore, outside the Commission's statutory authority.

29

The Commission disagrees. Requiring a financial institution to protect against disruption and misuse of its information system is within the Commission's authority under the GLBA, which directed the Commission to promulgate a rule that required financial institutions to “to protect against any anticipated threats or hazards to the security or integrity” of customer information. A disruption or misuse of an information system will be, in many cases, a threat to the “integrity” of customer information. In addition, disruption or misuse may also indicate the existence of a security weakness that could be exploited to gain unauthorized access to customer information. For example, an event in which ransomware placed on a system is used to encrypt customer information, rendering it useless, raises the possibility similar software could have been used to exfiltrate customer information. Accordingly, the Final Rule retains the inclusion of “misuse or disruption” within the definition of “security event.”

28

National Independent Automobile Dealers Association (comment 48, NPRM), at 4; National

Automobile Dealers Association (comment 46, NPRM), at 12-13; Consumer Data Industry Association (comment 36, NPRM), at 3-4.

29

National Independent Automobile Dealers Association (comment 48, NPRM), at 4; National Automobile Dealers Association (comment 46, NPRM), at 12-13.

Third, several commenters suggested the definition of “security event” be limited to events in which there is a risk of consumer harm or some other negative effect.

30

Similarly, some commenters argued the definition should exclude events that involve encrypted information in which the encryption key was not compromised or when there is evidence the information accessed has not been misused.

31

The Commission declines to narrow the provision in this manner. It believes a financial institution should still engage in its incident response procedures to determine whether the event indicates a weakness that could endanger customer information and to respond accordingly. The financial institution can then take the appropriate steps in response. Further, § 314.4(h) of the Final Rule, which sets forth the requirement for an incident response plan, requires the incident response plan be designed to respond only to security events “materially affecting the confidentiality, integrity, or availability of customer information,” limiting the impact of the definition of “security event.”

30

HITRUST (comment 18, NPRM), at 3; American Council on Education (comment 24, NPRM), at 7; Mortgage Bankers Association (comment 26, NPRM), at 4-5; Consumer Data Industry Association (comment 36, NPRM), at 3-4; National Automobile Dealers Association (comment 46, NPRM), at 12-13; National Independent Automobile Dealers Association (comment 48, NPRM), at 4.

31

Mortgage Bankers Association (comment 48, NPRM), at 4-5; National Automobile Dealers Association (comment 46, NPRM), at 12-13; National Independent Automobile Dealers Association (comment 48, NPRM) at 4; American Council on Education (comment 24, NPRM), at 7.

Accordingly, the Final Rule defines security event as an event resulting in unauthorized access to, or disruption or misuse of, an information system, information stored on such information system, or customer information held in physical form. The Proposed Rule placed this definition as paragraph (c), out of alphabetical order. The Final Rule adopts it as paragraph (p), placing it in alphabetical order with the other definitions in § 314.2.

Encryption

Proposed paragraph (e) defined encryption as the transformation of data into a form that results in a low probability of assigning meaning without the use of a protective process or key. This term was used in proposed § 314.4(c)(4), which generally required financial institutions to encrypt customer information. This definition was intended to define the process of encryption while not requiring any particular technology or technique for achieving the protection provided by encryption.

NADA argued this definition should be made more flexible by adding an alternative so it would read “the transformation of data into a form that results in a low probability of assigning meaning without the use of a protective process or key

or securing information by another method that renders the data elements unreadable or unusable”

(emphasis added).

32

On the other hand, others argued the Proposed Rule's definition did not sufficiently protect customer information.

33

For example, the Princeton University Center for Information Technology Policy (“Princeton Center”) suggested the Rule should be changed “to clarify that encryption must be consistent with current cryptographic standards and accompanied by appropriate safeguards for cryptographic key material.”

34

Similarly, ACE argued the definition should include “the transformation of data in accordance with industry standards.”

35

32

National Automobile Dealers Association (comment 46, NPRM), at 13.

33

American Council on Education (comment 24, NPRM), at 7; Princeton University Center for Information Technology Policy (comment 54, NPRM), at 4.

34

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 4.

35

American Council on Education (comment 24, NPRM), at 7.

The Commission agrees the proposed definition should be tethered to some technical standard, without being too prescriptive about what that standard is. Under the proposed definition, as well as NADA's proposed definition, financial institutions could have claimed they were “encrypting” data if they were aggregating it, scrambling it, or redacting it in a way that made it possible to re-identify the data through, for example, the application of common algorithms or programs. The Commission does not believe this would have provided consumers with sufficient protection. The Commission also agrees with the commenters who stated the definition should signal that encryption should be cryptographically based.

Accordingly, the Final Rule defines encryption as the transformation of data into a form that results in a low probability of assigning meaning without the use of a protective process or key, consistent with current cryptographic standards and accompanied by appropriate safeguards for cryptographic key material. This definition does not require any specific process or technology to perform the encryption but does require that whatever process is used be sufficiently robust to prevent the deciphering of the information in most circumstances.

Financial Institution

Incidental Activity

The Proposed Rule made one substantive change to the definition of “financial institution” it incorporated from the Privacy Rule. The change was designed to include entities “significantly engaged in activities that are incidental to [] financial activity” as defined by the Bank Holding Company Act. This proposed change brought only one activity into the definition that was not covered before: the act of “finding” as defined in 12 CFR 225.86(d)(1). The proposed revision to paragraph (f) added an example of a financial institution acting as a finder by “bringing together one or more buyers and sellers of any product or service for transactions that the parties themselves negotiate and consummate.” This example used the language set forth in 12 CFR 225.86(d)(1), which defines “finding” as an activity incidental to a financial activity under the Bank Holding Company Act. The Commission

adopts this proposal without modification.

The change to the definition of “financial institution” brings it into harmony with other agencies' GLB rules.

36

The change is supported by the language of the Gramm-Leach-Bliley Act.

37

The Act defines a “financial institution” as any institution “the business of which is engaging in financial activities as described in section 1843(k) of title 12.”

38

That section, in turn, describes activities that are financial in nature as those the Board has determined “to be financial in nature or incidental to such financial activity.”

39

The Final Rule's definition mirrors this language. The change will not lead to a significant expansion of the Rule coverage as it expands the definition only to include entities engaged in activity incidental to financial activity, as determined by the Federal Reserve Board. The Board has determined only one activity to be incidental to financial activity—“acting as a finder.”

40

36

See

12 CFR 1016.3(l) (defining “financial institution” for entities regulated by agencies other than the FTC).

See also

17 CFR 248.3(n) (defining “financial institution” to include “any institution the business of which is . . . incidental to . . . financial activities” for Security and Exchange Commission's rule implementing GLBA's safeguard provisions.).

37

15 U.S.C. 6801

et seq.

38

15 U.S.C. 6809(3).

39

12 U.S.C. 1843(k).

40

12 CFR 225.86.

Several commenters who addressed this issue supported the inclusion of activities incidental to financial activities.

41

Other commenters expressed concern the proposed change in the definition would expand the Rule's coverage to businesses that should not be considered financial institutions.

42

They argued the definition of the term “finder” is too broad and companies that connect buyers and sellers in non-financial contexts would be swept inappropriately into the definition of “financial institution.” The Association of National Advertisers argued advertising agencies could be considered “finders” because they play a role in connecting buyers and sellers.

43

41

Electronic Privacy Information Center (comment 55, NPRM), at 9; Independent Community Bankers of America (comment 35, NPRM), at 3; National Automobile Dealers Association (comment 46, NPRM), at 13-16.

42

Association of National Advertisers (comment, Workshop), at 4-5; internet Association (comment, Workshop

),

at 4-5;

see also

Anonymous (comment 15, NPRM) (questioning whether any governing body would oversee any future determinations by the Federal Reserve Board that activities are incidental to financial activity).

43

Association of National Advertisers (comment 5, Workshop), at 5.

In response, the Commission notes the Federal Reserve Board describes acting as a finder as “bringing together one or more buyers and sellers of any product or service for transactions that the parties themselves negotiate and consummate.”

44

The Board sets forth several activities within the scope of acting as a finder, such as “[i]dentifying potential parties, making inquiries as to interest, introducing and referring potential parties to each other, [] arranging contacts between and meetings of interested parties” and “[c]onveying between interested parties expressions of interest, bids, offers, orders and confirmations relating to a transaction.”

45

44

12 CFR 225.86 (d).

45

12 CFR 225.86 (d)(1)(i).

Although this language is somewhat broad, its scope is significantly limited in the context of the Safeguards Rule. First, the Safeguards Rule applies only to transactions “for personal, family, or household purposes.”

46

Therefore, only finding services involving consumer transactions will be covered. Second, the Safeguards Rule applies only to the information of customers, which are consumers with which a financial institution has a continuing relationship.

47

Therefore, it will not apply to finders that have only isolated interactions with consumers and do not receive information from other financial institutions about those institutions' customers. This significantly narrows the types of finders that will have obligations under the Rule, excluding, the Commission believes, most advertising agencies and similar businesses that generally do not have continuing relationships with consumers who are using their services for personal or household purposes.

46

See

Final Rule 16 CFR 314.2(b)(1).

47

16 CFR 314.1; Final Rule 16 CFR 314.2(c).

The Commission believes entities that perform finding services for consumers with whom they have an ongoing relationship are properly considered “financial institutions” for purposes of the Rule. Accordingly, the Commission adopts the changes to the definition of “financial institution” as proposed.

Other Changes to Definition of “Financial Institutions”

Other commenters suggested modifying the definition of “financial institution”

48

in different ways. The Electronic Privacy Information Center (EPIC) argued the definition should be expanded by treating more activities as financial activities.

49

EPIC pointed out information shared with social media companies, retailers, apps, and devices generally is not covered under the Safeguards Rule. The Commission understands the concern that many businesses fall outside the coverage of the Safeguards Rule, despite handling sensitive consumer information, but the Commission's authority to regulate activity under the Safeguards and Privacy Rules is established by the GLBA. The Rule's application is limited to financial institutions as defined by that statute and cannot be extended beyond that definition.

50

The institutions discussed by EPIC, however, are still covered by the FTC Act's prohibition against deceptive or unfair conduct, including with respect to their use and protection of consumer information.

51

48

National Pawnbrokers Association (comment 32, NPRM), at 5-6 (arguing that transaction-reporting vendors be included in definition); National Consumer Law Center and others (comment 58, NPRM), at 5 (arguing that consumer reporting agencies be included explicitly in the definition);

see also

American Escrow Association (comment, Workshop), at 2-3 (requesting that the Rule specifically set out the duties of real estate settlement operations and other businesses that handle but do not maintain sensitive information); Beverly Enterprises, LLC (comment 3, NPRM), at 3-4 (requesting that the Rule specifically set out duties related to online notarizations); Yangxue Li (comment 5, NPRM) (asking whether Rule would set forth specific guidelines for different industries); Slobadon Raybolka (comment 17, NPRM) (suggesting that companies that perform online background checks be covered by the rule); The Clearing House (comment 49, NPRM) (suggesting a separate set of more stringent rules for fintech companies).

49

Electronic Privacy Information Center (comment 55, NPRM), at 9.

50

See

15 U.S.C. 6801 (requiring agencies to promulgate Rule establishing standards for financial institutions); 15 U.S.C. 6809(3) (defining “financial institutions” as an “institution the business of which is engaging in financial activities as described” in the Bank Holding Company Act).

51

In the Matter of

Facebook, Inc.,

Docket No. C-4365 (Apr. 28, 2020);

FTC

v.

Wyndham Worldwide Corporation,

799 F.3d 236 (3d Cir. 2015); FTC v.

D-Link Systems, Inc.,

Case No. 3:17-cv-00039-JD (N.D. Cal. July 2, 2019); In the Matter of

Twitter, Inc.,

Docket No. C-4316 (Mar. 11, 2011).

The National Federation of Independent Business (NFIB) argued individuals and sole proprietors should be excluded from the definition of “financial institution” because an individual cannot be an “institution.”

52

When the Privacy Rule was promulgated in 2000, commenters also suggested the definition should exclude sole proprietors.

53

The Commission noted there was no basis to exclude sole proprietors and “[w]hether or not a

commercial enterprise is operated by a single individual is not determinative” of whether the enterprise is a financial institution. The Commission has not changed its position on this matter and declines to make this change to the definition of “financial institution.”

52

National Federation of Independent Business (comment 16, NPRM), at 2-3.

53

Privacy Rule, Final Rule, 65 FR 33645 (May 24, 2000) at 33656.

The Final Rule adopts this definition as proposed without change.

Information Security Program

Paragraph (i) of the Final Rule adopts the existing Rule's paragraph (c) and does not alter the definition of “information security program.” The Commission received no comments on this definition, and accordingly, adopts the current definition in the Final Rule.

Information System

Proposed paragraph (h) defined information system as a discrete set of electronic information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of electronic information, as well as any specialized system such as industrial/process controls systems, telephone switching and private branch exchange systems, and environmental control systems. The term “information system” was used throughout the proposed amendments to designate the systems that must be covered by the information security program.

The MSRT suggested this definition was too narrow in some respects and too broad in others.

54

It argued the definition of “information system” was too narrow because it did not include physical systems or employees and would exclude them from some of the provisions of the Rule. Specifically, the MSRT argued that based on this definition, the penetration tests required by § 314.4(d)(2) would not be required to test “potential human vulnerabilities” such as social engineering or phishing.

55

The Commission does not agree. Penetration testing, as defined by the Final Rule, is a process through which testers “attempt to circumvent or defeat the security features of an information system.”

56

One way such security features are tested is through social engineering and phishing.

57

The fact that the testing involves employees with access to the information system, rather than just the system itself, does not exclude such tests from the definition of “penetration testing.” Attempted social engineering and phishing are important parts of testing the security of information systems and would not be excluded by this definition.

54

Money Services Round Table (comment 53, NPRM), at 5-6.

55

Id.

at 5.

56

Final Rule § 314.2(j).

57

Indeed, Workshop participant Scott Wallace noted, in conducting penetration testing, “the first thing [he does]” is generally to “prepare for the phishing campaign.” Remarks of Scott Wallace, Safeguards Workshop Tr.,

supra

note 17, at 131-32.

The MSRT also argued the definition was too broad, and was joined by other commenters in this concern.

58

These commenters shared a concern the proposed definition would include systems that are in no way connected to customer information and would require financial institutions to include all systems in their possession, regardless of their involvement with customer information. The Commission agrees the definition should be limited to those systems that either contain customer information or are connected to systems that contain customer information, and adds that limitation to the Final Rule. The Rule does not limit the definition to only those systems that contain customer information, because a common source of data breaches is a vulnerability in a connected system that an attacker exploits to gain access to the company's network and move within the network to obtain access to the system containing sensitive information.

59

Accordingly, the definition of information system in the Final Rule is modified to a discrete set of electronic information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of electronic information containing customer information or any such system connected to a system containing customer information, as well as any specialized system such as industrial/process controls systems, telephone switching and private branch exchange systems, and environmental controls systems, that contains customer information or that is connected to a system that contains customer information.

58

Money Services Round Table (comment 53, NPRM), at 5; Consumer Data Industry Association (comment 36, NPRM), at 4; American Council on Education (comment 24, NPRM), at 7-8.

59

See

Remarks of Serge Jorgensen, Safeguards Workshop Tr.,

supra

note 17, at 58-59 (noting cybersecurity attacks can take advantage of systems that are connected to the systems in which sensitive information is stored); Remarks of Tom Dugas, Safeguards Workshop Tr.,

supra

note 17, at 138 (noting a vulnerability in one system can result in the exposure of information maintained in another system);

see also

Remarks of Rocio Baeza, Safeguards Workshop Tr.,

supra

note 17, at 106-07 (noting the heightened importance of encryption in a context where numerous systems are connected); Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 107-08 (same).

Multi-Factor Authentication

Proposed paragraph (i) defined multi-factor authentication as authentication through verification of at least two of the following types of authentication factors: Knowledge factors, such as a password; possession factors, such as a token; or inherence factors, such as biometric characteristics. This term was used in proposed § 314.4(c)(6),

60

which required financial institutions to implement multi-factor authentication for individuals accessing networks that contain customer information.

60

Section 314.4(c)(5) in the Final Rule.

Several commenters argued the definition should explicitly include SMS text messages as an acceptable example of a possession factor or otherwise to be explicitly allowed.

61

The Proposed Rule did not include SMS text messages as an example of a possession factor.

62

Most commenters who addressed this issue interpreted this exclusion from the examples as forbidding financial institutions from using SMS text messages as a possession factor for multi-factor authentication. That is not the effect of this exclusion, however. The language of the definition neither prohibits nor recommends use of SMS text messages. Indeed, SMS text messages are not addressed at all. In some cases, use of SMS text messages as a factor may be the best solution because of its low cost and easy use, if its risks do not outweigh those benefits under the circumstances.

63

In other instances, however, the use of SMS text messages may not be a reasonable solution, such as when extremely sensitive information can be obtained through the access method being controlled, or when a more secure method can be used for a comparable price. A financial institution will need to evaluate the balance of risks for its situation. If, however, the Commission were to explicitly allow use of SMS text messages, this could be considered a safe harbor that would not require the company to consider risks associated with use of SMS text as a factor in a particular use case. Accordingly, the Final Rule does not include SMS text

messages in the examples of possession factors.

61

Electronic Transactions Association (comment 27, NPRM), at 4; U.S. Chamber of Commerce (comment 33, NPRM), at 9; CTIA (comment 34, NPRM), at 7-9; Global Privacy Alliance (comment 38, NPRM), at 9; National Automobile Dealers Association (comment 46, NPRM), at 29; National Independent Automobile Dealers Association (comment 48, NPRM), at 6.

62

See, e.g.,

NIST Special Publication 800-63B, Digital Identity Guidelines, 5.1.3.3 (restricting use of verification using the Public Switched Telephone Network (SMS or voice) as an “out-of-band” factor for multi-factor authentication).

63

See, e.g.,

Remarks of Wendy Nather, Safeguards Workshop Tr.,

supra

note 17, at 231-32.

The final Rule adopts the proposed definition of “multi-factor authentication” without change as paragraph (k) of this section.

Penetration Testing

Proposed paragraph (j) defined penetration testing as a test methodology in which assessors attempt to circumvent or defeat the security features of an information system by attempting penetration of databases or controls from outside or inside your information systems. This term was used in proposed § 314.4(d)(2), which required financial institutions to continually monitor the effectiveness of their safeguards or to engage in annual penetration testing. The Commission received no comments concerning this definition. The Final Rule adopts the definition from the Proposed Rule as paragraph (m) of this section.

Personally Identifiable Financial Information

To minimize cross-referencing to the Privacy Rule, as noted above, the Commission is adding several definitions to the Final Rule. One of these definitions is “personally identifiable financial information,” which is identical to the definition currently contained in the Privacy Rule. This term is included within the ambit of “customer information,” in both the existing Rule and the Final Rule.

The Princeton Center suggested expanding the definition of “personally identifiable financial information” from the Privacy Rule to include “aggregate information or blind data that does not contain personal identifiers such as account numbers, names, or addresses.”

64

The Princeton Center further suggested clarifying that, for information to not be considered “personally identifiable financial information,” the financial institution must be required to demonstrate the information is not “reasonably linkable” to individuals.

64

Princeton University Center for Information Technology Policy (comment 54, NPRM) at 9-10.

The Commission does not believe this amendment is necessary. The definition of “personally identifiable financial information” is already a broad one.

65

It includes not just information associated with types of personal information such as a name or address or account number, but also information linked to a persistent identifier (“any information you collect through an Internet `cookie' (an information collecting device from a web server”)).

66

While there may be some merit to limiting the exception for aggregate information or blind data to data that cannot be reasonably linkable to an individual, for purposes of a rule that can be periodically updated to keep up with changing technology, the current approach is more concrete and enforceable, and less subject to differences in interpretation.

65

See

16 CFR 313.3(o)(1).

66

16 CFR 313.3(o)(2)(i)(F).

Service Provider

Proposed paragraph (k) adopted the existing Rule's definition and does not alter the definition of “service provider.” The Commission received no comments on this definition and adopts it as paragraph (q) of the Final Rule.

Sec. 314.3: Standards for Safeguarding Customer Information

Proposed § 314.3, which required financial institutions to develop an information security program (paragraph (a)) and set forth the objectives of the Rule (paragraph (b)), was largely identical to the existing Rule. It changed only the requirement that “safeguards” be based on the elements set forth in § 314.4, by replacing “safeguards” with “information security program.” The Commission received no comments on this proposal and adopts it without change in the Final Rule.

Sec. 314.4: Elements

Proposed § 314.4 altered the current Rule's required elements of an information security program and added several new elements.

General Comments

The Commission received many comments addressing the new elements, both in favor of the changes and opposed to them. The comments in favor of the changes generally argued these changes would protect consumers by improving the data security of institutions that hold their information.

67

Most of the comments opposed to the proposed elements fell into several categories, objecting: (1) The proposed changes were too prescriptive and did not allow financial institutions sufficient flexibility in managing their information security; (2) the proposed amendments would be too expensive for financial institutions, particularly smaller institutions, to adopt; and (3) some of the requirements should not apply to all customer information but should be limited to some subset of especially “sensitive” customer information. The Commission does not agree with these comments for the reasons discussed below, and accordingly, retains the general approach of the Proposed Rule in the Final Rule.

67

See, e.g.,

New York Department of Financial Service (comment 40, NPRM), at 1 (arguing the Proposed Rule would “further advance efforts to protect financial institutions and consumers from cybercriminals.”); Princeton University Center for Information Technology Policy (comment 54, NPRM), at 1 (stating the Proposed Rule “would significantly reduce data security risks for the customers of financial institutions.”); National Consumer Law Center and others (comment 58, NPRM), at 2 (stating requirements of Proposed Rule are “reasonable and common-sense measures that any company dealing with large amounts of consumer personal information should take.”).

Flexibility

Many industry groups argued the new proposed elements were too prescriptive, lacked flexibility, would quickly become outdated, and would force financial institutions to engage in activities that would not enhance security.

68

For example, the Electronics Transactions Association argued the Proposed Rule would “limit the ability of industry to develop new and innovative approaches to information security.”

69

Similarly, CTIA commented the Proposed Rule would create a “prescriptive core of requirements that covered businesses must follow, irrespective of whether risk assessments show they are necessary.”

70

68

See, e.g.,

HITRUST (comment 18, NPRM), at 1-2; American Council on Education (comment 24, NPRM), at 2-4; Cristian Munarriz (comment 21, NPRM); Electronic Transactions Association (comment 27, NPRM), at 1-2; National Pawnbrokers Association (comment 32, NPRM), at 3; CTIA (comment 34, NPRM), at 5; Consumer Data Industry Association (comment 36, NPRM), at 2; Wisconsin Bankers Association (comment 37, NPRM), at 1-2; Global Privacy Alliance (comment 38, NPRM), at 5-6; Bank Policy Institute (comment 39, NPRM), at 2; American Financial Services Association (comment 41, NPRM), at 4; National Association of Dealer Counsel (comment 44, NPRM), at 1; ACA International, (comment 45, NPRM), at 4; National Automobile Dealers Association (comment 46, NPRM), at 11; National Independent Automobile Dealers Association (comment 48, NPRM), at 2-3; Money Services Round Table (comment 53, NPRM), at 1-4; Software & Information Industry Association (comment 56, NPRM), at 1-3; Gusto and others (comment 11, Workshop), at 2; Association of National Advertisers (comment 5, Workshop), at 1-3; internet Association (comment 9, Workshop), at 2-3.

69

Electronic Transactions Association (comment 27, NPRM), at 1-2.

70

CTIA (comment 34, NPRM), at 5.

The Commission, however, believes the elements provide sufficient flexibility for financial institutions to adopt information security programs suited to the size, nature, and complexity of their organization and information systems. The elements for the information security programs set forth in this section are high-level principles that set forth basic issues the

programs must address, and do not prescribe how they will be addressed. For example, the requirement that the information security program be based on a risk assessment sets forth only three general items the assessment must address: (1) Criteria for evaluating risks faced by the financial institution; (2) criteria for assessing the security of its information systems; and (3) how the identified risks will be addressed. Other than meeting these basic requirements, financial institutions are free to perform their risk assessments in whatever way they choose, using whatever method or approach works best for them, as long as the method identifies reasonably foreseeable risks. The other elements are similarly flexible. The two elements that are more prescriptive, encryption and multi-factor authentication, allow financial institutions to adopt alternative solutions when necessary. Comments concerning individual elements are addressed separately in the more detailed analysis below.

Cost

Another common theme among the comments from industry groups was the proposed information security program elements would be prohibitively expensive, especially for smaller businesses.

71

Commenters argued the Proposed Rule would have required financial institutions to implement expensive changes to their systems and hire highly-compensated professionals to do so.

72

Industry groups were particularly concerned about the requirement that financial institutions designate a single qualified individual to coordinate their information security programs, arguing this would require hiring professionals that were both expensive, with salaries of more than $100,000 suggested by some, and in limited supply.

73

Overall, several commenters argued some financial institutions would be unable to afford to bring themselves into compliance with the Proposed Rule.

74

71

American Council on Education (comment 24, NPRM), at 13-14; Wisconsin Bankers Association (comment 37, NPRM), at 1-2; American Financial Services Association (comment 41, NPRM), at 4; National Association of Dealer Counsel (comment 44, NPRM), at 1; National Automobile Dealers Association (comment 46, NPRM), at 11; National Independent Automobile Dealers Association, (comment 48, NPRM), at 3; Gusto and others (comment 11, Workshop), at 2-4; National Pawnbrokers Association (comment 3, NPRM), at 2;

see also

Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 72-74 (describing study that found compliance would be expensive for automobile dealers).

72

See, e.g.,

Slides Accompanying Remarks of James Crifasi, FTC, “NADA Cost Study: Average Cost Per U.S. Franchised Dealership,” Event Materials, Information Security and Financial Institutions: An FTC Workshop to Examine Safeguards Rule (July 13, 2020)

https://www.ftc.gov/system/files/documents/public_events/1567141/slides-glb-workshop.pdf

(hereinafter Safeguards Workshop Slides), at 25 (estimating an upfront cost of $293,975 per dealership, and an recurring annual cost of $276,925);

see also

Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 72-75; Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 78 (estimating the average annual salary of a CISO can range from $180,000 to upwards of $400,000); Slides Accompanying Remarks of Lee Waters, “Estimated Costs of Proposed Changes,” Safeguards Workshop Slides, at 26 (estimating the annual costs of a security program to include: Multi-factor authentication, $50 for smart card readers, and $10 each for smart cards; a CISO, either an in-house CISO, $180,000, an in-house cybersecurity analyst, $76,000, or an outsourced cybersecurity contractor, between $120,000 and $240,000; penetration testing, average cost $4,800; and physical security, $215,000 for construction, and $10,000 to $20,000 for new or upgraded locks)

; see also

Remarks of Lee Waters, Safeguards Workshop Tr.,

supra

note 17, at 75-76.

73

See, e.g.,

Slides Accompanying Remarks of Lee Waters, “Estimated Costs of Proposed Changes,” Safeguards Workshop Slides,

supra

note 72, at 26 (estimating costs of an in-house CISO to be $180,000 annually, and an in-house cybersecurity analyst to be $76,000 annually; and estimating an outsourced cybersecurity contractor would cost between $120,000 to $240,000 annually);

see also

Remarks of Lee Waters, Safeguards Workshop Tr.,

supra

note 17, at 75-76; Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 78 (estimating that the average annual salary of a CISO can range from $180,000 to upwards of $400,000).

74

See

Remarks of Lee Waters, Safeguards Workshop Tr.,

supra

note 17, at 119-20 (noting when small businesses have to spend money to hire third-party vendors and security experts to comply with regulations, that affects consumer prices and small business profit margins); Slides Accompanying Remarks of James Crifasi, “NADA Cost Study: Average Cost Per U.S. Franchised Dealership,” Safeguards Workshop Slides,

supra

note 72, at 25

; see also

Remarks of James Crifasi,

supra

note 17, at 73 (noting the requirements “start becoming a little bit unaffordable here.”).

The Commission recognizes properly securing information systems can be an expensive and technically difficult task. However, the Commission believes the additional costs imposed by the Proposed Rule are mitigated for several reasons and, ultimately, those costs are justified in order to protect customer information as required by the GLBA.

75

First, for almost 20 years, financial institutions have been required under the current Safeguards Rule to have information security programs in place. The current Safeguards Rule requires financial institutions to “develop, implement, and maintain a comprehensive [written] information security program . . . appropriate to [the financial institutions'] size and complexity, the nature and scope of [their] activities, and the sensitivity of any customer information at issue.”

76

This comprehensive program must be coordinated by one or more individuals and based on a risk assessment.

77

As such, financial institutions complying with the current Rule will not be required to establish an information security program from scratch. Instead, they can compare their existing programs to the revised Rule, and address any gaps. The Commission believes many of the requirements set forth in the Final Rule are so fundamental to any information security program that the information security programs of many financial institutions will already include them if those programs are in compliance with the current Safeguards Rule.

75

The Small Business Administration's Office of Advocacy commented it was concerned the FTC had not gathered sufficient data as to either the costs or benefits of the proposed changes for small financial institutions. Office of Advocacy, U.S. Small Business Administration (comment 28, NPRM), at 3-4. The FTC shares the Office of Advocacy's interest in ensuring that regulatory changes have an evidentiary basis. Many of the questions on which the FTC sought public comment, both in the regulatory review and in the proposed Rule context, specifically related to the costs and benefits of existing and proposed Rule requirements. Following the initial round of commenting, the Commission conducted the FTC Safeguards Workshop and solicited additional public comments with the explicit goal of gathering additional data relating to the costs and benefits of the proposed changes.

See

Public Workshop Examining Information Security for Financial Institutions and Information Related to Changes to the Safeguards Rule, 85 FR 13082 (Mar. 6, 2020). As detailed throughout this document, the Commission believes there is a strong evidentiary basis for the issuance of the final Rule.

76

16 CFR 314.3.

77

16 CFR 314.4.

Second, a number of commenters who raised concerns about the costs imposed by the Rule believed the Proposed Rule would have required the hiring of a highly-compensated expert to serve as a Chief Information Security Officer (CISO).

78

It is correct the Proposed Rule would have modified the current requirement of designating an “employee or employees to coordinate your information security program” by requiring the designation of a single qualified individual responsible for

overseeing and implementing the security program. This individual was referred to in the Proposed Rule as a Chief Information Security Officer or “CISO.” As discussed in detail below, the Final Rule does not use this term, though the concept is the same: The person designated to coordinate the information security program need only be “qualified.” No particular level of education, experience, or certification is prescribed by the Rule. Accordingly, financial institutions may designate any qualified individual who is appropriate for their business. Only if the complexity or size of their information systems require the services of an expert will the financial institution need to hire such an individual.

79

78

Several speakers at the Safeguards Workshop also raised this concern.

See, e.g.,

Slides Accompanying Remarks of James Crifasi, “NADA Cost Study: Average Cost Per U.S. Franchised Dealership,” in Safeguards Workshop Slides,

supra

note 72, at 25 (estimating appointing a CISO to increase program accountability would be a one-time, up-front cost of $27,500, with a recurring annual cost of $51,000); Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 72-75; Slides Accompanying Remarks of Lee Waters, “Estimated Costs of Proposed Changes,” in Safeguards Workshop Slides,

supra

note 72, at 26 (estimating costs of an in-house CISO to be $180,000 annually, and an in-house cybersecurity analyst to be $76,000 annually; and estimating that an outsourced cybersecurity contractor would cost between $120,000 to $240,000 annually); Remarks of Lee Waters, Safeguards Workshop Tr.,

supra

note 17, at 75-76; Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 78 (estimating that the average annual salary of a CISO can range from $180,000 to upwards of $400,000).

79

See, e.g.,

Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 89-90 (noting the size of a financial institution and the amount and nature of the information it holds factor into an appropriate information security program)

; see also

Slides Accompanying Remarks of Rocio Baeza, “Models for Complying to the Safeguards Rule Changes,” in Safeguards Workshop Slides,

supra

note 72, at 27-28 (describing three different compliance models: In-house, outsource, and hybrid, with costs ranging from $199 per month to more than $15,000 per month); Remarks of Rocio Baeza, Safeguards Workshop Tr.,

supra

note 17, at 81-83 (describing three compliance models in more detail).

Finally, the Commission believes while large financial institutions may well incur substantial costs to implement complex information security programs, there are much more affordable solutions available for financial institutions with smaller and simpler information systems. For example, there are very low-cost or even free vulnerability assessment programs available: “virtual CISO” services enable a third party to provide security support for many companies, splitting the cost of information security professionals among them; many applications and hardware have built-in encryption requirements;

80

and there are affordable multi-factor authentication solutions aimed at businesses of various sizes.

80

See

Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 78 (describing virtual CISO services).

Considering these points, although there will undoubtedly be expenses involved for some, or even many, financial institutions to update their programs, the Commission believes these expenses are justified because of the vital importance of protecting customer information collected, maintained, and processed by financial institutions. Congress recognized the importance of securing consumers' sensitive financial information when it passed the GLBA, which required the FTC to promulgate the Safeguards Rule. The importance, as well as the difficulty, of protecting customer information has only increased in the more than twenty years since the passage of the GLBA. The Commission believes the amendments to the Safeguards Rule are necessary to ensure the purposes of the GLBA are satisfied, and so consumers can have confidence financial institutions are providing reasonable safeguards to protect their information.

“Sensitive” Customer Information

Several industry groups also suggested significant portions of the Proposed Rule should not apply to all customer information, but rather only to some subset of particularly “sensitive” customer information, such as account numbers or social security numbers.

81

These commenters generally argued the definition of “customer information” is too broad, as it will include information the commenters felt is not particularly sensitive, such as name and address, and does not justify extensive safeguards.

82

81

See, e.g.,

Electronic Transactions Association (comment 27, NPRM), at 2-4; CTIA (comment 34, NPRM), at 10; Global Privacy Alliance (comment 38, NPRM), at 7-8; American Financial Services Association (comment 41, NPRM), at 5; ACA International (comment 45, NPRM), at 13; Money Services Round Table (comment 53, NPRM), at 6-7.

82

See, e.g.,

Electronic Transactions Association (comment 27, NPRM), at 2; Global Privacy Alliance (comment 38, NPRM), at 7.

The Commission does not agree that some portion of customer information is not entitled to the protections required by the Final Rule. The Safeguards Rule defines “customer information” as “any record containing nonpublic personal information” about a customer handled or maintained by or on behalf of a financial institution.

83

The Final Rule defines “nonpublic personal information” as “personally identifiable financial information,” but does not include information that is “publicly available.” Although this definition is broad, the Commission believes information covered by it is rightfully considered sensitive and should be protected accordingly. The businesses regulated by the Safeguards Rule are not just any businesses, but are financial institutions and are responsible for handling and maintaining financial information that is both important to consumers and valuable to attackers who try to obtain the information for financial gain. Even the fact that a consumer is a customer of a particular financial institution is generally nonpublic and can be sensitive. For example, the revelation of a customer relationship between a consumer and a particular type of financial institution, such as debt collectors or payday lenders, may make those customers' information more vulnerable to compromise by facilitating social engineering or similar attacks. The nature of the relationship between customers and their financial institutions makes all nonpublic information held by the financial institution inherently sensitive and worthy of the level of protection set forth in the Rule.

83

16 CFR 314.2(b).

Although the Commission believes all customer information should be safeguarded by financial institutions and declines to exclude any portion of that information from protection under any of the provisions of the Rule, it notes the Rule does contemplate financial institutions will consider the sensitivity of particular information in designing their information security programs and safeguards. The elements required by this section are generally flexible enough to allow financial institutions to treat various pieces of information differently. For example, paragraph (c)(1) requires information security programs to include safeguards that address access control of customer information. The paragraph requires financial institutions to develop measures to ensure only authorized users access customer information, but does not prescribe any particular measures that must be adopted. When designing these measures, a financial institution may design a system in which more sensitive information is protected by more stringent access controls. Even in the more specific provisions of the Rule, there is flexibility to address the relative sensitivity of information. For example, in § 313.4(c)(5)'s requirement that customer information be protected by multi-factor authentication, financial institutions have flexibility to implement the multi-factor authentication depending on the sensitivity of the information. The financial institution may select factors such as SMS text messages to access less sensitive information, but determine more sensitive information should be protected by other, more secure, factors for authentication.

Third-Party Standards and Frameworks

In addition, in the NPRM, the Commission asked whether the Safeguards Rule should incorporate outside standards, such as the National Institute of Standards and Technology (“NIST”) framework, either as required elements of an information security program or as a safe harbor that would

treat compliance with such a standard as compliance with the Safeguards Rule. Some commenters advocated for the adoption of an outside standard into the Safeguards Rule.

84

Cisco Systems, Inc. suggested the Safeguards Rule should be connected to NIST guidance, arguing this would allow the Rule to evolve as NIST's guidance evolves.

85

An anonymous commenter suggested the Rule should comply with “international standard ISO/IEC 27001.”

86

The National Consumer Law Center argued certain financial institutions with particularly sensitive customer information should be required to comply with guidelines issued by NIST and the Federal Financial Institutions Examination Council (FFIEC).

87

Other commenters acknowledged the value of outside standards but were opposed to the Rule requiring compliance with them.

88

84

Cisco Systems, Inc. (comment 51, NPRM), at 4; National Consumer Law Center and others (comment 58), at 2; Anonymous (comment 2, Workshop).

85

Cisco Systems, Inc. (Comment 51, NPRM), at 4.

86

Anonymous (comment 2, Workshop). The ISO/IEC 27001 standard is an information security standard issued by the International Organization for Standardization.

See

ISO/IEC 27001 Information Security Management, ISO,

https://www.iso.org/isoiec-27001-information-security.html

(last accessed 15 Dec. 2020).

87

National Consumer Law Center and others (comment 58, NPRM), at 2.

88

HITRUST (comment 18, NPRM), at 2;

see also

Consumer Reports (comment 52, NPRM), at 6-7 (discouraging the adoption of outside standards as a safe harbor for companies).

Some commenters suggested while compliance with outside standards should not be required, compliance should serve as a “safe harbor” for compliance with the Rule.

89

On the other hand, Consumer Reports noted while such standards can be helpful guidance, they should not be a safe harbor for compliance with the Rule because financial institutions must take steps to ensure they are responding to changing information security threats regardless of the requirements of an outside framework.

90

89

Mortgage Bankers Association (comment 26, NPRM), at 2 (suggesting Rule be modified so financial institutions that use the NIST Cybersecurity Framework would be in de facto compliance with the Rule);

see also

National Pawnbrokers Association (comment 32, NPRM), at 6-7 (advocating for the adoption of safe harbors for small financial institutions without detailing what should be required to qualify for the safe harbor).

90

Consumer Reports (comment 52, NPRM), at 6-7.

The Commission declines to change the Rule to incorporate or reference a particular security standard or framework for a variety of reasons. First, it is not clear the more detailed frameworks would apply well to financial institutions of various sizes and industries. In addition, mandating companies follow a particular security standard or framework would reduce the flexibility built into the Rule. Similarly, the Commission declines to make compliance with an outside standard a safe harbor for the Rule. In such a scenario, the use of safe harbors would not greatly enhance regulatory stability or predictability for financial institutions because the Commission would be required to actively monitor whether those standards continued to provide equivalent protections for Safeguards compliance and modify the Rule if a standard became inadequate. In addition, in investigating possible violations of the Rule, the Commission would be required to independently verify whether the financial institution had in fact complied with the outside framework, which would require substantial effort and expense on the part of the Commission and the target of the investigation.

Specific Elements

In addition to these generally applicable comments, commenters addressed many of the individual elements set forth by this section. These elements are discussed in more detail below.

Paragraph (a)—Designation of a Single Qualified Individual

Proposed paragraph (a) changed the current requirement that institutions designate an “employee or employees to coordinate your information security program” to instead require the financial institution to designate “a qualified individual responsible for overseeing and implementing your information security program and enforcing your information security program.”

91

This individual was referenced in the Proposed Rule as a Chief Information Security Officer or “CISO.”

91

Section 314.4(a).

The notice of proposed rulemaking for the Proposed Rule emphasized the use of the term “CISO” was for clarity in the Proposed Rule.

92

Despite the use of the term “CISO,” the Proposed Rule did not require financial institutions to actually grant that title to the designated individual. Commenters that responded to this proposal, however, generally assumed the person designated to coordinate and oversee a financial institution's information security program would be required to have the qualifications, duties, responsibilities, and accompanying pay of a CISO as that position is generally understood in the information security field.

93

The position of CISO is generally limited to large companies with fairly complex information security systems, so the salary of this position is often very high.

94

Accordingly, many commenters argued hiring a CISO would be prohibitively expensive for many financial institutions.

95

Additionally, commenters argued the hiring of such an in-demand professional would be difficult because of a general shortage of such professionals available for hiring.

96

92

84 FR 13165.

93

U.S. Chamber of Commerce (comment 33, NPRM), at 10; National Automobile Dealers Association (comment 46), at 17-19; National Independent Automobile Dealers Association (comment 48, NPRM), at 5; ACA International (Comment 45, NPRM), at 8.

94

See. e.g.,

Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 78 (estimating the average annual salary of a CISO can range from $180,000 to upwards of $400,000).

95

National Automobile Dealers Association (comment 46, NPRM), at 17-19; National Independent Automobile Dealers Association (comment 48, NPRM), at 5; U.S. Chamber of Commerce (comment 33, NPRM), at 10; ACA International (comment 45, NPRM), at 8.

96

National Automobile Dealers Association (comment 46, NPRM), at 18-19; U.S. Chamber of Commerce (comment 33, NPRM), at 10; ACA International (comment 45, NPRM), at 8.

By using the term “CISO,” the Commission did not intend to require all financial institutions hire a highly qualified professional with an extremely high salary, regardless of the financial institutions' size or complexity. The Proposed Rule required only that financial institutions designate a “qualified individual” to oversee and enforce their information security program, without specifying any particular level of experience, education, or compensation, or requiring any particular duties outside of overseeing the financial institution's information security program and other requirements specifically set forth in the Rule.

97

The use of the term “CISO” in the Proposed Rule, however, caused confusion about the requirements of this section. Accordingly, the Final Rule replaces the term “CISO” with “Qualified Individual” to refer to the individual designated under this section of the Rule.

97

84 FR 13175.

The use of the term “Qualified Individual” is meant to clarify the only requirement for this designated individual is that he or she be qualified to oversee and enforce the financial institution's information security program. What qualifications are necessary will depend upon the size and complexity of a financial institution's information system and the volume and sensitivity of the customer information the financial institution

possesses or processes. The Qualified Individual of a financial institution with a very small and simple information system will need less training and expertise than a Qualified Individual for a financial institution with a large, complex information system. The exact qualifications will depend on the nature of the financial institution's information system. Each financial institution will need to evaluate its own information security needs and designate an individual with appropriate qualifications to meet those needs.

The Commission believes, in many cases, financial institutions' current coordinators, whether their own employees or third-party contractors, may be qualified for this role.

98

Because the current Safeguards Rule requires financial institutions to designate an “employee or employees to coordinate your information security program,” financial institutions in compliance with that Rule will already have one or more information security coordinators. Although the current Rule does not expressly require that these coordinators be qualified for that position, the current Rule requires a financial institution to maintain “appropriate” safeguards, regularly test those safeguards, and evaluate and adjust the information security program in light of that testing.

99

In order to effectively comply with these ongoing requirements, a financial institution's coordinator must have some level of information security training and knowledge and, therefore, will likely be an appropriate Qualified Individual under the Final Rule. Accordingly, in many cases this amendment to the Rule will not require any additional hiring expenses.

98

Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 74 (stating car dealerships can rely on existing staff for this role); Remarks of Lee Waters, Safeguards Workshop Tr.,

supra

note 17, at 78-79 (stating any dealership with any IT staff at all would have someone who could assume the role of “qualified individual,” perhaps requiring some additional research or outside help); Remarks of Rocio Baeza, Safeguards Workshop Tr.,

supra

note 17, at 81-82 (stating companies may use an existing employee for the role and “for any areas where there may be skill gaps, that can be supplemented with either certifications or some type of education.”).

99

16 CFR 314.4.

In addition to explicitly requiring that the information security program coordinator be qualified for the role, the Commission proposed to require the designation of a single employee, as opposed to the multiple coordinators allowed by the existing Rule. Some commenters objected to this proposal on the grounds that it would interfere with financial institutions' flexibility in organizing their information security personnel.

100

For example, the Consumer Data Industry Association (“CDIA”) commented the designation of a single coordinator would interfere with financial institutions' ability to organize their program “to share responsibilities among different personnel with different strengths.”

101

Similarly, ACA International argued this requirement would prevent financial institutions from having multiple staff members share responsibilities for information security programs.

102

100

National Independent Automobile Dealers Association (comment 48, NPRM), at 5; Consumer Data Industry Association (comment 36, NPRM), at 5; National Association of Dealer Counsel (comment 44, NPRM), at 2; ACA International (comment 45, NPRM), at 7-8; Money Services Round Table (comment 53, NPRM), at 10; Gusto and others (Comment 11, Workshop), at 2;

see also

Remarks of James Crifasi, Safeguards Workshop TR,

supra

note 17, at 74 (stating “when we're talking about a small and medium business [. . .] we really need to see that `qualified individual' be a mix of folks”).

101

Consumer Data Industry Association (comment 36, NPRM), at 5.

102

ACA International (comment 45, NPRM), at 7-8. NPA raised similar concerns. National Pawnbrokers Association (comment 3, Workshop), at 2.

Other commenters argued the designation of a single individual as the coordinator of the information security program provides no proven benefits over the use of multiple coordinators.

103

Similarly, NADA argued that, while the appointment of a single qualified individual might improve accountability, improving accountability does not improve security.

104

On the other hand, a group of consumer and advocacy groups including the National Consumer Law Center (“NCLC”) argued appointing a single individual as the coordinator of the information security program can increase security and prevent security events based on lack of accountability and poor coordination.

105

103

Consumer Data Industry Association (comment 36, NPRM), at 5; National Automobile Dealers Association (comment 46, NPRM), at 19; ACA International (comment 45, NPRM), at 8.

104

National

Automobile Dealers Association

(comment 46, NPRM), at 19.

105

National Consumer Law Center and others (comment 58, NPRM), at 3 (arguing that a clear line of reporting with a single responsible individual could have prevented the Equifax consumer data breach).

The Commission retains the requirement to designate a single qualified individual, because it believes there are clear benefits to the designation of a single coordinator. Designating a single coordinator to oversee an information security program clarifies lines of reporting in enforcing the program, can avoid gaps in responsibility in managing data security, and improve communication.

106

106

Remarks of Adrienne Allen, Safeguards Workshop Tr.,

supra

note 17, at 182-84 (stating that without a single responsible individual, information security staff “can fall into traps of each relying on someone else to make a hard call . . . [In a program without a single coordinator] issues can sometimes fall through the cracks.”); Remarks of Michele Norin, Safeguards Workshop Tr.,

supra

note 17, at 184-85 (“I think it's extremely important to have a person in front of the information security program. I think that there are so many components to understand, to manage, to keep an eye on. I think it's difficult to do that if it's part of someone else's job. And so I found that it's extremely helpful to have a person in charge of that program just from a pure basic management perspective and understanding perspective.”).

The Commission disagrees with the commenter who stated improved accountability does not lead to improved security. The goal of improving accountability is to ensure information security staff and financial institution management give the necessary attention and resources to information security. In addition, an individual that has clear responsibility for the strength of a financial institution's information security program will be accountable to improve the program and ensure it protects customer information.

107

107

See, e.g.,

Federal Trade Commission Staff Comment on the Preliminary Draft for the NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management (Oct. 24, 2019), at 12-14 (suggesting NIST clarify that one person should be in charge of the program).

https://www.ftc.gov/system/files/documents/advocacy_documents/ftc-staff-comment-preliminary-draft-nist-privacy-framework/p205400nistprivacyframeworkcomment.pdf.

The major breach that occurred at national consumer reporting agency Equifax in 2017 demonstrates the importance of clear lines of reporting and accountability in management of information security programs. The U.S. House Committee on Oversight and Government Reform issued a report on the breach that identified Equifax's organization as one of the major causes of the breach.

108

The report indicated Equifax's division of responsibility for information security between two individuals that reported to two different company officers contributed to failures of communication, oversight, and enforcement that led to millions of consumers' data being compromised.

109

Increasing accountability for individuals and organizations can directly lead to improved security for customer information.

108

U.S. House, Committee on Oversight and Government Reform, Majority Staff Report, The Equifax Data Breach, at 55-62, 115th Congress (Dec. 2018).

109

Id.

Finally, the Commission does not believe the requirement to designate a single Qualified Individual would

prevent the approach of having multiple people responsible for different aspects of the program, as some commenters asserted. While the Qualified Individual appointed as the coordinator of the information security program would have ultimate responsibility for overseeing and managing the information security program, financial institutions may still assign particular duties and responsibilities to other staff members.

110

A financial institution may organize its personnel in teams or share decision making between individuals. Moreover, the Rule does not require this be the Qualified Individual's sole job—he or she may have other duties. The Rule requires only that one individual assume the ultimate responsibility for overseeing and enforcing the program.

110

See

Remarks of Adrienne Allen, Safeguards Workshop Tr.,

supra

note 17, at 189-90 (noting that, even where there is a single point person, decision makers rarely operate “in a vacuum.”).

Accordingly, the Final Rule requires designation of a single Qualified Individual, as proposed, but no longer uses the term “CISO.”

Third-Party Coordinators

The Proposed Rule stated that the Qualified Individual would not need to be an employee of the financial institution, but could be an employee of an affiliate or a service provider. This change was intended to accommodate financial institutions that may prefer to retain an outside expert, lack the resources to employ a qualified person to oversee a program, or decide to pool resources with affiliates to share staff to manage information security. The Proposed Rule required, however, that to the extent a financial institution used a service provider or affiliate, the financial institution must still: (1) Retain responsibility for compliance with the Rule; (2) designate a senior member of its personnel to be responsible for direction and oversight of the Qualified Individual; and (3) require the service provider or affiliate to maintain an information security program that protects the financial institution in accordance with the Rule.

The Commission received one comment on this aspect of the provision. NADA argued that, because a senior member of a financial institution's personnel must be responsible for the oversight of a third-party Qualified Individual, the supervising individual would need to be an expert in information security, and the financial institution would still be required to hire an expensive employee to supervise the third-party Qualified Individual.

111

The Rule, however, does not require individuals responsible for overseeing third-party Qualified Individuals to be information security experts themselves. The senior personnel that oversees the third-party Qualified Individual is charged with supervising and monitoring the third-party so the financial institution is aware of its data security needs and the safeguards being used to protect its information systems. This person does not need to be qualified to coordinate the information security program him or herself. Technical staff are frequently supervised by employees or officers with limited technical expertise.

112

The Rule requires only the same responsibilities a supervisor would have in overseeing an in-house information security coordinator of a financial institution. Accordingly, the Commission adopts the proposed paragraph without modification.

111

National

Automobile Dealers Association

(comment 46, NPRM), at 18.

112

See

Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 79-80 (stating that, in his work as a third-party information security service provider, he is often overseen by executives without technical backgrounds);

see also

Remarks of Rocio Baeza, Safeguards Workshop Tr.,

supra

note 17, at 105-06 (noting distinction in how executives and technical staff may understand their organizations' use of encryption); Remarks of Karthik Rangarajan, Safeguards Workshop Tr.,

supra

note 17, at 196 (discussing challenges inherent in discussing technical issues with board members who lack a technical background)and at 211 (noting organizations can successfully manage their relationships with third-party service providers without “becom[ing] experts” in the services provided).

Proposed Paragraph (b)

The NPRM proposed amending paragraph (b) to clarify a financial institution must base its information security program on the findings of its risk assessment by adding an explicit statement that financial institutions' “information security program [shall be based] on a risk assessment.”

113

In addition, the Proposed Rule removed existing § 314.4(b)'s requirement that the risk assessment must include consideration of specific risks

114

because these specific risks are set forth elsewhere in the Proposed Rule.

115

The Commission received no comments on this paragraph and adopts paragraph (b) as proposed.

113

Proposed 16 CFR 314.4(b).

114

Proposed 16 CFR 314.4(b)(1), (2), and (3).

115

See, e.g.,

Proposed 16 CFR 314.4(c)(2) and (10) and (e).

Written Risk Assessment

Paragraph (b)(1) of the Proposed Rule required the risk assessment be written and include: (1) Criteria for the evaluation and categorization of identified security risks or threats the financial institution faces; (2) criteria for the assessment of the confidentiality, integrity, and availability of the financial institution's information systems and customer information, including the adequacy of the existing controls in the context of the identified risks or threats to the financial institution; and (3) requirements describing how identified risks will be mitigated or accepted based on the risk assessment and how the information security program will address the financial institution's risks. Commenters raised several concerns about the Proposed Rule's provisions on risk assessment, none of which merit changes to the Proposed Rule.

First, some commenters objected to the level of specificity of the Proposed Rule, with some arguing the requirements were too specific, and others arguing the requirements were not specific enough. With respect to the Proposed Rule being too specific, commenters such as ACA and U.S. Chamber of Commerce argued it removed financial institutions' flexibility in performing risk assessments.

116

The U.S. Chamber of Commerce contended, because the criteria are too specific, a risk assessment performed using them would not be “sufficiently risk based.”

117

CDIA expressed concern it was unclear “what level of specificity is required” in the written risk assessment and if detailed risk assessments are required, they “could themselves become a roadmap for a security breach.”

118

116

ACA International (comment 45, NPRM), at 12; U.S. Chamber of Commerce (comment 33, NPRM), at 10.

117

U.S. Chamber of Commerce (comment 33, NPRM), at 10.

118

Consumer Data Industry Association (comment 36, NPRM), at 5.

In contrast, several other commenters recommended the Rule set forth more specific criteria for risk assessments. Inpher suggested the Commission add a requirement that risk assessments require financial institutions to examine “technologies that are deployed by [financial institutions'] information security systems, and evaluate the feasibility” of adopting “privacy enhancing technologies” that would better address vulnerabilities and thwart threats.

119

Inpher also recommended the Rule require financial institutions to conduct privacy impact assessments with “specific guidelines to review internal data protection standards and adherence to fair information

principles.”

120

The Princeton Center suggested the Rule require risk assessments to include threat modeling and adopt the concept of defense in depth.

121

HALOCK Security Labs recommended the Rule specifically require “a) That risk assessments should evaluate the likelihood of magnitudes of harm that result from threats and errors, b) That risk assessments should explicitly estimate foreseeable harm to consumers as well as to the covered financial institutions, c) That risk mitigating controls are commensurate with the risks they address, [and] d) That risk assessments estimate likelihoods and impacts using available data.”

122

119

Inpher, Inc. (comment 50, NPRM), at 4.

120

Id.

121

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 2.

122

HALOCK Security Labs (comment 4, Workshop) at 2.

See

Rocio Baeza (comment 12, Workshop) at 2-3 (suggesting a detailed list of requirements for the risk assessment).

The Commission believes the Proposed Rule's provisions on risk assessment strike the right balance between specificity and flexibility. The amendments provide only a high-level list of criteria the risk assessment must address. They essentially require that the financial institution identify and evaluate risks to its systems, evaluate the adequacy of its existing controls for addressing these risks, and identify how these risks can be mitigated. These are core requirements of any risk-assessment.

123

The Rule does not require any specific methodology or approach for performing the assessment. Financial institutions are free to perform the risk assessment using the method most suitable for their organization as long as that method meets the general requirements set forth in the Rule.

124

And while the Commission agrees the additional requirements suggested by some commenters may be beneficial in many, or even most, risk assessments, it believes a more flexible requirement will better allow financial institutions to find the risk assessment method that best fits their organization and will better accommodate changes in recommended approaches in the future.

123

See, e.g.,

Remarks of Chris Cronin, Safeguards Workshop Tr.,

supra

note 17, at 25 (stating that evaluating the likelihoods and impacts of potential security risks and evaluating existing controls is an important component of a risk assessment); Remarks of Serge Jorgensen, Safeguards Workshop Tr.,

supra

note 17, at 29-30 (emphasizing the importance of risk assessments as tools for adjusting existing security measures to account for both current and future security threats); Nat. Inst. of Sci. & Tech., U.S. Dept. of Com., Special Publication 800-30 Rev. 1, Guide for Conducting Risk Assessments 1 (2012) (describing the purpose of risk assessments as the identification of and prioritization of risk in order to inform decision making and risk response).

124

ACA International further argued because risk assessment criteria are generally understood, they do not need to be included in the Final Rule. ACA International (comment 45, NPRM). The Commission believes it is helpful to be clear about the criteria the risk assessment must contain, even if those criteria are commonly understood.

In response to CDIA's concern about the risk assessment providing a roadmap for bad actors, certainly, the written risk assessment will include details about a financial institution's systems that could assist an attacker if obtained by the attacker. Accordingly, the risk assessment should be protected as any other sensitive information would be. The Commission does not view this concern as a reason not to create such a document. Indeed, the concern would apply to any written document that provides information regarding a financial institution's information security procedures, from a network diagram to written security code.

Second, some commenters argued implementing the risk-assessment provision as proposed would be too expensive and difficult for financial institutions.

125

For example, NADA argued the contemplated risk assessment would be very costly because the criteria set out in paragraph (b)(1) are “well outside the scope of expertise of anyone but the most sophisticated IT professionals.”

126

In response, although the Commission declines to modify the provision, it addresses NADA's concern in § 314.6 by exempting financial institutions that maintain information concerning fewer than 5,000 consumers from the specific requirements of paragraph (b)(1), and from the requirement to memorialize the risk assessment in writing. For those financial institutions that do not qualify for this exemption, the Commission believes they will be able to perform the required risk assessment in a manner that is practical and affordable for their institution. There are many resources available to financial institutions to aid in risk assessment, including service providers that can assist institutions of various sizes.

127

125

National Association of Dealer Counsel (comment 44, NPRM), at 3; National Automobile Dealers Association (comment 46, NPRM), at 20.

126

National Automobile Dealers Association (comment 46, NPRM), at 20.

127

See, e.g.,

Slides Accompanying Remarks of Rocio Baeza, in Safeguards Workshop Slides,

supra

note 72, at 27-28 (describing three different compliance models: In-house, outsource, and hybrid, with costs ranging from $199 per month to more than $15,000 per month); Slides Accompanying the Remarks of Brian McManamon, “Sample Pricing,” in Safeguards Workshop Slides,

supra

note 72, at 29 (estimating the cost of cybersecurity services based on number of endpoints: $2K-$5K per month for 25-250 endpoints; $5K-$15K for 250-750 endpoints; $15K-$30K for 750-1,000 endpoints; and $30K-$50K for 1,500-2,500 endpoints);

see also

Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 83-85.

While acknowledging there will be some cost to conducting a risk assessment, the Commission believes a properly conducted risk assessment is an essential part of a financial institution's information security program. The entire Safeguards Rule, both as it currently exists and as amended, requires that the information security program be based on a risk assessment. An information security program cannot properly guard against risks to customer information if those risks have not been identified and assessed.

128

The Commission believes this requirement properly emphasizes the importance of robust risk assessments, while providing financial institutions sufficient flexibility in performing these assessments. Finally, the Commission notes, because the current Rule also requires that a risk assessment be performed, financial institutions that have complied with the current Rule have already conducted a risk assessment. And, even if that risk assessment was not memorialized in writing, the work conducted for that risk assessment should be useful in performing future risk assessments.

128

See

Remarks of Chris Cronin, Safeguards Workshop Tr.,

supra

note 17, at 48-49 (noting all information security frameworks and guidelines are based on risk analysis).

Third, NADA objected to the requirement that the risk assessment describe how each identified risk will be “mitigated or accepted,” arguing it is not clear when it is appropriate to “accept a risk.”

129

NADA argued that documenting a decision to accept a risk would “create a record that can be distorted and second guessed after the fact,” and “context is lost when it is written and reviewed after an incident has occurred.”

130

The Rule does not require a financial institution to mitigate every risk identified, no matter how remote or insignificant. Instead, the Rule allows a financial institution to accept a risk, if its assessment of the risk reveals that the chance it will produce a security event is very small, if the consequences of the risk are minimal, or the cost of mitigating the risk far outweighs the benefit. In those cases, the financial institution may choose to accept the risk. A financial institution concerned that its decision to accept a risk will later be questioned may choose to set forth whatever context or

explanation it sees fit in the written assessment.

129

National Automobile Dealers Association (comment 46, NPRM) at 20.

130

Id.

Finally, while several commenters supported the idea of conducting “periodic” risk assessments as required by the Proposed Rule,

131

NADA objected it is unclear how often financial institutions need to conduct risk assessments under this section.

132

In order to be effective, a risk assessment must be subject to periodic reevaluation to adapt to changes in both financial institutions' information systems and changes in threats to the security of those systems. The Commission declines, however, to set forth a specific schedule for risk assessments. The Commission believes it would not be appropriate to set forth an inflexible schedule for periodic risk assessments because each financial institution must set its own schedule based on the needs and resources of its institution.

131

Inpher

, Inc.

(comment 50, NPRM), at 3; Global Privacy Alliance (comment 38, NPRM), at 11.

132

National Automobile Dealers Association (comment 46, NPRM), at 20.

The Final Rule adopts § 314.4(b) as proposed.

Paragraph (c)

Proposed paragraph (c) retained the existing Rule's requirement for financial institutions to design and implement safeguards to control the risks identified in the risk assessment. In addition, it added more detailed requirements for what the safeguards must address (

e.g.,

access controls, data inventory, disposal, change management, monitoring). These specific requirements represent elements of an information security program that the Commission views as essential and should be addressed by all financial institutions.

133

133

NADA disagreed with the Commission's statement in the NPRM for the Proposed Rule that “most financial institutions already implement” the specific requirements in paragraph (c), stating that many financial institutions “do not currently implement some or all of these measures.” National Automobile Dealers Association (comment 46, NPRM), at 20. The Commission continues to believe most financial institutions institute some form of most of these measures, such as access control, secure disposal, and monitoring authorized users, based on its enforcement and business outreach experience. While NADA's statement that some financial institutions implement none of the measures may be true, this underlines the necessity of making these elements explicit requirements under the Rule, as these elements are necessary for a reasonable information security program for all financial institutions. Indeed, a financial institution that utilizes none of these elements and exercises no access control, no secure disposal procedures, and does not monitor users of its systems is unlikely to be in compliance with the current Rule.

As a preliminary matter, Global Privacy Alliance (GPA) argued all of these elements should be made optional and financial institutions should be required only to take these elements “into consideration” when designing their information security programs.

134

While the Commission agrees it is important that the Rule allow financial institutions flexibility in designing their information security programs, these elements are such important parts of information security that each program must address them. For example, an information security program that has no access controls or does not contain any measures to monitor the activities of users on the systems cannot be said to be protecting the financial institution's systems. The Final Rule, therefore, continues to require each information security program to contain safeguards that address these elements, with modifications described below.

134

Global Privacy Alliance (comment 38, NPRM), at 6.

Access Controls

Proposed paragraph (c)(1) required financial institutions to “place access controls on information systems, including controls to authenticate and permit access only to authorized individuals to protect against the unauthorized acquisition of customer information and to periodically review such access controls.”

Commenters suggested a number of modifications to this provision. First, GPA argued this provision should require controls on access to information, rather than on information systems.

135

Second, several commenters suggested adding further safeguards to the “access control” requirement. For example, the Princeton Center argued the Rule should adopt the “Principle of Least Privilege,” a principle that no user should have access greater than is necessary for legitimate business purposes.

136

Reynolds and Reynolds Company (Reynolds) suggested the Rule clarify that financial institutions must “vet, control, and monitor user access to sensitive information.”

137

Consumer Reports argued paragraph (c)(1) should be amended to control access not just to authorized users, but to further limit access to when such access is reasonably necessary.

138

ACE argued that any requirement for physical access control allow financial institutions to determine which locations should have restricted access, rather than limiting physical access to every building and office within, say, a college campus.

139

Finally, some commenters argued the proposed language was too vague,

140

particularly as it applied to vendor-supplied services.

141

135

Global Privacy Alliance (comment 38, NPRM), at 9-10.

136

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 4-5.

137

Reynolds and Reynolds Company (comment 7, Workshop), at 7.

138

Consumer Reports (comment 52, NPRM), at 7.

139

American Council on Education (comment 24, NPRM), at 10.

140

National Automobile Dealers Association (comment 46, NPRM), at 23; National Independent Automobile Dealers Association (comment 48, NPRM), at 5; American Council on Education (comment 24, NPRM), at 10;

141

National Independent Automobile Dealers Association (comment 48, NPRM), at 5; American Council on Education (comment 24, NPRM), at 10.

In response to the comments, the Commission makes a number of changes to this provision in the Final Rule. First, the Commission clarifies that the Rule requires access controls, not just for information systems, but for all customer information, whether it is housed in information systems or in physical locations. To streamline the Rule, the Final Rule combines the separate physical access controls requirement found in proposed paragraph (c)(3) with this paragraph. Physical access controls will generally be most important in situations in which sensitive customer information is kept in physical form (such as hard-copy loan applications, or printed consumer reports). It may also require physical restrictions to access machines that contain customer information (

e.g.,

locked doors and/or key card access to a computer lab).

142

The Commission declines to make any changes in response to ACE's concern that every physical location will need to be protected—as the Rule states, physical controls must be implemented to protect unauthorized access to customer information. Where no customer information exists, the Rule would not require physical controls.

142

NIADA suggested instituting physical access controls would cost a dealership $215,000 because each computer would need to have its own lockable cubicle and there would need to be lockable offices for all desks.

See

Remarks of Lee Waters, Safeguards Workshop Tr.,

supra

note 17, at 76. As originally promulgated, the Rule already requires financial institutions implement “physical safeguards that are appropriate to your size and complexity.” 16 CFR 314.3. The Final Rule's requirement is consistent with that longstanding requirement. If computers have technical safeguards preventing unauthorized users from accessing customer information, they usually will not need to be in a lockable area, particularly if they are not generally left unattended and are not likely to be stolen. Similarly, desks would need to be in lockable offices only if they contain accessible paper records. A lockable file cabinet may be a more economical solution.

Second, the Commission agrees with the commenters who advocated that the Rule implement the principle of least privilege. The Commission does not believe it is appropriate, for example, for larger companies to give all

employees and service providers access to all customer information. Such overbroad access could create additional harm in the event of an intruder gaining access to a system by impersonating an employee or service provider. Accordingly, the Commission clarifies this in the Final Rule by adding a requirement that not only must a financial institution implement access controls, but it should also restrict access only to customer information needed to perform a specific function.

As to the suggestion the Commission impose monitoring requirements for access, that requirement exists in paragraph (c)(8). And as to the suggestion the requirement is too vague as to service providers, the Commission believes the Final Rule is clear: When a vendor accesses the financial institution's data or information systems, the financial institution must ensure appropriate access controls are in place. Separately, under paragraph (f), the financial institution must reasonably oversee the vendor's safeguards, which would necessarily include access controls for the vendor's system.

Finally, as to the suggestion the provision is vague generally, as discussed above, the Final Rule seeks to preserve flexibility in its provisions, both so that financial institutions can design programs appropriate for their systems and so that changes in technology or security practices will not render the Rule obsolete. The Commission believes maintaining less prescriptive requirements is the best way to achieve the goal of flexibility and protecting customer information.

143

143

NPA expressed concern about the effect of the Rule on pawnbrokers who the commenter stated are required by law to allow law enforcement access to their physical records. National Pawnbrokers Association (comment 32, NPRM), at 7. Nothing in the Rule conflicts with any such requirements. Law enforcement appropriately accessing customer information under a law that requires that access would be considered authorized use under those circumstances.

Accordingly, the Commission combines paragraphs (c)(1) and (3) from the Proposed Rule into revised paragraph (c)(1) of the Final Rule, which requires implementing and periodically reviewing access controls on customer information, including technical and, as appropriate, physical controls to (1) authenticate and permit access only to authorized users to protect against the unauthorized acquisition of customer information and (2) limit authorized users' access only to customer information that they need to perform their duties and functions, or, in the case of customers, to access their own information.

144

144

As noted above, the Commission is also changing the term “authorized individuals” to “authorized users.”

System Inventory

In the NPRM, the Commission proposed to require the financial institution to “[i]dentify and manage the data, personnel, devices, systems, and facilities that enable [the financial institution] to achieve business purposes in accordance with their relative importance to business objectives and [the financial institution's] risk strategy.”

145

This requirement was designed to ensure the financial institution inventoried the data in its possession, inventoried the systems on which that data is collected, stored, or transmitted, and had a full understanding of the relevant portions of its information systems and their relative importance.

146

The Commission retains this provision in the Final Rule without modification.

145

Proposed 16 CFR 314.4(c)(2).

146

See, e.g.,

Complaint at 11,

FTC

v.

Wyndham Worldwide Corp.,

No. CV 2:12-cv-01365-SPL (D. Ariz. June 26, 2012) (alleging company failed to provide reasonable security by, among other things, failing to inventory computers connected to its network).

Commenters raised two general objections to this provision. First, some commenters argued it was too vague and that it was not clear how such an inventory should be conducted or what systems should be included.

147

The Commission believes the language provides effective guidance while still allowing a variety of approaches by financial institutions in identifying systems involved in their businesses. This provision requires a financial institution to identify all “data, personnel, devices, systems, and facilities” that are a part of its business and to determine their importance to the financial institution. This inventory of systems must include all systems that are a part of the business so the financial institution can locate all customer information it controls, the systems connected to that information, and how they are connected. This inventory forms the basis of an information security program because a system cannot be protected if the financial institution does not understand its structure or know what data is stored in its systems.

147

National Automobile Dealers Association (comment 46, NPRM), at 23-24; American Financial Services Association (comment 41, NPRM), at 5; American Council on Education (comment 24, NPRM), at 10.

Second, ACE suggested the scope of this provision should be limited to systems “directly related to the privacy and security of `customer information.' ”

148

The Commission declines to make this change because the purpose of this provision is to allow financial institutions to obtain a clear picture of their systems and to identify where customer information is kept and how it can be accessed. An inventory must examine all systems in order to identify all systems that contain customer information or are connected to systems that do. If a financial institution does not first examine all systems and instead limits the inventory to systems it considers to be directly related to security, it could give an incomplete picture of the financial institution's systems and could result in some customer information or ways to connect to that information being overlooked.

149

148

American Council on Education (comment 24, NPRM), at 10.

149

Another commenter criticized proposed paragraph (c)(2) because some financial institutions “have no control” over which networks they transmit customer information. National Pawnbrokers Association (comment 32, NPRM), at 7. Paragraph (c)(2) does not require a financial system to identify all networks over which it may transmit customer information.

See also, infra,

this document's discussion of NPA's comments on § 314.4(f) of the Final Rule, noting financial institutions are generally not required to oversee other entities' service providers over which they have no control.

The Commission adopts paragraph (c)(2) of the Proposed Rule as final, without modifications.

Access to Physical Location

Proposed paragraph (c)(3) would have required that financial institutions restrict access to physical locations containing customer information only to authorized individuals. The Final Rule combines this section with proposed paragraph (c)(1) in order to eliminate redundancy and clarify that access controls must consider both electronic and physical access.

Encryption

Proposed paragraph (c)(4) required financial institutions to encrypt all customer information, both in transit over external networks and at rest. The Proposed Rule allowed financial institutions to use alternative means to protect customer information, subject to review and approval by the financial institution's Qualified Individual.

Several commenters supported the inclusion of an encryption requirement.

150

In fact, some suggested

the Proposed Rule did not go far enough in requiring encryption. Inpher suggested the Rule should require encryption of customer information when in use, in addition to when in transit or at rest.

151

The Princeton Center suggested requiring encryption of data while in transit over internal networks, in addition to requiring it for external networks, noting the blurring of the distinction between internal and external networks.

152

150

Inpher, Inc. (comment 50, NPRM), at 4; Princeton University Center for Information Technology Policy (comment 54, NPRM), at 3; Electronic Privacy Information Center (comment 55, NPRM), at 8; National Consumer Law Center and others (comment 58, NPRM), at 3.

151

Inpher, Inc. (comment 50, NPRM), at 4.

152

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 3.

In contrast, others argued encryption could be too expensive and technically challenging for some financial institutions and should not be required in all cases.

153

Indeed, GPA argued the Rule should not require encryption at all, financial institutions should be free to adopt other protective measures for customer information, and the Rule should allow financial institutions to “determine the controls that are most appropriate for protecting the sensitive information that they handle.”

154

Similarly, some commenters argued financial institutions should be required to encrypt customer information only when the risk to the customer information justifies it.

155

Others suggested encryption in more limited circumstances, such as on systems “to which unauthorized individuals may have access,”

156

for sensitive data,

157

or for data in transit.

158

The Mortgage Bankers Association argued encryption at rest is unnecessary because customer information at rest in a financial institution's system is sufficiently protected by controlling access to the system.

159

Two commenters stated guidelines issued by the Federal Financial Institutions Examination Council (FFIEC) do not require most banks to encrypt data at rest, unless the institution's risk assessment indicates such encryption is necessary.

160

153

National Pawnbrokers Association (comment 32, NPRM), at 3; U.S. Chamber of Commerce (comment 33, NPRM), at 11; CTIA (comment 34, NPRM) at 10; Wisconsin Bankers Association (comment 37, NPRM), at 2.

154

Global Privacy Alliance (comment 38, NPRM), at 7-8.

155

Bank Policy Institute (comment 39, NPRM), at 14; Mortgage Bankers Association (comment 26, NPRM), at 6; Global Privacy Alliance (comment 38, NPRM), at 7-8.

156

Bank Policy Institute (comment 39, NPRM), at 14.

157

U.S. Chamber of Commerce (comment 33, NPRM), at 11; American Financial Services Association (comment 41, NPRM), at 5; ACA International (comment 45, NPRM), at 13; CTIA (comment 34, NPRM), at 10.

158

Mortgage Bankers Association (comment 26, NPRM), at 6; Wisconsin Bankers Association (comment 37, NPRM), at 2; American Financial Services Association (comment 41, NPRM), at 5; Ken Shaurette (comment 19, NPRM), (suggesting the Commission consider whether “databases, applications and operating systems are prepared to fully support full encryption without significant performance impact or ability to continue to function.”); National Automobile Dealers Association (comment 46, NPRM), at 25-26 (arguing the terms “at rest” and “in transit” are unclear).

159

Mortgage Bankers Association (comment 26, NPRM), at 6.

160

Wisconsin Bankers Association (comment 37, NPRM), at 2 (discussing FFIEC Information Technology Booklet); American Financial Services Association (comment 41, NPRM), at 5 (discussing FFIEC Cybersecurity Assessment Tool).

The Commission declines to modify the encryption requirement from the Proposed Rule. As to the comments that suggest the requirement should be relaxed, the Commission notes there are numerous free or low cost encryption solutions available to financial institutions, particularly for data in transit,

161

that make encryption a feasible solution in most situations. For data at rest, encryption is now cheaper, more flexible, and easier than ever before.

162

In many cases, widely used software and hardware have built-in encryption capabilities.

163

161

See

Remarks of Matthew Green, Safeguards Workshop Tr,

supra

note 17, at 225 (noting website usage of encryption is above 80 percent; “Let's Encrypt” provides free TLS certificates; and costs have gone down to the point that if a financial institution is not using TLS encryption for data in motion, it is making an unusual decision outside the norm); Remarks of Rocio Baeza, Safeguards Workshop Tr.,

supra

note 17, at 106 (“[T]he encryption of data in transit has been standard. There's no pushback with that.”);

see also

National Pawnbrokers Association (comment 3, Workshop), at 2 (“[I]n states that allow us to use technology for the receipt of information from consumer customers and software to print our pawn tickets and store information, we believe our members have access through their software providers to protections that comply with the Safeguards Rule.”).

162

See

Remarks of Wendy Nather, Safeguards Workshop Tr.,

supra

note 17, at 267 (“we have a lot more options, a lot more technologies today than we did before that are making both of these solutions, both encryption and MFA, easier to use, more flexible, in some cases cheaper, and we should be encouraging their adoption wherever possible.”); Remarks of Matthew Green, Safeguards Workshop Tr.,

supra

note 17, at 265-66 (“I think that we're in a great time when we've reached the point where we can actually mandate that encryption be used. I mean, years ago—I've been in this field for 15, you know, 20 years now, I guess. And, you know, encryption used to be this exotic thing that was very, very difficult to use, very expensive and not really feasible for securing information security systems. And we've reached the point where now it is something that's come to be and we can actually build well. So I'm really happy about that.”).

163

See

Remarks of Randy Marchany, Safeguards Workshop Tr.,

supra

note 17, at 229-30 (noting encryption is already built into the Microsoft Office environment and a number of Microsoft products, such as Spreadsheets, Excel, Docs, and PowerPoint, support that encryption feature). Other applications that have encryption built in include database applications; app platforms iOS and Android; and development frameworks for web applications on banking sites.

In response to the argument that the Rule should not require encryption at rest because FFIEC guidelines do not require it, the Commission notes the Safeguards Rule is very different from the guidelines issued by the FFIEC. The depository financial institutions regulated by the banking agencies are subject to regular examinations by their regulator. The guidelines created by the FFIEC are designed to be used by the examiner, as part of those examinations, to evaluate the security of the financial institution; the examiner thus has a direct role in regularly verifying the financial institution has taken appropriate steps to protect its customer information. In contrast, the Safeguards Rule regulates covered financial institutions directly and must be usable by those entities to determine appropriate information security without any interaction between the financial institution and the Commission. The Commission does not have the ability to examine each financial institution and work with that institution to ensure their information security is appropriate. Therefore, a requirement that institutions encrypt information by default is appropriate for the Safeguards Rule, as the Commission believes encryption of customer information at rest is appropriate in most cases.

Finally, while some commenters suggested eliminating the encryption requirement for certain types of data (

e.g.,

non-sensitive) or certain categories of data (

e.g.,

data at rest), the Commission notes, as discussed in more detail above, the fact that an individual is a customer of a financial institution alone may be sensitive. In any event, the Rule provides financial institutions with flexibility to adopt alternatives to encryption with the approval of the Qualified Individual.

Similarly, the Commission declines to

extend

the encryption requirement to data in use or to data transmitted over internal networks, as some commenters suggested. The Commission does not believe the technology that would encrypt data while in use (as opposed to in transit or at rest) has been adopted widely enough at this time to justify mandating its use by all financial institutions under the FTC's jurisdiction. As to encryption of data transmitted over internal networks, the Commission acknowledges, due to changes in network design and the growth of cloud and mobile computing, the distinction between internal and external networks is less clear than it once was. However, the Commission believes requiring all financial institutions to encrypt all communications over internal networks would be unduly burdensome at this

time. There remain significant costs and technical hurdles to encrypting transmissions on internal networks that would not be reasonable to impose on all financial institutions, especially smaller institutions with simpler systems that might realize less benefit from this approach. While the Commission encourages financial institutions to consider whether it would be appropriate for them to encrypt the transmission of customer information over internal networks, it declines to require this for all financial institutions.

164

164

The Commission believes transmissions of customer information to remote users or to cloud service providers should be treated as external transmissions, as those transmissions are sent out of the financial institution's systems.

Commenters pointed to three additional concerns about encryption, none of which the Commission finds persuasive. First, the Bank Policy Institute commented the encryption requirement would in fact weaken security by blocking surveillance of the information by the financial institution and requiring the “broad distribution” of encryption keys.

165

The Commission does not believe an encryption requirement would weaken security. Encryption is almost universally recommended by security experts and included in most security standards.

166

Further, new tools have been developed to address the issue the Bank Policy Institute has raised. Many financial institutions have monitoring tools on the edge of their networks to monitor data leaving the network. It used to be the case these network monitoring tools could not see the content of encrypted data as it left the corporate network and was transmitted to the internet. However, there are now tools available that can see the data as it departs the network, even if the data is encrypted.

167

Any marginal security costs of encryption are far outweighed by the benefits of rendering customer information unreadable.

165

Bank Policy Institute (comment 39, NPRM), at 13-14.

166

See, e.g., Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2.1,

PCI Security Standards Council (May 2018),

https://www.pcisecuritystandards.org/document_library

(last accessed 30 Nov. 2020) (Requirement 4 encrypt transmission of cardholder data across open, public networks).

167

See, e.g., Encrypted Traffic Management,

Broadcom Inc.,

https://www.broadcom.com/products/cyber-security/network/encrypted-traffic-management

(last accessed 30 Nov. 2020);

SSL Visibility,

F5, Inc.,

https://www.f5.com/solutions/application-security/ssl-visibility

(last accessed 30 Nov. 2020).

Second, some commenters argued financial institutions should be able to implement alternatives to encryption without obtaining approval from the Qualified Individual.

168

The New York Insurance Association expressed concern financial institutions might feel they need to encrypt all customer information because of the risk that the alternative controls approved by the Qualified Individual would be “second guessed” in the event unencrypted data is compromised.

169

The Commission, however, believes this concern is a core element of information security based on risk assessment. Every aspect of an information security program is based on the judgment of the financial institution and its staff. The Qualified Individual's decision concerning alternate controls, like other decisions by the financial institution and its staff, will be subject to review in any enforcement action to determine whether the decision was appropriate. If the Qualified Individual is not required to make a formal decision, it is much more likely a decision not to encrypt information will be made even if there is no compensating control, or even made without the Qualified Individual's knowledge.

168

Bank Policy Institute (comment 39, NPRM), at 14; New York Insurance Association (comment 31, NPRM), at 1.

169

New York Insurance Association (comment 31, NPRM) at 1.

Third, the National Pawnbrokers Association (“NPA”) expressed concern that if pawnbrokers are required to encrypt customer information they may fall out of compliance with state and local regulations concerning transaction reporting.

170

NPA stated pawnbrokers are often required by state or local law to report every pawn transaction, along with nonpublic personally identifiable consumer information, to law enforcement, and the agencies that receive this information “prefer to take this information electronically and in unencrypted forms.”

171

The Commission believes if transmitting the information in unencrypted form is a preference of the agencies and not a requirement, then pawnbrokers can comply with both the Safeguards Rule and these laws by encrypting any transmissions that include customer information. If there are cases where a required transmission of customer information cannot be encrypted for technical reasons, then the pawnbroker's Qualified Individual will need to work with the law enforcement agency to implement alternative compensating controls to ensure the customer information remains secure during these transmissions.

172

170

National Pawnbrokers Association (comment 3, Workshop), at 2-3.

171

Id.

at 2.

172

NADA suggested it is not clear how the encryption requirement will apply to customer information held on a service provider's system or on the systems of the subcontractors of the service provider. National Automobile Dealers Association (comment 46, NPRM), at 21-22. The Commission believes the Final Rule lays out a financial institution's obligations in this situation: It requires customer information be encrypted unless infeasible. Section 314.4(e), in turn, requires financial institutions to require service providers to implement and maintain appropriate safeguards by contract and to periodically assess the continued adequacy of those measures. A financial institution that uses a service provider to store and process customer information must require that service provider to encrypt that information and periodically determine whether it continues to do so. If it is infeasible for the service provider to meet these requirements then the financial institution's Qualified Individual must work with the service provider to develop compensating controls or cease doing business with the service provider.

The Final Rule adopts this paragraph as paragraph (c)(3) without revision.

Secure Development Practices

Proposed paragraph (c)(5) required financial institutions to “[a]dopt secure development practices for in-house developed applications utilized” for “transmitting, accessing, or storing customer information.” In this paragraph, the Commission proposed requiring financial institutions to address the security of software they develop to handle customer information, as distinct from the security of their networks that contain customer information.

173

In addition, the Proposed Rule required “procedures for evaluating, assessing, or testing the security of externally developed applications [financial institutions] utilize to transmit, access, or store customer information.” This provision required financial institutions to take steps to verify that applications they use to handle customer information are secure.

174

173

See, e.g.,

Complaint,

FTC

v.

D-Link Systems, Inc.,

No. 3:17-CV-00039-JD (N.D. Cal. March 20, 2017) (alleging company failed to provide reasonable security when it failed to adequately test the software on its devices).

174

See, e.g.,

Complaint,

Lenovo,

FTC No. 152-3134 (January 2, 2018) (alleging company failed to provide reasonable security by failing to properly assess and address security risks caused by third-party software).

Some commenters argued evaluating the security of externally developed software would be too expensive or impractical for some financial institutions,

175

while others raised different concerns. The American Council on Education suggested, in cases in which a financial institution cannot obtain access to a software provider's code or technical

infrastructure, then evaluating the security of its software is infeasible.

176

NADA further suggested in order to evaluate the security of software, financial institutions would need to hire an expensive IT professional.

177

175

American Council on Education (comment 24, NPRM), at 11; National Automobile Dealers Association (comment 46, NPRM), at 26-27.

176

American Council on Education (comment 24, NPRM), at 11.

177

National Automobile Dealers Association (comment 46, NPRM), at 26-27.

The Commission does not agree with these assertions. Evaluating the security of software does not require access to the source code of that software or access to the provider's infrastructure. For example, a provider can supply the steps it took to ensure the software was secure, whether it uses encryption to transmit information, and the results of any testing it conducted. In addition, there are third party services that assess software. An institution can also set up automated searches regarding vulnerabilities, patches, and updates to software listed on the financial institution's inventory. The exact nature of the evaluation required will depend on the size of the financial institution and the amount and sensitivity of customer information associated with the software. If the software will be used to handle large amounts of extremely sensitive information, then a more thorough evaluation will be warranted. Likewise, the nature of the software used will also affect the evaluation. Software that has been thoroughly tested by third parties may need little more than a review of the test results, while software that has not been widely used and tested will require closer examination.

The Commission adopts proposed paragraph (c)(5) as paragraph (c)(4) of the Final Rule.

Multi-Factor Authentication

Proposed paragraph (c)(6) required financial institutions to “implement multi-factor authentication for any individual accessing customer information” or “internal networks that contain customer information.”

178

The Proposed Rule would have allowed financial institutions to adopt a method other than multi-factor authentication that offers reasonably equivalent or more secure access controls with the written permission of its Qualified Individual. In the Final Rule, the Commission retains the general requirements of proposed paragraph (c)(6) as paragraph (c)(5), with some modifications described below.

178

Proposed 16 CFR 314.4(c)(6).

Although several commenters expressed support for including a multi-factor authentication requirement in the Final Rule,

179

others opposed such a requirement. For example, ACE argued a blanket requirement mandating multi-factor authentication for all institutions of all sizes and complexities is not the best solution.

180

The National Independent Automobile Dealers Association (NIADA) commented the costs of multi-factor authentication would be too high for some financial institutions because it would need to be built into their information systems from scratch.

181

NIADA also argued adopting multi-factor authentication would disrupt a financial institution's activities as employees had to “jump through multiple hoops to log in.”

182

Cisco Systems, Inc. argued that while multi-factor authentication is an effective safeguard, it should not be specifically required by the Rule because, while it is currently good security practice, in the future multi-factor authentication may become outdated, and that allowing financial institutions to satisfy the Rule in this way could result in inadequate protection.

183

179

Justine Bykowski (comment 12, NPRM); Princeton University Center for Information Technology Policy (comment 54, NPRM), at 6-7; Electronic Privacy Information Center (comment 55, NPRM), at 8; National Consumer Law Center and others (comment 58, NPRM), at 2;

see also

Remarks of Wendy Nather, Safeguards Workshop Tr.,

supra

note 17, at 240-41 (discussing the security poverty line).

180

American Council on Education (comment 24, NPRM), at 11-12.

181

National Independent Automobile Dealers Association (comment 48, NPRM), at 6;

see also

Ken Shaurette (comment 19, NPRM) (questioning whether multi-factor authentication is appropriate for all financial institutions).

182

National Independent Automobile Dealers Association (comment 48, NPRM), at 6.

183

Cisco Systems, Inc. (comment 51, NPRM), at 2-4.

Other commenters did not dispute the benefits of multi-factor authentication generally, but argued the Rule should limit the multi-factor authentication requirement. Some of these commenters stated the Rule should only require multi-factor authentication when the financial institution's risk assessment justifies it.

184

Others argued there should be a distinction between internal access and external access. For example, some commenters argued the Rule should not require multi-factor authentication when a user accesses customer information from an internal network,

185

because there are other controls on internal access that make multi-factor authentication unnecessary.

186

Another commenter stated requiring multi-factor authentication when a customer accesses their information from an external network could create problems for some institutions.

187

Finally, the Princeton Center argued the Rule should be amended to clarify that multi-factor authentication should be required for internal and external networks.

188

184

Bank Policy Institute (comment 39, NPRM), at 11-13; Global Privacy Alliance (comment 38, NPRM), at 8.

185

Electronic Transactions Association (comment 27, NPRM), at 3 n.1; U.S. Chamber of Commerce (comment 33, NPRM), at 11; CTIA (comment 34, NPRM), at 11; Global Privacy Alliance (comment 38, NPRM), at 8; Bank Policy Institute (comment 39, NPRM), at 12; National Automobile Dealers Association (comment 46, NPRM), at 28; National Independent Automobile Dealers Association (comment 48, NPRM), at 6; New York Insurance Association (comment 31, NPRM), at 1.

186

CTIA (comment 34, NPRM), at 11; Electronic Transactions Association (comment 27, NPRM), at 3 n.1; U.S. Chamber of Commerce (comment 33, NPRM), at 11.

187

American Council on Education (comment 24, NPRM), at 11.

188

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 6-7;

see also

Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 102 (stating his company TECH LOCK supports requiring multi-factor authentication for users connecting from internal networks).

Finally, CTIA took issue with the proposed requirement that the Qualified Individual be permitted to approve “reasonably equivalent or more secure” controls if multi-factor authentication is not feasible, suggesting instead that Qualified Individuals be permitted to approve “effective alternative compensating controls.”

189

189

CTIA (comment 34, NPRM), at 11-12;

see also

Electronic Transactions Association (comment 27, NPRM) at 3 (suggesting use of the term “alternative compensating controls”).

The Commission disagrees with the commenters who stated the Rule should not include a multi-factor authentication requirement. As to costs, many affordable multi-factor authentication solutions are available in the marketplace.

190

Most financial institutions will be able to find a solution that is both affordable and workable for their organization. In the cases when that it is not possible, the

Rule allows financial institutions to adopt reasonably equivalent controls.

191

190

See, e.g.,

Slides Accompanying Remarks of Brian McManamon, “MFA/2FA Pricing (Duo),” in Safeguards Workshop Slides,

supra

note 72, at 30 (setting forth prices for multi-factor/two-factor services from Duo, including free services for up to ten users); Remarks of Brian McManamon, Safeguards Workshop Tr.,

supra

note 17, at 102-03; Slides Accompanying Remarks of Lee Waters, “Estimated Costs of Proposed Changes,” in Safeguards Workshop Slides,

supra

note 72, at 26 estimating costs of MFA to be $50 for smartcard or fingerprint readers, and $10 each per smartcard); Slides Accompanying Remarks of Wendy Nather, “Authentication Methods by Industry,” in Safeguards Workshop Slides,

supra

note 72, at 37 (chart showing the use of MFA solutions such as Duo Push, phone call, mobile passcode, SMS passcode, hardware token, Yubikey passcode, and U2F token in industries such as financial services and higher education); Remarks of Wendy Nather, Safeguards Workshop Tr.,

supra

note 17,

at 233-34.

191

See also

Remarks of James Crifasi, Safeguards Workshop Tr.,

supra

note 17, at 103-04 (noting even where legacy systems do not support multi-factor authentication, alternative measures can be used and “it's things that can easily be done.”)

As to potential disruptions requiring multi-factor authentication may cause, the Commission notes that many organizations, both financial institutions and otherwise, currently require employees to use multi-factor authentication without major disruption.

192

Many multi-factor authentication systems are available that do not materially increase the time it takes to log into a system as compared to the use of only a password.

193

In short, multi-factor authentication is an extremely effective way to prevent unauthorized access to a financial institution's information system,

194

and its benefits generally outweigh any increased time it takes to log into a system. In those situations when the need for quick access outweighs the security benefits of multi-factor authentication, the Rule allows the use of reasonably equivalent controls.

192

See, e.g.,

Remarks of Randy Marchany, Safeguards Workshop Tr.,

supra

note 17, at 236-38 (describing how Virginia Tech implemented multi-factor authentication in 2016 for its more than 156,000 users); Slides Accompanying Remarks of Wendy Nather, “Authentication Methods by Industry,” in Safeguards Workshop Slides,

supra

note 72, at 37 demonstrating the types of multi-factor authentication used by health care, financial services, higher education and the Federal Government); Remarks of Wendy Nather, Safeguards Workshop Tr.,

supra

note 17, at 233-35.

193

See

Remarks of Wendy Nather, Safeguards Workshop Tr.,

supra

note 17, at 234 (describing how a phone call to a landline is popular in some segments).

194

See, e.g.,

Remarks of Matthew Green, Safeguards Workshop Tr.,

supra

note 17, at 266 (explaining passwords are not enough of an authentication feature but when MFA is used and deployed, the defenders can win against attackers);

id.

at 239 (describing how because smart phones have modern secure hardware processors, biometric sensors and readers built in, increasingly consumers can get the security they need through the devices they already have by storing cryptographic authentication keys on the devices and then using the phone to activate them).

Finally, although the Commission agrees the Rule should not lock financial institutions into using outmoded or obsolete technologies, the basic structure of using multiple factors to identify a user is unlikely to be rendered obsolete in the near future. The Rule's definition of multi-factor authentication addresses only this principle and does not require any particular technology or technique to achieve it. This should allow it to accommodate most changes in information security practices. In the event of an unforeseen change to the information security environment that would discount the value of multi-factor authentication, the Commission will adjust the Rule accordingly.

195

195

The Mortgage Bankers Association expressed concern the Proposed Rule would not allow the use of a single-sign on process, where a user is given access to multiple applications with the use of one set of credentials. Mortgage Bankers Association (comment 26, NPRM), at 7. The Commission does not view the Rule as preventing such a system, if the user has used multi-factor authentication to access the system and the system is designed to ensure any user of a given application has been subjected to multi-factor authentication.

The Commission agrees with the commenter who stated multi-factor authentication is justified both when external users, such as customers, and internal users, such as employees, access an information system. Multi-factor authentication can prevent many attacks focused on using stolen passwords from both employees and customers to access customer information. Other common attacks on information systems, such as social engineering or brute force password attacks, target employee credentials and use those credentials to get access to an information system.

196

These attacks can usually be stopped through the use of multi-factor authentication. Accordingly, the Final Rule requires multi-factor authentication whenever any individual—employee, customer or otherwise—accesses an information system. If a financial institution determines it is not the best solution for its information system, it may adopt reasonably equivalent controls with the approval of the Qualified Individual.

196

See

Remarks of Pablo Molina, Safeguards Workshop Tr.,

supra

note 17, at 30 (mentioning “phishing,” or social engineering, as a common type of cybersecurity attack); Remarks of Lee Waters, Safeguards Workshop,

supra

note 17, at 91 (same); Remarks of Michele Norin, Safeguards Workshop Tr.,

supra

note 17, at 179 (same);

see also

Cyber Div., Fed. Bureau of Investigation,

Private Industry Notification No. 20200303-001, Cyber Criminals Conduct Business Email Compromise through Exploitation of Cloud-Based Email Services, Costing U.S. Businesses Over Two Billion Dollars,

(March 2020),

https://www.ic3.gov/media/news/2020/200707-4.pdf,

at 1-2, (last accessed 1 Dec. 2020) (“Between January 2014 and October 2019, the Internet Crime Complaint Center (IC3) received complaints totaling over $2.1 billion in actual losses from [Business Email Compromise (“BEC”)] scams targeting the largest [cloud-based email] platforms. Losses from BEC scams overall have increased every year since IC3 began tracking the scam in 2013 and have been reported in all 50 states and in 177 countries.”).

The Commission recognizes the language of the Proposed Rule may have created some confusion by its use of the term “internal networks” to define the systems affected by the multi-factor authentication requirement, instead of the term “information systems” as used other places in the Rule.

197

In addition, the Commission agrees with commenters that argued separating the multi-factor authentication into two sentences created confusion.

198

Accordingly, the Commission modifies paragraph (c)(5) of the Final Rule, which was proposed as paragraph (c)(6), to require financial institutions to “[i]mplement multi-factor authentication for any individual accessing any information system, unless your Qualified Individual has approved in writing the use of reasonably equivalent or more secure access controls.”

197

Consumer Data Industry Association (comment 36, NPRM), at 6-7; Cisco Systems, Inc. (comment 51, NPRM), at 3-4.

198

Bank Policy Institute (comment 39, NPRM), at 11.

Finally, the Commission declines to adopt CTIA's proposed alternative that would allow Qualified Individuals to approve “effective alternative compensating controls,” even if they are not “reasonably equivalent or more secure” than multi-factor authentication. Given the important role multi-factor authentication has in access control, any alternative measure should provide at least as much protection as multi-factor authentication.

199

199

NADA argued, for financial institutions that have appointed a third party to act as their information security coordinator, this provision would require the institution to turn over decisionmaking to someone “with no stake in the business outcome.” National Automobile Dealers Association (comment 46, NPRM), at 29-30. This concern misinterprets the role of the Qualified Individual. Whether the Qualified Individual is inside the company or at a third-party company, that individual will report to and be supervised by senior management of a financial institution (unless the Qualified Individual is the head of the financial institution). If a Qualified Individual recommends a safeguard that would not be practical for the business, the financial institution is not required to adopt this safeguard but can use an alternative adequate safeguard that will be functional. Indeed, when it comes to third parties, the Rule specifically requires someone in the financial institution direct and oversee the third party.

Audit Trails

Proposed paragraph (c)(7) required information security programs to include audit trails designed to detect and respond to security events.

200

Audit trails are chronological logs that show who has accessed an information system and what activities the user engaged in during a given period.

201

200

Proposed 16 CFR 314.4(c)(7).

201

See

Information Technology Laboratory Computer Security Resource Center,

Glossary,

National Institute of Standards and Technology,

https://csrc.nist.gov/glossary/term/audit-trail

(last accessed Dec. 2, 2020).

Some commenters supported this requirement.

202

The Princeton Center noted audit trails are “crucial to designing effective security measures

that allow institutions to detect and respond to security incidents.”

203

It also stated audit trails “help understand who has accessed the system and what activities the user has engaged in.”

204

202

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 8; Electronic Privacy Information Center (comment 55, NPRM), at 8.

203

Princeton University Center for Information Technology Policy (comment 54, NPRM), at 8.

204

Id.

Other commenters argued this requirement imposed unclear obligations or would not improve security.

205

For example, GPA commented the Proposed Rule conflated the use of logs to reconstruct past events and the active use of logs to monitor user activity.

206

The American Financial Services Association argued adding logging capabilities to some legacy systems would be expensive and difficult.

207

Another commenter argued the increased use of cloud storage would mean that financial institutions might not have access to any audit trails.

208

In addition, NADA argued it did not believe maintenance of logs would increase security but would instead create records that could be sought by parties “seeking to place blame” for breaches.

209

205

National Automobile Dealers Association (comment 46, NPRM), at 30-31; National Independent Automobile Dealers Association (comment 48, NPRM), at 6; American Financial Services Association (comment 41, NPRM), at 6; Global Privacy Alliance (comment 38, NPRM), at 11.

206

Global Privacy Alliance (comment 38, NPRM), at 11.

207

American Financial Services Association (comment 41, NPRM), at 6.

208

American Council of Education (comment 24, NPRM), at 12.

209

National Automobile Dealers Association (comment 46, NPRM), at 30-31.

The Commission believes logging user activity is a crucial component of information security because in the event of a security event it allows financial institutions to understand what was accessed and when. However, the term “audit trails” may have been unclear in this context. In order to clarify that logging user activity is a part of the user monitoring process, the Final Rule does not include paragraph (c)(7) of the Proposed Rule and instead modifies the user monitoring provision to include a requirement to log user activity.

210

By putting the “monitoring” and “logging” requirements together, the Final Rule provides greater clarity on the comment raised by the GPA: Financial institutions are expected to use logging to “monitor” active users and reconstruct past events.

210

See

Final Rule, 16 CFR 314.4(c)(8).

Disposal Procedures

Proposed paragraph (c)(8) required financial institutions to develop procedures for the secure disposal of customer information that is no longer necessary for their business operations or other legitimate business purposes.

211

The Proposed Rule allowed the retention of information when retaining the information is required by law or where targeted disposal is not feasible.

211

Proposed 16 CFR 314.4(c)(8).

Some commenters supported the inclusion of a disposal requirement as proposed or suggested that the disposal requirements should be strengthened.

212

Consumer Reports argued financial institutions should be required to dispose of customer information when it is no longer needed for the business purpose for which it was gathered.

213

The Princeton Center suggested the Rule require dis

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.

A word about cookies

We need a few to keep you signed in and the library working. The rest help us see which pages people use and where they get stuck. They stay off unless you say yes.