Vol. 80 Wednesday, 

No. 246 December 23, 2015 

Part V 

Commodity Futures Trading Commission 

17 CFR Part 37, 38 and 49 

System Safeguards Testing Requirements; Proposed Rules 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80140 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

1See generally CFTC Staff Roundtable on 

Cybersecurity and System Safeguards Testing 

(March 18, 2015) (‘‘CFTC Roundtable’’), at 11–91, 

transcript available at http://www.cftc.gov/ucm/

groups/public/@newsroom/documents/file/tran

script031815.pdf. The Commission held the CFTC 

Roundtable due to its concern about the growing 

cybersecurity threat discussed in the following 

paragraphs, and in order to, among other things, 

discuss the issue and identify critical areas of 

concern. Similarly, a June 2015 Market Risk 

Advisory Committee (‘‘MRAC’’) meeting focused on 

cybersecurity. See generally MRAC Meeting (June 2, 

2015), at 6, transcript available at http://www.cftc.

gov/ucm/groups/public/@aboutcftc/documents/file/

mrac_060215_transcript.pdf. 

2Committee on Payments and Market 

Infrastructures of the Bank for International 

Settlements, Cyber resilience in financial market 

infrastructures (November 2014), at 1, available at 

http://www.bis.org/cpmi/publ/d122.pdf. 

3 IOSCO and WFE, Cyber-crime, securities 

markets and systemic risk, Staff Working Paper 

(SWP2/2013) (July 16, 2013) (‘‘IOSCO–WFE Staff 

Report’’), at 3, available at http://www.iosco.org/

research/pdf/swp/Cyber-Crime-Securities-Marketsand-Systemic-Risk.pdf. 

COMMODITY FUTURES TRADING 

COMMISSION 

17 CFR Parts 37, 38, and 49 

RIN 3038–AE30 

System Safeguards Testing 

Requirements 

AGENCY: Commodity Futures Trading 

Commission. 

ACTION: Proposed rulemaking; advanced 

notice of proposed rulemaking. 

SUMMARY: The Commodity Futures 

Trading Commission (‘‘Commission’’ or 

‘‘CFTC’’) is amending its system 

safeguards rules for designated contract 

markets, swap execution facilities, and 

swap data repositories, by enhancing 

and clarifying existing provisions 

relating to system safeguards risk 

analysis and oversight and cybersecurity 

testing, and adding new provisions 

concerning certain aspects of 

cybersecurity testing. The Commission 

is clarifying the existing system 

safeguards rules for all designated 

contract markets, swap execution 

facilities, and swap data repositories by 

specifying and defining the types of 

cybersecurity testing essential to 

fulfilling system safeguards testing 

obligations, including vulnerability 

testing, penetration testing, controls 

testing, security incident response plan 

testing, and enterprise technology risk 

assessment. The Commission is also 

clarifying rule provisions respecting the 

categories of risk analysis and oversight 

that statutorily-required programs of 

system safeguards-related risk analysis 

and oversight must address; system 

safeguards-related books and records 

obligations; the scope of system 

safeguards testing; internal reporting 

and review of testing results; and 

remediation of vulnerabilities and 

deficiencies. The new provisions 

concerning certain aspects of 

cybersecurity testing, applicable to 

covered designated markets (as defined) 

and all swap data repositories, include 

minimum frequency requirements for 

conducting the essential types of 

cybersecurity testing, and requirements 

for performance of certain tests by 

independent contractors. In this release, 

the Commission is also issuing an 

Advance Notice of Proposed 

Rulemaking requesting public comment 

concerning whether the minimum 

testing frequency and independent 

contractor testing requirements should 

be applied, via a future Notice of 

Proposed Rulemaking, to covered swap 

execution facilities (to be defined). 

DATES: Comments must be received on 

or before February 22, 2016. 

ADDRESSES: You may submit comments, 

identified by RIN number 3038–AE30, 

by any of the following methods: 

• CFTC Web site: http://

comments.cftc.gov. Follow the 

instructions for submitting comments 

through the Comments Online process 

on the Web site. 

• Mail: Send to Christopher 

Kirkpatrick, Secretary of the 

Commission, Commodity Futures 

Trading Commission, Three Lafayette 

Centre, 1155 21st Street NW., 

Washington, DC 20581. 

• Hand Delivery/Courier: Same as 

Mail, above. 

• Federal eRulemaking Portal: http:// 

www.regulations.gov. Follow the 

instructions for submitting comments. 

Please submit your comments using 

only one method. All comments must be 

submitted in English, or must be 

accompanied by an English translation. 

Contents will be posted as received to 

http://www.cftc.gov. You should submit 

only information that you wish to make 

available publicly. If you wish the 

Commission to consider information 

that may be exempt from disclosure 

under the Freedom of Information Act, 

a petition for confidential treatment of 

the exempt information may be 

submitted according to the established 

procedures in CFTC Regulation 145.9. 

FOR FURTHER INFORMATION CONTACT: 

Rachel Berdansky, Deputy Director, 

Division of Market Oversight, 202–418– 

5429, rberdansky@cftc.gov; David 

Taylor, Associate Director, Division of 

Market Oversight, 202–418–5488, 

dtaylor@cftc.gov, or David Steinberg, 

Associate Director, Division of Market 

Oversight, 202–418–5102, dsteinberg@

cftc.gov; Commodity Futures Trading 

Commission, Three Lafayette Centre, 

1155 21st Street NW., Washington, DC 

20851. 

SUPPLEMENTARY INFORMATION: 

Table of Contents 

I. Preamble 

A. Background: The Current Cybersecurity 

Threat Environment and the Need for 

Cybersecurity Testing 

B. Categories of Risk Analysis and 

Oversight Applicable to All DCMs, SEFs, 

and SDRs 

C. Requirements To Follow Best Practices, 

Ensure Testing Independence, and 

Coordinate BC–DR Plans 

D. Updating of Business ContinuityDisaster Recovery Plans and Emergency 

Procedures 

E. System Safeguards-Related Books and 

Records Obligations 

F. Cybersecurity Testing Requirements for 

DCMs, SEFs, and SDRs 

G. Additional Testing-Related Risk 

Analysis and Oversight Program 

Requirements Applicable to All DCMs, 

SEFs, and SDRs 

H. Required Production of Annual Total 

Trading Volume 

I. Advance Notice of Proposed Rulemaking 

Regarding Minimum Testing Frequency 

and Independent Contractor Testing 

Requirements for Covered SEFs 

II. Related Matters 

A. Regulatory Flexibility Act 

B. Paperwork Reduction Act 

C. Consideration of Costs and Benefits 

III. Requests for Comment 

A. Comments Regarding Notice of 

Proposed Rulemaking 

B. Comments Regarding Advance Notice of 

Proposed Rulemaking Concerning 

Covered SEFs 

I. Preamble 

A. Background: The Current 

Cybersecurity Threat Environment and 

the Need for Cybersecurity Testing 

1. Current Cybersecurity Landscape 

Cyber threats to the financial sector 

continue to expand. As the Commission 

was informed by cybersecurity experts 

participating in its 2015 Staff 

Roundtable on Cybersecurity and 

System Safeguards Testing, these threats 

have a number of noteworthy aspects.1

First, the financial sector faces an 

escalating volume of cyber attacks. 

According to the Committee on 

Payments and Market Infrastructures 

(‘‘CPMI’’) of the Bank for International 

Settlements (‘‘BIS’’), ‘‘Cyber attacks 

against the financial system are 

becoming more frequent, more 

sophisticated and more widespread.’’ 2

A survey of 46 global securities 

exchanges conducted by the 

International Organization of Securities 

Commissions (‘‘IOSCO’’) and the World 

Federation of Exchanges (‘‘WFE’’) found 

that as of July 2013, over half of 

exchanges world-wide had experienced 

a cyber attack during the previous year.3

Cybersecurity now ranks as the number 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80141 

4 DTCC, Systemic Risk Barometer Study (Q1 

2015), at 1, available at http://dtcc.com/∼/media/

Files/pdfs/Systemic-Risk-Report-2015-Q1.pdf. 

5PricewaterhouseCoopers, Managing Cyber Risks 

in an Interconnected World: Key Findings from the 

Global State of Information Security Survey 2015 

(September 30, 2014), at 7, available at www.pwc.

com/gsiss2015 (‘‘PWC Survey’’). 

6 Id. 

7CFTC Roundtable, at 41–42. 

8See CFTC Roundtable, at 12, 14–15, 17–24, 42– 

44, 47. 

9 IOSCO–WFE Staff Report, at 3–4, available at 

http://www.iosco.org/research/pdf/swp/CyberCrime-Securities-Markets-and-Systemic-Risk.pdf. 

10CFTC Roundtable, at 20–21. 

11 Id. at 21–22. 

12 Id. at 74–76, 81–82. 

13 Id. 

14 IOSCO–WFE Staff Report, at 3, available at 

http://www.iosco.org/research/pdf/swp/CyberCrime-Securities-Markets-and-Systemic-Risk.pdf. 

15CFTC Roundtable, at 22–23. 

16 Id. 

17 Id. at 14, 79–80. 

18 Id. at 60–69. 

19 Id. at 72–74. As Roundtable panelists also 

noted, experienced penetration testers are finding 

that when they are able to penetrate a financial 

institution, they often are able to move between 

internet-facing and non-internet-facing systems by 

harvesting passwords and credentials and 

exploiting access privileges associated with them. 

Id. 

20 Id. at 62–64, 77–79. 

21 Id. at 24–25. 

22 Id. at 47–55. 

23 Id. at 24. 

24 Id. at 44. 

25 Id. at 46. 

one concern for nearly half of financial 

institutions in the U.S. according to a 

2015 study by the Depository Trust & 

Clearing Corporation (‘‘DTCC’’).4 The 

annual Price Waterhouse Coopers 

Global State of Information Security 

Survey for 2015, which included 9,700 

participants, found that the total 

number of security incidents detected in 

2014 increased by 48 percent over 2013, 

for a total of 42.8 million incoming 

attacks, the equivalent of more than 

117,000 attacks per day, every day.5 As 

the PWC Survey pointed out, these 

numbers do not include undetected 

attacks. Verizon’s 2015 Data Breach 

Investigations Report noted that during 

2014 the financial services sector 

experienced an average of 350 malware 

attacks per week.6

Second, financial sector entities also 

face increasing numbers of more 

dangerous cyber adversaries with 

expanding and worsening motivations 

and goals. Until recently, most cyber 

attacks on financial sector institutions 

were conducted by criminals whose aim 

was monetary theft or fraud.7 As noted 

at the CFTC Roundtable, while such 

attacks continue, there has also been a 

rise in attacks by politically motivated 

hacktivists or terrorists, and by nation 

state actors, aimed at disruption of their 

targets’ operations, at theft of data or 

intellectual property, at extortion, at 

cyber espionage, at corruption or 

destruction of data, or at degradation or 

destruction of automated systems.8

IOSCO and the WFE note that attacks on 

securities exchanges now tend to be 

disruptive in nature, and note that 

‘‘[t]his suggests a shift in motive for 

cyber-crime in securities markets, away 

from financial gain and towards more 

destabilizing aims.’’ 9

Third, financial institutions may now 

encounter increasing cyber threat 

capabilities. According to a CFTC 

Roundtable participant, one current 

trend heightening cyber risk for the 

financial sector is the emergence of 

cyber intrusion capability—typically 

highest when supported by nation state 

resources—as a key tool of statecraft for 

most states.10 Another trend noted by 

Roundtable participants is an increase 

in sophistication on the part of most 

actors in the cyber arena, both in terms 

of technical capability and of capacity to 

organize and carry out attacks.11

Fourth, the cyber threat environment 

includes an increase in cyber attack 

duration.12 While attacks aimed at 

monetary theft or fraud tend to manifest 

themselves quickly, more sophisticated 

attacks may involve cyber adversaries 

having a cyber presence inside a target’s 

automated systems for an extended 

period of time, and avoiding 

detection.13 IOSCO and the WFE noted 

in 2013 that: 

The rise of a relatively new class of cyberattack is especially troubling. This new class 

is referred to as an ‘Advanced Persistent 

Threat.’ Advanced Persistent Threats (APTs) 

are usually directed at business and political 

targets for political ends. APTs involve 

stealth to persistently infiltrate a system over 

a long period of time, without the system 

displaying any unusual symptoms.14

Fifth, there is now a broadening cyber 

threat field. Financial institutions 

should consider cyber vulnerabilities 

not only with respect to their desktop 

computers, but also with respect to 

mobile devices used by their 

employees.15 In some cases, their risk 

analysis should address not only 

protecting the integrity of data in their 

own automated systems, but also 

protecting data in the cloud.16 Adequate 

risk analysis should also address both 

the vulnerabilities of the entity’s 

automated systems and human 

vulnerabilities such as those posed by 

social engineering or by disgruntled or 

coerced employees.17 The cyber threat 

field includes automated systems that 

are not directly internet-facing, which 

can be vulnerable to cyber attacks 

despite their isolation behind 

firewalls.18 In practice, there is 

interconnectivity between internetfacing and corporate information 

technology (‘‘IT’’) and operations 

technology, since the two can be and 

often are connected for maintenance 

purposes or in error.19 Non-internetfacing systems are also vulnerable to 

insertion of malware-infected removable 

media, phishing attacks, and other 

social engineering techniques, and to 

supply-chain risk involving both 

hardware and software.20

Finally, financial institutions cannot 

achieve cyber resilience by addressing 

threats to themselves alone: They also 

face threats relating to the increasing 

interconnectedness of financial services 

firms.21 In today’s environment, a 

financial entity’s risk assessments 

should consider cybersecurity across the 

financial sector, from exchanges and 

clearinghouses to counterparties and 

customers, technology providers, other 

third party service providers, and the 

businesses and products in the entity’s 

supply chain.22

2. Need for Cybersecurity Testing 

Cybersecurity testing by designated 

contract markets (‘‘DCMs’’), swap 

execution facilities (‘‘SEFs’’), derivatives 

clearing organizations (‘‘DCOs’’), swap 

data repositories (‘‘SDRs’’), and other 

entities in the financial sector can 

harden cyber defenses, mitigate 

operations, reputation, and financial 

risk, and maintain cyber resilience and 

ability to recover from cyber attack.23 To 

ensure the effectiveness of cybersecurity 

controls, a financial sector entity must 

test in order to find and fix its 

vulnerabilities before an attacker 

exploits them. A financial sector entity’s 

testing should assess, on the basis of 

information with respect to current 

threats, how the entity’s controls and 

countermeasures stack up against the 

techniques, tactics, and procedures used 

by its potential adversaries.24 Testing 

should include periodic risk 

assessments made in light of changing 

business conditions, the changing threat 

landscape, and changes to automated 

systems. It should also include recurring 

tests of controls and automated system 

components to verify their effectiveness 

and operability, as well as continuous 

monitoring and scanning of system 

operation and vulnerabilities.25 Testing 

should focus on the entity’s ability to 

detect, contain, respond to, and recover 

from cyber attacks, not just on its 

perimeter defenses designed to prevent 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80142 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

26 Id. at 80–84. As one cybersecurity expert has 

remarked, ‘‘Organizations are too focused on 

firewalls, spam filters, and other Maginot Line-type 

defenses that have lost their effectiveness. That’s a 

misguided philosophy. There’s no such thing as a 

perimeter anymore.’’ Associated Press, Cyber theft 

of personnel info rips hole in espionage defenses 

(June 15, 2015), available at http://bigstory.ap.org/ 

article/93077d547f074bed8ce9eb292a3bbd47/

cybertheft-personnel-info-rips-hole-espionagedefenses. 

27CFTC Roundtable, at 15–16, 65, 71–73, 80–83. 

28 Id. at 87–88. 

29FISMA section 3544(b)(5), available at http://

csrc.nist.gov/drivers/documents/FISMA-final.pdf. 

30NIST Framework, Subcategory PR.IP–10, at 28, 

and Category DE.DP, at 31, available at http://www.

nist.gov/cyberframework/upload/cybersecurityframework-021214.pdf. 

31FINRA, Report on Cybersecurity Practices 

(February 2015), at 1–2, available at https://www.

finra.org/sites/default/files/p602363%20Report%20

on%20Cybersecurity%20Practices_0.pdf. 

32 Id. at 8. 

33Council on CyberSecurity, The Critical Security 

Controls for Effective Cyber Defense Version 5.1, 

Critical Security Control (‘‘CSC’’) 4, at 27, available 

at http://www.counciloncybersecurity.org/criticalcontrols/. 

34 Id. 

35 Id., CSC 20, at 102. 

36 Id., CSC 20–1, at 102. 

37 Id., CSC 20–6, at 103. 

38The FFIEC includes the Board of Governors of 

the Federal Reserve System, the Federal Deposit 

Insurance Corporation, the Office of the 

Comptroller of the Currency, the Consumer 

Financial Protection Bureau, the National Credit 

Union Administration, and the State Liaison 

Committee of the Conference of State Bank 

Supervision. 

39FFIEC, E-Banking IT Examination Handbook, 

at 30, available at http://ithandbook.ffiec.gov/ 

ITBooklets/FFIEC_ITBooklet_E-Banking.pdf. 

40PriceWaterhouseCoopers, Insurance 2020 and 

Beyond: Reaping the Dividends of Cyber Resilience, 

2015, available at http://www.pwc.com/gx/en/ 

insurance/publications/assets/reaping-dividendscyber-resilience.pdf. 

41 IOSCO Consultation Report, Mechanisms for 

Trading Venues to Effectively Manage Electronic 

Trading Risks and Plans for Business Continuity 

(April 2015) (‘‘IOSCO 2015 Consultation Report’’), 

at 3, available at http://www.iosco.org/library/ 

pubdocs/pdf/IOSCOPD483.pdf. 

42 Id. at 9. 

43European Securities and Markets Authority 

(‘‘ESMA’’), Guidelines: Systems and controls in an 

automated trading environment for trading 

platforms, investment firms and competent 

authorities (February 24, 2012), at 7, available at 

http://www.esma.europa.eu/system/files/ 

esma_2012_122_en.pdf. 

44CPMI–IOSCO, Principles for Financial Market 

Infrastructures, (Apr. 2012), at 96, available at 

intrusions.26 It should address 

detection, containment, and recovery 

from compromise of data integrity— 

perhaps the greatest threat with respect 

to financial sector data—in addition to 

compromise of data availability or 

confidentiality, which tend to be the 

main focus of many best practices.27

Both internal testing by the entity itself 

and independent testing by third party 

service providers are essential 

components of an adequate testing 

regime.28

Cybersecurity testing is a wellestablished best practice generally and 

for financial sector entities. The Federal 

Information Security Management Act 

(‘‘FISMA’’), which is a source of 

cybersecurity best practices and also 

establishes legal requirements for 

federal government agencies, calls for 

‘‘periodic testing and evaluation of the 

effectiveness of information security 

policies, procedures, and practices, to 

be performed with a frequency 

depending on risk, but no less than 

annually.’’ 29 The National Institute of 

Standards and Technology (‘‘NIST’’) 

Framework for Improving Critical 

Infrastructure Cybersecurity (‘‘NIST 

Framework’’) calls for testing of 

cybersecurity response and recovery 

plans and cybersecurity detection 

processes and procedures.30 The 

Financial Industry Regulatory Authority 

(‘‘FINRA’’) 2015 Report on 

Cybersecurity Practices notes that ‘‘Risk 

assessments serve as foundational tools 

for firms to understand the 

cybersecurity risks they face across the 

range of the firm’s activities and assets,’’ 

and calls for firms to develop, 

implement and test cybersecurity 

incident response plans.31 FINRA notes 

that one common deficiency with 

respect to cybersecurity is ‘‘failure to 

conduct adequate periodic cybersecurity 

assessments.’’ 32 The critical security 

controls established by the Council on 

CyberSecurity (‘‘the Council’’) call for 

entities to ‘‘[c]ontinuously acquire, 

assess, and take action on new 

information in order to identify 

vulnerabilities, remediate, and 

minimize the window of opportunity for 

attackers.’’ 33 The Council notes that 

‘‘[o]rganizations that do not scan for 

vulnerabilities and proactively address 

discovered flaws face a significant 

likelihood of having their computer 

systems compromised.’’ 34 The 

Council’s critical security controls also 

call for entities to ‘‘test the overall 

strength of an organization’s defenses 

(the technology, the processes, and the 

people) by simulating the objectives and 

actions of an attacker.’’ 35 The Council 

calls for implementation of this control 

by conducting ‘‘regular external and 

internal penetration tests to identify 

vulnerabilities and attack vectors that 

can be used to exploit enterprise 

systems successfully,’’ from both 

outside and inside the boundaries of the 

organization’s network perimeter,36 and 

also calls for use of vulnerability 

scanning and penetration testing in 

concert.37

The Federal Financial Institutions 

Examination Council (‘‘FFIEC’’),38

another important source of 

cybersecurity best practices for financial 

sector entities, effectively summarized 

the need for cybersecurity testing in 

today’s cyber threat environment: 

Financial institutions should have a testing 

plan that identifies control objectives; 

schedules tests of the controls used to meet 

those objectives; ensures prompt corrective 

action where deficiencies are identified; and 

provides independent assurance for 

compliance with security policies. Security 

tests are necessary to identify control 

deficiencies. An effective testing plan 

identifies the key controls, then tests those 

controls at a frequency based on the risk that 

the control is not functioning. Security 

testing should include independent tests 

conducted by personnel without direct 

responsibility for security administration. 

Adverse test results indicate a control is not 

functioning and cannot be relied upon. 

Follow-up can include correction of the 

specific control, as well as a search for, and 

correction of, a root cause. Types of tests 

include audits, security assessments, 

vulnerability scans, and penetration tests.39

Some experts note that cybersecurity 

testing may become a requirement for 

obtaining cyber insurance. Under such 

an approach, coverage might be 

conditioned on cybersecurity testing 

and assessment followed by 

implementation of appropriate 

prevention and detection procedures.40

Cybersecurity testing is also 

supported internationally. IOSCO has 

emphasized the importance of testing to 

ensure effective controls, in light of 

risks posed by the complexity of 

markets caused by technological 

advances.41 IOSCO has stated that 

trading venues should ‘‘appropriately 

monitor critical systems and have 

appropriate control mechanisms in 

place.’’ 42 The European Securities and 

Markets Authority (‘‘ESMA’’) 

Guidelines for automated trading 

systems call for trading platforms to test 

trading systems and system updates to 

ensure that the system meets regulatory 

requirements, that risk management 

controls work as intended, and that the 

system can function effectively in 

stressed market conditions.43 Further, 

the Principles for Financial Market 

Infrastructures (‘‘PFMIs’’) published by 

the Bank for International Settlements’ 

Committee on Payments and Market 

Infrastructures (‘‘CPMI’’) and IOSCO’s 

Technical Committee (together, ‘‘CPMI– 

IOSCO’’) note that with respect to 

operational risks, which include cyber 

risk, ‘‘[a financial market 

infrastructure]’s arrangements with 

participants, operational policies, and 

operational procedures should be 

periodically, and whenever necessary, 

tested and reviewed, especially after 

significant changes occur to the system 

or a major incident occurs. . . .’’ 44


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80143 

http://www.iosco.org/library/pubdocs/pdf/

IOSCOPD377.pdf. See also CPMI, Cyber resilience 

in financial market infrastructures, (Nov. 2014), 

available at http://www.bis.org/cpmi/publ/d122.pdf. 

45 7 U.S.C. 7(d)(20); 7 U.S.C. 5h(f)(14); 7 U.S.C. 

24a(c)(8); 17 CFR 38.1050; 17 CFR 37.1400; 17 CFR 

49.24(a)(1). 

46 Id. 

47 17 CFR 38.1051(a) and (b); 17 CFR 37.1401(a); 

Appendix A to Part 37, Core Principle 14 of Section 

5h of the Act—System Safeguards (a) Guidance (1) 

Risk analysis and oversight program; 17 CFR 

49.24(b) and (c). 

48See 17 CFR 38.1051(a); 17 CFR 37.1401(a); and 

17 CFR 49.24(b). 

49See 17 CFR 38.1051(c) and 38.1051(i) (for 

DCMs); 17 CFR 37.1401(b) and Appendix A to Part 

37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (3) Coordination 

(for SEFs); 17 CFR 49.24(d) and 49.24(k) (for SDRs). 

50 17 CFR 38.1050(a) (for DCMs); 17 CFR 

37.1400(a) (for SEFs); 17 CFR 49.24(a)(1) (for SDRs). 

51See NIST Special Publication (‘‘SP’’) 800–53 

Rev. 4, Security and Privacy Controls for Federal 

Information Systems and Organizations Controls 

(‘‘NIST SP 800–53 Rev. 4’’), RA–1, RA–2, and RA– 

3, available at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf. 

52NIST SP 800–39, Managing Information 

Security Risk: Organization, Mission, and 

Information System View (March 2011) (‘‘NIST SP 

800–39’’), available at http://csrc.nist.gov/ 

publications/nistpubs/800-39/SP800-39-final.pdf. 

53 Id. at 1. 

B. Categories of Risk Analysis and 

Oversight Applicable to All DCMs, SEFs, 

and SDRs 

The system safeguards provisions of 

the Commodity Exchange Act (‘‘Act’’ or 

‘‘CEA’’) and Commission regulations 

applicable to all DCMs, SEFs, and SDRs 

require each DCM, SEF, and SDR to 

maintain a program of risk analysis and 

oversight to identify and minimize 

sources of operational risk.45 The Act 

provides that each such entity must 

have appropriate controls and 

procedures for this purpose, and must 

have automated systems that are 

reliable, secure, and have adequate 

scalable capacity.46 Commission 

regulations concerning system 

safeguards for DCMs, SEFs, and SDRs 

provide that the program of risk analysis 

and oversight required of each such 

entity must address specified categories 

of risk analysis and oversight, and 

applicable regulations and guidance 

provide that such entities should follow 

generally accepted standards and best 

practices for development, operation, 

reliability, security, and capacity of 

automated systems.47

Six categories of risk analysis and 

oversight are specified in the 

Commission’s current regulations for 

DCMs, SEFs, and SDRs: Information 

security; business continuity-disaster 

recovery (‘‘BC–DR’’) planning and 

resources; capacity and performance 

planning; systems operations; systems 

development and quality assurance; and 

physical security and environmental 

controls.48 The current DCM, SEF, and 

SDR system safeguards regulations 

address specific requirements 

concerning BC–DR, but do not provide 

any further guidance respecting the 

other five required categories.49 In this 

Notice of Proposed Rulemaking 

(‘‘NPRM’’), the Commission proposes to 

clarify what is already required of all 

DCMs, SEFs, and SDRs regarding the 

other five specified categories, by 

defining each of them. The proposed 

definitions are grounded in generally 

accepted best practices regarding 

appropriate risk analysis and oversight 

with respect to system safeguards, 

which all DCMs, SEFs, and SDRs should 

follow as provided in the current 

regulations. As the proposed definitions 

explicitly state, they are not intended to 

be all-inclusive; rather, they highlight 

important aspects of the required risk 

analysis and oversight categories. 

The Commission is also proposing to 

add and define another enumerated 

category, enterprise risk management 

and governance, to the list of required 

categories of system safeguards-related 

risk analysis and oversight. As 

explained below, generally accepted 

best practices regarding appropriate risk 

analysis and oversight with respect to 

system safeguards—which form the 

basis for the proposed definition of this 

added category—also establish 

enterprise risk management and 

governance as an important category of 

system safeguards-related risk analysis 

and oversight. This category is therefore 

implicit in the Commission’s existing 

system safeguard regulations, which 

already require each DCM, SEF, and 

SDR to maintain a program of risk 

analysis and oversight with respect to 

system safeguards.50 The proposed rule 

would make it an explicitly listed 

category for the sake of clarity. As with 

the other proposed category definitions, 

the definition of the proposed 

additional category of enterprise risk 

management and governance clarifies 

what is already required and will 

continue to be required of all DCMs, 

SEFs, and SDRs with regard to their 

system safeguards-related risk analysis 

and oversight programs under the 

existing rules. As such, addition of this 

category does not impose additional 

obligations on such entities. The 

Commission sets forth below the best 

practices surrounding enterprise risk 

management and governance. In 

connection with its further definition of 

five of the other six categories of risk 

analysis and oversight already 

enumerated in the existing regulations, 

the Commission will also cite some 

examples of the best practices 

underlying those categories. 

1. Enterprise Risk Management and 

Governance 

As stated in the proposed rules, this 

category of risk analysis and oversight 

includes the following five areas: 

• Assessment, mitigation, and 

monitoring of security and technology 

risk. 

• Capital planning and investment 

with respect to security and technology. 

• Board of directors and management 

oversight of system safeguards. 

• Information technology audit and 

controls assessments. 

• Remediation of deficiencies. 

The category also includes any other 

enterprise risk management and 

governance elements included in 

generally accepted best practices. As 

noted above, this category of risk 

analysis and oversight is already 

implicit in the Commission’s existing 

system safeguards rules for all DCMs, 

SEFs, and SDRs, as an essential part of 

an adequate program of risk analysis 

and oversight according to generally 

accepted standards and best practices. 

The Commission sets out below the best 

practices basis for its proposed 

definition of this category, which like 

the other proposed definitions is 

provided for purposes of clarity. 

a. Assessment, Mitigation, and 

Monitoring of Security and Technology 

Risk 

In the area of assessment, mitigation, 

and monitoring of security and 

technology risk, NIST calls for 

organizations to develop appropriate 

and documented risk assessment 

policies, to make effective risk 

assessments, and to develop and 

implement a comprehensive risk 

management strategy relating to the 

operation and use of information 

systems.51 NIST notes that risk 

assessment is a fundamental component 

of an organization’s risk management 

process, which should include framing, 

assessing, responding to, and 

monitoring risks associated with 

operation of information systems or 

with any compromise of data 

confidentiality, integrity, or 

availability.52 According to NIST: 

Leaders must recognize that explicit, wellinformed risk-based decisions are necessary 

in order to balance the benefits gained from 

the operation and use of these information 

systems with the risk of the same systems 

being vehicles through which purposeful 

attacks, environmental disruptions, or human 

errors cause mission or business failure.53

NIST standards further provide that 

an organization’s risk management 

strategy regarding system safeguards 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80144 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

54NIST SP 800–53 Rev. 4, control PM–9 Risk 

Management Strategy, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 

55 ISACA, Control Objectives for Information and 

Related Technology (‘‘COBIT’’) 5, Align, Plan and 

Organize (‘‘APO’’) APO12, available at https:// 

cobitonline.isaca.org/. 

56 Id. at APO12.03. 

57NIST 800–53 Rev. 4, SA–2, Allocation of 

Resources, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf. 

58 Id. at PM–3, Information Security Resources. 

59COBIT 5, APO06, available at https:// 

cobitonline.isaca.org/. 

60See, e.g., NIST 800–53 Rev. 4, Program 

Management Controls PM–1, Information Security 

Program Plan, PM–2, Senior Information Security 

Officer, and PM 9, Risk Management Strategy, 

available at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf. 

61FFIEC, Audit IT Examination Handbook, 

Objective 3, at A–2, available at http:// 

ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_Audit.pdf. 

62 Id. 

63COBIT 5, APO01, available at https:// 

cobitonline.isaca.org/. 

64CFTC Roundtable, at 242–243. In addition, 

boards of directors can now face litigation alleging 

breach of fiduciary duty based on failure to monitor 

cybersecurity risk and ensure maintenance of 

proper cybersecurity controls. See, e.g., Kulla v. 

Steinhafel, D. Minn. No. 14–CV–00203, (U.S. Dist. 

2014) (shareholder derivative suit against Target 

board of directors), and Palkon v. Holmes, D. NJ No. 

2:14–CV–01234 (U.S. Dist. 2014) (shareholder 

derivative suit against Wyndham Worldwide 

Corporation board members). 

65FFIEC, Audit IT Examination Handbook, at 1, 

available at http://ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_Audit.pdf. 

66 Id. 

67 Id. 

68NIST 800–53 Rev. 4, control PM–4, Plan of 

Action and Milestones Process, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 

69COBIT 5, APO12, available at https:// 

cobitonline.isaca.org/. 

70FFIEC, Audit IT Examination Handbook, 

Objective 6, at A–4, available at http:// 

ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_Audit.pdf. 

71 Id. 

should include risk mitigation 

strategies, processes for evaluating risk 

across the organization, and approaches 

for monitoring risk over time.54 ISACA’s 

Control Objectives for Information and 

Related Technology (‘‘COBIT’’) 5 calls 

for organizations to continually identify, 

assess, and reduce IT-related risk in 

light of levels of system safeguards risk 

tolerance set by the organization’s 

executive management.55 As part of 

such assessment, COBIT 5 calls for 

maintaining an updated risk profile that 

includes known risks and risk attributes 

as well as an inventory of the 

organization’s related resources, 

capabilities, and controls.56

b. Capital Planning and Investment 

Respecting Security and Technology 

Security and technology capital 

planning and investment are also 

recognized as best practices for 

enterprise risk management and 

governance. NIST standards call for 

entities to determine, as part of their 

capital planning and investment control 

process, both the information security 

requirements of their information 

systems and the resources required to 

protect those systems.57 NIST standards 

further provide that entities should 

ensure that their capital planning and 

investment includes the resources 

needed to implement their information 

security programs, and should 

document all exceptions to this 

requirement.58 ISACA’s COBIT 5 also 

addresses capital planning, budgeting, 

and investment with respect to 

information technology and system 

safeguards.59

c. Board of Directors and Management 

Oversight of System Safeguards 

Board of directors and management 

oversight of system safeguards is 

another recognized best practice for 

enterprise risk management and 

governance. NIST defines requirements 

for board of directors and management 

oversight of cybersecurity.60 The FFIEC 

calls for financial sector organizations to 

review the system safeguards-related 

credentials of the board of directors or 

the board committee responsible for 

oversight of technology and security, 

and to determine whether the directors 

responsible for such oversight have the 

appropriate level of experience and 

knowledge of information technology 

and related risks to enable them to 

provide adequate oversight.61 If 

directors lack the needed level of 

experience and knowledge, the FFIEC 

calls for the organization to consider 

bringing in outside independent 

consultants to support board 

oversight.62 ISACA’s COBIT 5 calls for 

entities to maintain effective governance 

of the enterprise’s IT mission and 

vision, and to maintain mechanisms and 

authorities for managing the enterprise’s 

use of IT in support of its governance 

objectives, in light of the criticality of IT 

to its enterprise strategy and its level of 

operational dependence on IT.63 In a 

three-lines-of-defense model for 

cybersecurity, the important third line 

of defense consists of having an 

independent audit function report to the 

board of directors concerning 

independent tests, conducted with 

sufficient frequency and depth, that 

determine whether the organization has 

appropriate and adequate cybersecurity 

controls in place which function as they 

should.64

d. Information Technology Audit and 

Controls Assessment 

Information technology audit and 

controls assessments are an additional 

major aspect of best practices regarding 

enterprise risk management and 

governance. As the FFIEC has stated: 

A well-planned, properly structured audit 

program is essential to evaluate risk 

management practices, internal control 

systems, and compliance with corporate 

policies concerning IT-related risks at 

institutions of every size and complexity. 

Effective audit programs are risk-focused, 

promote sound IT controls, ensure the timely 

resolution of audit deficiencies, and inform 

the board of directors of the effectiveness of 

risk management practices.65

The FFIEC has also noted that today’s 

rapid rate of change with respect to 

information technology and 

cybersecurity make IT audits essential 

to the effectiveness of an overall audit 

program.66 Further: 

The audit program should address IT risk 

exposures throughout the institution, 

including the areas of IT management and 

strategic planning, data center operations, 

client/server architecture, local and widearea networks, telecommunications, physical 

and information security . . . systems 

development, and business continuity 

planning. IT audit should also focus on how 

management determines the risk exposure 

from its operations and controls or mitigates 

that risk.67

e. Remediation of Deficiencies 

Finally, remediation of deficiencies is 

another important part of enterprise risk 

management and governance best 

practices. NIST calls for organizations to 

ensure that plans of action and 

milestones for IT systems and security 

are developed, maintained, and 

documented, and for organizations to 

review such plans for consistency with 

organization-wide risk management 

strategy and priorities for risk response 

actions.68 As noted above, ISACA’s 

COBIT 5 establishes best practices 

calling for entities to reduce IT-related 

risk within levels of tolerance set by 

enterprise executive management.69 The 

FFIEC calls for management to take 

appropriate and timely action to address 

identified IT problems and weaknesses, 

and to report such actions to the board 

of directors.70 FFIEC further calls for the 

internal audit function to determine 

whether management sufficiently 

corrects the root causes of all significant 

system safeguards deficiencies.71

2. Information Security 

As stated in the proposed rules, this 

category of risk analysis and oversight 

includes, without limitation, controls 

relating to each of the following: 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80145 

72NIST SP 800–53 Rev. 4, Access Controls (‘‘AC’’) 

control family, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf; Council on CyberSecurity, CSC 7, 12, 15, 

available at http://www.counciloncybersecurity.org/ 

critical-controls/. 

73NIST SP 800–53 Rev. 4, Identification and 

Authentication (‘‘IA’’) control family, available at 

http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; Council 

on CyberSecurity, CSC 1, 2, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

74NIST SP 800–53 Rev. 4, Awareness and 

Training (‘‘AT’’) control family, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf; Council on CyberSecurity, 

CSC 9, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

75NIST SP 800–53 Rev. 4, Audit and 

Accountability (‘‘AU’’) control family, available at 

http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; Council 

on CyberSecurity, CSC 14, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

76NIST SP 800–53 Rev. 4, Media Protection 

(‘‘MP’’) control family, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 

77NIST SP 800–53 Rev. 4, Personnel Security 

(‘‘PS’’) control family, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 

78NIST SP 800–53 Rev. 4, System and 

Communication Protection (‘‘SC’’) control family, 

available at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; Council 

on CyberSecurity, CSC 7, 10, 11, 13, available at 

http://www.counciloncybersecurity.org/criticalcontrols/. 

79NIST SP 800–53 Rev. 4, System and 

Information Integrity (‘‘SI’’) control family, available 

at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; Council 

on CyberSecurity, CSC 3, 5, 17, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

80NIST SP 800–53 Rev. 4, control RA–5, available 

at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; Council 

on CyberSecurity, CSC 4, 5, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

81NIST SP 800–53 Rev. 4, control CA–8, available 

at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; Council 

on CyberSecurity, CSC 20, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

82NIST SP 800–53 Rev. 4, Incident Response 

(‘‘IR’’) control family, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf; NIST SP 800–61 Rev. 2, 

Computer Security Incident Handling Guide (‘‘NIST 

SP 800–61 Rev. 2’’), available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-61r2.pdf. 

83 17 CFR 38.1051(c) (for DCMs); 17 CFR 

37.1401(b) (for SEFs); 17 CFR 49.24(a)(2) (for SDRs). 

84 17 CFR 38.1051(c) and (d) (for DCMs); 17 CFR 

37.1401(b) and (c) (for SEFs); 17 CFR 49.24(d), (e), 

and (f) (for SDRs). 

85 17 CFR 38.1051(h) (for DCMs); 17 CFR 

37.1401(g) (for SEFs); 17 CFR 49.24(j) (for SDRs). 

86 17 CFR 38.1051(i)(1) and (2) (for DCMs); 

Appendix A to Part 37, Core Principle 14 of Section 

5h of the Act—System Safeguards (a) Guidance 

(3)(i) and (ii) (for SEFs); 17 CFR 49.24(k)(1) and (2) 

(for SDRs). 

87 17 CFR 38.1051(i)(3) (for DCMs); Appendix A 

to Part 37, Core Principle 14 of Section 5h of the 

Act—System Safeguards (a) Guidance (3)(iii) (for 

SEFs); 17 CFR 49.24(k)(3) (for SDRs). 

88 17 CFR 38.1051(b) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (1) Risk analysis 

and oversight program (for SEFs); 17 CFR 49.24(c) 

(for SDRs). For such best practices, see generally, 

e.g., NIST SP 800–34 Rev. 1, Contingency Planning 

Guide for Federal Information Systems, available at 

http://csrc.nist.gov/publications/nistpubs/800-34- 

rev1/sp800-34-rev1_errata-Nov11-2010.pdf. 

89CFTC Roundtable, at 277–363. 

90 ISACA, COBIT 5, Build, Acquire and 

Implement (‘‘BAI’’) BAI04, available at https://

cobitonline.isaca.org/; FFIEC, Operations IT 

Examination Handbook, at 33–34, 35, 40–41, 

available at http://ithandbook.ffiec.gov/ITBooklets/

FFIEC_ITBooklet_Operations.pdf. 

• Access to systems and data (e.g., 

least privilege, separation of duties, 

account monitoring and control).72

• User and device identification and 

authentication.73

• Security awareness training.74

• Audit log maintenance, monitoring, 

and analysis.75

• Media protection.76

• Personnel security and screening.77

• Automated system and 

communications protection (e.g., 

malware defenses, software integrity 

monitoring).78

• Automated system and information 

integrity (e.g., network port control, 

boundary defenses, encryption).79

• Vulnerability management.80

• Penetration testing.81

• Security incident response and 

management.82

The category also includes any other 

elements of information security 

included in generally accepted best 

practices. All of these important aspects 

of information security are grounded in 

generally accepted standards and best 

practices, such as the examples cited in 

the footnotes for each aspect given 

above. The Commission believes that 

information security programs that 

address each of these aspects continue 

to be essential to maintaining effective 

system safeguards in today’s 

cybersecurity threat environment. 

3. Business Continuity-Disaster 

Recovery Planning and Resources 

The Commission’s current system 

safeguards regulations for DCMs, SEFs, 

and SDRs already contain detailed 

description of various aspects of this 

category of risk analysis and oversight. 

The regulations require DCMs, SEFs, 

and SDRs to maintain a BC–DR plan and 

BC–DR resources, emergency 

procedures, and backup facilities 

sufficient to enable timely resumption 

of the DCM’s, SEF’s, or SDR’s 

operations, and resumption of its 

fulfillment of its responsibilities and 

obligations as a CFTC registrant 

following any such disruption.83 In this 

connection, the regulations address 

applicable recovery time objectives for 

resumption of operations.84 The 

regulations also require regular, 

periodic, objective testing and review of 

DCM, SEF, and SDR BC–DR 

capabilities.85 Applicable regulations 

and guidance provide that the DCM, 

SEF, or SDR, to the extent practicable, 

should coordinate its BC–DR plan with 

those of other relevant parties as 

specified, initiate and coordinate 

periodic, synchronized testing of such 

coordinated plans.86 They further 

provide that the DCM, SEF, or SDR 

should ensure that its BC–DR plan takes 

into account the BC–DR plans of its 

telecommunications, power, water, and 

other essential service providers.87 In 

addition, the regulations and guidance 

call for DCMs, SEFs, and SDRs to follow 

generally accepted best practices and 

standards with respect to BC–DR 

planning and resources, as similarly 

provided for the other specified 

categories of system safeguards risk 

analysis and oversight.88

Because the current system safeguards 

regulations already address these 

various aspects of the category of BC– 

DR planning and resources, the 

Commission is not proposing to further 

define this category at this time. The 

Commission notes that participants in 

the CFTC Roundtable discussed 

whether BC–DR planning and testing is 

at an inflection point: while such 

planning and testing has traditionally 

focused on kinetic events such as storms 

or physical attacks by terrorists, today 

cybersecurity threats may also result in 

loss of data integrity or long-term cyber 

intrusion. Future development of 

different types of BC–DR testing focused 

on cyber resiliency, and of new 

standards for recovery and resumption 

of operations may be warranted.89

4. Capacity and Performance Planning 

As provided in the proposed rule, this 

category of risk analysis and oversight 

includes (without limitation): Controls 

for monitoring DCM, SEF, or SDR 

systems to ensure adequate scalable 

capacity (e.g., testing, monitoring, and 

analysis of current and projected future 

capacity and performance, and of 

possible capacity degradation due to 

planned automated system changes); 90

and any other elements of capacity and 

performance planning included in 

generally accepted best practices. All of 

these important aspects of capacity and 

performance planning are grounded in 

generally accepted standards and best 

practices, such as the examples cited in 

the footnote above. The Commission 

believes that capacity and performance 

planning programs that address these 

aspects are essential to maintaining 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80146 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

91NIST SP 800–53 Rev. 4, Maintenance (‘‘MA’’) 

control family, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf. 

92NIST SP 800–53 Rev. 4, Configuration 

Management (‘‘CM’’) control family, available at 

http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53r4.pdf; Council on 

CyberSecurity, CSC 1, 2, 3, 10, 11, 12, available at 

http://www.counciloncybersecurity.org/criticalcontrols/. 

93FFIEC, Operations IT Examination Handbook, 

at 28, and Objective 10, at A–8 to A–9, available at 

http://ithandbook.ffiec.gov/ITBooklets/FFIEC_IT

Booklet_Operations.pdf; ISACA, COBIT 5, Deliver, 

Service and Support (‘‘DSS’’) process DSS03, 

available at https://cobitonline.isaca.org/. 

94NIST SP 800–53 Rev. 4, control SA–4, available 

at http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53r4.pdf; FFIEC 

Development and Acquisition IT Examination 

Handbook, at 2–3, available at http://ithandbook.

ffiec.gov/ITBooklets/FFIEC_ITBooklet_Development

andAcquisition.pdf. 

95NIST SP 800–53 Rev. 4, controls SA–8, SA–10, 

SA–11, available at http://nvlpubs.nist.gov/

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf; NIST SP 800–64 Rev. 2, Security 

Considerations in the System Development Life 

Cycle (‘‘NIST SP 800–64 Rev. 2’’), at 26–27, 

available at http://csrc.nist.gov/publications/

nistpubs/800-64-Rev2/SP800-64-Revision2.pdf; 

FFIEC, Development and Acquisition IT 

Examination Handbook, at 8–9, and Objective 9, at 

A–6 to A–7, available at http://ithandbook.ffiec.gov/ 

ITBooklets/FFIEC_ITBooklet_Developmentand

Acquisition.pdf. 

96 Id. at 47–48. 

97NIST SP 800–53 Rev. 4, controls SA–9, SA–12, 

available at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf; FFIEC, 

Outsourcing Technology Services IT Examination 

Handbook, at 2, available at http://ithandbook.ffiec.

gov/ITBooklets/F FFIEC_ITBooklet_Outsourcing

TechnologyServices.pdf. 

98NIST SP 800–53 Rev. 4, controls AT–3, SA–11, 

available at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf. 

99NIST SP 800–53 Rev. 4, Physical and 

Environmental Protection (PE) control family, 

available at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf; FFIEC, 

Operations IT Examination Handbook, at 15–18, 

available at http://ithandbook.ffiec.gov/ITBooklets/

FFIEC_ITBooklet_Operations.pdf. 

100See § 38.1051(b) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (1) Risk analysis 

and oversight program (for SEFs); § 49.24(c) (for 

SDRs). 

101See § 38.1051(h) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (2) Testing (for 

SEFs); § 49.24(j) (for SDRs). 

102See § 38.1051(i) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (3) Coordination 

(for SEFs); § 49.24(k) (for SDRs). 

103Regarding following best practices, see 

proposed rule § 38.1051(b) (for DCMs); § 37.1401(b) 

(for SEFs); and § 49.24(c) (for SDRs). Regarding 

tester independence, see proposed rules 

§§ 38.1051(h)(2)(iv), (3)(i)(C), (3)(ii)(B), (4)(iii), 

(5)(iv), and (6)(ii) (for DCMs); §§ 37.1401(h)(2)(i), 

(3)(i)(A), (4)(i), (5)(iii), and (6)(i) (for SEFs); and 

§§ 49.24(j)(2)(iii), (3)(i)(B), (4)(ii), (5)(iv), and (6)(ii) 

(for SDRs). Regarding BC–DR plan and plan testing 

coordination, see proposed rule § 38.1051(i) (for 

DCMs); § 37.1401(i) (for SEFs); and § 49.24(k) (for 

SDRs). 

effective system safeguards in today’s 

cybersecurity threat environment. 

5. Systems Operations 

As set out in the proposed rule, this 

category of risk analysis and oversight 

includes (without limitation) each of the 

following elements: 

• System maintenance.91

• Configuration management (e.g., 

baseline configuration, configuration 

change and patch management, least 

functionality, inventory of authorized 

and unauthorized devices and 

software).92

• Event and problem response and 

management.93

It also includes any other elements of 

system operations included in generally 

accepted best practices. All of these 

important aspects of systems operations 

are grounded in generally accepted 

standards and best practices, for 

example those cited in the footnotes for 

each aspect given above. The 

Commission believes that systems 

operations programs that address each 

of these aspects are essential to 

maintaining effective system safeguards 

in today’s cybersecurity threat 

environment. 

6. Systems Development and Quality 

Assurance 

As set out in the proposed rule, this 

category of risk analysis and oversight 

includes (without limitation) each of the 

following elements: 

• Requirements development.94

• Pre-production and regression 

testing.95

• Change management procedures 

and approvals.96

• Outsourcing and vendor 

management.97

• Training in secure coding 

practices.98

It also includes any other elements of 

systems development and quality 

assurance included in generally 

accepted best practices. All of these 

important aspects of systems 

development and quality assurance are 

grounded in generally accepted 

standards and best practices, such as the 

examples cited in the footnotes for each 

aspect given above. The Commission 

believes that systems development and 

quality assurance programs that address 

each of these aspects are essential to 

maintaining effective system safeguards 

in today’s cybersecurity threat 

environment. 

7. Physical Security and Environmental 

Controls. 

As stated in the proposed rule, this 

category of risk analysis and oversight 

includes (without limitation) each of the 

following elements: 99

• Physical access and monitoring. 

• Power, telecommunication, 

environmental controls. 

• Fire protection. 

It also includes any other elements of 

physical security and environmental 

controls included in generally accepted 

best practices. All of these important 

aspects of physical security and 

environmental controls are grounded in 

generally accepted standards and best 

practices, such as the examples cited in 

the footnote given above. The 

Commission believes that physical 

security and environmental controls 

programs that address each of these 

aspects are essential to maintaining 

effective system safeguards in today’s 

cybersecurity threat environment. 

C. Requirements To Follow Best 

Practices, Ensure Testing Independence, 

and Coordinate BC–DR Plans 

The Commission’s current regulations 

for DCMs and SDRs and its guidance for 

SEFs provide that such entities should 

follow best practices in addressing the 

categories which their programs of risk 

analysis and oversight are required to 

include.100 They provide that such 

entities should ensure that their system 

safeguards testing, whether conducted 

by contractors or employees, is 

conducted by independent professionals 

(i.e., persons not responsible for 

development or operation of the systems 

or capabilities being tested).101 They 

further provide that such entities should 

coordinate their BC–DR plans with the 

BC–DR plans of market participants and 

essential service providers.102

In this NPRM, the Commission is 

proposing to make these three 

provisions mandatory for all DCMs, 

SEFs, and SDRs. The proposed rule 

provisions reflect this at appropriate 

points.103 Making these provisions 

mandatory will align the system 

safeguards rules for DCMs, SEFs, and 

SDRs with the Commission’s system 

safeguards rules for DCOs, which 

already contain mandatory provisions in 

these respects. The Commission 

believes that in today’s cybersecurity 

threat environment (discussed above), 

following generally accepted standards 

and best practices, ensuring tester 

independence, and coordinating BC–DR 

plans appropriately are essential to 

adequate system safeguards and cyber 

resiliency for DCMs, SEFs, and SDRs, as 

well as for DCOs. For this reason, the 

Commission believes that making these 

provisions mandatory will benefit 

DCMs, SEFs, and SDRs, their market 

participants and customers, and the 

public interest. The Commission 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80147 

104NIST SP 800–61 Rev. 2, at 8, available at 

http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-61r2.pdf. 

105NIST SP 800–34 Rev. 1, at 8, available at 

http://csrc.nist.gov/publications/nistpubs/800-34- 

rev1/sp800-34-rev1_errata-Nov11-2010.pdf. 

106 17 CFR 38.1051(g) and (h) (for DCMs); 17 CFR 

37.1401(f) and (g) (for SEFs); 17 CFR 49.24(i) and 

(j) (for SDRs). 

107 17 CFR 1.31; see also 17 CFR 38.1051(g) and 

(h); 17 CFR 37.1401(f) and (g); 17 CFR 49.24(i) and 

(j). 

108CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

109 Id. 

110 17 CFR 38.1051(h) (for DCMs); 17 CFR 

37.1401(g) (for SEFs); 17 CFR 49.24(j) (for SDRs). 

111The Commission’s existing rules and guidance 

provide that a DCM’s, SEF’s, or SDR’s entire 

program of risk analysis and oversight, which 

includes testing, should be based on generally 

accepted standards and best practices with respect 

to the development, operation, reliability, security, 

and capacity of automated systems. See 17 CFR 

38.1051(h) (for DCMs); Appendix A to Part 37, Core 

Principle 14 of Section 5h of the Act—System 

Safeguards (a) Guidance (1) Risk analysis and 

oversight program (for SEFs); 17 CFR 49.24(j) (for 

SDRs). Each of the types of testing addressed in this 

NPRM—vulnerability testing, penetration testing, 

controls testing, security incident response plan 

testing, and enterprise technology risk assessment— 

has been a generally recognized best practice for 

system safeguards since before the testing 

requirements of the Act and the current regulations 

were adopted. The current system safeguards 

provisions of the CEA and the Commission’s 

regulations became effective in August 2012. 

Generally accepted best practices called for each 

type of testing specified in the proposed rule well 

before that date, as shown in the following 

examples. Regarding all five types of testing, see, 

e.g., NIST SP 800–53A, Rev. 1, Guide for Assessing 

the Security Controls in Federal Information 

Systems and Organizations (‘‘NIST 800–53A 

Rev.1’’), at E1, F67, F230, F148, and F226, June 

2010, available at 

http://csrc.nist.gov/publications/nistpubs/800-53Arev1/sp800-53A-rev1-final.pdf. Regarding 

vulnerability testing, see, e.g., NIST SP 800–53A 

Rev. 1, at F67, June 2010, available at 

http://csrc.nist.gov/publications/nistpubs/800-53Arev1/sp800-53A-rev1-final.pdf; and NIST SP 800– 

115, Technical Guide to Information Security 

Testing and Assessment, at 5–2, September 2008, 

available at 

http://csrc.nist.gov/publications/nistpubs/800-115/ 

SP800-115.pdf. Regarding penetration testing, see, 

e.g., NIST Special Publication (‘‘SP’’) 800–53A, Rev. 

1, at E1, June 2010, available at: http://csc.nist.gov/ 

publications/nistpubs/800-53A-rev1/sp800-53Arev1-final.pdf; and NIST 800–115, at 4–4, 

Continued 

understands that most DCMs, SEFs, and 

SDRs have been following the 

provisions of the current regulations 

and guidance in these respects, and thus 

already meet these proposed 

requirements. 

D. Updating of Business ContinuityDisaster Recovery Plans and Emergency 

Procedures 

The Commission is proposing 

amendment of the current system 

safeguards rules requiring DCMs, SEFs, 

and SDRs to maintain a business 

continuity-disaster recovery plan and 

emergency procedures, by adding a 

requirement for such plans and 

procedures to be updated as frequently 

as required by appropriate risk analysis, 

but at a minimum at least annually. 

Updating such plans and procedures at 

least annually is a best practice. NIST 

standards provide that once an 

organization has developed a BC–DR 

plan, ‘‘the organization should 

implement the plan and review it at 

least annually to ensure the organization 

is following the roadmap for maturing 

the capability and fulfilling their [sic] 

goals for incident response.’’ 104 NIST 

also states that information systems 

contingency plans (‘‘ISCPs’’) ‘‘should be 

reviewed for accuracy and completeness 

at least annually, as well as upon 

significant changes to any element of 

the ISCP, system, mission/business 

processes supported by the system, or 

resources used for recovery 

procedures.’’ 105

As noted previously, current 

Commission system safeguards 

regulations and guidance provide that 

all DCMs, SEFs, and SDRs should 

follow best practices in their required 

programs of risk analysis and oversight. 

The Commission understands that many 

DCMs, SEFs, and SDRs currently update 

their BC–DR plans and emergency 

procedures at least annually. In light of 

these facts, the Commission believes 

that the proposed requirement for 

updating such plans and procedures as 

often as indicated by appropriate risk 

analysis, and at a minimum at least 

annually, may not impose substantial 

additional burdens or costs on DCMs, 

SEFs, or SDRs. 

E. System Safeguards-Related Books 

and Records Obligations 

The Commission’s current system 

safeguards rules for all DCMs, SEFs, and 

SDRs contain a provision addressing 

required production of system 

safeguards-related documents to the 

Commission on request.106 The 

proposed rule includes a provision 

amending these document production 

provisions, to further clarify 

requirements for document production 

by all DCMs, SEFs, and SDRs relating to 

system safeguards. The proposed 

provision would require each DCM, 

SEF, and SDR to provide to the 

Commission, promptly on the request of 

Commission staff: Current copies of its 

BC–DR plans and other emergency 

procedures, updated at a frequency 

determined by appropriate risk analysis 

but at a minimum no less than annually; 

all assessments of its operational risks 

or system safeguards-related controls; 

all reports concerning system safeguards 

testing and assessment required by the 

Act or Commission regulations; and all 

other documents requested by 

Commission staff in connection with 

Commission oversight of system 

safeguards. 

As noted in the text of the proposed 

rule, production of all such books and 

records is already required by the Act 

and Commission regulations, notably by 

Commission regulation § 1.31.107 No 

additional cost or burden is created by 

this provision. This section is included 

in the proposed rule solely to provide 

additional clarity to DCMs, SEFs, and 

SDRs concerning their statutory and 

regulatory obligation to produce all such 

system safeguards-related documents 

promptly upon request by Commission 

staff. 

F. Cybersecurity Testing Requirements 

for DCMs, SEFs, and SDRs 

1. Clarification of Existing Testing 

Requirements for All DCMs, SEFs, and 

SDRs 

The Act requires each DCM, SEF, and 

SDR to develop and maintain a program 

of system safeguards-related risk 

analysis and oversight to identify and 

minimize sources of operational risk.108

The Act mandates that in this 

connection each DCM, SEF and SDR 

must develop and maintain automated 

systems that are reliable, secure, and 

have adequate scalable capacity, and 

must ensure system reliability, security, 

and capacity through appropriate 

controls and procedures.109

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.110

In this NPRM, as discussed in detail 

below, the Commission proposes to 

clarify this system safeguards and 

cybersecurity testing requirement, by 

specifying and defining five types of 

system safeguards testing that a DCM, 

SEF, or SDR necessarily must perform to 

fulfill the requirement. The Commission 

believes, as the generally accepted 

standards and best practices noted in 

this NPRM make clear, that it would be 

essentially impossible for a DCM, SEF, 

or SDR to fulfill its existing obligation 

to conduct testing sufficient to ensure 

the reliability, security, and capacity of 

its automated systems without 

conducting each type of testing 

addressed by the proposed rule. Each of 

these types of testing is a generally 

recognized best practice for system 

safeguards.111 For these reasons, the 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80148 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

September 2008, available at: http://csrc.nist.gov/ 

publications/nistpubs/800-115/SP800-115.pdf. 

Regarding controls testing, see, e.g., NIST 800–53A, 

Rev. 1, at 13 and Appendix F1, June 2010, available 

at http://csrc.nist.gov/publications/nistpubs/800- 

53A-rev1/sp800-53A-rev1-final.pdf. Regarding 

security incident response plan testing, see, e.g., 

NIST 800–53A, Rev. 1, at F148, June 2010, available 

at http://csrc.nist.gov/publications/nistpubs/800- 

53A-rev1/sp800-53A-rev1-final.pdf. Regarding 

enterprise technology risk assessment, see, e.g., 

NIST 800–53A, Rev.1, at F226, June 2010, available 

at http://csrc.nist.gov/publications/nistpubs/800- 

53A-rev1/sp800-53A-rev1-final.pdf. 

112See discussion above concerning the need for 

cybersecurity testing. 

113 Id. 

114These considerations do not apply to SDRs. 

Each SDR contains reported swap data that 

constitutes a unique part of the total picture of the 

entire swap market that the Dodd-Frank Wall Street 

Reform and Consumer Protection Act, Pub. L. 111– 

203, 124 Stat. 1376 (2010) (‘‘Dodd-Frank Act’’) 

requires the Commission to have. Therefore, the 

highest level of system safeguards protection must 

be required for all SDRs. The Commission also 

notes that, because the Commission is proposing a 

parallel cybersecurity testing rule that would cover 

all DCOs, a non-covered DCM that shares common 

ownership and automated systems with a DCO 

would in practice fulfill the testing frequency and 

independent contractor testing requirements 

proposed for covered DCMs, by virtue of sharing 

automated systems and system safeguards with the 

DCO. 

provisions of the proposed rule calling 

for each DCM, SEF, and SDR to conduct 

each of these types of testing and 

assessment clarify the testing 

requirements of the existing system 

safeguards rules for DCMs, SEFs, and 

SDRs; they do not impose new 

requirements. Providing this 

clarification of the testing provisions of 

the existing system safeguards rules is a 

primary purpose of this proposed rule. 

The Commission’s clarification of 

existing testing requirements for DCMs, 

SEFs, and SDRs by specifying and 

defining five types of cybersecurity 

testing essential to fulfilling those 

testing requirements is designed to set 

out high-level, minimum requirements 

for these types of testing, with the 

expectation that the particular ways in 

which DCMs, SEFs, and SDRs conduct 

such testing may change as accepted 

standards and industry best practices 

develop over time and are reflected in 

the DCM’s, SEF’s, or SDR’s risk analysis. 

This parallels the inclusion in the 

Commission’s existing system 

safeguards rules and guidance for 

DCMs, SEFs, and SDRs of provisions 

that call for those entities to follow 

generally accepted standards and best 

practices in their programs of risk 

analysis and oversight with respect to 

system safeguards. Those similarly highlevel provisions were also designed to 

allow DCMs, SEFs, and SDRs flexibility 

in adapting their programs to current 

industry best practices, which the 

Commission recognized and continues 

to recognize will evolve over time. 

2. New Minimum Testing Frequency 

and Independent Contractor Testing 

Requirements for Covered DCMs and 

All SDRs 

In this NPRM, as discussed in detail 

below, the Commission is also 

proposing that covered DCMs (as 

defined) and all SDRs would be subject 

to new minimum testing frequency 

requirements with respect to each type 

of system safeguards testing included in 

the clarification of the system 

safeguards testing requirement in the 

Commission’s existing system 

safeguards rules. To strengthen the 

objectivity and reliability of the testing, 

assessment, and information available to 

the Commission regarding covered DCM 

and SDR system safeguards, the 

Commission is also proposing that for 

certain types of testing, covered DCMs 

and SDRs would be subject to new 

independent contractor testing 

requirements. The Commission believes 

that in light of the current cyber threat 

environment described above, the 

minimum frequency requirements being 

proposed are necessary and appropriate, 

and will give additional clarity 

concerning what is required in this 

respect. As discussed above, and 

discussed in detail below, the proposed 

minimum frequency requirements are 

all grounded in generally accepted 

standards and best practices.112 Best 

practices also call for testing by both 

entity employees and independent 

contractors as a necessary means of 

ensuring the effectiveness of 

cybersecurity testing and of the entity’s 

program of risk analysis and 

oversight.113

The Commission believes that the 

minimum testing frequency and 

independent contractor testing 

requirements in the proposed rule 

should be applied to DCMs whose 

annual total trading volume is five 

percent or more of the annual total 

trading volume of all DCMs regulated by 

the Commission, as well as to all SDRs. 

This would give DCMs that have less 

than five percent of the annual total 

trading volume of all DCMs more 

flexibility regarding the testing they 

must conduct. As a matter of policy, the 

Commission believes it is appropriate to 

reduce possible costs and burdens for 

smaller entities when it is possible to do 

so consistent with achieving the 

fundamental goals of the Act and 

Commission rules. Accordingly, the 

Commission believes that applying the 

minimum frequency and independent 

contractor requirements in this 

proposed rule only to DCMs whose 

annual volume is five percent or more 

of the total annual volume of all 

regulated DCMs, and to SDRs, would be 

appropriate, in light of the fact that 

smaller DCMs will still be required to 

conduct testing of all the types clarified 

in the proposed rule as essential to 

fulfilling the testing requirements of the 

existing DCM system safeguards 

rules.114

To give effect to this concept, the 

proposed rule would make this five 

percent volume threshold the basis for 

its definition of a ‘‘covered designated 

contract market,’’ and would require all 

DCMs to report their annual total 

trading volume to the Commission each 

year, as discussed below in section H. 

The proposed rule defines ‘‘annual total 

trading volume’’ as the total number of 

all contracts traded on or pursuant to 

the rules of a designated contract 

market. Under the proposed rule, a DCM 

would become a covered DCM, and thus 

become subject to the proposed testing 

frequency and independent contractor 

testing requirements, if it meets the five 

percent volume threshold with respect 

to calendar year 2015 or any calendar 

year thereafter. 

It is possible that a DCM which has 

previously become a covered DCM 

subject to these requirements by 

meeting the five percent volume 

threshold could cease to meet the 

definition of a covered DCM if its 

annual total trading volume later fell 

below the five percent volume 

threshold. The proposed rule’s 

frequency requirements for controls 

testing and for independent contractor 

testing of key controls specify that such 

testing must be performed no less 

frequently than every two years, the 

longest minimum frequency 

requirement included in the proposed 

rule. The Commission believes that a 

DCM which has become a covered DCM 

should complete an entire cycle of the 

testing required of covered DCMs before 

it ceases to be subject to those 

requirements by virtue of its annual 

total trading volume falling below the 

five percent threshold. Accordingly, the 

proposed rule’s definition of ‘‘covered 

designated contract market’’ also 

specifies that such a DCM would cease 

to be a covered DCM when it has fallen 

below the five percent volume threshold 

for two consecutive years. 

3. Vulnerability Testing 

a. Need for Vulnerability Testing 

Testing to identify cyber and 

automated system vulnerabilities is a 

significant component of a DCM’s, 

SEF’s, or SDR’s program of risk analysis 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80149 

115Council on Cybersecurity, CSC 4, Continuous 

Vulnerability Assessment and Remediation: Why Is 

This Control Critical? (emphasis added), available at 

http://www.counciloncybersecurity.org/criticalcontrols/. 

116CFTC Roundtable, at 95–96. 

117 Id. 

118 Id. 

119NIST SP 800–53 Rev. 4, control RA–5 

Vulnerability Scanning, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 120 Id. 121 Id. 122 Id. 123Council on Cybersecurity, CSC 4, Continuous 

Vulnerability Assessment and Remediation, 

available at http://www.counciloncybersecurity.org/ 

critical-controls/. 124 Id. at CSC 4–1. 125Security Standards Council, Payment Card 

Industry Data Security Standards (v.3.1, 2015) 

(‘‘PCI DSS’’), Requirement 11: Regularly test 

security systems and processes, available at 

https://www.pcisecuritystandards.org/ 

security_standards/index.php. 

126 Id., Requirement 11.2. 

127See NIST SP 800–53 Rev. 4, control RA–5, 

available at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf. 

128See, e.g., NIST SP 800–115, Technical Guide 

to Information Security Testing and Assessment 

(2008) (‘‘NIST 800–115’’), at 2–4, available at http:// 

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf, noting that ‘‘[e]xternal testing often begins 

with reconnaissance techniques that search public 

registration data, Domain Name System (DNS) 

server information, newsgroup postings, and other 

publicly available information to collect 

information (e.g., system names, Internet Protocol 

[IP] addresses, operating systems, technical points 

of contact) that may help the assessor to identify 

vulnerabilities.’’ 

129See, e.g., SANS Institute, Penetration Testing: 

Assessing Your Overall Security Before Attackers 

Do (June 2006), at 7, available at https://www.sans.

org/reading-room/whitepapers/analyst/penetrationtesting-assessing-security-attackers-34635, noting: 

‘‘A wide variety of tools may be used in penetration 

testing. These tools are of two main types; 

reconnaissance or vulnerability testing tools and 

exploitation tools. While penetration testing is more 

directly tied to the exploitation tools, the initial 

scanning and reconnaissance is often done using 

less intrusive tools.’’ 

130See, PCI DSS, at 94, available at https://www.

pcisecuritystandards.org/security_standards/

index.php, defining a vulnerability scan as ‘‘a 

combination of automated or manual tools, 

techniques, and/or methods run against external 

and internal network devices and servers, designed 

to expose potential vulnerabilities that could be 

found and exploited by malicious individuals.’’ See 

also NIST SP 800–115, supra note 111, available at 

Continued 

and oversight to identify and minimize 

sources of operational risk, and a 

necessary prerequisite for remediating 

vulnerabilities, minimizing exposure to 

attackers, and enhancing automated 

system resilience in the face of cyber 

threats. The Council on Cybersecurity 

explains the need for ongoing 

vulnerability testing as follows: 

Cyber defenders must operate in a constant 

stream of new information: Software updates, 

patches, security advisories, threat bulletins, 

etc. Understanding and managing 

vulnerabilities has become a continuous 

activity, requiring significant time, attention, 

and resources. 

Attackers have access to the same 

information, and can take advantage of gaps 

between the appearance of new knowledge 

and remediation. For example, when new 

vulnerabilities are reported by researchers, a 

race starts among all parties, including: 

Attackers (to ‘‘weaponize’’, deploy an attack, 

exploit); vendors (to develop, deploy patches 

or signatures and updates), and defenders (to 

assess risk, regression-test patches, install). 

Organizations that do not scan for 

vulnerabilities and proactively address 

discovered flaws face a significant likelihood 

of having their computer systems 

compromised. Defenders face particular 

challenges in scaling remediation across an 

entire enterprise, and prioritizing actions 

with conflicting priorities, and sometimesuncertain side effects.115

Vulnerability testing is essential to 

cyber resilience.116 CFTC Roundtable 

participants noted that for a financial 

sector institution, vulnerability testing 

will scan and assess the security 

controls of the entity’s automated 

systems, on an ongoing basis, to ensure 

that they are in place and operating 

properly.117 In the automated system 

context, such testing will include 

ongoing review that includes automated 

scanning, to ensure that timely software 

updates and patches have been made for 

operating systems and applications, that 

network components are configured 

properly, and that no known 

vulnerabilities are present in operating 

systems and application software.118

b. Best Practices Call for Vulnerability 

Testing 

Conducting ongoing vulnerability 

testing, including automated scanning, 

is a best practice with respect to 

cybersecurity. NIST standards call for 

organizations to scan for automated 

system vulnerabilities both on a regular 

and ongoing basis and when new 

vulnerabilities potentially affecting their 

systems are identified and reported.119

NIST adds that organizations should 

employ vulnerability scanning tools and 

techniques that automate parts of the 

vulnerability management process, with 

respect to enumerating platforms, 

software flaws, and improper 

configurations; formatting checklists 

and test procedures, and measuring 

vulnerability impacts.120 NIST states 

that vulnerability scans should address, 

for example: Patch levels; functions, 

ports, protocols, and services that 

should not be accessible to users or 

devices; and improperly configured or 

incorrectly operating information flow 

controls.121 NIST also calls for the 

organization to remediate vulnerabilities 

identified by vulnerability testing, in 

accordance with its assessments of 

risk.122

The Council on CyberSecurity’s 

Critical Security Controls call for 

organizations to ‘‘continuously acquire, 

assess, and take action on new 

information in order to identify 

vulnerabilities, remediate, and 

minimize the window of opportunity for 

attackers.’’ 123 The Council states that 

organizations should use vulnerability 

scanning tools that look for both codebased and configuration-based 

vulnerabilities, run automated 

vulnerability scans against all systems 

on the network at a minimum on a 

weekly basis, and deliver to 

management prioritized lists of the most 

critical vulnerabilities found.124

The Data Security Standards (‘‘DSS’’) 

of the Payment Card Industry (‘‘PCI’’) 

Security Standards Council note that 

‘‘[v]ulnerabilities are being discovered 

continually by malicious individuals 

and researchers, and being introduced 

by new software,’’ and accordingly 

provide that ‘‘[s]ystem components, 

processes, and custom software should 

be tested frequently to ensure security 

controls continue to reflect a changing 

environment.’’ 125 These standards call 

for running internal and external 

network vulnerability scans both 

regularly and after any significant 

change in the network.126

c. Proposed Vulnerability Testing 

Definitions and Related Provisions 

The Commission is proposing to 

clarify the existing testing requirements 

for all DCMs, all SEFs, and all SDRs by 

specifying vulnerability testing as an 

essential means of fulfilling those 

requirements, and defining it as testing 

of a DCM’s, SEF’s, or SDR’s automated 

systems to determine what information 

may be discoverable through a 

reconnaissance analysis of those 

systems and what vulnerabilities may be 

present on those systems. This 

definition is consistent with NIST 

standards for such testing.127 For 

purposes of this definition, the term 

‘‘reconnaissance analysis’’ is used to 

combine various aspects of vulnerability 

testing.128 The proposed definition 

deliberately refers broadly to 

vulnerability testing in order to avoid 

prescribing use of any particular 

technology or tools, because 

vulnerability assessments may not 

always be automated, and technology 

may change.129

The proposed rule would require that 

vulnerability testing include automated 

vulnerability scanning, as well as an 

analysis of the test results to identify 

and prioritize all vulnerabilities that 

require remediation.130 Best practices 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80150 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

http://csrc.nist.gov/publications/nistpubs/800-115/ 

SP800-115.pdf; noting that testing techniques that 

include vulnerability scanning ‘‘. . . can identify 

systems, ports, services, and potential 

vulnerabilities, and may be performed manually but 

are generally performed using automated tools.’’ 

131NIST SP 800–39, at 47–48, available at 

http://csrc.nist.gov/publications/nistpubs/800-39/

SP800-39-final.pdf. 

132CFTC Roundtable, at 170–171. 

133The PCI Monitor, published by the PCI 

Security Standards Council, explains the 

differences between unauthenticated and 

authenticated vulnerability scanning, and the 

benefits of each type, as follows: [U]nauthenticated 

web application scan tests are conducted with no 

usernames and/or passwords as part of the test. 

Authenticated web application scan tests use 

usernames and passwords to simulate user activity 

on the Web site or system being tested. Essentially, 

unauthenticated scan testing is ‘‘logged-out testing’’ 

and authenticated scanning is ‘‘logged-in testing.’’ 

. . . Unauthenticated scan testing is typically much 

easier than authenticated testing; it can be 

performed with basic tools and doesn’t require a 

great deal of technical expertise or understanding 

of the systems, Web pages or workflows being 

tested. Unauthenticated tests are also much quicker 

and can be effective in detecting recognizable 

vulnerabilities without investing a great deal of 

time and resources. However, unauthenticated 

testing alone is not an effective method of 

simulating targeted attacks. The results may be 

limited, producing a false sense of assurance that 

the systems have been thoroughly assessed. . . . 

[A]uthenticated testing is more thorough since user 

interaction and functionality . . . can be more 

accurately simulated. Performing authenticated 

testing does require a broader and deeper skill set 

and should only be performed by qualified, 

experienced professionals. . . . Additionally, since 

authenticated testing often includes manual 

techniques, the amount of time required to perform 

such tests can increase significantly. . . . As a 

general guideline, if the desire is to simulate what 

users on the system are able to do, then 

authenticated testing is the most effective approach. 

If the intent is to quickly identify the highest risks 

that any user or tool could exploit, then 

unauthenticated testing may suffice. Once the 

unauthenticated vulnerabilities are identified and 

remediated, then authenticated testing should be 

considered to achieve a more comprehensive 

assessment. 

PCI Monitor, Vol. 2, Issue 26 (June 25, 2014), 

available at http://training.pcisecuritystandards.

org/the-pci-monitor-weekly-news-updates-andinsights-from-pci-ssc2?ecid=ACsprvuuirRbrU3v

Dlk76s_ngGKJKEYlvaBJzvvUMldZv4KKh6V1guIK

OR5VLTNfAqPQ_Gmox3zO&utm_campaign=

Monitor&utm_source=hs_email&utm_medium=

email&utm_content=13292865&_hsenc=p2ANqtz_

LIkkHURyUmyq1p2OxB39R5nOpRh1XHE_jW6w

CC6EEUAow15E7AuExcIGwdYxyh_6YNxVvKorc

urk6r90E3d7dG71fbw&_hsmi=13292865%20-%20

web. 

134See PCI DSS, supra note 125, App. B at 112, 

available at https://www.pcisecuritystandards.org/

security_standards/index.php: ‘‘Compensating 

controls may be considered . . . when an entity 

cannot meet a requirement explicitly as stated, due 

to legitimate technical or documented business 

constraints, but has sufficiently mitigated the risk 

associated with the requirement through 

implementation of other, or compensating, 

controls.’’ 

135FFIEC, Information Security IT Examination 

Handbook, at 82, available at http://ithandbook.

ffiec.gov/ITBooklets/FFIEC_ITBooklet_Information

Security.pdf. 

136See NIST SP 800–39, at 47–48, available at 

http://csrc.nist.gov/publications/nistpubs/800-39/

SP800-39-final.pdf; FFIEC, Information Security IT 

Examination Handbook, at 82, available at http:// 

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

137 Id. 

138PCI DSS, Requirement 11.2, available at 

https://www.pcisecuritystandards.org/security_

standards/index.php. 

139Council on CyberSecurity, CSC 4, Continuous 

Vulnerability Assessment and Remediation, 

available at http://www.counciloncybersecurity.org/ 

critical-controls/. 140The Commission understands that most 

covered DCMs and SDRs currently conduct 

vulnerability testing on at least a quarterly basis and 

in many cases on a continuous basis. 141CFTC Roundtable, at 88. 142 Id. at 88–89. 143 Id. at 103–104. 144 Id. at 177. 

note that in most situations, 

vulnerability monitoring is most 

efficient and cost-effective when 

automation is used.131 Participants in 

the CFTC Roundtable agreed that 

automated vulnerability scanning 

provides important benefits.132 Where 

indicated by appropriate risk analysis, 

automated scanning would be required 

to be conducted on an authenticated 

basis (i.e., using log-in credentials).133

Where automated scans are 

unauthenticated (i.e., conducted 

without using usernames or passwords), 

effective compensating controls would 

be required.134

The proposed rule would require all 

DCMs, SEFs, and SDRs to conduct 

vulnerability testing at a frequency 

determined by an appropriate risk 

analysis. Testing as often as indicated 

by appropriate risk analysis is a best 

practice. For example, the FFIEC states 

that ‘‘[t]he frequency of testing should 

be determined by the institution’s risk 

assessment.’’ 135 Best practices call for 

risk assessments to include 

consideration of a number of important 

factors in this regard, including, for 

example, the frequency and extent of 

changes in the organization’s automated 

systems and operating environment; the 

potential impact if risks revealed by 

testing are not addressed appropriately; 

the degree to which the relevant threat 

environment or potential attacker 

profiles and techniques are changing; 

and the results of other testing.136

Frequency appropriate to risk analysis 

can also vary depending on the type of 

monitoring involved; for example, with 

whether automated monitoring or 

procedural testing is being 

conducted.137

d. Minimum Vulnerability Testing 

Frequency Requirements for Covered 

DCMs and SDRs 

The proposed rule would require 

covered DCMs and SDRs to conduct 

vulnerability testing no less frequently 

than quarterly. Best practices support 

this requirement. For example, PCI DSS 

standards provide that entities should 

run internal and external network 

vulnerability scans ‘‘at least quarterly,’’ 

as well as after any significant network 

changes, new system component 

installations, firewall modifications, or 

product upgrades.138 The Council on 

CyberSecurity calls for entities to 

‘‘continuously acquire, assess, and take 

action on new information in order to 

identify vulnerabilities.’’ 139 In light of 

these best practices and the current 

level of cyber threat to the financial 

sector discussed above, the Commission 

believes that the proposed rule 

provisions regarding vulnerability 

testing frequency are appropriate in 

today’s cybersecurity environment.140

e. Independent Contractor Vulnerability 

Testing Requirements for Covered DCMs 

and All SDRs 

The proposed rule would require 

covered DCMs and SDRs to engage 

independent contractors to conduct two 

of the required quarterly vulnerability 

tests each year, while permitting 

covered DCMs and SDRs to conduct 

other vulnerability testing using 

employees not responsible for 

development or operation of the systems 

or capabilities being tested. 

Participants in the CFTC Roundtable 

agreed that important benefits are 

provided when a testing program 

includes both testing by independent 

contractors and testing by entity 

employees not responsible for building 

or operating the system being tested. As 

one participant noted, ‘‘[t]here are 

advantages to both, but neither can 

stand alone.’’ 141 Much testing needs to 

happen internally, but much also needs 

to be conducted from the viewpoint of 

an outsider, particularly where testing 

against the possible tactics or 

techniques of a particular threat actor is 

concerned.142 Third-party vendors offer 

specialized expertise concerning the 

latest threat intelligence, the latest 

attack vectors against the financial 

sector, and the recent experience of 

other entities with similar systems and 

similar vulnerabilities.143 One benefit 

offered by testing conducted by entity 

employees is that internal vulnerability 

testing and scanning can utilize 

viewpoints that the outside world 

would not have, based on intimate 

knowledge of the entity’s network and 

systems.144 Conversely, an additional 

benefit provided by independent 

contractor testing comes from the 

outsider’s different perspective, and his 

or her ability to look for things that 

entity employees may not have 

contemplated during the design or 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80151 

145 Id. at 171. 

146 Id. 

147NIST SP 800–115, at 6–6, available at http:// 

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf. NIST also notes that giving outsiders 

access to an organization’s systems can introduce 

additional risk, and recommends proper vetting and 

attention to contractual responsibility in this regard. 

148FFIEC, Information Security IT Examination 

Handbook, at 81, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

149 Id. 

150 ISACA, COBIT 5, Monitor, Evaluate and 

Assess (‘‘MEA’’) MEA02.05, Ensure that assurance 

providers are independent and qualified, available 

at https://cobitonline.isaca.org. 

151 Id. at 6. 

152 Id. 

153PCI DSS, Requirement 11, Regularly test 

security systems and processes, at 94–96, available 

at https://www.pcisecuritystandards.org/security_

standards/index.php. 

154See FFIEC, Information Security IT 

Examination Handbook, at 81, available at http:// 

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

155NIST SP 800–53 Rev. 4, App. B at B–17, 

available at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf. 

156 Id. at F–62, CA–8 Penetration Testing. 

157Council on Cybersecurity, CSC 20, Penetration 

Tests and Red Team Exercises: Why Is This Control 

Critical? available at http://www.counciloncyber

security.org/critical-controls/. 

operation of the system involved.145

One Roundtable participant observed 

that the vulnerability assessments 

which are the goal of vulnerability 

testing done by entity employees need 

to themselves be tested and validated by 

independent, external parties.146 In 

short, an overall testing program that 

includes both testing by independent 

contractors and testing by entity 

employee can offer complementary 

benefits. 

Regarding the benefits provided by 

independent contractor testing, NIST 

notes that: 

[E]ngaging third parties (e.g., auditors, 

contractor support staff) to conduct the 

assessment offers an independent view and 

approach that internal assessors may not be 

able to provide. Organizations may also use 

third parties to provide specific subject 

matter expertise that is not available 

internally.147

FFIEC states that testing by 

independent contractors provides 

credibility to test results.148 Where 

testing is conducted by entity 

employees, FFIEC calls for tests 

performed ‘‘by individuals who are also 

independent of the design, installation, 

maintenance, and operation of the 

tested system.’’ 149 In its COBIT 5 

framework, ISACA states that those 

performing system safeguards testing 

and assurance should be independent 

from the functions, groups, or 

organizational components being 

tested.150 With respect to system 

safeguards testing by internal auditors, 

FFIEC states that the auditors should 

have both independence and authority 

from the Board of Directors to access all 

records and staff necessary for their 

audits.151 It also states that they should 

not participate in activities that may 

compromise or appear to compromise 

their independence, such as preparing 

or developing the types of reports, 

procedures, or operational duties 

normally reviewed by auditors.152 The 

data security standards of the Payment 

Card Industry Security Standards 

Council call for conducting both 

internal and external vulnerability 

scans, with external scans performed by 

an approved vendor.153

Current Commission system 

safeguards rules leave to a DCM or SDR 

the choice of whether vulnerability 

testing or other system safeguards 

testing is conducted by independent 

contractors or entity employees not 

responsible for building or operating the 

systems being tested. The proposed 

requirement for some vulnerability 

testing to be performed by independent 

contractors is intended to ensure that 

covered DCM and SDR programs of risk 

analysis and oversight with respect to 

system safeguards include the benefits 

coming from a combination of testing by 

both entity employees and independent 

contractors, as discussed above. In light 

of the best practices and the current 

level of cyber threat to the financial 

sector discussed above, the Commission 

believes that the proposed rule 

provisions regarding vulnerability 

testing by independent contractors are 

appropriate in today’s cybersecurity 

environment. 

4. Penetration Testing 

a. Need for Penetration Testing 

Penetration testing to exploit cyber 

and automated system vulnerabilities, a 

testing type which complements 

vulnerability testing, is also a significant 

component of a DCM’s, SEF’s, or SDR’s 

program of risk analysis and oversight to 

identify and minimize sources of 

operational risk. Penetration tests go 

beyond the uncovering of an 

organization’s automated system 

vulnerabilities that vulnerability testing 

aims to achieve: They subject the system 

to real-world attacks by testing 

personnel, in order to identify both the 

extent to which an attacker could 

compromise the system before the 

organization detects and counters the 

attack, and the effectiveness of the 

organization’s response mechanisms.154

NIST defines penetration testing as ‘‘[a] 

test methodology in which assessors, 

typically working under specific 

constraints, attempt to circumvent or 

defeat the security features of an 

information system.’’ 155 NIST describes 

the benefits of penetration testing as 

follows: 

Penetration testing is a specialized type of 

assessment conducted on information 

systems or individual system components to 

identify vulnerabilities that could be 

exploited by adversaries. Such testing can be 

used to either validate vulnerabilities or 

determine the degree of resistance 

organizational information systems have to 

adversaries within a set of specified 

constraints (e.g., time, resources, and/or 

skills). Penetration testing attempts to 

duplicate the actions of adversaries in 

carrying out hostile cyber attacks against 

organizations and provides a more in-depth 

analysis of security-related weaknesses/

deficiencies.156

The Council on CyberSecurity 

explains the need for penetration testing 

as follows: 

Attackers often exploit the gap between 

good defensive designs and intentions and 

implementation or maintenance. . . . In 

addition, successful defense requires a 

comprehensive program of technical 

defenses, good policy and governance, and 

appropriate action by people. In a complex 

environment where technology is constantly 

evolving, and new attacker tradecraft appears 

regularly, organizations should periodically 

test their defenses to identify gaps and to 

assess their readiness. 

Penetration testing starts from the 

identification and assessment of 

vulnerabilities that can be identified in the 

enterprise. It complements this by designing 

and executing tests that demonstrate 

specifically how an adversary can either 

subvert the organization’s security goals (e.g., 

the protection of specific Intellectual 

Property) or achieve specific adversarial 

objectives (e.g., establishment of a covert 

Command and Control infrastructure). The 

result provides deeper insight, through 

demonstration, into the business risks of 

various vulnerabilities. 

[Penetration testing] exercises take a 

comprehensive approach at the full spectrum 

of organization policies, processes, and 

defenses in order to improve organizational 

readiness, improve training for defensive 

practitioners, and inspect current 

performance levels. Independent Red Teams 

can provide valuable and objective insights 

about the existence of vulnerabilities and the 

efficacy of defenses and mitigating controls 

already in place and even of those planned 

for future implementation.157

Anecdotally, one CFTC Roundtable 

participant characterized the need for 

penetration testing by stating that, ‘‘you 

will never know how strong your 

security is until you try to break it 

yourself and try to bypass it,’’ adding 

that ‘‘if you’re not testing to see how 

strong it is, I guarantee you, somebody 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80152 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

158 Id. at 96. 

159 Id. at 58–60. 

160Council on CyberSecurity, CSC 20–1, available 

at http://www.counciloncybersecurity.org/criticalcontrols/. 

161FINRA, Report on Cybersecurity Practices 

(February 2015), at 22, available at https://www.

finra.org/sites/default/files/p602363%20Report%20

on%20Cybersecurity%20Practices_0.pdf. 

162 Id. 

163NIST SP 800–53 Rev. 4, control CA-8 

Penetration Testing, available at http://

nvlpubs.nist.gov/nistpubs/SpecialPublications/

NIST.SP.800-53r4.pdf. 

164NIST SP 800–115, at 2–4 to 2–5, available at 

http://csrc.nist.gov/publications/nistpubs/800-115/

SP800-115.pdf. 

165 Id. See also, e.g., System Administration, 

Networking, and Security Institute (‘‘SANS’’), 

Penetration Testing in the Financial Services 

Industry (2010), at 17, available at https://

www.sans.org/reading-room/whitepapers/testing/

penetration-testing-financial-services-industry33314 (‘‘Penetration testing is essential given the 

context of high operational risk in the financial 

services industry.’’) 

166See discussion above concerning vulnerability 

testing. 

167The SEC’s Regulation System Compliance and 

Integrity (‘‘Regulation SCI’’), issued in final form in 

December 2014, also requires penetration testing by 

SCI entities, defined as including, among other 

things, national securities exchanges, alternative 

trading systems, and registered clearing agencies. It 

requires each SCI entity to conduct SCI reviews that 

include penetration testing at least every three 

years. The Commission’s proposed rule would 

require covered DCMs and SDRs to conduct 

penetration testing at a frequency determined by an 

appropriate risk analysis, but no less frequently 

than annually. In light of the multiple best practices 

cited above, and the importance of covered DCMs 

and SDRs to the national economy, the Commission 

believes that conducting penetration testing at least 

annually is appropriate. 

else is.’’ 158 Another Roundtable 

participant described the essential 

function of penetration testing as 

intruding into a network as stealthily as 

possible, mimicking the methodologies 

used by attackers, seeing whether and at 

what point the entity can detect the 

intrusion, and identifying gaps between 

the entity’s current defenses and 

attacker capabilities, with the goal of 

reducing the time needed to detect an 

intrusion from multiple days to 

milliseconds, and closing the gaps 

between attacker and defender 

capabilities.159

b. Best Practices Call for Both External 

and Internal Penetration Testing 

Best practices and standards provide 

that organizations should conduct two 

types of penetration testing: External 

and internal. Many best practices 

sources also describe the benefits of 

both types of penetration testing. The 

Council on CyberSecurity states that 

organizations should: 

Conduct regular external and internal 

penetration tests to identify vulnerabilities 

and attack vectors that can be used to exploit 

enterprise systems successfully. Penetration 

testing should occur from outside the 

network perimeter (i.e., the Internet or 

wireless frequencies around an organization) 

as well as from within its boundaries (i.e., on 

the internal network) to simulate both 

outsider and insider attacks.160

FINRA’s recent Report on 

Cybersecurity Practices provides a 

useful description of the benefits of 

penetration testing: 

Penetration Testing (also known as ‘‘Pen 

Testing’’) is an effective practice that 

simulates a real-world attack against a firm’s 

computer systems. The goal of a third-party 

penetration test is to get an attacker’s 

perspective on security weaknesses that a 

firm’s technology systems may exhibit. 

Penetration Tests are valuable for several 

reasons: 

• Determining the feasibility of a particular 

set of attack vectors; 

• identifying higher-risk vulnerabilities 

that result from a combination of lower-risk 

vulnerabilities exploited in a particular 

sequence; 

• identifying vulnerabilities that may be 

difficult or impossible to detect with 

automated network or application 

vulnerability scanning software; 

• assessing the magnitude of potential 

business and operational impacts of 

successful attacks; 

• testing the ability of network defenders 

to successfully detect and respond to the 

attack; and 

• providing evidence to support increased 

investments in security personnel and 

technology. 

Penetration Tests can take different forms 

depending on a firm’s specific objectives for 

the test. Each of these contributes in its own 

way to an overall defense-in-depth 

strategy.161

FINRA also describes the different 

benefits of external and internal 

penetration testing, and emphasizes the 

need for both types: 

External penetration testing is designed to 

test a firm’s systems as they are exposed to 

the outside world (typically via the Internet), 

while internal penetration testing is designed 

to test a firm’s systems’ resilience to the 

insider threat. An advanced persistent attack 

may involve an outsider gaining a 

progressively greater foothold in a firm’s 

environment, effectively becoming an insider 

in the process. For this reason, it is important 

to perform penetration testing against both 

external and internal interfaces and 

systems.162

NIST standards for system safeguards 

call for organizations to conduct 

penetration testing, and reference both 

external and internal testing.163 NIST 

describes the benefits of external 

penetration tests as follows: 

External security testing is conducted from 

outside the organization’s security perimeter. 

This offers the ability to view the 

environment’s security posture as it appears 

outside the security perimeter—usually as 

seen from the Internet—with the goal of 

revealing vulnerabilities that could be 

exploited by an external attacker.164

NIST notes that internal penetration 

tests offer different benefits, as follows: 

For internal security testing, assessors 

work from the internal network and assume 

the identity of a trusted insider or an attacker 

who has penetrated the perimeter defenses. 

This kind of testing can reveal vulnerabilities 

that could be exploited, and demonstrates the 

potential damage this type of attacker could 

cause. Internal security testing also focuses 

on system-level security and configuration— 

including application and service 

configuration, authentication, access control, 

and system hardening.165

c. Proposed Penetration Testing 

Definitions and Related Provisions 

The Commission is proposing to 

clarify the existing testing requirements 

for all DCMs, all SEFs, and all SDRs by 

specifying both external and internal 

penetration testing as essential to 

fulfilling those requirements, and 

defining both. External penetration 

testing would be defined as attempts to 

penetrate a DCM’s, SEF’s, or SDR’s 

automated systems or networks from 

outside their boundaries to identify and 

exploit vulnerabilities (including, but 

not limited to, methods for 

circumventing the security features of 

an application, system, or network). 

Internal penetration testing would be 

defined as attempts to penetrate a 

DCM’s, SEF’s, or SDR’s automated 

systems or networks from inside their 

boundaries to identify and exploit 

vulnerabilities (including, but not 

limited to, methods for circumventing 

the security features of an application, 

system, or network). These definitions 

are consistent with the standards and 

best practices discussed above. In light 

of the best practices, and the external 

and internal penetration testing benefits 

noted above, the Commission believes 

that such testing is important in the 

context of today’s cybersecurity threat 

environment. 

The proposed rule would require all 

DCMs, SEFs, and SDRs to conduct both 

external and internal penetration testing 

at a frequency determined by an 

appropriate risk analysis. As discussed 

above, testing as often as indicated by 

appropriate risk analysis is a best 

practice.166

d. Minimum Penetration Testing 

Frequency Requirements for Covered 

Dcms and Sdrs 

The proposed rule would require 

covered DCMs and SDRs to conduct 

both external and internal penetration 

testing no less frequently than 

annually.167 Best practices support this 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80153 

168The Commission understands that most 

covered DCMs (as defined) and most SDRs 

currently conduct external and internal penetration 

testing at least annually. 

169NIST, SP 800–115, Technical Guide to 

Information Security Testing and Assessment, 

Section 5.2.2, at 5–5, available at http://

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf. 

170FFIEC, Information Security IT Examination 

Handbook, at 82, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

171PCI DSS, Requirements 11.3.1 and 11.3.2. 

available at https://www.pcisecuritystandards.org/

documents/PCI_DSS_v3-1.pdf. 

172See discussion above concerning vulnerability 

testing. 

173NIST SP 800-115, at 6–6, available at http:// 

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf. NIST also notes that giving outsiders 

access to an organization’s systems can introduce 

additional risk, and recommends proper vetting and 

attention to contractual responsibility in this regard. 

174PCI DSS, Requirement 11, Regularly test 

security systems and processes, at 94–96, available 

at https://www.pcisecuritystandards.org/security_

standards/index.php. 

175CFTC Roundtable, at 88–89, 103–104, 171. 

176The Commission understands that most DCMs 

that would be covered by the proposed covered 

DCM definition, and most SDRs, currently have 

external penetration testing conducted by 

independent contractors at least annually. 

177 17 CFR 38.1050(a) (for DCMs); 17 CFR 

37.1400(a) (for SEFs); 17 CFR 49.24(a)(1) (for SDRs). 

178NIST SP 800–53 Rev. 4, at F–3, available at 

http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf; See also 

CFTC Roundtable, at 194–196. 

179NIST SP 800–53A Rev. 4, Assessing Security 

and Privacy Controls to Federal Information 

Systems and Organizations (‘‘NIST SP 800–53A 

Rev. 4’’), at 1, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

53Ar4.pdf. 

180 Id. at xi (Foreword). 

181NIST SP 800–53 Rev. 4, control CA–2 Security 

Assessments, available at http://nvlpubs.nist.gov/

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf. 

requirement.168 NIST calls for at least 

annual penetration testing of an 

organization’s network and systems.169

The FFIEC calls for independent 

penetration testing of high risk systems 

at least annually, and for quarterly 

testing and verification of the efficacy of 

firewall and access control defenses.170

Data security standards for the payment 

card industry provide that entities 

should perform both external and 

internal penetration testing ‘‘at least 

annually,’’ as well as after any 

significant network changes, new 

system component installations, firewall 

modifications, or product upgrades.171

e. Independent Contractor Penetration 

Testing Requirements for Covered 

DCMS and All SDRS 

The proposed rule would require 

covered DCMs and SDRs to engage 

independent contractors to conduct the 

required minimum of an annual 

external penetration test. It would allow 

covered DCMs and SDRs to have 

internal penetration testing, and any 

additional external penetration testing 

needed in light of appropriate risk 

analysis, conducted either by 

independent contractors or by entity 

employees who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

As noted above, best practices support 

having some testing conducted by 

independent contractors.172 NIST notes 

that: 

[E]ngaging third parties (e.g., auditors, 

contractor support staff) to conduct the 

assessment offers an independent view and 

approach that internal assessors may not be 

able to provide. Organizations may also use 

third parties to provide specific subject 

matter expertise that is not available 

internally.173

The data security standards of the 

Payment Card Industry Security 

Standards Council call for external 

testing to be performed by an approved 

vendor.174 Participants in the CFTC 

Roundtable agreed that important 

benefits are provided when a testing 

program includes testing by 

independent contractors, noting that 

vendor testing has particular value with 

respect to what external penetration 

does, namely test from the viewpoint of 

an outsider and against the current 

tactics, techniques, and threat vectors of 

current threat actors as revealed by 

current threat intelligence.175

Current Commission system 

safeguards rules leave to a DCM or SDR 

the choice of whether penetration 

testing or other system safeguards 

testing is conducted by independent 

contractors or entity employees not 

responsible for building or operation of 

the systems being tested. The proposed 

requirement for the required minimum 

annual external penetration testing to be 

performed by independent contractors 

is intended to ensure that covered DCM 

and SDR programs of risk analysis and 

oversight with respect to system 

safeguards include the benefits provided 

when independent contractors perform 

such testing. In light of the best 

practices and the current level of cyber 

threat to the financial sector discussed 

above, the Commission believes that the 

proposed rule provisions regarding 

external penetration testing by 

independent contractors are appropriate 

in today’s cybersecurity 

environment.176

5. Controls Testing 

a. Need for Controls Testing 

As defined in the proposed rule, 

controls are the safeguards or 

countermeasures used by a DCM, SEF, 

or SDR to protect the reliability, 

security, or capacity of its automated 

systems or the confidentiality, integrity, 

and availability of its data and 

information, so as to fulfill its statutory 

and regulatory responsibilities. Controls 

testing is defined as assessment of all of 

the DCM’s, SEF’s, or SDR’s system 

safeguards-related controls, to 

determine whether they are 

implemented correctly, are operating as 

intended, and are enabling the 

organization to meet system safeguards 

requirements. Regular, ongoing testing 

of all of an organization’s system 

safeguards-related controls for these 

purposes is a crucial part of the program 

of risk analysis and oversight required 

of all DCMs, SEFs, and SDRs by the Act 

and Commission regulations.177 As 

noted in NIST’s standards and best 

practices, there are three broad types of 

system safeguards-related controls, 

including technical controls, 

operational controls, and management 

controls.178 Some controls provide 

safeguards against automated system 

failures or deficiencies, while others 

guard against human error, deficiencies, 

or malicious action. Controls testing as 

addressed by the proposed rule includes 

all of these types of system safeguards 

controls. 

Describing some of the important 

benefits of controls assessment, NIST 

notes that ‘‘[u]nderstanding the overall 

effectiveness of implemented security 

and privacy controls is essential in 

determining the risk to the 

organization’s operations and assets 

. . . resulting from the use of the 

system,’’179 and observes that controls 

assessment ‘‘is the principal vehicle 

used to verify that implemented security 

controls . . . are meeting their stated 

goals and objectives.’’ 180 NIST adds 

that: 

Security assessments: (i) Ensure that 

information security is built into 

organizational information systems; (ii) 

identify weaknesses and deficiencies early in 

the development process; (iii) provide 

essential information needed to make riskbased decisions as part of security 

authorization processes; and (iv) ensure 

compliance to vulnerability mitigation 

procedures.181

The Commission believes that in today’s 

rapidly-changing cybersecurity threat 

environment, regular, ongoing controls 

testing that verifies over time the 

effectiveness of each system safeguards 

control used by a DCM, SEF, or SDR is 

essential to ensuring the continuing 

overall efficacy of the entity’s system 

safeguards and of its program of risk 

analysis and oversight. 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80154 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

182 Id. 

183NIST SP 800–53A Rev. 4, at 3, available at 

http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53Ar4.pdf. 

184FFIEC, Information Security IT Examination 

Handbook, available at http://ithandbook.ffiec.gov/ 

ITBooklets/FFIEC_ITBooklet_Information

Security.pdf. 

185 ISACA, COBIT 5, MEA02 Evaluate and Assess 

the System of Internal Control, available at 

https://cobitonline.isaca.org/. 

186 Id., Section 02.02 Review Business Process 

Controls Effectiveness. 

187 Id., Section 02. 

188See discussion above concerning the need for 

controls testing. 

189See discussion above concerning vulnerability 

testing. 

190The Commission understands that the 

proposed rule could result in some additional 

controls testing costs for some covered DCMs or 

SDRs, because they are not currently conducting 

testing of all their system safeguards controls at the 

minimum frequency required by the proposed rule. 

In such cases, the covered DCM or SDR would need 

to accelerate the testing of some controls to comply 

with the two-year minimum frequency requirement. 

191NIST SP 800–53A Rev. 4, at 17–18, available 

at http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53Ar4.pdf. 

192NIST SP–800–137, Information Security 

Continuous Monitoring (ISCM) for Federal 

Information Systems and Organizations, at 6, 

available at http://csrc.nist.gov/publications/

nistpubs/800-137/SP800-137-Final.pdf. 

193The Commission understands that most DCMs 

that would be covered by the proposed covered 

DCM definition, and most SDRs, currently retain 

independent contractors to perform testing of their 

key controls. 

b. Best Practices Call for Controls 

Testing 

Best practices and standards call for 

organizations to conduct regular, 

ongoing controls testing that over time 

includes testing of all their system 

safeguards-related controls. NIST calls 

for organizations to have a security 

assessment plan that: 

Assesses the security controls in the 

information system and its environment of 

operation to determine the extent to which 

the controls are implemented correctly, 

operating as intended, and producing the 

desired outcome with respect to meeting 

established security requirements.182

NIST notes that the results of such 

testing can allow organizations, among 

other things to identify potential 

cybersecurity problems or shortfalls, 

identify security-related weaknesses and 

deficiencies, prioritize risk mitigation 

decisions and activities, confirm that 

weaknesses and deficiencies have been 

addressed, and inform related budgetary 

decisions and capital investment.183

FFIEC calls for controls testing because 

‘‘[c]ontrols should not be assumed to be 

completely effective,’’ and states that a 

controls testing program ‘‘is sound 

industry practice and should be based 

on an assessment of the risk of noncompliance or circumvention of the 

institution’s controls.’’ 184 ISACA’s 

COBIT standards call for organizations 

to ‘‘[c]ontinuously monitor and evaluate 

the control environment, including selfassessments and independent assurance 

reviews,’’ 185 and to ‘‘[r]eview the 

operation of controls . . . to ensure that 

controls within business process operate 

effectively.’’ 186 ISACA observes that 

this enables management ‘‘to identify 

control deficiencies and inefficiencies 

and to initiate improvement 

actions.’’ 187

c. Controls Testing Definitions and 

Related Provisions 

In this NPRM, the Commission is 

proposing to clarify the existing testing 

requirements for all DCMs, SEFs, and 

SDRs by specifying controls testing as 

essential to fulfilling those 

requirements, and defining it. The 

proposed rule’s definitions of controls 

and controls testing are discussed 

above.188 The proposed rule also defines 

‘‘key controls’’ as those controls that an 

appropriate risk analysis determines are 

either critically important for effective 

system safeguards, or intended to 

address risks that evolve or change more 

frequently and therefore require more 

frequent review to ensure their 

continuing effectiveness in addressing 

such risks. 

The proposed rule would require each 

DCM, SEF, and SDR to conduct controls 

testing, including testing of each control 

included in its program of system 

safeguards-related risk analysis and 

oversight, at a frequency determined by 

an appropriate risk analysis. As 

discussed above, testing at such a 

frequency is a best practice.189

d. Minimum Controls Testing 

Frequency Requirements for Covered 

DCMs and SDRs 

The proposed rule would call for a 

covered DCM or an SDR to conduct 

controls testing, including testing of 

each control included in its program of 

system safeguards-related risk analysis 

and oversight, no less frequently than 

every two years. It would permit such 

testing to be conducted on a rolling 

basis over the course of the two-year 

period or the period determined by 

appropriate risk analysis, whichever is 

shorter.190

The proposed rule includes this 

frequency provision in order to ensure 

that in all cases, each control included 

in the system safeguards risk analysis 

and oversight program of a covered 

DCM or an SDR is tested at least every 

two years, or tested more frequently if 

that is indicated by appropriate analysis 

of the entity’s system safeguards-related 

risks. The Commission believes that it is 

essential for each control to be tested at 

least this often in order to confirm the 

continuing adequacy of the entity’s 

system safeguards in today’s 

cybersecurity threat environment. The 

Commission also recognizes that 

appropriate risk analysis may well 

determine that more frequent testing of 

either certain key controls or all controls 

is necessary. 

The provision permitting such testing 

to be done on a rolling basis is included 

in recognition of the fact that an 

adequate system safeguards program for 

a covered DCM or an SDR must 

necessarily include large numbers of 

controls of all the various types 

discussed above, and that therefore it 

could be impracticable and unduly 

burdensome to require testing of all 

controls in a single test. The rolling 

basis provision is designed to give 

flexibility to a covered DCM or an SDR 

concerning which controls are tested 

when during the applicable minimum 

period—either every two years or more 

often if called for by appropriate risk 

analysis—as long as each control is 

tested within the applicable minimum 

period. This flexibility is intended to 

reduce burdens associated with testing 

every control to the extent possible 

while still ensuring the needed 

minimum testing frequency. Testing on 

a rolling or recursive basis is also 

congruent with best practices. NIST 

states that a controls test can consist of 

either complete assessment of all 

controls or a partial assessment of 

controls selected for a particular 

assessment purpose.191 NIST notes that 

over time, organizations can increase 

cybersecurity situational awareness 

through appropriate testing, which 

provides increased insight into and 

control of the processes used to manage 

the organization’s security, which in 

turn enhances situational awareness, in 

a recursive process.192

e. Independent Contractor Controls 

Testing Requirements for Covered DCMs 

and SDRs 

The proposed rule would require 

covered DCMs and SDRs to engage 

independent contractors to test and 

assess each of the entity’s key controls 

no less frequently than every two 

years.193 It permits the covered DCM or 

SDR to conduct any other required 

controls testing by using either 

independent contractors or entity 

employees not responsible for 

development or operation of the systems 

of capabilities involved in the test. 

Independent testing of key controls is 

consonant with best practices. ISACA 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80155 

194 ISACA, COBIT 5, MEA02, Monitor, Evaluate 

and Assess the System of Internal Control, available 

at https://cobitonline.isaca.org/. 

195NIST SP 800–53 Rev. 4, control CA–2 Security 

Assessments, Control Enhancements 1, Security 

Assessments: Independent Assessors, available at 

http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53r4.pdf. 

196The requirements proposed by the 

Commission regarding controls testing are generally 

consistent with the SEC’s Regulation SCI, issued in 

final form in December 2014. Regulation SCI 

applies to SCI entities, defined as including, among 

other things, national securities exchanges, 

alternative trading systems, and registered clearing 

agencies. It requires each SCI entity to conduct SCI 

reviews that include assessments of the design and 

effectiveness of internal controls, in a manner 

consistent with industry standards. SCI reviews 

must be conducted at least annually. 

197NIST defines a ‘‘security incident’’ as ‘‘[a]n 

occurrence that actually or potentially jeopardizes 

the confidentiality, integrity, or availability of an 

information system or the information the system 

processes, stores, or transmits, or that constitutes a 

violation or imminent threat of violation of security 

policies, security procedures, or acceptable use 

policies.’’ NIST SP 800–53 Rev. 4, at B–9, available 

at http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53r4.pdf. NIST further 

defines a ‘‘computer security incident’’ as ‘‘a 

violation or imminent threat of violation of 

computer security policies, acceptable use policies, 

or standard security practices.’’ NIST SP 800–61 

Rev. 2, available at http://nvlpubs.nist.gov/

nistpubs/SpecialPublications/NIST.SP.800- 

61r2.pdf. The FFIEC defines a ‘‘security incident’’ 

as ‘‘the attempted or successful unauthorized 

access, use, modification, or destruction of 

information systems or customer data. If 

unauthorized access occurs, the financial 

institution’s computer systems could potentially 

fail and confidential information could be 

compromised.’’ FFIEC IT Examination Handbook, 

Business Continuity Planning IT Examination 

Handbook, at 25, available at http://

ithandbook.ffiec.gov/ ITBooklets/FFIEC_ITBooklet_

BusinessContinuityPlanning.pdf. 

198Council on CyberSecurity, The Critical 

Security Controls for Effective Cyber Defense 

Version 5.1, CSC 18, at 96, available at http://

www.counciloncybersecurity.org/critical-controls/. 

199CFTC Roundtable, at 82–84. 

200 Id. at 79–80. 

201 Id. at 284–287. 

202 Id. at 283–284, 290–294. 

203NIST SP 800–34 Rev. 1, Contingency Planning 

Guide for Federal Information Systems (‘‘NIST SP 

800–34 Rev. 1’’), § 2.2.5 Cyber Incident Response 

Plan, at 11, available at http://csrc.nist.gov/

publications/nistpubs/800-34-rev1/sp800-34-rev1_

errata-Nov11-2010.pdf. 

204 Id. 

205NIST SP 800–53 Rev. 4, control IR–3 Incident 

Response Testing, available at http://

Continued 

standards call for controls testing to 

include independent assurance reviews 

as well as self-assessments, in order to 

assure control effectiveness.194 NIST 

calls for controls testing to include 

assessment by independent assessors, 

free from actual or perceived conflicts of 

interest, in order to validate the 

completeness, accuracy, integrity, and 

reliability of test results.195 The 

proposed rule’s requirement for testing 

of key controls by independent 

contractors at least every two years is 

designed to ensure that covered DCM 

and SDR programs of risk analysis and 

oversight with respect to system 

safeguards include these benefits with 

regard to the testing of their key 

controls. In light of the best practices 

and the current level of cyber threat to 

the financial sector discussed above, the 

Commission believes that having each 

of a covered DCM’s or SDR’s key 

controls tested by independent 

contractors at least every two years is 

appropriate and important in today’s 

cybersecurity environment. The rolling 

basis provision of the proposed rule 

regarding controls testing would leave 

to a covered DCM or SDR the choice of 

whether to have key controls testing by 

independent contractors done in a 

single test at least every two years, or in 

multiple, partial tests by independent 

contractors that cover each key control 

within the two-year minimum 

period.196

6. Security Incident Response Plan 

Testing 

a. Need for Security Incident Response 

Plans and Testing 

Financial sector entities should 

maintain and test a security incident 197

response plan (‘‘SIRP’’). As the Council 

on CyberSecurity explains in addressing 

its Critical Security Control calling for 

incident response plans and testing: 

Cyber incidents are now just part of our 

way of life. Even large, well-funded, and 

technically sophisticated enterprises struggle 

to keep up with the frequency and 

complexity of attacks. The question of a 

successful cyber-attack against an enterprise 

is not ‘‘if’’ but ‘‘when’’. When an incident 

occurs, it is too late to develop the right 

procedures, reporting, data collection, 

management responsibility, legal protocols, 

and communications strategy that will allow 

the enterprise to successfully understand, 

manage, and recover. Without an incident 

response plan, an organization may not 

discover an attack in the first place, or, if the 

attack is detected, the organization may not 

follow good procedures to contain damage, 

eradicate the attacker’s presence, and recover 

in a secure fashion. Thus, the attacker may 

have a far greater impact, causing more 

damage, infecting more systems, and possibly 

exfiltrate more sensitive data than would 

otherwise be possible were an effective 

incident response plan in place.198

Adequate cyber resilience requires that 

organizations have the capacity to 

detect, contain, eliminate, and recover 

from a cyber intrusion. The Commission 

believes that SIRPs and their testing are 

essential to such capabilities. 

CFTC Roundtable participants 

recommended that the Commission 

consider SIRP testing in addressing the 

various types of testing needed in 

today’s cyber threat environment.199

Panelists stated that testing an 

organization’s ability to recover from 

cyber attacks, in particular from attacks 

aimed at destruction of data or 

automated systems or at degradation of 

data integrity, is very important.200

They noted that when a security 

incident actually happens, it is helpful 

to have an incident response plan, but 

more helpful to have tested it. Panelists 

explained if the organization has 

practiced its plan or framework for 

responding to a security incident, the 

people who must make decisions—often 

with incomplete or conflicting 

information—will know what numbers 

to call, where to go, what is expected, 

and what the framework is for making 

the quick decisions that are needed. 

They also noted that failure to practice 

the response process can delay or 

paralyze timely response and cause 

severe consequences, and that this 

makes practicing an incident response 

plan or framework crucial to effective 

incident response.201 Panelists also 

noted that much financial sector 

business continuity testing has focused 

in the past on an entity’s ability to 

respond to physical security incidents 

such as storms, transportation or electric 

power outages, fire, flood, etc. In 

addition to physical security incident 

response testing, adequate testing today 

must take into account the fact that the 

risk landscape has changed and now 

includes increased cyber threat.202

b. Best Practices Call for Maintaining 

and Testing a SIRP 

Having and testing a cyber and 

physical security incident response plan 

is a best practice with regard to 

cybersecurity. NIST urges organizations 

to have a cyber incident response plan 

that: 

Establishes procedures to address cyber 

attacks against an organization’s information 

system(s). These procedures are designed to 

enable security personnel to identify, 

mitigate, and recover from malicious 

computer incidents, such as unauthorized 

access to a system or data, denial of service, 

or unauthorized changes to system hardware, 

software, or data (e.g., malicious logic, such 

as a virus, worm, or Trojan horse).203

NIST notes that such plans may be 

included as an appendix to the 

organization’s business continuity 

plan.204

NIST best practices for cybersecurity 

also call for organizations to test their 

incident response capabilities with 

respect to their information systems, at 

appropriate frequencies, to determine 

their effectiveness, and to document test 

results.205 They provide that 

organizations should: 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80156 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

nvlpubs.nist.gov/nistpubs/SpecialPublications/

NIST.SP.800-53r4.pdf. 

206NIST SP 800–84, Guide to Test, Training, and 

Exercise Programs for IT Plans and Capabilities 

(‘‘NIST SP 800–84’’), at ES–1, available at http://

csrc.nist.gov/publications/nistpubs/800-84/SP800- 

84.pdf. 

207 Id. at ES–2. 

208NIST SP 800–53 Rev. 4, control CP–2 

Contingency Plan, available at http://

nvlpubs.nist.gov/nistpubs/SpecialPublications/

NIST.SP.800-3r4.pdf. 

209NIST SP 800–53 Rev. 4, control CP–4 

Contingency Plan Testing, available at http://

nvlpubs.nist.gov/nistpubs/SpecialPublications/

NIST.SP.800-53r4.pdf. 

210FINRA, Report on Cybersecurity Practices 

(February 2015), at 23, available at https://

www.finra.org/sites/default/files/p602363%20

Report%20on%20Cybersecurity%20

Practices_0.pdf. 

211FFIEC, Business Continuity Planning IT 

Examination Handbook, at 25, available at http:// 

ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_BusinessContinuityPlanning.pdf. 

212 Id. at 25–26. 

213Council on CyberSecurity, The Critical 

Security Controls for Effective Cyber Defense 

Version 5.1, CSC 18, at 96, available at http:// 

www.counciloncybersecurity.org/critical-controls/. 

214 Id. at 97. 

215NIST SP 800–53 Rev. 4, control IR–3 Incident 

Response Testing, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 

216 17 CFR 38.1050; 17 CFR 38.1051(a) and (b) (for 

DCMs); Appendix A to Part 37, Core Principle 14 

of Section 5h of the Act—System Safeguards (a) 

Guidance (1) Risk analysis and oversight program 

(for SEFs); 17 CFR 49.24(a) through (c) (for SDRs). 

217NIST SP 800–53 Rev. 4, control IR–1 Incident 

Response Policy and Procedures, available at http:// 

nvlpubs.nist.gov/nistpubs/SpecialPublications/ 

NIST.SP.800-53r4.pdf. 

[H]ave information technology (IT) plans in 

place, such as contingency and computer 

security incident response plans, so that they 

can respond to and manage adverse 

situations involving IT. These plans should 

be maintained in a state of readiness, which 

should include having personnel trained to 

fulfill their roles and responsibilities within 

a plan, having plans exercised to validate 

their content, and having systems and system 

components tested to ensure their operability 

in an operational environment specified in a 

plan. These three types of events can be 

carried out efficiently and effectively through 

the development and implementation of a 

test, training, and exercise (TT&E) program. 

Organizations should consider having such a 

program in place because tests, training, and 

exercises are so closely related. For example, 

exercises and tests offer different ways of 

identifying deficiencies in IT plans, 

procedures, and training.206

NIST adds that: 

Organizations should conduct TT&E events 

periodically; following organizational 

changes, updates to an IT plan, or the 

issuance of new TT&E guidance; or as 

otherwise needed. This assists organizations 

in ensuring that their IT plans are reasonable, 

effective, and complete, and that all 

personnel know what their roles are in the 

conduct of each IT plan. TT&E event 

schedules are often dictated in part by 

organizational requirements. For example, 

NIST Special Publication 800–53 requires 

Federal agencies to conduct exercises or tests 

for their systems’ contingency plans and 

incident response capabilities at least 

annually.207

In addition, NIST states that an 

organization following best practices: 

Coordinates contingency planning 

activities with incident handling activities. 

By closely coordinating contingency 

planning with incident handling activities, 

organizations can ensure that the necessary 

contingency planning activities are in place 

and activated in the event of a security 

incident.208

According to NIST, an organization 

following best practices tests the 

contingency plan for an information 

system at an appropriate frequency, 

using organization-defined tests, to 

determine the effectiveness of the plan 

and the organizational readiness to 

execute the plan. It then reviews the test 

results, and initiates corrective actions if 

needed.209

FINRA’s best practices also call for 

SIRPs. FINRA’s 2015 Report on 

Cybersecurity Practices states that: 

Firms should establish policies and 

procedures, as well as roles and 

responsibilities for escalating and responding 

to cybersecurity incidents. Effective practices 

for incident response include involvement in 

industry-wide and firm-specific simulation 

exercises as appropriate to the role and scale 

of a firm’s business.210

The FFIEC has said that ‘‘[e]very 

financial institution should develop an 

incident response policy that is properly 

integrated into the business continuity 

planning process.’’ 211 The FFIEC also 

calls for incident response plan testing, 

stating that ‘‘[f]inancial institutions 

should assess the adequacy of their 

preparation by testing incident response 

guidelines to ensure that the procedures 

correspond with business continuity 

strategies.212

The Council on CyberSecurity’s 

Critical Security Controls provide that 

organizations should protect their 

information, as well as their reputations, 

by developing and implementing an 

incident response plan and 

infrastructure ‘‘for quickly discovering 

an attack and then effectively containing 

the damage, eradicating the attacker’s 

presence, and restoring the integrity of 

the network and systems.’’ 213 The 

Critical Security Controls also call for 

organizations to ‘‘conduct periodic 

incident scenario sessions for personnel 

associated with the incident handling 

team, to ensure that they understand 

current threats and risks, as well as their 

responsibilities in supporting the 

incident handling teams.’’ 214

c. Flexibility Regarding Forms of SIRP 

Testing 

SIRP testing can take a number of 

possible forms, consistent with 

generally accepted standards and best 

practices, and accordingly, the proposed 

rule would apply the general 

requirement that the forms of testing 

addressed in an entity’s security 

incident response plan should be 

aligned with an entity’s appropriate 

analysis of its system safeguards-related 

risks. As noted in NIST’s best practices 

regarding security incident response 

testing: 

Organizations test incident response 

capabilities to determine overall effectiveness 

of the capabilities and to identify potential 

weaknesses or deficiencies. Incident 

response testing includes, for example, the 

use of checklists, walk-through or tabletop 

exercises, simulations (parallel/full 

interrupt), and comprehensive exercises. 

Incident response testing can also include a 

determination of the effects on organizational 

operations (e.g., reduction in mission 

capabilities), organizational assets, and 

individuals due to incident response.215

As provided in the proposed rule, the 

scope of the plan and its testing should 

be broad enough to support entity 

resilience with respect to security 

incidents that is sufficient to enable the 

entity to fulfill its statutory and 

regulatory responsibilities. Such 

resilience should include the ability to 

detect, contain, respond to, and recover 

from both cyber and physical security 

incidents in a timely fashion. 

d. Best Practices Provide Guidance 

Regarding Appropriate SIRP Contents 

The Commission notes that its 

existing system safeguards rules and 

guidance for DCMs, SEFs, and SDRs 

provide that those entities should follow 

generally accepted standards and best 

practices in meeting the testing 

requirements applicable to their 

required program of risk analysis and 

oversight with respect to system 

safeguards, and that this applies with 

respect to SIRPs and their testing.216

Best practices provide useful guidance 

concerning the contents of an adequate 

SIRP. 

For example, NIST calls for an 

organization to develop, document, and 

distribute to the appropriate personnel 

‘‘an incident response policy that 

addresses purpose, scope, roles, 

responsibilities, management 

commitment, coordination among 

organizational entities, and 

compliance,’’ as well as ‘‘procedures to 

facilitate the implementation of the 

incident response policy and associated 

incident response controls.’’ 217 NIST 

further recommends that an 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80157 

218NIST SP 800–53 Rev. 4, control IR–8 Incident 

Response Plan, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf. 

219 Id. 

220NIST SP 800–61 Rev. 2, section 2.3.1 Policy 

Elements, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

61r2.pdf. 

221See discussion above concerning vulnerability 

testing. 

222The Commission understands that many 

covered DCMs (as defined) and many SDRs 

currently conduct SIRP testing at least annually. 

223NIST SP 800–84, Guide to Test, Training, and 

Exercise Programs for IT Plans and Capabilities, at 

2–4 (citing NIST SP 800–53, Rev. 4, Security and 

Privacy Controls for Federal Information Systems 

and Organizations). 

224NIST SP 800–39, at 1, available at http:// 

csrc.nist.gov/publications/nistpubs/800-39/SP800- 

39-final.pdf. 

organization should develop and 

maintain an incident response plan that: 

1. Provides the organization with a 

roadmap for implementing its incident 

response capability; 

2. Describes the structure and organization 

of the incident response capability; 

3. Provides a high-level approach for how 

the incident response capability fits into the 

overall organization; 

4. Meets the unique requirements of the 

organization, which relate to mission, size, 

structure, and functions; 

5. Defines reportable incidents; 

6. Provides metrics for measuring the 

incident response capability within the 

organization; 

7. Defines the resources and management 

support needed to effectively maintain and 

mature an incident response capability; and 

8. Is reviewed and approved by 

[appropriate organization-defined personnel 

or roles].218

NIST also calls for the organization to 

distribute copies of the plan to 

appropriate personnel; review the plan 

at an appropriate frequency; update the 

plan ‘‘to address system/organizational 

changes or problems encountered 

during plan implementation, execution, 

or testing;’’ communicate plan changes 

to appropriate personnel; and protect 

the plan from unauthorized disclosure 

and modification.219 NIST notes that 

while incident response policies are 

individualized to the organization, most 

policies include the same key elements: 

• Statement of management commitment. 

• Purpose and objectives of policy. 

• Scope of the policy (to whom and what 

it applies and under what circumstances). 

• Definition of computer security incidents 

and related terms. 

• Organizational structure and definition 

of roles, responsibilities, and levels of 

authority; should include the authority of the 

incident response team to confiscate or 

disconnect equipment and to monitor 

suspicious activity, the requirements for 

reporting certain types of incidents, the 

requirements and guidelines for external 

communications and information sharing 

(e.g., what can be shared with whom, when, 

and over what channels), and the handoff 

and escalation points in the incident 

management process. 

• Prioritization or severity ratings of 

incidents. 

• Performance measures. 

• Reporting and contact forms.220

e. Proposed SIRP Definitions and 

Related Provisions 

In this NPRM, the Commission is 

proposing to clarify the existing testing 

requirements for all DCMs, SEFs, and 

SDRs by specifying SIRP testing as 

essential to fulfilling those 

requirements, and defining it. The 

proposed rule would define ‘‘security 

incident’’ as a cyber or physical security 

event that actually or potentially 

jeopardizes automated system 

operation, reliability, security, or 

capacity, or the availability, 

confidentiality, or integrity of data. The 

proposed rule would define ‘‘security 

incident response plan’’ as a written 

plan that documents the DCM’s, SEF’s, 

or SDR’s policies, controls, procedures, 

and resources for identifying, 

responding to, mitigating, and 

recovering from security incidents, as 

well as the roles and responsibilities of 

management, staff, and independent 

contractors in responding to security 

incidents. This definition notes that a 

SIRP may be a separate document or a 

BC–DR plan section or appendix 

dedicated to security incident response. 

The proposed rule would define 

‘‘security incident response plan 

testing’’ as testing of a DCM’s, SEF’s, or 

SDR’s SIRP to determine its 

effectiveness, identify its potential 

weaknesses or deficiencies, enable 

regular updating and improvement, and 

maintain the entity’s preparedness and 

resiliency with respect to security 

incidents. This definition adds that 

methods of conducting SIRP testing may 

include (without limitation) checklist 

completion, walk-through or table-top 

exercises, simulations, and 

comprehensive exercises. 

The proposed rule would require all 

DCMs, SEFs, and SDRs to conduct SIRP 

testing at a frequency determined by an 

appropriate risk analysis. As discussed 

above, testing as often as indicated by 

appropriate risk analysis is a best 

practice.221 The Commission believes 

that in today’s cybersecurity threat 

environment, appropriate risk analysis 

may well call for conducting frequent 

SIRP tests of various types. The 

flexibility regarding forms of SIRP 

testing provided by the proposed rule is 

designed in part to encourage 

appropriately frequent SIRP testing. 

f. Minimum SIRP Testing Frequency 

Requirements for Covered DCMs and 

SDRs 

The proposed rule would call for a 

covered DCM or an SDR to conduct 

SIRP testing no less frequently than 

annually.222 Best practices support this 

requirement. For example, NIST calls 

for organizations to test their systemsrelated contingency plans and incident 

response capabilities at least 

annually.223

g. Who Performs Security Incident 

Response Plan Testing 

The proposed rule would leave to 

covered DCMs and SDRs (as well as to 

all other DCMs and to all SEFs) the 

choice of having security incident 

response plan testing conducted by 

independent contractors or by 

employees of the covered DCM or SDR. 

This provision of the proposed rule 

therefore would not impose any 

additional burdens or costs on DCMs or 

SDRs. 

7. Enterprise Technology Risk 

Assessment 

a. Enterprise Technology Risk 

Assessment Definition and Purpose 

The proposed rule would clarify the 

testing requirements of the 

Commission’s current system safeguards 

rules for all DCMs, SEFs, and SDRs by 

specifying that conducting regular 

enterprise technology risk assessments 

(‘‘ETRAs’’) is essential to meeting those 

testing requirements. The proposed rule 

would define ETRAs as written 

assessments that include (without 

limitation) an analysis of threats and 

vulnerabilities in the context of 

mitigating controls. As further defined, 

an ETRA identifies, estimates, and 

prioritizes a DCM’s, SEF’s or SDR’s risks 

to operations or assets, or to market 

participants, individuals, or other 

entities, resulting from impairment of 

the confidentiality, integrity, or 

availability of data and information or 

the reliability, security, or capacity of 

automated systems. The purpose of 

assessments of enterprise risk is 

identifying (a) threats and 

vulnerabilities, (b) the harm that could 

occur given the potential for threats that 

exploit vulnerabilities, and (c) the 

likelihood that such harm will occur, in 

order to produce a broad determination 

of the organization’s system safeguardsrelated risks.224 According to NIST, 

such risk assessment is necessary for 

well-informed, risk-based leadership 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80158 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

225 Id. 

226NIST SP 800–115, available at http:// 

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf. 

227See, e.g., ISACA, COBIT 5; International 

Organisation for Standardisation and International 

Electrotechnical Commission (‘‘ISO/IEC’’) 27001; 

FFIEC. 

228FINRA, Report on Cybersecurity Practices 

(February 2015), at 14, available at https://www.

finra.org/sites/default/files/p602363%20

Report%20on%20Cybersecurity%20

Practices_0.pdf. 

229See discussion of vulnerability testing 

frequency. 

230FFIEC, Information Security IT Examination 

Handbook, at 7–8, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

231FINRA, Report on Cybersecurity Practices 

(February 2015), at 12, available at https://www.

finra.org/sites/default/files/p602363%20Report%20

on%20Cybersecurity%20Practices_0.pdf. 

232 Id. at 13. 

233 ISACA, COBIT 5, APO12, Manage Risk, 

available at https://cobitonline.isaca.org. 

234The Commission understands that most 

covered DCMs and most SDRs currently perform 

cybersecurity and system safeguards risk 

assessments on at least an annual basis. 

235FINRA, Report on Cybersecurity Practices 

(February 2015), at 14, available at https://www.

finra.org/sites/default/files/p602363%20Report%2

0on%20Cybersecurity%20Practices_0.pdf. 

236FFIEC, Information Security IT Examination 

Handbook, at 7–8, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

237 Id. at 86. 

238See NIST SP 800–115, at 6–6, available at 

http://csrc.nist.gov/publications/nistpubs/800-115/ 

decisions that ‘‘balance the benefits 

gained from the operation and use of 

. . . information systems with the risk of 

the same systems being vehicles through 

which purposeful attacks, 

environmental disruptions, or human 

errors cause mission or business 

failure.’’ 225

An ETRA may be used as the 

overarching vehicle through which a 

DCM, SEF, or SDR draws together and 

uses the results and lessons learned 

from each of the types of cybersecurity 

and system safeguards testing addressed 

in the proposed rule, in order to identify 

and mitigate its system safeguardsrelated risks. As NIST observes, ‘‘[s]ince 

no one technique can provide a 

complete picture of the security of a 

system or network, organizations should 

combine appropriate techniques to 

ensure robust security assessments.’’ 226

The proposed rule’s testing scope 

provisions would require that DCMs, 

SEFs, and SDRs conduct ETRAs of a 

scope broad enough to identify any 

vulnerability that, if exploited or 

accidentally triggered, could enable: (1) 

Interference with the organization’s 

operations or the fulfillment of its 

statutory and regulatory responsibilities, 

(2) impairment or degradation of the 

reliability, security, or capacity of the 

organization’s automated systems, (3) 

addition, deletion, modification, 

exfiltration, or compromise of any data 

relating to the organization’s regulated 

activities, or (4) any other unauthorized 

action affecting the organization’s 

regulated activities or the hardware or 

software used in connection with them. 

The proposed rule would not, however, 

specify particular methods, structures, 

or frameworks for ETRAs. Best practices 

provide a number of sources for such 

risk assessment frameworks,227 and a 

DCM, SEF, or SDR would have 

flexibility to choose the assessment 

framework it believes most appropriate 

to its particular circumstances. FINRA 

notes that approaches to integrating 

threats and vulnerabilities in an overall 

risk assessment report often differ, with 

some organizations following 

proprietary risk assessment 

methodologies and others using vendor 

products tailored to their particular 

needs, and with firms using a variety of 

cyber incident and threat intelligence 

inputs for their risk assessments.228 The 

flexibility provided by the proposed 

rule in this respect is intended to reduce 

the costs of performing an ETRA to the 

extent practicable while still ensuring 

the sufficiency of the important 

assessment process. 

The proposed rule would require all 

DCMs, SEFs, and SDRs to conduct 

ETRAs at a frequency determined by an 

appropriate risk analysis. As noted 

above, conducting testing and 

assessment as often as indicated by such 

risk analysis is a best practice.229

b. Best Practices Call for ETRAs 

Regular performance of ETRAs is a 

best practice. In describing such 

assessments and emphasizing their 

importance, FFIEC states that: 

Financial institutions must maintain an 

ongoing information security risk assessment 

program that effectively: 

• Gathers data regarding the information 

and technology assets of the organization, 

threats to those assets, vulnerabilities, 

existing security controls and processes, and 

the current security standards and 

requirements; 

• Analyzes the probability and impact 

associated with the known threats and 

vulnerabilities to their assets; and 

• Prioritizes the risks present due to 

threats and vulnerabilities to determine the 

appropriate level of training, controls, and 

assurance necessary for effective 

mitigation.230

FINRA calls for firms to conduct regular 

risk assessments to identify 

cybersecurity risks, and for such 

assessments to include ‘‘an assessment 

of external and internal threats and asset 

vulnerabilities, and prioritized and 

time-bound recommendations to 

remediate identified risks.’’ 231 FINRA 

calls such risk assessments ‘‘a key driver 

in a firm’s risk management-based 

cybersecurity program.’’ 232 ISACA 

standards contain similar provisions.233

c. Minimum ETRA Frequency 

Requirements for Covered DCMs and 

SDRs 

The proposed rule would call for 

covered DCMs and SDRs to conduct an 

ETRA no less frequently than 

annually.234 Either annual or more 

frequent assessment of technology and 

cybersecurity risk is a best practice. For 

example, FINRA states that firms 

conducting appropriate risk assessment 

do so either annually or on an ongoing 

basis throughout the year, in either case 

culminating in an annual risk 

assessment report.235 As noted above, 

FFIEC calls for financial institutions to 

maintain ongoing information security 

risk assessment programs.236

The proposed requirement to prepare 

a written assessment on at least an 

annual basis would not eliminate the 

need for a covered DCM or SDR to 

conduct risk assessment and monitoring 

on an ongoing basis, as best practices 

require. Rather, the proposed 

requirement is intended to formalize the 

risk assessment process and ensure that 

it is documented at a minimum 

frequency. As noted in the FFIEC 

Handbook: ‘‘Monitoring and updating 

the security program is an important 

part of the ongoing cyclical security 

process. Financial institutions should 

treat security as dynamic with active 

monitoring; prompt, ongoing risk 

assessment; and appropriate updates to 

controls.’’ 237

d. Who Conducts ETRAs 

The proposed rule would permit 

covered DCMs and SDRs (as well as all 

other DCMs and all SEFs) to conduct 

ETRAs using either independent 

contractors or employees not 

responsible for development or 

operation of the systems or capabilities 

being assessed. Assessment by 

independent contractors is congruent 

with best practices. NIST and FFIEC 

note that assessment by independent 

contractors offers the benefit of an 

independent view and approach that 

might not be provided by internal 

assessors, and can lend credibility to 

assessment results.238 Best practices 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80159 

SP800-115.pdf; and FFIEC, Information Security IT 

Examination Handbook, at 81, available at http:// 

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf. 

239 Id. See also, e.g., ISACA, COBIT 5, MEA02.05, 

Ensure that assurance providers are independent 

and qualified, available at https:// 

cobitonline.isaca.org/. 

240The requirements proposed by the 

Commission regarding enterprise technology risk 

assessment are generally consistent with the SEC’s 

Regulation SCI, issued in final form in December 

2014. Regulation SCI applies to SCI entities, defined 

as including, among other things, national 

securities exchanges, alternative trading systems, 

and registered clearing agencies. It requires each 

SCI entity to conduct SCI reviews that include 

automated system risk assessments, in a manner 

consistent with industry standards. SCI reviews 

must be conducted at least annually. 

241CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

242 Id. 

243 17 CFR 38.1051(h) (for DCMs); 17 CFR 

37.1401(g) (for SEFs); 17 CFR 49.24(j) (for SDRs). 

244See 17 CFR 38.1051(b) (for DCMs); Appendix 

A to Part 37, Core Principle 14 of Section 5h of the 

Act—System Safeguards (a) Guidance (1) Risk 

analysis and oversight program (for SEFs); 17 CFR 

49.24(c) (for SDRs). 245See e.g., NIST SP 800–115, Technical Guide to 

Information Security Testing and Assessment, at 6– 

10—6–12, September 2008, available at http:// 

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf; NIST SP 800–53A Rev. 4, at 10, available 

at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53Ar4.pdf; FFIEC, 

Information Security IT Examination Handbook, at 

5, available at http://ithandbook.ffiec.gov/ 

ITBooklets/ 

FFIEC_ITBooklet_InformationSecurity.pdf; NIST SP 

800–53 Rev. 4, Program Management (‘‘PM’’) 

control family, available at http://nvlpubs.nist.gov/ 

nistpubs/SpecialPublications/NIST.SP.800- 

53r4.pdf; FINRA, Report on Cybersecurity Practices, 

February 2015, at 8, available at https://

www.finra.org/sites/default/files/

p602363%20Report%20on%20Cybersecurity%20

Practices_0.pdf; FFIEC, Audit IT Examination 

Handbook, Objective 6, at A–4, available at http:// 

ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_Audit.pdf; ISACA, COBIT 5, 

APO12, available at https://cobitonline.isaca.org/. 

246The current system safeguards provisions of 

the CEA and the Commission’s regulations became 

effective in August 2012. Generally accepted best 

practices called for appropriate testing scope, 

internal reporting and review of test results, and 

remediation of vulnerabilities and deficiencies 

disclosed by testing well before that date, as shown 

in the following examples. Regarding scope of 

testing and assessment, see, e.g., NIST SP 800–115, 

Technical Guide to Information Security Testing 

and Assessment, at 6–10 to 6–12, September 2008, 

available at http://csrc.nist.gov/publications/ 

nistpubs/800-115/SP800-115.pdf. Regarding 

internal reporting and review, see, e.g., FFIEC, 

Information Security IT Examination Handbook, at 

5, available at http://ithandbook.ffiec.gov/ 

ITBooklets/ 

FFIEC_ITBooklet_InformationSecurity.pdf. 

Regarding remediation, see, e.g., FFIEC, Audit IT 

Examination Handbook, Objective 6, at A–4, 

available at http://ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_Audit.pdf. 

247CFTC Roundtable, at 97, 100–101, 107–111, 

127–130, 139–141, 172–180. 

248 Id. 

also support assessment by entity 

employees, provided that they are 

suitably independent of the design, 

installation, maintenance, and operation 

of systems being assessed.239 A 

dedicated risk department, an internal 

audit department, or a Chief 

Compliance Officer would be examples 

of entity employees who could 

appropriately conduct an ETRA. 

Because the proposed rule gives 

flexibility to covered DCMs and SDRs 

regarding who conducts ETRAs, this 

provision will not impose additional 

costs.240

G. Additional Testing-Related Risk 

Analysis and Oversight Program 

Requirements Applicable To All DCMs, 

SEFs, and SDRs 

As noted above, the Act requires each 

DCM, SEF, and SDR to develop and 

maintain a program of system 

safeguards-related risk analysis and 

oversight to identify and minimize 

sources of operational risk.241 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.242 The Commission’s 

existing system safeguards rules for 

DCMs, SEFs, and SDRs mandate that, in 

order to achieve these statutory 

requirements, each DCM, SEF, and SDR 

must conduct testing and review 

sufficient to ensure that its automated 

systems are reliable, secure, and have 

adequate scalable capacity.243 The 

existing rules and guidance also provide 

that a DCM’s, SEF’s, or SDR’s entire 

program of risk analysis and oversight, 

which includes such testing, should be 

based on generally accepted standards 

and best practices with respect to the 

development, operation, reliability, 

security, and capacity of automated 

systems.244

In this NPRM, in addition to 

clarifying the existing testing 

requirements for DCMs, SEFs, and SDRs 

by specifying and defining the five types 

of testing that these entities necessarily 

must perform to fulfill those 

requirements, the Commission also 

proposes to clarify the testing 

requirements by specifying and defining 

three other aspects of DCM, SEF, and 

SDR risk analysis and oversight 

programs that are necessary to 

fulfillment of the testing requirements 

and achievement of their purposes. 

These three aspects are: (1) The scope of 

testing and assessment, (2) internal 

reporting and review of test results, and 

(3) remediation of vulnerabilities and 

deficiencies revealed by testing. These 

risk analysis and oversight program 

aspects are generally recognized best 

practice for system safeguards. As best 

practices and also the Act and the 

regulations themselves make clear, it 

would be essentially impossible for a 

DCM, SEF, or SDR to fulfill its 

obligation to conduct testing sufficient 

to ensure the reliability, security, and 

capacity of its automated systems 

without conducting testing of 

appropriate scope; without performing 

appropriate internal reporting and 

review of test results; or without 

remediating vulnerabilities and 

deficiencies disclosed by testing, in line 

with appropriate risk analysis.245 This 

has been true since before the testing 

requirements of the Act and the current 

regulations were adopted.246

Accordingly, the provisions of the 

proposed rule addressing testing scope, 

internal reporting and review, and 

remediation clarify the testing 

requirements of the existing system 

safeguards rules for DCMs, SEFs, and 

SDRs; they do not impose new 

requirements. 

1. Scope of Testing and Assessment 

The Commission is proposing that the 

scope of all testing and assessment 

required by its system safeguards 

regulations for DCMs, SEFs, and SDRs 

should be broad enough to include all 

testing of automated systems and 

controls necessary to identify any 

vulnerability which, if exploited or 

accidentally triggered, could enable an 

intruder or unauthorized user or insider 

to interfere with the entity’s operations 

or with fulfillment of its statutory and 

regulatory responsibilities; to impair or 

degrade the reliability, security, or 

capacity of the entity’s automated 

systems; to add to, delete, modify, 

exfiltrate, or compromise the integrity of 

any data related to the entity’s regulated 

activities; or to undertake any other 

unauthorized action affecting the 

entity’s regulated activities or the 

hardware or software used in 

connection with those activities. 

Testing scope should take into 

account not only an organization’s 

particular automated systems and 

networks and vulnerabilities, including 

any recent changes to them, but also the 

nature of the organization’s possible 

adversaries and their capabilities as 

revealed by current cybersecurity threat 

analysis: iI short, it should be based on 

proper risk analysis.247 The Commission 

recognizes that, as Roundtable panelists 

noted, the scope set for particular 

instances of the various types of 

cybersecurity testing can vary 

appropriately.248 The scope provisions 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80160 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

249FINRA, Report on Cybersecurity Practices, 

February 2015, at 7, available at https://www.finra.

org/sites/default/files/p602363%20Report%20on

%20Cybersecurity%20Practices_0.pdf. 

250 Id. 

251 Id. at 8. 

252FFIEC, Information Security IT Examination 

Handbook, at 5, available at http://ithandbook.ffiec.

gov/ITBooklets/FFIEC_ITBooklet_Information

Security.pdf. 

253 Id. See also, e.g., NIST SP 800–53 Rev. 4, 

Program Management (‘‘PM’’) control family, 

available at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf. 

254FFIEC, Audit IT Examination Handbook, 

Objective 6, at A–4, available at http://ithandbook.

ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf. 

255 ISACA, COBIT 5, APO12, available at 

https://cobitonline.isaca.org/. 

256See, e.g., NIST SP 800–53A Rev. 4, at 3, 

available at http://csrc.nist.gov/publications/

nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; 

FFIEC, Audit IT Examination Handbook, Objective 

6, at A–4, available at http://ithandbook.ffiec.gov/IT

Booklets/FFIEC_ITBooklet_Audit.pdf. 

of the proposed rule are designed to give 

a DCM, SEF, or SDR flexibility with 

regard to setting the scope of particular 

cybersecurity tests, so long as its overall 

program of testing is sufficient to 

provide adequate assurance of the 

overall effectiveness of its cybersecurity 

controls with respect to its system 

safeguards-related risks. The 

Commission believes that the scope of 

testing and assessment set out in the 

proposed rule is broad enough to 

provide the needed flexibility, while 

still providing sufficient guidance 

regarding the testing scope necessary for 

an adequate program of system 

safeguards-related risk analysis and 

oversight. Such flexibility should 

reduce costs and burdens associated 

with the proposed scope requirements 

to the extent possible while still 

ensuring the system safeguards 

resilience necessary in today’s 

cybersecurity threat environment. 

2. Internal Reporting and Review 

The proposed rule would require that 

a DCM’s, SEF’s, or SDR’s senior 

management and its Board of Directors 

receive and review reports of the results 

of all testing and assessment required by 

Commission rules. It also would require 

DCMs, SEFs, and SDRs to establish and 

follow appropriate procedures for 

remediation of issues identified through 

such review, and for evaluation of the 

effectiveness of the organization’s 

testing and assessment protocols. 

Oversight of an organization’s 

cybersecurity and system safeguards 

program by both senior management 

and the Board of Directors is a best 

practice. According to FINRA: 

Active executive management—and as 

appropriate to the firm, board-level 

involvement—is an essential effective 

practice to address cybersecurity threats. 

Without that involvement and commitment, 

a firm is unlikely to achieve its cybersecurity 

goals.249

FINRA observes that ‘‘[b]oards should 

play a leadership role in overseeing 

firms’ cybersecurity efforts,’’ and states 

that they should understand and 

approach cybersecurity as an enterprisewide risk management issue rather than 

merely an information technology 

issue.250 As noted by FINRA, the 

absence of proactive senior management 

and board involvement in cybersecurity 

can make firms more vulnerable to 

successful cybersecurity attacks.251 The 

FFIEC states that regular reports to the 

board should address the results of the 

organization’s risk assessment process 

and of its security monitoring and 

testing, including both internal and 

external audits and reviews.252 In 

addition, FFIEC calls for boards to 

review recommendations for changes to 

the information security program 

resulting from testing and assessment, 

and to review the overall effectiveness 

of the program.253

3. Remediation 

The proposed rule would require each 

DCM, SEF, and SDR to analyze the 

results of the testing and assessment 

required by the applicable system 

safeguards rules, in order to identify all 

vulnerabilities and deficiencies in its 

systems, and to remediate those 

vulnerabilities and deficiencies to the 

extent necessary to enable it to fulfill 

the applicable system safeguards 

requirements and meet its statutory and 

regulatory obligations. The proposed 

rule would require such remediation to 

be timely in light of appropriate risk 

analysis with respect to the risks 

presented. 

Remediation of vulnerabilities and 

deficiencies revealed by cybersecurity 

testing is a best practice and a 

fundamental purpose of such testing. 

FFIEC calls for management of financial 

sector organizations to take appropriate 

and timely action to address identified 

cybersecurity and system safeguards 

problems and weaknesses.254 ISACA’s 

COBIT 5 standards call for organizations 

to continually identify, assess, and 

reduce IT-related risk within levels of 

tolerance set by executive 

management.255

Best practices recognize that risk 

mitigation decisions and activities need 

to be prioritized in light of appropriate 

risk analysis, and that prompt and 

sufficient corrective action should target 

not only significant deficiencies noted 

in testing and assessment reports but 

also the root causes of such 

deficiencies.256 The minimum basis for 

system safeguards remediation 

decisions, priorities, and actions by 

DCMs, SEFs, and SDRs is set out in the 

proposed rule: DCMs, SEFs, and SDRs 

must remediate system safeguards 

vulnerabilities and deficiencies 

sufficiently to enable them to meet 

applicable system safeguards 

requirements and fulfill their statutory 

and regulatory obligations. Remediation 

that failed to meet this standard would 

not provide adequate system safeguards 

protection in today’s cybersecurity 

threat environment, and could result in 

unacceptable harm to the public or the 

national economy. 

H. Required Production of Annual Total 

Trading Volume 

As discussed above in preamble 

section F, the proposed rule would 

create requirements applicable to 

covered DCMs, as defined, as well as to 

SDRs, concerning system safeguards 

testing frequency and testing by 

independent contractors. As also 

discussed above, the Commission 

believes that the minimum testing 

frequency and independent contractor 

testing requirements in the proposed 

rule should be applied to DCMs whose 

annual total trading volume is five 

percent or more of the annual total 

trading volume of all DCMs regulated by 

the Commission. This would give DCMs 

that have less than five percent of the 

annual total trading volume of all DCMs 

more flexibility regarding the testing 

they must conduct. With respect to 

DCMs, the Commission believes that 

applying the proposed frequency and 

independent contractor requirements 

only to DCMs whose annual total 

trading volume is five percent or more 

of the annual total trading volume of all 

regulated DCMs may be appropriate, in 

light of the fact that smaller DCMs will 

still be required to conduct testing of all 

the types addressed in the proposed rule 

pursuant to the existing DCM system 

safeguards rules. 

In order to provide certainty to all 

DCMs concerning whether the testing 

frequency and independent contractor 

provisions of the propose rule would 

apply to them, it is necessary for the 

Commission to receive annually from 

each DCM, beginning in 2016, its annual 

total trading volume for the preceding 

year, and to notify each DCM annually, 

beginning in 2016, of the percentage of 

the annual total trading volume of all 

DCMs which is constituted by that 

DCM’s annual total trading volume for 

the preceding year. The proposed rule 

therefore would require each DCM to 

report its annual total trading volume 

for 2015 to the Commission within 30 

calendar days of the effective date of the 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80161 

257The SEC’s Regulation SCI, issued in final form 

in December 2014, employs similar methodology to 

distinguish in some cases which entities are subject 

to SCI review requirements. Regulation SCI uses 

percentages of average daily dollar volume of stock 

trading to determine whether alternative trading 

systems are subject to Regulation SCI as SCI 

entities. 

258See discussion above concerning the need for 

cybersecurity testing. 259 5 U.S.C. 601 et seq. 

final rule, and to report its annual total 

volume for 2016 and each subsequent 

year thereafter to the Commission by 

January 31 of 2017 and of each calendar 

year thereafter.257

I. Advance Notice of Proposed 

Rulemaking Regarding Minimum 

Testing Frequency and Independent 

Contractor Testing Requirements for 

Covered SEFs 

The Commission is considering 

proposing, by means of a future NPRM, 

that the most systemically important 

SEFs should be subject to the same new 

minimum testing frequency 

requirements proposed in this NPRM for 

covered DCMs and SDRs. It is also 

considering proposing, by means of a 

future NPRM, that the most systemically 

important SEFs should be subject to the 

same independent contractor testing 

requirements proposed in this NPRM for 

covered DCMs and SDRs. Accordingly, 

by means of this concluding section of 

the preamble and the related set of 

questions and requests for comment at 

the conclusion of the Requests for 

Comment section, the Commission is 

issuing an Advance Notice of Proposed 

Rulemaking (‘‘ANPRM’’) with respect to 

these subjects. 

As discussed above, the Commission 

believes that, in light of the current 

cyber threat environment, the minimum 

frequency requirements and 

independent contractor testing 

requirements proposed in this NPRM for 

covered DCMs and SDRs are necessary 

and appropriate for ensuring the 

cybersecurity and resiliency of such 

entities, and are essential to the 

effectiveness of their cybersecurity 

testing and the adequacy of their 

programs of system safeguards risk 

analysis and oversight. As noted above, 

these requirements are grounded in 

generally accepted standards and best 

practices.258 The Commission also 

believes, as discussed above, that the 

independent contractor testing 

requirements proposed in this NPRM for 

covered DCMs and SDRs will 

appropriately strengthen the objectivity 

and reliability of the testing, assessment, 

and information available to the 

Commission regarding covered DCM 

and SDR system safeguards. 

For the same reasons, the Commission 

believes that it is appropriate and 

necessary to consider applying these 

same minimum testing frequency and 

independent contractor testing 

requirements to the most systemically 

important SEFs. The Commission is 

aware that at this time SEFs are new 

CFTC-regulated entities still awaiting 

final registration by the Commission, 

and that the SEF market is still in an 

early stage of development. 

Nevertheless, the Commission believes 

that SEFs that trade swaps with 

significant notional value or that trade 

significant numbers of swaps may have 

become systemically important enough 

that such requirements for them may 

now have become essential, in light of 

today’s cybersecurity threat 

environment (discussed above), the 

importance of the swap market to the 

U.S. economy, as recognized by the 

Dodd-Frank Act, and the notional value 

and volume of swaps traded on larger 

SEFs or pursuant to their rules. 

Preliminarily, the Commission 

believes it is appropriate to consider 

defining the ‘‘covered SEFs’’ to which 

these requirements would be applied as 

those SEFs for which the annual total 

notional value of all swaps traded on or 

pursuant to the rules of the SEF is ten 

percent (10%) or more of the annual 

total notional value of all swaps traded 

on or pursuant to the rules of all SEFs 

regulated by the Commission. This 

threshold would give SEFs that have 

less than ten percent of the annual total 

notional value of all swaps traded more 

flexibility regarding the testing they 

must conduct. As a matter of policy, the 

Commission believes it is appropriate to 

reduce possible costs and burdens for 

smaller entities when it is possible to do 

so consistent with achieving the 

fundamental goals of the Act and 

Commission rules. Accordingly, the 

Commission believes, preliminarily, 

that applying the minimum frequency 

and independent contractor 

requirements in this proposed rule only 

to SEFs that have ten percent or more 

of the annual total notional value of all 

swap traded would be appropriate, in 

light of the fact that smaller SEFs will 

still be required, pursuant to this 

current NPRM, to conduct testing of all 

the types clarified in the NPRM as 

essential to fulfilling the testing 

requirements of the existing SEF system 

safeguards rules. The Commission also 

notes that, under this current NPRM and 

the parallel NPRM being issued with 

respect to DCOs, a non-covered SEF that 

shares common ownership and 

automated systems with a DCO, a 

covered DCM, or an SDR would in 

practice fulfill the testing frequency and 

independent contractor testing 

requirements by virtue of sharing 

automated systems and system 

safeguards with the DCO, covered DCM, 

or SDR. 

However, the Commission will also 

consider whether it would be more 

appropriate to define ‘‘covered SEF’’ in 

terms of annual total notional value of 

swaps traded, or in terms of annual total 

number of swaps traded, and how 

notional value would best be defined in 

this context. It will also consider what 

percentage share of the annual total 

notional value of all swaps traded on all 

SEFs regulated by the Commission, or of 

the annual total number of swaps 

traded, should be used to define 

‘‘covered SEF.’’ It will further consider 

whether it would be more appropriate 

for the definition to be applied with 

respect to the notional value or the 

number of swaps in each asset class 

separately, or to be applied with respect 

to the notional value or the number of 

all swaps combined regardless of asset 

class. 

Accordingly, in the final part of the 

Request for Comment section below, the 

Commission is seeking comments 

regarding each of these considerations. 

The Commission will consider all such 

comments in determining what 

definition of ‘‘covered SEF’’ it should 

propose in a future NPRM on this 

subject, if such a proposal is made. The 

Commission is also seeking information 

relating to the possible costs and 

benefits of applying the minimum 

testing frequency and independent 

contractor testing requirements to 

covered SEFs, and how such benefits or 

costs could be quantified or estimated. 

In addition, the Commission seeks 

additional information regarding the 

extent to which SEFs are currently 

meeting these requirements. Finally, the 

Commission seeks additional 

information concerning the most 

appropriate method for SEFs to report 

annually to the Commission their 

annual total notional value of swaps 

traded or their annual total number of 

swaps traded. 

II. Related Matters 

A. Regulatory Flexibility Act 

The Regulatory Flexibility Act 

(‘‘RFA’’) requires that agencies consider 

whether the regulations they propose 

will have a significant economic impact 

on a substantial number of small entities 

and, if so, provide a regulatory 

flexibility analysis respecting the 

impact.259 The rules proposed by the 

Commission will impact DCMs, SEFs, 

and SDRs. The Commission has 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80162 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

260See 47 FR 18618–21 (Apr. 30, 1982). 

261See 47 FR 18618, 18619 (Apr. 30, 1982) 

discussing DCMs; 78 FR 33548 (June 4, 2013) 

discussing SEFs; 76 FR 54575 (Sept. 1, 2011) 

discussing SDRs. 

262 44 U.S.C. 3501 et seq. 

263See OMB Control No. 3038–0052, available at 

http://www.reginfo.gov/public/do/ 

PRAOMBHistory?ombControlNumber=3038–0052. 

264See OMB Control No. 3038–0074, available at 

http://www.reginfo.gov/public/do/ 

PRAOMBHistory?ombControlNumber=3038-0074. 

265See OMB Control No. 3038–0086, available at 

http://www.reginfo.gov/public/do/ 

PRAOMBHistory?ombControlNumber=3038–0086. 

266Commission regulation § 1.31(a)(1) 

specifically provides that ‘‘all books and records 

required to be kept by the Act or by these 

regulations shall be kept for a period of five years 

from the date thereof and shall be readily accessible 

during the first 2 years of the 5-year period.’’ The 

rule further provides that ‘‘all such books and 

records shall be open to inspection by any 

representative of the Commission or the United 

States Department of Justice.’’ See 17 CFR 

1.31(a)(1). 

267Commission regulation § 38.1051(g) 

specifically provides that ‘‘a designated contract 

market must provide to the Commission upon 

request current copies of the business-continuity 

disaster recovery plan and other emergency 

procedures, its assessments of its operational risks, 

and other documents requested by Commission 

staff for the purpose of maintaining a current profile 

of the designated contract market’s systems.’’ See 17 

CFR 38.1051(g). 

268Commission regulation § 38.1051(h) 

specifically provides that ‘‘a designated contract 

market must conduct regular, periodic, objective 

testing and review of its automated systems to 

ensure that they are reliable, secure, and have 

adequate scalable capacity. It must also conduct 

regular, periodic testing and review of its business 

continuity-disaster recovery capabilities.’’ The 

regulation further provides that ‘‘pursuant to Core 

Principle 18 (Recordkeeping) and §§ 38.950 and 

38.951, the designated contract market must keep 

records of all such tests, and make all test results 

available to the Commission upon request.’’ See 17 

CFR 38.1051(h). 

269 77 FR 36612 (June 19, 2012). 

270 77 FR 36664–65 (June 19, 2012). 

271Commission regulation § 37.1401(f) 

specifically provides that a swap execution facility 

shall provide to the Commission, upon request, 

current copies of its business continuity-disaster 

recovery plan and other emergency procedures, its 

assessments of its operational risks, and other 

documents requested by Commission staff for the 

purpose of maintaining a current profile of the swap 

execution facility’s automated systems. See 17 CFR 

37.1401(f). 

272Commission regulation § 37.1401(g) 

specifically provides that a swap execution facility 

shall conduct regular, periodic, objective testing 

and review of its automated systems to ensure that 

previously established certain 

definitions of ‘‘small entities’’ to be used 

by the Commission in evaluating the 

impact of its regulations on small 

entities in accordance with the RFA.260

The Commission has previously 

determined that DCMs, SEFs, and SDRs 

are not small entities for the purpose of 

the RFA.261 Therefore, the Chairman, on 

behalf of the Commission pursuant to 5 

U.S.C. 605(b), certifies that the proposed 

rules will not have a significant 

economic impact on a substantial 

number of small entities. 

B. Paperwork Reduction Act 

1. Introduction 

The Paperwork Reduction Act of 1995 

(‘‘PRA’’) 262 imposes certain 

requirements on Federal agencies, 

including the Commission, in 

connection with their conducting or 

sponsoring any collection of 

information, as defined by the PRA. An 

agency may not conduct or sponsor, and 

a person is not required to respond to, 

a collection of information unless it 

displays a currently valid control 

number. This proposed rulemaking 

contains recordkeeping and reporting 

requirements that are collections of 

information within the meaning of the 

PRA. 

The proposed rulemaking contains 

provisions that would qualify as 

collections of information, for which the 

Commission has already sought and 

obtained control numbers from the 

Office of Management and Budget 

(‘‘OMB’’). The titles for these collections 

of information are ‘‘Part 38–Designated 

Contract Markets’’ (OMB Control 

Number 3038–0052), ‘‘Part 37–Swap 

Execution Facilities’’ (OMB Control 

Number 3038–0074), and ‘‘Part 49– 

Swap Data Repositories; Registration 

and Regulatory Requirements’’ (OMB 

Control Number 3038–0086). If adopted, 

responses to these collections of 

information would be mandatory. As 

discussed below, with the exception of 

proposed § 38.1051(n) that would 

require all DCMs to submit annual 

trading volume information to the 

Commission, the Commission believes 

the proposal will not impose any new 

recordkeeping or reporting requirements 

that are not already accounted for in 

existing collections 3038–0052,263

3038–0074,264 and 3038–0086.265

Accordingly, the Commission invites 

public comment on the accuracy of its 

estimate regarding the impact of 

proposed § 38.1051(n) on collection 

3038–0052 and its determination that no 

additional recordkeeping or information 

collection requirements or changes to 

existing collection requirements would 

result from the proposal. 

The Commission will protect 

proprietary information according to the 

Freedom of Information Act (‘‘FOIA’’) 

and 17 CFR part 145, ‘‘Commission 

Records and Information.’’ In addition, 

section 8(a)(1) of the Act strictly 

prohibits the Commission, unless 

specifically authorized by the Act, from 

making public ‘‘data and information 

that would separately disclose the 

business transactions or market 

positions of any person and trade 

secrets or names of customers.’’ The 

Commission is also required to protect 

certain information contained in a 

government system of records according 

to the Privacy Act of 1974. 

2. Clarification of Collections 3038– 

0052, 3038–0074, and 3038–0086 

The Commission notes that all DCMs, 

SEFs, and SDRs are already subject to 

system safeguard-related books and 

records obligations. However, with the 

exception of business continuitydisaster recovery testing, the records 

relating to a particular system safeguard 

test or assessment are not explicitly 

addressed in the current rules. 

Therefore, as discussed above in Section 

I.E., the Commission is proposing to 

amend §§ 38.1051(g), 37.1041(g), and 

49.24(i) to clarify the system safeguardrelated books and records obligations for 

all DCMs, SEFs, and SDRs. The 

proposed regulations would require 

these entities, in accordance with 

Commission regulation § 1.31,266 to 

provide the Commission with the 

following system safeguards-related 

books and records promptly upon 

request of any Commission 

representative: (1) current copies of the 

BC–DR plans and other emergency 

procedures; (2) all assessments of the 

entity’s operational risks or system 

safeguard-related controls; (3) all reports 

concerning system safeguards testing 

and assessment required by this chapter, 

whether performed by independent 

contractors or employees of the DCM, 

SEF, or SDR; and (4) all other books and 

records requested by Commission staff 

in connection with Commission 

oversight of system safeguards pursuant 

to the Act or Commission regulations, or 

in connection with Commission 

maintenance of a current profile of the 

entity’s automated systems. The 

pertinent recordkeeping and reporting 

requirements of proposed § 38.1051(g) 

are contained in the provisions of 

current Commission regulations 

§§ 38.1051(g) 267 and (h),268 which were 

adopted on June 19, 2012 (‘‘DCM Final 

Rules’’).269 In the DCM Final Rules, the 

Commission estimated that each 

respondent subject to the part 38 

requirements would experience a 10 

percent increase, or 30 additional hours, 

in the information collection burden as 

a result of the regulations implementing 

certain core principles, including Core 

Principle 20 (System Safeguards).270

The pertinent recordkeeping and 

reporting burdens of proposed 

§ 37.1401(g) are contained in the 

provisions of current Commission 

regulations §§ 37.1041(f) 271 and (g),272


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80163 

they are reliable, secure, and have adequate scalable 

capacity. A swap execution facility shall also 

conduct regular, periodic testing and review of its 

business continuity-disaster recovery capabilities. 

The rule further provides that pursuant to Core 

Principle 10 under section 5h of the Act 

(Recordkeeping and Reporting) and §§ 37.1000 

through 37.1001, the swap execution facility shall 

keep records of all such tests, and make all test 

results available to the Commission upon request. 

See 17 CFR 37.1401(g). 

273 78 FR 33476 (June 4, 2013). 

274 78 FR 33551 (June 4, 2013). 

275Commission regulation § 49.24(i) specifically 

provides that a registered swap data repository shall 

provide to the Commission upon request current 

copies of its business continuity and disaster 

recovery plan and other emergency procedures, its 

assessments of its operational risks, and other 

documents requested by Commission staff for the 

purpose of maintaining a current profile of the swap 

data repository’s automated systems. See 17 CFR 

49.24(i). 

276Commission regulation § 49.24(j) specifically 

provides that a registered swap data repository shall 

conduct regular, periodic, objective testing and 

review of its automated systems to ensure that they 

are reliable, secure, and have adequate scalable 

capacity. It shall also conduct regular, periodic 

testing and review of its business continuitydisaster recovery capabilities. The rule further 

provides that pursuant to §§ 1.31, 49.12 and 45.2 of 

the Commission’s Regulations, the swap data 

repository shall keep records of all such tests, and 

make all test results available to the Commission 

upon request. See 17 CFR 49.24(j). 

277 76 FR 54538 (Sept. 1, 2011). 

278 76 FR 54572 (Sept. 1, 2011). 

279 75 FR 80924 (Dec. 23, 2010). 

280 In arriving at a wage rate for the hourly costs 

imposed, Commission staff used the National 

Industry-Specific Occupational Employment and 

Wage Estimates, published in May (2014 Report). 

The hourly rate for a Compliance Officer in the 

Securities and Commodity Exchanges as published 

in the 2014 Report was $44.03 per hour. 281 7 U.S.C. 19(a). 

which were adopted on June 4, 2103 

(‘‘SEF Final Rules’’).273 In the SEF Final 

Rules, the Commission estimated that 

each respondent subject to the part 37 

requirements would incur a collection 

burden of 308 hours annually as a result 

of the regulations implementing certain 

core principles, including Core 

Principle 14 (System Safeguards).274

Additionally, the pertinent 

recordkeeping and reporting 

requirements of proposed § 49.24(i) are 

contained in the provisions of current 

Commission regulations §§ 49.24(i) 275

and (j),276 which were adopted on 

September 1, 2011 (‘‘SDR Final 

Rules’’).277 In the SDR Final Rules, the 

Commission determined that the 

collection burdens created by the 

Commission’s proposed rules, which 

were discussed in detail in the 

proposing release, are identical to the 

collective burdens of the final rules.278

The Commission estimated in the 

proposing release that the total ongoing 

annual burden for all of the § 49.24 

requirements is 15,000 burden hours per 

respondent.279 The Commission 

believes that proposed §§ 38.1051(g) and 

49.24(i) would not impact the burden 

estimates currently provided for in OMB 

Control Numbers 3038–0052, 3038– 

0074, and 3038–0086. 

3. Proposed Revision to Collection 

3038–0052 

Proposed § 38.1051(n) would require 

all DCMs to provide to the Commission 

for calendar year 2015, and each 

calendar year thereafter, its annual total 

trading volume. This information would 

be required within 30 calendar days of 

the effective date of the final version of 

this rule, and for 2016 and subsequent 

years by January 31 of the following 

calendar year. The Commission believes 

that all DCMs generally calculate their 

annual trading volume in the usual 

course of business and many of the 

DCMs already publish this information 

on their Web site. Consequently, the 

Commission believes that any burden 

incurred by the DCMs as a result of 

proposed § 38.1051(n) would be 

minimal. Presently, there are 15 

registered DCMs that would be required 

to comply with proposed § 38.1051(n) 

and the burden hours for this collection 

have been estimated as follows: 

Estimated number of respondents: 15. 

Annual responses by each 

respondent: 1. 

Total annual responses: 15. 

Estimated average hours per response: 

0.5. 

Aggregate annual reporting burden: 

7.5. 

With the respondent burden for this 

collection estimated to average 0.5 

hours per response, the total annual cost 

burden per respondent is estimated to 

be $22.015. The Commission based its 

calculation on an hourly wage rate of 

$44.03 for a Compliance Officer.280

4. Information Collection Comments 

The Commission invites comment on 

any aspect of the proposed information 

collection requirements discussed 

above. Pursuant to 44 U.S.C. 

3506(c)(2)(B), the Commission will 

consider public comments on such 

proposed requirements in: (1) 

Evaluating whether the proposed 

collection of information is necessary 

for the proper performance of the 

functions of the Commission, including 

whether the information will have a 

practical use; (2) Evaluating the 

accuracy of the Commission’s estimate 

of the burden of the proposed collection 

of information, including the validity of 

the methodology and assumptions used; 

(3) Enhancing the quality, utility, and 

clarity of the information proposed to be 

collected; and (4) Minimizing the 

burden of collection of information on 

those who are to respond, including 

through the use of appropriate 

automated, electronic, mechanical, or 

other technological information 

collection techniques. 

Copies of the submission from the 

Commission to OMB are available from 

the CFTC Clearance Officer, 1155 21st 

Street NW., Washington, DC 20581, 

(202) 418–5160 or from http:// 

RegInfo.gov. Persons desiring to submit 

comments on the proposed information 

collection requirements should send 

those comments to: The Office of 

Information and Regulatory Affairs, 

Office of Management and Budget, 

Room 10235, New Executive Office 

Building, Washington, DC 20503, 

Attention: Desk Officer of the 

Commodity Futures Trading 

Commission; (202) 395–6566 (fax); or 

OIRAsubmissions@omb.eop.gov (email). 

Please provide the Commission with a 

copy of submitted comments so that all 

comments can be summarized and 

addressed in the final rulemaking, and 

please refer to the ADDRESSES section of 

this rulemaking for instructions on 

submitting comments to the 

Commission. OMB is required to make 

a decision concerning the proposed 

information collection requirements 

between thirty (30) and sixty (60) days 

after publication of the Proposal in the 

Federal Register. Therefore, a comment 

to OMB is best assured of receiving full 

consideration if OMB (as well as the 

Commission) receives it within thirty 

(30) days of publication of the Proposal. 

C. Consideration of Costs and Benefits 

1. Introduction 

Section 15(a) of the CEA requires the 

Commission to consider the costs and 

benefits of its actions before 

promulgating a regulation under the 

CEA or issuing certain orders.281

Section 15(a) further specifies that the 

costs and benefits shall be evaluated in 

light of five broad areas of market and 

public concern: (1) Protection of market 

participants and the public; (2) 

efficiency, competitiveness, and 

financial integrity of futures markets; (3) 

price discovery; (4) sound risk 

management practices; and (5) other 

public interest considerations. The 

Commission considers below the costs 

and benefits resulting from its 

discretionary determinations with 

respect to the section 15(a) factors. 

As an initial matter, the Commission 

considers the incremental costs and 

benefits of these regulations, that is the 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80164 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

282For example, to quantify benefits such as 

enhanced protections for market participants and 

the public and financial integrity of the futures and 

swaps markets would require information, data 

and/or metrics that either do not exist, or to which 

the Commission generally does not have access. 

283Committee on Payments and Market 

Infrastructures of the Bank for International 

Settlements, Cyber resilience in financial market 

infrastructures (November 2014), at 1. 

284 IOSCO and WFE, Cyber-crime, securities 

markets and systemic risk, Staff Working Paper 

(SWP2/2013) (July 16, 2013), at 3, available at 

http://www.iosco.org/research/pdf/swp/CyberCrime-Securities-Markets-and-Systemic-Risk.pdf. 

285Ponemon Institute Research Report sponsored 

by IBM, 2015 Cost of Data Brach Study: Global 

Analysis (May 2015), at 1. 

286 Id. at 2. The cost component includes the 

abnormal turnover of customers, increased 

customer acquisition activities, reputation losses 

and diminished goodwill. The growing awareness 

of identity theft and customers’ concerns about the 

security of their personal data following a breach 

has contributed to the lost business. 

287CFTC Roundtable, at 24. 

288CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

289 Id. 

290 17 CFR 38.1051(h) (for DCMs); 17 CFR 

37.1401(g) (for SEFs); 17 CFR 49.24(j) (for SDRs). 

291The Commission’s existing rules and guidance 

provide that a DCM’s, SEF’s, or SDR’s entire 

program of risk analysis and oversight, which 

includes testing, should be based on generally 

accepted standards and best practices with respect 

to the development, operation, reliability, security, 

and capacity of automated systems. See Appendix 

A to Part 37, Core Principle 14 of Section 5h of the 

Act—System Safeguards (a) Guidance (1) Risk 

analysis and oversight program (for SEFs); 17 CFR 

38.1051(h) (for DCMs); 17 CFR 49.24(j) (for SDRs). 

Each of the types of testing addressed in this 

NPRM—vulnerability testing, penetration testing, 

controls testing, security incident response plan 

testing, and enterprise technology risk assessment— 

has been a generally recognized best practice for 

system safeguards since before the testing 

requirements of the Act and the current regulations 

were adopted. The current system safeguards 

provisions of the CEA and the Commission’s 

regulations became effective in August 2012. 

Generally accepted best practices called for each 

type of testing specified in the proposed rule well 

before that date, as shown in the following 

examples. Regarding all five types of testing, see, 

e.g., NIST SP 800–53A, Rev. 1, Guide for Assessing 

the Security Controls in Federal Information 

Systems and Organizations (‘‘NIST 800–53A 

Rev.1’’), at E1, F67, F230, F148, and F226, June 

2010, available at http://csrc.nist.gov/publications/ 

nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. 

Regarding vulnerability testing, see, e.g., NIST SP 

costs and benefits that are not already 

present in the current system safeguard 

practices and requirements under the 

Act and the Commission’s regulations 

for DCMs, SEFs, and SDRs. Where 

reasonably feasible, the Commission has 

endeavored to estimate quantifiable 

costs and benefits. Where quantification 

is not feasible, the Commission 

identifies and describes costs and 

benefits qualitatively.282

As discussed below, the Commission 

has identified certain costs and benefits 

associated with some of the proposed 

regulations and requests comment on all 

aspects of its proposed consideration of 

costs and benefits, including 

identification and assessment of any 

costs and benefits not discussed herein. 

In particular, the Commission requests 

that commenters provide data and any 

other information or statistics that the 

commenters relied on to reach any 

conclusions regarding the Commission’s 

proposed consideration of costs and 

benefits, including the series of 

questions at the end of this section. 

2. Background and Baseline for the 

Proposal 

As discussed above in Section I.A., 

the Commission believes that the 

current cyber threats to the financial 

sector, including DCMs, SEFs, and SDRs 

regulated by the Commission, have 

expanded over the course of recent 

years. According to the Committee on 

Payments and Market Infrastructures of 

the Bank for International Settlements, 

‘‘Cyber attacks against the financial 

system are becoming more frequent, 

more sophisticated and more 

widespread.’’ 283 A survey of 46 global 

securities exchanges conducted by 

IOSCO and the WFE found that as of 

July 2013, over half of exchanges worldwide had experienced a cyber attack 

during the previous year.284 The 

Ponemon Institute 2015 Cost of Data 

Breach Study, which included 350 

companies, found that the average cost 

of a data breach is $3.79 million, which 

represents a 23 percent increase from 

the 2014 study.285 Moreover, the study 

concluded that the consequences of lost 

business are having a greater impact on 

the cost of a data breach with the 

average cost increasing from $1.33 

million last year to $1.57 million this 

year.286 Accordingly, the current cyber 

threat environment highlights the need 

to consider an updated regulatory 

framework with respect to cybersecurity 

testing for DCMs, SEFs, and SDRs. 

Although the Commission 

acknowledges that the proposal would 

likely result in some additional costs, 

particularly for some covered DCMs and 

SDRs, the proposal would also bring 

several overarching benefits to the 

futures and swaps industry. A 

comprehensive cybersecurity testing 

program is important to efforts by the 

regulated entities to harden cyber 

defenses, to mitigate operations, 

reputation, and financial risk, and to 

maintain cyber resilience and ability to 

recover from cyber attack.287

Significantly, to ensure the effectiveness 

of cybersecurity controls, a financial 

sector entity must test in order to find 

and fix its vulnerabilities before an 

attacker exploits them. 

The Commission recognizes that any 

economic effects, including costs and 

benefits, should be compared to a 

baseline that accounts for current 

regulatory requirements. The baseline 

for this cost and benefit consideration is 

the set of existing requirements under 

the Act and the Commission’s 

regulations for DCMs, SEFs, and SDRs. 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.288 The Act 

also mandates that each DCM, SEF, and 

SDR must develop and maintain 

automated systems that are reliable, 

secure, and have adequate scalable 

capacity, and must ensure system 

reliability, security, and capacity 

through appropriate controls and 

procedures.289 The Commission’s 

existing system safeguards rules for 

DCMs, SEFs, and SDRs mandate that, in 

order to achieve these statutory 

requirements, each DCM, SEF, and SDR 

must conduct testing and review 

sufficient to ensure that its automated 

systems are reliable, secure, and have 

adequate scalable capacity.290

As discussed above, the Commission 

proposes to clarify the system 

safeguards and cybersecurity testing 

requirements of its existing rules for 

DCMs, SEFs, and SDRs, by specifying 

and defining five types of system 

safeguards testing that a DCM, SEF, or 

SDR necessarily must perform to fulfill 

the testing requirement. Each of the 

types of testing and assessment that 

would be required under the proposed 

rule—vulnerability testing, penetration 

testing, controls testing, security 

incident response plan testing, and 

enterprise technology risk assessment— 

is a generally recognized best practice 

for system safeguards, as discussed 

above and discussed in detail below. 

Moreover, the Commission believes, as 

the generally accepted standards and 

best practices noted in this NPRM make 

it clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

each type of testing addressed by the 

proposed rule. This has been true since 

before the testing requirements of the 

Act and the current regulations were 

adopted, and it would be true today 

even if the Commission were not issuing 

this NPRM.291 Accordingly, as 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80165 

800–53A Rev. 1, at F67, June 2010, available at 

http://csrc.nist.gov/publications/nistpubs/800-53Arev1/sp800-53A-rev1-final.pdf; and NIST SP 800– 

115, Technical Guide to Information Security 

Testing and Assessment, at 5–2, September 2008, 

available at http://csrc.nist.gov/publications/ 

nistpubs/800-115/SP800-115.pdf . Regarding 

penetration testing, see, e.g., NIST Special 

Publication (‘‘SP’’) 800–53A, Rev. 1, at E1, June 

2010, available at: http://csc.nist.gov/publications/ 

nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; 

and NIST 800–115, at 4–4, September 2008, 

available at: http://csrc.nist.gov/publications/ 

nistpubs/800-115/SP800-115.pdf. Regarding 

controls testing, see, e.g., NIST 800–53A, Rev. 1, at 

13 and Appendix F1, June 2010, available at http:// 

csrc.nist.gov/publications/nistpubs/800-53A-rev1/ 

sp800-53A-rev1-final.pdf. Regarding security 

incident response plan testing, see, e.g., NIST 800– 

53A, Rev. 1, at F148, June 2010, available at http:// 

csrc.nist.gov/publications/nistpubs/800-53A-rev1/ 

sp800-53A-rev1-final.pdf. Regarding enterprise 

technology risk assessment, see, e.g., NIST 800– 

53A, Rev.1, at F226, June 2010, available at http:// 

csrc.nist.gov/publications/nistpubs/800-53A-rev1/ 

sp800-53A-rev1-final.pdf. 

292The Commission notes that the DCMs and 

SDRs that provided the information for the DMO 

Preliminary Survey requested confidential 

treatment. Additionally, because the Commission’s 

cost estimates are only based on preliminary data 

from some DCMs and SDRs, the Commission is 

including questions throughout the consideration of 

costs and benefits section for commenters to 

provide the Commission with specific cost 

estimates regarding the proposed rules. 

293By definition, averages are meant to serve only 

as a reference point; the Commission understands 

that due to the nature of the proposed requirements 

in relation to the current practices at a covered 

DCM or an SDR, some entities may go above the 

average while others may stay below. 

294Commission staff conduct system safeguard 

examinations (‘‘SSEs’’) to evaluate DCMs’ 

compliance with Core Principle 20 (System 

Safeguards) and Commission regulations §§ 38.1050 

and 38.1051. See 17 CFR 38.1050 and 38.1051. With 

respect to SDRs, Commission staff conduct SSEs to 

evaluate SDRs’ compliance with Commission 

regulation § 49.24. See 17 CFR 49.24. 

295The Commission believes that the proposed 

requirement in §§ 38.1051(c), 37.1041(c), and 

49.24(d) that would require all DCMs (covered and 

non-covered), SEFs, and SDRs to update BC–DR 

plans and emergency procedures no less frequently 

than annually will impose new costs relative to the 

current requirements. Additionally, the proposed 

provisions that would make it mandatory for such 

entities to follow best practices, ensure tester 

independence, and coordinate BC–DR plans will 

also impose new costs relative to the current 

requirements. The Commission also expects that all 

DCMs will incur additional costs as a result of 

proposed requirement in § 38.1051(n) for the 

reporting of annual trading volume to the 

Commission. 

296Based on information obtained from the DMO 

Preliminary Survey and the Commission’s system 

safeguard compliance program, the Commission 

understands that most covered DCMs and SDRs 

currently conduct system safeguard testing at the 

proposed minimum frequency for most of the five 

tests in the proposal. Additionally, the Commission 

understands that most covered DCMs and SDRs 

currently engage independent contractors for the 

testing required by the proposal. 

discussed below in this consideration of 

costs and benefits section, the 

Commission believes that, with the 

exception of the minimum testing 

frequency and independent contractor 

requirements for covered DCMs and 

SDRs, the proposed rules calling for 

each DCM, SEF, and SDR to conduct 

each of these types of testing and 

assessment will not impose any new 

costs on DCMs, SEFs, and SDRs. If 

compliance with the clarified testing 

requirements proposed herein results in 

costs to DCMs, SEFs, and SDRs, the 

Commission believes that those are 

costs associated with compliance with 

existing testing requirements and not 

the proposed rules. 

To assist the Commission in its 

understanding of the current system 

safeguard practices at DCMs and SDRs, 

Commission staff collected some 

preliminary information from some 

DCMs and SDRs regarding their current 

costs associated with conducting 

vulnerability testing, external and 

internal penetration testing, controls 

testing, and enterprise technology risk 

assessments (‘‘DMO Preliminary 

Survey’’).292 Some of the cost estimates 

provided by the DCMs and SDRs 

included estimates at the parent 

company level of the DCM and SDR as 

the entities were unable to apportion the 

actual costs to a particular entity within 

their corporate structure, within which 

entities may share the same automated 

systems and system safeguard programs. 

In some cases, apportioning costs could 

be further complicated by sharing of 

system safeguards among DCMs, SEFs, 

SDRs, or DCOs. Therefore, in the data 

collected for the DMO Preliminary 

Survey, it is difficult in some cases to 

distinguish between the system 

safeguard-related costs of DCMs, SEFs, 

SDRs, and DCOs. In light of the above 

factors, the cost estimates discussed 

below are simple cost averages of the 

affected entities’ estimates, without 

regard to the type of entity.293 The data 

from the DMO Preliminary Survey, 

information received by Commission 

staff in administering the Commission’s 

system safeguard program,294 and 

information the Commission received 

during the CFTC Roundtable on March 

18, 2015, are reflected below in the 

Commission’s effort to estimate the 

costs and benefits of the proposal. 

As noted above, and discussed more 

fully below, the Commission believes 

that to the extent that the proposal will 

impose additional costs, such costs will 

primarily impact covered DCMs (as 

defined) and SDRs as a result of the 

minimum testing frequency and 

independent contractor 

requirements.295 The Commission 

expects that the costs and benefits may 

vary somewhat among the covered 

DCMs and SDRs. In this same regard, 

the Commission notes that some 

covered DCMs and SDRs are larger or 

more complex than others, and the 

proposed requirements may impact 

covered DCMs and SDRs differently 

depending on their size and the 

complexity of their systems.296 The 

Commission recognizes that it is not 

possible to precisely estimate the 

additional costs for covered DCMs and 

SDRs that may be incurred as a result of 

this rulemaking, as the actual costs will 

be dependent on the operations and 

staffing of the particular covered DCM 

and SDR, and to some degree, the 

manner in which they choose to 

implement compliance with the 

proposed new requirements. The 

Commission is sensitive to the 

economic effects of the proposed 

regulations, including costs and 

benefits. Accordingly, the Commission 

seeks comment on the costs and benefits 

associated with the proposed 

regulations, including, where possible, 

quantitative data. 

While certain costs are amenable to 

quantification, other costs are not easily 

estimated, such as the costs to the 

public or market participants in the 

event of a cybersecurity incident at a 

DCM, SEF, or SDR. The public interest 

is served by these critical infrastructures 

performing their functions. The 

Commission’s proposed regulations are 

intended to mitigate the frequency and 

severity of system security breaches or 

functional failures, and therefore, 

provide an important if unquantifiable 

benefit to the public interest. Although 

the benefits of effective regulation are 

difficult to estimate in dollar terms, the 

Commission believes that they are of 

equal importance in light of the 

Commission’s mandate to protect 

market participants and the public and 

to promote market integrity. 

The discussion of costs and benefits 

that follows begins with a summary of 

each proposed regulation and a 

consideration, where appropriate, of the 

corresponding costs and benefits. At the 

conclusion of this discussion, the 

Commission considers the costs and 

benefits of the proposed regulations 

collectively in light of the five factors 

set forth in section 15(a) of the CEA. 

3. Categories of Risk Analysis and 

Oversight: Sections 38.1051(a), 

37.1401(a), and 49.24(b) 

a. Summary of Proposed Rules 

As discussed above in Section I.B., 

the proposed rules would, among other 

things, add enterprise risk management 

and governance to the list of required 

categories of system safeguards-related 

risk analysis and oversight. 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80166 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

297 17 CFR 38.1050(a) (for DCMs); 17 CFR 

37.1400(a) (for SEFs); and 17 CFR 49.24(a)(1) (for 

SDRs). 

298See § 38.1051(b) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (1) Risk analysis 

and oversight program (for SEFs); § 49.24(c) (for 

SDRs). 

299See § 38.1051(h) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (2) Testing (for 

SEFs); § 49.24(j) (for SDRs). 

300See § 38.1051(i) (for DCMs); Appendix A to 

Part 37, Core Principle 14 of Section 5h of the Act— 

System Safeguards (a) Guidance (3) Coordination 

(for SEFs); § 49.24(k) (for SDRs). 

301Commission regulations §§ 38.1051(c) (for 

DCMs), 37.1401(b) (for SEFs), and 49.24(d) (for 

SDRs); 17 CFR 38.1051(c); 17 CFR 37.1401(b); 17 

CFR 49.24(d). 

302The Commission understands from 

conducting its oversight of DCMs, SEFs, and SDRs 

that many of these entities currently update their 

respective BC–DR plans and emergency procedures 

at least annually. 

303NIST SP 800–53 Rev. 4, Physical and 

Environmental Protection (PE) control family, 

available at http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53r4.pdf; FFIEC, 

Operations IT Examination Handbook, at 15–18, 

available at http://ithandbook.ffiec.gov/ITBooklets/ 

FFIEC_ITBooklet_Operations.pdf. 

304Commission regulation § 1.31(a)(1) 

specifically provides that ‘‘all books and records 

required to be kept by the Act or by these 

regulations shall be kept for a period of five years 

from the date thereof and shall be readily accessible 

during the first 2 years of the 5-year period.’’ The 

rule further provides that ‘‘all such books and 

records shall be open to inspection by any 

representative of the Commission or the United 

States Department of Justice.’’ See 17 CFR 

1.31(a)(1). 

b. Costs and Benefits 

As discussed in the preamble, the 

Commission believes that enterprise risk 

management and governance is implicit 

in the Commission’s existing system 

safeguard regulations, which already 

require each DCM, SEF, and SDR to 

maintain a program of risk analysis and 

oversight with respect to system 

safeguards.297 The proposed rules 

would make enterprise risk management 

and governance an explicitly listed 

category for the sake of clarity. The 

Commission believes that this 

clarification will not impose any new 

costs for DCMs, SEFs, and SDRs. 

4. Requirements to Follow Best 

Practices, Ensure Testing Independence, 

and Coordinate BC–DR Plans: Sections 

for Best Practices—38.1051(b); 

37.1401(b); and § 49.24(c). Sections for 

Tester Independence—38.1051(h)(2)(iv), 

(3)(i)(C), (3)(ii)(B), (4)(iii), (5)(iv), and 

(6)(ii); 37.1401(h)(2)(i), (3)(i)(A), (4)(i), 

(5)(iii), and (6)(i); and 49.24(j)(2)(iii), 

(3)(i)(B), (4)(ii), (5)(iv), and (6)(ii). 

Sections for BC–DR Plans—38.1051(i); 

§ 37.1401(i); and § 49.24(k) 

a. Summary of Proposed Rules 

As discussed above in Section I.C., 

the proposed rules would make the 

existing provisions with respect to 

following best practices, ensuring tester 

independence, and coordinating BC–DR 

plans mandatory for DCMs, SEFs, and 

SDRs. 

b. Costs 

As discussed in the preamble, the 

Commission’s existing rules for DCMs 

and SDRs and its guidance for SEFs 

provide that such entities should follow 

best practices in addressing the 

categories which their programs of risk 

analysis and oversight are required to 

include.298 They provide that such 

entities should ensure that their system 

safeguards testing, whether conducted 

by contractors or employees, is 

conducted by independent professionals 

(persons not responsible for 

development or operation of the systems 

or capabilities being tested).299 They 

further provide that such entities should 

coordinate their BC–DR plans with the 

BC–DR plans of market participants and 

essential service providers.300 In light of 

the language in the proposed rules that 

would make these provisions 

mandatory, the proposed rules will 

impose new costs relative to the current 

requirements. However, the 

Commission does not have 

quantification or estimation of these 

potential costs. 

c. Benefits 

Making the provisions mandatory will 

align the system safeguards rules for 

DCMs, SEFs, and SDRs with the 

Commission’s system safeguards rules 

for DCOs, which already contain 

mandatory provisions in these respects. 

The Commission believes that in today’s 

cybersecurity threat environment, 

following generally accepted standards 

and best practices, ensuring tester 

independence, and coordinating BC–DR 

plans appropriately are essential to 

adequate system safeguards and cyber 

resiliency for DCMs, SEFs, and SDRs. 

The Commission also believes that 

clarity concerning necessary 

requirements in these respects will 

benefit DCMs, SEFs, and SDRs, their 

market participants and customers, and 

the public interest. 

d. Request for Comments 

The Commission requests comment 

on the potential costs and benefits 

associated with the proposed provisions 

that would make it mandatory for 

DCMs, SEFs, and SDRs to follow best 

practices, ensure tester independence, 

and coordinate BC–DR plans, including, 

where possible, quantitative data. 

5. Updating of Business ContinuityDisaster Recovery Plans and Emergency 

Procedures: Sections 38.1051(c), 

37.1401(c), and 49.24(d). 

a. Summary of Proposed Rules 

As discussed above in Section I.D., 

the proposed rules would require a 

DCM, SEF, or SDR to update its BC–DR 

plan and emergency procedures at a 

frequency determined by an appropriate 

risk analysis, but at a minimum no less 

frequently than annually. 

b. Costs 

The Commission’s existing rules 

provide that DCMs, SEFs, and SDRs 

must maintain BC–DR plans and 

emergency procedures, but do not 

specify a frequency in which such plans 

and procedures must be updated.301 The 

proposed rules will impose new costs 

relative to the requirements of the 

current rules.302 However, the 

Commission does not have 

quantification or estimation of these 

potential costs. 

c. Benefits 

The Commission notes that updating 

BC–DR plans and emergency procedures 

at least annually is a generally accepted 

best practice, as it follows NIST and 

other standards. These standards 

highlight the importance of updating 

such plans and procedures at least 

annually to help enable the organization 

to better prepare for cyber security 

incidents. Specifically, the NIST 

standards provide that once an 

organization has developed a BC–DR 

plan, ‘‘the organization should 

implement the plan and review it at 

least annually to ensure the organization 

is following the roadmap for maturing 

the capability and fulfilling their [sic] 

goals for incident response.’’ 303

d. Request for Comments 

The Commission requests comment 

on the potential costs and benefits 

associated with complying with 

proposed regulations §§ 38.1051(c), 

37.1401(c), and 49.24(d), including, 

where possible, quantitative data. 

6. Required system safeguards-related 

books and records obligations: Sections 

38.1051(g), 37.1041(g), and 49.24(i) 

a. Summary of Proposed Rules 

As discussed above in Section I.E., 

proposed §§ 38.1051(g), 37.1401(g), and 

49.24(i) would require a DCM, SEF, or 

SDR, in accordance with Commission 

regulation § 1.31,304 to provide the 

Commission with the following system 

safeguards-related books and records 

promptly upon request of any 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80167 

305CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

306 Id. 

307Commission regulations §§ 38.1051(h) (for 

DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for 

SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 

17 CFR 49.24(j). 

308See supra note 291. 

Commission representative: (1) Current 

copies of the BC–DR plans and other 

emergency procedures; (2) all 

assessments of the entity’s operational 

risks or system safeguards-related 

controls; (3) all reports concerning 

system safeguards testing and 

assessment required by this chapter, 

whether performed by independent 

contractors or employees of the DCM, 

SEF, or SDR; and (4) all other books and 

records requested by Commission staff 

in connection with Commission 

oversight of system safeguards pursuant 

to the Act or Commission regulations, or 

in connection with Commission 

maintenance of a current profile of the 

entity’s automated systems. 

b. Costs 

As discussed more fully above in the 

PRA section, all DCMs, SEFs, and SDRs 

are already subject to system safeguardrelated books and records requirements. 

However, with the exception of BC–DR 

testing, the records relating to a 

particular system safeguard test or 

assessment are not explicitly addressed 

in the current rules. Therefore, the 

Commission is proposing §§ 38.1051(g), 

37.1401(g), and 49.24(i) to clarify the 

system safeguard recordkeeping and 

reporting requirements for these 

entities. The Commission notes that the 

pertinent recordkeeping and reporting 

requirements of proposed § 38.1051(g) 

are contained in the provisions of 

current Commission regulations 

§§ 38.1051(g) and (h). The pertinent 

recordkeeping and reporting 

requirements of proposed § 37.1041(g) 

are contained in the provisions of 

current §§ 37.1041(f) and (g). In 

addition, the pertinent recordkeeping 

and reporting requirements of proposed 

§ 49.24(i) are contained in the 

provisions of current Commission 

regulations §§ 49.24(i) and (j). Because 

the production of system-safeguard 

records is already required by the 

current rules, the Commission believes 

that the proposed rules would not 

impose any additional costs on DCMs, 

SEFs, and SDRs. 

c. Benefits 

The recordkeeping requirements for 

DCMs, SEFs, and SDRs allow the 

Commission to fulfill its oversight role 

and effectively monitor a DCM’s, SEF’s, 

or SDR’s system safeguards program and 

compliance with the Act and the 

Commission’s regulations. In addition, 

such requirements enable Commission 

staff to perform efficient examinations 

of DCMs, SEFs, and SDRs, and increase 

the likelihood that Commission staff 

may identify conduct inconsistent with 

the requirements. Further, making all 

system safeguard-related documents 

available to the Commission upon 

request informs the Commission of areas 

of potential weaknesses, or persistent or 

recurring problems, across the DCMs, 

SEFs, and SDRs. 

7. Definitions: Sections 38.1051(h)(1), 

37.1041(h)(1), and 49.24(j)(1) 

a. Summary of Proposed Rules 

Proposed §§ 38.105(h)(1), 

37.1041(h)(1), and 49.24(j)(1) would 

include definitions for the following 

terms: (1) Controls; (2) controls testing; 

(3) enterprise technology risk 

assessment; (4) external penetration 

testing; (5) internal penetration testing; 

(6) key controls; (7) security incident; 

(8) security incident response plan; (9) 

security incident response plan testing; 

and (10) vulnerability testing. 

Additionally, § 38.105(h)(1) would 

include the definition for covered 

designated contract market. 

b. Costs and Benefits 

The proposed definitions simply 

provide context to the specific system 

safeguard tests and assessments that a 

DCM, SEF, or SDR would be required to 

conduct on an ongoing basis. 

Accordingly, the costs and benefits of 

these terms are attributable to the 

substantive testing requirements and, 

therefore, are discussed in the cost and 

benefit considerations related to the 

rules describing the requirements for 

each test. 

8. Vulnerability Testing: Sections 

38.1051(h)(2), 37.1401(h)(2), and 

49.24(j)(2) 

a. Summary of Proposed Rules 

As discussed above in Section I.F.3., 

proposed §§ 38.1051(h)(1), 

37.1401(h)(1), and 49.24(j)(1) would 

define vulnerability testing as testing of 

a DCM’s, SEF’s, or SDR’s automated 

systems to determine what information 

may be discoverable through a 

reconnaissance analysis of those 

systems and what vulnerabilities may be 

present on those systems. The proposed 

rules would require a DCM, SEF, or SDR 

to conduct vulnerability testing that is 

sufficient to satisfy the testing scope 

requirements in proposed §§ 38.1051(k), 

37.1401(k), and 49.24(l), at a frequency 

determined by an appropriate risk 

analysis. Vulnerability testing would 

include automated vulnerability 

scanning, with some such scanning to 

be conducted on an authenticated basis 

(e.g., using log-in credentials). Where 

scanning is conducted on an 

unauthenticated basis, implementation 

of effective compensating controls 

would be required. At a minimum, 

covered DCMs and SDRs would be 

required to conduct vulnerability testing 

no less frequently than quarterly. 

Covered DCMs and SDRs would be 

required to engage independent 

contractors to perform two of the 

required quarterly tests each year, 

although the entity could have other 

vulnerability testing conducted by 

employees not responsible for 

development or operation of the systems 

or capabilities being tested. 

b. Costs 

1. Vulnerability Testing Requirement for 

All DCMs, SEFs, and SDRs 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.305 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.306

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.307

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

vulnerability testing. The proposed 

rules clarify the existing testing 

requirements by specifying vulnerability 

testing as a necessary component. The 

Commission believes that this has 

always been the case.308 If compliance 

with the existing testing requirements as 

clarified by the proposed rules results in 

costs to a DCM, SEF, or SDR beyond 

those it already incurs in this 

connection, the Commission believes 

that such additional costs would be 

attributable to compliance with the 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80168 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

309While the existing system safeguards rules 

provide that all DCMs must conduct testing to 

ensure the reliability, security, and capacity of their 

automated systems, and thus to conduct 

vulnerability testing, external and internal 

penetration testing, controls testing, enterprise 

technology risk assessments, and to have and test 

security incident response plans in a way governed 

by appropriate risk analysis, the proposed rules 

would avoid applying the addition minimum 

frequency requirements to non-covered DCMs in 

order to give smaller markets with fewer resources 

somewhat more flexibility regarding the testing they 

must conduct. The Commission believes that such 

a reduced burden for smaller DCMs may be 

appropriate, in light of the fact that they will still 

be required to conduct such testing and 

assessments, and to have security incident response 

plans, pursuant to the existing system safeguards 

rules for DCMs. 

310See Commission regulations §§ 38.1051(h) (for 

DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 

17 CFR 49.24(j). 

311Based on the information collected in the 

DMO Preliminary Survey, the Commission 

understands that most covered DCMs and SDRs 

currently conduct vulnerability testing at the 

proposed frequency. 

312PCI DSS standards, 11.2, at 94, available at 

https://www.pcisecuritystandards.org/security_

standards/index.php. 

313 Id. 

314Based on the information collected in the 

DMO Preliminary Survey, the Commission 

understands that some covered DCMs and SDRs 

may not be engaging independent contractors at all, 

or may not be engaging such contractors at a 

frequency that would satisfy proposed frequency 

requirement. 

315See CFTC Roundtable, at 88–89; NIST SP 800– 

115, at 6–6, available at http://csrc.nist.gov/

publications/nistpubs/800-115/SP800-115.pdf; 

FFIEC, Information Security IT Examination 

Handbook, at 81, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf; PCI–DSS Version 3.1, 

Requirement 11, Regularly test security systems and 

processes, at 94–96, available at https://

www.pcisecuritystandards.org/security_standards/

index.php. 

316 During the CFTC Roundtable, one of the 

participants noted the difficulty in providing cost 

estimates for vulnerability and penetration testing, 

but emphasized that vulnerability testing is 

generally automated while penetration testing is 

usually more manual. See CFTC Roundtable, at 98. 

317See Security Standards Council, PCI–DSS 

Information Supplement: Penetration Testing 

Guidance, p. 3, available at: https://

www.pcisecuritystandards.org/documents/

Penetration_Testing_Guidance_March_2015.pdf. 

existing regulations and not to the 

proposed rules. Accordingly, the 

Commission believes that this 

clarification will not impose any new 

costs for DCMs, SEFs, and SDRs. 

2. Minimum Vulnerability Testing 

Frequency Requirements for Covered 

DCMs and SDRs 

As discussed above, the proposed 

rules would require covered DCMs and 

SDRs to conduct vulnerability testing no 

less frequently than quarterly.309 The 

current rules require DCMs and SDRs to 

conduct regular, periodic, objective 

testing of their automated systems.310

Accordingly, the proposed rules will 

impose new costs relative to the 

requirements of the current rules.311

The Commission notes that the 

proposed frequency comports with 

industry best practices.312

3. Independent Contractor Requirement 

for Covered DCMs and SDRs 

As discussed above, the proposed 

rules would require at least two of the 

required quarterly vulnerability tests 

each year to be conducted by an 

independent contractor. Current 

regulations §§ 38.1051(h) and 49.24(j) 

provide that testing of automated 

systems should be conducted by 

qualified, independent professionals.313

The qualified independent professionals 

may be independent contractors or 

employees of a DCM or SDR as long as 

they are not responsible for 

development or operation of the systems 

or capabilities being tested. 

Accordingly, the proposed independent 

contractor requirement will impose new 

costs relative to the requirements of the 

current rules.314 The Commission notes 

that best practices also support the use 

of independent contractors to conduct 

vulnerability testing.315

4. Cost Estimates for Covered DCMs and 

SDRs 

The Commission’s preliminary cost 

estimate for vulnerability testing, based 

on data collected from the DMO 

Preliminary Survey, suggests that on 

average, a covered DCM or SDR 

currently spends approximately 

$3,495,000 annually.316 The data also 

suggests that with respect to the entities 

that currently use independent 

contractors to conduct vulnerability 

testing, a covered DCM or SDR spends 

approximately $71,500 to hire an 

independent contractor to conduct one 

vulnerability test annually and $143,000 

to conduct two tests annually. In 

providing these estimates, the 

Commission recognizes that the actual 

costs may vary widely as a result of 

many factors, including the size of the 

organization, the complexity of the 

automated systems, and the scope of the 

test. Where a covered DCM or SDR does 

not currently use an independent 

contractor to conduct any vulnerability 

tests, the Commission expects that such 

entities may also incur some additional 

minor costs as a result of the need to 

establish and implement internal 

policies and procedures that are 

reasonably designed to address the 

workflow associated with the test. For 

example, the Commission expects that 

such policies and procedures may 

include communication and 

cooperation between the entity and 

independent contractor, communication 

and cooperation between the entity’s 

legal, business, technology, and 

compliance departments, appropriate 

authorization to remediate 

vulnerabilities identified by the 

independent contractor, implementation 

of the measures to address such 

vulnerabilities, and verification that 

these measures are effective and 

appropriate. Moreover, although the 

Commission believes that all covered 

DCMs and SDRs have substantial 

policies and procedures in place for 

vulnerability testing conducted by 

internal staff, the Commission 

acknowledges that affected entities who 

do not already use independent 

contractors for some vulnerability 

testing may need to dedicate time to 

reviewing and revising their existing 

policies and procedures to ensure that 

they are sufficient in the context of the 

proposed requirements. The 

Commission believes that any costs 

incurred by the entities as result of such 

review would be minor. 

c. Benefits 

Vulnerability testing identifies, ranks, 

and reports vulnerabilities that, if 

exploited, may result in an intentional 

or unintentional compromise of a 

system.317 The complex analysis and 

plan preparation that a DCM, SEF, or 

SDR undertakes to complete 

vulnerability testing, including 

designing and implementing changes to 

existing plans, are likely to contribute to 

a better ex ante understanding by the 

DCM’s, SEF’s, or SDR’s management of 

the challenges the entity would face in 

a cyber threat scenario, and thus better 

preparation to meet those challenges. 

This improved preparation in turn helps 

reduce the possibility of market 

disruptions. Regularly conducting 

vulnerability tests enables a DCM, SEF, 

or SDR to mitigate the impact that a 

cyber threat to, or a disruption of, a 

DCM’s, SEF’s, or SDR’s operations 

would have on market participants, 

parties required by the Act or 

Commission regulations to report swaps 

data to SDRs, and, more broadly, the 

stability of the U.S. financial markets. 

Accordingly, the Commission believes 

that such testing strengthens a DCM’s, 

SEF’s, and SDR’s automated systems, 

thereby protecting market participants 

and swaps data reporting parties from a 

disruption in services. 

With respect to the proposed 

minimum frequency requirement for 

covered DCMs and SDRs, the 

Commission believes that such entities 

have a significant incentive to conduct 

vulnerability testing at least quarterly in 

order to identify the latest threats to the 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80169 

318PCI DSS, Requirement 11.2 Regularly test 

security systems and processes, at 94, available at 

https://www.pcisecuritystandards.org/security_

standards/index.php. 

319CFTC Roundtable, at 88. 

320 Id. at 88–89. 

321 Id. at 177. 

322 Id. at 171. 

323See NIST SP 800–115, at 6–6, available at 

http://csrc.nist.gov/publications/nistpubs/800-115/

SP800-115.pdf; FFIEC, Information Security IT 

Examination Handbook, at 81, available at http:// 

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf; ISACA, COBIT 5, 

MEA02.05, Ensure that assurance providers are 

independent and qualified, available at https://

cobitonline.isaca.org/. 

324CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

325 Id. 

326Commission regulations §§ 38.1051(h) (for 

DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for 

SEFs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 

17 CFR 49.24(j). 

327See supra note 291. 

organization and reduce the likelihood 

that attackers could exploit 

vulnerabilities. Best practices support 

the requirement that vulnerability 

testing be conducted no less frequently 

than quarterly. For example, PCI DSS 

standards provide that entities should 

run internal and external network 

vulnerability scans ‘‘at least quarterly,’’ 

as well as after any significant network 

changes, new system component 

installations, firewall modifications, or 

product upgrades.318 Moreover, the 

Commission believes that the proposed 

frequency requirement will give 

additional clarity to covered DCMs and 

SDRs concerning what is required of 

them in this respect. 

As noted above, the proposed rules 

would also require covered DCMs and 

SDRs to engage independent contractors 

to conduct two of the required quarterly 

vulnerability tests each year, while 

providing covered DCMs and SDRs with 

the flexibility to conduct other 

vulnerability testing using employees 

not responsible for development or 

operation of the systems or capabilities 

being tested. Consistent with the views 

shared by the panelists at the CFTC 

Roundtable, the Commission believes 

there are important benefits when a 

testing program includes both testing by 

independent contractors and testing by 

entity employees not responsible for 

building or operating the system being 

tested. One participant in the CFTC 

Roundtable noted, ‘‘[t]here are 

advantages to both, but neither can 

stand alone.’’ 319 Much testing needs to 

happen internally, but much also needs 

to be conducted from the viewpoint of 

an outsider, particularly where testing 

against the possible tactics or 

techniques of a particular threat actor is 

concerned.320 With respect to testing 

conducted by entity employees, one 

benefit is that internal vulnerability 

testing and scanning can utilize 

viewpoints that the outside world 

would not have, based on intimate 

knowledge of the entity’s network and 

systems.321 An additional benefit 

provided by independent contractor 

testing comes from the outsider’s 

different perspective, and his or her 

ability to look for things that entity 

employees may not have contemplated 

during the design or operation of the 

system involved.322 The Commission 

also notes that best practices support 

having testing conducted by both 

independent contractors and entity 

employees.323 Accordingly, the 

Commission believes the proposed rules 

are appropriate and would strike the 

appropriate balance between both entity 

employees and independent contractors 

conducting the vulnerability tests. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of vulnerability testing, 

including the minimum testing 

frequency and independent contractor 

requirement, and the extent to which 

the proposed rules clarify the standard. 

The Commission particularly solicits 

comments concerning the need for 

vulnerability testing and the associated 

costs and benefits, from DCMs, SEFs, 

and SDRs, from futures and swap 

market participants, from best practices 

and standards organizations, from 

cybersecurity service providers and 

cybersecurity experts in both the private 

and public sectors, and from other 

financial regulators. 

9. External Penetration Testing: Sections 

38.1051(h)(3)(i), 37.1401(h)(3)(i), and 

49.24(j)(3)(i) 

a. Summary of Proposed Rules 

As discussed above in Section I.F.4., 

proposed §§ 38.1051(h)(1), 

37.1401(h)(1), and 49.24(j)(1) would 

define external penetration testing as 

attempts to penetrate a DCM’s, SEF’s or 

SDR’s automated systems from outside 

the systems’ boundaries to identify and 

exploit vulnerabilities. The proposed 

rules would require a DCM, SEF, or SDR 

to conduct external penetration testing 

that is sufficient to satisfy the scope 

requirements in proposed §§ 38.1051(k), 

37.1401(k), and 49.24(l), at a frequency 

determined by an appropriate risk 

analysis. At a minimum, covered DCMs 

and SDRs would be required to conduct 

external penetration testing no less 

frequently than annually. Covered 

DCMs and SDRs would also be required 

to engage independent contractors to 

perform the required annual external 

penetration test, although the entity 

could have other external penetration 

testing conducted by employees not 

responsible for development or 

operation of the systems or capabilities 

being tested. 

b. Costs 

1. External Penetration Testing for All 

DCMs, SEFs, and SDRs 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.324 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.325

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.326

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

external penetration testing. 

The proposed rules clarify the 

existing testing requirements by 

specifying external penetration testing 

as a necessary component. The 

Commission believes it has always been 

the case.327 If compliance with the 

existing testing requirements as clarified 

by the proposed rules results in costs to 

a DCM, SEF, or SDR beyond those it 

already incurs in this connection, the 

Commission believes that such 

additional costs would be attributable to 

compliance with the existing 

regulations and not to the proposed 

rules. Accordingly, the Commission 

believes that this clarification will not 

impose any new costs for DCMs, SEFs, 

and SDRs. 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80170 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

328See Commission regulations §§ 38.1051(h) (for 

DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 

17 CFR 49.24(j). 

329Based on the information collected in the 

DMO Preliminary Survey, the Commission 

understands that most covered DCMs and SDRs 

currently conduct external penetration testing at the 

proposed frequency. 

330NIST, SP 800–115, Technical Guide to 

Information Security Testing and Assessment, 

Section 5.2.2, at 5–5, available at http://

csrc.nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf. 

331 Id. 

332Based on the information collected in the 

DMO Preliminary Survey, the Commission 

understands that most covered DCMs and SDRs 

currently engage independent contractors to 

conduct external penetration testing. 

333Council on CyberSecurity, CSC 20–1, available 

at http://www.counciloncybersecurity.org/criticalcontrols/. 

334CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

335 Id. 

336Commission regulations §§ 38.1051(h) (for 

DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for 

SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 

17 CFR 49.24(j). 

2. Minimum External Penetration 

Testing Frequency Requirements for 

Covered DCMs and SDRs 

As discussed above, the proposed 

rules would require covered DCMs and 

SDRs to conduct external penetration 

testing no less frequently than annually. 

The current rules require DCMs and 

SDRs to conduct regular, periodic, 

objective testing of their automated 

systems.328 Therefore, the proposed 

rules will impose new costs relative to 

the requirements of the current rules.329

The Commission notes that the 

proposed frequency requirement is 

consistent with industry best 

practices.330

3. Independent Contractor Requirement 

for Covered DCMs and SDRs 

As discussed above, the proposed 

rules would require the annual external 

penetration test to be conducted by an 

independent contractor. Current 

regulations §§ 38.1051(h) and 49.24(j) 

provide that testing of automated 

systems should be conducted by 

qualified, independent professionals.331

The qualified independent professionals 

may be independent contractors or 

employees of a DCM or SDR as long as 

they are not responsible for 

development or operation of the systems 

or capabilities being tested. Therefore, 

the proposed rules will impose new 

costs relative to the requirements of the 

current rules.332 The Commission notes 

that best practices support using 

independent contractors to conduct 

external penetration testing.333

4. Cost Estimates for Covered DCMs and 

SDRs 

Based on the cost information from 

the DMO Preliminary Survey, the 

Commission estimates that the average 

cost for a covered DCM or SDR to 

conduct external penetration testing 

annually is approximately $244,625. 

The Commission recognizes that the 

actual costs may vary widely as a result 

of many factors, including the size of 

the organization, the complexity of the 

automated systems, and the scope of the 

test. Where a covered DCM or SDR does 

not currently use an independent 

contractor to conduct the external 

penetration test, the Commission 

expects that such entities may also incur 

some additional minor costs as a result 

of the need to establish and implement 

internal policies and procedures that are 

reasonably designed to address the 

workflow associated with the test. For 

example, the Commission expects that 

such policies and procedures may 

include communication and 

cooperation between the entity and 

independent contractor, communication 

and cooperation between the entity’s 

legal, business, technology, and 

compliance departments, appropriate 

authorization to remediate 

vulnerabilities identified by the 

independent contractor, implementation 

of the measures to address such 

vulnerabilities, and verification that 

these measures are effective and 

appropriate. The Commission 

acknowledges that covered DCMs and 

SDRs that currently do not use 

independent contractors for the external 

penetration test may need to dedicate 

time to reviewing and revising their 

existing policies and procedures to 

ensure that they are sufficient in the 

context of the proposed requirements. 

The Commission believes that any costs 

incurred by the entities as result of such 

review would be minor. 

c. Benefits 

The benefits for external penetration 

testing, including the minimum testing 

frequency and independent contractors, 

are discussed below in conjunction with 

the benefits for internal penetration 

testing. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of external penetration testing, 

including the minimum testing 

frequency and independent contractor 

requirement. The Commission 

particularly solicits comments 

concerning the need for external 

penetration testing and the associated 

costs and benefits, from DCMs, SEFs, 

and SDRs, from futures and swap 

market participants, from best practices 

and standards organizations, from 

cybersecurity service providers and 

cybersecurity experts in both the private 

and public sectors, and from other 

financial regulators. 

10. Internal Penetration Testing: 

Sections 38.1051(h)(3)(ii), 

37.1401(h)(3)(ii), and 49.24(j)(3)(ii) 

a. Summary of Proposed Rules 

As discussed above in Section I.F.4., 

proposed §§ 38.1051(h)(1), 

37.1401(h)(1), and 49.24(j)(1) would 

define internal penetration testing as 

attempts to penetrate a DCM’s, SEF’s, or 

SDR’s automated systems from inside 

the systems’ boundaries to identify and 

exploit vulnerabilities. The proposed 

rules would require a DCM, SEF, or SDR 

to conduct internal penetration testing 

that is sufficient to satisfy the scope 

requirements in proposed §§ 38.1051(k), 

37.1401(k), and 49.24(l), at a frequency 

determined by an appropriate risk 

analysis. At a minimum, covered DCMs 

and SDRs would be required to conduct 

the internal penetration testing no less 

frequently than annually. The DCM or 

SDR may engage independent 

contractors to conduct the test, or the 

entity may use employees of the DCM 

or SDR who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

b. Costs 

1. Internal Penetration Testing for All 

DCMs, SEFs, and SDRs 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.334 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.335

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.336

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80171 

337See supra note 291. 

338See Commission regulations §§ 38.1051(h) (for 

DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 

17 CFR 49.24(j). 

339Based on the information from the DMO 

Preliminary Survey, the Commission understands 

that most covered DCMs and SDRs currently 

conduct internal penetration testing at the proposed 

frequency. 

340PCI DSS standards, at 96–97, available at 

https://www.pcisecuritystandards.org/security_

standards/index.php. 

341FFIEC, Information Security IT Examination 

Handbook, at 81, available at http://ithandbook.

ffiec.gov/ITBooklets/FFIEC_ITBooklet_Information

Security.pdf. 

342FINRA, Report on Cybersecurity Practices 

(February 2015), at 22, available at https://www.

finra.org/sites/default/files/p602363%20Report%20

on%20Cybersecurity%20Practices_0.pdf. 

343NIST, SP 800–115, Technical Guide to 

Information Security Testing and Assessment, 

Section 5.2.2, at 5–5, available at http://csrc.nist.

gov/publications/nistpubs/800-115/SP800-115.pdf. 

344FFIEC, Information Security IT Examination 

Handbook, at 82, available at http://ithandbook.

ffiec.gov/ITBooklets/FFIEC_ITBooklet_Information

Security.pdf. 

345PCI DSS, Requirements 11.3.1 and 11.3.2., 

available at https://www.pcisecuritystandards.org/

documents/PCI_DSS_v3-1.pdf. 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

internal penetration testing. The 

proposed rules clarify the existing 

testing requirements by specifying 

internal penetration testing as a 

necessary component. The Commission 

believes that this has always been the 

case.337 If compliance with the existing 

testing requirements as clarified in the 

proposed rules results in costs to a 

DCM, SEF, or SDR beyond those it 

already incurs in this connection, the 

Commission believes that such 

additional costs would be attributable to 

compliance with the existing 

regulations and not to the proposed 

rules. Accordingly, the Commission 

believes that this clarification will not 

impose any new costs on DCMs, SEFs, 

and SDRs. 

2. Minimum Internal Penetration 

Testing Frequency Requirements for 

Covered DCMs and SDRs 

As discussed above, the proposed 

rules would require covered DCMs and 

SDRs to conduct internal penetration 

testing no less frequently than annually. 

The current rules require DCMs and 

SDRs to conduct regular, periodic, 

objective testing of their automated 

systems.338 Therefore, the proposed 

rules will impose new costs relative to 

the requirements of the current rules.339

The Commission notes that the 

proposed frequency is consistent with 

industry best practices.340

3. Cost Estimates for Covered DCMs and 

SDRs 

Based on the data from the DMO 

Preliminary Survey, the Commission 

estimates that the current average cost 

for a covered DCM or SDR conducting 

internal penetration testing is 

approximately $410,625 annually. In 

providing these estimates, the 

Commission recognizes that the actual 

costs may vary significantly as a result 

of numerous factors, including the size 

of the organization, the complexity of 

the automated systems, and the scope of 

the test. Additionally, the Commission 

recognizes that the affected entities may 

undertake an evaluation, on an initial 

and ongoing basis, regarding internal 

policies and procedures that may need 

to be revised. If such an evaluation is 

required, the Commission believes that 

any incremental costs would be minor. 

c. Benefits 

External penetration testing benefits 

DCMs, SEFs, and SDRs by identifying 

the extent to which its systems can be 

compromised before an attack is 

identified.341 Such testing is conducted 

outside a DCM’s, SEF’s, or SDR’s 

security perimeter to help reveal 

vulnerabilities that could be exploited 

by an external attacker. Accordingly, the 

Commission believes that the external 

penetration testing strengthens DCMs’, 

SEFs’, and SDRs’ systems, thereby 

protecting not only the DCMs, SEFs, and 

SDRs, but also market participants and 

parties required by the Act or 

Commission regulations to report swaps 

data to the SDRs from a disruption in 

services, which could potentially 

disrupt the functioning of the broader 

financial markets. 

By attempting to penetrate a DCM’s, 

SEF’s or SDR’s automated systems from 

inside the systems’ boundaries, internal 

penetration tests allow the respective 

entities to assess system vulnerabilities 

from attackers that penetrate their 

perimeter defenses and from trusted 

insiders, such as former employees and 

contractors. In addition to being an 

industry best practice, the Commission 

believes that annual internal penetration 

testing is important because such 

potential attacks by trusted insiders 

generally pose a unique and substantial 

threat due to their more sophisticated 

understanding of a DCM’s, SEF’s, or 

SDR’s systems. Moreover, ‘‘[a]n 

advanced persistent attack may involve 

an outsider gaining a progressively 

greater foothold in a firm’s environment, 

effectively becoming an insider in the 

process. For this reason, it is important 

to perform penetration testing against 

both external and internal interfaces and 

systems.’’ 342 As discussed above in the 

costs section, the proposed rules would 

address the required minimum 

frequency for covered DCMs and SDRs 

in performing external and internal 

penetration testing. Best practices 

support external and internal 

penetration testing on at least an annual 

basis. NIST calls for at least annual 

penetration testing of an organization’s 

network and systems.343 The FFIEC 

calls for penetration testing of high risk 

systems at least annually, and for 

quarterly testing and verification of the 

efficacy of firewall and access control 

defenses.344 Data security standards for 

the payment card industry provide that 

entities should perform both external 

and internal penetration testing ‘‘at least 

annually,’’ as well as after any 

significant network changes, new 

system component installations, firewall 

modifications, or product upgrades.345

The Commission believes the specified 

frequency levels would increase the 

likelihood that the affected entities will 

be adequately protected against the level 

of cybersecurity threat now affecting the 

financial sector. The Commission also 

notes that identifying and fixing 

vulnerabilities that could be exploited 

by adversaries would likely be a more 

cost effective alternative to dealing with 

a successful cyber attack. 

With respect to external penetration 

testing, the proposed requirement for 

annual testing to be performed by 

independent contractors is intended to 

ensure that covered DCM and SDR 

programs of risk analysis and oversight 

with respect to system safeguards 

include the benefits provided when 

independent contractors perform such 

testing. The Commission shares the 

view expressed by participants in the 

CFTC Roundtable that vendor testing 

has particular value with respect to 

external penetration testing because the 

test comes from the viewpoint of an 

outsider and against the current tactics, 

techniques, and threat vectors of current 

threat actors as revealed by current 

threat intelligence. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of internal penetration testing, 

including the minimum testing 

frequency requirement. The 

Commission particularly solicits 

comments concerning the need for 

internal penetration testing and the 

associated costs and benefits, from 

DCMs, SEFs, and SDRs, from futures 

and swap market participants, from best 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80172 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

346CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

347 Id. 

348Commission regulations §§ 38.1051(h) (for 

DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for 

SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 

17 CFR 49.24(j). 

349See supra note 291. 

350See Commission regulations §§ 38.1051(h) (for 

DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 

17 CFR 49.24(j). 

351Based on the information collected in the 

DMO Preliminary Survey, the Commission 

understands that some covered DCMs and SDRs 

currently conduct controls testing at the proposed 

frequency level. 

352NIST SP 800–53A Rev. 4, at 17–18, available 

at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53Ar4.pdf. 

353 Id. 

354Based on the information collected in the 

DMO Preliminary Survey, the Commission 

understands that most covered DCMs and SDRs 

currently engage independent contractors to 

conduct key controls testing. 

355NIST SP 800–53 Rev. 4, control CA–2 Security 

Assessments, Control Enhancements 1, Security 

Assessments: Independent Assessors, available at 

http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53r4.pdf. 

356One of the Cybersecurity Roundtable 

participants noted that with respect to the costs for 

a properly scoped program of controls testing there 

is no single answer to this question because it 

depends on the number of an organization’s 

applications and the amount of money spent across 

the industry varies greatly. See CFTC Roundtable, 

at 258–59. 

practices and standards organizations, 

from cybersecurity service providers 

and cybersecurity experts in both the 

private and public sectors, and from 

other financial regulators. 

11. Controls Testing: Sections 

38.1051(h)(4), 37.1401(h)(4), and 

49.24(j)(4) 

a. Summary of Proposed Rules 

As discussed above in Section I.F.5., 

proposed §§ 38.1051(h)(1), 37.1401(h)(1) 

and 49.24(j)(1) would define controls 

testing as an assessment of the DCM’s, 

SEF’s, or SDR’s market controls to 

determine whether such controls are 

implemented correctly, are operating as 

intended, and are enabling the entity to 

meet the system safeguard requirements 

established by the respective chapters. 

The proposed rules would require a 

DCM, SEF, or an SDR to conduct 

controls testing that is sufficient to 

satisfy the scope requirements in 

proposed §§ 38.1051(k), 37.1401(k), and 

49.24(l), at a frequency determined by 

an appropriate risk analysis. At a 

minimum, covered DCMs and SDRs 

would be required to conduct the 

controls testing no less frequently than 

every two years. The testing may be 

conducted on a rolling basis over the 

course of the minimum two-year period 

or over a minimum period determined 

by an appropriate risk analysis. The 

covered DCM and SDR must engage 

independent contractors to test and 

assess the key controls in the entity’s 

risk analysis and oversight, no less 

frequently than every two years. The 

entities may conduct any other controls 

testing required by §§ 38.1051(h)(4) and 

49.24(j)(4) by using either independent 

contractors or employees of the covered 

DCM or SDR who are not responsible for 

the development or operations of the 

systems or capabilities being tested. 

b. Costs 

1. Controls Testing for All DCMs, SEFs, 

and SDRs 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.346 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.347

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.348

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

controls testing. 

The proposed rules clarify the 

existing testing requirements by 

specifying controls testing as a 

necessary component. The Commission 

believes that this has always been the 

case.349 If compliance with the existing 

testing requirements as clarified by the 

proposed rules imposes costs to a DCM, 

SEF, or SDR beyond those it already 

incurs in this connection, the 

Commission believes that such 

additional costs would be attributable to 

compliance with the existing 

regulations and not to the proposed 

rules. Accordingly, the Commission 

believes that this clarification will not 

impose any new costs for DCMs, SEFs, 

or SDRs. 

2. Minimum Controls Testing Frequency 

Requirements for Covered DCMs and 

SDRs 

As discussed above, the proposed 

rules would require a covered DCM or 

SDR to test each control included in its 

program of system safeguards-related 

risk analysis and oversight no less 

frequently than every two years. The 

proposed rules would also permit such 

testing to be conducted on a rolling 

basis over the course of the period 

determined by appropriate risk analysis. 

The current rules require DCMs and 

SDRs to conduct regular, periodic, 

objective testing of their automated 

systems.350 Therefore, the proposed 

rules will impose new costs relative to 

the requirements of the current rules.351

The Commission notes that testing on a 

rolling basis is consistent with generally 

accepted best practices.352

3. Independent Contractor Requirement 

for Covered DCMs and SDRs 

As discussed above, the proposed 

rules would require a DCM or SDR to 

engage an independent contractor to test 

and assess the key controls no less 

frequently than every two years. Current 

regulations §§ 38.1051(h) and 49.24(j) 

provide that testing of automated 

systems should be conducted by 

qualified, independent professionals.353

The qualified independent professionals 

may be independent contractors or 

employees of a DCM or SDR as long as 

they are not responsible for 

development or operation of the systems 

or capabilities being tested. 

Accordingly, the proposed rules will 

impose new costs relative to the 

requirements of the current rules.354

The Commission notes that best 

practices support independent testing of 

key controls.355

4. Cost Estimates for Covered DCMs and 

SDRs 

Based on the information from the 

DMO Preliminary Survey, the 

Commission estimates that the current 

average cost for a covered DCM or an 

SDR conducting controls testing is 

approximately $2,724,000 annually.356

Consistent with all of the system 

safeguard-related tests required in the 

proposal, the Commission recognizes 

that the actual costs may vary widely as 

a result of numerous factors including, 

the size of the organization, the 

complexity of the automated systems, 

and the scope of the test. With respect 

to a covered DCM or SDR that does not 

currently use an independent contractor 

to conduct key controls testing, the 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80173 

357NIST SP 800–53A, Assessing Security and 

Privacy Controls in Federal Information Systems 

and Organizations, rev. 4 (‘‘NIST SP 800–53A’’), 

p. 3, available at: http://nvlpubs.nist.gov/nistpubs/ 

SpecialPublications/NIST.SP.800-53Ar4.pdf. 

358CFTC Roundtable, at 43–44. 

359NIST SP 800–53A Rev. 4, at 17–18, available 

at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53Ar4.pdf. 360NIST SP 800–53 Rev. 4, supra note 195. 

Commission expects that these entities 

may incur some minor costs as a result 

of the need to establish and implement 

internal policies and procedures that are 

reasonably designed to address the 

workflow associated with the test. For 

example, the Commission expects that 

such policies and procedures may 

include the communication and 

cooperation between the entity and 

independent contractor, communication 

and cooperation between the entity’s 

legal, business, technology, and 

compliance departments, appropriate 

authorization to remediate deficiencies 

identified by the independent 

contractor, implementation of the 

measures to address such deficiencies, 

and verification that these measures are 

effective and appropriate. While the 

Commission believes that all covered 

DCMs and SDRs have substantial 

policies and procedures in place for 

controls testing conducted by internal 

staff, the Commission acknowledges 

that the affected entities may dedicate 

time in reviewing and revising their 

existing policies and procedures to 

ensure that they are sufficient in the 

context of the proposed requirements. 

The Commission believes that any costs 

incurred by the entities as result of such 

review would be minor. 

c. Benefits 

Controls testing is essential in 

determining risk to an organization’s 

operations and assets, to individuals, 

and to other organizations, and to the 

nation resulting from the use of the 

organization’s systems.357 In other 

words, controls testing is vital because 

it allows firms to be nimble in 

preventing, detecting, or recovering 

from an attack.358 The Commission 

believes that the complex analysis and 

plan preparation that a DCM, SEF, and 

SDR undertakes with respect to controls 

testing, including designing and 

implementing changes to existing plans, 

likely contributes to a better ex ante 

understanding by the DCM’s, SEF’s, and 

SDR’s management of the challenges the 

entity would face in a cyber threat 

scenario, and thus better preparation to 

meet those challenges. This improved 

preparation would help reduce the 

possibility of market disruptions and 

financial losses to market participants. 

Moreover, regularly conducting controls 

testing enables a DCM, SEF, and SDR to 

mitigate the impact that a cyber threat 

to, or a disruption of, a DCM’s, SEF’s, 

or SDR’s operations would have on 

market participants, entities required by 

the Act or Commission regulations to 

report swaps data to SDRs, and, more 

broadly, the stability of the U.S. 

financial markets. Accordingly, the 

Commission believes that such testing 

strengthens a DCM’s, SEF’s, and SDR’s 

automated systems, thereby protecting 

market participants and swaps data 

reporting parties from a disruption in 

services. 

As noted above in the costs section, 

the proposed rules would require a 

covered DCM or SDR to test each 

control included in its program of 

system safeguards-related risk analysis 

oversight no less frequently than every 

two years. The Commission believes 

that it is essential for each control to be 

tested at least this often in order to 

confirm the continuing adequacy of the 

entity’s system safeguards in today’s 

cybersecurity threat environment. 

Additionally, the frequency requirement 

would benefit the affected entities by 

providing additional clarity concerning 

what is required of them in this respect. 

The proposed rules would also permit 

such testing to be conducted on a rolling 

basis over the course of the period 

determined by appropriate risk analysis. 

The rolling basis provision is designed 

to give a covered DCM or SDR flexibility 

concerning which controls are tested 

during the required minimum frequency 

period. This flexibility is intended to 

reduce burdens associated with testing 

every control to the extent possible 

while still ensuring the needed 

minimum testing frequency. The 

Commission also notes that testing on a 

rolling basis is consistent with industry 

best practices.359

Additionally, as noted above, the 

proposed rules would require a covered 

DCM or SDR to engage independent 

contractors to test and assess each of the 

entity’s key controls no less frequently 

than every two years. The entities 

would have the flexibility to conduct 

any other controls testing by either 

independent contractors or entity 

employees not responsible for 

development or operation of the systems 

or capabilities being tested. Independent 

testing of key controls is consistent with 

best practices. Significantly, the NIST 

Standards note the important benefits of 

independent testing and call for controls 

testing to include assessment by 

independent assessors, free from actual 

or perceived conflicts of interest, in 

order to validate the completeness, 

accuracy, integrity, and reliability of test 

results.360 Accordingly, in light of best 

practices and the current cyber threat 

level to the financial sector, the 

Commission believes the independent 

contractor requirement would provide 

these substantial benefits. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of controls testing, including 

the minimum testing frequency and 

independent contractor requirement. 

The Commission particularly solicits 

comments concerning the need for 

controls testing and the associated costs 

and benefits, from DCMs, SEFs, and 

SDRs, from futures and swap market 

participants, from best practices and 

standards organizations, from 

cybersecurity service providers and 

cybersecurity experts in both the private 

and public sectors, and from other 

financial regulators. 

12. Security Incident Response Plan 

Testing: Sections 38.1051(h)(5), 

37.1401(h)(5), and 49.24(j)(5) 

a. Summary of Proposed Rules 

As discussed above in Section I.F.6., 

proposed §§ 38.1051(h)(1), 

37.1401(h)(1), and 49.24(j)(1) would 

define security incident response plan 

testing as testing of a DCM’s, SEF’s, or 

SDR’s security incident response plan to 

determine the plan’s effectiveness, 

identifying its potential weaknesses or 

deficiencies, enabling regular plan 

updating and improvement, and 

maintaining organizational 

preparedness and resiliency with 

respect to security incidents. In 

addition, methods of conducting 

security incident response plan testing 

may include, but are not limited to, 

checklist completion, walk-through or 

table-top exercises, simulations, and 

comprehensive exercises. The DCM’s, 

SEF’s, or SDR’s security incident 

response would be required to include, 

without limitation, the entity’s 

definition and classification of security 

incidents, its policies and procedures 

for reporting security incidents and for 

internal and external communication 

and information sharing regarding 

security incidents, and the hand-off and 

escalation points in its security incident 

response process. The entities may 

coordinate its security incident response 

plan testing with other testing required 

by this section or with testing of its 

other BC–DR and crisis management 

plans. The proposed rules would 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80174 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

361CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

362 Id. 

363Commission regulations §§ 38.1051(h) (for 

DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for 

SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 

17 CFR 49.24(j). 

364See supra note 291. 

365See Commission regulations §§ 38.1051(h) (for 

DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 

17 CFR 49.24(j). 

366Based on the Commission’s experience in 

administering the system safeguard compliance 

program, the Commission believes that many 

covered DCMs and SDRs currently conduct security 

incident response plan testing at the proposed 

frequency. 

367NIST SP 800–84, Guide to Test, Training, and 

Exercise Programs for IT Plans and Capabilities, at 

2–4 (citing NIST SP 800–53, Rev. 4, Security and 

Privacy Controls for Federal Information Systems 

and Organizations). 

require covered DCMs and SDRs to 

conduct such testing at a frequency 

determined by an appropriate risk 

analysis, but at a minimum no less 

frequently than annually. 

b. Costs 

1. Security Incident Response Plan 

Testing for All DCMs, SEFs, and SDRs 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.361 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.362

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.363

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

security incident response plan testing. 

The proposed rules clarify the 

existing testing requirements by 

specifying security incident response 

plan testing as a necessary component. 

The Commission believes that this has 

always been the case.364 If compliance 

with the existing testing requirements as 

clarified by the proposed rules results in 

costs to a DCM, SEF, or SDR beyond 

those it already incurs in this 

connection, the Commission believes 

that such additional costs would be 

attributable to compliance with the 

existing regulations and not to the 

proposed rules. Accordingly, the 

Commission believes that this 

clarification will not impose any new 

costs for DCMs, SEFs, and SDRs. 

2. Minimum Security Incident Response 

Testing Frequency Requirements for 

Covered DCMs and SDRs 

As discussed above, the proposed 

rules would require covered DCMs and 

SDRs to conduct security incident 

response plan testing at least annually. 

The current rules require DCMs and 

SDRs to conduct regular, periodic, 

objective testing of their automated 

systems.365 Accordingly, the proposed 

rules will impose new costs relative to 

the requirements of the current rules.366

The Commission notes that the 

proposed frequency requirement is 

consistent with industry best 

practices.367

3. Estimated Costs for Covered DCMs 

and SDRs 

At present, the Commission cannot 

quantify or estimate the current costs 

associated with security incident 

response plan testing at a covered DCM 

or SDR. Nevertheless, to the extent that 

the proposed rules would impose 

additional costs on covered DCMs and 

SDRs, the Commission believes that 

such costs may vary widely as result of 

numerous factors, including the size of 

the organization, the complexity of the 

automated systems, and the scope of the 

test. Additional costs incurred by the 

affected entities could include time in 

reviewing and revising existing policies 

and procedures, initially and on an 

ongoing basis, concerning security 

incident response testing to ensure that 

they are sufficient in the context of the 

proposed requirements. In such cases, 

the Commission believes that any costs 

would be minimal. 

c. Benefits 

Security incident response plans, and 

adequate testing of such plans, reduce 

the damage caused by breaches of a 

DCM’s, SEF’s, or SDR’s network 

security. Network security breaches are 

highly likely to have a substantial 

negative impact on a DCM’s, SEF’s, or 

SDR’s operations. They can increase 

costs through lost productivity, lost 

current and future market participation 

or swap data reporting, compliance 

penalties, and damage to the DCM’s, 

SEF’s, or SDR’s reputation and brand. 

Moreover, the longer a cyber intrusion 

continues, the more its impact may be 

compounded. 

The proposed rules would provide 

clarity to covered DCMs and SDRs 

concerning the minimum testing 

frequency. The Commission believes the 

proposed frequency requirement would 

increase the likelihood that these 

entities could mitigate the duration and 

impact in the event of a security 

incident by making them better 

prepared for such an incident. 

Therefore, a covered DCM or SDR may 

also be better positioned to reduce any 

potential impacts to automated system 

operation, reliability, security, or 

capacity, or the availability, 

confidentiality, or integrity of its futures 

and swaps data. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of the proposed security 

incident response plan testing 

requirement, including the minimum 

testing frequency requirement. The 

Commission also seeks comments on all 

aspects of the proposed security 

incident response plan testing 

requirement. The Commission 

particularly solicits comments 

concerning both the need for security 

incident response plans and plan testing 

and the associated costs and benefits, 

from DCMs, SEFs, and SDRs, from 

futures and swap market participants, 

from best practices and standards 

organizations, from cybersecurity 

service providers and cybersecurity 

experts in both the private and public 

sectors, and from other financial 

regulators. 

13. Enterprise Technology Risk 

Assessment: Sections §§ 38.1051(h)(6), 

37.1401(h)(6), and 49.24(j)(6) 

a. Summary of Proposed Rules 

As discussed above in Section I.F.7., 

proposed §§ 38.1051(h)(1), 

37.1401(h)(1), and 49.24(j)(1) would 

define ETRA as an assessment that 

includes an analysis of threats and 

vulnerabilities in the context of 

mitigating controls. In addition, the 

assessment identifies, estimates, and 

prioritizes risks to the entity’s 

operations or assets, or to market 

participants, individuals, or other 

entities, resulting from impairment of 

the confidentiality, integrity, and 

availability of data and information or 

the reliability, security, or capacity of 

automated systems. The proposed rules 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80175 

368CEA section 5(d)(20) (for DCMs); CEA section 

5h(f)(14) (for SEFs); CEA section 21(f)(4)(A) and 17 

CFR 49.24(a) (for SDRs). 

369 Id. 

370Commission regulations §§ 38.1051(h) (for 

DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for 

SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 

17 CFR 49.24(j). 

371See supra note 291. 

372See Commission regulations §§ 38.1051(h) (for 

DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 

17 CFR 49.24(j). 

373Based on the information from the DMO 

Preliminary Survey, the Commission understands 

that most covered DCMs and SDRs currently 

conduct ETRAs at the proposed frequency. 

374FINRA, Report on Cybersecurity Practices 

(February 2015), at 14, available at https://

www.finra.org/sites/default/files/p602363%20

Report%20on%20Cybersecurity%20Practices_

0.pdf. 

375FINRA, Report on Cybersecurity Practices 

(February 2015), at 14, available at https://www.

finra.org/sites/default/files/p602363%20Report%20

on%20Cybersecurity%20Practices_0.pdf. 

would require a covered DCM or SDR to 

conduct an ETRA at a frequency 

determined by an appropriate risk 

analysis, but at a minimum no less 

frequently than annually. The proposed 

rules would provide that the assessment 

may be conducted by independent 

contractors, or employees of the DCM or 

SDR who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

b. Costs 

1. ETRAs for All DCMs, SEFs, and SDRs 

As discussed in the preamble, the Act 

requires each DCM, SEF, and SDR to 

develop and maintain a program of 

system safeguards-related risk analysis 

and oversight to identify and minimize 

sources of operational risk.368 The Act 

mandates that in this connection each 

DCM, SEF, and SDR must develop and 

maintain automated systems that are 

reliable, secure, and have adequate 

scalable capacity, and must ensure 

system reliability, security, and capacity 

through appropriate controls and 

procedures.369

The Commission’s existing system 

safeguards rules for DCMs, SEFs, and 

SDRs mandate that, in order to achieve 

these statutory requirements, each DCM, 

SEF, and SDR must conduct testing and 

review sufficient to ensure that its 

automated systems are reliable, secure, 

and have adequate scalable capacity.370

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without conducting 

ETRAs. 

The proposed rules clarify the 

existing testing requirements by 

specifying ETRAs as a necessary 

component.371 The Commission 

believes that this has always been the 

case. If compliance with the existing 

testing requirements as clarified by the 

proposed rules results in costs to a 

DCM, SEF, or SDR beyond those it 

already incurs in this connection, the 

Commission believes that such 

additional costs would be attributable to 

compliance with the existing 

regulations and not to the proposed 

rules. Accordingly, the Commission 

believes that this clarification will not 

impose any new costs for DCMs, SEFs, 

and SDRs. 

2. Minimum ETRA Frequency 

Requirements for Covered DCMs and 

SDRs 

As discussed above, the proposed 

rules would require covered DCMs and 

SDRs to conduct ETRAs at least 

annually. The current rules require 

DCMs and SDRs to conduct regular, 

periodic, objective testing of their 

automated systems.372 Therefore, the 

proposed rules will impose new costs 

relative to the requirements of the 

current rules.373 The Commission notes 

that the proposed frequency 

requirement comports with industry 

best practices.374

3. Estimated Costs for Covered DCMs 

and SDRs 

Based on the information from the 

DMO Preliminary Survey, the 

Commission estimates that the current 

average cost for covered DCMs and 

SDRs conducting the assessment is 

approximately $1,347,950 annually. 

However, the Commission notes that 

actual costs may vary widely among the 

affected entities due to the size of the 

organization, the complexity of the 

automated systems, and the scope of the 

assessment. Additionally, the 

Commission recognizes that the affected 

entities may undertake an evaluation, 

on an initial and ongoing basis, 

regarding internal policies and 

procedures that may need to be revised. 

If such an evaluation is required, the 

Commission believes that any 

incremental costs would be minor. 

c. Benefits 

The Commission believes that ETRAs 

are an essential component of a 

comprehensive system safeguard 

program. ETRAs can be viewed as a 

strategic approach through which 

DCMs, SEFs, and SDRs identify risks 

and aligns its systems goals accordingly. 

The Commission believes that these 

requirements are necessary to support a 

strong risk management framework for 

DCMs, SEFs, and SDRs, thereby helping 

to protect DCMs, SEFs, and SDRs, 

market participants, parties required by 

the Act or Commission regulations to 

report swaps data to SDRs, and helping 

to mitigate the risk of market 

disruptions. 

The proposed rules would provide 

clarity to covered DCMs and SDRs 

concerning the minimum assessment 

frequency. Best practices support 

annual or more frequent assessment of 

technology and cybersecurity risk. For 

example, FINRA states that firms 

conducting appropriate risk assessment 

do so either annually or on an ongoing 

basis throughout the year, in either case 

culminating in an annual risk 

assessment report.375 The Commission 

believes the proposed frequency 

requirements would better position the 

entities to identify, estimate, and 

prioritize the risks facing them in 

today’s cybersecurity threat 

environment. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of the enterprise technology 

risk assessment requirement, including 

the minimum testing frequency 

requirement. The Commission 

particularly solicits comments 

concerning the need for enterprise 

technology risk assessments and the 

associated costs and benefits, from 

DCMs, SEFs, and SDRs, from futures 

and swap market participants, from best 

practices and standards organizations, 

from cybersecurity service providers 

and cybersecurity experts in both the 

private and public sectors, and from 

other financial regulators. 

14. Scope for Testing and Assessment: 

Sections 38.1051(k), 37.1401(k), and 

49.24(l) 

a. Summary of Proposed Rules 

As discussed above in Section I.G.1., 

proposed §§ 38.1051(k), 37.1401(k), and 

49.24(l) would require that the scope for 

all system safeguards testing and 

assessment required by this chapter 

must be broad enough to include all 

testing of automated systems, networks, 

and controls necessary to identify any 

vulnerability which, if triggered, could 

enable an intruder or unauthorized user 

or insider to: (1) Interfere with the 

entity’s operations or with fulfillment of 

the entity’s statutory and regulatory 

responsibilities; (2) impair or degrade 

the reliability, security, or adequate 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80176 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

376FINRA, Report on Cybersecurity Practices, 

February 2015, at 7, available at https://www.finra.

org/sites/default/files/p602363%20Report%20on

%20Cybersecurity%20Practices_0.pdf; FFIEC, 

Information Security IT Examination Handbook, at 

5, available at http://ithandbook.ffiec.gov/

ITBooklets/FFIEC_ITBooklet_Information

Security.pdf.; and NIST SP 800–53, Rev. 4, Program 

Management Control Family, available at http://

nvlpubs.nist.gov/nistpubs/SpecialPublications/

NIST.SP.800-53r4.pdf. 

377See e.g., NIST SP 800–115, Technical Guide to 

Information Security Testing and Assessment, at 6– 

10–6–12, September 2008, available at http://csrc.

nist.gov/publications/nistpubs/800-115/SP800- 

115.pdf; NIST SP 800–53A Rev. 4, at 10, available 

at http://nvlpubs.nist.gov/nistpubs/

SpecialPublications/NIST.SP.800-53Ar4.pdf; 

FFIEC, Information Security IT Examination 

Handbook, at 5, available at http://ithandbook.ffiec.

gov/ITBooklets/FFIEC_ITBooklet_Information

Security.pdf; NIST SP 800–53 Rev. 4, Program 

Management control family, available at http://

nvlpubs.nist.gov/nistpubs/SpecialPublications/

NIST.SP.800-53r4.pdf; FINRA, Report on 

Cybersecurity Practices, February 2015, at 8, 

available at https://www.finra.org/sites/default/

files/p602363%20Report%20on%20Cybersecurity

%20Practices_0.pdf; FFIEC, Audit IT Examination 

Handbook, Objective 6, at 5, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

Audit.pdf; ISACA, COBIT 5, APO12, available at 

https://cobitonline.isaca.org/. 

378See supra note 246. 

379FINRA, Report on Cybersecurity Practices, 

February 2015, at 7, available at https://

www.finra.org/sites/default/files/p602363%20

Report%20on%20Cybersecurity%20Practices_

0.pdf; FFIEC, Information Security IT Examination 

Handbook, at 5, available at http://

ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_

InformationSecurity.pdf.; and NIST SP 800–53, Rev. 

4, Program Management Control Family, available 

at http://nvlpubs.nist.gov/nistpubs/Special

Publications/NIST.SP.800-53r4.pdf. 

scalable capacity of the entity’s 

automated systems; (3) add to, delete, 

augment, modify, exfiltrate, or 

compromise the integrity of any data 

related to the entity’s regulated 

activities; or (4) undertake any other 

unauthorized action affecting the 

entity’s regulated activities or the 

hardware or software used in 

connection with those activities. 

b. Costs and Benefits 

The Commission believes that the 

costs and benefits associated with the 

scope for testing and assessment are 

generally attributable to the substantive 

testing requirements; therefore they are 

discussed in the cost and benefit 

considerations related to the rules 

describing the requirements for each test 

or assessment. 

15. Internal Review of Test and 

Assessment Reports: Sections 

38.1051(l), 37.1401(l), and 49.24(m) 

a. Summary of Proposed Rules 

As discussed above in Section I.G.2. 

proposed §§ 38.1051(l), 37.1401(l), and 

49.24(m) would require the senior 

management and the Board of Directors 

of the DCM, SEF, or SDR to receive and 

review reports setting forth the results of 

all testing and assessment required by 

this section. In addition, the proposed 

rules would require the DCM, SEF, or 

SDR to establish and follow appropriate 

procedures for the remediation of issues 

identified through such review, as 

provided in sections 38.1051(m), 

37.1401(m), and 49.24(n) (Remediation), 

and for evaluation of the effectiveness of 

testing and assessment protocols. 

b. Costs 

As discussed in the preamble, the 

Commission proposes to clarify the 

testing requirements by specifying and 

defining certain aspects of DCM, SEF, 

and SDR risk analysis and oversight 

programs that are necessary to 

fulfillment of the testing requirements 

and achievement of their purposes. This 

clarification includes review of system 

safeguard testing and assessments by 

senior management and the DCM’s, 

SEF’s, or SDR’s Board of Directors, 

which is recognized as best practice for 

system safeguards.376 The Commission 

believes, as the generally accepted 

standards and best practices noted in 

this NPRM make clear, that it would be 

essentially impossible for a DCM, SEF, 

or SDR to fulfill its existing obligation 

to conduct testing sufficient to ensure 

the reliability, security, and capacity of 

its automated systems without 

performing appropriate internal 

reporting and review of test results.377

This has been true since before the 

testing requirements of the Act and the 

current regulations were adopted.378 If 

compliance with the existing testing 

requirements as clarified by the 

proposed rules results in costs to a 

DCM, SEF, or SDR beyond those it 

already incurs, the Commission believes 

that such additional costs would be 

attributable to compliance with the 

existing regulations and not to the 

proposed rules. Accordingly, the 

Commission believes that this 

clarification will not impose any new 

costs for DCMs, SEFs, and SDRs. 

c. Benefits 

The Commission believes that 

internal reporting and review are an 

essential component of a comprehensive 

and effective system safeguard program. 

While senior management and the 

DCM’s, SEF’s, or SDR’s board of 

directors will have to devote resources 

to reviewing testing and assessment 

reports, active supervision by senior 

management and the board of directors 

promotes responsibility and 

accountability by affording them greater 

opportunity to evaluate the effectiveness 

of the testing and assessment protocols. 

Moreover, the attention by the board of 

directors and senior management 

should help to promote a focus on such 

reviews and issues, and enhance 

communication and coordination 

regarding such reviews and issues 

among the business, technology, legal, 

and compliance personnel of the DCM, 

SEF, and SDR. Active supervision by 

senior management and the board of 

directors also promotes a more efficient, 

effective, and reliable DCM and SDR 

risk management and operating 

structure. Consequently, DCMs, SEFs, 

and SDRs should be better positioned to 

strengthen the integrity, resiliency, and 

availability of its automated systems. 

d. Request for Comments 

The Commission requests comment 

on any potential costs of proposed 

§§ 38.1051(l), 37.1401(l), and 49.24(m) 

on DCMs, SEFs, and SDRs, including, 

where possible, quantitative data. 

16. Remediation: Sections 38.1051(m), 

37.1401(m), and 49.24(n) 

a. Summary of Proposed Rules 

As discussed above in Section I.G.3., 

proposed §§ 38.1051(m), 37.1401(m), 

and 49.24(n) would require a DCM, SEF, 

or an SDR to analyze the results of the 

testing and assessment required by this 

section to identify all vulnerabilities 

and deficiencies in the entity’s systems. 

The DCM, SEF, or SDR would also be 

required to remediate the vulnerabilities 

and deficiencies revealed by all testing 

and assessment, to the full extent 

necessary to enable the entity to fulfill 

the system safeguards requirements of 

this chapter, and to meet all statutory 

and regulatory obligations in connection 

with its regulated activities. The 

remediation must be timely in light of 

appropriate risk analysis with respect to 

the risks presented by such 

vulnerabilities and deficiencies. 

b. Costs 

As discussed in the preamble, the 

Commission proposes to clarify the 

testing requirements by specifying and 

defining certain aspects of DCM, SEF, 

and SDR risk analysis and oversight 

programs that are necessary to 

fulfillment of the testing requirements 

and achievement of their purposes. This 

clarification includes remediation. 

Remediation of vulnerabilities and 

deficiencies revealed by cybersecurity 

testing is a best practice and a 

fundamental purpose of such testing.379

The Commission believes, as the 

generally accepted standards and best 

practices noted in this NPRM make 

clear, that it would be essentially 

impossible for a DCM, SEF, or SDR to 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80177 

380See supra note 377. 

381See supra note 246. 

382 In arriving at a wage rate for the hourly costs 

imposed, Commission staff used the National 

Industry-Specific Occupational Employment and 

Wage Estimates, published in May (2014 Report). 

The hourly rate for a Compliance Officer in the 

Securities and Commodity Exchanges as published 

in the 2014 Report was $44.03 per hour. 

fulfill its existing obligation to conduct 

testing sufficient to ensure the 

reliability, security, and capacity of its 

automated systems without performing 

remediation.380 This has been true since 

before the testing requirements of the 

Act and the current regulations were 

adopted.381 If compliance with the 

existing testing requirements as clarified 

by the proposed rules results in costs to 

a DCM, SEF, or SDR beyond those it 

already incurs, the Commission believes 

that such additional costs would be 

attributable to compliance with the 

existing regulations and not to the 

proposed rules. Accordingly, the 

Commission believes that this 

clarification will not impose any new 

costs for DCMs, SEFs, and SDRs. 

c. Benefits 

The Commission believes that 

effective remediation is a critical 

component of a comprehensive and 

effective system safeguard program. As 

discussed above, the Commission 

believes that the remediation of 

vulnerabilities and deficiencies revealed 

by cybersecurity testing is an industry 

best practice. Moreover, remediation 

may reduce the frequency and severity 

of systems disruptions and breaches for 

the DCMs, SEFs, and SDRs. In addition, 

remediation helps to ensure that the 

entities dedicate appropriate resources 

to timely address system safeguardrelated deficiencies and would place an 

emphasis on mitigating harm to market 

participants while promoting market 

integrity. Without a timely remediation 

requirement, the impact of 

vulnerabilities or deficiencies identified 

by the testing or assessment could 

persist and have a detrimental effect on 

the futures and swaps markets generally 

as well as market participants. 

d. Request for Comments 

As set out in more detail below in the 

Request for Comments section, the 

Commission seeks additional 

information regarding the costs and 

benefits of the remediation requirement. 

The Commission particularly solicits 

comments concerning the need for 

remediation and the associated costs 

and benefits, from DCMs, SEFs, and 

SDRs, from futures and swap market 

participants, from best practices and 

standards organizations, from 

cybersecurity service providers and 

cybersecurity experts in both the private 

and public sectors, and from other 

financial regulators. 

17. Required Production of Annual 

Trading Volume: Section 38.1051(n) 

a. Summary of Proposed Rule 

Proposed § 38.1051(n) would require 

all DCMs to provide to the Commission 

for calendar year 2015, and each 

calendar year thereafter, its annual total 

trading volume. This information would 

be required within 30 calendar days of 

the effective date of the final version of 

this rule, and for 2016 and subsequent 

years by January 31 of the following 

calendar year. 

b. Costs 

As discussed above in the PRA 

section, the Commission believes that 

all DCMs generally calculate their 

annual trading volume in the usual 

course of business and many of the 

DCMs already publish this information 

on their Web site. Therefore, the 

Commission believes that any costs 

incurred by the DCMs as a result of 

proposed § 38.1051(n) would be 

minimal. The Commission estimates 

that each DCM would spend 

approximately half an hour to prepare 

and file the trading volume information 

with Commission at a cost of 

approximately $22.00 annually.382

c. Benefits 

As a result of the Commission’s 

proposal to apply the enhanced system 

safeguard requirements to DCMs whose 

annual trading volume in a calendar 

year is five percent or more of the 

combined annual trading volume of all 

DCMs regulated by Commission (i.e., 

covered DCMs), the Commission 

believes that it is necessary to require all 

DCMs to provide the Commission with 

annual trading volume information. 

Otherwise, the Commission would be 

unable to accurately evaluate whether a 

particular DCM would be subject to the 

proposal. As stated in the proposed rule, 

the Commission will provide each DCM 

with its percentage of the combined 

annual trading volume of all DCMs 

regulated by the Commission for the 

preceding calendar year. Therefore, all 

DCMs will receive certainty from the 

Commission regarding whether they 

must comply with the enhanced system 

safeguard requirements. This 

requirement will support more accurate 

application of the proposed rules. 

18. Section 15(a) Factors 

a. Protection of Market Participants and 

the Public 

The Commission believes that the 

proposed rules should benefit the 

futures and swaps markets by promoting 

more robust automated systems and 

therefore fewer disruptions and marketwide closures, systems compliance 

issues, and systems intrusions. Because 

automated systems play a central and 

critical role in today’s electronic 

financial market environment, oversight 

of DCMs, SEFs, and SDRs with respect 

to automated systems is an essential 

part of effective oversight of both futures 

and swaps markets. In addition, 

providing the Commission with reports 

concerning system safeguards testing 

and assessments required by the 

proposed rules will facilitate the 

Commission’s oversight of futures and 

swaps markets, augment the 

Commission’s efforts to monitor 

systemic risk, and will further the 

protection of market participants and 

the public by helping to ensure that 

automated systems are available, 

reliable, secure, have adequate scalable 

capacity, and are effectively overseen. 

As a result, the Commission also 

expects fewer interruptions to the 

systems that directly support the 

respective entities, including matching 

engines, regulatory and surveillance 

systems, and the dissemination of 

market data, which should help ensure 

compliance with the relevant statutory 

and regulatory obligations. Moreover, 

market participants will benefit from 

systems that are secure and able to 

protect their anonymity with respect to 

positions in the marketplace and other 

aspects of their personally-identifiable 

information. 

b. Efficiency, Competitiveness, and 

Financial Integrity of the Markets 

A DCM or SEF that has system 

safeguard policies and procedures in 

place, including the timely remediation 

of vulnerabilities and deficiencies in 

light of appropriate risk analysis, will 

promote overall market confidence and 

could lead to greater market efficiency, 

competitiveness, and perceptions of 

financial integrity. Safeguarding the 

reliability, security, and capacity of 

DCM, SEF, and SDR computer systems 

are essential to mitigation of system risk 

for the nation’s financial sector as a 

whole. A comprehensive testing 

program capable of identifying 

operational risks will enhance the 

efficiency, and financial integrity of the 

markets by increasing the likelihood 

that trading remains uninterrupted and 

transactional data and positions are not 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80178 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

383 During the CFTC Roundtable, one of the 

participants noted that ‘‘if data is disclosed about 

activity in the markets, that is a survivable event 

from a resiliency perspective, but if we don’t know 

who owns what and what their positions are, then 

there are no markets.’’ CFTC Roundtable, at 71. 384CFTC Roundtable, at 28. 

lost.383 A DCM or SEF with such a 

program also promotes confidence in 

the markets, and encourages liquidity 

and stability. Moreover, the ability of a 

DCM or SEF to recover and resume 

trading promptly in the event of a 

disruption of their operations, or an 

SDR to recover and resume its swap 

data recordkeeping and reporting 

function, is highly important to the U.S. 

economy and ensuring the resiliency of 

the automated systems is a critical part 

of the Commission’s mission. 

Additionally, and because SDRs hold 

data needed by financial regulators from 

multiple jurisdictions, safeguarding 

such systems will be essential to 

mitigation of systemic risk world-wide. 

Notice to the Commission concerning 

the results of system safeguard tests 

performed by the DCMs, SEFs, and 

SDRs will assist the Commission’s 

oversight and its ability to assess 

systemic risk levels. It would present 

unacceptable risks to the U.S. financial 

system if futures and swaps markets that 

comprise critical components of the 

world financial system, and SDRs that 

hold data concerning swaps, were to 

become unavailable for an extended 

period of time for any reason, and 

adequate system safeguards are essential 

to the mitigation of such risks. 

c. Price Discovery 

Any interruption in trading on a DCM 

or SEF can distort the price discovery 

process. Similarly, any interruption in 

the operations of an SDR will hamper 

the Commission’s ability to examine 

potential price discrepancies and other 

trading inconsistencies in the swaps 

market. Therefore, reliable functioning 

computer systems and networks are 

essential in protecting the price 

discovery process. The Commission 

believes that the proposed rules will 

reduce the incidence and severity of 

automated system security breaches and 

functional failures. In addition, the 

Commission views the proposed rules 

as likely to facilitate the price discovery 

process by mitigating the risk of 

operational market interruptions from 

disjoining forces of supply and demand. 

The presence of thorough system 

safeguards testing signals to the market 

that a DCM or SEF is a financially sound 

place to trade, thus attracting greater 

liquidity which leads to more accurate 

price discovery. 

d. Sound Risk Management Practices 

The proposed rules will benefit the 

risk management practices of both the 

regulated entities and the participants 

who use the facilities of those entities. 

Participants who use DCMs or SEFs to 

manage commercial price risks should 

benefit from markets that behave in an 

orderly and controlled fashion. If prices 

move in an uncontrolled fashion due to 

a cybersecurity incident, those who 

manage risk may be forced to exit the 

market as a result of unwarranted 

margin calls or deterioration of their 

capital. In addition, those who want to 

enter the market to manage risk may 

only be able to do so at prices that do 

not reflect the actual supply and 

demand fundamentals due to the effects 

of a cybersecurity incident. Relatedly, 

participants may have greater 

confidence in their ability to unwind 

positions because market disruptions 

would be less common. With respect to 

SDRs, the Commission believes that the 

ability of participants in the swaps 

market to report swap transactions to an 

SDR without interruption will serve to 

improve regulators’ ability to monitor 

risk management practices through 

better knowledge of open positions and 

SDR services related to various trade, 

collateral, and risk management 

practices. The Commission notes 

regulator access (both domestic and 

foreign) to the data held by an SDR is 

essential for regulators to be able to 

monitor the swap market and certain 

participants relating to systemic risk. 

e. Other Public Interest Considerations 

The American economy and the 

American public depend upon the 

availability of reliable and secure 

markets for price discovery, hedging, 

and speculation. Ensuring the adequate 

safeguarding and the reliability, 

security, and capacity of the systems 

supporting these market functions is a 

core focus in the Commission’s role in 

monitoring and assessing the level of 

systemic risk, and is central to its 

fulfillment of oversight responsibilities. 

As one CFTC Roundtable panelist 

explained, ‘‘if the futures system doesn’t 

work many other things don’t work, and 

it’s a wholly interconnected system. 

And the more we can make all the parts 

more secure the more resilient it’s going 

to be overall.’’ 384

III. Requests for Comment 

A. Comments Regarding Notice of 

Proposed Rulemaking 

The Commission requests comments 

from the public on all aspects of this 

NPRM. This specifically includes 

comments on all aspects of the 

Commission’s preliminary 

consideration of costs and benefits 

associated with the Proposal, and all 

aspects of the Commission’s preliminary 

consideration of the five factors that the 

Commission is required to consider 

under section 15(a) of the CEA. The 

Commission particularly solicits 

comments concerning all aspects of the 

Proposal and its associated costs and 

benefits from DCMs, SEFs, and SDRs, 

from futures and swap market 

participants, from best practices and 

standards organizations, from 

cybersecurity providers and 

cybersecurity experts in both the private 

and public sectors, and from other 

financial regulators. 

The questions below relate to areas 

that the Commission believes may be 

relevant. In addressing these questions 

or any other aspects of the Proposal and 

Commission’s assessments, commenters 

are encouraged to submit any data or 

other information that they may have 

quantifying or qualifying the costs and 

benefits of the Proposal. Comments may 

be submitted directly to the Office of 

Information and Regulatory Affairs, by 

fax at (202) 395–6566 or by email at 

OIRAsubmissions@omb.eop.gov. Please 

provide the Commission with a copy of 

submitted comments so that all 

comments can be summarized and 

addressed in the final rule preamble. 

Refer to the ADDRESSES section of this 

NPRM for comment submission 

instructions to the Commission. A copy 

of the supporting statements for the 

collections of information discussed 

above may be obtained by visiting 

http://RegInfo.gov. OMB is required to 

make a decision concerning the 

collection of information between 30 

and 60 days after publication of this 

document in the Federal Register. 

Therefore, a comment is best assured of 

having its full effect if OMB receives it 

within 30 days of publication. 

1. Do commenters agree with the 

Commission’s analysis of the costs and 

benefits of each provision in the 

Proposal? Please explain why or why 

not. 

2. Do commenters believe that there 

are additional benefits or costs that 

could be quantified or otherwise 

estimated? If so, please identify those 

categories and, if possible, provide 

specific estimates or data. 

3. Do commenters agree that the 

definitions of the categories of risk 

analysis and oversight to be addressed 

by DCM, SEF, and SDR programs of 

system safeguards-related risk analysis 

and oversight included in the Proposal 

are appropriate, sufficiently clear, and 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80179 

reflective of generally accepted best 

practices and standards? Please identify 

any suggested clarifications or changes 

respecting these definitions. 

4. Do commenters agree that following 

generally accepted standards and best 

practices, ensuring tester independence, 

and coordinating BC–DR plans 

appropriately are essential to adequate 

system safeguards and cyber resiliency 

for DCMs, SEFs, and SDRs, and that the 

current rule provisions and guidance 

providing that DCMs, SEFs, and SDRs 

should comply in these regards should 

be changed to require mandatory 

compliance? Please identify, and 

quantify insofar as possible, any new 

costs that DCMs, SEFs, or SDRs would 

incur due to making such compliance 

mandatory. 

5. Do commenters agree that the 

definitions of terms included in the 

proposed §§ 38.1051(h)(1), 

37.1401(h)(1), and 49.24(j)(1) are 

appropriate, sufficiently clear, and 

reflective of generally accepted best 

practices and standards? Please identify 

any suggested clarifications or changes 

respecting these definitions. 

6. Do commenters agree that the types 

of system safeguards testing specified in 

the Proposal, including vulnerability 

testing, external and internal 

penetration testing, controls testing, 

security incident response plan testing, 

and enterprise technology risk 

assessment, are appropriate and 

necessary in today’s cybersecurity 

environment? Please explain why or 

why not. Also, do commenters agree 

that each testing type is appropriately 

and adequately addressed by the 

Proposal? Please explain why or why 

not, and identify any suggested 

clarifications or changes in this 

connection. 

7. Are the types of cybersecurity and 

system safeguards testing included in 

the Proposal sufficient in the aggregate 

to provide the cybersecurity and system 

safeguards protections needed by DCMs, 

SEFs, and SDRs to enable them to fulfill 

their statutory and regulatory 

requirements in the current 

cybersecurity environment? Please 

explain why or why not. Also, should 

the Commission consider requiring 

other types of cybersecurity and system 

safeguards testing not included in the 

Proposal? If so, please identify the other 

types of testing that should be required, 

and if possible provide information 

concerning the costs and benefits that 

would be involved. 

8. The existing system safeguards 

rules for DCMs, SEFs, and SDRs require 

testing sufficient to ensure automated 

system reliability, security, and 

capacity. The Proposal clarifies these 

testing requirements by specifying and 

defining five types of system safeguards 

testing essential to fulfilling these 

existing requirements. Do commenters 

agree that this clarification will not 

impose new costs on DCMs, SEFs, and 

SDRs? Commenters who disagree are 

asked to specify which types of testing 

called for in the Proposal DCMs, SEFs, 

or SDRs do not currently conduct, and 

what new costs such entities would 

incur as the result of the clarification of 

required testing types. 

9. Do commenters agree that the 

minimum testing frequency 

requirements included in the Proposal 

for each of the types of system 

safeguards testing are appropriate in 

today’s cybersecurity environment? 

Please explain why or why not. In your 

response, please be specific with respect 

to the types of testing that you suggest 

should be conducted either more or less 

frequently than specified in the 

Proposal, and indicate the potential 

costs and benefits associated with each 

such modification. 

10. Do commenters agree with the 

requirements included in the Proposal 

for certain testing to be conducted by 

independent contractors? Please explain 

why or why not. If not, please address 

what testing you believe should be 

conducted by independent contractors, 

and the frequency of independent 

contractor testing that should be 

required. Please also indicate the 

potential costs and benefits associated 

with each such modification. 

11. What are the benefits of requiring 

certain tests to be conducted by 

independent contractors? In your 

response, please be specific with respect 

to which tests should be conducted by 

independent contractors and, if 

possible, provide specific estimates or 

data for the costs of each test. 

12. For covered DCMs and SDRs, 

please identify and explain how any of 

the proposed testing requirements 

respecting minimum testing frequency 

and use of independent contractors 

differ from the current practice at the 

entity (e.g., the entity does not currently 

use independent contractors for 

vulnerability testing, whereas the 

proposed rule would require the entity 

to engage independent contractors to 

conduct two of the required quarterly 

tests each year). In cases where the 

Proposal differs from current practice, 

please provide specific estimates of any 

additional costs that the entity would 

incur to comply with the proposal. 

13. Do commenters agree that the 

testing scope requirements provided in 

the Proposal are appropriate, 

sufficiently clear, reflective of generally 

accepted best practices and standards, 

and sufficient to enable DCMs, SEFs, 

and SDRs to fulfill their statutory and 

regulatory responsibilities? Please 

identify any suggested clarifications or 

changes respecting these provisions. 

14. Do commenters agree that the 

internal reporting and review 

requirements provided in the Proposal 

are appropriate, sufficiently clear, 

reflective of generally accepted best 

practices and standards, and sufficient 

to enable DCMs, SEFs, and SDRs to 

fulfill their statutory and regulatory 

responsibilities? Please identify any 

suggested clarifications or changes 

respecting these provisions. 

15. Do commenters agree that the 

remediation requirements provided in 

the Proposal are appropriate, 

sufficiently clear, reflective of generally 

accepted best practices and standards, 

and sufficient to enable DCMs, SEFs, 

and SDRs to fulfill their statutory and 

regulatory responsibilities? Please 

identify any suggested clarifications or 

changes respecting these provisions. 

16. Do commenters believe that there 

are any costs or benefits from the 

Proposal that could be quantified or 

monetized that are unique to a DCM, 

SEF, or an SDR? If so, please identify 

those costs or benefits, and if possible 

provide specific estimates or data. 

17. Are there methods by which the 

Commission could reduce the costs 

imposed by the Proposal, while still 

maintaining the system safeguards for 

DCMs, SEFs, and SDRs that are required 

by law and are appropriate to today’s 

cybersecurity threat environment? If so, 

please explain. 

18. Are there any unintended 

consequences that would result from the 

Proposal? If so, please describe them, 

and explain how the unintended 

consequences would impact any of the 

costs or benefits associated with the 

Proposal, or would impact DCM, SEF, or 

SDR operations. 

19. Does the Proposal appropriately 

describe the potential impacts on the 

protection of market participants and 

the public, efficiency and competition, 

financial integrity of the futures markets 

and price discovery, sound risk 

management practices, and other public 

interest considerations? If not, please 

provide specific examples. 

20. Do commenters believe that there 

are reasonable alternatives to any aspect 

of the Proposal? In the response, please 

specifically describe such alternatives 

and identify their potential costs and 

benefits relative to the proposal. Please 

also describe the potential impacts of 

the alternatives on protection of market 

participants and the public, efficiency 

and competition, financial integrity of 

the futures markets and price discovery, 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80180 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

sound risk management practices, and 

other public interest considerations. 

B. Comments Regarding Advance Notice 

of Proposed Rulemaking Concerning 

Covered SEFs 

The Commission requests comments 

from the public on all aspects of the 

ANPRM included herein concerning 

possible future minimum testing 

frequency requirements and 

independent contractor testing 

requirements for covered SEFs. The 

Commission particularly solicits 

comments concerning all aspects of the 

ANPRM from DCMs, SEFs, and SDRs, 

from futures and swap market 

participants, from best practices and 

standards organizations, from 

cybersecurity providers and 

cybersecurity experts in both the private 

and public sectors, and from other 

financial regulators. 

The questions below relate to areas 

that the Commission believes may be 

relevant. In addressing these questions 

or any other aspects of the ANPRM 

concerning possible future minimum 

testing frequency requirements and 

independent contractor testing 

requirements for covered SEFs, 

commenters are encouraged to submit 

any data or other information that they 

may have quantifying or qualifying costs 

and benefits that could be related to the 

ANPRM. Comments may be submitted 

directly to the Office of Information and 

Regulatory Affairs, by fax at (202) 395– 

6566 or by email at OIRAsubmissions@

omb.eop.gov. Please provide the 

Commission with a copy of submitted 

comments so that all comments can be 

summarized and addressed in the final 

rule preamble. Refer to the ADDRESSES

section of this NPRM for comment 

submission instructions to the 

Commission. 

The Commission is considering 

whether the minimum testing frequency 

and independent contractor testing 

requirements which this NPRM would 

apply to covered DCMs and SDRs 

should be applied, via a future NPRM, 

to the most systemically important 

SEFs, which such a future NPRM would 

define as ‘‘covered SEFs.’’ The 

Commission requests comments on all 

aspects of this question, including 

possible related costs and benefits. In 

addition, commenters are asked to 

address the particular aspects of this 

subject included in the questions below. 

1. Should the minimum testing 

frequency and independent contractor 

testing requirements be applied, via a 

future NPRM, to the most systemically 

important SEFs, or to all SEFs, or 

should such requirements not be 

applied to SEFs at this time? 

2. Given the nature of the swap 

market, would it be more appropriate to 

define ‘‘covered SEF’’ in terms of the 

annual total notional value of all swaps 

traded on or pursuant to the rules of a 

SEF, as compared with the annual total 

notional value of all swaps traded on or 

pursuant to the rules of all SEFs 

regulated by the Commission? Or would 

it be more appropriate to define 

‘‘covered SEF’’ in terms of the annual 

total number of swaps traded on or 

pursuant to the rules of a SEF, as 

compared with the annual total number 

of swaps traded on all SEFs regulated by 

the Commission? 

3. If defining ‘‘covered SEF’’ in terms 

of notional value is more appropriate, 

how should ‘‘notional value’’ be 

defined? 

4. If defining ‘‘covered SEF’’ in terms 

of notional value is more appropriate, 

what percentage share of the annual 

total notional value of all swaps traded 

on all SEFs regulated by the 

Commission should be used to define 

‘‘covered SEF’’? 

5. If defining ‘‘covered SEF’’ in terms 

of the annual total number of swaps 

traded is more appropriate, what 

percentage share of the annual total 

number of all swaps traded on all SEFs 

regulated by the Commission should be 

used to define ‘‘covered SEF’’? 

6. Would it be more appropriate for 

the definition to address the notional 

value or the number of swaps in each 

asset class separately, or to address the 

notional value or the number of all 

swaps combined regardless of asset 

class? 

7. Do commenters agree that overall 

risk mitigation for the U.S. swap market 

as a whole would be enhanced if the 

minimum testing frequency and 

independent contractor testing 

requirements were applied to the most 

systemically important SEFs? Or do 

commenters believe that the testing 

requirements for all SEFs proposed in 

the current NPRM are sufficient for 

appropriate overall risk mitigation? Or 

do commenters believe the minimum 

testing frequency and independent 

contractor testing requirements should 

be applied to all SEFs in order to 

appropriately address the risk to the 

U.S. swap market? 

8. The Commission is considering 

defining ‘‘covered SEF’’ as a SEF for 

which the annual total notional value of 

all swaps traded on or pursuant to the 

rules of the SEF is ten percent (10%) or 

more of the annual total notional value 

of all swaps traded on or pursuant to the 

rules of all SEFs regulated by the 

Commission. Via a future NPRM, such 

SEFs would be subject to the minimum 

testing frequency and independent 

contractor testing requirements 

proposed in this current NPRM for 

covered DCMs and SDRs. Do 

commenters agree that this percentage 

share provides the most appropriate 

means of determining which SEFs 

would be ‘‘covered SEFs’’ subject to 

these requirements? Would a different 

percentage share be more appropriate, 

and if so, what other percentage share 

should be used? Should the 

Commission consider a different 

methodology for defining covered SEFs? 

If so, please explain. 

9. How should the benefits and costs 

of applying the minimum testing 

frequency and independent contractor 

testing requirements to covered SEFs be 

quantified or estimated? If possible, 

provide specific estimates or data. 

10. For each of the five types of 

cybersecurity testing addressed in this 

NPRM, what costs would a covered SEF 

incur to comply with the minimum 

testing frequency and independent 

contractor testing requirements? 

11. To what extent are SEFs currently 

meeting the minimum testing frequency 

and independent contractor testing 

requirements proposed in this NPRM? 

To the extent possible, please provide 

specific estimates or data. 

12. How could a SEF most 

appropriately report to the Commission 

its annual total notional value of all 

swaps traded or its annual total number 

of swaps traded, in order to enable the 

Commission to notify it of whether it is 

a covered SEF? 

13. Are there additional alternatives 

or factors which commenters believe the 

Commission should consider in 

determining what, if anything, to 

propose in connection with the 

definition of covered SEFs and 

minimum testing frequency and 

independent contractor testing 

requirements for covered SEFs? 

List of Subjects 

17 CFR Part 37 

Commodity futures, Reporting and 

recordkeeping requirements, System 

safeguards testing requirements. 

17 CFR Part 38 

Commodity futures, Reporting and 

recordkeeping requirements, System 

safeguards testing requirements. 

17 CFR Part 49 

Administrative practice and 

procedure, Reporting and recordkeeping 

requirements, System safeguards testing 

requirements. 

For the reasons set forth in the 

preamble, the Commodity Futures 

Trading Commission proposes to amend 

17 CFR chapter I as follows: 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80181 

PART 37—SWAP EXECUTION 

FACILITIES 

■ 1. The authority citation for part 37 

continues to read as follows: 

Authority: 7 U.S.C. 1a, 2, 5, 6, 6c, 7, 7a– 

2, 7b–3, and 12a, as amended by Titles VII 

and VIII of the Dodd Frank Wall Street 

Reform and Consumer Protection Act, Pub. L. 

111–203, 124 Stat. 1376. 

■ 2. Amend § 37.1401 as follows: 

■ a. Revise paragraphs (a) and (b); 

■ b. Remove paragraph (f); 

■ c. Redesignate paragraphs (c) through 

(e) as paragraphs (d) through (f); 

■ d. Add new paragraph (c); 

■ e. Revise paragraph (g); 

■ f. Redesignate paragraph (h) as 

paragraph (j); and 

■ g. Add new paragraphs (h), (i), (k), (l), 

and (m). 

The revisions and additions read as 

follows: 

§ 37.1401 Requirements. 

(a) A swap execution facility’s 

program of risk analysis and oversight 

with respect to its operations and 

automated systems must address each of 

the following categories of risk analysis 

and oversight: 

(1) Enterprise risk management and 

governance. This category includes, but 

is not limited to: Assessment, 

mitigation, and monitoring of security 

and technology risk; security and 

technology capital planning and 

investment; board of directors and 

management oversight of technology 

and security; information technology 

audit and controls assessments; 

remediation of deficiencies; and any 

other elements of enterprise risk 

management and governance included 

in generally accepted best practices. 

(2) Information security. This category 

includes, but is not limited to, controls 

relating to: Access to systems and data 

(e.g., least privilege, separation of 

duties, account monitoring and control); 

user and device identification and 

authentication; security awareness 

training; audit log maintenance, 

monitoring, and analysis; media 

protection; personnel security and 

screening; automated system and 

communications protection (e.g., 

network port control, boundary 

defenses, encryption); system and 

information integrity (e.g., malware 

defenses, software integrity monitoring); 

vulnerability management; penetration 

testing; security incident response and 

management; and any other elements of 

information security included in 

generally accepted best practices. 

(3) Business continuity-disaster 

recovery planning and resources. This 

category includes, but is not limited to: 

Regular, periodic testing and review of 

business continuity-disaster recovery 

capabilities, the controls and 

capabilities described in paragraphs (c), 

(d), (j), and (k) of this section; and any 

other elements of business continuitydisaster recovery planning and 

resources included in generally 

accepted best practices. 

(4) Capacity and performance 

planning. This category includes, but is 

not limited to: Controls for monitoring 

the swap execution facility’s systems to 

ensure adequate scalable capacity (e.g., 

testing, monitoring, and analysis of 

current and projected future capacity 

and performance, and of possible 

capacity degradation due to planned 

automated system changes); and any 

other elements of capacity and 

performance planning included in 

generally accepted best practices. 

(5) Systems operations. This category 

includes, but is not limited to: System 

maintenance; configuration 

management (e.g., baseline 

configuration, configuration change and 

patch management, least functionality, 

inventory of authorized and 

unauthorized devices and software); 

event and problem response and 

management; and any other elements of 

system operations included in generally 

accepted best practices. 

(6) Systems development and quality 

assurance. This category includes, but is 

not limited to: Requirements 

development; pre-production and 

regression testing; change management 

procedures and approvals; outsourcing 

and vendor management; training in 

secure coding practices; and any other 

elements of systems development and 

quality assurance included in generally 

accepted best practices. 

(7) Physical security and 

environmental controls. This category 

includes, but is not limited to: Physical 

access and monitoring; power, 

telecommunication, and environmental 

controls; fire protection; and any other 

elements of physical security and 

environmental controls included in 

generally accepted best practices. 

(b) In addressing the categories of risk 

analysis and oversight required under 

paragraph (a) of this section, a swap 

execution facility shall follow generally 

accepted standards and best practices 

with respect to the development, 

operation, reliability, security, and 

capacity of automated systems. 

(c) A swap execution facility must 

maintain a business continuity-disaster 

recovery plan and business continuitydisaster recovery resources, emergency 

procedures, and backup facilities 

sufficient to enable timely recovery and 

resumption of its operations and 

resumption of its ongoing fulfillment of 

its responsibilities and obligations as a 

swap execution facility following any 

disruption of its operations. Such 

responsibilities and obligations include, 

without limitation: Order processing 

and trade matching; transmission of 

matched orders to a designated clearing 

organization for clearing, where 

appropriate; price reporting; market 

surveillance; and maintenance of a 

comprehensive audit trail. The swap 

execution facility’s business continuitydisaster recovery plan and resources 

generally should enable resumption of 

trading and clearing of swaps executed 

on or pursuant to the rules of the swap 

execution facility during the next 

business day following the disruption. 

Swap execution facilities determined by 

the Commission to be critical financial 

markets are subject to more stringent 

requirements in this regard, set forth in 

§ 40.9 of this chapter. A swap execution 

facility must update its business 

continuity-disaster recovery plan and 

emergency procedures at a frequency 

determined by an appropriate risk 

analysis, but at a minimum no less 

frequently than annually. 

* * * * * 

(g) As part of a swap execution 

facility’s obligation to produce books 

and records in accordance with § 1.31 of 

this chapter, Core Principle 10 

(Recordkeeping and Reporting), and 

§§ 37.1000 and 37.1001, a swap 

execution facility must provide to the 

Commission the following system 

safeguards-related books and records, 

promptly upon the request of any 

Commission representative: 

(1) Current copies of its business 

continuity-disaster recovery plans and 

other emergency procedures; 

(2) All assessments of its operational 

risks or system safeguards-related 

controls; 

(3) All reports concerning system 

safeguards testing and assessment 

required by this chapter, whether 

performed by independent contractors 

or by employees of the swap execution 

facility; and 

(4) All other books and records 

requested by Commission staff in 

connection with Commission oversight 

of system safeguards pursuant to the Act 

or to part 37 of the Commission’s 

regulations, or in connection with 

Commission maintenance of a current 

profile of the swap execution facility’s 

automated systems. 

(5) Nothing in paragraph (g) of this 

section shall be interpreted as reducing 

or limiting in any way a swap execution 

facility’s obligation to comply with Core 

Principle 10 (Recordkeeping and 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80182 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

Reporting) or with § 1.31 of this chapter, 

or §§ 37.1000 or 37.1001 of the 

Commission’s regulations. 

(h) A swap execution facility must 

conduct regular, periodic, objective 

testing and review of its automated 

systems to ensure that they are reliable, 

secure, and have adequate scalable 

capacity. It must also conduct regular, 

periodic testing and review of its 

business continuity-disaster recovery 

capabilities. Such testing and review 

shall include, without limitation, all of 

the types of testing set forth in 

paragraph (h) of this section. 

(1) Definitions. As used in paragraph 

(h) of this section: 

Controls means the safeguards or 

countermeasures employed by the swap 

execution facility in order to protect the 

reliability, security, or capacity of its 

automated systems or the 

confidentiality, integrity, and 

availability of its data and information, 

and in order to enable the swap 

execution facility to fulfill its statutory 

and regulatory responsibilities. 

Controls testing means assessment of 

the swap execution facility’s controls to 

determine whether such controls are 

implemented correctly, are operating as 

intended, and are enabling the swap 

execution facility to meet the system 

safeguards requirements established by 

this chapter. 

Enterprise technology risk assessment 

means a written assessment that 

includes, but is not limited to, an 

analysis of threats and vulnerabilities in 

the context of mitigating controls. An 

enterprise technology risk assessment 

identifies, estimates, and prioritizes 

risks to swap execution facility 

operations or assets, or to market 

participants, individuals, or other 

entities, resulting from impairment of 

the confidentiality, integrity, and 

availability of data and information or 

the reliability, security, or capacity of 

automated systems. 

External penetration testing means 

attempts to penetrate the swap 

execution facility’s automated systems 

from outside the systems’ boundaries to 

identify and exploit vulnerabilities. 

Methods of conducting external 

penetration testing include, but are not 

limited to, methods for circumventing 

the security features of an automated 

system. 

Internal penetration testing means 

attempts to penetrate the swap 

execution facility’s automated systems 

from inside the systems’ boundaries, to 

identify and exploit vulnerabilities. 

Methods of conducting internal 

penetration testing include, but are not 

limited to, methods for circumventing 

the security features of an automated 

system. 

Key controls means those controls that 

an appropriate risk analysis determines 

are either critically important for 

effective system safeguards or intended 

to address risks that evolve or change 

more frequently and therefore require 

more frequent review to ensure their 

continuing effectiveness in addressing 

such risks. 

Security incident means a cyber 

security or physical security event that 

actually or potentially jeopardizes 

automated system operation, reliability, 

security, or capacity, or the availability, 

confidentiality or integrity of data. 

Security incident response plan 

means a written plan documenting the 

swap execution facility’s policies, 

controls, procedures, and resources for 

identifying, responding to, mitigating, 

and recovering from security incidents, 

and the roles and responsibilities of its 

management, staff and independent 

contractors in responding to security 

incidents. A security incident response 

plan may be a separate document or a 

business continuity-disaster recovery 

plan section or appendix dedicated to 

security incident response. 

Security incident response plan 

testing means testing of a swap 

execution facility’s security incident 

response plan to determine the plan’s 

effectiveness, identify its potential 

weaknesses or deficiencies, enable 

regular plan updating and improvement, 

and maintain organizational 

preparedness and resiliency with 

respect to security incidents. Methods of 

conducting security incident response 

plan testing may include, but are not 

limited to, checklist completion, walkthrough or table-top exercises, 

simulations, and comprehensive 

exercises. 

Vulnerability testing means testing of 

a swap execution facility’s automated 

systems to determine what information 

may be discoverable through a 

reconnaissance analysis of those 

systems and what vulnerabilities may be 

present on those systems. 

(2) Vulnerability testing. A swap 

execution facility shall conduct 

vulnerability testing of a scope 

sufficient to satisfy the requirements set 

forth in paragraph (k) of this section, at 

a frequency determined by an 

appropriate risk analysis. 

(i) Such vulnerability testing shall 

include automated vulnerability 

scanning. Where indicated by 

appropriate risk analysis, such scanning 

must be conducted on an authenticated 

basis, e.g., using log-in credentials. 

Where scanning is conducted on an 

unauthenticated basis, the designated 

contract market must implement 

effective compensating controls. 

(ii) Vulnerability testing for a swap 

execution facility shall be conducted by 

qualified, independent professionals. 

Such qualified independent 

professionals may be independent 

contractors or employees of the swap 

execution facility, but shall not be 

persons responsible for development or 

operation of the systems or capabilities 

being tested. 

(3) Penetration testing—(i) External 

penetration testing. A swap execution 

facility shall conduct external 

penetration testing of a scope sufficient 

to satisfy the requirements set forth in 

paragraph (k) of this section, at a 

frequency determined by an appropriate 

risk analysis. 

(A) External penetration testing for a 

swap execution facility shall be 

conducted by qualified, independent 

professionals. Such qualified 

independent professionals may be 

independent contractors or employees 

of the swap execution facility, but shall 

not be persons responsible for 

development or operation of the systems 

or capabilities being tested. 

(B) [Reserved] 

(ii) Internal penetration testing. A 

swap execution facility shall conduct 

internal penetration testing of a scope 

sufficient to satisfy the requirements set 

forth in paragraph (k) of this section, at 

a frequency determined by an 

appropriate risk analysis. 

(A) A swap execution facility may 

conduct internal penetration testing by 

engaging independent contractors, or by 

using employees of the swap execution 

facility who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

(B) [Reserved] 

(4) Controls testing. A swap execution 

facility shall conduct controls testing of 

a scope sufficient to satisfy the 

requirements set forth in paragraph (k) 

of this section, at a frequency 

determined by an appropriate risk 

analysis. Such controls testing must 

include testing of each control included 

in the swap execution facility’s program 

of risk analysis and oversight. 

(i) Controls testing for a swap 

execution facility shall be conducted by 

qualified, independent professionals. 

Such qualified independent 

professionals may be independent 

contractors or employees of the swap 

execution facility, but shall not be 

persons responsible for development or 

operation of the systems or capabilities 

being tested. 

(ii) [Reserved] 

(5) Security incident response plan 

testing. A swap execution facility shall 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80183 

conduct security incident response plan 

testing sufficient to satisfy the 

requirements set forth in paragraph (k) 

of this section, at a frequency 

determined by an appropriate risk 

analysis. 

(i) A swap execution facility’s security 

incident response plan shall include, 

without limitation, the swap execution 

facility’s definition and classification of 

security incidents, its policies and 

procedures for reporting security 

incidents and for internal and external 

communication and information sharing 

regarding security incidents, and the 

hand-off and escalation points in its 

security incident response process. 

(ii) A swap execution facility may 

coordinate its security incident response 

plan testing with other testing required 

by this section or with testing of its 

other business continuity-disaster 

recovery and crisis management plans. 

(iii) A swap execution facility may 

conduct security incident response plan 

testing by engaging independent 

contractors or by using employees of the 

swap execution facility who are not 

responsible for development or 

operation of the systems or capabilities 

being tested. 

(6) Enterprise technology risk 

assessment. A swap execution facility 

shall conduct enterprise technology risk 

assessment of a scope sufficient to 

satisfy the requirements set forth in 

paragraph (k) of this section, at a 

frequency determined by an appropriate 

risk analysis. 

(i) A swap execution facility may 

conduct enterprise technology risk 

assessments by using independent 

contractors or employees of the swap 

execution facility who are not 

responsible for development or 

operation of the systems or capabilities 

being assessed. 

(ii) [Reserved] 

(i) To the extent practicable, a swap 

execution facility shall: 

(1) Coordinate its business continuitydisaster recovery plan with those of the 

market participants it depends upon to 

provide liquidity, in a manner adequate 

to enable effective resumption of 

activity in its markets following a 

disruption causing activation of the 

swap execution facility’s business 

continuity-disaster recovery plan; 

(2) Initiate and coordinate periodic, 

synchronized testing of its business 

continuity-disaster recovery plan with 

those of the market participants it 

depends upon to provide liquidity; and 

(3) Ensure that its business 

continuity-disaster recovery plan takes 

into account the business continuitydisaster recovery plans of its 

telecommunications, power, water, and 

other essential service providers. 

* * * * * 

(k) Scope of testing and assessment. 

The scope for all system safeguards 

testing and assessment required by this 

part must be broad enough to include all 

testing of automated systems and 

controls necessary to identify any 

vulnerability which, if triggered, could 

enable an intruder or unauthorized user 

or insider to: 

(1) Interfere with the swap execution 

facility’s operations or with fulfillment 

of its statutory and regulatory 

responsibilities; 

(2) Impair or degrade the reliability, 

security, or adequate scalable capacity 

of the swap execution facility’s 

automated systems; 

(3) Add to, delete, modify, exfiltrate, 

or compromise the integrity of any data 

related to the swap execution facility’s 

regulated activities; or 

(4) Undertake any other unauthorized 

action affecting the swap execution 

facility’s regulated activities or the 

hardware or software used in 

connection with those activities. 

(l) Internal reporting and review. Both 

the senior management and the Board of 

Directors of the swap execution facility 

shall receive and review reports setting 

forth the results of all testing and 

assessment required by this section. The 

swap execution facility shall establish 

and follow appropriate procedures for 

the remediation of issues identified 

through such review, as provided in 

paragraph (m) of this section, and for 

evaluation of the effectiveness of testing 

and assessment protocols. 

(m) Remediation. A swap execution 

facility shall analyze the results of the 

testing and assessment required by this 

section to identify all vulnerabilities 

and deficiencies in its systems. The 

swap execution facility must remediate 

those vulnerabilities and deficiencies to 

the extent necessary to enable the swap 

execution facility to fulfill the system 

safeguards requirements of this part and 

meet its statutory and regulatory 

obligations. Such remediation must be 

timely in light of appropriate risk 

analysis with respect to the risks 

presented by such vulnerabilities and 

deficiencies. 

Appendix B to Part 37—[Removed and 

Reserved] 

■ 3. In Appendix B to Part 37, under the 

centered section heading Core Principle 

14 of Section 5h of the Act—System 

Safeguards, remove and reserve the text. 

PART 38—DESIGNATED CONTACT 

MARKETS 

■ 4. The authority citation for part 38 

continues to read as follows: 

Authority: 7 U.S.C. 1a, 2, 6, 6a, 6c, 6e, 6d, 

6f, 6g, 6i, 6j, 6k, 6l, 6m, 6n, 7, 7a–2, 7b, 7b– 

1, 7b–3, 8, 9, 15, and 21, as amended by the 

Dodd-Frank Wall Street Reform and 

Consumer Protection Act, Pub. L. 111–203, 

124 Stat. 1376. 

■ 5. Amend § 38.1051 as follows: 

■ a. Revise paragraphs (a), (b), (c), (g), 

(h), and (i) introductory text; and 

■ b. Add new paragraphs (k), (l), (m), 

and (n). 

The revisions and additions read as 

follows: 

§ 38.1051 General requirements. 

(a) A designated contract market’s 

program of risk analysis and oversight 

with respect to its operations and 

automated systems must address each of 

the following categories of risk analysis 

and oversight: 

(1) Enterprise risk management and 

governance. This category includes, but 

is not limited to: Assessment, 

mitigation, and monitoring of security 

and technology risk; security and 

technology capital planning and 

investment; board of directors and 

management oversight of technology 

and security; information technology 

audit and controls assessments; 

remediation of deficiencies; and any 

other elements of enterprise risk 

management and governance included 

in generally accepted best practices. 

(2) Information security. This category 

includes, but is not limited to, controls 

relating to: Access to systems and data 

(e.g., least privilege, separation of 

duties, account monitoring and control); 

user and device identification and 

authentication; security awareness 

training; audit log maintenance, 

monitoring, and analysis; media 

protection; personnel security and 

screening; automated system and 

communications protection (e.g., 

network port control, boundary 

defenses, encryption); system and 

information integrity (e.g., malware 

defenses, software integrity monitoring); 

vulnerability management; penetration 

testing; security incident response and 

management; and any other elements of 

information security included in 

generally accepted best practices. 

(3) Business continuity-disaster 

recovery planning and resources. This 

category includes, but is not limited to: 

Regular, periodic testing and review of 

business continuity-disaster recovery 

capabilities, the controls and 

capabilities described in paragraphs (c), 

(d), (j), and (k) of this section; and any 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80184 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

other elements of business continuitydisaster recovery planning and 

resources included in generally 

accepted best practices. 

(4) Capacity and performance 

planning. This category includes, but is 

not limited to: Controls for monitoring 

the designated contract market’s 

systems to ensure adequate scalable 

capacity (e.g., testing, monitoring, and 

analysis of current and projected future 

capacity and performance, and of 

possible capacity degradation due to 

planned automated system changes); 

and any other elements of capacity and 

performance planning included in 

generally accepted best practices. 

(5) Systems operations. This category 

includes, but is not limited to: System 

maintenance; configuration 

management (e.g., baseline 

configuration, configuration change and 

patch management, least functionality, 

inventory of authorized and 

unauthorized devices and software); 

event and problem response and 

management; and any other elements of 

system operations included in generally 

accepted best practices. 

(6) Systems development and quality 

assurance. This category includes, but is 

not limited to: Requirements 

development; pre-production and 

regression testing; change management 

procedures and approvals; outsourcing 

and vendor management; training in 

secure coding practices; and any other 

elements of systems development and 

quality assurance included in generally 

accepted best practices. 

(7) Physical security and 

environmental controls. This category 

includes, but is not limited to: Physical 

access and monitoring; power, 

telecommunication, and environmental 

controls; fire protection; and any other 

elements of physical security and 

environmental controls included in 

generally accepted best practices. 

(b) In addressing the categories of risk 

analysis and oversight required under 

paragraph (a) of this section, a 

designated contract market shall follow 

generally accepted standards and best 

practices with respect to the 

development, operation, reliability, 

security, and capacity of automated 

systems. 

(c) A designated contract market must 

maintain a business continuity-disaster 

recovery plan and business continuitydisaster recovery resources, emergency 

procedures, and backup facilities 

sufficient to enable timely recovery and 

resumption of its operations and 

resumption of its ongoing fulfillment of 

its responsibilities and obligations as a 

designated contract market following 

any disruption of its operations. Such 

responsibilities and obligations include, 

without limitation: Order processing 

and trade matching; transmission of 

matched orders to a designated clearing 

organization for clearing; price 

reporting; market surveillance; and 

maintenance of a comprehensive audit 

trail. The designated contract market’s 

business continuity-disaster recovery 

plan and resources generally should 

enable resumption of trading and 

clearing of the designated contract 

market’s products during the next 

business day following the disruption. 

Designated contract markets determined 

by the Commission to be critical 

financial markets are subject to more 

stringent requirements in this regard, set 

forth in § 40.9 of this chapter. Electronic 

trading is an acceptable backup for open 

outcry trading in the event of a 

disruption. A designated contract 

market must update its business 

continuity-disaster recovery plan and 

emergency procedures at a frequency 

determined by an appropriate risk 

analysis, but at a minimum no less 

frequently than annually. 

* * * * * 

(g) As part of a designated contract 

market’s obligation to produce books 

and records in accordance with 

Commission regulation § 1.31 of this 

chapter, Core Principle 18 

(Recordkeeping), and §§ 38.950 and 

38.951, a designated contract market 

must provide to the Commission the 

following system safeguards-related 

books and records, promptly upon the 

request of any Commission 

representative: 

(1) Current copies of its business 

continuity-disaster recovery plans and 

other emergency procedures; 

(2) All assessments of its operational 

risks or system safeguards-related 

controls; 

(3) All reports concerning system 

safeguards testing and assessment 

required by this chapter, whether 

performed by independent contractors 

or by employees of the designated 

contract market; and 

(4) All other books and records 

requested by Commission staff in 

connection with Commission oversight 

of system safeguards pursuant to the Act 

or to part 38 of the Commission’s 

regulations, or in connection with 

Commission maintenance of a current 

profile of the designated contract 

market’s automated systems. 

(5) Nothing in paragraph (g) of this 

section shall be interpreted as reducing 

or limiting in any way a designated 

contract market’s obligation to comply 

with Core Principle 18 (Recordkeeping) 

or with § 1.31 of this chapter, or 

§§ 38.950 or 38.951 of the Commission’s 

regulations. 

(h) A designated contract market must 

conduct regular, periodic, objective 

testing and review of its automated 

systems to ensure that they are reliable, 

secure, and have adequate scalable 

capacity. It must also conduct regular, 

periodic testing and review of its 

business continuity-disaster recovery 

capabilities. Such testing and review 

shall include, without limitation, all of 

the types of testing set forth in 

paragraph (h) of this section. A covered 

designated contract market, as defined 

in this section, shall be subject to the 

additional requirements regarding 

minimum testing frequency and 

independent contractor testing set forth 

in paragraph (h) of this section. 

(1) Definitions. As used in paragraph 

(h) of this section: 

Controls means the safeguards or 

countermeasures employed by the 

designated contract market in order to 

protect the reliability, security, or 

capacity of its automated systems or the 

confidentiality, integrity, and 

availability of its data and information, 

and in order to enable the designated 

contract market to fulfill its statutory 

and regulatory responsibilities. 

Controls testing means assessment of 

the designated contract market’s 

controls to determine whether such 

controls are implemented correctly, are 

operating as intended, and are enabling 

the designated contract market to meet 

the system safeguards requirements 

established by this chapter. 

Covered designated contract market 

means a designated contract market 

whose annual total trading volume in 

calendar year 2015, or in any 

subsequent calendar year, is five percent 

(5%) or more of the combined annual 

total trading volume of all designated 

contract markets regulated by the 

Commission for the year in question, 

based on annual total trading volume 

information provided to the 

Commission by each designated 

contract market pursuant to the 

procedure set forth in this chapter. A 

covered designated contract market that 

has annual total trading volume of less 

than five percent (5%) of the combined 

annual total trading volume of all 

designated contract markets regulated 

by the Commission for two consecutive 

calendar years ceases to be a covered 

designated contract market as of March 

1 of the calendar year following such 

two consecutive calendar years. 

Enterprise technology risk assessment 

means a written assessment that 

includes, but is not limited to, an 

analysis of threats and vulnerabilities in 

the context of mitigating controls. An 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80185 

enterprise technology risk assessment 

identifies, estimates, and prioritizes 

risks to designated contract market 

operations or assets, or to market 

participants, individuals, or other 

entities, resulting from impairment of 

the confidentiality, integrity, and 

availability of data and information or 

the reliability, security, or capacity of 

automated systems. 

External penetration testing means 

attempts to penetrate the designated 

contract market’s automated systems 

from outside the systems’ boundaries to 

identify and exploit vulnerabilities. 

Methods of conducting external 

penetration testing include, but are not 

limited to, methods for circumventing 

the security features of an automated 

system. 

Internal penetration testing means 

attempts to penetrate the designated 

contract market’s automated systems 

from inside the systems’ boundaries, to 

identify and exploit vulnerabilities. 

Methods of conducting internal 

penetration testing include, but are not 

limited to, methods for circumventing 

the security features of an automated 

system. 

Key controls means those controls that 

an appropriate risk analysis determines 

are either critically important for 

effective system safeguards or intended 

to address risks that evolve or change 

more frequently and therefore require 

more frequent review to ensure their 

continuing effectiveness in addressing 

such risks. 

Security incident means a cyber 

security or physical security event that 

actually or potentially jeopardizes 

automated system operation, reliability, 

security, or capacity, or the availability, 

confidentiality or integrity of data. 

Security incident response plan 

means a written plan documenting the 

designated contract market’s policies, 

controls, procedures, and resources for 

identifying, responding to, mitigating, 

and recovering from security incidents, 

and the roles and responsibilities of its 

management, staff and independent 

contractors in responding to security 

incidents. A security incident response 

plan may be a separate document or a 

business continuity-disaster recovery 

plan section or appendix dedicated to 

security incident response. 

Security incident response plan 

testing means testing of a designated 

contract market’s security incident 

response plan to determine the plan’s 

effectiveness, identify its potential 

weaknesses or deficiencies, enable 

regular plan updating and improvement, 

and maintain organizational 

preparedness and resiliency with 

respect to security incidents. Methods of 

conducting security incident response 

plan testing may include, but are not 

limited to, checklist completion, walkthrough or table-top exercises, 

simulations, and comprehensive 

exercises. 

Vulnerability testing means testing of 

a designated contract market’s 

automated systems to determine what 

information may be discoverable 

through a reconnaissance analysis of 

those systems and what vulnerabilities 

may be present on those systems. 

(2) Vulnerability testing. A designated 

contract market shall conduct 

vulnerability testing of a scope 

sufficient to satisfy the requirements set 

forth in in paragraph (k) of this section, 

at a frequency determined by an 

appropriate risk analysis. 

(i) Such vulnerability testing shall 

include automated vulnerability 

scanning. Where indicated by 

appropriate risk analysis, such scanning 

must be conducted on an authenticated 

basis, e.g., using log-in credentials. 

Where scanning is conducted on an 

unauthenticated basis, the designated 

contract market must implement 

effective compensating controls. 

(ii) At a minimum, a covered 

designated contract market shall 

conduct such vulnerability testing no 

less frequently than quarterly. 

(iii) A covered designated contract 

market shall engage independent 

contractors to conduct two of the 

required quarterly vulnerability tests 

each year. The covered designated 

contract market may conduct other 

vulnerability testing by using employees 

of the covered designated contract 

market who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

(iv) Vulnerability testing for a 

designated contract market which is not 

a covered designated contract market as 

defined in this section shall be 

conducted by qualified, independent 

professionals. Such qualified 

independent professionals may be 

independent contractors or employees 

of the designated contract market, but 

shall not be persons responsible for 

development or operation of the systems 

or capabilities being tested. 

(3) Penetration testing—(i) External 

penetration testing. A designated 

contract market shall conduct external 

penetration testing of a scope sufficient 

to satisfy the requirements set forth in 

paragraph (k) of this section, at a 

frequency determined by an appropriate 

risk analysis. 

(A) At a minimum, a covered 

designated contract market shall 

conduct such external penetration 

testing no less frequently than annually. 

(B) A covered designated contract 

market shall engage independent 

contractors to conduct the required 

annual external penetration test. The 

covered designated contract market may 

conduct other external penetration 

testing by using employees of the 

covered designated contract market who 

are not responsible for development or 

operation of the systems or capabilities 

being tested. 

(C) External penetration testing for a 

designated contract market which is not 

a covered designated contract market as 

defined in this section shall be 

conducted by qualified, independent 

professionals. Such qualified 

independent professionals may be 

independent contractors or employees 

of the designated contract market, but 

shall not be persons responsible for 

development or operation of the systems 

or capabilities being tested. 

(ii) Internal penetration testing. A 

designated contract market shall 

conduct internal penetration testing of a 

scope sufficient to satisfy the 

requirements set forth in paragraph (k) 

of this section, at a frequency 

determined by an appropriate risk 

analysis. 

(A) At a minimum, a covered 

designated contract market shall 

conduct such internal penetration 

testing no less frequently than annually. 

(B) A designated contract market may 

conduct internal penetration testing by 

engaging independent contractors, or by 

using employees of the designated 

contract market who are not responsible 

for development or operation of the 

systems or capabilities being tested. 

(4) Controls testing. A designated 

contract market shall conduct controls 

testing of a scope sufficient to satisfy the 

requirements set forth in paragraph (k) 

of this section, at a frequency 

determined by an appropriate risk 

analysis. Such controls testing must 

include testing of each control included 

in the designated contract market’s 

program of risk analysis and oversight. 

(i) At a minimum, a covered 

designated contract market shall such 

conduct controls testing no less 

frequently than every two years. The 

covered designated contract market may 

conduct such testing on a rolling basis 

over the course of the minimum twoyear period or over a minimum period 

determined by an appropriate risk 

analysis, whichever is shorter. 

(ii) A covered designated contract 

market shall engage independent 

contractors to test and assess the key 

controls included in its program of risk 

analysis and oversight no less frequently 

than every two years. The covered 

designated contract market may conduct 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80186 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

any other controls testing required by 

paragraph (h)(4) of this section by using 

independent contractors or employees 

of the covered designated contract 

market who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

(iii) Controls testing for a designated 

contract market which is not a covered 

designated contract market as defined in 

this section shall be conducted by 

qualified, independent professionals. 

Such qualified independent 

professionals may be independent 

contractors or employees of the 

designated contract market, but shall 

not be persons responsible for 

development or operation of the systems 

or capabilities being tested. 

(5) Security incident response plan 

testing. A designated contract market 

shall conduct security incident response 

plan testing sufficient to satisfy the 

requirements set forth in paragraph (k) 

of this section, at a frequency 

determined by an appropriate risk 

analysis. 

(i) A designated contract market’s 

security incident response plan shall 

include, without limitation, the 

designated contract market’s definition 

and classification of security incidents, 

its policies and procedures for reporting 

security incidents and for internal and 

external communication and 

information sharing regarding security 

incidents, and the hand-off and 

escalation points in its security incident 

response process. 

(ii) A designated contract market may 

coordinate its security incident response 

plan testing with other testing required 

by this section or with testing of its 

other business continuity-disaster 

recovery and crisis management plans. 

(iii) At a minimum, a covered 

designated contract market shall 

conduct such security incident response 

plan testing no less frequently than 

annually. 

(iv) A designated contract market may 

conduct security incident response plan 

testing by engaging independent 

contractors or by using employees of the 

designated contract market who are not 

responsible for development or 

operation of the systems or capabilities 

being tested. 

(6) Enterprise technology risk 

assessment. A designated contract 

market shall conduct enterprise 

technology risk assessment of a scope 

sufficient to satisfy the requirements set 

forth in paragraph (k) of this section, at 

a frequency determined by an 

appropriate risk analysis. 

(i) A covered designated contract 

market shall conduct an enterprise 

technology risk assessment no less 

frequently than annually. 

(ii) A designated contract market may 

conduct enterprise technology risk 

assessments by using independent 

contractors or employees of the 

designated contract market who are not 

responsible for development or 

operation of the systems or capabilities 

being assessed. 

(i) To the extent practicable, a 

designated contract market shall: 

* * * * * 

(k) Scope of testing and assessment. 

The scope for all system safeguards 

testing and assessment required by this 

part must be broad enough to include all 

testing of automated systems and 

controls necessary to identify any 

vulnerability which, if triggered, could 

enable an intruder or unauthorized user 

or insider to: 

(1) Interfere with the designated 

contract market’s operations or with 

fulfillment of its statutory and 

regulatory responsibilities; 

(2) Impair or degrade the reliability, 

security, or adequate scalable capacity 

of the designated contract market’s 

automated systems; 

(3) Add to, delete, modify, exfiltrate, 

or compromise the integrity of any data 

related to the designated contract 

market’s regulated activities; or 

(4) Undertake any other unauthorized 

action affecting the designated contract 

market’s regulated activities or the 

hardware or software used in 

connection with those activities. 

(l) Internal reporting and review. Both 

the senior management and the Board of 

Directors of the designated contract 

market shall receive and review reports 

setting forth the results of all testing and 

assessment required by this section. The 

designated contract market shall 

establish and follow appropriate 

procedures for the remediation of issues 

identified through such review, as 

provided in paragraph (m) this section, 

and for evaluation of the effectiveness of 

testing and assessment protocols. 

(m) Remediation. A designated 

contract market shall analyze the results 

of the testing and assessment required 

by this section to identify all 

vulnerabilities and deficiencies in its 

systems. The designated contract market 

must remediate those vulnerabilities 

and deficiencies to the extent necessary 

to enable the designated contract market 

to fulfill the system safeguards 

requirements of this part and meet its 

statutory and regulatory obligations. 

Such remediation must be timely in 

light of appropriate risk analysis with 

respect to the risks presented by such 

vulnerabilities and deficiencies. 

(n) Required production of annual 

total trading volume. (1) As used in 

paragraph (n) of this section, annual 

total trading volume means the total 

number of all contracts traded on or 

pursuant to the rules of a designated 

contract market during a calendar year. 

(2) Each designated contract market 

shall provide to the Commission for 

calendar year 2015 and each calendar 

year thereafter its annual total trading 

volume, providing this information for 

2015 within 30 calendar days of the 

effective date of the final version of this 

rule, and for 2016 and subsequent years 

by January 31 of the following calendar 

year. For calendar year 2015 and each 

calendar year thereafter, the 

Commission shall provide to each 

designated contract market the 

percentage of the combined annual total 

trading volume of all designated 

contract markets regulated by the 

Commission which is constituted by 

that designated contract market’s annual 

total trading volume, providing this 

information for 2015 within 60 calendar 

days of the effective date of the final 

version of this rule, and for 2016 and 

subsequent years by February 28 of the 

following calendar year. 

PART 49—SWAP DATA 

REPOSITORIES 

■ 6. The authority citation for part 49 

continues to read as follows: 

Authority: 7 U.S.C. 12a and 24a, as 

amended by Title VII of the Wall Street 

Reform and Consumer Protection Act, Pub. L. 

111–203, 124 Stat. 1376 (2010), unless 

otherwise noted. 

■ 7. Amend § 49.24 as follows: 

■ a. Revise paragraphs (b), (c), (d), (i), (j), 

and (k) introductory text; and 

■ b. Add new paragraphs (l), (m), and 

(n). 

The revisions and additions read as 

follows: 

§ 49.24 System Safeguards. 

* * * * * 

(b) A registered swap data repository’s 

program of risk analysis and oversight 

with respect to its operations and 

automated systems must address each of 

the following categories of risk analysis 

and oversight: 

(1) Enterprise risk management and 

governance. This category includes, but 

is not limited to: Assessment, 

mitigation, and monitoring of security 

and technology risk; security and 

technology capital planning and 

investment; board of directors and 

management oversight of technology 

and security; information technology 

audit and controls assessments; 

remediation of deficiencies; and any 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80187 

other elements of enterprise risk 

management and governance included 

in generally accepted best practices. 

(2) Information security. This category 

includes, but is not limited to, controls 

relating to: Access to systems and data 

(e.g. least privilege, separation of duties, 

account monitoring and control); user 

and device identification and 

authentication; security awareness 

training; audit log maintenance, 

monitoring, and analysis; media 

protection; personnel security and 

screening; automated system and 

communications protection (e.g., 

network port control, boundary 

defenses, encryption); system and 

information integrity (e.g., malware 

defenses, software integrity monitoring); 

vulnerability management; penetration 

testing; security incident response and 

management; and any other elements of 

information security included in 

generally accepted best practices. 

(3) Business continuity-disaster 

recovery planning and resources. This 

category includes, but is not limited to: 

Regular, periodic testing and review of 

business continuity-disaster recovery 

capabilities, the controls and 

capabilities described in paragraphs (a), 

(d), (e), (f), and (k) of this section; and 

any other elements of business 

continuity-disaster recovery planning 

and resources included in generally 

accepted best practices. 

(4) Capacity and performance 

planning. This category includes, but is 

not limited to: Controls for monitoring 

the designated contract market’s 

systems to ensure adequate scalable 

capacity (e.g., testing, monitoring, and 

analysis of current and projected future 

capacity and performance, and of 

possible capacity degradation due to 

planned automated system changes); 

and any other elements of capacity and 

performance planning included in 

generally accepted best practices. 

(5) Systems operations. This category 

includes, but is not limited to: System 

maintenance; configuration 

management (e.g., baseline 

configuration, configuration change and 

patch management, least functionality, 

inventory of authorized and 

unauthorized devices and software); 

event and problem response and 

management; and any other elements of 

system operations included in generally 

accepted best practices. 

(6) Systems development and quality 

assurance. This category includes, but is 

not limited to: Requirements 

development; pre-production and 

regression testing; change management 

procedures and approvals; outsourcing 

and vendor management; training in 

secure coding practices; and any other 

elements of systems development and 

quality assurance included in generally 

accepted best practices. 

(7) Physical security and 

environmental controls. This category 

includes, but is not limited to: Physical 

access and monitoring; power, 

telecommunication, and environmental 

controls; fire protection; and any other 

elements of physical security and 

environmental controls included in 

generally accepted best practices. 

(c) In addressing the categories of risk 

analysis and oversight required under 

paragraph (b) of this section, a registered 

swap data repository shall follow 

generally accepted standards and best 

practices with respect to the 

development, operation, reliability, 

security, and capacity of automated 

systems. 

(d) A registered swap data repository 

shall maintain a business continuitydisaster recovery plan and business 

continuity-disaster recovery resources, 

emergency procedures, and backup 

facilities sufficient to enable timely 

recovery and resumption of its 

operations and resumption of its 

ongoing fulfillment of its duties and 

obligations as a swap data repository 

following any disruption of its 

operations. Such duties and obligations 

include, without limitation: The duties 

set forth in § 49.19, and maintenance of 

a comprehensive audit trail. The swap 

data repository’s business continuitydisaster recovery plan and resources 

generally should enable resumption of 

swap data repository’s operations and 

resumption of ongoing fulfillment of the 

swap data repository’s duties and 

obligations during the next business day 

following the disruption. A swap data 

repository shall update its business 

continuity-disaster recovery plan and 

emergency procedures at a frequency 

determined by an appropriate risk 

analysis, but at a minimum no less 

frequently than annually. 

* * * * * 

(i) As part of a swap data repository’s 

obligation to produce books and records 

in accordance with §§ 1.31 and 45.2 of 

this chapter, and § 49.12, a swap data 

repository must provide to the 

Commission the following system 

safeguards-related books and records, 

promptly upon the request of any 

Commission representative: 

(1) Current copies of its business 

continuity-disaster recovery plans and 

other emergency procedures; 

(2) All assessments of its operational 

risks or system safeguards-related 

controls; 

(3) All reports concerning system 

safeguards testing and assessment 

required by this chapter, whether 

performed by independent contractors 

or by employees of the swap data 

repository; and 

(4) All other books and records 

requested by Commission staff in 

connection with Commission oversight 

of system safeguards pursuant to the Act 

or Commission regulations, or in 

connection with Commission 

maintenance of a current profile of the 

swap data repository’s automated 

systems. 

(5) Nothing in paragraph (i) of this 

section shall be interpreted as reducing 

or limiting in any way a swap data 

repository’s obligation to comply with 

§§ 1.31 or 45.2 of this chapter, or § 49.12 

of the Commission’s regulations. 

(j) A registered swap data repository 

shall conduct regular, periodic, 

objective testing and review of its 

automated systems to ensure that they 

are reliable, secure, and have adequate 

scalable capacity. It shall also conduct 

regular, periodic testing and review of 

its business continuity-disaster recovery 

capabilities. Such testing and review 

shall include, without limitation, all of 

the types of testing set forth in 

paragraph (j) of this section. 

(1) Definitions. As used in paragraph 

(j) of this section: 

Controls means the safeguards or 

countermeasures employed by the swap 

data repository in order to protect the 

reliability, security, or capacity of its 

automated systems or the 

confidentiality, integrity, and 

availability of its data and information, 

and in order to enable the swap data 

repository to fulfill its statutory and 

regulatory duties and responsibilities. 

Controls testing means assessment of 

the swap data repository’s controls to 

determine whether such controls are 

implemented correctly, are operating as 

intended, and are enabling the swap 

data repository to meet the system 

safeguards requirements established by 

this chapter. 

Enterprise technology risk assessment 

means a written assessment that 

includes, but is not limited to, an 

analysis of threats and vulnerabilities in 

the context of mitigating controls. An 

enterprise technology risk assessment 

identifies, estimates, and prioritizes 

risks to swap data repository operations 

or assets, or to market participants, 

individuals, or other entities, resulting 

from impairment of the confidentiality, 

integrity, and availability of data and 

information or the reliability, security, 

or capacity of automated systems. 

External penetration testing means 

attempts to penetrate the swap data 

repository’s automated systems from 

outside the systems’ boundaries to 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80188 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

identify and exploit vulnerabilities. 

Methods of conducting external 

penetration testing include, but are not 

limited to, methods for circumventing 

the security features of an automated 

system. 

Internal penetration testing means 

attempts to penetrate the swap data 

repository’s automated systems from 

inside the systems’ boundaries, to 

identify and exploit vulnerabilities. 

Methods of conducting internal 

penetration testing include, but are not 

limited to, methods for circumventing 

the security features of an automated 

system. 

Key controls means those controls that 

an appropriate risk analysis determines 

are either critically important for 

effective system safeguards or intended 

to address risks that evolve or change 

more frequently and therefore require 

more frequent review to ensure their 

continuing effectiveness in addressing 

such risks. 

Security incident means a cyber 

security or physical security event that 

actually or potentially jeopardizes 

automated system operation, reliability, 

security, or capacity, or the availability, 

confidentiality or integrity of data. 

Security incident response plan 

means a written plan documenting the 

swap data repository’s policies, 

controls, procedures, and resources for 

identifying, responding to, mitigating, 

and recovering from security incidents, 

and the roles and responsibilities of its 

management, staff and independent 

contractors in responding to security 

incidents. A security incident response 

plan may be a separate document or a 

business continuity-disaster recovery 

plan section or appendix dedicated to 

security incident response. 

Security incident response plan 

testing means testing of a swap data 

repository’s security incident response 

plan to determine the plan’s 

effectiveness, identify its potential 

weaknesses or deficiencies, enable 

regular plan updating and improvement, 

and maintain organizational 

preparedness and resiliency with 

respect to security incidents. Methods of 

conducting security incident response 

plan testing may include, but are not 

limited to, checklist completion, walkthrough or table-top exercises, 

simulations, and comprehensive 

exercises. 

Vulnerability testing means testing of 

a swap data repository’s automated 

systems to determine what information 

may be discoverable through a 

reconnaissance analysis of those 

systems and what vulnerabilities may be 

present on those systems. 

(2) Vulnerability testing. A swap data 

repository shall conduct vulnerability 

testing of a scope sufficient to satisfy the 

requirements set forth in paragraph (l) of 

this section. 

(i) Such vulnerability testing shall 

include automated vulnerability 

scanning. Where indicated by 

appropriate risk analysis, such scanning 

must be conducted on an authenticated 

basis, e.g., using log-in credentials. 

Where scanning is conducted on an 

unauthenticated basis, the swap data 

repository must implement effective 

compensating controls. 

(ii) The swap data repository shall 

conduct such vulnerability testing at a 

frequency determined by an appropriate 

risk analysis, but no less frequently than 

quarterly. 

(iii) The swap data repository shall 

engage independent contractors to 

conduct two of the required quarterly 

vulnerability tests each year. The swap 

data repository may conduct other 

vulnerability testing by using employees 

of the swap data repository who are not 

responsible for development or 

operation of the systems or capabilities 

being tested. 

(3) Penetration testing—(i) External 

penetration testing. A swap data 

repository shall conduct external 

penetration testing of a scope sufficient 

to satisfy the requirements set forth in 

paragraph (l) of this section. 

(A) The swap data repository shall 

conduct such external penetration 

testing at a frequency determined by an 

appropriate risk analysis, but no less 

frequently than annually. 

(B) The swap data repository shall 

engage independent contractors to 

conduct the required annual external 

penetration test. The swap data 

repository may conduct other external 

penetration testing by using employees 

of the swap data repository who are not 

responsible for development or 

operation of the systems or capabilities 

being tested. 

(ii) Internal penetration testing. A 

swap data repository shall conduct 

internal penetration testing of a scope 

sufficient to satisfy the requirements set 

forth in paragraph (l) of this section. 

(A) The swap data repository shall 

conduct such internal penetration 

testing at a frequency determined by an 

appropriate risk analysis, but no less 

frequently than annually. 

(B) The swap data repository may 

conduct internal penetration testing by 

engaging independent contractors, or by 

using employees of the swap data 

repository who are not responsible for 

development or operation of the systems 

or capabilities being tested. 

(4) Controls testing. A swap data 

repository shall conduct controls testing 

of a scope sufficient to satisfy the 

requirements set forth in paragraph (l) of 

this section. Such controls testing shall 

include testing of each control included 

in the swap data repository’s program of 

system safeguards risk analysis and 

oversight. 

(i) The swap data repository shall 

conduct controls testing at a frequency 

determined by an appropriate risk 

analysis, but no less frequently than 

every two years. The swap data 

repository may conduct such testing on 

a rolling basis over the course of the 

minimum two-year period or over a 

minimum period determined by an 

appropriate risk analysis, whichever is 

shorter. 

(ii) The swap data repository shall 

engage independent contractors to test 

and assess the key controls, as 

determined by appropriate risk analysis, 

included in the entity’s program of risk 

analysis and oversight no less frequently 

than every two years. The swap data 

repository may conduct any other 

controls testing required by this 

paragraph (j)(4) of this section by using 

independent contractors or employees 

of the swap data repository who are not 

responsible for development or 

operation of the systems or capabilities 

being tested. 

(5) Security incident response plan 

testing. A swap data repository shall 

conduct security incident response plan 

testing sufficient to satisfy the 

requirements set forth in paragraph (l) of 

this section. 

(i) The swap data repository’s security 

incident response plan shall include, 

without limitation, the swap data 

repository’s definition and classification 

of security incidents, its policies and 

procedures for reporting security 

incidents and for internal and external 

communication and information sharing 

regarding security incidents, and the 

hand-off and escalation points in its 

security incident response process. 

(ii) The swap data repository may 

coordinate its security incident response 

plan testing with other testing required 

by this section or with testing of its 

other business continuity-disaster 

recovery and crisis management plans. 

(iii) The swap data repository shall 

conduct such security incident response 

plan testing at a frequency determined 

by an appropriate risk analysis, but at a 

minimum no less frequently than 

annually. 

(iv) The swap data repository may 

conduct security incident response plan 

testing by engaging independent 

contractors or by using employees of the 

swap data repository who are not 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80189 

1Testimony of Frank J. Cilluffo, Director, Center 

for Cyber and Homeland Security, Before the U.S. 

House of Representatives, Committee on Financial 

Services, Subcommittee on Oversight and 

Investigations, 1 (June 16, 2015)(noting that ‘‘the 

following figures which were provided to me 

recently by a major U.S. bank on a not-forattribution basis: Just last week, they faced 30,000 

cyber-attacks. This amounts to an attack every 34 

seconds, each and every day. And these are just the 

attacks that the bank actually knows about, by 

virtue of a known malicious signature or IP address. 

As for the source of the known attacks, 

approximately 22,000 came from criminal 

organizations; and 400 from nation-states.’’), 

available at https://cchs.gwu.edu/sites/

cchs.gwu.edu/files/downloads/A%20Global

%20Perspective%20on%20Cyber%20Threats%20- 

%2015%20June%202015.pdf. 

2 Id. 

responsible for development or 

operation of the systems or capabilities 

being tested. 

(6) Enterprise technology risk 

assessment. A swap data repository 

shall conduct enterprise technology risk 

assessment of a scope sufficient to 

satisfy the requirements set forth in 

paragraph (l) of this section. 

(i) The swap data repository shall 

conduct an enterprise technology risk 

assessment at a frequency determined 

by an appropriate risk analysis, but no 

less frequently than annually. 

(ii) The swap data repository may 

conduct enterprise technology risk 

assessments by using independent 

contractors or employees of the swap 

data repository who are not responsible 

for development or operation of the 

systems or capabilities being assessed. 

(k) To the extent practicable, a 

registered swap data repository shall: 

* * * * * 

(l) Scope of testing and assessment. 

The scope for all system safeguards 

testing and assessment required by this 

section must be broad enough to include 

all testing of automated systems and 

controls necessary to identify any 

vulnerability which, if triggered, could 

enable an intruder or unauthorized user 

or insider to: 

(1) Interfere with the swap data 

repository’s operations or with 

fulfillment of its statutory and 

regulatory responsibilities; 

(2) Impair or degrade the reliability, 

security, or adequate scalable capacity 

of the swap data repository’s automated 

systems; 

(3) Add to, delete, modify, exfiltrate, 

or compromise the integrity of any data 

related to the swap data repository’s 

regulated activities; or 

(4) Undertake any other unauthorized 

action affecting the swap data 

repository’s regulated activities or the 

hardware or software used in 

connection with those activities. 

(m) Internal reporting and review. 

Both the senior management and the 

Board of Directors of the swap data 

repository shall receive and review 

reports setting forth the results of all 

testing and assessment required by this 

section. The swap data repository shall 

establish and follow appropriate 

procedures for the remediation of issues 

identified through such review, as 

provided in paragraph (n) of this 

section, and for evaluation of the 

effectiveness of testing and assessment 

protocols. 

(n) Remediation. A swap data 

repository shall analyze the results of 

the testing and assessment required by 

this section to identify all 

vulnerabilities and deficiencies in its 

systems. The swap data repository must 

remediate those vulnerabilities and 

deficiencies to the extent necessary to 

enable the swap data repository to fulfill 

the system safeguards requirements of 

this part and meet its statutory and 

regulatory obligations. Such 

remediation must be timely in light of 

appropriate risk analysis with respect to 

the risks presented by such 

vulnerabilities and deficiencies. 

Issued in Washington, DC, on December 

17, 2015, by the Commission. 

Christopher J. Kirkpatrick, 

Secretary of the Commission. 

Note: The following appendices will not 

appear in the Code of Federal Regulations. 

Appendices to System Safeguards 

Testing Requirements—Commission 

Voting Summary, Chairman’s 

Statement, and Commissioners’ 

Statements Appendix 1—Commission 

Voting Summary 

On this matter, Chairman Massad and 

Commissioners Bowen and Giancarlo voted 

in the affirmative. No Commissioner voted in 

the negative. 

Appendix 2—Statement of Chairman 

Timothy G. Massad 

I strongly support this proposed rule, 

which would enhance and clarify 

requirements to protect exchanges, swap 

execution facilities and swap data 

repositories from numerous cybersecurity 

risks. 

This proposal, alongside a companion 

measure released by the Commission’s 

Division of Clearing and Risk, ensures that 

the private companies that run the core 

infrastructure under our jurisdiction are 

doing adequate evaluation of cybersecurity 

risks and testing of their own cybersecurity 

and operational risk protections. 

I believe this proposed rule will help 

address a number of concerns, such as 

information security, physical security, 

business continuity and disaster recovery. 

The proposal sets principles-based testing 

standards which are deeply rooted in 

industry best practices. 

The rule identifies five types of testing as 

critical to a sound system safeguards 

program: Vulnerability testing, penetration 

testing, controls testing, security incident 

response plan testing and enterprise-wide 

assessment of technology risk. Such efforts 

are vital to mitigate risk and preserve the 

ability to detect, contain, respond to, and 

recover from a cyberattack or other type of 

operational problem. 

The proposal applies the base standards to 

swap execution facilities. It also contains an 

anticipated notice of proposed rulemaking, 

which notes that the Commission is 

considering whether to apply minimum 

testing frequency and independent contractor 

testing requirements to the most systemically 

important swap execution facilities. I 

previously stated that I did not expect our 

proposal would apply to SEFs—not because 

cybersecurity isn’t just as important for 

them—but because many SEFs are still in the 

very early stages of operation. 

But my fellow commissioners have 

expressed concerns about potential 

vulnerabilities and felt that we should 

propose that the requirements apply to SEFs 

at this time. I appreciate their views and am 

committed to working collaboratively to 

address these issues. 

As always, we welcome public comment 

on this and its companion proposal, which 

will be carefully considered before taking any 

final action. 

Appendix 3—Concurring Statement of 

Commissioner Sharon Y. Bowen 

Today, we are considering two rule 

proposals that address an issue which is right 

at the heart of systemic risk in our markets— 

cybersecurity. The question that we face is: 

With a problem as immense as cybercrime, 

and the many measures already being 

employed to combat it, what would today’s 

proposed rules accomplish? In answer to that 

question, I want to say a few words about our 

cybercrime challenge, what is currently being 

done to address it, and what I hope these 

proposed regulations would add to these 

efforts. 

The problem is clear—our firms are facing 

an unrelenting onslaught of attacks from 

hackers with a number of motives ranging 

from petty fraud to international 

cyberwarfare. We have all heard of notable 

and sizable companies that have been the 

victim of cybercrime, including: Sony, eBay, 

JPMorgan, Target, and Staples—even the U.S. 

government has fallen victim. 

In recent testimony before the House 

Committee on Financial Services, 

Subcommittee on Oversight and 

Investigations about cybercrime, the Director 

of the Center for Cyber and Homeland 

Security noted that the ‘‘U.S. financial 

services sector in particular is in the 

crosshairs as a primary target.’’ 1 He cited one 

U.S. bank which stated that it faced 30,000 

cyber-attacks in one week—averaging an 

attack every 34 seconds.2

Given the magnitude of the problem, it is 

not at all surprising that a lot is already being 

done to address it. The Department of 

Homeland Security and others have been 

working with private firms to shore up 

defenses. Regulators have certainly been 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
80190 Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 

3Commissioner Sharon Y. Bowen, Commodity 

Futures Trading Commission, ‘‘Remarks of CFTC 

Commissioner Sharon Y. Bowen Before the 17th 

Annual OpRisk North America,’’ March 25, 2015, 

available at http://www.cftc.gov/PressRoom/

SpeechesTestimony/opabowen-2. 

4NIST Framework, Subcategory PR.IP–10, at 28, 

and Category DE.DP, at 31, available at http://

www.nist.gov/cyberframework/upload/

cybersecurity-framework-021214.pdf. 

1See Guest Lecture of Commissioner J. 

Christopher Giancarlo, Harvard Law School, 

Fidelity Guest Lecture Series on International 

Finance (Dec. 1, 2015), http://www.cftc.gov/

PressRoom/SpeechesTestimony/opagiancarlo-11; 

see also Keynote Address of CFTC Commissioner J. 

Christopher Giancarlo before the 2015 ISDA Annual 

Asia Pacific Conference, Top Down Financial 

Market Regulation: Disease Mislabeled as Cure (Oct. 

26, 2015), http://www.cftc.gov/PressRoom/

SpeechesTestimony/opagiancarlo-10. 

2See CFTC Commissioner J. Christopher 

Giancarlo, Pro-Reform Reconsideration of the CFTC 

Swaps Trading Rules: Return to Dodd-Frank, White 

Paper (Jan. 29, 2015), available at http://

www.cftc.gov/idc/groups/public/@newsroom/

documents/file/sefwhitepaper012915.pdf (noting 

that this mismatch—and the application of this 

framework worldwide—has caused numerous 

harms, foremost of which is driving global market 

participants away from transacting with entities 

subject to CFTC swaps regulation, resulting in 

fragmented global swaps markets); see also 

Statement of Commissioner J. Christopher 

Giancarlo, Six Month Progress Report on CFTC 

Swaps Trading Rules: Incomplete Action and 

Fragmented Markets (Aug. 4, 2015), http://

www.cftc.gov/PressRoom/SpeechesTestimony/

giancarlostatement080415. See also International 

Swaps and Derivatives Association, Cross-Border 

Fragmentation of Global Interest Rate Derivatives: 

The New Normal? First Half 2015 Update, ISDA 

Research Note (Oct. 28, 2015), http://

www2.isda.org/functional-areas/research/researchnotes/ (concluding that the market for euro interest 

rate swaps continues to remain fragmented in U.S. 

and non-U.S. liquidity pools ever since the 

introduction of the U.S. SEF regime in October 

2013). 

active. The Securities and Exchange 

Commission (‘‘SEC’’), the Federal Deposit 

Insurance Corporation (‘‘FDIC’’), the Federal 

Reserve Board (‘‘FRB’’), the Federal Housing 

Finance Agency (‘‘FHFA’’), and our selfregulatory organization, the National Futures 

Association (‘‘NFA’’), have issued 

cybersecurity guidance. In Europe, the Bank 

of England (‘‘BOE’’) introduced the CBEST 

program to conduct penetration testing on 

firms, based on the latest data on cybercrime. 

We heard a presentation from the BOE about 

CBEST at a meeting of the Market Risk 

Advisory Committee this year. 

I wanted to hear what market participants 

were doing to address the challenge of our 

cybersecurity landscape so I met with several 

of our large registrant dealers and asked them 

about their cybersecurity efforts. After these 

discussions, I was both alarmed by the 

immensity of the problem and heartened by 

efforts of these larger participants to meet 

that problem head on. They were employing 

best practices such as reviewing the practices 

of their third party providers, using third 

parties to audit systems, sharing information 

with other market participants, integrating 

cybersecurity risk management into their 

governance structure, and staying in 

communication with their regulators. 

We have also been vigilant in our efforts 

to address cybersecurity. Under our current 

rule structure, many of our registrants have 

system safeguards requirements. They 

require, among other things, that the 

registrants have policies and resources for 

risk analysis and oversight with respect to 

their operations and automated systems, as 

well as reporting, recordkeeping, testing, and 

coordination with service providers. These 

requirements clearly include appropriate 

cybersecurity measures. We also regularly 

examine registrants for their adherence to the 

system safeguards requirements, including 

effective governance, use of resources, 

appropriate policies, and vigilant response to 

attacks. 

So if all of this is happening, what would 

more regulation accomplish? In other words, 

what is the ‘‘value add’’ of the rules being 

proposed today? The answer is: A great deal. 

While some firms are clearly engaging in best 

practices, we have no guarantee that all of 

them are. And as I have said before, in a 

system as electronically interconnected as 

our financial markets, ‘‘we’re collectively 

only as strong as our weakest link, and so we 

need a high baseline level of protection for 

everyone . . .’’ 3 We need to incentivize all 

firms under our purview to engage in these 

effective practices. 

We have to do this carefully though 

because once a regulator inserts itself into the 

cybersecurity landscape at a firm—the firm 

now has two concerns: Not just fighting the 

attackers, but managing its reputation with 

its regulator. So, if not done carefully, a 

regulator’s attempt to bolster cybersecurity at 

a firm can instead undermine it by 

incentivizing the firm to cover up any 

weaknesses in its cybersecurity 

infrastructure, instead of addressing them. 

Further, we must be careful not to mandate 

a one-size-fits-all standard because firms are 

different. Thus, we must be thoughtful about 

how to engage on this issue. We need to 

encourage best practices, while not 

hampering firms’ ability to customize their 

risk management plan to address their 

cybersecurity threats. 

I think these rulemakings are a great first 

step in accomplishing that balance. There are 

many aspects of these proposals that I like. 

First, they set up a comprehensive testing 

regime by: (a) Defining the types of 

cybersecurity testing essential to fulfilling 

system safeguards testing obligations, 

including vulnerability testing, penetration 

testing, controls testing, security incident 

response plan testing, and enterprise 

technology risk assessment; (b) requiring 

internal reporting and review of testing 

results; and (c) mandating remediation of 

vulnerabilities and deficiencies. Further, for 

certain significant entities, based on trading 

volume, it requires heightened measures 

such as minimum frequency requirements for 

conducting certain testing, and specific 

requirements for the use of independent 

contractors. 

Second, there is a focus on governance— 

requiring, for instance, that firms’ Board of 

Directors receive and review all reports 

setting forth the results of all testing. And 

third, these rulemakings are largely based on 

well-regarded, accepted best practices for 

cybersecurity, including The National 

Institute of Standards and Technology 

Framework for Improving Critical 

Infrastructure Cybersecurity (‘‘NIST 

Framework’’).4

In all, I think the staff has put together two 

thoughtful proposals. Clearly, however, this 

is only a first step since all our registrants, 

not just exchanges, SEFs, SDRs and DCOs, 

need to have clear cybersecurity measures in 

place. I am also very eager to hear what the 

general public has to say about these 

proposals. Do they go far enough to 

incentivize appropriate cybersecurity 

measures? Are they too burdensome for firms 

that do not pose significant risk to the 

system? And given that this is a dynamic 

field with a constantly evolving set of threats, 

what next steps should we take to address 

cybercrime? Please send in all your thoughts 

for our consideration. 

Appendix 4—Statement of 

Commissioner J. Christopher Giancarlo 

In one of our very first conversations over 

a year and a half ago, Chairman Massad and 

I discussed the many risks that cyber threats 

pose to trading markets. We agreed that cyber 

and overall system security is one of the most 

important issues facing markets today in 

terms of trading integrity and financial 

stability. 

Earlier this year, I called for a ‘‘bottom-up’’ 

approach to combating cyber threats.1 This 

approach involves a close and dynamic 

relationship between regulators and the 

marketplace. It also requires the continuous 

development of best practices, defensive 

strategies and response tactics through the 

leadership of market participants, operators 

and self-regulatory organizations. The job of 

the Commodity Futures Trading Commission 

(‘‘CFTC’’) as a regulator is to encourage, 

support, inform and empower this 

continuous development so that market 

participants adopt fully optimized and up-todate cyber defenses. 

It is appropriate that we are now taking up 

the subject of system safeguards. I commend 

Chairman Massad and CFTC staff for putting 

forth today’s proposal. I believe it generally 

reflects the ‘‘bottom-up’’ approach I have 

advocated for market participants to follow 

industry adopted standards and best 

practices. I support its publication for notice 

and comment. 

I believe it is right that the proposal covers 

not just designated contract markets 

(‘‘DCMs’’), but also swap execution facilities 

(‘‘SEFs’’). From my experience, SEFs are as 

concerned with cyber security as are DCMs. 

Nevertheless, it is true that the proposed 

rules will impose additional costs on some 

SEFs at a time when they are struggling to 

implement the myriad new Dodd-Frank 

requirements and obligations. Because 

system and cyber security should be a 

priority on our registrants’ precious time and 

resources, the CFTC must find ways to 

alleviate unnecessary regulatory costs. 

As I have said many times before, the best 

way to reduce unnecessary costs for SEFs is 

to correct the CFTC’s flawed swaps trading 

rules that remain fundamentally mismatched 

to the distinct liquidity and trading dynamics 

of global swaps markets.2 Attempting to 


tkelley on DSK3SPTVN1PROD with PROPOSALS4
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules 80191 

3The proposal requires market operators to 

follow industry adopted standards and best 

practices. Given the many organizations and U.S. 

government agencies (such as the U.S. Treasury 

Department’s Financial Crimes Enforcement 

Network, the Office of Domestic Finance’s Financial 

Sector Cyber Intelligence Group and the Office of 

Terrorist Financing and Financial Crimes) issuing 

cyber security procedures and advisories, there may 

be some question as to which procedures and 

advisories fall within industry best practices for 

purposes of complying with this rule proposal. To 

provide clarity, the CFTC should offer guidance to 

market participants regarding their obligations 

under the rule and designate safe harbors for 

compliance, as needed. 

4See supra note 1. 

accommodate this misbegotten regulatory 

framework restricts the SEF industry’s ability 

to deploy adequate resources for cyber 

defense. I also believe that the CFTC should 

provide a sufficient implementation period 

for any final rules so that market operators, 

especially smaller DCMs and SEFs, have 

adequate time to meet the new requirements. 

Given the constantly morphing nature of 

cyber risk, the best defenses provide no 

guarantee of protection. Therefore, it would 

be a perverse and unfortunate result if any 

final system safeguards rule were to have a 

chilling effect on robust cyber security 

efforts. Market participants who abide by the 

rule should not be afraid of a ‘‘double 

whammy’’ of a destructive cyber-attack 

followed shortly thereafter by a CFTC 

enforcement action. Being hacked, by itself, 

cannot be considered a rule violation subject 

to enforcement. The CFTC should offer clear 

guidance to market participants regarding 

their obligations under the rule and designate 

safe harbors for compliance with it.3 The 

CFTC should also indicate how it will 

measure market operators’ compliance 

against industry standards given that the 

exact requirements of best practices can be 

open to interpretation. 

In October, I called on the CFTC to add 

value to ongoing industry cyber security 

initiatives by designating a qualified cyber 

security information coordinator.4 This 

individual would work with our registered 

entities to help them navigate the maze of 

Federal national security agencies and access 

the most up-to-date cyber security 

information available. I ask market 

participants to comment on the value and 

utility of such a designation. 

As market regulators, we can have no naı ̈ve 

illusions that cyber belligerents—foreign and 

domestic—view the world’s financial 

markets as anything other than 21st century 

battlefields. Cyber-attacks on trading markets 

will not diminish anytime soon. They will be 

relentless for years, if not decades, to come. 

Cyber risk is a threat for which Dodd-Frank 

provides no guidance whatsoever. Together, 

market regulators and the regulated 

community must make cyber and system 

security our first priority in time and 

attention. Today’s proposal is a constructive 

step towards that goal. I look forward to 

reviewing thoughtful comments from market 

participants and the public. 

[FR Doc. 2015–32143 Filed 12–22–15; 8:45 am] 

BILLING CODE 6351–01–P 


tkelley on DSK3SPTVN1PROD with PROPOSALS4