System Safeguards Testing Requirements, 80139-80191 [2015-32143]

Agencies

• Commodity Futures Trading Commission

[Federal Register Volume 80, Number 246 (Wednesday, December 23, 2015)]
[Proposed Rules]
[Pages 80139-80191]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2015-32143]



[[Page 80139]]

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

Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / 
Proposed Rules

[[Page 80140]]


-----------------------------------------------------------------------

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: https://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: https://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 https://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 Continuity-Disaster 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\
---------------------------------------------------------------------------

    \1\ See generally CFTC Staff Roundtable on Cybersecurity and 
System Safeguards Testing (March 18, 2015) (``CFTC Roundtable''), at 
11-91, transcript available at https://www.cftc.gov/ucm/groups/public/@newsroom/documents/file/transcript031815.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 
https://www.cftc.gov/ucm/groups/public/@aboutcftc/documents/file/mrac_060215_transcript.pdf.
---------------------------------------------------------------------------

    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

[[Page 80141]]

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\
---------------------------------------------------------------------------

    \2\ Committee on Payments and Market Infrastructures of the Bank 
for International Settlements, Cyber resilience in financial market 
infrastructures (November 2014), at 1, available at https://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 https://www.iosco.org/research/pdf/swp/Cyber-Crime-Securities-Markets-and-Systemic-Risk.pdf.
    \4\ DTCC, Systemic Risk Barometer Study (Q1 2015), at 1, 
available at https://dtcc.com/~/media/Files/pdfs/Systemic-Risk-
Report-2015-Q1.pdf.
    \5\ PricewaterhouseCoopers, 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.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \7\ CFTC Roundtable, at 41-42.
    \8\ See CFTC Roundtable, at 12, 14-15, 17-24, 42-44, 47.
    \9\ IOSCO-WFE Staff Report, at 3-4, available at https://www.iosco.org/research/pdf/swp/Cyber-Crime-Securities-Markets-and-Systemic-Risk.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \10\ CFTC Roundtable, at 20-21.
    \11\ Id. at 21-22.
---------------------------------------------------------------------------

    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:
---------------------------------------------------------------------------

    \12\ Id. at 74-76, 81-82.
    \13\ Id.

    The rise of a relatively new class of cyber-attack 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\
---------------------------------------------------------------------------

    \14\ IOSCO-WFE Staff Report, at 3, available at https://www.iosco.org/research/pdf/swp/Cyber-Crime-Securities-Markets-and-Systemic-Risk.pdf.

    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 internet-facing 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-internet-facing 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\
---------------------------------------------------------------------------

    \15\ CFTC 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.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \21\ Id. at 24-25.
    \22\ Id. at 47-55.
---------------------------------------------------------------------------

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

[[Page 80142]]

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\
---------------------------------------------------------------------------

    \23\ Id. at 24.
    \24\ Id. at 44.
    \25\ Id. at 46.
    \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 https://bigstory.ap.org/article/93077d547f074bed8ce9eb292a3bbd47/cybertheft-personnel-info-rips-hole-espionage-defenses.
    \27\ CFTC Roundtable, at 15-16, 65, 71-73, 80-83.
    \28\ Id. at 87-88.
---------------------------------------------------------------------------

    Cybersecurity testing is a well-established 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\
---------------------------------------------------------------------------

    \29\ FISMA section 3544(b)(5), available at https://csrc.nist.gov/drivers/documents/FISMA-final.pdf.
    \30\ NIST Framework, Subcategory PR.IP-10, at 28, and Category 
DE.DP, at 31, available at https://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf.
    \31\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 1-2, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
    \32\ Id. at 8.
    \33\ Council on CyberSecurity, The Critical Security Controls 
for Effective Cyber Defense Version 5.1, Critical Security Control 
(``CSC'') 4, at 27, available at https://www.counciloncybersecurity.org/critical-controls/.
    \34\ Id.
    \35\ Id., CSC 20, at 102.
    \36\ Id., CSC 20-1, at 102.
    \37\ Id., CSC 20-6, at 103.
---------------------------------------------------------------------------

    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:
---------------------------------------------------------------------------

    \38\ The 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.

    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\
---------------------------------------------------------------------------

    \39\ FFIEC, E-Banking IT Examination Handbook, at 30, available 
at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_E-Banking.pdf.

    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\
---------------------------------------------------------------------------

    \40\ PriceWaterhouseCoopers, Insurance 2020 and Beyond: Reaping 
the Dividends of Cyber Resilience, 2015, available at https://www.pwc.com/gx/en/insurance/publications/assets/reaping-dividends-cyber-resilience.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \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 https://www.iosco.org/library/pubdocs/pdf/IOSCOPD483.pdf.
    \42\ Id. at 9.
    \43\ European 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 https://www.esma.europa.eu/system/files/esma_2012_122_en.pdf.
    \44\ CPMI-IOSCO, Principles for Financial Market 
Infrastructures, (Apr. 2012), at 96, available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD377.pdf. See also CPMI, 
Cyber resilience in financial market infrastructures, (Nov. 2014), 
available at https://www.bis.org/cpmi/publ/d122.pdf.

---------------------------------------------------------------------------

[[Page 80143]]

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\
---------------------------------------------------------------------------

    \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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \48\ See 17 CFR 38.1051(a); 17 CFR 37.1401(a); and 17 CFR 
49.24(b).
    \49\ See 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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \50\ 17 CFR 38.1050(a) (for DCMs); 17 CFR 37.1400(a) (for SEFs); 
17 CFR 49.24(a)(1) (for SDRs).
---------------------------------------------------------------------------

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:
---------------------------------------------------------------------------

    \51\ See 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 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \52\ NIST SP 800-39, Managing Information Security Risk: 
Organization, Mission, and Information System View (March 2011) 
(``NIST SP 800-39''), available at https://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf.

    Leaders must recognize that explicit, well-informed 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\
