Operational Resilience Framework for Futures Commission Merchants, Swap Dealers, and Major Swap Participants

Federal RegisterJan 24, 2024

Ask Donna

What actually matters in this document.

Text

COMMODITY FUTURES TRADING COMMISSION

17 CFR Parts 1 and 23

RIN 3038-AF23

Operational Resilience Framework for Futures Commission Merchants, Swap Dealers, and Major Swap Participants

AGENCY:

Commodity Futures Trading Commission.

ACTION:

Notice of proposed rulemaking.

SUMMARY:

The Commodity Futures Trading Commission (CFTC or Commission) is proposing to require that futures commission merchants, swap dealers, and major swap participants establish, document, implement, and maintain an Operational Resilience Framework reasonably designed to identify, monitor, manage, and assess risks relating to information and technology security, third-party relationships, and emergencies or other significant disruptions to normal business operations. The framework would include three components—an information and technology security program, a third-party relationship program, and a business continuity and disaster recovery plan—supported by broad requirements relating to governance, training, testing, and recordkeeping. The proposed rule would also require certain notifications to the Commission and customers or counterparties. The Commission is further proposing guidance relating to the management of risks stemming from third-party relationships.

DATES:

Comments must be received on or before March 2, 2024.

ADDRESSES:

You may submit comments, identified by RIN number 3038-AF23, by any of the following methods:

•

CFTC Comments Portal: https://comments.cftc.gov.

Select the “Submit Comments” link for this rulemaking and follow the instructions on the Public Comment Form.

•

Mail:

Christopher Kirkpatrick, Secretary of the Commission, Commodity Futures Trading Commission, Three Lafayette Centre, 1155 21st Street NW, Washington, DC 20581.

•

Hand Delivery/Courier:

Follow the same instructions as for Mail, above.

Please submit your comments using only one of these methods. Submissions through the CFTC Comments Portal are encouraged.

All comments must be submitted in English, or if not, accompanied by an English translation. Comments will be posted as received to

https://comments.cftc.gov.

You should submit only information that you wish to make available publicly. If you wish the Commission to consider information that you believe is exempt from disclosure under the Freedom of Information Act (FOIA), a petition for confidential treatment of the exempt information may be submitted according to the procedures established in Commission regulation 145.9.

17 CFR 145.9. The Commission's regulations are found at 17 CFR chapter I (2022).

The Commission reserves the right, but shall have no obligation, to review, pre-screen, filter, redact, refuse or remove any or all of your submission from

https://comments.cftc.gov

that it may deem to be inappropriate for publication, such as obscene language. All submissions that have been redacted or removed that contain comments on the merits of the rulemaking will be retained in the public comment file and will be considered as required under the Administrative Procedure Act and other applicable laws, and may be accessible under the FOIA.

FOR FURTHER INFORMATION CONTACT:

Amanda L. Olear, Director, at 202-418-5283 or

aolear@cftc.gov;

Pamela Geraghty, Deputy Director, at 202-418-5634 or

pgeraghty@cftc.gov;

Fern Simmons, Associate Director, at 202-418-5901 or

fsimmons@cftc.gov;

Elise Bruntel, Special Counsel, at 202-418-5577 or

ebruntel@cftc.gov;

Market Participants Division, Commodity Futures Trading Commission, Three Lafayette Centre, 1151 21st Street NW, Washington, DC 20581.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Introduction

II. Proposal

A. Generally—Proposed Paragraph (b)

1. Purpose and Scope; Components—Proposed Paragraphs (b)(1) and (b)(2)

2. Standard—Proposed Paragraph (b)(3)

3. Request for Comment

B. Governance—Proposed Paragraph (c)

1. Approval of Components—Proposed Paragraph (c)(1)

2. Risk Appetite and Risk Tolerance Limits—Proposed Paragraph (c)(2)

3. Internal Escalations—Proposed Paragraph (c)(3)

4. Consolidated Program or Plan—Proposed Paragraph (c)(4)

5. Request for Comment

C. Information and Technology Security Program—Proposed Paragraph (d)

1. Risk Assessment—Proposed Paragraph (d)(1)

2. Effective Controls—Proposed Paragraph (d)(2)

3. Incident Response Plan—Proposed Paragraph (d)(3)

4. Request for Comment

D. Third-Party Relationship Program—Proposed Paragraph (e)

1. Third-Party Relationship Lifecyle Stages—Proposed Paragraph (e)(1)

2. Heightened Requirements for Critical Third-Party Service Providers—Proposed Paragraph (e)(2)

3. Third-Party Service Provider Inventory—Proposed Paragraph (e)(3)

4. Retention of Responsibility—Proposed Paragraph (e)(3)

5. Application to Existing Third-Party Relationships

6. Guidance on Third-Party Relationship Programs—Proposed Paragraph (e)(4); Appendix A to Part 1; Appendix A to Subpart J of Part 23

7. Request for Comment

E. Business Continuity and Disaster Recovery Plan—Proposed Paragraph (f)

1. Definition of “Business Continuity and Disaster Recovery Plan”

2. Purpose—Proposed Paragraph (f)(1)

3. Minimum Contents—Proposed Paragraph (f)(2)

4. Accessibility—Proposed Paragraph (f)(3)

5. Request for Comment

F. Training and Distribution—Proposed Paragraph (g)

G. Review and Testing—Proposed Paragraph (h)

1. Reviews—Proposed Paragraph (h)(1)

2. Testing—Proposed Paragraph (h)(2)

3. Independence—Proposed Paragraph (h)(3)

4. Documentation—Proposed Paragraph (h)(4)

5. Internal Reporting—Proposed Paragraph (h)(5)

6. Request for Comment

H. Required Notifications—Proposed Paragraphs (i) and (j)

1. Commission Notification of Incidents—Proposed Paragraph (i)(1)

2. Commission Notification of BCDR Plan Activation—Proposed Paragraph (i)(2)

3. Notifications to Customers or Counterparties—Proposed Paragraph (j)

4. Request for Comment

I. Amendment and Expansion of Other Provisions in Current Commission Regulation 23.603

1. Emergency Contacts—Proposed Paragraph (k)

2. Recordkeeping—Proposed Paragraph (l)

3. Request for Comment

J. Cross-Border Application for Swap Entities

K. Implementation Period

III. Related Matters

A. Regulatory Flexibility Act

B. Paperwork Reduction Act

C. Cost-Benefit Considerations

D. Antitrust Laws

I. Introduction

In 2012 and 2013, the Commission adopted rules requiring that futures commission merchants (FCMs),

swap dealers (SDs)

and major swap

participants (MSPs)

establish risk management programs (RMPs).

The rules require that SDs and MSPs (together, swap entities) and FCMs design their RMPs to monitor and manage the risks associated with their activities as swap entities or FCMs.

Such risks include, but are not limited to, market, credit, liquidity, segregation, settlement, capital, and operational risk.

Taken together, the RMP rules support a unified Commission objective: to require FCMs and swap entities (collectively, covered entities) to establish comprehensive risk management practices to mitigate systemic risk and promote customer protection.

Recognizing that covered entities vary in size and complexity, the RMP rules identify certain elements that must, at a minimum, be included as part of the RMP, and require that certain risks must be taken into account; but the rules otherwise allow covered entities flexibility to design RMPs tailored to their circumstances and organizational structures.

See

7 U.S.C. 1a(28), 17 CFR 1.3 (defining “futures commission merchant”).

See

7 U.S.C. 1a(49), 17 CFR 1.3 (defining “swap dealer”).

See

7 U.S.C. 1a(33), 17 CFR 1.3 (defining “major swap participant”).”

See

17 CFR 1.11; 17 CFR 23.600; Enhancing Protections Afforded Customers and Customer Funds Held by Futures Commission Merchants and Derivatives Clearing Organizations, 78 FR 68506 (Nov. 14, 2013) (Final FCM RMP Rule); Swap Dealer and Major Swap Participant Recordkeeping, Reporting, and Duties Rules; Futures Commission Merchant and Introducing Broker Conflicts of Interest Rules; and Chief Compliance Officer Rules for Swap Dealers, Major Swap Participants, and Futures Commission Merchants, 77 FR 20128 (Apr. 3, 2012) (Final Swap Entities RMP Rule).

See

17 CFR 1.11(c); 17 CFR 23.600(b). The RMP rule for FCMs does not apply to FCMs that do not accept or hold customer assets.

See

17 CFR 1.11(a).

See

17 CFR 1.11(e); 17 CFR 23.600(c).

See

Final Swap Entities RMP Rule, 77 FR at 20128; Final FCM RMP Rule, 78 FR 68506.

See, e.g.,

Regulations Establishing and Governing the Duties of Swap Dealers and Major Swap Participants, 75 FR 71397, 71399 (Nov. 23, 2010) (Proposed Swap Entities RMP Rule) (“The Commission's rule has been designed such that the specific elements of a risk management program will vary depending on the size and complexity of a [swap entity's] business operations.”).

In the decade since the RMP rules were adopted, covered entities have encountered a wide variety of challenging conditions, including Brexit, the LIBOR transition, the COVID-19 pandemic stress period, the invasion of Ukraine, and general interest rate increases to tame inflation. Throughout this period, the Commission has, through its various oversight activities, observed that adherence to its RMP rules has supported covered entities' ability to withstand and recover from market challenges. The Commission therefore believes the RMP rules have helped establish a solid foundation of risk management among covered entities across various risk types, promoting a solid baseline standard of risk management that reduces overall systemic risk and enhances the Commission's customer protections.

Nevertheless, the Commission believes it has identified opportunities to adapt its regulations to further promote sound risk management practices, reduce risk to the U.S. financial system, and protect commodity interest customers and counterparties.

Specifically, as it relates to this proposal, the Commission believes that recent events, noted below, have highlighted the need for more particularized risk management requirements for covered entities designed to promote operational resilience. An outcome of the effective management of operational risk, “operational resilience” can be broadly defined as the ability of a firm to detect, resist, adapt to, respond to, and recover from operational disruptions.

As the use of technology and associated third-party service providers have expanded within the financial sector, so too have the sources of operational risk facing covered entities, notably the potential for technological failures and cyberattacks.

The Commission preliminarily believes that requirements for covered entities directed at promoting sound practices for managing these risks, as well as the risk of other potential physical disruptions to operations (

e.g.,

power outages, natural disasters, pandemics), and for mitigating their potential impact would not only strengthen individual covered entity operational resilience but would reduce risk to the U.S. financial system as a whole and help protect derivatives customers and counterparties.

The Commission recently solicited public comment on an advanced notice of proposed rulemaking regarding potential amendments to the RMP requirements.

See

Risk Management Program Regulations for Swap Dealers, Major Swap Participants, and Futures Commission Merchants, 88 FR 45826 (Jul. 18, 2023) (RMP ANPRM). The comment file is available at

https://comments.cftc.gov/PublicComments/CommentList.aspx?id=7412.

See

Proposed Swap Entities RMP Rule, 75 FR 71399, n.12 (defining “operational risk” as including “the risk of loss due to deficiencies in information systems, internal processes and staffing, or disruptions from external events that result in the reduction, deterioration, or breakdown in services or controls within the firm.”). Several sources have produced definitions of “operational resilience” relevant to the financial sector.

See e.g.,

Board of Governors of the Federal Reserve System (FRB), the Office of the Comptroller of the Currency (OCC), and the Federal Deposit Insurance Corporation (FDIC) (together, the prudential regulators),

Sound Practices to Strengthen Operational Resilience

at 2 (Oct. 30, 2020) (Prudential Operational Resilience Paper) (defining “operational resilience” as the “ability to deliver operations, including critical operations and core business lines, through a disruption from any hazard.”); Basel Committee on Banking Supervision (BCBS),

Principles for Operational Resilience

at 2, 3 (Mar. 31, 2021) (BCBS Operational Resilience Principles) (“ability of a bank to deliver critical operations through disruption”); National Institute of Standards and Technology (NIST),

Developing Cyber-Resilient Systems: A Systems Security Engineering Approach,

SP 800-160, Vol. 2, Rev. 1 at 76 (Dec. 2021) (“ability of systems to resist, absorb, and recover from or adapt to an adverse occurrence during operation that may cause harm, destruction, or loss of ability to perform mission-related functions.”). Core to each of these definitions is the notion of being able to continue to operate or perform despite a disruption.

See

Jason Harrell, Depository Trust & Clearing Corporation (DTCC) Managing Director, Head of External Engagements, “Operational and Technology Risk, Evolving Cybersecurity Risks in a Digitalized Era” (Sept. 20, 2023) (“While partnerships with third parties offer rapid solutions for institutions to access the latest technologies and capabilities, they also increase the surface area for potential threat actors to gain access to an institution, causing cyber incidents that can impact the institution's operations and potentially create additional sector impacts.”).

Responding to the RMP ANPRM, several commenters suggested the Commission consider addressing cybersecurity risk independently.

See

Americans for Financial Reform Education Fund (AFREF) and Public Citizen Letter at 6 (Sept. 18, 2023) (AFREF&PC Letter); Better Markets Letter Re: Risk Management Program Regulations for Swap Dealers, Major Swap Participants, and Futures Commission Merchants (RIN 3038-AE59) at 6-9 (Sept. 18, 2023) (Better Markets Letter); R.J. O'Brien & Associates LLC Letter at 5-6 (Sept. 18, 2023) (R.J. O'Brien Letter). AFRF and Public Citizen also recommended that the Commission consider extending its risk management regulations to encompass third-party service providers for information technology services.

See

AFREF&PC Letter at 2.

The importance of operational resilience in the financial industry has come into stark relief in the past few years, particularly following the COVID-19 pandemic. At the start of the pandemic, Commission staff initiated near daily in-depth discussions with covered entities as those registrants navigated the myriad challenges presented during that time. Through a combination of sustained intensive effort on the part of the covered entities, and targeted no-action positions and exemptive relief provided by Commission staff, covered entities generally continued to operate without material disruption to their CFTC-regulated activities. As a result of this unprecedented experience, the Commission considered whether there were additional opportunities for it to act to gain ongoing transparency into, and to provide further regulatory support to, covered entities' operational resilience practices outside of an unfolding crisis. Commission staff then began the work of assessing the current operational resilience landscape for covered entities and determining how the Commission could act to further the holistic consideration and adoption of operational resilience practices amongst covered entities to ensure that certain

operational risks impacting their CFTC-regulated activities were being addressed on an ongoing basis.

In particular, one area of increased focus is cyber risk. In 2022, cyber intelligence firms reported that the financial sector was among the most impacted by malicious emails, and was ultimately the most breached over the course of the year, with more than 566 successful attacks resulting in 254 million leaked records by early December 2022.

For the past two years, financial institutions responding to a DTCC risk survey have identified cyber risk as one of the top five risks to global financial markets, highlighting the increased sophistication of cyber criminals and the industry's growing digital footprint as key drivers.

Given that remote access and cloud computing may become permanent features of the financial markets, the need for financial institutions to strengthen, adapt, and prioritize their information and technology risk practices would seem critical to preserving the continued integrity and stability of U.S. financial markets.

See

Trellix,

The Threat Report Fall 2022