---------------------------------------------------------------------------

    \53\ Id. at 1.

    NIST standards further provide that an organization's risk 
management strategy regarding system safeguards

[[Page 80144]]

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\
---------------------------------------------------------------------------

    \54\ NIST SP 800-53 Rev. 4, control PM-9 Risk Management 
Strategy, available at https://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.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \57\ NIST 800-53 Rev. 4, SA-2, Allocation of Resources, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \58\ Id. at PM-3, Information Security Resources.
    \59\ COBIT 5, APO06, available at https://cobitonline.isaca.org/
.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \60\ See, 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 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \61\ FFIEC, Audit IT Examination Handbook, Objective 3, at A-2, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
    \62\ Id.
    \63\ COBIT 5, APO01, available at https://cobitonline.isaca.org/
.
    \64\ CFTC 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).
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \65\ FFIEC, Audit IT Examination Handbook, at 1, available at 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.

    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:
---------------------------------------------------------------------------

    \66\ Id.

    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 wide-area 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\
---------------------------------------------------------------------------

    \67\ Id.

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\
---------------------------------------------------------------------------

    \68\ NIST 800-53 Rev. 4, control PM-4, Plan of Action and 
Milestones Process, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \69\ COBIT 5, APO12, available at https://cobitonline.isaca.org/
.
    \70\ FFIEC, Audit IT Examination Handbook, Objective 6, at A-4, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
    \71\ Id.
---------------------------------------------------------------------------

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:

[[Page 80145]]

     Access to systems and data (e.g., least privilege, 
separation of duties, account monitoring and control).\72\
---------------------------------------------------------------------------

    \72\ NIST SP 800-53 Rev. 4, Access Controls (``AC'') control 
family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on CyberSecurity, 
CSC 7, 12, 15, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     User and device identification and authentication.\73\
---------------------------------------------------------------------------

    \73\ NIST SP 800-53 Rev. 4, Identification and Authentication 
(``IA'') control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on 
CyberSecurity, CSC 1, 2, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Security awareness training.\74\
---------------------------------------------------------------------------

    \74\ NIST SP 800-53 Rev. 4, Awareness and Training (``AT'') 
control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on CyberSecurity, 
CSC 9, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Audit log maintenance, monitoring, and analysis.\75\
---------------------------------------------------------------------------

    \75\ NIST SP 800-53 Rev. 4, Audit and Accountability (``AU'') 
control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on CyberSecurity, 
CSC 14, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Media protection.\76\
---------------------------------------------------------------------------

    \76\ NIST SP 800-53 Rev. 4, Media Protection (``MP'') control 
family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

     Personnel security and screening.\77\
---------------------------------------------------------------------------

    \77\ NIST SP 800-53 Rev. 4, Personnel Security (``PS'') control 
family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

     Automated system and communications protection (e.g., 
malware defenses, software integrity monitoring).\78\
---------------------------------------------------------------------------

    \78\ NIST SP 800-53 Rev. 4, System and Communication Protection 
(``SC'') control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on 
CyberSecurity, CSC 7, 10, 11, 13, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Automated system and information integrity (e.g., network 
port control, boundary defenses, encryption).\79\
---------------------------------------------------------------------------

    \79\ NIST SP 800-53 Rev. 4, System and Information Integrity 
(``SI'') control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on 
CyberSecurity, CSC 3, 5, 17, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Vulnerability management.\80\
---------------------------------------------------------------------------

    \80\ NIST SP 800-53 Rev. 4, control RA-5, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; 
Council on CyberSecurity, CSC 4, 5, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Penetration testing.\81\
---------------------------------------------------------------------------

    \81\ NIST SP 800-53 Rev. 4, control CA-8, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; 
Council on CyberSecurity, CSC 20, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Security incident response and management.\82\
---------------------------------------------------------------------------

    \82\ NIST SP 800-53 Rev. 4, Incident Response (``IR'') control 
family, available at https://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 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \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 https://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \89\ CFTC Roundtable, at 277-363.
---------------------------------------------------------------------------

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

[[Page 80146]]

effective system safeguards in today's cybersecurity threat 
environment.
---------------------------------------------------------------------------

    \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 https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Operations.pdf.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \91\ NIST SP 800-53 Rev. 4, Maintenance (``MA'') control family, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

     Configuration management (e.g., baseline configuration, 
configuration change and patch management, least functionality, 
inventory of authorized and unauthorized devices and software).\92\
---------------------------------------------------------------------------

    \92\ NIST SP 800-53 Rev. 4, Configuration Management (``CM'') 
control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; Council on CyberSecurity, 
CSC 1, 2, 3, 10, 11, 12, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

     Event and problem response and management.\93\
---------------------------------------------------------------------------

    \93\ FFIEC, Operations IT Examination Handbook, at 28, and 
Objective 10, at A-8 to A-9, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Operations.pdf; 
ISACA, COBIT 5, Deliver, Service and Support (``DSS'') process 
DSS03, available at https://cobitonline.isaca.org/.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \94\ NIST SP 800-53 Rev. 4, control SA-4, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; 
FFIEC Development and Acquisition IT Examination Handbook, at 2-3, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_DevelopmentandAcquisition.pdf.
---------------------------------------------------------------------------

     Pre-production and regression testing.\95\
---------------------------------------------------------------------------

    \95\ NIST SP 800-53 Rev. 4, controls SA-8, SA-10, SA-11, 
available at https://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 https://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 https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_DevelopmentandAcquisition.pdf.
---------------------------------------------------------------------------

     Change management procedures and approvals.\96\
---------------------------------------------------------------------------

    \96\ Id. at 47-48.
---------------------------------------------------------------------------

     Outsourcing and vendor management.\97\
---------------------------------------------------------------------------

    \97\ NIST SP 800-53 Rev. 4, controls SA-9, SA-12, available at 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; FFIEC, Outsourcing Technology Services IT Examination 
Handbook, at 2, available at https://ithandbook.ffiec.gov/ITBooklets/ 
FFIEC_ITBooklet_OutsourcingTechnologyServices.pdf.
---------------------------------------------------------------------------

     Training in secure coding practices.\98\
---------------------------------------------------------------------------

    \98\ NIST SP 800-53 Rev. 4, controls AT-3, SA-11, available at 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \99\ NIST SP 800-53 Rev. 4, Physical and Environmental 
Protection (PE) control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; 
FFIEC, Operations IT Examination Handbook, at 15-18, available at 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Operations.pdf.
---------------------------------------------------------------------------

     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\
---------------------------------------------------------------------------

    \100\ See Sec.  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); Sec.  
49.24(c) (for SDRs).
    \101\ See Sec.  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); Sec.  49.24(j) (for SDRs).
    \102\ See Sec.  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); Sec.  49.24(k) (for SDRs).
---------------------------------------------------------------------------

    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

[[Page 80147]]

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.
---------------------------------------------------------------------------

    \103\ Regarding following best practices, see proposed rule 
Sec.  38.1051(b) (for DCMs); Sec.  37.1401(b) (for SEFs); and Sec.  
49.24(c) (for SDRs). Regarding tester independence, see proposed 
rules Sec. Sec.  38.1051(h)(2)(iv), (3)(i)(C), (3)(ii)(B), (4)(iii), 
(5)(iv), and (6)(ii) (for DCMs); Sec. Sec.  37.1401(h)(2)(i), 
(3)(i)(A), (4)(i), (5)(iii), and (6)(i) (for SEFs); and Sec. Sec.  
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 Sec.  38.1051(i) (for DCMs); Sec.  37.1401(i) (for 
SEFs); and Sec.  49.24(k) (for SDRs).
---------------------------------------------------------------------------

D. Updating of Business Continuity-Disaster 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\
---------------------------------------------------------------------------

    \104\ NIST SP 800-61 Rev. 2, at 8, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.
    \105\ NIST SP 800-34 Rev. 1, at 8, available at https://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \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).
---------------------------------------------------------------------------

    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 Sec.  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.
---------------------------------------------------------------------------

    \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).
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \108\ CEA 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.
---------------------------------------------------------------------------

    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

[[Page 80148]]

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.
---------------------------------------------------------------------------

    \110\ 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for 
SEFs); 17 CFR 49.24(j) (for SDRs).
    \111\ The 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 
https://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding vulnerability testing, see, e.g., NIST SP 
800-53A Rev. 1, at F67, June 2010, available at https://csrc.nist.gov/publications/nistpubs/800-53A-rev1/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 https://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: https://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008, available at: 
https://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 https://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 https://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 https://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------

    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 high-level 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\
---------------------------------------------------------------------------

    \112\ See discussion above concerning the need for cybersecurity 
testing.
    \113\ Id.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \114\ These 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.
---------------------------------------------------------------------------

    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

[[Page 80149]]

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 sometimes-uncertain side effects.\115\
---------------------------------------------------------------------------

    \115\ Council on Cybersecurity, CSC 4, Continuous Vulnerability 
Assessment and Remediation: Why Is This Control Critical? (emphasis 
added), available at https://www.counciloncybersecurity.org/critical-controls/.

    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\
---------------------------------------------------------------------------

    \116\ CFTC Roundtable, at 95-96.
    \117\ Id.
    \118\ Id.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \119\ NIST SP 800-53 Rev. 4, control RA-5 Vulnerability 
Scanning, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \120\ Id.
    \121\ Id.
    \122\ Id.
---------------------------------------------------------------------------

    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 code-based 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\
---------------------------------------------------------------------------

    \123\ Council on Cybersecurity, CSC 4, Continuous Vulnerability 
Assessment and Remediation, available at https://www.counciloncybersecurity.org/critical-controls/.
    \124\ Id. at CSC 4-1.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \125\ Security 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.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \127\ See NIST SP 800-53 Rev. 4, control RA-5, available at 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \128\ See, e.g., NIST SP 800-115, Technical Guide to Information 
Security Testing and Assessment (2008) (``NIST 800-115''), at 2-4, 
available at https://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.''
    \129\ See, 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/penetration-testing-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.''
---------------------------------------------------------------------------

    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

[[Page 80150]]

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\
---------------------------------------------------------------------------

    \130\ See, 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 https://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.''
    \131\ NIST SP 800-39, at 47-48, available at https://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf.
    \132\ CFTC Roundtable, at 170-171.
    \133\ The 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 
https://training.pcisecuritystandards.org/the-pci-monitor-weekly-news-updates-and-insights-from-pci-ssc2?ecid=ACsprvuuirRbrU3vDlk76s_ngGKJKEYlvaBJzvvUMldZv4KKh6V1guIKOR5VLTNfAqPQ_Gmox3zO&utm_campaign=Monitor&utm_source=hs_email&utm_medium=email&utm_content=13292865&_hsenc=p2ANqtz_LIkkHURyUmyq1p2OxB39R5nOpRh1XHE_jW6wCC6EEUAow15E7AuExcIGwdYxyh_6YNxVvKorcurk6r90E3d7dG71fbw&_hsmi=13292865%20-%20web.
    \134\ See 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.''
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \135\ FFIEC, Information Security IT Examination Handbook, at 
82, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \136\ See NIST SP 800-39, at 47-48, available at https://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf; 
FFIEC, Information Security IT Examination Handbook, at 82, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \137\ Id.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \138\ PCI DSS, Requirement 11.2, available at https://www.pcisecuritystandards.org/security_standards/index.php.
    \139\ Council on CyberSecurity, CSC 4, Continuous Vulnerability 
Assessment and Remediation, available at https://www.counciloncybersecurity.org/critical-controls/.
    \140\ The 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.
---------------------------------------------------------------------------

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