at 11 (Nov. 2022) (noting that the financial services sector was the most targeted by malicious emails in Q3 of 2022); Flashpoint,

Flashpoint Year In Review: 2022 Financial Threat Landscape

(Dec. 20, 2022) (citing finance and insurance as the most-breached sector in 2022).

See

DTCC, Systemic Risk Barometer Survey: 2023 Risk Forecast (Dec. 7, 2022); DTCC, Systemic Risk Barometer Survey: 2022 Risk Forecast (Dec. 13, 2021) (naming cyber risk as the top risk to the economy).

See also

Bank for International Settlements (BIS), Financial Stability Institute (FSI), FSI Insights on policy implementation No. 50, Banks' cyber security—a second generation of regulatory approaches (June 12, 2023) (FSI Cybersecurity Paper) (citing a 2023 report that most chief risk officers consider cyber risk the top threat to the banking industry and the most likely to result in a crisis or major operational disruption); Federal Bureau of Investigation, internet Crime Complaint Center Releases 2022 Statistics (Mar. 22, 2023) (“Cyber-enabled crime has been around for many years, but methods used by perpetrators continue to increase in scope and sophistication emanating from around the world.”).

See

FRB,

Cybersecurity and Financial System Resilience Report

at 15 (Aug. 2023) (“The rising number of advanced persistent threats increases the potential for malicious cyber activity within the financial sector. Combined with the increased internet-based interconnectedness between financial institutions and the increasing dependence on third-party service providers, these threats may result in incidents that affect one or more participants in the financial services sector simultaneously and have potentially systemic consequences.”).

Covered entities have experienced firsthand how breaches of information and technology security can reduce their ability to protect customers. In 2016, for instance, a hacker was able to access customer records held on an FCM's backup storage device after a default configuration of that device left it open to infiltration via the internet.

In 2018, a successful phishing attack on an FCM compromised customer information and resulted in the FCM's acceptance of a fraudulent wire request that took $1 million in funds from a customer's account.

Other regulators have also taken action against banks registered as swap entities where failed controls and third-party service providers intersected to result in the significant exposure of customer information.

Even more recently, a ransomware attack on a U.S. broker-dealer in November 2023 was so significant, news reports indicate that the brokerage required a capital injection from a parent entity to settle $9 billion in trades, an amount many times larger than its net capital.

See In re AMP Global Clearing LL

C, CFTC Docket No. 18-10 (Feb. 12, 2018).

See In re Phillip Capital Inc.,

CFTC Docket No. 19-22 (Sept. 12, 2019).

See, e.g., In re Capital One, N.A. and Capital One Bank (USA), N.A.,

AA-EC-20-49 (Aug. 5, 2020) (OCC finding that failed risk management practices resulted in exposure of 100 million individual credit card applications, including approximately 140,000 social security numbers, by a former cloud servicer employee);

In re Morgan Stanley Smith Barney LLC,

File No. 3-17280 (Jun. 8, 2016) (Securities and Exchange Commission (SEC) finding that failed risk management controls allowed an employee to impermissibly access and transfer data regarding 730,000 accounts to a personal server, which was ultimately hacked by third parties).

See

Paritosh Bansal, Reuters, “Inside Wall Street's scramble after ICBC hack” (Nov. 13, 2023) (reporting that the firm asked clients to temporarily suspend business with them and clear trades elsewhere).

Against the backdrop of that work, a recent and well-documented incident serves as an important cautionary tale about the potential systemic impact of an operational event at a third-party service provider. On January 30, 2023, a ransomware attack on ION Markets, a division of UK-based third-party service provider ION Group LLC (ION), resulted in a two-week disruption in mid-office activities at several FCMs. ION provides order management, execution, trading, and trade processing services for several FCMs, including about 20 percent of clearing members at the Chicago Mercantile Exchange (CME), but also provides software services to many other financial institutions, notably many systemically important banks.

FCMs affected by the attack had to process trades manually, leading to delays in the timely and accurate reporting of trade data to the CFTC, and consequently a temporary lag in production of the Commission's weekly Commitments of Traders report.

The incident was initially so concerning that Japan cut off all connectivity with ION.

Within a couple days of the attack, however, regulators, including the CFTC, coordinated efforts to determine that the attack was limited to a small number of software applications relied on within the cleared derivatives space by about forty-two (42) institutions, with no significant impact to systemically important banks.

See

Luke Clancy, Risk.net, “One-fifth of CME clearing members hit by Ion hack” (Mar. 9, 2023);

see also

Statement of Todd Conklin, Deputy Assistant Secretary, Department of the Treasury (Treasury), Office of Cybersecurity and Critical Infrastructure Protection (OCCIP),

The Cyber Threat Landscape for Financial Markets: Lessons Learned from ION Markets, Cloud Use in Financial Services, and Beyond,

CFTC Technology Advisory Committee Meeting Transcript at 160-166 (Mar. 22, 2023) (Conklin TAC Presentation) (describing the potential “sprawling impact zone” had the ION incident not been limited to its derivatives software services),

available at https://www.cftc.gov/sites/default/files/2023/07/1688400024/tac_032223_transcript.pdf.

CFTC, Statement on ION and the Impact to the Derivatives Markets (Feb. 2, 2023),

available at https://www.cftc.gov/PressRoom/SpeechesTestimony/cftcstatement020223.

The Commitment of Traders report is widely relied on by market participants for insight into positions held on exchange-traded futures and options.

See

Conklin TAC Presentation (Mar. 22, 2023).

Id.

During a March 8, 2023, meeting of the CFTC's Market Risk Advisory Committee (MRAC), panelists discussed how the collaborative work of the CFTC, industry, and self-regulatory organizations (including CME, the National Futures Association (NFA), and the Financial Industry Regulatory Authority (FINRA)) helped mitigate the impact of the ION incident, allowing affected firms to return to business as usual within a couple weeks.

Nevertheless, panelists agreed that the incident highlighted the interconnectedness of the derivatives markets and the need for firms to continue to adapt safeguards to address the ever-evolving threat landscape.

As the ION incident demonstrates, a

disruptive cyber event can reach beyond particular financial institutions directly experiencing events to other institutions in the financial markets or to others doing business with an impacted financial institution, and could potentially impact financial stability.

See

CFTC, The Market Risk Advisory Committee to Meet on March 8 (Mar. 8, 2023) (MRAC Meeting),

available at https://www.cftc.gov/PressRoom/Events/opaeventmrac030823; see also

Conklin TAC Presentation (discussing how Treasury implemented its cyber incident response playbook in the days following the ION incident to mitigate the potential for panic after news reports began circulating information that the incident was more significant than regulators had initially determined it was).

See