[[Page 80151]]

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.
---------------------------------------------------------------------------

    \141\ CFTC Roundtable, at 88.
    \142\ Id. at 88-89.
    \143\ Id. at 103-104.
    \144\ Id. at 177.
    \145\ Id. at 171.
    \146\ Id.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \147\ NIST SP 800-115, at 6-6, available at https://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.

    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\
---------------------------------------------------------------------------

    \148\ FFIEC, Information Security IT Examination Handbook, at 
81, available at https://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.
    \153\ PCI DSS, Requirement 11, Regularly test security systems 
and processes, at 94-96, available at https://www.pcisecuritystandards.org/security_standards/index.php.
---------------------------------------------------------------------------

    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:
---------------------------------------------------------------------------

    \154\ See FFIEC, Information Security IT Examination Handbook, 
at 81, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \155\ NIST SP 800-53 Rev. 4, App. B at B-17, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

    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\

    \156\ Id. at F-62, CA-8 Penetration Testing.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \157\ Council on Cybersecurity, CSC 20, Penetration Tests and 
Red Team Exercises: Why Is This Control Critical? available at 
https://www.counciloncybersecurity.org/critical-controls/.

    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

[[Page 80152]]

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\
---------------------------------------------------------------------------

    \158\ Id. at 96.
    \159\ Id. at 58-60.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \160\ Council on CyberSecurity, CSC 20-1, available at https://www.counciloncybersecurity.org/critical-controls/.

    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\
---------------------------------------------------------------------------

    \161\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 22, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.

    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\
---------------------------------------------------------------------------

    \162\ Id.

    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:
---------------------------------------------------------------------------

    \163\ NIST SP 800-53 Rev. 4, control CA-8 Penetration Testing, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

    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\
---------------------------------------------------------------------------

    \164\ NIST SP 800-115, at 2-4 to 2-5, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.

    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\
---------------------------------------------------------------------------

    \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-industry-33314 (``Penetration testing is essential given 
the context of high operational risk in the financial services 
industry.'')
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \166\ See discussion above concerning vulnerability testing.
---------------------------------------------------------------------------

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

[[Page 80153]]

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\
---------------------------------------------------------------------------

    \167\ The 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.
    \168\ The Commission understands that most covered DCMs (as 
defined) and most SDRs currently conduct external and internal 
penetration testing at least annually.
    \169\ NIST, SP 800-115, Technical Guide to Information Security 
Testing and Assessment, Section 5.2.2, at 5-5, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
    \170\ FFIEC, Information Security IT Examination Handbook, at 
82, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \171\ PCI DSS, Requirements 11.3.1 and 11.3.2. available at 
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf.
---------------------------------------------------------------------------

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:
---------------------------------------------------------------------------

    \172\ See discussion above concerning vulnerability testing.

    [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\
---------------------------------------------------------------------------

    \173\ NIST SP 800-115, at 6-6, available at https://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.

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\
---------------------------------------------------------------------------

    \174\ PCI DSS, Requirement 11, Regularly test security systems 
and processes, at 94-96, available at https://www.pcisecuritystandards.org/security_standards/index.php.
    \175\ CFTC Roundtable, at 88-89, 103-104, 171.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \176\ The 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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \177\ 17 CFR 38.1050(a) (for DCMs); 17 CFR 37.1400(a) (for 
SEFs); 17 CFR 49.24(a)(1) (for SDRs).
    \178\ NIST SP 800-53 Rev. 4, at F-3, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; 
See also CFTC Roundtable, at 194-196.
---------------------------------------------------------------------------

    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:
---------------------------------------------------------------------------

    \179\ NIST 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 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
    \180\ Id. at xi (Foreword).

    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 risk-based decisions as 
part of security authorization processes; and (iv) ensure compliance 
to vulnerability mitigation procedures.\181\
---------------------------------------------------------------------------

    \181\ NIST SP 800-53 Rev. 4, control CA-2 Security Assessments, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

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.

[[Page 80154]]

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\
---------------------------------------------------------------------------

    \182\ Id.

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 non-compliance 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 self-assessments 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\
---------------------------------------------------------------------------

    \183\ NIST SP 800-53A Rev. 4, at 3, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
    \184\ FFIEC, Information Security IT Examination Handbook, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \188\ See discussion above concerning the need for controls 
testing.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \189\ See discussion above concerning vulnerability testing.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \190\ The 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.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \191\ NIST SP 800-53A Rev. 4, at 17-18, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
    \192\ NIST SP-800-137, Information Security Continuous 
Monitoring (ISCM) for Federal Information Systems and Organizations, 
at 6, available at https://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf.
---------------------------------------------------------------------------

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

[[Page 80155]]

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\
---------------------------------------------------------------------------

    \193\ The 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.
    \194\ ISACA, COBIT 5, MEA02, Monitor, Evaluate and Assess the 
System of Internal Control, available at https://cobitonline.isaca.org/.
    \195\ NIST SP 800-53 Rev. 4, control CA-2 Security Assessments, 
Control Enhancements 1, Security Assessments: Independent Assessors, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \196\ The 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.
---------------------------------------------------------------------------

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:
---------------------------------------------------------------------------

    \197\ NIST 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 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/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 https://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 https://ithandbook.ffiec.gov/ 
ITBooklets/FFIEC_ITBooklet_BusinessContinuityPlanning.pdf.

    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\
---------------------------------------------------------------------------

    \198\ Council on CyberSecurity, The Critical Security Controls 
for Effective Cyber Defense Version 5.1, CSC 18, at 96, available at 
https://www.counciloncybersecurity.org/critical-controls/.

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\
---------------------------------------------------------------------------

    \199\ CFTC Roundtable, at 82-84.
    \200\ Id. at 79-80.
    \201\ Id. at 284-287.
    \202\ Id. at 283-284, 290-294.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \203\ NIST SP 800-34 Rev. 1, Contingency Planning Guide for 
Federal Information Systems (``NIST SP 800-34 Rev. 1''), Sec.  2.2.5 
Cyber Incident Response Plan, at 11, available at https://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

NIST notes that such plans may be included as an appendix to the 
organization's business continuity plan.\204\
---------------------------------------------------------------------------

    \204\ Id.
---------------------------------------------------------------------------

    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:
---------------------------------------------------------------------------

    \205\ NIST SP 800-53 Rev. 4, control IR-3 Incident Response 
Testing, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.


[[Page 80156]]


---------------------------------------------------------------------------

    [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\
---------------------------------------------------------------------------

    \206\ NIST SP 800-84, Guide to Test, Training, and Exercise 
Programs for IT Plans and Capabilities (``NIST SP 800-84''), at ES-
1, available at https://csrc.nist.gov/publications/nistpubs/800-84/SP800-84.pdf.

---------------------------------------------------------------------------
    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\
---------------------------------------------------------------------------

    \207\ Id. at ES-2.

---------------------------------------------------------------------------
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\
---------------------------------------------------------------------------

    \208\ NIST SP 800-53 Rev. 4, control CP-2 Contingency Plan, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-3r4.pdf.

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\
---------------------------------------------------------------------------

    \209\ NIST SP 800-53 Rev. 4, control CP-4 Contingency Plan 
Testing, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \210\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 23, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.

    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\
---------------------------------------------------------------------------

    \211\ FFIEC, Business Continuity Planning IT Examination 
Handbook, at 25, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_BusinessContinuityPlanning.pdf.
    \212\ Id. at 25-26.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \213\ Council on CyberSecurity, The Critical Security Controls 
for Effective Cyber Defense Version 5.1, CSC 18, at 96, available at 
https://www.counciloncybersecurity.org/critical-controls/.
    \214\ Id. at 97.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \215\ NIST SP 800-53 Rev. 4, control IR-3 Incident Response 
Testing, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

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.
---------------------------------------------------------------------------

    \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).
---------------------------------------------------------------------------

    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

[[Page 80157]]

organization should develop and maintain an incident response plan 
that:
---------------------------------------------------------------------------

    \217\ NIST SP 800-53 Rev. 4, control IR-1 Incident Response 
Policy and Procedures, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

    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\
---------------------------------------------------------------------------

    \218\ NIST SP 800-53 Rev. 4, control IR-8 Incident Response 
Plan, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.

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:

    \219\ Id.

     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\
---------------------------------------------------------------------------

    \220\ NIST SP 800-61 Rev. 2, section 2.3.1 Policy Elements, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \221\ See discussion above concerning vulnerability 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 systems-related contingency plans and incident response 
capabilities at least annually.\223\
---------------------------------------------------------------------------

    \222\ The Commission understands that many covered DCMs (as 
defined) and many SDRs currently conduct SIRP testing at least 
annually.
    \223\ NIST 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).
---------------------------------------------------------------------------

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 safeguards-related risks.\224\ According to NIST, 
such risk assessment is necessary for well-informed, risk-based 
leadership

[[Page 80158]]

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\
---------------------------------------------------------------------------

    \224\ NIST SP 800-39, at 1, available at https://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf.
    \225\ Id.
---------------------------------------------------------------------------

    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 safeguards-related 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\
---------------------------------------------------------------------------

    \226\ NIST SP 800-115, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \227\ See, e.g., ISACA, COBIT 5; International Organisation for 
Standardisation and International Electrotechnical Commission 
(``ISO/IEC'') 27001; FFIEC.
    \228\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 14, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \229\ See discussion of vulnerability testing frequency.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \230\ FFIEC, Information Security IT Examination Handbook, at 7-
8, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.

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\
---------------------------------------------------------------------------

    \231\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 12, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
    \232\ Id. at 13.
    \233\ ISACA, COBIT 5, APO12, Manage Risk, available at https://cobitonline.isaca.org.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \234\ The Commission understands that most covered DCMs and most 
SDRs currently perform cybersecurity and system safeguards risk 
assessments on at least an annual basis.
    \235\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 14, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
    \236\ FFIEC, Information Security IT Examination Handbook, at 7-
8, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \237\ Id. at 86.
---------------------------------------------------------------------------

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

[[Page 80159]]

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\
---------------------------------------------------------------------------

    \238\ See NIST SP 800-115, at 6-6, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf; and 
FFIEC, Information Security IT Examination Handbook, at 81, 
available at https://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/.
    \240\ The 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.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \241\ CEA 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).
    \244\ See 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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \245\ See e.g., NIST SP 800-115, Technical Guide to Information 
Security Testing and Assessment, at 6-10--6-12, September 2008, 
available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf; NIST SP 800-53A Rev. 4, at 10, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf; 
FFIEC, Information Security IT Examination Handbook, at 5, available 
at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf; NIST SP 800-53 Rev. 4, 
Program Management (``PM'') control family, available at https://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 A-4, available at 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf; 
ISACA, COBIT 5, APO12, available at https://cobitonline.isaca.org/.
    \246\ The 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 https://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 https://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 https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
---------------------------------------------------------------------------

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

[[Page 80160]]

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.
---------------------------------------------------------------------------

    \247\ CFTC Roundtable, at 97, 100-101, 107-111, 127-130, 139-
141, 172-180.
    \248\ Id.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \249\ FINRA, Report on Cybersecurity Practices, February 2015, 
at 7, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.

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 enterprise-wide 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\
---------------------------------------------------------------------------

    \250\ Id.
    \251\ Id. at 8.
    \252\ FFIEC, Information Security IT Examination Handbook, at 5, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \253\ Id. See also, e.g., NIST SP 800-53 Rev. 4, Program 
Management (``PM'') control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \254\ FFIEC, Audit IT Examination Handbook, Objective 6, at A-4, 
available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
    \255\ ISACA, COBIT 5, APO12, available at https://cobitonline.isaca.org/.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \256\ See, e.g., NIST SP 800-53A Rev. 4, at 3, available at 