Statement of Walt Lukken, President and Chief Executive Officer, Futures Industry Association (FIA), MRAC Meeting Transcript at 41 (“While the number of clearing firms that use ION's suite of clearing products is limited, the interconnectedness of our markets made the outage impactful throughout the entirety of our marketplace.”);

see also

Statement of Tom W. Sexton, III, President and Chief Executive Officer, NFA, MRAC Meeting Transcript at 46 (“[O]ur member firms have adopted robust safeguards already that need to be adapted in light of today's and tomorrow's ongoing challenges and threats.”).

See

FIA, FIA Taskforce on Cyber Risk,

After Action Report and Findings

at 3 (Sept. 2023) (FIA Taskforce Report) (“The [ION incident] demonstrated that an outage at a single service provider can have damaging effects across a wide range of firms and threaten the orderly functioning of markets. The attack also demonstrated in vivid detail the complexities of restoring normal service.”).

In light of these and other events, the Commission believes that customer protection and the broader stability of the derivatives markets at large warrant more targeted CFTC requirements relating to the management of operational risk designed to promote operational resilience.

Specifically, the Commission believes that the absence of CFTC-specific requirements for covered entities that explicitly address information and technology security, as well as third-party risk, could impede the Commission's ability to fulfill its regulatory oversight obligations with respect to covered entities and ultimately weaken its ability to address systemic risk, protect customer assets, and promote responsible innovation.

The Commission further believes that enhanced CFTC oversight of covered entities with respect to operational resilience would help improve outcomes following operational disruptions by giving the Commission the ability to ensure that covered entities have actionable plans in place to address key operational risks.

Existing CFTC requirements for covered entities relating to operational risk or information security are more general in nature or limited in application.

See, e.g.,

17 CFR 1.11(e)(3)(ii) (providing, with respect to operational risk, that FCMs have automated financial risk management controls reasonably designed to prevent the placing of erroneous orders); Enhancing Protections Afforded Customers and Customer Funds Held by Futures Commission Merchants and Derivatives Clearing Organizations, 77 FR 67866, 67906 (Nov. 14, 2012) (describing Commission regulation 1.11(e)(3)(ii) as requiring an FCM's RMP to include automated financial risk management controls in order to reduce operational risk that could result from “fat finger” errors when submitting trades, or from technological “glitches” using automated trading); 17 CFR 23.600(c)(4)(vi) (requiring swap entities to take into account, among other things, secure and reliable operating and information systems with adequate, scalable capacity, and independence from the business trading unit; safeguards to detect, identify, and promptly correct deficiencies in operating and information systems; and reconciliation of all data and information in operating and information systems); 17 CFR 162.21 and 17 CFR 160.30 (requiring covered entities to adopt written policies and procedures addressing administrative, technical, and physical safeguards with respect to the information of consumers).

See

7 U.S.C. 5 (establishing among the purposes of the Commodity Exchange Act to deter disruptions to market integrity, to ensure the financial integrity of covered transactions and the avoidance of systemic risk, and to promote responsible innovation and fair competition among market participants).

II. Proposal

Section 4s(j)(2) of the Commodity Exchange Act (CEA or Act) expressly requires swap entities to establish robust and professional risk management systems adequate for managing their day-to-day business.

Section 4s(j)(7) further directs the Commission to prescribe rules governing the duties of swap entities, including the duty to establish risk management systems, which would include the management of operational risk.

The Commission is authorized to promulgate operational risk management requirements for FCMs pursuant to section 8a(5) of the CEA, which authorizes the Commission to make and promulgate such rules and regulations as, in the judgment of the Commission, are reasonably necessary to effectuate any of the provisions of, or to accomplish any of the purposes of, the CEA.

This general rulemaking authority may be used to prevent problems before they arise in the agency's blind spots,

and may be exercised to regulate circumstances or parties beyond those explicated in a statute.

Accordingly, the Commission has broad authority to promulgate regulations provided that such regulations are supported by a sufficient nexus to the CFTC's delegated authority. Specifically, Congress expressly empowered the Commission to prescribe certain requirements with respect to FCMs, namely, to require FCMs to register (sections 8a(1), 4d(a)(1), and 4f(a)(1) of the CEA

); to segregate customer funds (section 4d of the CEA

); to establish safeguards to minimize conflicts of interest (section 4d of the CEA

); to meet minimum financial requirements (section 4f of the CEA

); to manage and maintain records and reporting on the financial and operational risks of affiliates (section 4f of the CEA

); and to establish administrative, technical, and physical safeguards to protect the security and confidentiality of certain nonpublic personal information (section 5g of the CEA

), among other requirements.

See

7 U.S.C. 6s(j)(2).

See

7 U.S.C. 6s(j)(7).

7 U.S.C. 12a(5).

Inv. Co. Inst.

CFTC,

891 F. Supp. 2d 162, 193 (D.D.C. 2012),

as amended

(Jan. 2, 2013) (citing

Stilwell

Office of Thrift Supervision,

569 F.3d 514, 519 (D.C. Cir. 2009)).

Nat'l Ass'n of Mfrs. v. SEC, 748 F.3d 359, 366 (D.C. Cir. 2014), overruled on other grounds by Am. Meat Inst. v. U.S. Dept. of Agric., 760 F.3d 18 (D.C. Cir. 2014) (en banc).

7 U.S.C. 12a(1); 7 U.S.C. 6d(a)(1); 7 U.S.C. 6f(a)(1).

7 U.S.C. 6d.

Id.

7 U.S.C. 6f.

Id.

See

7 U.S.C. 7b-2; 15 U.S.C. 6801.

The Commission believes that more particularized operational risk management requirements are reasonably necessary to help effectuate these statutory requirements for FCMs and to accomplish the purposes of the CEA. FCMs play an important role in the derivatives markets, serving as both the primary point of access to the cleared commodity interest markets for customers and the custodian of the funds used to maintain their positions. Given their position at the center of the derivatives market ecosystem, FCMs' operational resilience is essential to well-functioning derivatives markets and to ensuring that customers receive the protections provided by the CEA. However, as discussed above, operational risks, notably cyber and third-party risks, have become an increasing threat to financial institutions, including FCMs. These risks can cause major disruptions to FCMs' operations, and consequently impact the ability of FCMs to fulfill their obligations as Commission registrants. In particular, information security threats and operational disruptions can place an FCM's financial resources at risk; disrupt an FCM's ability to segregate and protect customer funds; impede accurate recordkeeping, including records related to customer funds; and cause a host of other issues for FCMs, which ultimately inure to the detriment of their customers and the derivatives markets. Accordingly, the Commission believes a comprehensive operational resilience regime is reasonably necessary to ensure that an FCM adequately addresses and mitigates risks that could adversely impact its ability to operate and fulfill its statutory obligations and duties as an FCM.

As discussed in detail in subsequent sections of this release, the Commission is proposing to require that FCMs and swap entities establish an Operational Resilience Framework (ORF) that is reasonably designed to identify, monitor, manage, and assess risks relating to information and technology security, third-party relationships, and emergencies or other significant disruptions to normal business operations. At its core, the ORF would have three key components: an

information and technology security program, a third-party relationship program, and a business continuity and disaster recovery plan. The proposed ORF rule reflects a principles-based approach buttressed by certain minimum requirements specific to each of the component programs or plans, such as requiring an annual risk assessment and controls relating to information and technology security, and due diligence and monitoring requirements for third-party service providers. Proposed requirements relating to governance, training, testing, and recordkeeping would apply broadly and support the ORF as a whole. The proposed rule would further require covered entities to notify the Commission (and, in certain instances, customers or counterparties) of certain ORF-related events. Detailed guidance intended to assist covered entities in designing and implementing their third-party relationship program would be included in appendices to the rule.

In developing the proposed rule, the Commission endeavored to incorporate general directives to federal agencies articulated in the White House's March 2023 National Cybersecurity Strategy: Leverage existing standards and guidance, harmonize where sensible and appropriate to achieve better outcomes, and demonstrate an approach that is sufficiently nimble to meet the challenges of the ever-evolving technological threat landscape and fit the unique business and risk profile of each covered entity.

To that end, the proposal builds on the Commission's experience establishing system safeguard requirements for registered entities, as well as the approaches adopted by self-regulatory organizations and other regulatory authorities.

Notably, the proposal draws on approaches adopted by NFA, whose rules and interpretative notices relating to information systems security, third-party risk, and business continuity and disaster recovery planning apply to covered entities by virtue of being NFA members, and prudential regulators, who also regulate many covered entities, and have recently issued interagency positions on operational resilience and third-party relationship management.

The White House, National Cybersecurity Strategy at 8-9 (Mar. 2023) (National Cyber Strategy) (“Our strategic environment requires modern and nimble regulatory frameworks for cybersecurity tailored for each sector's risk profile, harmonized to reduce duplication, complementary to public-private collaboration, and cognizant of the cost of implementation.”).

See also

FIA Taskforce Report,

supra

note 27, at 9 (“[T]he Taskforce encourages regulators and legislators to take a principles-based approach to cyber risk and operational resilience. That approach may not be sufficient in all areas, but such a flexible approach is well suited to a threat landscape that is likely to continue evolving at a rapid rate.”).

See

17 CFR 37.1400 and 17 CFR 37.1401 (system safeguard requirements for swap execution facilities (SEFs)); 17 CFR 38.1050 and 17 CFR 38.1051 (designated contract markets (DCMs)); 17 CFR 39.18 (derivatives clearing organizations (DCOs)); 17 CFR 49.24 (swap data repositories (SDRs)).

See also

17 CFR 1.3 (defining “registered entity” to include DCMs, DCOs, SEFs, and SDRs). For a summary of international regulatory efforts related to operational resilience,

see

FIA Taskforce Report,

supra

note 27, at 7-8.

See

NFA Interpretive Notice 9070, NFA Compliance Rules 2-9, 2-36 and 2-49: Information Systems Security (rev. Sept. 30, 2019) (NFA ISSP Notice); NFA Interpretive Notice 9079, NFA Compliance Rules 2-9 and 2-36: Members' Use of Third-Party Service Providers (NFA Third-Party Notice) (effective Sept. 30, 2021); NFA Rule 2-38: Business Continuity and Disaster Recovery Plan (rev. July 1, 2019); NFA Interpretive Notice 9052, NFA Compliance Rule 2-38: Business Continuity and Disaster Recovery Plan (NFA BCDR Notice) (April 7, 2003); Prudential Operational Resilience Paper,

supra

note 11; Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (Jun. 9, 2023) (Prudential Third-Party Guidance).

See also

Computer-Security Incident Notification Requirements for Banking Organizations and their Bank Service Providers, 86 FR 66424 (Nov. 23, 2021); 12 CFR part 30, app. A (Interagency Guidelines Establishing Standards for Safety and Soundness), 12 CFR part 30, app. B (Interagency Guidelines Establishing Information Security Standards).

The Commission also surveyed the work of international standard-setting bodies, notably the BCBS

Principles for Operational Resilience.

The Commission also conferred with, and reviewed the standards published by the National Institute of Standards and Technology (NIST), a part of the U.S. Department of Commerce charged by Executive Order 13636 in 2013 with developing a framework to reduce cyber risks to critical infrastructure that incorporates voluntary consensus standards and industry best practices.

Standards developed in response to this charge and reviewed by the Commission include the

Framework for Improving Critical Infrastructure Cybersecurity

and the

Security and Privacy Controls for Information Systems and Organizations,

among others.

The Commission and other financial regulators have previously adapted NIST's standards in regulation and guidance related to operational resilience. The Commission's system safeguards requirements treat NIST's CSF as a source for well-established best practices for cybersecurity.

In Appendix A of the Interagency Sound Resilience Paper, the prudential regulators presented “a collection of sound practices for cyber risk management, aligned to NIST and augmented to emphasize governance and third-party risk management.”

The Commission also considered standards published by equivalent standard setting bodies like the International Standards Organization (ISO).

See

BCBS Operational Resilience Principles,

supra

note 11.

See also

International Organization of Securities Commissions (IOSCO),

Cyber Task Force: Final Report

(2019) (identifying different but comparable core standards or frameworks, including both NIST and ISO standards); Financial Stability Board (FSB),

Final report on Enhancing Third-Party Risk Management and Oversight—a toolkit for financial institutions and financial authorities

(Dec. 4, 2023) (FSB Third-Party Report). Materials related to the FSB's work on cyber resilience are available at

https://www.fsb.org/work-of-the-fsb/financial-innovation-and-structural-change/cyber-resilience/.

See

The White House, Office of the Press Secretary,

Executive Order—Improving Critical Infrastructure Cybersecurity,

E.O. 13636 (Feb. 12, 2013).

See

NIST, Framework for Improving Critical Infrastructure Cybersecurity (Version 1.1) at 2 (Apr. 16, 2018) (NIST CSF); NIST, SP 800-53, Security and Privacy Controls for Information Systems and Organizations (Sept. 2020, rev. Dec. 10, 2020) (NIST SP 800-53).

See also

Cybersecurity & Infrastructure Security Agency (CISA), Financial Services Sector-Specific Plan—2015 at 16 (rev. Dec. 17, 2020) (“While the [NIST cybersecurity framework] is designed to manage cybersecurity risks, its core functions of Identify, Protect, Detect, Respond, and Recover provide a model for considering physical risks as well. This methodology is increasingly central to the sector's thinking on security and resilience, and the concept aligns with existing [Federal Financial Institutions Examination Council (FFIEC)] guidance.”).

System Safeguards Testing Requirements for Derivatives Clearing Organizations, 81 FR 64322, 64329 (Sept. 19, 2016).

Board of Governors of the Federal Reserve System, the Office of the Comptroller of the Currency, and the Federal Deposit Insurance Corporation, Sound Practices to Strengthen Operational Resilience (Nov. 2, 2020),

available at https://www.federalreserve.gov/supervisionreg/srletters/SR2024.html.

See, e.g.,

ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection: Information security controls (Oct. 2022) (ISO/IEC 27001:2022).

Finally, in putting together the proposal, Commission staff engaged with staff at NFA and various federal agencies, including prudential regulators, and the SEC.

Based on these efforts, the Commission preliminarily believes that, if adopted, the proposed rule would strike an

appropriate balance between supporting technological and market innovation and fair competition, ensuring covered entities devote the necessary thought, planning, and resources to their operational resilience so as to support the resilience of the U.S. derivatives markets and the financial sector as a whole.

In accordance with section 712(a) of the Dodd-Frank Act (15 U.S.C. 8302), the Commission has consulted and coordinated, to the extent possible, with the SEC and the prudential regulators, including with the FRB, the OCC, and the FDIC, for purposes of assuring regulatory consistency and comparability. The Securities Exchange Act of 1934 and existing and proposed SEC regulations include requirements relating to risk management including cybersecurity, including requirements for SEC-regulated broker-dealers and security-based swap dealers.

See, e.g.

Cybersecurity Risk Management Rule for Broker-Dealers, Clearing Agencies, Major Security-Based Swap Participants, the Municipal Securities Rulemaking Board, National Securities Associations, National Securities Exchanges, Security-Based Swap Data Repositories, Security-Based Swap Dealers, and Transfer Agents, 88 FR 20212, sections IV.C.1.b.i and IV.C.1.b.iii (Apr. 5, 2023).

See

7 U.S.C. 5.

The Commission is proposing to codify the ORF rule for swap entities in existing Commission regulation 23.603, which currently contains the Commission's business continuity and disaster recovery requirements for swap entities.

As discussed in greater detail below, the Commission is proposing to retain the substance of the existing business continuity and disaster recovery requirements in current Commission regulation 23.603 as part of the ORF rule for swap entities, with certain modifications. Similar requirements would also be imposed on FCMs. The proposed ORF rule for FCMs would be codified in new Commission regulation 1.13. The proposed guidance on third-party relationships would be included in the appendices to parts 1 and 23 for FCMs and swap entities, respectively.

17 CFR 23.603.

As proposed, the regulatory text of the ORF rule for swap entities is nearly identical in structure and substance to the ORF rule for FCMs. Accordingly, to promote readability, when referencing sections of the regulatory text, this notice generally refers to the relevant paragraph of the proposed regulations (

i.e.,

“proposed paragraph (b)” would refer to paragraph (b) of both proposed Commission regulations 1.13 and proposed Commission regulation 23.603).

The Commission invites comment on all aspects of the proposed rule, as further detailed below.

A. Generally—Proposed Paragraph (b)

Paragraph (a) of proposed Commission regulations 1.13 and 23.603 provides definitions for terms used within the ORF rule. Each proposed definition is discussed in the context of the relevant substantive regulatory requirement throughout the remainder of this notice.

1. Purpose and Scope; Components—

Proposed Paragraphs (b)(1) and (b)(2)

As previously mentioned, the proposed rule would require covered entities to establish, document, implement, and maintain an Operational Resilience Framework, or ORF.

The ORF would need to be reasonably designed to identify, monitor, manage, and assess risks relating to three key risk areas that challenge operational resilience: (i) information and technology security, as defined in the proposed rule and discussed further below; (ii) third-party relationships; and (iii) emergencies or other significant disruptions to the continuity of normal business operations as a covered entity.

Although these risk areas are often viewed distinctly, as the introduction to this notice illustrates, they are significantly interrelated, as the relative strength of information and technology security and third-party risk management can directly affect recovery activities and improve outcomes following an emergency or other significant disruption.

Together, the Commission believes they represent important sources of potential operational risk, the effective management of which is key to operational resilience.

See

paragraph (b)(1) of proposed Commission regulations 1.13 and 23.603.

See

paragraphs (b)(1)(i)-(iii) of proposed Commission regulations 1.13 and 23.603.

See, e.g.,

ISO/IEC 27031:2011, Information technology—Security techniques—Guidelines for information and communication technology readiness for business continuity (Mar. 2011) (“Failures of [information and communication technology (ICT)] services, including the occurrence of security issues such as systems intrusion and malware infections, will impact the continuity of business operations. Thus, managing ICT and related continuity and other security aspects form a key part of business continuity requirements. Furthermore, in the majority of cases, the critical business functions that require business continuity are usually dependent upon ICT. This dependence means that disruptions to ICT can constitute strategic risks to the reputation of the organization and its ability to operate . . . As a result, effective [business continuity management] is frequently dependent upon effective ICT readiness to ensure that the organization's objectives can continue to be met in times of disruptions.”).

See

Prudential Operational Resilience Paper,

supra

note 11, at 8 (“Secure and resilient information systems underpin the operational resilience of a firm's critical operations and core business lines.”);

see also

Prudential Third-Party Guidance, 88 FR 37920 (discussing the interplay of third-party risks and operational resilience).

The proposed rule would require covered entities to establish three written component programs or plans, each dedicated to addressing one of the three enumerated risks within the ORF. The three component programs or plans would be: (i) an information and technology security program, (ii) a third-party relationship program, and (iii) a business continuity and disaster recovery plan.

Each component program or plan would need to be supported by written policies and procedures and meet the requirements set forth in the rule, as discussed in subsequent sections of this notice.

The definitions and specific requirements for the information and technology security program, the third-party relationship program, and the business continuity and disaster recovery plan are discussed in detail in subsequent sections of this notice specifically dedicated to discussing each of the three components.

See

paragraph (b)(2) of proposed Commission regulations 1.13 and 23.603;

see also

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “information and technology security program,” “third-party relationship program,” and “business continuity and disaster recovery plan”).

See

paragraph (b)(2) of proposed Commission regulations 1.13 and 23.603.

See

paragraphs (d) (information and technology security program), (e) (third-party relationship program), and (f) (business continuity and disaster recovery plan) of proposed Commission regulations 1.13 and 23.603 (describing the requirements for each program, respectively).

See

sections II.C (information and technology security program), II.D (third-party relationship program), II.E (business continuity and disaster recovery plan) of this notice,

infra.

Although they may go by different names, the Commission understands that written programs or plans of these types are generally recognized as common ways to address these risks and are even currently required of covered entities. NFA, for instance, currently requires members to adopt a written information systems security program (ISSP), a written supervisory framework to address outsourcing to third-party service providers, and a written business continuity and disaster recovery plan.

The Commission itself requires swap entities to have a written business continuity and disaster recovery plan.

Accordingly, to the extent that covered entities have existing programs or plans and policies and procedures that address the requirements of the ORF rule, by virtue of other regulatory requirements or otherwise, the Commission would not expect such covered entities to adopt entirely new component programs or plans. The Commission would only expect that covered entities review their existing programs and plans to ensure they meet the minimum requirements of the ORF rule and make any necessary amendments.

See

NFA ISSP Notice,

supra

note 43; NFA Third-Party Notice,

supra

note 43; and NFA BCDR Notice,

supra

note 43. NFA's requirement to establish a business continuity and disaster recovery plan does not currently apply to swap entities,

see

NFA Rule 2-38, paragraph (a),

supra

note 43.

See

17 CFR 23.603.

The Commission appreciates that covered entities may assign responsibility for the establishment, implementation, and maintenance of each ORF component program or plan to distinct functions within their organizations. By structuring the proposed rule to require a “framework” directed at operational resilience,

however, the Commission intends for executive leadership at covered entities to address the risk areas covered by the ORF as a cohesive and interrelated whole, breaking down any unnecessary internal silos, and to consider all aspects of operational resilience in determining their operational strategies, risk appetite, and risk tolerance limits.

The specific governance requirements of the proposed rule, which include the requirement to establish risk appetite and risk tolerance limits with respect to the ORF, further support this view.

See

paragraph (c) of proposed Commission regulations 1.13 and 23.603.

2. Standard—

Proposed Paragraph (b)(3)

The Commission is proposing to require that each covered entity implement the requirements of the proposed ORF rule in a manner that is appropriate and proportionate to the nature, scope, complexity, and risk profile of its business activities as a covered entity, following generally accepted standards and best practices (the (b)(3) standard).

The proposed (b)(3) standard reflects the general principles-based approach underpinning the proposed rule, which the Commission believes would be appropriate given the increased reliance on and rapid evolution of technology within the financial industry and its attendant risks.

This standard incorporates two themes that have broad support from other governmental and international standard-setting bodies when addressing matters related to operational resilience: (i) proportionality; and (ii) reliance on established standards and best practices.

See

paragraph (b)(3) of proposed Commission regulations 1.13 and 23.603.

See

BCBS Operational Resilience Principles,

supra

note 11, at 1 (“Recognising that a range of potential hazards cannot be prevented, the Committee believes that a pragmatic, flexible approach to operational resilience can enhance the ability of banks to withstand, adapt to and recover from potential hazards and thereby mitigate potentially severe adverse impacts.”);

see also

Prudential Operational Resilience Paper,

supra

note 11, at 9 (providing as a sound practice of operational resilience that firms review information systems “on a regular basis against common industry standards and best practices.”).

See, e.g.,

BCBS Operational Resilience Principles at 2-3 (“The principles for operational resilience set forth in this document are largely derived and adapted from existing guidance that has been issued by the Committee or national supervisors over a number of years. The Committee recognizes that many banks have well established risk management processes that are appropriate for their individual risk profile, operational structure, corporate governance and culture, and conform to the specific risk management requirements of their jurisdictions. By building upon existing guidance and current practices, the Committee is issuing a principles-based approach to operational resilience that will help to ensure proportional implementation across banks of various size, complexity and geographical location.”); FSB Third-Party Report,

supra

note 44, at 10-11; IOSCO,

Principles on Outsourcing: Final Report

at 10 (IOSCO Outsourcing Report) (Oct. 2021) (providing that “[t]he application and implementation of these Principles should be proportional to the size, complexity and risk posed by the outsourcing” of tasks, functions, processes, services, or activities to a service provider that would otherwise be undertaken by the regulated entity itself).

Broadly speaking, the principle of proportionality recognizes that operational resilience, and information and technology security, in particular, cannot be addressed with a one-size-fits-all approach.

On the contrary, differences in operational structures and business strategies among covered entities necessitate a more flexible and adaptive approach that would allow individual covered entities to best address their specific risks and evolve to address emerging challenges as they arise. Covered entities vary widely in terms of their business structure and risk profiles, such that a covered entity operating within a large bank holding company group structure and involved in a broad array of asset classes would likely have a different risk profile and different resources than an entity that is solely registered with the CFTC or that has a narrower scope to its CFTC-regulated business. The Commission would therefore expect that covered entities facing different operational risks may take different approaches to managing and monitoring those risks. Designing an operational resilience framework that would apply uniformly across all covered entities would not only pose significant challenges, it would likely be ineffective, imposing operational costs where no risks demand it. Accordingly, the Commission preliminarily believes that a proportional, risk-based approach would help ensure that firms, customers, counterparties, and the financial system at large can appropriately respond to and recover from operational shocks in context.

See e.g.,

FINRA, 2018 Report on Selected Cybersecurity Practices at 1 (Dec. 2018) (FINRA Cybersecurity Report) (“[T]here is no one-size-fits-all approach to cybersecurity.”); NIST CSF,

supra

note 46, at 2 (“The [NIST CSF] is not a one-size-fits-all approach to managing cybersecurity risk for critical infrastructure. Organizations will continue to have unique risks—different threats, different vulnerabilities, different risk tolerances.”).

Interpretive notices adopted by NFA reflect a comparable approach. Specifically, NFA's notices on ISSPs and the use of third-party service providers establish general, baseline requirements (

e.g.,

assess risks associated with the use of information technology systems or with reliance on third-party service providers) and then direct NFA members, including covered entities, to tailor the specifics to their businesses.

This approach is also consistent with the CFTC's own approach with respect to system safeguard requirements for registered entities,

as well as those of the prudential regulators.

Generally accepted standards and best practices themselves also generally support a proportional approach.

See

NFA ISSP Notice,

supra

note 43 (requiring each NFA member to adopt an ISSP appropriate to the its “size, complexity of operations, type of customers and counterparties, the sensitivity of the data accessible within its systems, and its electronic interconnectivity with other entities”); NFA Third-Party Notice,

supra

note 43 (“NFA recognizes that a Member must have flexibility to adopt a written supervisory framework relating to outsourcing functions to a [third-party service provider] that is tailored to a Member's specific needs and business . . .”).

See, e.g.,

17 CFR 37.1401(b) (SEFs); 17 CFR 38.1051(b) (DCMs); 17 CFR 39.18(b)(3) (DCOs); 17 CFR 49.24(c) (SDRs) (requiring registered entities to follow generally accepted standards and best practices with respect to the development, operation, reliability, security, and capacity of automated systems);

see also

System Safeguards Testing Requirements for Derivatives Clearing Organizations, 81 FR 64322, 64329 (Sept. 19, 2016) (DCO System Safeguards Testing Requirements) (describing the CFTC's approach to system safeguards for DCOs as providing DCOs with “flexibility to design systems and testing procedures based on the best practices that are most appropriate for that DCO's risks”).

12 CFR part 30, app. B (Interagency Guidelines Establishing Information Security Standards);

id.

at II.A. (Information Security Program) (“Each [financial institution] shall implement a comprehensive written information security program that includes administrative, technical, and physical safeguards appropriate to the size and complexity of the [financial institution] and the nature and scope of its activities.”); FFIEC Information Technology Examination Handbook, Information Security at 2 (Sept. 2016) (FFIEC Information Security Booklet) (“Institutions should maintain effective information security programs commensurate with their operational complexities.”).

The NIST CSF, for example, identifies activities designed to achieve specific cybersecurity outcomes and tiers practices by increasing degree of rigor and sophistication. In selecting a tier, NIST directs entities to consider their “current risk management practices, threat environment, legal and regulatory requirements, information sharing practices, business/mission objectives, supply chain cybersecurity requirements, and organizational constraints.”

See

NIST CSF,

supra

note 46, at 8.

The Commission emphasizes, however, that “proportional” does not mean “permissive.” The Commission's proposed standard for the ORF rule would not support a “race to the bottom,” where covered entities default to the minimum requirements of the proposed rule. On the contrary, covered entities would be required to implement an ORF that is reasonably designed to reflect and address their unique risk profile and activities, consistent with the proposed (b)(3) standard. Accordingly, the Commission would expect larger, more complex entities that operate more varied business lines, rely on more technological platforms, or

have more complicated agreements with third-party service providers to arrive at an ORF that is appropriate to their likely increased level of operational risk.

See

National Cyber Strategy,

supra

note 41, at 4 (“The most capable and best-positioned actors in cyberspace must be better stewards of the digital ecosystem.”);

see also

IOSCO Outsourcing Report,

supra

note 65, at 10.

The requirement for covered entities to follow generally accepted standards and best practices serves to ground covered entities' approaches to operational resilience in practices that are widely recognized as effective in aiding financial institutions to mitigate and recover from operational shocks. In adopting system safeguard requirements for registered entities, which require registered entities to follow generally accepted standards and best practices, the Commission identified several sources of standards and best practices.

NFA and other bodies have compiled similar lists.

Among perhaps the most commonly relied on by financial institutions are the NIST CSF, ISO, the Center for internet Security (CIS), and FFIEC, whose examination booklets and Cyber Assessment Tool (CAT) are specifically designed to guide financial institutions.

The Commission would expect covered entities to use generally accepted standards and industry best practices that are appropriate and proportionate to the nature, size, scope, complexities, and risk profile of their business activities, in designing or updating an ORF that would comply with the proposed rule. For instance, in conducting the risk assessment required under proposed paragraph (c)(1), a covered entity would need to identify risks to its information and technology security with reference to risks discussed in an appropriate standard or based on industry best practices, and then assess and prioritize those risks using frameworks and metrics recommended by those standards or practices. Requiring covered entities to follow generally accepted standards and industry best practices in developing and implementing the ORF would help ensure that covered entities establish, document, implement, and maintain ORFs reasonably designed to address their particular operational resilience-related risks.

See, e.g.,

DCO System Safeguards Testing Requirements, 81 FR 64322-23; 17 CFR 39.18(b)(3) (requiring DCOs to follow generally accepted standards and best practices with respect to the development, operation, reliability, security, and capacity of automated systems)

; see also

17 CFR 37.1401(b) (SEFs) (requiring the same); 17 CFR 38.1051(b) (DCMs) (same); 17 CFR 49.24(c) (SDRs) (same).

See, e.g.,

NFA, Cybersecurity FAQs, “Does NFA recommend any particular consultants that can help a Member draft an ISSP or perform penetration testing?”;

see also

FFIEC, Cybersecurity Resource Guide for Financial Institutions (Sept. 2022) (rev. Nov. 2022).

The Financial Services Sector Coordinating Council (FSSC) has also developed a NIST CSF profile specifically designed for financial institutions. The profile is now maintained, updated, and managed by the Cyber Risk Institute (CRI) and was last updated in January 2023.

See

CRI Profile v1.2 (Dec. 14, 2021),

available at https://cyberriskinstitute.org/the-profile/.

The proposed rule leverages these standards not only by directing covered entities to consider them in developing their approaches but by incorporating common themes contained within them into the substance of the proposed rule. In the Commission's view, reliance on such standards supports the use of a common lexicon, facilitating the development of understandable and transposable practices on a cross-border basis. The Commission further recognizes that generally accepted standards and best practices are likely to evolve over time, and the applicability of any particular standard may vary based on the unique circumstances and risk profile of each covered entity. Accordingly, the Commission preliminarily believes requiring covered entities to follow generally accepted standards and best practices supports the goal of an adaptive approach that can respond nimbly to rapid changes in emerging threats.

See

National Cyber Strategy,

supra

note 41, at 9 (“By leveraging existing international standards in a manner consistent with current policy and law, regulatory agencies can minimize the burden of unique requirements and reduce the need for regulatory harmonization.”).

3. Request for Comment

The Commission invites comment on all aspects of proposed paragraph (b), including the following questions:

Applicability to FCMs.

In adopting the RMP rule for FCMs in 2013, the Commission determined to limit the rule's applicability to FCMs that hold or accept customer funds.

The CEA and Commission regulations define a “futures commission merchant” as an entity that solicits or accepts orders to buy or sell futures contracts, options on futures, retail off-exchange forex contracts or swaps,

and

accepts money or other assets from customers to support such orders.

Although some entities are, for various reasons, currently registered as FCMs despite not accepting customer funds, as the Commission explained in the adopting release for the FCM RMP rule, FCMs that do not accept or hold customer funds to margin, guarantee, or security commodity interests are generally not operating as FCMs.

With respect to the proposed ORF rule, the Commission has preliminarily determined to apply the proposed requirements to all registered FCMs. Although the customer protection concerns may be mitigated for FCMs that do not handle customer assets, the Commission preliminarily believes that the potential systemic risk that can result from failures to manage information and technology risk, third-party relationships, emergencies, or other significant disruptions persist for all FCMs, given their access to customer information and their potential relationships with and/or connectivity to other regulated entities, including exchanges and clearinghouses.

See

17 CFR 1.11(a) (Nothing in this section shall apply to a futures commission merchant that does not accept any money, securities, or property (or extend credit in lieu thereof) to margin, guarantee, or secure any trades or contracts that result from soliciting or accepting orders for the purchase or sale of any commodity interest.).

See

7 U.S.C. 1a(28)(A); 17 CFR 1.3 (defining “futures commission merchant”) (emphasis added).

As of July 31, 2023, twelve (12) entities were registered as FCMs but were not required to segregate any funds on behalf of customers.

See

CFTC, Financial Data for FCMs (July 31, 2023),

available at https://www.cftc.gov/MarketReports/financialfcmdata/index.htm.

The Commission made clear in the adopting notice for the FCM RMP rule that it would expect that, prior to changing their business model to begin accepting customer funds, any registered FCM that does not currently accept customer funds would need to establish a risk management program that complies with Commission regulation 1.11 and file such program with the Commission and with the FCM's designated self-regulatory organization (DSRO).

See

Final FCM RMP Rule, 78 FR 68517.

The Final FCM RMP rule, by contrast, could be viewed as more directly targeting the management of specific risks associated with operating as an FCM.

a. Are the risks associated with information and technology security, third-party relationships, and emergencies or other significant disruptions substantially different or reduced for FCMs that do not hold customer funds? If yes, please explain.

b. Should the Commission consider limiting the ORF rule to FCMs that do not hold customer funds, consistent with the FCM RMP rule? Why or why not? Please explain.

Standard

. The proposed rule would require covered entities to follow “generally accepted standards and best practices” in establishing, implementing, and maintaining their ORFs. Although this notice identifies various sources of such standards and practices, including NIST, ISO, CIS, and FFIEC, the proposed rule does not further define or otherwise limit the scope of “generally accepted standards and best practices,” acknowledging that there are several sources of recognized standards currently relied on by covered entities and that standards and practices

are likely to evolve over time in response to changes in technology or emerging threats. Nevertheless, the Commission understands that, particularly in the United States, NIST and ISO standards are heavily relied on by covered entities and referenced by other regulators, making them widely recognized as the leading industry standards for cybersecurity and operational risk management.

a. Should the Commission further define or otherwise limit what constitutes “generally accepted standards and best practices”? Specifically, should the Commission require covered entities to follow NIST or ISO standards, as some commenters on the RMP ANPRM recommended?

Why or why not? Please explain.

See, e.g.,

R.J. O'Brien Letter,

supra

note 13, at 6 (“The Commission should also seek to implement the [NIST CSF] as a part of its standard for managing and mitigating this area of risk. The NIST CSF is widely accepted throughout many different industries and would set a universal standard and best practices for registrants to follow.”).

b. Are there any other standards or practices commonly relied on by covered entities that the Commission did not identify, directly or indirectly, in this notice? If so, please identify them and specify how they are currently relied on by covered entities.

B. Governance—Proposed Paragraph (c)

The topic of governance has gained increased attention within the context of operational resilience, particularly with respect to the area of information and technology security. As of the date of this notice, NIST is undergoing a process to update the NIST CSF, and new governance outcomes are expected to feature prominently.

Prudential regulators have also emphasized the role of effective governance to operational resilience.

In the Commission's view, the overall objective of an effective governance regime for an ORF should be the integration of operational resilience topics into existing reporting lines and operational structures, including the entity's overall operational strategy, to ensure active executive engagement and oversight in the management of operational risk that could challenge a covered entity's operational resilience.

See

NIST,

NIST Cybersecurity Framework 2.0 Concept Paper: Potential Significant Updates to the Cybersecurity Framework

at 10-11 (Jan. 19, 2023) (discussing how the update “will emphasize the importance of cybersecurity governance” by adding a new govern function);

see also

CRI,

The Profile Workbook: Guidance for Implementing the CRI Profile v1.2.1 and Responding to its Diagnostic Statements

at 16 (rev. Jan. 2023) (CRI Profile Workbook) (providing guidance on governance outcomes that have already been incorporated into the NIST CSF financial services sector profile).

See

Prudential Operational Resilience Paper,

supra

note 11, at 3.

See

BCBS Operational Resilience Principles,

supra

note 11, at 4 (“Principle 1: Banks should utilise their existing governance structure to establish, oversee and implement an effective operational resilience approach that enables them to respond and adapt to, as well as recover and learn from, disruptive events in order to minimise their impact on delivering critical operations through disruption.”) (internal citation omitted).

1. Approval of Components—

Proposed Paragraph (c)(1)

Accordingly, to ensure that a covered entity's senior leadership is involved in key decision-making around operational resilience, and is ultimately held accountable for implementation of the ORF, the proposed rule would require covered entities to have their senior leadership annually approve the ORF.

In recognition of the wide variety of corporate structures represented among covered entities, however, the proposed rule would give covered entities broad flexibility and discretion to identify the appropriate senior-level individual or body to provide such approval.

See

paragraph (c)(1) of proposed Commission regulations 1.13 and 23.603.

Specifically, paragraph (c)(1) of the proposed rule would require that each ORF component program or plan required by paragraph (b)(2) of the proposed rule is approved in writing, on at least an annual basis, by either the senior officer, an oversight body, or a senior-level official of the covered entity.

The term “oversight body” itself would be broadly defined to encompass any board, body, or committee of a board or body of the covered entity specifically granted the authority and responsibility for making strategic decisions, setting objectives and overall direction, implementing policies and procedures, or overseeing the management of operations for the covered entity.

Consistent with Commission regulation 3.1(j), “senior officer” would mean the chief executive officer or other equivalent officer of the covered entity.

As an example, under the proposed rule, a covered entity could elect to have its information and technology security program annually approved by its chief executive officer, its chief information security officer, or a committee with oversight authority over information and technology security.

Again, the intention behind offering this flexibility is to ensure that covered entities would be able to rely on and incorporate operational resilience into their existing governance structures when complying with the proposed ORF rule, while ensuring that each component program or plan would be approved by an individual or group of individuals with senior-level responsibilities and authority.

Id.

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “oversight body”).

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “senior officer”).

See also

17 CFR 3.1(j) (defining “senior officer”).

Other possible senior-level officials could be the covered entity's chief risk officer or chief operating officer, as appropriate.

2. Risk Appetite and Risk Tolerance Limits—

Proposed Paragraph (c)(2)

The proposed rule would further require covered entities to establish and implement appropriate risk appetite and risk tolerance limits with respect to the three risk areas enumerated in paragraph (b)(1) (information and technology security, third-party relationships, and emergencies or other significant disruptions to the continuity of normal business operations).

Although the terms “risk appetite” and “risk tolerance” are sometimes used interchangeably, the Commission intends the terms to have distinct meanings within the context of the proposed rule. Specifically, in the context of the proposed rule, “risk appetite” would mean the aggregate amount of risk a covered entity is willing to assume to achieve its strategic objectives.

Risk appetite is typically documented through a risk appetite statement, which establishes qualitative and quantitative measures designed to help identify when risk appetite has been exceeded and what appropriate mitigating strategies that can be taken.

With its proposed definition of “risk tolerance limit,” the Commission intends to capture a more focused measure of acceptable risk. Specifically, “risk tolerance limit” would mean the amount of risk, beyond its risk appetite, that a covered entity is prepared to tolerate through mitigating actions.

Thus, risk tolerance limits assume a particular type of risk has materialized (

e.g.,

an operational disruption has occurred) and identify the amount of disruption a firm is prepared to tolerate beyond its risk appetite.

Risk tolerance limits are also more likely to be measured in quantitative terms (

e.g.,

number of hours a particular system or application is down).

See

paragraph (c)(2)(i) of proposed Commission regulations 1.13 and 23.603.

See also

paragraph (b)(1) of proposed Commission regulations 1.11 and 23.603 (identifying the risk areas proposed to be covered by the ORF).

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “risk appetite”).

See also

12 CFR part 30, app. D, I.E.10 (Definitions) (defining “risk appetite” as the aggregate level and types of risk the board of directors and management are willing to assume to achieve a covered bank's strategic objectives and business program, consistent with applicable capital, liquidity, and other regulatory requirements); Prudential Operational Resilience Paper,

supra

note 11, at 14 (defining “risk appetite” as “[t]he aggregate level and types of risk the board and senior management are willing to assume to achieve a firm's strategic business objectives, consistent with applicable capital, liquidity, and other requirements and constraints”); BCBS Operational Resilience Principles,

supra

note 11, at 3, n.7 (defining “risk appetite” as “the aggregate level and types of risk a bank is willing to assume, decided in advance and within its risk capacity, to achieve its strategic objectives and business program”).

See

12 CFR part 30, app. D (requiring covered financial institutions to have a comprehensive written risk appetite statement).

See also

CRI Profile

Workbook,

supra

note 78, at 16 (“Risk appetite statements define certain risk tolerance metrics that help describe systems and services that the organization may consider high-risk.”).

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “risk tolerance limit”).

See also

Prudential Operational Resilience Paper, at 3, n. 11; 14 (defining “tolerance for disruption” as “determined by a firm's risk appetite for weathering disruption from operational risks considering its risk profile and the capabilities of its supporting operational environment” and “informed by existing regulations and guidance and by the analysis of a range of severe but plausible scenarios that would affect its critical operations and core business lines.”); CRI Profile Workbook at 291 (stating that “risk tolerance” “reflects the acceptable variation in outcomes related to specific performance measures linked to objectives the entity seeks to achieve”). ISACA,

Risk IT Framework,

2nd Ed. (July 27, 2020) (defining “risk tolerance” as “the acceptable deviation from the level set by the risk appetite and business objectives”).

The Commission recognizes that Commission regulations 1.11 and 23.600 incorporate the term “risk tolerance limits.”

See

17 CFR 1.11(e)(1), 17 CFR 23.600(c)(1). As proposed to be defined in the ORF rule, however, “risk tolerance limits” would be limited to the context of the risks identified in paragraph (b)(1) of the proposed rule and associated disruptions. Accordingly, if adopted, the defined use of the term “risk tolerance limit” in the proposed rule would not be intended to affect how covered entities use or interpret the term in the context of the Commission's RMP rules.

The Commission believes its proposed definitions are in line with proposed definitions of “risk appetite” and “risk tolerance” used by NIST. For example, in NIST Interagency or Internal Report 8286 (NIST IR 8286), NIST explains that a statement of risk appetite might be that “[e]mail shall be available during the large majority of a 24-hour period,” while the associated risk tolerance would be narrower, stating something like “[e]mail services shall not be interrupted more than five minutes during core hours.”

See

NIST IR 8286 at 5-6 (Oct. 2020). Accordingly, any existing risk appetite and risk tolerance limits established by covered entities pursuant to NIST or prudential regulator standards would be considered consistent with the proposed rule.

As with each component ORF program or plan, the proposed rule would require that a covered entity's risk appetite and risk tolerance limits be reviewed and approved in writing on at least an annual basis by either the senior officer, an oversight body, or a senior-level official of the covered entity.

This proposed requirement is intended to ensure that the risk appetite and risk tolerance limits are consistent with the covered entity's operational strategy and objectives, as established by senior leadership, and that senior leadership is involved in, and ultimately held accountable for, how operational risks faced by the covered entity are internalized by the covered entity.

See

paragraph (c)(2)(ii) of proposed Commission regulations 1.13 and 23.603.

The setting and approval of risk appetite and risk tolerance limits for operational risk is a well-recognized key component of effective governance and oversight.

The Commission therefore preliminarily believes the setting and approval of risk appetite and risk tolerance limits for operational risks captured by the ORF would be helpful to ensuring effective governance and oversight of the ORF. Specifically, the Commission believes that the process of identifying appropriate risk appetite and risk tolerance limits would have a disciplining effect, encouraging covered entities to think critically about the risks they face and their ability to comfortably manage them without incurring intolerable harm to themselves or their customers or counterparties. The Commission further believes that operating within set risk appetite and risk tolerance limits would help support a culture where senior leaders at covered entities can make more informed decisions about the risks they are willing to take and the mitigation measures they would need to employ to manage these risks, which would further support operational resilience.

See, e.g.,

BCBS Operational Resilience Principles,

supra

note 11, at 4 (“The board of directors should review and approve the bank's operational resilience approach considering the bank's risk appetite and tolerance for disruption to its critical operations. In formulating the bank's tolerance for disruption, the board of directors should consider the bank's operational capabilities given a broad range of severe but plausible scenarios that would affect its critical operations. The board of directors should ensure that the bank's policies effectively address instances where the bank's capabilities are insufficient to meet its stated tolerance for disruption.”); CRI Profile v1.2,

supra

note 74.

3. Internal Escalations—

Proposed Paragraph (c)(3)

To further ensure that senior leadership remains involved in and accountable for the ORF as it is implemented, the proposed rule would require either the senior officer, an oversight body, or a senior-level official of the covered entity to be notified of: (i) circumstances that exceed the risk tolerance limits established pursuant to paragraph (c)(2)(i) of the proposed rule; and (ii) incidents that require notification to the Commission, customers, or counterparties under the proposed rule, as further discussed in subsequent sections of this notice.

See

paragraph (c)(3) of proposed Commission regulations 1.13 and 23.603.

See also

paragraphs (i) and (j) of proposed Commission regulations 1.13 and 23.603, discussed in section II.G of this notice,

infra.

The Commission believes that circumstances that would push a covered entity outside of its risk tolerance limits or trigger a Commission notification requirement would be extraordinary, non-business-as-usual events, and would likely require the involvement of senior leadership to direct responsive actions to preserve or mitigate damage to operational resilience and prevent situations of intolerable harm. Ensuring that appropriate senior leadership, as determined by the covered entity, is apprised of instances where expected risk tolerance limits have been exceeded would further help senior leadership determine whether the risk appetite and risk tolerance limits are appropriately calibrated and whether identified mitigation strategies are working, creating opportunities to update either as necessary.

4. Consolidated Program or

Plan—Proposed Paragraph (c)(4)

The Commission is aware that many covered entities function as a division or affiliate of a larger entity or holding company structure; and that, in such instances, operational risks stemming from information and technology security, third-party relationships, and emergencies or other significant disruptions are generally monitored and managed at the enterprise level to address the risks holistically and to achieve economies of scale.

The proposed rule recognizes the benefits of such a consolidated approach and is not intended to interfere with covered entities' operational structures. Accordingly, the proposed rule would allow covered entities to satisfy the component program or plan requirement in paragraph (b)(2) through its participation in a consolidated program or plan, provided the consolidated program or plan meets the

requirements of the proposed rule.

As defined in the proposed rule, a “consolidated program or plan” would mean any information and technology security program, third-party relationship program, or business continuity and disaster recovery plan in which a covered entity participates with one or more affiliates and is managed and approved at the enterprise level.

100

In responding to the RMP ANPRM, several commenters noted how cybersecurity risk is generally managed at the enterprise level and should not be managed at the level of the entity regulated by the Commission.

See

FIA Letter at 11 (Sept. 18, 2023); International Swaps and Derivatives Association, Inc. (“ISDA”) and the Securities Industry and Financial Markets Association (“SIFMA”) Letter at 9 (Sept. 18, 2023).

See

paragraph (c)(4)(i) of proposed Commission regulations 1.13 and 23.603.

100

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “consolidated program”). Again, the specific definitions and minimum requirements of each program are discussed in sections II.C, II.D, and II.E of this notice,

infra.

Nevertheless, the Commission does have a strong regulatory interest in ensuring that operational shocks, such as cyber incidents or technological failures, having an impact on the discrete interests and operations of the covered entity are appropriately considered through the unique lens of the covered entity, which is regulated by the Commission. Accordingly, for a covered entity to satisfy the component program or plan requirement through its participation in a consolidated program or plan, the consolidated program or plan would need to meet the requirements of the proposed rule, as discussed in this notice. Those requirements include the establishment of appropriate risk appetite and risk tolerance limits that address the covered entity, as well as testing and other requirements, as discussed further below.

With respect to the requirements in proposed paragraphs (c)(1) and (c)(2)(i) that senior leadership of the covered entity approve, respectively, the component program or plan and the risk appetite and risk tolerance limits at least annually, the Commission recognizes that such a requirement might be challenging in the context of a consolidated program or plan, which is likely to address matters related to affiliates that are not within the scope of knowledge or responsibility of the covered entity. Accordingly, the proposed rule would allow covered entities relying on a consolidated program or plan to satisfy the approval requirements in paragraphs (c)(1) and (c)(2)(i) of the proposed rule, provided that either the senior officer, an oversight body, or a senior-level official of the covered entity attests in writing, on at least an annual basis, that the consolidated program or plan meets the requirements of this section and reflects the risk appetite and risk tolerance limits appropriate to the covered entity.

101

Notably, the senior officer, an oversight body, or a senior-level official at the covered entity would still need to be notified when the risk appetite and risk tolerance limits related to the covered entity are exceeded.

102

The Commission believes that such an attestation requirement would promote efficiency by allowing covered entities to continue to rely on an enterprise-level ORF and governance structures that have acknowledged benefits while also ensuring that such enterprise-level ORF appropriately addresses the risks specific to the covered entity, and would ensure that the requirements of the Commission's proposed rule are addressed for those covered entities in the same way as they would for a covered entity that is not a part of a larger enterprise.

103

101

See

paragraph (c)(4)(ii) of proposed Commission regulations 1.13 and 23.603.

102

See

paragraph (c)(3)(i) of proposed Commission regulations 1.13 and 23.603.

103

The Commission also believes this approach would be consistent with NFA's current interpretive notice on ISSPs.

See

NFA ISSP Notice,

supra

note 43 (“[T]o the extent a Member firm is part of a holding company that has adopted and implemented privacy and security safeguards organization-wide, then the Member firm can meet its supervisory responsibilities imposed by Compliance Rules 2-9, 2-36 and 2-49 to address the risks associated with information systems through its participation in a consolidated entity ISSP.”).

5. Request for Comment

The Commission invites comment on all aspects of the proposed governance requirements for the ORF, including the following questions:

Governance structures

. The proposed rule is intended to provide covered entities sufficient flexibility to integrate the proposed operational resilience requirements into existing reporting lines and operational structures, as well as to select the individual or body with senior-level responsibilities and authority to approve the component programs or plans of the ORF. Does the proposed rule accomplish this goal? If not, what other governance structure(s) should the Commission consider? Alternatively, should the Commission consider a more prescriptive, bright-line approach where only the senior officer or board of directors of the covered entity may provide any approvals required under the proposed rule? Please explain.

Internal escalations

. The proposed rule would require that the senior officer, an oversight body, or other senior-level official(s) of the covered entity be notified of circumstances that exceed risk tolerance limits or that require reporting to the Commission or counterparties or customers under the proposed rule. Should the Commission require internal escalation to any other specific personnel or under any other circumstances? Please identify and explain why.

Consolidated program or plan

. The proposed rule would allow covered entities relying on a consolidated program or plan to satisfy certain governance requirements by requiring the senior officer, an oversight body, or another senior-level official of the covered entity to attest in writing, on at least an annual basis, that the consolidated program or plan meets the requirements of the rule and reflects a risk appetite and risk tolerance limits appropriate to the covered entity. Is this standard workable for covered entities that function as a division or affiliate of a larger entity or holding company? Why or why not? Do such covered entities typically set their own risk appetite and risk tolerance limits, or are setting such limits conducted at the enterprise level? If they are set at the enterprise level, how is senior leadership of the covered entity typically involved in setting risk appetite and risk tolerance limits?

C. Information and Technology Security Program—Proposed Paragraph (d)

As mentioned above, the proposed rule would require each covered entity's ORF to include an information and technology security program, defined as a written program reasonably designed to identify, monitor, manage, and assess risks relating to information and technology security and that meets the minimum requirements for the program, as set forth in the proposed rule and discussed below.

104

The proposed rule would define “information and technology security” as the preservation of (a) the confidentiality, integrity, and availability of covered information and (b) the reliability, security, capacity, and resilience of covered technology.

105

“Covered information” would be defined to mean any sensitive or confidential data or information maintained by a covered entity in connection with its business activities as a covered entity.

106

“Covered technology” would be defined to mean any application, device, information technology asset, network service,

system, and other information-handling component, including the operating environment, that is used by a covered entity to conduct its business activities, or to meet its regulatory obligations, as a covered entity.

107

104

See

paragraph (d) of proposed Commission regulations 1.13 and 23.603.

See also

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “information and technology security program”).

105

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “information and technology security”).

106

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “covered information”).

107

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “covered technology”).

The proposed definition of “covered information” is intended to focus the requirements of the ORF on protecting data and information that are sensitive or otherwise intended to be kept confidential, whether by law or for business purposes. Notably, such data and information would include position, order, and account information, all of which covered entities have an obligation to keep confidential and which if made public could result in harm to customers, counterparties, or the markets more broadly. Often referred to as the “CIA triad,” confidentiality, integrity, and availability represent the three pillars of information security: preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information; guarding against the improper modification or destruction of data and information, ensuring its authenticity; and ensuring the timely and reliable access to and use of information.

108

The Commission therefore believes that compromising any aspect of the CIA triad with respect to covered information would have meaningful consequences for customers, counterparties, the covered entity, or even the market.

108

See

NIST, SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events (Dec. 2020) (discussing the CIA triad).

The proposed definition of “information and technology security” is likewise intended to ensure that the ORF is designed to address risks to two key facets of a covered entities' business for which they are registered with the Commission: the technology they use to conduct their regulated business activities and the sensitive information stored or transmitted therein. The proposed definition of “covered technology” is sufficiently broad to capture all types of technology (and related components) but is tailored to focus on the technology that is used by covered entities in the context of their regulated business activities, such that its disruption would have an impact on regulated business activities. The Commission preliminarily believes that reliability, security, capacity, and resilience are all key attributes of covered technology that must be preserved for it to function as intended without posing a disruption to operations. Accordingly, the Commission believes that having a program designed to preserve the confidentiality, integrity, and availability of covered information and the reliability, security, capacity, and resilience of covered technology is key to ensuring operational resilience.