https://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 https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
---------------------------------------------------------------------------

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

[[Page 80161]]

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\
---------------------------------------------------------------------------

    \257\ The 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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \258\ See discussion above concerning the need for cybersecurity 
testing.
---------------------------------------------------------------------------

    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

[[Page 80162]]

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.
---------------------------------------------------------------------------

    \259\ 5 U.S.C. 601 et seq.
    \260\ See 47 FR 18618-21 (Apr. 30, 1982).
    \261\ See 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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

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

    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 Sec.  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 Sec.  
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.
---------------------------------------------------------------------------

    \263\ See OMB Control No. 3038-0052, available at https://www.reginfo.gov/public/do/ PRAOMBHistory?ombControlNumber=3038-0052.
    \264\ See OMB Control No. 3038-0074, available at https://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0074.
    \265\ See OMB Control No. 3038-0086, available at https://www.reginfo.gov/public/do/ PRAOMBHistory?ombControlNumber=3038-0086.
---------------------------------------------------------------------------

    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 continuity-disaster 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 Sec. Sec.  38.1051(g), 37.1041(g), and 49.24(i) to 
clarify the system safeguard-related books and records obligations for 
all DCMs, SEFs, and SDRs. The proposed regulations would require these 
entities, in accordance with Commission regulation Sec.  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 Sec.  38.1051(g) are contained in the 
provisions of current Commission regulations Sec. Sec.  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 Sec.  
37.1401(g) are contained in the provisions of current Commission 
regulations Sec. Sec.  37.1041(f) \271\ and (g),\272\

[[Page 80163]]

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 Sec.  49.24(i) are contained in the provisions of current 
Commission regulations Sec. Sec.  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 
Sec.  49.24 requirements is 15,000 burden hours per respondent.\279\ 
The Commission believes that proposed Sec. Sec.  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.
---------------------------------------------------------------------------

    \266\ Commission regulation Sec.  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).
    \267\ Commission regulation Sec.  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).
    \268\ Commission regulation Sec.  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 Sec. Sec.  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).
    \271\ Commission regulation Sec.  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).
    \272\ Commission regulation Sec.  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 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 Sec. Sec.  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).
    \275\ Commission regulation Sec.  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).
    \276\ Commission regulation Sec.  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 continuity-disaster recovery capabilities. The rule 
further provides that pursuant to Sec. Sec.  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).
---------------------------------------------------------------------------

3. Proposed Revision to Collection 3038-0052
    Proposed Sec.  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 Sec.  38.1051(n) would be 
minimal. Presently, there are 15 registered DCMs that would be required 
to comply with proposed Sec.  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\
---------------------------------------------------------------------------

    \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.
---------------------------------------------------------------------------

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 https://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.
---------------------------------------------------------------------------

    \281\ 7 U.S.C. 19(a).
---------------------------------------------------------------------------

    As an initial matter, the Commission considers the incremental 
costs and benefits of these regulations, that is the

[[Page 80164]]

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\
---------------------------------------------------------------------------

    \282\ For 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.
---------------------------------------------------------------------------

    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 world-wide 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.
---------------------------------------------------------------------------

    \283\ Committee 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 https://www.iosco.org/research/pdf/swp/Cyber-Crime-Securities-Markets-and-Systemic-Risk.pdf.
    \285\ Ponemon 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.
    \287\ CFTC Roundtable, at 24.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \288\ CEA 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).
---------------------------------------------------------------------------

    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

[[Page 80165]]

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.
---------------------------------------------------------------------------

    \291\ The 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 
https://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding vulnerability testing, see, e.g., NIST SP 
800-53A Rev. 1, at F67, June 2010, available at https://csrc.nist.gov/publications/nistpubs/800-53A-rev1/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 https://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: https://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008, available at: 
https://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 https://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 https://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 https://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \292\ The 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.
    \293\ By 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.
    \294\ Commission staff conduct system safeguard examinations 
(``SSEs'') to evaluate DCMs' compliance with Core Principle 20 
(System Safeguards) and Commission regulations Sec. Sec.  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 Sec.  49.24. See 17 CFR 49.24.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \295\ The Commission believes that the proposed requirement in 
Sec. Sec.  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 Sec.  
38.1051(n) for the reporting of annual trading volume to the 
Commission.
    \296\ Based 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.
---------------------------------------------------------------------------

    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.

[[Page 80166]]

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.
---------------------------------------------------------------------------

    \297\ 17 CFR 38.1050(a) (for DCMs); 17 CFR 37.1400(a) (for 
SEFs); and 17 CFR 49.24(a)(1) (for 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 Sec.  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); Sec.  37.1401(i); and Sec.  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.
---------------------------------------------------------------------------

    \298\ See Sec.  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); Sec.  
49.24(c) (for SDRs).
    \299\ See Sec.  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); Sec.  49.24(j) (for SDRs).
    \300\ See Sec.  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); Sec.  49.24(k) (for SDRs).
---------------------------------------------------------------------------

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 Continuity-Disaster 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.
---------------------------------------------------------------------------

    \301\ Commission regulations Sec. Sec.  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).
    \302\ The 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.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \303\ NIST SP 800-53 Rev. 4, Physical and Environmental 
Protection (PE) control family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf; 
FFIEC, Operations IT Examination Handbook, at 15-18, available at 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Operations.pdf.
---------------------------------------------------------------------------

d. Request for Comments
    The Commission requests comment on the potential costs and benefits 
associated with complying with proposed regulations Sec. Sec.  
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 Sec. Sec.  38.1051(g), 
37.1401(g), and 49.24(i) would require a DCM, SEF, or SDR, in 
accordance with Commission regulation Sec.  1.31,\304\ to provide the 
Commission with the following system safeguards-related books and 
records promptly upon request of any

[[Page 80167]]

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.
---------------------------------------------------------------------------

    \304\ Commission regulation Sec.  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
    As discussed more fully above in the PRA section, all DCMs, SEFs, 