Under the proposed rule, each covered entity's information and technology security program would need to meet the (b)(3) standard,

i.e.,

be appropriate and proportionate to the nature, size, scope, complexities and risk profiles of the covered entity's business activities, following generally accepted standards and best practices.

109

The proposed rule would nevertheless establish certain minimum requirements for the information and technology security program, including a periodic risk assessment, effective controls, and an incident response plan. Each proposed minimum requirement is discussed in turn below.

109

See

paragraph (b)(3) of proposed Commission regulations 1.13 and 23.603.

1. Risk Assessment—

Proposed Paragraph (d)(1)

As part of the information and technology security program, covered entities would be required to conduct and document the results of a periodic and comprehensive risk assessment reasonably designed to identify, assess, and prioritize risks to information and technology security.

110

Risk assessments are widely recognized as a necessary and effective first step to monitoring and managing risks to information and technology security.

111

According to NIST, the purpose of a risk assessment is to inform decision makers and support risk responses by identifying: (i) relevant threats to organizations or threats directed through organizations against other organizations; (ii) vulnerabilities both internal and external to organizations; (iii) impact (

i.e.,

harm) to organizations that may occur given the potential for threats exploiting vulnerabilities; and (iv) the likelihood that harm will occur.

112

Given this broad and important purpose, the Commission believes conducting a comprehensive risk assessment would be reasonably necessary for covered entities to have a thorough understanding of their information and technology security risks, including the types of threats the covered entities face, internal and external vulnerabilities, the impact of such risks, and their relative priorities, to guide mitigation efforts.

110

See

paragraph (d)(1)(i) proposed Commission regulations 1.13 and 23.603.

111

See, e.g.,

ISO/IEC 27001:2022,

supra

note 48 (requiring a risk assessment to help organizations identify, analyze, and evaluate weaknesses in their information systems); ISO/IEC 31010:2019,

Risk management: Risk assessment techniques

(July 2, 2019); NIST, SP 800-39,

Managing Information Security Risk: Organization, Mission, and Information System View

at 37 (Mar. 2011) (NIST SP 800-39) (“Risk assessment identifies, prioritizes, and estimates risk to organizational operations (

i.e.,

mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems. Risk assessments use the results of threat and vulnerability assessments to identify and evaluate risk in terms of likelihood of occurrence and potential adverse impact (

i.e.,

magnitude of harm) to organizations, assets, and individuals.”); NIST, SP 800-30,

Guide for Conducting Risk Assessments,

Rev. 1, at ix (Sept. 2012) (NIST SP 800-30) (“Risk assessments are a key part of effective risk management and facilitate decision making . . .”).

See also

12 CFR part 30, app. B (establishing a requirement to assess risk by identifying reasonably foreseeable threats, assessing the likelihood and potential damage of the threats, and assessing the sufficiency of arrangements to control risks); Prudential Operational Resilience Paper,

supra

note 11, at 4 (“The firm's operational risk management function implements and maintains risk identification and assessment approaches that adequately capture business processes and their associated operational risks, including technology and third-party risks.”).

112

See

NIST SP 800-30 at 1.

As stated, the risk assessment would need to identify, assess, and prioritize risks to information and technology security.

113

In broad terms, the Commission anticipates that conducting the assessment could first involve taking an inventory of covered technology and then identifying and assessing the likelihood and potential impact of reasonably foreseeable threats and vulnerabilities to information and technology security (

i.e.,

to the confidentiality, integrity, and availability of covered information, or to the reliability, security, capacity or resilience of covered technology) in light of the existing operational environment. Identified threats and vulnerabilities could derive from a wide array of sources, including both external cyber threats and internal gaps in existing systems or controls.

113

See

paragraph (d)(1)(i) proposed Commission regulations 1.13 and 23.603.

The Commission would then expect the risks to be prioritized in light of the covered entity's stated risk appetite and risk tolerance limits to help direct resources and other activities in order to best support information and technology security. If the proposal is adopted as final, the Commission would expect covered entities to use the results of each risk assessment as a basis for designing, implementing, and refining other elements of its information and technology security program, including

but not limited to, the development of controls, testing protocols, and the incident response plan, as discussed further below.

114

In this way, a well-conducted risk assessment should support the development of a more rational, effective, and valuable information and technology security framework, especially as the assessment is repeated and built upon over time.

114

See

NIST SP 800-39 at 34 (“Information generated during the risk assessment may influence the original assumptions, change the constraints regarding appropriate risk responses, identify additional tradeoffs, or shift priorities.”).

The proposed rule would not prescribe a specific process or methodology for the risk assessment, but the risk assessment would need to be consistent with the proposed (b)(3) standard.

115

Following generally accepted standards and best practices, covered entities would need to implement processes and methodologies that ensure the risk assessment reflects the nature, size, scope, complexities, and risk profile of its business activities as a covered entity. Any such processes or methodologies should also be sufficient to identify, assess, and prioritize risks to information and technology security and to evaluate their potential impact on covered technology and covered information.

116

115

See

paragraph (b)(3) of proposed Commission regulations 1.13 and 23.603, discussed

supra.

The Commission is aware of several sources for industry standards and best practices regarding information security risk assessments.

See, e.g.,

NIST SP 800-39;

see also

FFIEC Information Security Booklet,

supra

note 69.

116

See

paragraph (d)(1)(i) of proposed Commission regulations 1.13 and 23.603.

To ensure that the risk assessment is conducted objectively, the proposal would require that the personnel involved in conducting the assessment are not responsible for the development or implementation of the covered technology or related controls.

117

Such personnel could be employees of the covered entity, an affiliated entity, or a third-party service provider. To ensure that senior leadership is aware of risks to information security, and can appropriately prioritize them within the covered entity's broader strategy and risk management framework, the proposed rule would expressly require that the results of the risk assessment be provided to the senior officer, oversight body, or other senior-level official who approves the information and technology security program upon the risk assessment's completion.

118

The Commission believes the results of the risk assessment would be key information for senior leadership in determining whether to approve an information and technology security program.

117

See

paragraph (d)(1)(ii) of proposed Commission regulations 1.13 and 23.603.

118

See

paragraph (d)(1)(iii) of proposed Commission regulations 1.13 and 23.603.

See also

NIST SP 800-30,

supra

note 111, at 1 (“The purpose of risk assessments is to inform decision makers and support risk responses . . .”).

The proposed rule would require that the covered entity conduct the risk assessment at a frequency consistent with the (b)(3) standard (

i.e.,

a frequency appropriate and proportionate to the nature, scope, and complexities of its business activities as a covered entity, following generally accepted standards and best practices) but, in any case, no less frequently than annually.

119

Given the rapidly evolving nature of technological developments and related threats, the Commission preliminarily believes that a uniform requirement to conduct a risk assessment on at least an annual basis would support the development of a strong, foundational level of information and technology security across the industry, thereby mitigating the overall threat of systemic risk. However, the Commission understands that generally accepted standards and best practices may encourage more frequent risk assessments for covered entities that engage in broader or more complex business activities and would expect covered entities to conduct risk assessments more frequently if the circumstances so require.

119

See

paragraph (d)(1)(ii) of proposed Commission regulations 1.13 and 23.603.

As mentioned above, the proposed rule would allow covered entities to satisfy the requirement to have an information and technology security program through its participation in a consolidated information and technology security program.

120

Accordingly, such covered entities would be allowed to rely on a risk assessment that is conducted at an enterprise level. In such cases, the Commission would expect that the covered entities review the program and supporting policies and procedures for conducting the risk assessment to ensure it captures and assesses the risks to the covered entity consistent with the proposed rule so as to support the related attestation requirement.

121

120

See

paragraph (c)(4)(i) of proposed Commission regulations 1.13 and 23.603.

121

See

paragraph (c)(4)(ii) of proposed Commission regulations 1.13 and 23.603.

2. Effective Controls—

Proposed Paragraph (d)(2)

The proposed rule would require that the information and technology security program establish, document, implement, and maintain controls reasonably designed to prevent, detect, and mitigate identified risks to information and technology security.

122

An essential component of any information and technology security program, and a critical component of a covered entity's overall ORF, controls (also referred to as “countermeasures” or “safeguards”) include any measures (actions, devices, procedures, techniques) designed to promote information and technology security.

123

The selection, design, and implementation of controls can therefore have significant implications for a covered entity's information and technology security and overall operational resilience.

124

Accordingly, the Commission believes effective controls would be a critical component of a covered entity's overall ORF.

122

See

paragraph (d)(2) of proposed Commission regulations 1.13 and 23.603.

123

See

Committee on Payments and Market Infrastructures (CPMI), IOSCO,

Guidance on cyber resilience for financial market infrastructures

at 7 (Jun. 2016) (CPMI IOSCO Cyber Resilience Guidance) (noting that a strong information and communications technologies control environment is a fundamental and critical component of overall cyber resilience).

See also

NIST SP 800-53,

supra

note 46, at 8 (“Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and reflecting the protection needs of organizational stakeholders. Controls are selected and implemented by the organization in order to satisfy the system requirements. Controls can include administrative, technical, and physical aspects.”); ISO/IEC 27001:2022,

supra

note 48, Annex A (

Information security management systems

) (providing guidelines for 93 objectives and controls).

124

See

Prudential Operational Resilience Paper,

supra

note 11, at 8 (identifying as a sound practice for operational resilience routinely applying and evaluating the effectiveness of processes and controls to protect confidentiality, integrity, availability, and overall security of data and information systems).

Although the proposed rule would not mandate that covered entities implement specific controls, it would require covered entities to consider, at a minimum, certain categories of controls, discussed below, and adopt those consistent with the (b)(3) standard.

125

If the proposal is adopted as final, the Commission would further expect that a particular covered entity's determination of which controls to implement would be guided by the results of its risk assessment, considering the covered entity's risk appetite and risk tolerance limits.

126

Adopted controls would also need to address risks to information and technology security identified through other means, including outcomes of continuous monitoring of threats and vulnerabilities, actual and attempted cyber-attacks, threat intelligence, scenario analysis, and the likelihood and realistic impact of such attacks. In other words, the controls would need to be linked to and address the identified and prioritized risks to information and technology security. The Commission would advise covered entities to document their consideration of controls within each of the enumerated categories and their reasoning for adopting specific controls within any given category, or for declining to adopt any controls within a particular category. Further, the Commission would expect those controls to be reviewed and revised as needed to reflect the results of the covered entity's most recent risk assessment.

125

See

paragraphs (d)(2)(i)-(xii) of proposed Commission regulations 1.13 and 23.603 (identifying categories of controls for covered entities to consider).

See also

paragraph (b)(3) of proposed Commission regulations 1.13 and 23.603.

126

See

paragraph (c)(2) of proposed Commission regulations 1.13 and 23.603 (requiring covered

entities to establish and implement risk appetite and risk tolerance limits).

The specific categories of controls the Commission would require covered entities to consider under the proposed rule include: access controls; access restrictions; encryption; dual control procedures,

127

segregation of duties, and background checks; change management practices; system development and configuration management practices; flaw remediation; measures to protect against destruction, loss, or damage to covered information; monitoring systems and procedures to detect attacks or intrusions; response programs; and measures to promptly recover and secure any compromised covered information.

128

127

Dual control procedures refer to a technique that requires two or more separate persons, operating together, to protect sensitive data and information. Both persons are equally responsible for protecting the information and neither can access the information alone.

See

Interagency Guidelines Establishing Standards for Safeguarding Customer Information and Rescission of Year 2000 Standards for Safety and Soundness, 66 FR 8616, 8622 (Feb. 1, 2001) (Interagency Guidelines Safeguarding Customer Information).

128

See

paragraphs (d)(2)(i)-(xi) of proposed Commission regulations 1.13 and 23.600.

The Commission preliminarily believes that these categories of controls collectively represent a comprehensive array of controls for ensuring the information and technology security. Access controls, access restrictions, encryption, and background checks would limit access to covered technology and covered information to individuals with a legitimate business need in both physical and digital environments. Dual control procedures, segregation of duties, procedures relating to modifications to covered technology, and measures to protect against destruction, loss, or damage to covered information, would support the integrity and availability of covered information from accidental or intentional damage or disclosure to unauthorized recipients. Change management practices would ensure that the information and technology security program, and associated controls, continue to operate as intended over time as systems and processes are updated. Systems development, configuration management, and flaw remediation practices would operate to ensure the integrity and availability of covered technology throughout any updates to covered technology or following a vulnerability analysis.

129

Measures to protect against destruction of covered information due to environmental hazards would further ensure that covered information remains available even following a physical disruption. Monitoring systems and procedures, response programs, and measures to promptly recover and secure any compromised covered information would serve to detect unauthorized access to covered information and to recover it if the covered entity's access to the covered information were impaired (

e.g.,

through a ransomware attack).

129

Based on its experience, the Commission further believes that that failures in change management, systems development, and vulnerability patching practices are common sources of disruption among financial institutions and are often neglected control areas.

The proposed rule is modeled after an approach adopted by prudential regulators. Since the early 2000s, prudential regulators have required financial institutions to consider a similar list of categories of controls when designing their information security programs.

130

In adopting their list of categories, prudential regulators described them as designed to control identified risks and to achieve the overall objective of ensuring the security and confidentiality of customer information.

131

Prudential regulators further emphasized that the categories were broad enough to be adapted by institutions of varying sizes, scope of operations, and risk management structures, such that the manner of implementing the guidelines would vary from institution to institution.

132

Given that the list of control categories developed by prudential regulators, many of which are included in the Commission's proposed rule, has a longstanding history of being effective and adaptable to the financial industry at large, the Commission preliminarily believes that incorporating a similar approach with respect to covered entities would also further the Commission's intent to adopt a flexible rule that can be tailored to each individual covered entity and adapted over time to respond to changing threat environments and risk profiles.

133

130

See

Interagency Guidelines Safeguarding Customer Information, 66 FR 8616;

see also

12 CFR part 30, app. B. The guidelines were expanded and retitled, “Interagency Guidelines Establishing Information Security Standards” in 2004,

see

Proper Disposal of Consumer Information Under the Fair and Accurate Credit Transactions Act of 2003, 69 FR 77610 (Dec. 28, 2004).

131

See

Interagency Guidelines Safeguarding Customer Information, 66 FR 8621.

132

Commenters further supported the level of detail,

see id.

at 8622.

133

NIST has compiled a comprehensive catalog of security and privacy controls for all types of computing platforms, including general purpose computing systems, cyber-physical systems, cloud systems, mobile systems, and Internet of Things (IoT) devices.

See

NIST SP 800-53,

supra

note 123.

3. Incident Response Plan—Proposed Paragraph (d)(3)

The proposed rule would require that the information and technology security program include a written incident response plan that is reasonably designed to detect, assess, contain, mitigate the impact of, and recover from an incident.

134

A hallmark of operational resilience is the recognition that although meaningful steps can be taken to prevent and deter risks to information and technology security, such risks may never be entirely eliminated.

135

As the ION incident illustrated, quick and complete recovery of covered technology and operations may be key to mitigating the potential systemic impact to the financial markets. Accordingly, a crucial aspect of any information and technology security program, and therefore any ORF, is having a plan to respond to and recover from events that may create risks to information and technology security.

136

The Commission believes, therefore, that an effective incident response plan would help covered entities minimize the potential impact to their operations and customers or counterparties when negative events occur, facilitating their recovery as swiftly and successfully as possible.

137

It can also assist in securing against the destruction or theft of sensitive and important confidential customer or counterparty information, which could have a very real impact on their business and assets.

134

See

paragraph (d)(3) of proposed Commission regulations 1.13 and 23.603. The Commission is aware that some covered entities may have established an incident response plan as a separate document or as an attachment to another plan, such as a BCDR plan. If the proposed rule is adopted, the Commission would be agnostic as to where a covered entity elects to house its incident response plan provided it otherwise meets the requirements of the proposed rule, including recordkeeping, furnishing it to the Commission upon request, and distributing it to personnel.

135

See

BCBS Operational Resilience Principles,

supra

note 12, at 1 (stating that, in recognition that “the range of potential hazards cannot be prevented,” the focus should be on “the ability of banks to withstand, adapt to and recover from potential hazards and thereby mitigate potentially severe adverse impacts”).

136

See, e.g.,

BCBS Operational Resilience Principles at 7, n.18 (“The goal of incident

management is to limit the disruption and restore critical operations in line with the bank's risk tolerance for disruption.”).

See also

FFIEC Information Security Booklet,

supra

note 69, 50-51 (“containing the incident, coordinating with law enforcement and third parties, restoring systems, preserving data and evidence, providing assistance to customers, and otherwise facilitating operational resilience”); NIST, SP 800-184,

Guide for Cybersecurity Event Recovery

(Dec. 2016) (NIST SP 800-184) (“evaluate the potential impact, planned response activities, and resulting recovery processes long before an actual cyber event takes place”); CIS,

Incident Response Policy Template: Critical Security Controls

(Mar. 8, 2023) at 4 (“The primary goal of incident response is to identify threats on the enterprise, respond to them before they can spread, and remediate them before they can cause harm.”) (CIS Incident Response Template).

137

See

FFIEC, CAT at 52 (May 2017) (“The incident response plan is designed to ensure recovery from disruption of services, assurance of data integrity, and recovery of lost or corrupted data following a cybersecurity incident”); CPMI IOSCO Cyber Resilience Guidance,

supra

note 123, at 16 (recognizing the incident response plan enables the business “to resume critical operations rapidly, safely and with accurate data”).

For purposes of the proposed rule, “incident” would be defined as any event, occurrence, or circumstance that could jeopardize information and technology security, including if it occurs at a third-party service provider.

138

The purpose of the incident response plan is to identify and classify foreseeable types of incidents and to establish steps to detect, assess, contain, mitigate the impact of, and recover from incidents. The Commission's proposed definition of “incident” is intentionally broad to ensure that the incident response plan would address any event that could reasonably jeopardize (

i.e.,

endanger or put at risk) information and technology security, even if that danger never materializes or the incident response plan is otherwise successful at preventing or reversing the danger. As defined in the proposed rule, “incident” is broad enough to cover various types of risks to covered technology (

e.g.,

disruption or modification) or covered information (

e.g.,

disclosure or destruction), regardless of the source (

e.g.,

external threat actor or internal staff, physical or electronic) or whether the event was accidental or malicious in nature, since intent may not be readily determined at the outset of an incident. Common examples of incidents would include unauthorized access to a system or data; unauthorized changes to system hardware, software, or data; or a failure of controls that could, if not addressed, endanger information and technology security.

138

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “incident”).