and SDRs are already subject to system safeguard-related 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 Sec. Sec.  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 Sec.  
38.1051(g) are contained in the provisions of current Commission 
regulations Sec. Sec.  38.1051(g) and (h). The pertinent recordkeeping 
and reporting requirements of proposed Sec.  37.1041(g) are contained 
in the provisions of current Sec. Sec.  37.1041(f) and (g). In 
addition, the pertinent recordkeeping and reporting requirements of 
proposed Sec.  49.24(i) are contained in the provisions of current 
Commission regulations Sec. Sec.  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 Sec. Sec.  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, Sec.  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 Sec. Sec.  
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 Sec. Sec.  
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\
---------------------------------------------------------------------------

    \305\ CEA 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.
---------------------------------------------------------------------------

    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

[[Page 80168]]

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.
---------------------------------------------------------------------------

    \307\ Commission regulations Sec. Sec.  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).
    \308\ See supra note 291.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \309\ While 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.
    \310\ See Commission regulations Sec. Sec.  38.1051(h) (for 
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
    \311\ Based 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.
    \312\ PCI DSS standards, 11.2, at 94, available at https://www.pcisecuritystandards.org/security_standards/index.php.
---------------------------------------------------------------------------

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 Sec. Sec.  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\
---------------------------------------------------------------------------

    \313\ Id.
    \314\ Based 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.
    \315\ See CFTC Roundtable, at 88-89; NIST SP 800-115, at 6-6, 
available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf; FFIEC, Information Security IT Examination Handbook, 
at 81, available at https://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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \317\ See 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.
---------------------------------------------------------------------------

    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

[[Page 80169]]

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.
---------------------------------------------------------------------------

    \318\ PCI DSS, Requirement 11.2 Regularly test security systems 
and processes, at 94, available at https://www.pcisecuritystandards.org/security_standards/index.php.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \319\ CFTC Roundtable, at 88.
    \320\ Id. at 88-89.
    \321\ Id. at 177.
    \322\ Id. at 171.
    \323\ See NIST SP 800-115, at 6-6, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf; FFIEC, 
Information Security IT Examination Handbook, at 81, available at 
https://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/.
---------------------------------------------------------------------------

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 Sec. Sec.  
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 Sec. Sec.  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\
---------------------------------------------------------------------------

    \324\ CEA 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.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \326\ Commission regulations Sec. Sec.  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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \327\ See supra note 291.

---------------------------------------------------------------------------

[[Page 80170]]

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\
---------------------------------------------------------------------------

    \328\ See Commission regulations Sec. Sec.  38.1051(h) (for 
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
    \329\ Based 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.
    \330\ NIST, SP 800-115, Technical Guide to Information Security 
Testing and Assessment, Section 5.2.2, at 5-5, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

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 Sec. Sec.  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\
---------------------------------------------------------------------------

    \331\ Id.
    \332\ Based 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.
    \333\ Council on CyberSecurity, CSC 20-1, available at https://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------

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 Sec. Sec.  
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 Sec. Sec.  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\
---------------------------------------------------------------------------

    \334\ CEA 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.
---------------------------------------------------------------------------

    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

[[Page 80171]]

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.
---------------------------------------------------------------------------

    \336\ Commission regulations Sec. Sec.  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).
    \337\ See supra note 291.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \338\ See Commission regulations Sec. Sec.  38.1051(h) (for 
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
    \339\ Based 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.
    \340\ PCI DSS standards, at 96-97, available at https://www.pcisecuritystandards.org/security_standards/index.php.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \341\ FFIEC, Information Security IT Examination Handbook, at 
81, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \342\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 22, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
    \343\ NIST, SP 800-115, Technical Guide to Information Security 
Testing and Assessment, Section 5.2.2, at 5-5, available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
    \344\ FFIEC, Information Security IT Examination Handbook, at 
82, available at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \345\ PCI DSS, Requirements 11.3.1 and 11.3.2., available at 
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf.
---------------------------------------------------------------------------

    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

[[Page 80172]]

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 Sec. Sec.  
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 Sec. Sec.  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 Sec. Sec.  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\
---------------------------------------------------------------------------

    \346\ CEA 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.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \348\ Commission regulations Sec. Sec.  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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \349\ See supra note 291.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \350\ See Commission regulations Sec. Sec.  38.1051(h) (for 
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
    \351\ Based 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.
    \352\ NIST SP 800-53A Rev. 4, at 17-18, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
---------------------------------------------------------------------------

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 Sec. Sec.  
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\
---------------------------------------------------------------------------

    \353\ Id.
    \354\ Based 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.
    \355\ NIST SP 800-53 Rev. 4, control CA-2 Security Assessments, 
Control Enhancements 1, Security Assessments: Independent Assessors, 
available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
---------------------------------------------------------------------------

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

[[Page 80173]]

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.
---------------------------------------------------------------------------

    \356\ One 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.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \357\ NIST SP 800-53A, Assessing Security and Privacy Controls 
in Federal Information Systems and Organizations, rev. 4 (``NIST SP 
800-53A''), p. 3, available at: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
    \358\ CFTC Roundtable, at 43-44.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \359\ NIST SP 800-53A Rev. 4, at 17-18, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \360\ NIST SP 800-53 Rev. 4, supra note 195.
---------------------------------------------------------------------------

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 Sec. Sec.  
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

[[Page 80174]]

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\
---------------------------------------------------------------------------

    \361\ CEA 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.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \363\ Commission regulations Sec. Sec.  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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \364\ See supra note 291.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \365\ See Commission regulations Sec. Sec.  38.1051(h) (for 
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
    \366\ Based 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.
    \367\ NIST 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).
---------------------------------------------------------------------------

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 Sec. Sec.  
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 Sec. Sec.  
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

[[Page 80175]]

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\
---------------------------------------------------------------------------

    \368\ CEA 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.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \370\ Commission regulations Sec. Sec.  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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \371\ See supra note 291.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \372\ See Commission regulations Sec. Sec.  38.1051(h) (for 
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
    \373\ Based on the information from the DMO Preliminary Survey, 
the Commission understands that most covered DCMs and SDRs currently 
conduct ETRAs at the proposed frequency.
    \374\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 14, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
---------------------------------------------------------------------------

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.
---------------------------------------------------------------------------

    \375\ FINRA, Report on Cybersecurity Practices (February 2015), 
at 14, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
---------------------------------------------------------------------------

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 Sec. Sec.  
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

[[Page 80176]]

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 Sec. Sec.  
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.
---------------------------------------------------------------------------

    \376\ FINRA, 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 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.; and NIST SP 800-53, Rev. 
4, Program Management Control Family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \377\ See e.g., NIST SP 800-115, Technical Guide to Information 
Security Testing and Assessment, at 6-10-6-12, September 2008, 
available at https://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf; NIST SP 800-53A Rev. 4, at 10, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf; 
FFIEC, Information Security IT Examination Handbook, at 5, available 
at https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf; NIST SP 800-53 Rev. 4, 
Program Management control family, available at https://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 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf; 
ISACA, COBIT 5, APO12, available at https://cobitonline.isaca.org/.
    \378\ See supra note 246.
---------------------------------------------------------------------------

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 
Sec. Sec.  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 Sec. Sec.  
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

[[Page 80177]]

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.
---------------------------------------------------------------------------

    \379\ FINRA, 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 
https://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.; and NIST SP 800-53, Rev. 
4, Program Management Control Family, available at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
    \380\ See supra note 377.
    \381\ See supra note 246.
---------------------------------------------------------------------------

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 
safeguard-related 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 Sec.  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 Sec.  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\
---------------------------------------------------------------------------

    \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.
---------------------------------------------------------------------------

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 market-wide 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

[[Page 80178]]

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.
---------------------------------------------------------------------------

    \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.
---------------------------------------------------------------------------

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\
---------------------------------------------------------------------------

    \384\ CFTC Roundtable, at 28.
---------------------------------------------------------------------------

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 https://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

[[Page 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 Sec. Sec.  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,

[[Page 80180]]

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:

[[Page 80181]]

PART 37--SWAP EXECUTION FACILITIES

0
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.

0
2. Amend Sec.  37.1401 as follows:
0
a. Revise paragraphs (a) and (b);
0
b. Remove paragraph (f);
0
c. Redesignate paragraphs (c) through (e) as paragraphs (d) through 
(f);
0
d. Add new paragraph (c);
0
e. Revise paragraph (g);
0
f. Redesignate paragraph (h) as paragraph (j); and
0
g. Add new paragraphs (h), (i), (k), (l), and (m).
    The revisions and additions read as follows:


Sec.  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 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 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 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 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 
continuity-disaster 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 Sec.  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 Sec.  1.31 of this chapter, Core 
Principle 10 (Recordkeeping and Reporting), and Sec. Sec.  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

[[Page 80182]]

Reporting) or with Sec.  1.31 of this chapter, or Sec. Sec.  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, 
walk-through 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

[[Page 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 continuity-disaster 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 continuity-disaster 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]

0
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

0
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.

0
5. Amend Sec.  38.1051 as follows:
0
a. Revise paragraphs (a), (b), (c), (g), (h), and (i) introductory 
text; and
0
b. Add new paragraphs (k), (l), (m), and (n).
    The revisions and additions read as follows:


Sec.  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

[[Page 80184]]

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.
    (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 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 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 Sec.  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 Sec.  1.31 
of this chapter, Core Principle 18 (Recordkeeping), and Sec. Sec.  
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 
Sec.  1.31 of this chapter, or Sec. Sec.  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

[[Page 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, 
walk-through 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 two-year 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

[[Page 80186]]

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

0
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.

0
7. Amend Sec.  49.24 as follows:
0
a. Revise paragraphs (b), (c), (d), (i), (j), and (k) introductory 
text; and
0
b. Add new paragraphs (l), (m), and (n).
    The revisions and additions read as follows:


Sec.  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

[[Page 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 
continuity-disaster 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 Sec.  49.19, and maintenance of a comprehensive audit trail. 
The swap data repository's business continuity-disaster 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 Sec. Sec.  1.31 and 45.2 of this 
chapter, and Sec.  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 Sec. Sec.  1.31 or 45.2 of this chapter, or Sec.  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

[[Page 80188]]

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, 
walk-through 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

[[Page 80189]]

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\
---------------------------------------------------------------------------

    \1\ Testimony 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-for-attribution 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.
---------------------------------------------------------------------------

    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

[[Page 80190]]

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 self-regulatory 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.
---------------------------------------------------------------------------

    \3\ Commissioner 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 
https://www.cftc.gov/PressRoom/SpeechesTestimony/opabowen-2.
---------------------------------------------------------------------------

    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\
---------------------------------------------------------------------------

    \4\ NIST Framework, Subcategory PR.IP-10, at 28, and Category 
DE.DP, at 31, available at https://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf.
---------------------------------------------------------------------------

    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-to-date cyber defenses.
---------------------------------------------------------------------------

    \1\ See Guest Lecture of Commissioner J. Christopher Giancarlo, 
Harvard Law School, Fidelity Guest Lecture Series on International 
Finance (Dec. 1, 2015), https://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), https://www.cftc.gov/PressRoom/SpeechesTestimony/opagiancarlo-10.
---------------------------------------------------------------------------

    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

[[Page 80191]]

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.
---------------------------------------------------------------------------

    \2\ See 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 https://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), https://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), https://www2.isda.org/functional-areas/research/research-notes/ (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).
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \3\ The 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.
---------------------------------------------------------------------------

    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.
---------------------------------------------------------------------------

    \4\ See supra note 1.
---------------------------------------------------------------------------

    As market regulators, we can have no na[iuml]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