Consistent with the general framework for the ORF as a whole, the proposal would require the incident response plan to meet certain minimum requirements.

139

In broad terms, these requirements focus on identifying persons relevant to an incident response (

i.e.,

personnel involved in responding to the incident and persons who should be notified of such incidents) and how and when they should be involved; documenting the nature of the covered entity's response; and remediating any weaknesses that lead to the incident.

140

The Commission believes that clearly identifying parties who would be involved in incident response, including external parties like third-party service providers and law enforcement, and establishing associated roles and responsibilities would help ensure that incidents are: (1) resolved in a timely manner and by appropriate personnel; (2) adequately resourced financially, operationally, and staffing-wise; and (3) disclosed to appropriate persons either within senior leadership of the covered entity or externally, where required.

141

The process of documenting incidents and management's response, as well as any subsequent remediation efforts, would assist with any related reporting obligations and required information sharing, as well as with subsequent testing of the incident response plan or post-mortem analysis, which would potentially lead to adjustments in subsequent risk assessments and provide lessons learned that could serve to help prevent the occurrence of incidents in the future.

142

139

See

paragraphs (d)(3)(i)-(vi) of proposed Commission regulations 1.13 and 23.603.

140

See id.

141

See also

NIST SP 800-61 (“It is important to identify other groups within the organization that may need to participate in incident handling so that their cooperation can be solicited before it is needed. Every incident response team relies on the expertise, judgment, and abilities of others . . .”).

142

See

NIST SP 800-184,

supra

note 132; CIS Incident Response Template,

supra

note 136, at 4 (“Without understanding the full scope of an incident, how it happened, and what can be done to prevent it from happening again, defenders will just be in a perpetual `whack-a-mole' pattern.”).

Among these minimum requirements for the incident response plan is the need for it to include escalation protocols,

i.e.,

a process of identifying when to involve or alert specific personnel, including senior leadership, of an incident.

143

Specifically, the proposed rule would require that the senior officer, oversight body, or other senior-level official that has primary responsibility for overseeing the information and technology security program; the Chief Compliance Officer (CCO);

144

and any other relevant personnel be timely informed of incidents that may significantly impact the covered entity's regulatory obligations or require notification to the Commission.

145

This provision is designed to ensure that every individual who has a role in responding to an incident at a covered entity would be appropriately notified. CCOs of covered entities in particular have a duty to take reasonable steps to ensure compliance with Commission regulations relating to the covered entities' business as a covered entity.

146

Timely disclosure of incidents to the CCO that could impact a covered entity's regulatory obligations or require disclosure to the Commission would therefore be crucial for a covered entity CCO to fulfill the duty to take reasonable steps to ensure compliance. As previously discussed above in the section addressing governance, the Commission believes that involving senior leadership in incident response would be particularly important to ensure that they are apprised of and held accountable for the ultimate effectiveness of the ORF, and that incidents receive proper attention and are swiftly addressed.

143

See

paragraph (d)(3)(ii) of proposed Commission regulations 1.13 and 23.603.

144

See

17 CFR 3.3 (establishing the qualifications and duties of covered entity CCOs).

145

See

paragraph (d)(3)(ii) of proposed Commission regulations 1.13 and 23.603.

See also

paragraph (i) of proposed Commission regulations 1.13 and 23.603 (requiring notification of certain incidents to the Commission), discussed in section II.H of this release,

infra.

146

See

17 CFR 3.3(d)(3).

4. Request for Comment

The Commission invites comment on all aspects of the proposed information and technology security program requirement, including the following questions:

Risk Assessment.

a. The proposed rule would require that the risk assessment be provided to relevant senior leadership of the covered entity upon its completion but would not require that such senior leadership certify in writing that they have received the results of the risk assessment or approve the results of the risk assessment. Such approvals and certifications may be required in other contexts to ensure that senior leadership

is aware of risk assessments and consider them in establishing strategic goals, risk appetite, and risk tolerance limits. Should the Commission require such a certification or approval? Why or why not? Please explain.

b. Given the rapidly evolving technological and threat landscape, the proposed rule would require risk assessments to be performed on at least an annual basis to support the mitigation of systemic risk and develop a strong baseline standard across covered entities. The Commission is aware of standards imposing risk assessments as frequently as every six months and as infrequently as every two years. Should the Commission consider a shorter or longer baseline frequency for risk assessments? Why or why not? Please explain.

Effective controls

. The proposed rule would require covered entities to consider broad categories of controls and determine which to adopt consistent with the proposed (b)(3) standard. The Commission is also aware that certain controls, including firewalls, antivirus, and multifactor authentication (MFA) are commonly recommended within the industry. With respect to MFA, which requires users to present two or more authentication factors at login to verify their identity before they are granted access, CISA advises that implementing MFA is important because it makes it more difficult for threat actors to gain access to information systems, even if passwords or PINs are compromised through phishing attacks or other means.

147

In 2021, FFIEC issued guidance advising financial institutions that MFA or controls of equivalent strength, including for those employees, could help more effectively mitigate risks when a financial institution's risk assessment indicates that single-factor authentication with layered security is inadequate.

148

The guidance added that MFA factors, which may include memorized secrets, look-up secrets, out-of-band devices, one-time-password devices, biometrics identifiers, and cryptographic keys, can vary in terms of usability, convenience, and strength and their ability to be exploited.

149

That same year, the Federal Trade Commission updated its rule for safeguarding customer information to mandate financial institutions to adopt MFA for all users.

150

The Commission preliminarily believes that requiring covered entities to implement such widely recommended controls, such as and including MFA, would help reduce cyber security risks and clarify expectations. Should the Commission mandate the use of any specific controls, including firewalls, antivirus, and/or MFA? Why or why not? Please explain.

147

CISA, Multi-Factor Authentication Fact Sheet (Jan. 2022),

available at https://www.cisa.gov/sites/default/files/publications/MFA-Fact-Sheet-Jan22-508.pdf.

NIST defines MFA as “[a]n authentication system that requires more than one distinct authentication factor for successful authentication. Multi-factor authentication can be performed using a multi-factor authenticator or by a combination of authenticators that provide different factors. The three authentication factors are

something you know, something you have, and something you are.”

NIST, SP 800-63-3,

Digital Identity Guidelines

at 49 (June 2017).

148

FFIEC, Authentication and Access to Financial Institution Services and Systems at 7 (rev. Jan. 5, 2022).

149

Id.

150

See

Standards for Safeguarding Customer Information, 86 FR 70272 (Dec. 9, 2021);

see also

16 CFR 314.4(c)(5) (requiring financial intuitions to “[i]mplement multi-factor authentication for any individual accessing any information system unless [a qualified individual, as defined in the rule] has approved in writing the use of reasonably equivalent or more secure access controls.”).

Incident response plan

. As proposed, covered entities would be required to notify their CCOs of incidents that they have determined may significantly impact regulatory obligations or require notification to the Commission. Commission staff are aware of instances where covered entity CCOs have not been notified of incidents sufficiently early to play a meaningful role in determining whether the incident implicates any CFTC requirements and in developing an appropriate remediation plan. Should covered entities be required to notify their CCOs of all incidents, only incidents that may require notification under the proposed rule, or incidents that may require notification under the proposed rule to other financial regulatory authorities? Why or why not?

D. Third-Party Relationship Program—Proposed Paragraph (e)

The second program required to be included as part of the proposed ORF would be a third-party relationship program, defined as a written program reasonably designed to identify, monitor, manage, and assess risks relating to third-party relationships that meets the requirements of the proposed rule.

151

The Commission understands that covered entities currently routinely rely upon third parties for a wide variety of products, services, and activities, including, for example, information technology, counterparty or customer relationship management, accounting, compliance, human resources, margin processing, trading, and risk management. Reliance on third-party service providers carries many potential benefits, including a reduction in operating costs and access to technological advancements that can improve operations and regulatory compliance.

152

151

See

paragraph (e) of proposed Commission regulations 1.13 and 23.603.

See also

paragraph (a) of proposed regulations 1.13 and 23.603 (defining “third-party relationship program”).

152

See

Prudential Third-Party Guidance, 88 FR 37927 (“The use of third parties can offer banking organizations significant benefits, such as access to new technologies, human capital, delivery channels, products, services, and markets.”); IOSCO Outsourcing Report,

supra

note 65, at 4 (“The benefits of outsourcing include lowering costs, increasing automation to speed up tasks and reduce the need for manual intervention, and providing flexibility to allow regulated entities to rapidly adjust both to the scope and scale of their activities.”); FFIEC,

Information Technology Examination Handbook, Outsourcing Technology Services Booklet

at 1 (June 2004) (“The ability to contract for technology services typically enables an institution to offer its customers enhanced services without the various expenses involved in owning the required technology or maintaining the human capital required to deploy and operate it.”).

But that reliance is not riskless.

153

As the ION incident illustrated, operational disruptions of third-party services, particularly of those important to a firm's operations or regulatory obligations, can present challenges for individual firms and even the financial system as a whole.

154

The risks may vary from minor to significant, depending on the nature of the provider or the service being rendered, but they are inherent in the nature of a third-party service provider relationship, in which a firm relies on the performance of another entity and the quality and reliability of that performance is not in the direct control of the firm.

155

The Commission accordingly believes that, in order to support their operational resilience, covered entities should have a plan in place to identify, monitor, manage, and assess the risks associated with third-party relationships.

156

153

See

Prudential Third-Party Guidance, 88 FR 37927 (“[T]he use of third parties can reduce a banking organization's direct control over activities and may introduce new risks or increase existing risks, such as operational, compliance, and strategic risks.”).

154

See supra

note 20 and accompanying text.

155

See

Prudential Third-Party Guidance, 88 FR 37927 (“Increased risk often arises from greater operational or technological complexity, newer or different types of relationships, or potential inferior performance by the third party. A banking organization can be exposed to adverse impacts, including substantial financial loss and operational disruption, if it fails to appropriately manage the risks associated with third-party relationships.”).

156

For purposes of the proposed rule, the Commission would construe “third-party service provider” broadly and consistently with the terms “third-party” and “business arrangement” as used in the Prudential Third-Party Relationship Guidance.

See id.

(“Third-party relationships can include, but are not limited to, outsourced services, use of independent consultants, referral arrangements, merchant payment processing

services, services provided by affiliates and subsidiaries, and joint ventures. Some banking organizations may form third-party relationships with new or novel structures and features—such as those observed in relationships with some financial technology (fintech) companies.”).

As mentioned above, the Commission appreciates that the risks presented by individual third-party relationships may vary depending on the firm, the provider, or service. For instance, risks may be more elevated if the service provider is a new entrant to the marketplace or the service relates to a new, untested technology, and covered entities with more numerous or intricate third-party relationships may experience greater overall risk from third parties by virtue of the number and complexity of their relationships. Accordingly, the proposed rule would not require third-party relationship programs to apply an identical degree of scrutiny and oversight to all third-party relationships. Instead, consistent with the principles-based focus of the proposed rule, and the proposed (b)(3) standard, the Commission would expect covered entities to adopt a third-party relationship program that helps them identify and assess the risks of their existing and future third-party relationships and adapt their risk management practices consistent with those risks, their risk appetite and risk tolerance limits, and the nature, size, scope, complexity, and risk profile of their business activities, following generally accepted standards and best practices.

157

See

paragraph (b)(3) of proposed Commission regulations 1.13 and 23.603.

See also

NFA Third-Party Notice,

supra

note 43 (“NFA recognizes that a Member must have flexibility to adopt a written supervisory framework relating to outsourcing functions to a Third-Party Service Provider that is tailored to a Member's specific needs and business . . .”); Prudential Third-Party Guidance, 88 FR 37924 (“[I]t is the responsibility of the banking organization to identify and evaluate the risks associated with each third-party relationship and to tailor its risk management practices, commensurate with the banking organization's size, complexity, and risk profile, as well as with the nature of its third-party relationships.”).

1. Third-Party Relationship Lifecyle Stages—Proposed Paragraph (e)(1)

To guide covered entities in developing their third-party relationship programs, and to ensure that the programs address the full scope of risks that third-party relationships can present, the proposed rule would require the third-party relationship program to describe how the covered entity would address the risks attendant to each stage of the third-party relationship lifecycle.

158

Specifically, the proposed rule would require the program to address: (i) pre-selection risk assessment; (ii) the due diligence process for prospective third-party relationships;

159

(iii) contractual negotiations; (iv) ongoing monitoring during the course of the relationship; and (v) termination of the relationship, including preparations for planned and unplanned terminations.

160

158

See

paragraph (e)(1) of proposed Commission regulations 1.13 and 23.603.

159

The proposed rule is not intended to interfere with the obligation in Commission regulation 1.11(e) for FCMs to conduct onboarding and ongoing due diligence on depositories carrying customer funds.

See

17 CFR 1.11(e)(3)(i)(A)-(B).

160

See

paragraphs (e)(1)(i)-(v) of proposed Commission regulations 1.13 and 23.603.

See also

NFA Third-Party Notice (requiring NFA members to establish a written supervisory framework that includes an initial risk assessment, onboarding due diligence, ongoing monitoring, termination, and recordkeeping); 12 CFR part 30, app. B, III.D. (Oversee Service Provider Arrangements) (requiring financial institutions to exercise appropriate due diligence in selecting service providers, contract with service providers to implement “appropriate measures designed to meet the objectives of” prudential guidelines for information security; and, where indicated by its risk assessment, monitor service providers to confirm they have satisfied their obligations).

Each of these stages offers covered entities opportunities to assess and take steps to mitigate the potential risks associated with reliance on third-party service providers. At the outset, covered entities should determine whether it is appropriate for a third-party service provider to perform a particular service and evaluate the associated risks.

161

For instance, the determination to secure a third-party service provider may carry greater risks where the service directly impacts a regulatory requirement, where the third-party service provider would be given direct access to covered information, or where a disruption of services could impact regulatory compliance or have a negative impact on customers or counterparties. Due diligence provides covered entities with information to assess whether a prospective third-party service provider is equipped, operationally and otherwise, to perform as expected.

162

Contractual negotiations offer a possibility to mitigate potential risks by including provisions to assign specific responsibilities or liabilities, but may also contribute to risks, especially where a covered entity may have more limited negotiating power.

163

Ongoing monitoring of a third-party service provider's performance likewise aids covered entities in identifying whether selected third-party service providers remain able to perform as expected throughout the duration of the relationship.

164

Finally, the manner in which the relationship ends can have a major impact on the covered entity, particularly if it ends due to a breach of performance. Plans to address the termination, through contingencies or otherwise, could therefore prove important to ensuring the covered entity's ongoing operations.

165

The Commission therefore preliminarily believes that effective management of third-party risks would require covered entities to have a program that establishes methodologies and practices to assess and manage the risks of third-party relationships throughout each of these five stages of the third-party relationship lifecycle.

166

161

See

NFA Third-Party Notice (“At the outset, a Member should determine whether a particular regulatory function is appropriate to outsource and evaluate the risks associated with outsourcing the function.”); Prudential Third-Party Guidance, 88 FR 37928 (“As part of sound risk management, effective planning allows a banking organization to evaluate and consider how to manage risks before entering into a third-party relationship.”).

162

See

IOSCO Outsourcing Report,

supra

note 65, at 18 (“It is important that regulated entities exercise due care, skill, and diligence in the selection of service providers. The regulated entity should be satisfied that the service provider has the ability and capacity to undertake the provision of the outsourced task effectively at all times.”); Prudential Third-Party Guidance, 88 FR 37929 (“Conducting due diligence on third parties before selecting and entering into third-party relationships is an important part of sound risk management. It provides management with the information needed about potential third parties to determine if a relationship would help achieve a banking organization's strategic and financial goals. The due diligence process also provides a banking organization with the information needed to evaluate whether it can appropriately identify, monitor, and control risks associated with the particular third-party relationship.”).

163

See

IOSCO Outsourcing Report at 21 (“Contractual provisions can reduce the risks of non-performance or aid the resolution of disagreements about the scope, nature, and quality of the service to be provided.”).

164

See id.

at 18 (“The regulated entity should also establish appropriate processes and procedures for monitoring the performance of the service provider on an ongoing basis to ensure that it retains the ability and capacity to continue to provide the outsourced task.”).

165

See id.

at 33 (“Where a task is outsourced, there is an increased risk that the continuity of the particular task in terms of daily management and control of that task, related information and data, staff training, and knowledge management, is dependent on the service provider continuing in that role and performing that task.”).

166

See

Prudential Third-Party Guidance, 88 FR 37928 (“Effective third-party risk management generally follows a continuous life cycle for third-party relationships.”).

2. Heightened Requirements for Critical Third-Party Service Providers—Proposed Paragraph (e)(2)

Although the Commission appreciates that third-party risks are not uniform, it nevertheless believes that certain circumstances warrant enhanced risk management practices across all covered entities. Specifically, the proposed rule would require that the third-party relationship program establish heightened due diligence and ongoing

monitoring practices with respect to third-party service providers deemed critical third-party service providers.

167

The proposed rule would define “critical third-party service provider” to mean a third-party service provider, the disruption of whose performance would be reasonably likely to either (a) significantly disrupt a covered entity's businesses operations or (b) significantly and adversely impact the covered entity's counterparties or customers.

168

The Commission understands that it is common practice for financial institutions, whether by regulatory mandate or otherwise, to identify a subset of services or providers more central to their operations and apply greater scrutiny and oversight to them to ensure the services are provided without disruption. The proposed rule's definition of “critical third-party service provider” focuses on the potential impact a disruption to performance would have on the covered entity's regulated business operations, customers, or counterparties. Where such an impact would be significant, as assessed in light of the covered entity's business activities, risk appetite, and risk tolerance limits, the Commission believes heightened due diligence for potential critical third-party service providers and ongoing monitoring for onboarded critical third-party service providers are warranted to both mitigate the potential for such an occurrence and to promote the ability for covered entities to take early and effective action if a critical third-party service provider's performance is disrupted to mitigate the impact and effectively recover.

169

167

See

paragraph (e)(2) of proposed Commission regulations 1.13 and 23.603.

168

See

paragraph (a) of proposed Commission regulations 1.13 and 23.603 (defining “critical third-party service provider”).

169

See

NFA Third-Party Notice,

supra

note 43 (“Additionally, a Member's onboarding due diligence process should be heightened for Third-Party Service Providers that obtain or have access to a Member's critical and/or confidential data and those that support a Member's critical regulatory-related systems (

e.g.,

handling customer segregated funds, keeping required records, filing financial reports, etc.).”).

3. Third-Party Service Provider Inventory—Proposed Paragraph (e)(3)

To help ensure that covered entities implement a comprehensive and consistent approach to identifying their critical third-party service providers, covered entities would be required to create, maintain, and regularly update an inventory of third-party service providers they have engaged to support their activities as a covered entity, identifying whether each third-party service provider in the inventory is a critical third-party service provider.

170

The Commission preliminarily believes that the process of creating an inventory of service providers, particularly the deliberative process involved in designating certain providers as critical third-party service providers, would help covered entities assess and evaluate the risks they face from their third-party service providers, and determine when to apply heightened monitoring. Maintaining such an inventory would also reflect that not all third-party service providers present the same level and types of risks to a covered entity, and would help covered entities assess and evaluate who is providing services and the attendant risk that any disruption of those services would have on a covered entity's business. The inventory would also provide covered entities a holistic view of their third-party service providers, which would help them better understand how risks identified during due diligence and ongoing monitoring may interact or require additional management. Having a clear understanding of who is providing services, particularly those services identified as critical, would further assist covered entities in identifying potential interconnections that may not be readily apparent if the entities are not assembled and reviewed collectively.

171

170

See

paragraph (e)(3) of proposed Commission regulations 1.13 and 23.603.

171

Prudential Third-Party Guidance, 88 FR 37927 (“Maintaining a complete inventory of its third-party relationships and periodically conducting risk assessments for each third-party relationship supports a banking organization's determination of whether risks have changed over time and to update risk management practices accordingly.”).

Covered entities relying on a consolidated third-party relationship program would be able to rely on an enterprise-wide third-party service provider inventory provided that the inventory meets the requirements of the proposed rule, including identifying critical third-party service providers specific to the covered entity.

172

See

paragraph (c)(4)(i) of proposed Commission regulations 1.13 and 23.603 (allowing covered entities to rely on consolidated programs).

4. Retention of Responsibility—Proposed Paragraph (e)(3)

For the avoidance of doubt, the proposed rule would make clear that, notwithstanding their determination to rely on a third-party service provider, covered entities remain responsible for meeting their obligations under the CEA and Commission regulations.

173

This provision reflects the principle, widely recognized among financial regulatory authorities, including the Commission, that while financial institutions may be able to delegate functions to third-party service providers, they cannot delegate their responsibility to comply with applicable laws and regulations.

174

This provision is intended to ensure that covered entities are aware that they remain responsible for the performance of all applicable regulatory functions, whether performed by the covered entity or by a third-party service provider, and are accordingly fully subject to the Commission's jurisdiction, including its examination and enforcement authorities.

173

See

paragraph (e)(3) of proposed Commission regulations 1.13 and 23.603.

174

See

NFA Third-Party Notice,

supra

note 43 (“If a Member outsources a regulatory function, however, it remains responsible for complying with NFA and/or CFTC Requirements and may be subject to discipline if a Third-Party Service Provider's performance causes the Member to fail to comply with those Requirements.”); Prudential Third-Party Guidance, 88 FR 37927 (“A banking organization's use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house.”); IOSCO Outsourcing Report,

supra

note 65, at 12 (“The regulated entity retains full responsibility, legal liability, and accountability to the regulator for all tasks that it may outsource to a service provider to the same extent as if the service were provided in-house.”).

See also

17 CFR 37.204 (SEFs); 17 CFR 38.154 (DCMs); 17 CFR 39.18(d) (DCOs) (providing that such registered entities retain responsibility for meeting relevant regulatory requirements when entering into contractual outsourcing arrangements).

5. Application to Existing Third-Party Relationships

Should the proposed rule be adopted as final, the Commission would expect covered entities to apply their third-party relationship programs across all stages of the relationship lifecycle on a going-forward basis. Although the Commission would not require covered entities to renegotiate or terminate existing agreements, it would expect covered entities to conduct ongoing monitoring of existing third-party service providers consistent with the program and this regulation and, to the extent possible, to rely on its program with respect to termination. For any third-party service providers contemplated or onboarded after the effective date of the proposed rule, or for any contracts renegotiated or renewed after the effective date of the rule, however, the Commission would expect covered entities to apply the entirety of the third-party relationship program from pre-selection through termination.

6. Guidance on Third-Party Relationship Programs—Proposed Paragraph (e)(4); Appendix A to Part 1; Appendix A to Subpart J of Part 23

To assist covered entities in developing third-party relationship programs that adequately address risks from third-party relationships, the Commission is proposing guidance outlining potential risks, considerations, and strategies for covered entities to consider.

175

The proposed guidance addresses all five stages of the relationship lifecycle and, if adopted, would be codified as appendices to parts 1 and 23 of the Commission's regulations for FCMs and swap entities, respectively.

176

Designed to be broadly applicable to all covered entities, the proposed guidance identifies actions and factors for covered entities to consider. The factors and actions identified are not exhaustive, nor should they be viewed as a required checklist. The nonbinding guidance would merely be intended to aid covered entities as they design third-party relationship programs tailored to their own unique circumstances, consistent with the general ORF “appropriate and proportionate standard” discussed above.

175

See

paragraph (e)(4) of proposed Commission regulations 1.13 and 23.603.

176

See

proposed Appendix A to part 1 and proposed Appendix A to Subpart J of part 23.

In developing the proposed guidance, the Commission considered the recommendations of international standard-setting bodies, including IOSCO and FSB, in light of observations and lessons derived from its own oversight activities.

177

In an effort to incorporate as much consensus as possible, the Commission also gave special consideration to existing guidance from NFA and the guidance on third-party relationships recently adopted by prudential regulators, both of which currently apply to at least some covered entities.

178

177

See

IOSCO Outsourcing Report,

supra

note 65; FSB Third-Party Report,

supra

note 44.

178

See

NFA Third-Party Notice; Prudential Third-Party Guidance, 88 FR 37920.

The full text of the guidance is included at the end of this notice as proposed appendix A to part 1 for FCMs and proposed appendix A to subpart J of part 23. The guidance is identical in substance for FCMs and swap entities.

7. Request for Comment

The Commission invites comment on all aspects of the proposed third-party relationship program requirement and associated guidance, including the following questions:

Scope of Application.

NFA's interpretive notice on third-party relationships is limited in scope to “outsourcing,” which NFA defines as third-party relationships in which an NFA member has a third-party service provider or vendor perform certain functions that would otherwise by undertaken by the member itself to comply with NFA and CFTC requirements.

179

The proposed rule would follow the approach taken by prudential regulators in their third-party guidance, which more broadly addresses any circumstances where banking organizations rely on third parties for products, services, or activities to “capture[ ] the full range of third-party relationships that may pose risk to banking organizations.”

180

Should the Commission consider limiting the scope of its guidance to outsourcing of CFTC regulatory obligations? Why or why not? Please explain.

179

See

NFA Third-Party Notice,

supra

note 43.

180

See

Prudential Third-Party Guidance, 88 FR 37921-22.

Critical third-party service provider.

The proposed rule includes a definition of “critical third-party service provider.” The Commission understands it is common practice for financial institutions to identify and apply heightened oversight of third-party service providers they deem critical. NFA's interpr

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.