[Federal Register Volume 81, Number 181 (Monday, September 19, 2016)]
[Rules and Regulations]
[Pages 64272-64319]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-22174]



[[Page 64271]]

Vol. 81

Monday,

No. 181

September 19, 2016

Part II





Commodity Futures Trading Commission





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





17 CFR Parts 37, 38, and 49





System Safeguards Testing Requirements; Final Rule

  Federal Register / Vol. 81 , No. 181 / Monday, September 19, 2016 / 
Rules and Regulations  

[[Page 64272]]


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

COMMODITY FUTURES TRADING COMMISSION

17 CFR Parts 37, 38, and 49

RIN 3038-AE30


System Safeguards Testing Requirements

AGENCY: Commodity Futures Trading Commission.

ACTION: Final rule.

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

SUMMARY: The Commodity Futures Trading Commission (``Commission'' or 
``CFTC'') is adopting final rules amending its current system 
safeguards rules for designated contract markets, swap execution 
facilities, and swap data repositories, by enhancing and clarifying 
current provisions relating to system safeguards risk analysis and 
oversight and cybersecurity testing, and adding new provisions 
concerning certain aspects of cybersecurity testing. The final rules 
clarify the Commission's current 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. 
These testing types are vulnerability testing, penetration testing, 
controls testing, security incident response plan testing, and 
enterprise technology risk assessment. The final rules also clarify 
current 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. In addition, the final 
rules adopt new provisions set forth in the Commission's Notice of 
Proposed Rulemaking, applicable to covered designated contract markets 
(as defined) and all swap data repositories, establishing minimum 
frequency requirements for conducting certain types of cybersecurity 
testing, and requiring performance of certain tests by independent 
contractors.

DATES: 
    Effective date: This rule is effective September 19, 2016.
    Compliance dates: (1) Designated contract markets, swap execution 
facilities, and swap data repositories must be in full compliance with 
the vulnerability testing requirements of this rule within 180 calendar 
days after the effective date. (2) Designated contract markets, swap 
execution facilities, and swap data repositories must be in full 
compliance with the penetration testing requirements of this rule 
within one year after the effective date. Such compliance must include 
having conducted and completed penetration testing that complies with 
this rule within one year after the effective date. In the case of 
covered designated contract markets and swap data repositories, such 
compliance must include penetration testing conducted and completed by 
an independent contractor as required by this rule. (3) Designated 
contract markets, swap execution facilities, and swap data repositories 
must be in full compliance with the controls testing requirements of 
this rule within one year after the effective date. Covered designated 
contract markets and swap data repositories must have testing of key 
controls by an independent contractor as required by this rule 
completed within three years after the effective date. (4) Designated 
contract markets, swap execution facilities, and swap data repositories 
must be in full compliance with the security incident response plan 
testing requirements of this rule within 180 calendar days after the 
effective date. Such compliance must include having created and 
completed testing of a security incident response plan within 180 days 
after the effective date. (5) Designated contract markets, swap 
execution facilities, and swap data repositories must be in full 
compliance with the enterprise technology risk assessment requirements 
of this rule within one year after the effective date. Such compliance 
must include having completed an enterprise technology risk assessment 
that complies with this rule within one year after the effective date. 
(6) Designated contract markets, swap execution facilities, and swap 
data repositories must be in full compliance with the requirements of 
this rule for updating their business continuity-disaster recovery 
plans and emergency procedures within one year after the effective 
date. Such compliance must include having completed an update of such 
plans and procedures within one year after the effective date. (7) 
Designated contract markets must be in full compliance with the 
requirements of this rule respecting required production of annual 
total trading volume within 30 calendar days of the effective date. (8) 
Designated contract markets, swap execution facilities, and swap data 
repositories must be in full compliance with the system safeguards-
related books and records requirements of this rule, which are part of 
such entities' current books and records requirements under current 
Commission regulations and statutory core principles, as of the 
effective date. (9) Designated contract markets, swap execution 
facilities, and swap data repositories must be in full compliance with 
all other provisions of these final rules within one year after the 
effective date.

FOR FURTHER INFORMATION CONTACT: Rachel Berdansky, Deputy Director, 
Division of Market Oversight, 202-418-5429, [email protected]; David 
Taylor, Associate Director, Division of Market Oversight, 202-418-5488, 
[email protected], or David Steinberg, Associate Director, Division of 
Market Oversight, 202-418-5102, [email protected]; Commodity Futures 
Trading Commission, Three Lafayette Centre, 1155 21st Street NW., 
Washington, DC 20851.

SUPPLEMENTARY INFORMATION:

I. Background

A. The Need for Cybersecurity Testing

    On December 15, 2015, the Commission issued a Notice of Proposed 
Rulemaking (``NPRM'') proposing to amend its system safeguards rules 
for designated contract markets (``DCMs''), swap execution facilities 
(``SEFs''), and swap data repositories (``SDRs'').\1\
---------------------------------------------------------------------------

    \1\ System Safeguards Testing Requirements, Proposed Rule, 80 FR 
80139, 80140 (Dec. 23, 2015).
---------------------------------------------------------------------------

    As detailed in the NPRM, cyber threats to the financial sector 
continue to expand, increasing the need for enhanced cybersecurity 
testing. Such testing should focus on the entity's ability to detect, 
contain, respond to, and recover from cyber attacks. It should also 
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. As noted in the NPRM, cybersecurity testing is a well-
established best practice both generally and for financial sector 
entities.\2\
---------------------------------------------------------------------------

    \2\ Id. at 80142.
---------------------------------------------------------------------------

    Cybersecurity testing is also supported internationally. The 
recently published Guidance on cyber resilience for financial market 
infrastructures issued by the Committee on Payments and Market 
Infrastructures and the Board of the International Organization of 
Securities Commissions (``CPMI-IOSCO Guidance'') provides that:

    Testing is an integral component of any cyber resilience 
framework. All elements of a cyber resilience framework should be

[[Page 64273]]

rigorously tested to determine their overall effectiveness before 
being deployed within an FMI, and regularly thereafter. This 
includes the extent to which the framework is implemented correctly, 
operating as intended and producing desired outcomes. Understanding 
the overall effectiveness of the cyber resilience framework in the 
FMI and its environment is essential in determining the residual 
cyber risk to the FMI's operations, assets, and ecosystem.\3\
---------------------------------------------------------------------------

    \3\ Committee on Payments and Market Infrastructures (CPMI) and 
Board of the International Organization of Securities Commissions 
(IOSCO), Guidance on cyber resilience for financial market 
infrastructures (June 2016) section 7.1, at 18, available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD535.pdf.

The CPMI-IOSCO Guidance also states that a financial market 
infrastructure ``should establish a comprehensive testing program to 
validate the effectiveness of its cyber resilience framework on a 
regular and frequent basis,'' employing appropriate cyber threat 
intelligence to inform its testing methods, and using the results to 
support ongoing improvement of its cyber resilience.\4\
---------------------------------------------------------------------------

    \4\ Id., section 7.2 at 18.
---------------------------------------------------------------------------

B. Summary of the Proposed System Safeguards Testing Requirements Rule

1. Fundamental Goals
    The NPRM identified two principal goals. The first goal was 
clarification of current cybersecurity testing requirements for all 
DCMs, SEFs, and SDRs, along with clarification, amplification, and 
harmonization of other current system safeguards rule provisions. The 
second goal was the addition of new rule provisions for covered DCMs 
(as defined) and SDRs, establishing minimum frequency requirements for 
conducting certain types of cybersecurity testing, and requiring 
performance of certain tests by independent contractors.
2. 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 these entities to maintain a program of risk 
analysis and oversight to identify and minimize sources of operational 
risk.\5\ Commission regulations concerning system safeguards provide 
that the program of risk analysis and oversight required of each such 
entity must address specified categories of risk analysis and oversight 
to identify and minimize sources of operational risk.\6\ The NPRM 
proposed clarification of what is already required of all DCMs, SEFs, 
and SDRs regarding the six current categories which their programs of 
risk analysis and oversight must address, by further defining those 
categories.\7\ It also added and defined another category, enterprise 
risk management and governance, in order to clarify a requirement 
already implicit in the statutory mandate to maintain a program of 
system safeguards risk analysis and oversight. As set out in the NPRM, 
all seven categories and their definitions are grounded in generally 
accepted best practices.\8\
---------------------------------------------------------------------------

    \5\ 7 U.S.C. 5h(f)(14), 7(d)(20), and 24a(c)(8); 17 CFR 37.1400, 
38.1050, and 49.24(a)(1).
    \6\ 17 CFR 38.1051(a) and (b) (for DCMs); 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 (for SEFs); 17 CFR 49.24(b) and (c) (for SDRs).
    \7\ The six current categories include 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.
    \8\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------

3. 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 system 
safeguards risk analysis and oversight are required to include.\9\ 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).\10\ They further provide that such entities should coordinate 
their business continuity-disaster recovery (``BC-DR'') plans with the 
BC-DR plans of market participants and essential service providers.\11\ 
The NPRM proposed making these provisions mandatory for all DCMs, SEFs, 
and SDRs, thus aligning the rules for these entities with the 
Commission's rules for derivatives clearing organizations 
(``DCOs'').\12\
---------------------------------------------------------------------------

    \9\ 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).
    \10\ 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).
    \11\ 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).
    \12\ 80 FR 80139, 80146 (Dec. 23, 2015).
---------------------------------------------------------------------------

4. Updating of Business Continuity-Disaster Recovery Plans and 
Emergency Procedures
    The NPRM proposed amending the current system safeguards rules 
requiring all 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.\13\
---------------------------------------------------------------------------

    \13\ Id. at 80147.
---------------------------------------------------------------------------

5. 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.\14\ 
As noted in the NPRM, production of all such books and records is 
already required by the Act and Commission regulations, notably by 
Commission regulation Sec.  1.31.\15\ The NPRM proposed amending these 
document production provisions to further clarify requirements for 
document production by all DCMs, SEFs, and SDRs relating to system 
safeguards.\16\
---------------------------------------------------------------------------

    \14\ 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).
    \15\ 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).
    \16\ 80 FR 80139, 80147 (Dec. 23, 2015). The NPRM specified that 
the obligation to produce books and records includes production of: 
Current copies of BC-DR plans and emergency procedures; assessments 
of operational risks or system safeguards-related controls; reports 
concerning system safeguards testing and assessment, whether 
performed by independent contractors or employees; and all other 
books and records requested by Commission staff in connection with 
Commission oversight of system safeguards.
---------------------------------------------------------------------------

6. Cybersecurity Testing Requirements for DCMs, SEFs and SDRs
a. Clarification of Current Testing Requirements for All DCMs, SEFs, 
and SDRs
    The Commission's current system safeguards rules for DCMs, SEFs, 
and SDRs mandate that each such entity must conduct testing and review 
sufficient to ensure that its automated systems are reliable, secure, 
and have adequate scalable capacity.\17\ The NPRM proposed clarifying 
this system safeguards and cybersecurity testing requirement, by 
specifying and defining five types of system safeguards testing and 
assessment that a DCM, SEF, or SDR necessarily must perform to fulfill

[[Page 64274]]

the requirement.\18\ These testing and assessment types included 
vulnerability testing, both external and internal penetration testing, 
controls testing, security incident response plan testing, and 
enterprise technology risk assessment. As set out in the NPRM, each of 
these types of testing is a generally recognized best practice for 
system safeguards.\19\ Providing this clarification of the testing 
provisions of the current system safeguards rules is a primary purpose 
of this final rule. The NPRM proposed high-level, minimum requirements 
for these types of testing, recognizing 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. The NPRM 
provisions regarding each of the testing types are set out in 
additional detail in the discussion below concerning comments received.
---------------------------------------------------------------------------

    \17\ 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for SEFs); 
17 CFR 49.24(j) (for SDRs).
    \18\ 80 FR 80139, 80147 (Dec. 23, 2015).
    \19\ The Commission's current rules and guidance provide that a 
DCM's, SEF's, or SDR's entire program of risk analysis and 
oversight, which includes testing, should be based on generally 
accepted standards and best practices with respect to the 
development, operation, reliability, security, and capacity of 
automated systems. See 17 CFR 38.1051(h) (for DCMs); Appendix A to 
Part 37, Core Principle 14 of Section 5h of the Act--System 
Safeguards (a) Guidance (1) Risk analysis and oversight program (for 
SEFs); 17 CFR 49.24(j) (for SDRs). Each of the types of testing 
addressed in this NPRM--vulnerability testing, penetration testing, 
controls testing, security incident response plan testing, and 
enterprise technology risk assessment--has been a generally 
recognized best practice for system safeguards since before the 
testing requirements of the Act and the current regulations were 
adopted. The current system safeguards provisions of the CEA and the 
Commission's regulations became effective in August 2012. Generally 
accepted best practices called for each type of testing specified in 
the proposed rule well before that date, as shown in the following 
examples. Regarding all five types of testing, see, e.g., NIST SP 
800-53A, Rev. 1, Guide for Assessing the Security Controls in 
Federal Information Systems and Organizations (``NIST 800-53A Rev. 
1''), at E1, F67, F230, F148, and F226, June 2010, available at: 
http://csrc.nist.gov/publications/nistpubs/800-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: http://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: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. Regarding penetration testing, see, e.g., NIST Special 
Publication (``SP'') 800-53A, Rev. 1, at E1, June 2010, available 
at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008, 
available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. Regarding controls testing, see, e.g., NIST 800-53A, 
Rev. 1, at 13 and Appendix F1, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding security incident response plan testing, see, 
e.g., NIST 800-53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding enterprise technology risk assessment, see, 
e.g., NIST 800-53A, Rev.1, at F226, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------

b. New Minimum Testing Frequency and Independent Contractor Testing 
Requirements for Covered DCMs and All SDRs
    The NPRM proposed that covered DCMs (as defined) and all SDRs would 
be subject to new minimum testing frequency requirements with respect 
to some of the proposed types of system safeguards testing.\20\ To 
strengthen the objectivity and reliability of the testing, assessment, 
and information available to the Commission regarding covered DCM and 
SDR system safeguards, the NPRM also proposed that for certain types of 
testing, covered DCMs and SDRs would be subject to new independent 
contractor testing requirements.\21\ Establishing such minimum 
frequency and independent contractor requirements regarding 
cybersecurity testing by covered DCMs and SDRs is a primary purpose of 
this final rule. As noted in the NPRM, the proposed minimum frequency 
requirements and the requirement for some testing to be conducted by 
independent contractors are grounded in generally accepted standards 
and best practices.\22\ The NPRM provisions regarding the minimum 
frequency and independent contractor requirements are set out in 
additional detail below in the discussion of comments received.
---------------------------------------------------------------------------

    \20\ 80 FR 80139, 80148 (Dec. 23, 2015).
    \21\ Id.
    \22\ Id.
---------------------------------------------------------------------------

7. Additional Testing-Related Risk Analysis and Oversight Program 
Requirements Applicable to All DCMs, SEFs, and SDRs
    The NPRM also clarified the current testing requirements for DCMs, 
SEFs, and SDRs by specifying and defining three other aspects of risk 
analysis and oversight programs that are necessary to fulfillment of 
the testing requirements and achievement of their purposes.\23\ 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. As set out in the 
NPRM, all three of these risk analysis and oversight program aspects 
are grounded in generally recognized best practices for system 
safeguards.\24\
---------------------------------------------------------------------------

    \23\ 80 FR 80139, 80159 (Dec. 23, 2015).
    \24\ Id.
---------------------------------------------------------------------------

a. Scope of Testing and Assessment
    The NPRM proposed that the scope of all testing and assessment 
required by the Commission's 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.\25\ The NPRM noted 
that testing scope should be based on proper risk analysis.\26\
---------------------------------------------------------------------------

    \25\ Id.
    \26\ Id. at 80160.
---------------------------------------------------------------------------

b. Internal Reporting and Review
    The NPRM called for 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.\27\ It also called 
for 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.\28\ As noted in the NPRM, these requirements are 
grounded in best practices.\29\
---------------------------------------------------------------------------

    \27\ Id.
    \28\ Id.
    \29\ Id.
---------------------------------------------------------------------------

c. Remediation
    The NPRM called for 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.\30\ The NPRM proposed requiring that such 
remediation be timely in light of appropriate risk analysis with 
respect to the risks presented.\31\ As noted in the

[[Page 64275]]

NPRM, such remediation is grounded in best practices.\32\
---------------------------------------------------------------------------

    \30\ Id.
    \31\ Id.
    \32\ Id.
---------------------------------------------------------------------------

8. Required Production of Annual Total Trading Volume
    The NPRM defined ``covered DCM'' as a DCM whose annual total 
trading volume is five percent or more of the annual total trading 
volume of all DCMs regulated by the Commission.\33\ It did so for the 
purpose of applying the proposed minimum system safeguards testing 
frequency and independent contractor testing requirements, discussed 
above, to such covered DCMs. The NPRM noted that 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, 
while still requiring all DCMs to conduct testing of all the types 
addressed in the NPRM.\34\ To provide certainty to DCMs as to whether 
they currently met the definition of a covered DCM, the NPRM called for 
each DCM to report to the Commission annually its annual total trading 
volume for the preceding year, and for the Commission to notify each 
DCM annually 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.\35\ The NPRM therefore called for each DCM to 
report its annual total trading volume for 2015 to the Commission 
within 30 calendar days of the effective date of the 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.\36\ The NPRM's definition of covered DCM also 
addressed cases where a DCM that had been a covered DCM ceased to meet 
the definitional requirements for covered DCM status, by providing that 
a covered DCM having annual total trading volume of less than five 
percent of the combined annual total trading volume of all regulated 
DCMs for two consecutive calendar years would cease to be a covered DCM 
as of March 1 of the calendar year following such two consecutive 
calendar years.\37\ This two-year period permitted completion of the 
proposed two-year cycle for independent contractor-conducted controls 
testing.
---------------------------------------------------------------------------

    \33\ Id. at 80148.
    \34\ Id.
    \35\ Id. at 80160, 80161.
    \36\ Id.
    \37\ Id. at 80148.
---------------------------------------------------------------------------

C. Overview of Comments Received

    The comment period for the NPRM closed on February 23, 2016. The 
Commission received nine comment letters addressing the NPRM. Comments 
were provided by: The Chicago Mercantile Exchange (``CME'') Group DCMs, 
the CME SEF, and the CME SDR (collectively, ``CME''); Intercontinental 
Exchange, Inc. (``ICE'') Futures U.S., ICE Swap Trade, and ICE Trade 
Vault (collectively, ``ICE''); the Minneapolis Grain Exchange 
(``MGEX''); the North American Derivatives Exchange (``Nadex''); the 
CBOE Futures Exchange (``CFE''); the Depository Trust and Clearing 
Corporation Data Repository (``DDR''); Tradeweb Markets LLC 
(``Tradeweb''); the Wholesale Markets Broker's Association, Americas 
(``WMBAA''), whose members include BGC SEF, GFI SEF, Tradition SEF, and 
Tullett Prebon SEF; and FireEye, a third-party cybersecurity service 
provider.\38\
---------------------------------------------------------------------------

    \38\ All comment letters are available on the Commission Web 
site at: http://comments.cftc.gov/PublicComments/CommentList.aspx?id=1650.
---------------------------------------------------------------------------

    Most commenters expressed broad support for the proposed system 
safeguards testing rules. ICE stated that it supports the Commission's 
efforts to improve, clarify, and enhance its rules relating to system 
safeguards and address cybersecurity testing, calling clarification and 
enhancement of these rules in response to escalating and evolving 
cybersecurity threats ``timely and welcome,'' and noting that 
cybersecurity and system safeguards are paramount to the functioning of 
the derivatives markets. MGEX said it appreciates and supports the 
efforts the Commission has put forth to address the growing risk that 
cyber threats pose to trading markets. Nadex stated that it ``commends 
the Commission's undertaking of this endeavor,'' that it agrees with 
the general thrust of the proposed rule, and that it appreciates the 
Commission's efforts to clarify and enhance the current system 
safeguards regulations, align requirements with industry standards, and 
ensure that registrants are meeting compliance thresholds. CFE noted 
its agreement with the NPRM's approach featuring principles-based 
testing standards deeply rooted in industry best practices. DDR 
commended the Commission for its efforts to strengthen system 
safeguards and cybersecurity testing, and called the proposed rules 
``constructive steps in addressing key issues.'' Tradeweb stated that 
it strongly supports the principles-based testing standards in the 
NPRM. WMBAA said that it appreciates the Commission's efforts to 
clarify current system safeguards rule and cybersecurity testing 
requirements.
    Many commenters also offered suggestions and recommendations for 
clarification or modification of specific NPRM provisions. These 
comments are addressed as appropriate in connection with the discussion 
below of the final rule provisions to which they relate. Certain 
comments requested further clarification relating to definitions 
provided in the NPRM. Any definitional changes in the final rule are 
provided for clarification only and do not impose new substantive 
obligations not included in the NPRM.

D. Advanced Notice of Proposed Rulemaking Regarding Minimum Testing 
Frequency and Independent Contractor Testing Requirements for Covered 
SEFs

1. ANPRM Provisions
    The NPRM included an Advanced Notice of Proposed Rulemaking 
(``ANPRM'') concerning Commission consideration of whether to propose 
in a future NPRM that the most systemically important SEFs should be 
subject to the same minimum testing frequency and independent 
contractor testing requirements proposed in the NPRM for covered DCMs 
and SDRs.\39\ In announcing its intent to consider such a proposal, the 
Commission expressed its belief that, because these requirements were 
essential to the effectiveness of covered DCM cybersecurity testing and 
the adequacy of their programs of risk analysis and oversight, it is 
appropriate to consider whether the same requirements should be applied 
to the most systemically important SEFs. In the ANPRM, the Commission 
took note that the SEF market is still in the early stages of 
development. It also suggested that one possible definition of 
``covered SEF'' could be SEFs for which the annual total notional value 
of all swaps traded on or pursuant to the rules of the SEF is ten 
percent 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. 
However, the ANPRM stated that the Commission would also consider 
whether annual total notional value or annual total number of swaps 
traded would provide a more appropriate definition, and whether any 
definition should apply to swaps in each asset class separately or to 
all swaps combined regardless of asset class. The Commission requested 
comments regarding each of these

[[Page 64276]]

considerations, possible costs and benefits and how they could be 
quantified or estimated, and any other aspects of the ANPRM.
---------------------------------------------------------------------------

    \39\ 80 FR 80139, 80148 (Dec. 23, 2015).
---------------------------------------------------------------------------

2. Comments Received
    The Commission received several comments concerning the ANPRM.
    Tradeweb called for careful consideration by the Commission, in 
dialogue with the SEFs to whom any proposal would potentially apply, 
before issuance of an NPRM on this subject. Tradeweb suggested that, 
because the SEF market is still in an early stage of development and a 
covered SEF concept could have a disproportionate impact on the 
commercial viability of certain SEFs, both the definition of ``covered 
SEF'' and the potential costs and benefits involved would require 
further study and discussion with the industry. To that end, Tradeweb 
urged the Commission to convene a roundtable or working group of SEFs 
to discuss the nature and scope of any future SEF-specific system 
safeguards NPRM before moving forward with such a proposal. Tradeweb 
advised the Commission to consider the cross-border scope and impact of 
any future NPRM, and to solicit comment from international regulators 
either independently or as part of the suggested roundtable or working 
group.
    Several commenters suggested that any future requirements proposed 
should apply to all SEFs. Tradeweb called for any future proposal to 
avoid putting certain SEFs at a competitive disadvantage, and to cover 
all SEFs rather than only systemically important SEFS. WMBAA 
recommended that the Commission decline to propose a ``covered SEF'' 
concept, arguing that: (1) SEF operations do not raise the same 
systemic concerns attendant on failure of major DCMs or DCOs; (2) 
products traded on SEFs are fungible across multiple platforms; (3) in 
the present early stage of the SEF market, individual SEFs could be 
``covered'' one year but not the next, leading to uncertainty; and (4) 
the present unsettled nature of the SEF regulatory environment would 
make adoption of a ``covered SEF'' concept premature. CME called for 
the Commission to adopt the same risk based system safeguards 
requirements for all SEFs, leaving testing frequency to be determined 
by risk analysis, and avoiding an independent contractor testing 
requirement.
    Tradeweb and WMBAA also suggested that the costs associated with 
imposition of ``covered SEF'' requirements could well exceed any 
benefits derived. However, no commenters offered specific information 
concerning possible costs.
3. Further Commission Consideration
    The Commission has considered and evaluated the comments received 
concerning the ANPRM. The Commission agrees with the comments 
suggesting that further consideration and consultation with both the 
industry and other relevant regulators and stakeholders would be 
appropriate and helpful before issuance of any future NPRM regarding 
``covered SEFs.'' The Commission also notes the current lack of 
specific cost and benefit information regarding this concept, and the 
current absence of a consensus on how ``covered SEF'' would be best 
defined in light of the characteristics of swaps and the swap market. 
Accordingly, the Commission will engage in appropriate consultation 
prior to determining whether to issue a future NPRM regarding ``covered 
SEFs.''

II. The Final Rules

A. Categories of Risk Analysis and Oversight--Sec. Sec.  37.1401(a), 
38.1051(a), and 49.24(b).

1. Proposed Rule
    As noted above, the NPRM proposed clarification of what is already 
required of all DCMs, SEFs, and SDRs regarding the categories which 
their programs of risk analysis and oversight must address, by further 
defining the six categories addressed by the current rules.\40\ It also 
added and defined another category, enterprise risk management and 
governance, doing so to clarify a requirement already implicit in the 
statutory mandate to maintain a program of system safeguards risk 
analysis and oversight.\41\ As set out in the NPRM, all seven 
categories and their definitions are grounded in generally accepted 
best practices.\42\
---------------------------------------------------------------------------

    \40\ 80 CFR 80139, 80147 (Dec. 23, 2015).
    \41\ Id. at 80143.
    \42\ Id.
---------------------------------------------------------------------------

2. Comments Received
    The Commission received three comments on this topic. Two 
commenters, CME and DDR, concurred with the NPRM's addition of the 
category of enterprise risk analysis and governance to the list of 
categories that programs of risk analysis and oversight must address, 
and suggested clarifications in this respect. CME stated that it 
recognizes the importance of effective Board oversight, and asked the 
Commission to confirm that such oversight may appropriately be 
delegated to Board level committees. CME also asked the Commission to 
confirm that the final rule will allow regulated entities flexibility 
of organizational design concerning how their programs of risk analysis 
and oversight address the enterprise risk management and governance 
category, and will not require that an entity's enterprise risk 
management function conduct all components of this category. DDR agreed 
with the Commission that active supervision of system safeguards by 
both senior management and the Board of Directors promotes more 
efficient, effective, and reliable risk management, and will better 
position regulated entities to strengthen the integrity, resiliency, 
and availability of their automated systems. Noting its agreement that 
regulated entities should give their boards access to the appropriate 
system safeguards and cyber resiliency information so as to enable 
effective oversight, DDR suggested that the final rules should 
acknowledge that there are multiple ways a regulated entity can ensure 
that its board is appropriately informed. One commenter, MGEX, 
questioned why this NPRM proposed adding the category of enterprise 
risk management and governance, while the Commission's parallel Notice 
of Proposed Rulemaking addressed to DCOs did not, citing this as an 
inconsistency between the two NPRMs.\43\
---------------------------------------------------------------------------

    \43\ See 80 FR 80139, 80113 (Dec. 23, 2015).
---------------------------------------------------------------------------

    MGEX commented that the NPRM proposed a requirement for all DCMs, 
SEFs, and SDRs to have a program of risk analysis and oversight, 
without defining such a program. MGEX also stated that the lists of 
topics specified in the NPRM as included in each category to be 
addressed in the required program of risk analysis and oversight were 
overly prescriptive, citing as an example the list of topics the NPRM 
specified as included in the category of information security. MGEX 
suggested that the specified categories should be principles-based and 
should look to evolving best practices.
3. Final Rule
    The Commission has considered and evaluated the comments concerning 
addition of the category of enterprise risk analysis and governance to 
the list of categories which must be addressed by the program of system 
safeguards-related risk analysis and oversight which the CEA requires 
all DCMs, SEFs, and SDRs to establish and maintain. For the reasons set 
forth below, the Commission is adopting the list of categories as 
proposed.

[[Page 64277]]

    The Commission continues to believe that addition of the category 
of enterprise risk analysis and governance is appropriate because this 
clarifies a requirement already implicit in the statutory mandate to 
maintain a program of system safeguards risk analysis and 
oversight.\44\ The Commission confirms that the addition of this 
category does not require that the listed elements of this category be 
conducted through a particular organizational structure or by 
particular DCM, SEF, or SDR staff; rather, the final rule provides 
flexibility in this regard.
---------------------------------------------------------------------------

    \44\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------

    The Commission agrees with the comments acknowledging the 
importance of effective Board of Directors oversight of system 
safeguards, which the Commission believes is essential to establishing 
and maintaining the top-down, organization-wide culture of adherence to 
cybersecurity principles that is required for resilience in today's 
cybersecurity threat environment. In addition, the Commission agrees 
with CME's comment that Board of Directors oversight of system 
safeguards may appropriately be delegated to a Board-level committee or 
committees, and with DDR's comment that there are a variety of ways in 
which a DCM, SEF, or SDR can ensure that its Board is sufficiently and 
appropriately informed to enable it to provide appropriate system 
safeguards and cybersecurity oversight. In the Commission's view, 
providing the Board with information sufficient to enable it to provide 
active, appropriate, knowledgeable, and effective oversight of system 
safeguards and cybersecurity is the key in this regard.
    The Commission has also considered and evaluated MGEX's comment 
asserting that the NPRM proposed establishment of a requirement for 
DCMs, SEFs, and SDRs to have a program of system safeguards risk 
analysis and oversight, without defining such a program, and its 
comment concerning the lists of topics specified in the NPRM as 
included in each category to be addressed in the required program of 
risk analysis and oversight. The requirement for regulatees to have a 
program of system safeguards risk analysis and oversight was mandated 
by Congress in the CEA itself, and thus is required by law.\45\ The 
NPRM's references to it did not propose creation of a new requirement 
in this regard. The Commission's current system safeguards regulations 
define the program of risk analysis and oversight by specifying the 
categories of risk analysis and oversight which the program must 
address. As noted above and in the NPRM, the category of enterprise 
risk management and governance is implicit and inherent in the 
statutory requirement itself, and supported by generally accepted 
standards and best practices.\46\
---------------------------------------------------------------------------

    \45\ CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20).
    \46\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------

    The Commission agrees with MGEX that the required categories of 
risk analysis and oversight should be principles-based, but disagrees 
that the NPRM lists of topics included in each category consist of 
static lists of controls. As set out in detail in the NPRM, each of the 
aspects cited in the NPRM for the various categories that the required 
program of risk analysis and oversight must address is rooted in 
generally accepted standards and best practices.\47\ Because the 
Commission's current system safeguards rules and guidance provide that 
DCMs, SEFs, and SDRs should follow generally accepted best practices 
and standards regarding system safeguards, these entities' programs of 
risk analysis and oversight should already be addressing each of the 
aspects included in the NPRM for each risk analysis and oversight 
category. As the NPRM explicitly states, the aspects specified in the 
NPRM for each category do not provide all-inclusive or static lists; 
rather, they highlight important aspects of the categories that are 
already recognized as best practices.\48\ An important benefit of the 
adherence-to-best-practices approach taken in the Commission's current 
system safeguards rules, the NPRM generally, and the NPRM provisions 
addressing the categories in particular, is precisely that such best 
practices can evolve over time as the cybersecurity field evolves. In 
addition, the Commission continues to believe, as it stated in the 
NPRM, that risk analysis and oversight programs that address each of 
the aspects listed in the NPRM for the risk analysis and oversight 
categories are essential to maintaining effective system safeguards in 
today's cybersecurity threat environment.\49\
---------------------------------------------------------------------------

    \47\ Id.
    \48\ Id.
    \49\ Id. at 80145.
---------------------------------------------------------------------------

B. Requirement To Follow Generally Accepted Standards and Best 
Practices--Sec. Sec.  37.1401(b), 38.1051(b), and 49.24(c)

1. Proposed Rule
    The NPRM retained the substance of the Commission's current system 
safeguards rule provision calling for DCMs, SEFs, and SDRs to adhere to 
generally accepted standards and best practices in their required 
programs of system safeguards risk analysis and oversight. The only 
change proposed in the NPRM was language adjustment to clarify that 
such adherence is mandatory for all DCMs, SEFs, and SDRs.\50\
---------------------------------------------------------------------------

    \50\ Id. at 80146.
---------------------------------------------------------------------------

2. Comments Received
    Several commenters, including CME, Nadex, DDR, Tradeweb, and WMBAA, 
agreed with the Commission that an entity's program of risk analysis 
and oversight should follow generally accepted standards and best 
practices. CME requested that the Commission confirm that generally 
accepted best practices not explicitly cited in the NPRM may also be 
used in this regard. CME also asked the Commission to confirm that the 
intent of this provision is that a regulated entity should take 
generally accepted best practices into account as it designs a program 
of risk analysis and oversight tailored to its risks and its 
appropriate analysis of those risks, rather than to codify particular 
best practices.
3. Final Rule
    The Commission has considered and evaluated the comments concerning 
the requirement that a DCM's, SEF's, or SDR's required program of risk 
analysis and oversight should follow generally accepted standards and 
best practices. For the reasons set forth below, the Commission is 
adopting this provision as proposed.
    As CME asked the Commission to confirm, the best practices cited in 
the NPRM do not constitute an exclusive or codified list.\51\ DCMs, 
SEFs, and SDRs should take generally accepted best practices and 
standards into account as they conduct appropriate and current analysis 
of individual risks and conducts appropriate and effective oversight 
with respect to such risks. A program of risk analysis and oversight 
should consider all generally accepted sources of best practices in 
addressing the particular risks and circumstances of the entity in 
question in an effective and appropriate way. In the Commission's view, 
the requirement to follow generally accepted standards and best 
practices is one of the most important requirements of the Commission's 
system safeguards rules. Best practices evolve over time in conjunction 
with the changing cybersecurity threat environment. The agility that a 
best practices approach therefore provides is crucial to effective 
resilience with respect to cybersecurity and system

[[Page 64278]]

safeguards. In addition, ongoing development of best practices benefits 
from private sector expertise and input, as well as from public sector 
contributions. Such private sector expertise and input is important to 
effective cybersecurity. The Commission also observes that requiring 
financial sector entities to follow best practices with respect to 
system safeguards and cybersecurity is an effective key to harmonizing 
the oversight of cybersecurity conducted by different financial 
regulators. Some financial regulators, such as the FFIEC agencies, are 
themselves sources of generally accepted best practices. Regulatory 
oversight of cybersecurity generally follows best practices, most 
sources of which are largely consonant with each other.
---------------------------------------------------------------------------

    \51\ Id.
---------------------------------------------------------------------------

C. Business Continuity-Disaster Recovery Plan--Sec. Sec.  37.1401(c), 
38.1051(c), and 49.24(d)

1. Proposed Rule
    The Commission's current rules concerning the business continuity-
disaster recovery (``BC-DR'') plans of DCMs, SEFs, and SDRs require 
that these entities maintain BC-DR plans and resources, emergency 
procedures, and backup facilities sufficient to enable timely recovery 
and resumption of their operations and fulfillment of their 
responsibilities and obligations as registrants, and specify recovery 
time. The NPRM proposed further alignment of these provisions with 
generally accepted standards and best practices by adding a requirement 
for DCMs, SEFs, and SDRs to update their BC-DR plans and emergency 
procedures at a frequency determined by an appropriate risk analysis, 
but at a minimum no less frequently than annually.\52\
---------------------------------------------------------------------------

    \52\ Id. at 80147.
---------------------------------------------------------------------------

2. Comments Received
    CME stated that it agreed with the Commission's proposal to require 
updating of BC-DR plans and emergency procedures at least annually and 
more frequently if necessitated by other circumstances.
3. Final Rule
    The Commission has considered and evaluated the comment concerning 
the frequency of updates to BC-DR plans and emergency procedures, with 
which it agrees. As noted above, updating such plans at a frequency 
determined by risk analysis but no less frequently than annually is 
supported by generally accepted standards and best practices. The 
Commission is adopting this provision as proposed.

D. Books and Records Requirements--Sec. Sec.  37.1401(g), 38.1051(g), 
and 49.24(i)

1. Proposed Rule
    As noted above, 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.\53\ The NPRM proposed amending these document production 
provisions to further clarify requirements for system safeguards-
related document production.\54\ Specifically, the NPRM proposed 
requiring each DCM, SEF, or SDR to provide to the Commission, promptly 
on the request of Commission staff: Current copies of its BC-DR plans 
and emergency procedures; all assessments of its operational risks or 
system safeguards-related controls; all reports concerning system 
safeguards testing and assessment; and all other books and records 
requested in connection with Commission oversight of system 
safeguards.\55\
---------------------------------------------------------------------------

    \53\ 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).
    \54\ 80 FR 80139, 80147 (Dec. 23, 2015).
    \55\ Id.
---------------------------------------------------------------------------

2. Comments Received
    Two commenters, CME and WMBAA, recognized the Commission's 
established authority to require production of records, but asked the 
Commission to continue to work with DCMs, SEFs, and SDRs to find ways 
that highly sensitive system safeguards-related materials can be made 
available to Commission staff in ways that maximize protection of their 
confidentiality. WMBAA suggested that this could be accomplished in 
appropriate cases by having CFTC staff review highly sensitive 
information at a registrant's location or in a non-electronic, non-
reproducible format.
    ICE, suggested that, with respect to parent firms that own both 
CFTC-regulated and non-CFTC-regulated entities, the Commission should 
avoid requiring production of documents discussing risks at the firm-
wide level, and limit its production requests to documents focused 
solely on the risks of CFTC-regulated entities. In contrast, WMBAA 
noted that a registrant's systems, such as SEF systems, are often a 
subset of a larger financial services company's systems, and share 
cybersecurity defenses, procedures, and testing with the parent entity 
as a whole, rather than standing alone with respect to cybersecurity. 
WMBAA suggested that it would be contrary to best practices for CFTC 
oversight to focus solely on the risks and cybersecurity protections of 
the CFTC-regulated entity's systems, without considering the related 
systems and protections of the parent entity.
3. Final Rule
    The Commission has considered and evaluated the comments concerning 
the books and records provisions of the NPRM. For the reasons set forth 
below, the Commission is adopting these provisions as proposed.
    The established requirements of the Commission's regulations 
regarding production of books and records are essential to the 
Commission's ability to fulfill its oversight responsibilities. The 
Commission also recognizes that the cybersecurity and system safeguards 
information of DCMs, SEFs, and SDRs can be sensitive. As noted by 
commenters, Commission staff conducting cybersecurity oversight work 
regularly with regulated entities to find ways for sensitive 
cybersecurity information to be made available to the Commission while 
minimizing the risk of inappropriate disclosure.
    The Commission has also considered and evaluated the comments 
concerning production of books and records that address the system 
safeguards risks and cybersecurity protections of parent companies. The 
Commission agrees with WMBAA's observation that the automated systems, 
programs of system safeguards-related risk analysis and oversight, 
cybersecurity defenses and testing, and BC-DR plans and resources of 
CFTC-regulated DCMs, SEFs, and SDRs owned by parent financial sector 
companies that also own entities not regulated by the Commission are 
frequently shared across the parent company. Indeed, this is presently 
the case with respect to the parent companies of all DCMs, SEFs, and 
SDRs regulated by the Commission which are subsidiaries of a parent 
company. The Commission disagrees with ICE's suggestion that production 
of books and records addressing parent-wide system safeguards risks and 
risk analysis and oversight programs should not be required. Production 
of all of the books and records specified in the NPRM books and records 
provision is already required by the Act and Commission regulations, 
notably by Commission regulation Sec.  1.31.\56\ Because DCMs, SEFs, 
and SDRs often share system safeguards and cybersecurity risks, system 
safeguards risk analysis and oversight programs, automated systems, 
business continuity-disaster recovery

[[Page 64279]]

plans, and other system safeguards and cybersecurity resources with 
their parent companies, the suggested limitation would in many cases--
including the case of ICE itself--cripple the oversight of system 
safeguards risks and risk analysis and oversight programs for which the 
CEA makes the Commission responsible, and thus would harm the public 
interest. The Commission will continue to exercise its authority to 
require production of all books and records relating to the system 
safeguards of DCMs, SEFs, and SDRs, including those relating to the 
system safeguards risks and risk analysis and oversight programs of 
parent companies where such risks or such programs are shared in whole 
or in part by a DCM, SEF, or SDR.
---------------------------------------------------------------------------

    \56\ 80 FR 80139, 80147 (Dec. 23, 2015).
---------------------------------------------------------------------------

E. System Safeguards Testing--Sec. Sec.  37.1401(h), 38.1051(h), and 
49.24(j)

    The provisions of the NPRM addressing automated system testing by 
DCMs, SEFs, and SDRs retained the language of the Commission's current 
rules requiring these entities to conduct regular, periodic, objective 
testing and review of their automated systems to ensure their 
reliability, security, and adequate scalable capacity.\57\ They also 
retained the language of the current rules requiring regular, periodic 
testing and review of the business continuity-disaster recovery 
capabilities of such entities. The NPRM proposed further clarification 
of the current rules by specifying that such testing and review must 
include vulnerability testing, penetration testing, controls testing, 
security incident response plan testing, and enterprise technology risk 
assessment, and defining certain terms related to such testing.\58\
---------------------------------------------------------------------------

    \57\ Id. at 80147, 80148.
    \58\ Id.
---------------------------------------------------------------------------

1. Definitions--Sec. Sec.  37.1401(h)(1), 38.1051(h)(1), and 
49.24(j)(1)
a. Proposed Rule
    For the purposes of the testing sections of the Commission's system 
safeguards rules, the NPRM defined the following terms relating to 
system safeguards testing and assessment by DCMs, SEFs, and SDRs: 
Controls; controls testing; enterprise technology risk assessment; 
external penetration testing; internal penetration testing; key 
controls; security incident; security incident response plan; security 
incident response plan testing; and vulnerability testing. With respect 
to testing by DCMs, the NPRM also defined the following term: Covered 
designated contract market.\59\
---------------------------------------------------------------------------

    \59\ Id. at 80148.
---------------------------------------------------------------------------

b. Comments Received
    Five commenters, CME, ICE, MGEX, DDR, and WMBAA, provided comments 
concerning some of the definitions proposed in the NPRM.
    (1) External and internal penetration testing.
    ICE recommended that the definitions of external and internal 
penetration testing specify that such testing should include scenario 
or capture-the-flag testing intended to compromise the system 
holistically via all available means including technical exploit, 
social engineering, and lateral traversal. ICE also suggested that the 
Commission clarify that penetration testing is not intended to include 
application-specific tests, and recommended that the final rule should 
avoid specifying parameters for internal penetration testing, in order 
to allow each regulated entity to determine its own testing 
methodology. Tradeweb suggested that external penetration testing 
should be defined to mean penetration testing conducted over the 
internet. WMBAA suggested that the final rule should not focus on 
testing from a SEF system's perimeter, but should focus on all the 
systems supporting the SEF's functionality, whether those of the SEF 
itself or of its parent company.
(2) Controls and Key Controls
    As part of its recommendation that the final rule eliminate all 
requirements for controls testing (addressed in the discussion of 
controls testing below), ICE recommended that the final rule should 
remove the proposed definitions of controls and key controls.
(3) Covered Designated Contract Market
    MGEX commented that the definitional distinction between covered 
and non-covered DCMs is a valuable concept that recognizes the lower 
systemic risk posed by smaller entities.\60\ However, CME commented 
that the distinction is unnecessarily complex and imposes undue 
burdens, and suggested that the final rule adopt a uniform set of 
standards for all DCMs. CME also suggested that if the covered DCM 
concept were to be retained, the Commission should consider 
alternatives to annual DCM reporting of total annual trading volume, 
because the Commission currently receives volume reports pursuant to 
DCM Core Principle 8 and part 16 of the Commission's regulations.
---------------------------------------------------------------------------

    \60\ MGEX commented that the Commission should use a similar 
definition to distinguish between larger and smaller derivatives 
clearing organizations (``DCOs''). MGEX also made these comments in 
its comment letter concerning the Commission's NPRM regarding system 
safeguards testing by DCOs, available at: http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60651&SearchText=. Since testing 
by DCOs is not addressed by this final rule, but will be addressed 
in the final rule regarding DCO system safeguards testing, these 
comments are most appropriately addressed in the DCO system 
safeguards testing final rule, and are addressed there.
---------------------------------------------------------------------------

(4) Security Incident
    The NPRM defined ``security incident'' as 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. No comments were 
received concerning the NPRM definition. However, the Commission 
received a comment from the Options Clearing Corporation (``OCC'') 
concerning the identical definition included in the parallel Notice of 
Proposed Rulemaking issued by the Commission on December 15, 2015, 
proposing to amend its system safeguards rules for DCOs.\61\ OCC argued 
that including in the definition events that ``potentially'' jeopardize 
automated systems or data renders the definition vague, and could be 
interpreted to include most, if not all, cybersecurity events 
experienced by a DCO. OCC suggested amending the definition to replace 
``potentially jeopardizes'' with ``has a significant likelihood of 
jeopardizing.''
---------------------------------------------------------------------------

    \61\ 80 FR 80113 (Dec. 23, 2015). The OCC comment letter is 
available at http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60650&SearchText=.
---------------------------------------------------------------------------

    Some comments also addressed terms that were used but not defined 
in the NPRM. Although the NPRM did not define the terms ``recovery'' or 
``resumption,'' DDR commented that, in its view, the NPRM distinguished 
between resumption of critical functions following a cyber incident on 
the one hand, and recovery in the sense of restoration of capabilities 
or services impaired due to a cyber event. Noting that this distinction 
is consistent with the definitions of these terms in the CMPI-IOSCO 
Guidance on Cyber Resilience for Financial Market Infrastructures--
Consultative Report of November 24, 2015,\62\ DDR stated that in this 
respect the NPRM appropriately recognized differences among financial 
market infrastructures with respect to varying requirements for 
recovery and resumption timeframes.
---------------------------------------------------------------------------

    \62\ CPMI-IOSCO, Guidance on Cyber Resilience for Financial 
Market Infrastructures--Consultative Report (Nov. 2015), at 26, 
available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD513.pdf.

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

[[Page 64280]]

    CME, ICE, and MGEX commented concerning the NPRM's use of the terms 
``independent contractor'' and ``independent professional.'' CME 
asserted that neither term is clearly defined in either the 
Commission's current rules or the NPRM. ICE called on the Commission to 
clarify in the final rule that entity employee groups such as the 
internal audit function are considered to be independent professionals 
not responsible for the development of operation of the systems or 
capabilities tested or assessed in the area of system safeguards. While 
not commenting directly on these definitions, MGEX expressed the view 
that having independent testing performed is a key and costly feature 
proposed in the NPRM.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
the definitions proposed in the NPRM. For the reasons discussed below, 
the final rule will amend the definition of security incident, and 
otherwise retain the definitions as proposed.
(1) External and Internal Penetration Testing
    The Commission agrees with ICE's suggestion that penetration 
testing that attempts to compromise an entity's systems holistically 
through means including technical exploit, social engineering, and 
lateral traversal is appropriate to today's cybersecurity threat 
environment. The Commission also agrees with ICE's recommendation that 
the final rule should avoid specifying particular internal penetration 
testing parameters in order to give DCMs, SEFs, and SDRs flexibility in 
determining their particular methodology for such testing, and believes 
that approach is also appropriate regarding external penetration 
testing. Best practices indicate that with respect to penetration 
testing, entities should regularly ``update the list of attack 
techniques and exploitable vulnerabilities used in penetration testing 
based on an organizational assessment of risk or when significant new 
vulnerabilities or threats are identified and reported.'' \63\ Where 
penetration testing that attempts to compromise systems holistically 
through means including technical exploit, social engineering, and 
lateral traversal is called for by appropriate risk analysis, as it may 
be in most or even all cases, the final rule will require penetration 
testing using such means, by virtue of its requirement for all DCMs, 
SEFs, and SDRs to follow best practices, and its requirement for all 
DCMs, SEFs, and SDRs to make the scope of their cybersecurity testing 
broad enough to include all testing that their programs of risk 
analysis and current cybersecurity threat analysis indicate is 
necessary. The Commission notes that essential penetration testing 
methods and techniques may change over time, based on an entity's 
appropriate risk analysis, technological changes, and the evolving 
nature of cybersecurity threats. The Commission disagrees with 
Tradeweb's suggestion that external penetration testing should be 
defined as testing conducted over the Internet. Best practices indicate 
that external penetration testing should be conducted from multiple 
vectors including remote access, virtual private network connections, 
and any separate environments or local area network segments, as well 
as the internet.\64\ In addition, such testing should include not only 
Iinternet based or network-layer based tests but also application-layer 
assessments. The Commission agrees with WMBAA's comment that 
penetration testing must include testing of all systems supporting a 
regulated entity's functionality or involved in the entity's system 
safeguards, whether the systems belong to the entity itself or to the 
entity's parent company.
---------------------------------------------------------------------------

    \63\ NIST SP 800-53A, Rev. 4, Assessing Security and Privacy 
Controls in Federal Information Systems and Organizations--Building 
Effective Assessment Plans, at E-1, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
    \64\ See, e.g., Security Standards Council, Payment Card 
Industry Data Security Standards, Apr. 2016, v. 3.2 (``PCI DSS''), 
available at https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf, Information Supplement: Penetration Testing 
Guidance, at 5-8, available at https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf; and Center 
for Internet Security, Critical Security Controls, at 68-69, 
available at https://www.cisecurity.org/critical-controls/.
---------------------------------------------------------------------------

(2) Covered Designated Contract Market
    The Commission has considered and evaluated the comments for and 
against the NPRM's definitional distinction between covered and non-
covered DCMs. The Commission continues to believe that the NPRM's 
proposed requirements regarding the minimum frequencies at which 
various types of cybersecurity testing should be conducted and 
regarding the use of independent contractors to perform specified tests 
are important and appropriate in today's cybersecurity threat 
environment. As noted in the NPRM, these requirements aim to strengthen 
the objectivity and reliability of the testing and assessment 
information available to the Commission regarding system safeguards, 
and to ensure the effectiveness and timeliness of both cybersecurity 
testing and programs of risk analysis and oversight.\65\ Additionally, 
the use of independent contractors for many types of testing is 
consonant with best practices. The Commission also continues to believe 
that application of these requirements 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 is appropriate. This 
approach reduces possible costs and burdens for smaller and less 
systemically critical DCMs, by giving them additional flexibility 
regarding their cybersecurity testing. The fact that smaller DCMs will 
still be required to conduct testing of all the types addressed in the 
final rule means that this approach will not impair the fundamental 
goals of the CEA and the Commission's system safeguards regulations. 
The NPRM also proposed offering such added flexibility to SEFs, which 
like non-covered DCMs are required to conduct all of the specified 
types of testing but not made subject to the minimum frequency and 
independent contractor requirements. The Commission continues to 
believe this to be appropriate as well, for the same reasons.\66\
---------------------------------------------------------------------------

    \65\ 80 FR 80139, 80148 (Dec. 23, 2015).
    \66\ Id.
---------------------------------------------------------------------------

    The Commission declines CME's suggestion that it rely on DCM volume 
reports submitted pursuant to part 16 of the Commission's regulations. 
The Commission notes that while it receives daily trade information 
from DCMs pursuant to part 16, it does not receive total annual trading 
volume information from DCMs.\67\ The Commission believes that DCM 
submission of annual trading volume requirement is essential for the 
Commission to accurately evaluate whether a particular DCM must comply 
with the frequency and independent contractor requirements as a covered 
DCM. The Commission believes that annual total trading volume 
information is readily available to DCMs, and that DCMs generally 
calculate their annual trading volume in the usual course of business. 
The Commission does not believe that looking up the amount of a DCM's 
annual total trading volume and reporting that amount to the Commission 
once a year, something that can be done by email in thirty minutes

[[Page 64281]]

or less, can reasonably be said to impose an undue burden on a DCM.
---------------------------------------------------------------------------

    \67\ Core Principle 8 is inapplicable here, because it requires 
DCMs to publish daily volume information but does not require 
submission of that information to the Commission.
---------------------------------------------------------------------------

(3) Security Incident
    The Commission has considered and evaluated OCC's comment 
concerning the definition of ``security incident'' included in the 
Commission's parallel NPRM proposing amendment of its system safeguards 
rules for DCOs. The Commission is amending the definition as the 
comment suggested, defining security incident as a cyber security or 
physical security event that ``actually jeopardizes or has a 
significant likelihood of jeopardizing'' automated systems or data. The 
definition included in the DCO NPRM is identical to the one included in 
the NPRM regarding DCMs, SEFs, and SDRs. The Commission issued the two 
NPRMs simultaneously and in parallel, and intended that the final rules 
issued in connection with both NPRMs should be closely aligned. 
Accordingly, the Commission believes the comment received is germane to 
both final rules. The Commission also notes that the amendment of this 
definition does not expand the definition's reach but rather narrows it 
somewhat, and therefore lightens any costs or burdens involved to at 
least some degree.
(4) Recovery and Resumption
    With respect to DDR's comment regarding the terms ``recovery'' and 
``resumption,'' the Commission notes that the NPRM did not, and the 
final rule will not, define these terms or make any change to the 
language or the requirements of the Commission's current system 
safeguards rules for DCMs, SEFs, or SDRs regarding recovery and 
resumption of operations and fulfillment of responsibilities and 
obligations as a registered entity.
(5) Independent Contractor and Independent Professional
    The Commission has considered and evaluated the various comments 
concerning the terms ``independent contractor'' and ``independent 
professional'' used in the NPRM.\68\ The Commission notes that both 
terms are effectively defined in the Commission's current system 
safeguards rules for DCMs and SDRs and its current system safeguards 
rules and guidance for SEFs.\69\ These current provisions call for the 
system safeguards testing required of all DCMs, SEFs, and SDRs to be 
conducted by qualified, independent professionals, who may be 
independent contractors or employees of the DCM, SEF, or SDR, but 
should not be persons responsible for development or operation of the 
systems or capabilities being tested.\70\
---------------------------------------------------------------------------

    \68\ 80 FR 80139, 80146 through 80161 (Dec. 23, 2015).
    \69\ 17 CFR Sec. Sec.  38.1051(h) (for DCMs); 37.1401 (g) and 
Appendix B to Part 37, Core Principle 14 of Section 5h of the Act--
System Safeguards (C)(a)(2) (for SEFs); 49.24(j) (for SDRs).
    \70\ Id.
---------------------------------------------------------------------------

    Accordingly, for purposes of the current system safeguards rules, 
independent contractors are qualified system safeguards professionals 
who are not employees of the DCM, SEF, or SDR. The current rules use 
the terms independent contractor and employee as they are legally 
defined and generally used.\71\ The Commission believes that the 
distinction between independent contractor and employee is well settled 
and understood, and does not need additional definition in the system 
safeguards rules.
---------------------------------------------------------------------------

    \71\ See, e.g., Black's Law Dictionary, Tenth Ed. (Thomson 
Reuters, St. Paul, MN, 2014) (``Employee. Someone who works in the 
service of another person (the employer) under an express or implied 
contract of hire, under which the employer has the right to control 
the details of work performance.'') (``Independent Contractor. 
Someone who is entrusted to undertake a specific project but who is 
left free to do the assigned work and to choose the method for 
accomplishing it.'')
---------------------------------------------------------------------------

    With respect to system safeguards testing, the current rules 
provide that employees conducting required testing must be independent 
in that they are not employees responsible for development or operation 
of the systems or capabilities being tested. The Commission believes 
that this distinction between employees with sufficient independence to 
appropriately conduct required system safeguards testing and those who 
lack such independence is also sufficiently clear, and does not require 
additional definition. The NPRM used, and the final rule will retain, 
this language from the current system safeguards rules. Where this 
requirement is included, the testing in question must be conducted by 
employees who are independent, which means employees not responsible 
for developing or operating what is being tested.\72\ Employees who are 
part of the internal audit function of a DCM, SEF, or SDR, are one 
example of employees having appropriate independence. Other employees 
who possess the specified degree of independence and have 
qualifications the DCM, SEF, or SDR believes are appropriate may also 
be suitable in such cases.
---------------------------------------------------------------------------

    \72\ This requirement is included in the final rule provisions 
concerning most types of testing, but as discussed below is not 
included in the SIRP testing provision.
---------------------------------------------------------------------------

    One clarification may be helpful with respect to testing required 
to be performed by independent contractors, as distinct from testing 
performed by persons performing the internal audit function. As noted 
above, the internal audit function is a required aspect of the 
enterprise risk management and governance category which must be 
included in the program of risk analysis and oversight that a DCM, SEF, 
or SDR must maintain. It is an integral part of, and a responsibility 
of, the regulated entity, whether carried out in-house or outsourced. 
The NPRM proposed required testing by independent contractors in part 
to give the Commission's system safeguards oversight a third source of 
system safeguards information on which to rely, in addition to the 
entity's employees and its internal audit function.\73\ It also 
proposed independent contractor testing to give the regulated entity 
the benefit of a truly outside perspective concerning system 
safeguards, not colored by beginning from the institutional point of 
view, something that best practices say is important as noted earlier. 
Accordingly, testing performed by persons executing the internal audit 
function will not fulfill the requirement for testing by independent 
contractors, whether it is performed by employees executing the 
internal audit function or by internal audit contractors to whom a DCM, 
SEF, or SDR outsources part or all of its internal audit function.
---------------------------------------------------------------------------

    \73\ 80 FR 80139, 80148 (Dec. 23, 2015).
---------------------------------------------------------------------------

2. Vulnerability Testing--Sec. Sec.  37.1401(h)(2), 38.1051(h)(2), and 
49.24(j)(2)
a. Proposed Rule
    The NPRM called for all DCMs, SEFs, and SDRs to conduct 
vulnerability testing of a scope sufficient to satisfy the requirements 
in the proposed rule.\74\ It proposed requiring all such entities to 
conduct vulnerability testing at a frequency determined by an 
appropriate risk analysis, with a minimum frequency requirement of 
quarterly vulnerability testing for covered DCMs and SDRs.\75\ The NPRM 
called for vulnerability testing to include automated vulnerability 
scanning, conducted on an authenticated basis where indicated by 
appropriate risk analysis, with compensating controls where scanning is 
conducted on an unauthenticated basis. The NPRM called for covered DCMs 
and SDRs to engage independent contractors to conduct two of the 
minimum quarterly vulnerability tests required of them each

[[Page 64282]]

year.\76\ It provided that all other vulnerability testing by covered 
DCMs and SDRs, and all vulnerability testing by non-covered DCMs and 
SEFs, should be conducted either by independent contractors or by 
employees not responsible for development or operation of the systems 
or capabilities being tested.\77\
---------------------------------------------------------------------------

    \74\ 80 FR 80139, 80148 through 80151 (Dec. 23, 2015).
    \75\ Id. at 80149, 80150.
    \76\ Id. at 80150.
    \77\ Id. at 80150, 80151.
---------------------------------------------------------------------------

b. Comments Received
(1) Requirement for Vulnerability Testing
    Several commenters, including CME, ICE, and Nadex, agreed that the 
NPRM's call for vulnerability testing was appropriate, because such 
testing is critical to identification and remediation of cybersecurity 
vulnerabilities. CME stated that vulnerability testing, of a scope 
aligned with risk analysis, should be embedded in an organization's 
systems development life cycle, in order to promote a culture of 
awareness as early and close to the first line of defense as possible.
(2) Vulnerability Testing Frequency
    Commenters, including CME and ICE, supported the minimum quarterly 
vulnerability testing frequency requirement for covered DCMs and SDRs. 
CME noted that at least quarterly testing is likely to be an 
appropriate frequency for most organizations where critical assets are 
concerned. Regarding the requirement to test as often as indicated by 
appropriate risk analysis, CME agreed that vulnerability testing 
frequency should be aligned with appropriate risk analysis. MGEX called 
for the final rule to leave the frequency of vulnerability testing to 
be determined by regulatees. ICE argued that regulatees should not be 
subject to a formal risk assessment to potentially determine a higher 
vulnerability testing frequency. Nadex asked the Commission to confirm 
that the level of detail in the risk assessment used to determine 
appropriate vulnerability testing frequency is that called for by 
generally accepted standards and best practices.
(3) Automated Scanning and Authenticated Scanning
    Commenters raised no issue with the NPRM requirement for 
vulnerability testing to include automated vulnerability scanning. ICE 
called for removal of the requirement for automated scanning to include 
authenticated scanning, arguing that this requirement would increase 
the cost and time of a scan, increase risk through creation of an 
operating system login on a new system, and have limited utility in the 
context of financial system infrastructure.
(4) Vulnerability Testing by Independent Contractors
    A number of commenters argued that the use of independent 
contractors for vulnerability testing could undesirably increase risks. 
CME suggested that outsider access to systems can broaden both 
operations risk and the risk of disclosure of sensitive information, 
and noted that there is a limited supply of independent contractors 
with appropriate qualifications for vulnerability testing. ICE 
commented that vulnerability scanners can be hazardous to systems, can 
cause issues during deployment, and require a high level of care to 
avoid live system jeopardy, including both intimate network knowledge 
and change control interaction. In short, ICE stated, third-party 
vulnerability scanning would be costly and potentially dangerous 
without adding value. DDR stated that vulnerability testing by 
independent contractors would introduce unnecessary risk to critical 
infrastructure and heighten the risk of systems outages. These 
commenters therefore requested that the final rule eliminate the 
independent contractor requirement for vulnerability testing, and 
permit such testing to be conducted by entity employees not responsible 
for development or operation of the systems or capabilities tested. CME 
suggested that allowing such employees to conduct vulnerability testing 
has been proven effective, allows testing by those with the greatest 
knowledge and experience concerning the systems tested, and has the 
benefit of promoting an organizational culture of cybersecurity 
awareness. DDR recommended that SDR employees conduct vulnerability 
testing, and that independent contractors review testing procedures to 
confirm that they are effective and consonant with industry standards.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
vulnerability testing. For the reasons set out below, the final rule 
will call for vulnerability testing and include the proposed 
vulnerability testing frequency requirements, but will not require that 
automated vulnerability scanning include authenticated scanning, and 
will not require the use of independent contractors as proposed.
(1) Requirement for Vulnerability Testing
    The Commission agrees with commenters that vulnerability testing is 
critical to identification and remediation of cybersecurity 
vulnerabilities. It is an essential component of an effective program 
of risk analysis and oversight, and an essential means of fulfilling 
the testing requirements of the Commission's current system safeguards 
rules.
(2) Vulnerability Testing Frequency
    The Commission agrees with the comments supporting the minimum 
quarterly vulnerability testing requirement for covered DCMs and SDRs, 
and agrees that, in today's cybersecurity environment, most 
organizations should conduct such testing at least quarterly. The 
Commission also agrees that, beyond the minimum frequency proposed for 
covered DCMs and SDRs, all DCMs, SEFs, and SDRs should conduct 
vulnerability testing as frequently as indicated by appropriate risk 
analysis. The Commission disagrees with the suggestion that the 
frequency of vulnerability testing should simply be left to these 
entities themselves. It is essential for such testing to be conducted 
as frequently as indicated by analysis of a particular entity's risks, 
which is likely in most cases to call for testing at least quarterly. 
The risk analysis referred to in the NPRM in this connection is the 
appropriate risk analysis which each DCM, SEF, and SDR must conduct and 
maintain as an integral part of the program of risk analysis and 
oversight that the CEA requires. ICE apparently misunderstood the NPRM 
as calling for a separate, formal risk analysis made for the specific 
purpose of determining vulnerability testing frequency. That is not 
required; what is required is vulnerability testing as often as 
indicated by the ongoing, appropriate risk analysis inherent in a 
regulatee's required program of risk analysis and oversight. As 
provided in the current system safeguards rules and in the NPRM, the 
program of risk analysis required of a DCM, SEF, or SDR, and the risk 
analyses inherent in that program, are indeed to be conducted in light 
of generally accepted standards and best practices.\78\
---------------------------------------------------------------------------

    \78\ 80 FR 80139, 80149, 80150 (Dec. 23, 2015).
---------------------------------------------------------------------------

(3) Automated Scanning and Authenticated Scanning
    No commenters disagreed with the proposed requirement for 
vulnerability testing to include automated

[[Page 64283]]

vulnerability scanning. In light of ICE's suggestion that the proposed 
requirement for automated scanning to include authenticated scanning 
could increase costs, burdens, and risks while having limited utility 
for DCMs, SEFs, and SDRs, the Commission has decided to remove the 
authenticated scanning requirement from the final rule. Instead, the 
final rule provides that automated vulnerability scanning must follow 
best practices. The Commission notes that, to the extent that best 
practices require or come to require authenticated scanning, such 
scanning would be mandatory pursuant to the requirement to follow best 
practices, and would be addressed in system safeguards examinations.
(4) Vulnerability Testing by Independent Contractors
    The Commission has carefully considered the multiple comments 
suggesting that use of independent contractors for vulnerability 
testing could undesirably increase risks, raise hazards for automated 
systems, and increase costs and dangers without adding value. The 
Commission has also noted the comment that vulnerability testing 
conducted by employees not responsible for development or operation of 
the systems or capabilities tested has been proven effective, provides 
expertise valuable in vulnerability testing, and promotes an 
organizational culture of cybersecurity awareness. For these reasons, 
and in order to reduce costs and burdens to the extent practicable 
while still achieving the purposes of the CEA and of the NPRM, the 
final rule does not include the proposed requirement for covered DCMs 
and SDRs to have some vulnerability testing conducted by independent 
contractors. Instead, the final rule permits all DCMs, SEFs, and SDRs 
to conduct all required vulnerability testing by using either 
independent contractors or entity employees not responsible for 
development or operation of the systems or capabilities being tested. 
The Commission acknowledges the value of DDR's recommendation that 
independent contractors evaluate the effectiveness of the regulatee's 
vulnerability testing procedures and their consistency with best 
practices. While the final rule's vulnerability testing provisions will 
not incorporate such a requirement, the Commission observes that such 
independent validation of vulnerability testing procedures should 
likely be included as part of a regulatee's controls testing program.
3. External Penetration Testing--Sec. Sec.  37.1401(h)(3), 
38.1051(h)(3), and 49.24(j)(3)
a. Proposed Rule
    The NPRM called for all DCMs, SEFs, and SDRs to conduct external 
penetration testing of a scope sufficient to satisfy the requirements 
in the proposed rule.\79\ It proposed requiring all such entities to 
conduct external penetration testing at frequency determined by an 
appropriate risk analysis, with a minimum frequency requirement of 
annual external penetration testing for covered DCMs and SDRs.\80\ The 
NPRM called for covered DCMs and SDRs to engage independent contractors 
to conduct the annual external penetration test required of them.\81\ 
It provided that all other external penetration testing by covered DCMs 
and SDRs, and all external penetration testing by non-covered DCMs and 
SEFs, should be conducted either by independent contractors or by 
employees not responsible for development or operation of the systems 
or capabilities being tested.\82\
---------------------------------------------------------------------------

    \79\ 80 FR 80139, 80152 (Dec. 23, 2015).
    \80\ Id. at 80152, 80153.
    \81\ Id. at 80153.
    \82\ Id. at 80152, 80153.
---------------------------------------------------------------------------

b. Comments Received
(1) Requirement for External Penetration Testing
    Commenters raised no issue with the NPRM's call for external 
penetration testing. CME noted that penetration testing is a 
significant component of the program to identify and minimize sources 
of operational risk required of all DCMs, SEFs, and SDRs. CME also 
approved the flexibility concerning penetration test design provided in 
the NPRM. Nadex noted its agreement with the NPRM's penetration testing 
requirement.
(2) External Penetration Testing Frequency
    Commenters also raised no issue with the requirement for all DCMs, 
SEFs, and SDRs to conduct external penetration testing at a frequency 
determined by appropriate risk analysis. CME noted that many risk based 
factors should inform the frequency of such testing. Several commenters 
also supported the annual minimum frequency requirement for external 
penetration testing by covered DCMs and SDRs. CME stated that annual 
external penetration testing generally will be appropriate, ICE stated 
that it agrees with the annual requirement, and Nadex agreed with the 
NPRM's penetration testing requirements. MGEX called for the final rule 
to leave the frequency of external penetration testing to be determined 
by regulatees. ICE argued that regulatees should not be subject to a 
formal risk assessment to potentially determine a higher penetration 
testing frequency.
(3) External Penetration Testing by Independent Contractors
    Most commenters raised no issue with the requirement for covered 
DCMs and SDRs to have the required annual external penetration test 
conducted by independent contractors. DDR commented generally that an 
SDR should have flexibility regarding whether to have testing conducted 
by independent contractors or employees not responsible for development 
or operation of the systems or capabilities tested, based on the risks 
of that SDR.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
external penetration testing. For the reasons discussed below, the 
final rule will include the NPRM provisions regarding such testing as 
proposed.
(1) Requirement for External Penetration Testing
    The Commission agrees with commenters that external penetration 
testing is a significant and essential component of an effective 
program of system safeguards risk analysis and oversight. Such testing 
is an essential means of fulfilling the testing requirement in the 
Commission's current system safeguards rules.
(2) External Penetration Testing Frequency
    The Commission agrees with the comment that many risk based factors 
should inform the frequency of external penetration testing, and notes 
that this is true for all DCMs, SEFs, and SDRs. The Commission also 
agrees with the comments supporting the minimum frequency requirement 
of annual external penetration testing by covered DCMs and SDRs. As 
noted in the NPRM, this requirement is supported by generally accepted 
standards and best practices, which make it clear that such testing at 
least annually is essential to adequate system safeguards in today's 
cybersecurity environment. For this reason, the Commission disagrees 
with the suggestion that the frequency of such testing by covered DCMs 
and SDRs should be left to determination by those entities themselves. 
The proposal's minimum requirement was for a single

[[Page 64284]]

annual test; although, as noted in the NPRM, adequate risk analysis 
could well require more frequent testing in light of the risks faced by 
a particular regulatee.\83\ A separate, formal risk analysis made for 
the specific purpose of determining external penetration testing 
frequency is not required. Rather, external penetration testing is 
required as often as indicated by the ongoing, appropriate risk 
analysis inherent in a regulatee's statutorily-required program of risk 
analysis and oversight, conducted in light of generally accepted 
standards and best practices.
---------------------------------------------------------------------------

    \83\ Id. at 80152.
---------------------------------------------------------------------------

(3) External Penetration Testing by Independent Contractors
    In determining the final rule's provisions regarding external 
penetration testing by independent contractors, the Commission has 
noted that, as set forth above, most commenters raised no issue with 
this requirement for covered DCMs and SDRs. As noted in the NPRM, 
generally accepted standards and best practices make it clear that 
independent testing by third party service providers is an essential 
component of an adequate testing regime, and that this is notably the 
case with respect to penetration testing.\84\ The Commission believes 
that the independent viewpoint and approach provided by independent 
contractors, who can conduct a penetration test from the perspective of 
an outside adversary uncolored by insider assumptions or blind spots, 
will benefit covered DCM and SDR programs of risk analysis and 
oversight. Independent contractor penetration testing will strengthen 
Commission oversight of system safeguards, by providing an important, 
credible third source of information in addition to what is available 
from covered DCM or SDR staff and from the internal audit function of 
those entities. In light of these considerations, the Commission 
disagrees with the comments suggesting elimination of the requirement 
for the minimum annual external penetration test of a covered DCM or 
SDR to be conducted by independent contractors.
---------------------------------------------------------------------------

    \84\ Id. at 80153.
---------------------------------------------------------------------------

4. Internal Penetration Testing--Sec. Sec.  37.1401(h)(4), 
38.1051(h)(4), and 49.24(j)(4)
a. Proposed Rule
    The NPRM called for all DCMs, SEFs, and SDRs to conduct internal 
penetration testing of a scope sufficient to satisfy the requirements 
in the proposed rule.\85\ It proposed requiring all such entities to 
conduct external penetration testing at a frequency determined by an 
appropriate risk analysis, with a minimum frequency requirement of 
annual internal penetration testing for covered DCMs and SDRs.\86\ The 
NPRM provided that all internal penetration testing by DCMs, SEFs, or 
SDRs should be conducted either by independent contractors or by 
employees not responsible for development or operation of the systems 
or capabilities being tested.\87\
---------------------------------------------------------------------------

    \85\ 80 FR 80139, 80152 (Dec. 23, 2015).
    \86\ Id. at 80152, 80153.
    \87\ Id.
---------------------------------------------------------------------------

b. Comments Received
(1) Requirement for Internal Penetration Testing
    Commenters raised no issue with the NPRM's call for internal 
penetration testing. As noted above concerning external penetration 
testing, CME noted that penetration testing generally is a significant 
component of the program to identify and minimize sources of 
operational risk required of all DCMs, SEFs, and SDRs, and approved the 
flexibility concerning penetration test design provided in the NPRM. 
Also as noted above, Nadex stated its agreement with the NPRM's 
penetration testing requirements.
(2) Internal Penetration Testing Frequency
    Commenters also raised no issue with the requirement for all DCMs, 
SEFs, and SDRs to conduct internal penetration testing at a frequency 
determined by appropriate risk analysis. As noted above, CME stated 
that many risk based factors should inform the frequency of penetration 
testing generally. With respect to the requirement for covered DCMs and 
SDRs to conduct internal penetration testing at least annually, ICE 
stated agreement with the proposal. Nadex agreed with the proposed 
penetration testing requirements generally. On the basis that that 
there is a scarcity of potential employees with the skill set required 
to conduct internal penetration testing without introducing risks into 
the production environment and other sensitive environments, CME 
suggested making annual internal penetration testing an objective 
rather than a requirement, so that covered DCMs and SDRs can prioritize 
truly effective testing over less skilled testing done merely to 
satisfy the annual requirement. As noted above, MGEX called for the 
final rule to leave the frequency of penetration testing to be 
determined by regulatees. ICE argued that regulatees should not be 
subject to a formal risk assessment to potentially determine a higher 
penetration testing frequency.
(3) Who Should Perform Internal Penetration Testing
    Commenters raised no issue with the NPRM provision giving all DCMs, 
SEFs, and SDRs the choice of whether to have internal penetration 
testing performed by independent contractors or by employees not 
responsible for development or operation of the systems or capabilities 
tested.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
internal penetration testing. For the reasons discussed below, the 
final rule will include the NPRM's internal penetration testing 
provisions as proposed.\88\
---------------------------------------------------------------------------

    \88\ 80 FR 80139, 80152, 80153 (Dec. 23, 2015).
---------------------------------------------------------------------------

(1) Requirement for Internal Penetration Testing
    The Commission agrees with commenters that external penetration 
testing is a significant and essential component of an effective 
program of system safeguards risk analysis and oversight. Such testing 
is an essential means of fulfilling the testing requirement in the 
Commission's current system safeguards rules.
(2) Internal Penetration Testing Frequency
    The Commission agrees with the comment that many risk based factors 
should inform the frequency of internal penetration testing, and notes 
that this is true for all DCMs, SEFs, and SDRs. It also agrees with the 
comments supporting the minimum frequency requirement of annual 
internal penetration testing by covered DCMs and SDRs. As noted in the 
NPRM, this requirement, like the parallel requirement regarding 
external penetration testing, is supported by generally accepted 
standards and best practices, which make it clear that such testing at 
least annually is essential to adequate system safeguards in today's 
cybersecurity environment.\89\ Accordingly, the Commission disagrees 
with the suggestions that annual internal penetration testing by 
covered DCMs and SDRs should be a mere objective, or that the frequency 
of such testing by covered DCMs and SDRs should be left to 
determination by those entities themselves. The Commission also notes, 
as it stated in the NPRM, that

[[Page 64285]]

adequate risk analysis could well require more frequent testing in 
light of the risks faced by a particular regulatee.\90\ A separate, 
formal risk analysis made for the specific purpose of determining 
internal penetration testing frequency is not required. Rather, 
internal penetration testing is required as often as indicated by the 
ongoing, appropriate risk analysis inherent in a regulatee's required 
program of risk analysis and oversight, conducted in light of generally 
accepted standards and best practices.
---------------------------------------------------------------------------

    \89\ Id.
    \90\ Id.
---------------------------------------------------------------------------

(3) Who Should Perform Internal Penetration Testing
    The Commission continues to believe, as provided in the NPRM, that 
it is appropriate to give all DCMs, SEFs, and SDRs the choice of 
whether to have internal penetration testing performed by independent 
contractors or by employees not responsible for development or 
operation of the systems or capabilities tested.\91\ Commenters raised 
no issue with this provision.
---------------------------------------------------------------------------

    \91\ Id. at 80153.
---------------------------------------------------------------------------

5. Controls Testing--Sec. Sec.  37.1401(h)(5), 38.1051(h)(5), and 
49.24(j)(5)
a. Proposed Rule
    The NPRM called for each DCM, SEF, and SDR to conduct controls 
testing of a scope sufficient to satisfy the scope requirements in the 
proposed rule, including testing of each control included in the 
entity's program of risk analysis and oversight.\92\ It proposed each 
such entity to conduct controls testing at frequency determined by an 
appropriate risk analysis, with a minimum frequency requirement for 
covered DCMs and SDRs calling for testing of all controls every two 
years.\93\ The NPRM provided that covered DCMs and SDRs could conduct 
such testing on a rolling basis over the minimum two-year period or 
over the minimum period determined by appropriate risk analysis, 
whichever is shorter.\94\ The NPRM called for covered DCMs and SDRs to 
engage independent contractors to conduct testing of key controls no 
less frequently than every two years.\95\ It provided that all other 
controls testing by covered DCMs and SDRs, and all controls testing by 
non-covered DCMs and SEFs, should be conducted either by independent 
contractors or by employees not responsible for development or 
operation of the systems or capabilities being tested.\96\
---------------------------------------------------------------------------

    \92\ Id. at 80153, 80154.
    \93\ Id. at 80154.
    \94\ Id.
    \95\ Id.
    \96\ Id. at 80154, 80155.
---------------------------------------------------------------------------

b. Comments Received
(1) Requirement for Controls Testing
    CME and Nadex approved of the NPRM's call for controls testing. CME 
stated that the NPRM correctly identified controls testing as a crucial 
part of a program of risk analysis and oversight, and agreed with the 
categories which the current rules and the NPRM specify as included in 
such a program. CME also agreed with the NPRM's flexible approach to 
using best practices to inform the design and implementation of 
controls testing in light of risk analysis. ICE called for the final 
rule to eliminate the requirement for controls testing, arguing that 
many controls do not require testing, that few organizations have a 
static universe of controls, and that control weaknesses will come to 
light in vulnerability and penetration testing. Tradeweb asked the 
Commission to provide further guidance on how controls testing differs 
from vulnerability testing, whether Service Organization Controls 
(``SOC'') 1 and 2 reports prepared in accordance with the American 
Institute of Certified Public Accountants' Statement on Standards for 
Attestation Engagements (``SSAE'') Number 16 could be used for controls 
testing purposes, and whether penetrations tests could be used to 
fulfill controls testing requirements.
(2) Controls Testing Frequency
    Regarding the minimum controls testing frequency of every two years 
proposed for covered DCMs and SDRs, CME commented that some less 
critical controls do not warrant testing on a two-year cycle, and cited 
best practices permitting controls testing on a three-year cycle. CME 
suggested that the final rule should call for the minimum controls 
testing frequency for covered DCMs and SDRs to be determined by risk 
analysis (as the NPRM proposed for non-covered DCMs and SEFs), or 
alternatively that a minimum frequency cycle of three years would be a 
reasonable alternative to the NPRM's proposed two-year cycle. CME 
suggested that, while many organizations will implement a two-year 
schedule for at least the testing of key controls, either of CME's 
proposed alternatives would make controls testing more cost effective, 
and increase focus on the most critical controls.
(3) Who Should Perform Controls Testing
    CME commented that effective testing of key controls can be done by 
employees not responsible for development or operation of the controls 
tested, as well as by independent contractors, and that such 
independent employees' familiarity with the organization's controls can 
improve the efficiency and effectiveness of controls testing. 
Accordingly, CME suggested that, while independent contractor controls 
testing may be beneficial, the final rule should not exclude controls 
testing by independent employees, for example employees such as 
internal audit staff. DDR also commented that, where the NPRM proposed 
to require independent contractor testing, the final rule should give 
flexibility to use either independent contractors or independent 
employees. ICE suggested that the final rule should not require key 
controls testing at all. In support, ICE argued that the concept of key 
controls is not universally adopted; that risk analysis relies on 
testing of all controls in concert; that a testing requirement directed 
at key controls could result in organizations documenting fewer 
controls; and that the key controls testing proposal would impose a 
large burden for little or no practical improvement in security. MGEX 
stated that the NPRM required testing of all controls on a rolling 
basis by independent contractors every two years.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
controls testing. For the reasons discussed below, the Commission is 
adopting the NPRM's requirement for all DCMs, SEFs, and SDRs to conduct 
testing of all their system safeguards-related controls, its 
requirement for such testing by all such entities to be conducted as 
often as indicated by appropriate risk analysis, and its requirement 
for independent contractor testing of the key controls of covered DCMs 
and SDRs. However, for the reasons discussed below concerning controls 
testing frequency, the Commission is modifying the proposed controls 
testing minimum frequency requirement for covered DCMs and SDRs, to 
call for testing of their key controls--including independent 
contractor testing of such controls--within a three-year rather than a 
two-year period.

[[Page 64286]]

(1) Requirement for Controls Testing
    The Commission agrees with commenters that controls testing is a 
crucial part of a program of risk analysis and oversight and that best 
practices should inform the design and implementation of controls 
testing in light of risk analysis. 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. The 
Commission disagrees with the suggestion that the final rule should not 
require any controls testing. As noted in the NPRM, generally accepted 
standards and best practices call for such testing.\97\ Moreover, in 
conducting oversight of system safeguards, Commission staff have found 
a significant number of instances, at both larger and smaller entities, 
where (a) system malfunctions, market halts, and the success of cyber 
intrusions were caused by failures of both key and non-key controls; 
(b) such problems could have been prevented had the controls in 
question been tested; and (c) testing of the relevant controls had been 
entirely omitted or not done for substantial periods of time. The 
controls testing requirement set out in the NPRM is designed to remedy 
such situations, and ensure that controls testing by all DCMs, SEFs, 
and SDRs follows best practices. By design, the NPRM did not prescribe 
the design of the overall program of controls testing or the particular 
tests it may include. Various forms of testing, including vulnerability 
testing, penetration testing, SSAE16 SOC1 or SOC2 assessments, and 
others, may well contribute in varying degrees--subject to their 
particular natures and limitations--to an overall program for the 
testing of controls as called for by the NPRM. The Commission notes 
that the depth and coverage of a single assessment may not be 
sufficient to meet the final rule's testing scope requirements 
discussed below. It also notes that the proposed controls testing 
requirement gives DCMs, SEFs, and SDRs the flexibility to determine the 
appropriate combination of testing methods and techniques necessary to 
determine whether their controls are implemented correctly, operating 
as intended, and enabling them to meet the system safeguards 
requirements of the Commission's rules.
---------------------------------------------------------------------------

    \97\ 80 FR 80139, 80152 (Dec. 23, 2015).
---------------------------------------------------------------------------

(2) Controls Testing Frequency
    The Commission has noted the best practices cited by CME supporting 
controls testing on a three-year cycle. After due consideration, the 
Commission agrees that a three-year rather than two-year minimum 
controls testing frequency requirement for covered DCMs and SDRs may 
reduce costs and burdens, while providing beneficial flexibility in 
overall controls testing program design and still ensuring that the 
fundamental purposes of the CEA and the Commission's system safeguards 
rules are achieved. The NPRM called for covered DCMs and SDRs, as well 
as non-covered DCMs and SEFs, to conduct controls testing as frequently 
as appropriate risk analysis requires.\98\ The Commission notes that 
this fundamental frequency requirement could well require a controls 
testing cycle shorter than three years, as acknowledged in the comment 
on this point. In light of these considerations, the final rule 
requires all DCMs, SEFs, and SDRs to test the controls included in 
their programs of risk analysis and oversight as frequently as 
appropriate risk analysis requires. At a minimum, it will require 
covered DCMs and SDRs to conduct the required key controls testing--
including key controls testing by independent contractors as discussed 
below--no less frequently than every three years. As proposed in the 
NPRM, it will permit covered DCMs and SDRS to conduct such testing on a 
rolling basis, but require this to be done over the course of the 
minimum period or the period determined by an appropriate risk 
analysis, whichever is shorter.
---------------------------------------------------------------------------

    \98\ 80 FR 80139, 80154 (Dec. 23, 2015).
---------------------------------------------------------------------------

(3) Who Should Perform Controls Testing
    The Commission agrees with the comments noting that testing of key 
controls by both independent contractors and employees not responsible 
for development or operation of the controls tested can be valuable and 
effective. As noted in the NPRM, best practices recognize the value of, 
and recommend, both such approaches.\99\ The Commission notes that the 
NPRM did not propose barring covered DCM or SDR employees from testing 
key controls; rather, it proposed that covered DCM and SDR testing of 
key controls include independent contractor testing of all such 
controls within the minimum period. As with penetration testing, the 
Commission believes that independent contractor testing of key controls 
will strengthen covered DCM and SDR programs of risk analysis and 
oversight, by providing a valuable outsider perspective concerning 
crucial safeguards uncolored by insider assumptions or blind spots. The 
Commission further believes that independent contractor testing of key 
controls will strengthen Commission oversight of system safeguards, by 
providing an important, credible third source of information concerning 
crucial safeguards in addition to what is available from covered DCM or 
SDR staff and from the internal audit function of those entities. As 
noted above, because best practices call for controls testing, the 
Commission disagrees with the comment suggesting that the final rule 
should not require testing of key controls by either independent 
contractors or employees. The NPRM did not require independent 
contractor testing of all controls, but rather required independent 
contractor testing of the key controls of covered DCMs and SDRs.\100\
---------------------------------------------------------------------------

    \99\ Id. at 80154, 80155.
    \100\ Id.
---------------------------------------------------------------------------

6. Security Incident Response Plan Testing--Sec. Sec.  37.1401(h)(6), 
38.1051(h)(6), and 49.24(j)(6)
a. Proposed Rule
    The NPRM called for each DCM, SEF, and SDR to conduct security 
incident response plan (``SIRP'') testing of a scope sufficient to 
satisfy the scope requirements in the proposed rule.\101\ It called for 
each such entity's SIRP to include, without limitation, the entity's 
definition and classification of security events, its policies and 
procedures for reporting and communicating internally and externally 
concerning security incidents, and the hand-off and escalation points 
in its security incident response process.\102\ It proposed permitting 
each such entity to coordinate its SIRP testing with its BC-DR plan or 
other testing required by the applicable system safeguards rules.\103\ 
The NPRM proposed requiring all DCMs, SEFs, and SDRs to conduct SIRP 
testing at a frequency determined by an appropriate risk analysis, with 
a minimum frequency requirement of annual SIRP testing for covered DCMs 
and SDRs.\104\ Finally, the NPRM called for all DCMs, SEFs, and SDRs to 
have SIRP testing conducted by either independent contractors or 
employees not responsible for development or operation of the systems 
or capabilities tested.\105\
---------------------------------------------------------------------------

    \101\ Id. at 80155 through 80157.
    \102\ Id.
    \103\ Id. at 80157.
    \104\ Id.
    \105\ Id.

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

[[Page 64287]]

b. Comments Received
(1) Requirement To Maintain and Test a SIRP
    Several commenters agreed with the NPRM's call for each DCM, SEF, 
and SDR to maintain and test a SIRP meeting the requirements in the 
proposal. CME called SIRPs an important tool for all entities in their 
efforts to be ready to face inevitable cyber attacks. CME noted its 
appreciation for the proposal's flexibility for entities to design 
their SIRP testing in light of their risk analysis, and for the 
proposal's approval of coordination of SIRP testing with other types of 
testing. ICE and Nadex also stated support for the NPRM's SIRP testing 
provision. However, while Tradeweb stated that having a SIRP is 
essential to the functioning of a SEF, it argued that the SIRP testing 
requirement should be reduced to annual review and approval of the SIRP 
by a SEF employee responsible for information security.
(2) SIRP Testing Frequency
    No commenters expressed disagreement with the proposed requirement 
for all DCMs, SEFs, and SDRs to conduct SIRP testing as often as 
indicated by appropriate risk analysis. Regarding the proposed 
requirement for covered DCMs and SDRs to test their SIRPs once a year 
at a minimum, CME commented that at least annual SIRP testing is 
appropriate in today's cybersecurity environment.
(3) Who Should Conduct SIRP Testing
    No commenters expressed disagreement with the proposed general 
requirement giving DCMs, SEFs, and SDRs the choice of whether to have 
SIRP testing conducted by independent contractors or employees. 
However, CME suggested that the final rule should permit SIRP testing 
to be led by an independent employee who is not responsible for 
development or operation of what is tested but who is responsible for 
design of the SIRP itself. CME stated that this would allow the entity 
to leverage its employees with expertise in crisis and risk management 
and in incident response and planning, for both planning and testing 
purposes, in a way that is optimal for the entity's system safeguards.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
SIRP testing. For the reasons discussed below, the Commission is 
adopting the proposed requirements for each DCM, SEF, and SDR to 
maintain a SIRP (as defined and described) and test it as often as 
indicated by appropriate risk analysis, and the proposed requirement 
for each covered DCM and SDR to conduct SIRP testing at least annually. 
It is modifying the proposed provisions regarding who may conduct SIRP 
testing, to permit testing to be led or conducted either by independent 
contractors or by any entity employee.
(1) Requirement To Maintain and Test a SIRP
    The Commission agrees with commenters that maintaining and testing 
a SIRP is important for effective system safeguards in today's 
cybersecurity environment. The Commission confirms that the proposed 
SIRP testing requirement is indeed intended to give DCMs, SEFs, and 
SDRs flexibility concerning the format and design of their SIRP 
testing, and concerning its coordination with other types of testing, 
so long as the entity's SIRP testing is consonant with appropriate risk 
analysis and enables fulfillment of the proposed scope requirements. 
The Commission disagrees with the suggestion that the requirement to 
test the SIRP should be reduced to mere annual review and approval of 
the SIRP by an employee responsible for information security. As noted 
in the NPRM, best practices emphasize that SIRP testing is crucial to 
effective cyber incident response in today's cybersecurity 
environment.\106\ Failure to practice the cyber incident response 
process can delay or paralyze timely response and cause severe 
consequences.
---------------------------------------------------------------------------

    \106\ 80 FR 80139, 80155 through 80156 (Dec. 23, 2015).
---------------------------------------------------------------------------

(2) SIRP Testing Frequency
    The Commission notes that no commenters disagreed with the 
requirement to conduct SIRP testing as often as indicated by 
appropriate risk analysis, and agrees with the comment that at least 
annual SIRP testing is appropriate for covered DCMs and SDRs in today's 
cybersecurity environment.
(3) Who Should Conduct SIRP Testing
    The Commission has considered the suggestion that allowing SIRP 
testing to be led by an employee responsible for design of the SIRP 
itself could improve system safeguards in general and SIRP testing in 
particular. The Commission believes that this could provide useful 
benefits and flexibility to DCMs, SEFs, and SDRs, without impairing the 
purposes of the CEA and the Commission's regulations which SIRP testing 
is designed to advance. In addition, SIRP testing differs from the 
other types of testing specified in the final rule, in that what is 
tested is not automated systems but the security incident response plan 
itself, or in other words what people do if a security incident 
happens. Accordingly, the final rule calls for SIRP testing by all 
DCMs, SEFs, and SDRs to be conducted by either independent contractors 
or employees, without restricting which employees may lead or conduct 
the testing.
7. Enterprise Technology Risk Assessment--Sec. Sec.  37.1401(h)(7), 
38.1051(h)(7), and 49.24(j)(7)
a. Proposed Rule
    The NPRM called for each DCM, SEF, and SDR to conduct enterprise 
technology risk assessment (``ETRA'') of a scope sufficient to satisfy 
the scope requirements in the proposed rule.\107\ It called for each 
DCM, SEF, and SDR to conduct an ETRA as often as required by 
appropriate risk analysis, and for covered DCMs and SDRs to do this at 
least annually.\108\ It stated that all regulatees could conduct ETRAs 
by using independent contractors or employees not responsible for 
development or operation of the systems or capabilities being 
assessed.\109\
---------------------------------------------------------------------------

    \107\ Id. at 80157 through 80159.
    \108\ Id. at 80158.
    \109\ Id. at 80158, 80159.
---------------------------------------------------------------------------

b. Comments Received
(1) ETRA Requirement
    CME agreed that regular risk assessments should drive ongoing 
efforts to address cyber risks. Nadex stated its general agreement with 
the proposed ETRA requirement. ICE argued that the ETRA requirement is 
already adequately addressed by current Commission rules, and called 
for omission of the ETRA requirement in the final rule. ICE also argued 
that the proposed ETRA requirement is not cyber-specific and does not 
focus on the confidentiality, availability, or integrity of data. 
Tradeweb agreed that assessment of technology risks is essential, but 
argued that the ETRA requirement is duplicative of the other proposed 
testing requirements.
(2) ETRA Frequency and Scope
    CME suggested that ETRAs would benefit from incorporating the 
results of controls testing and other testing, and suggested that it 
would be beneficial and less costly to align the requirement for 
completing an ETRA with the applicable frequency requirement for 
controls testing. Nadex requested clarification of whether the ETRA 
could incorporate the results of other required

[[Page 64288]]

testing as reported to management and the board of directors, or 
whether a full stand-alone assessment is required. Tradeweb suggested 
that an annual full assessment would be burdensome and costly, and 
suggested that, in lieu of repeated full assessments, annual review and 
approval of previous assessments should be sufficient.
(3) Who Should Conduct ETRAs
    No commenters expressed disagreement with the NPRM provision 
calling for ETRAs to be conducted by either independent contractors or 
employees not responsible for development or operation of the systems 
or capabilities assessed. ICE suggested that ETRAs should be carried 
out by enterprise risk program staff rather than information security 
staff.
c. Final Rule
    The Commission has considered and evaluated the comments concerning 
ETRAs. For the reasons discussed below, the Commission is adopting the 
proposed requirements, but is adding a provision in the final rule 
stating that a DCM, SEF, or SDR that has conducted an enterprise 
technology risk assessment as required may conduct subsequent 
assessments by updating the previous assessment.
(1) ETRA Requirement
    The Commission agrees with the comment that regular risk 
assessments should drive ongoing efforts to address cyber risks. The 
Commission continues to believe that conducting regular ETRAs is 
essential to meeting the testing requirements of its current system 
safeguards rules and maintaining system safeguards resiliency in 
today's cybersecurity environment. Regular, ongoing identification, 
estimation, and prioritization of risks that could result from 
impairment of the confidentiality, integrity, or availability of data 
and information or the reliability, security, and capacity of automated 
systems is crucial to effective system safeguards. As noted in the 
NPRM, regular performance of ETRAs is a well-established best 
practice.\110\ The proposed ETRA requirement is designed to provide an 
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 addition to other methods of risk identification, in order to 
identify and mitigate its system safeguards-related risks. ETRAs can 
also inform the design of the other types of testing. As such, the ETRA 
requirement it is not duplicative of the other testing requirements, 
but rather an enhancement of their value. The Commission also notes 
that, as discussed above, multiple NPRM provisions to be adopted in the 
final rule call for determinations made in light of the appropriate 
risk analysis that is required by the CEA. Accordingly, a regulatee's 
current ETRA summarizing in writing both its analysis of its system 
safeguards risks and the basis for that analysis and for the entity's 
system safeguards decisions will be a key tool for Commission 
determination of the adequacy of the entity's compliance with system 
safeguards requirements. The Commission therefore disagrees with the 
suggestion that the final rule should omit the ETRA requirement.
---------------------------------------------------------------------------

    \110\ Id. at 80158.
---------------------------------------------------------------------------

(2) ETRA Frequency and Scope
    While the Commission agrees that the results of other types of 
testing can usefully inform ETRAs, the Commission believes that, as 
best practices provide, regularly updated ETRAs are crucial to the 
effectiveness of system safeguards in today's rapidly changing 
cybersecurity environment. The Commission therefore does not accept the 
suggestion that ETRAs should only be required as often as a complete 
cycle of controls testing is completed, not least because the final 
rule is adopting the suggestion to lengthen that cycle to three rather 
than two years. The Commission reiterates that the results of other 
required forms of system safeguards testing can and should be 
incorporated in ETRAs, and in turn should be informed and driven by 
ETRAs. Because ETRAs that provide current assessment of current risks 
are essential to effective programs of system safeguards risk analysis 
and oversight, as discussed above, the Commission disagrees with the 
suggestion that annual review and reapproval of previous assessments 
would be sufficient. However, the Commission believes that thorough 
updating of a previous assessment conducted in compliance with the ETRA 
requirements set out in the NPRM can be sufficient to fulfill the 
purposes of an appropriate ETRA, and can reduce costs and burdens 
without impairment of the purposes of the CEA and the system safeguards 
rules. Accordingly the final rule clarifies that such updating of a 
previous fully compliant ETRA, in light of current risks and 
circumstances, can fulfill the ETRA requirement. The Commission 
emphasizes that best practices require all DCMs, SEFs, and SDRs to 
conduct risk assessment and monitoring on an ongoing basis, as 
frequently as the entity's risks and circumstances require. The final 
rule requirement for covered DCMs and SDRs to prepare a written 
assessment on at least an annual basis does 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 minimum frequency 
requirement is intended to formalize the risk assessment process and 
ensure that it is documented at a minimum frequency.
(3) Who Should Conduct ETRAs
    The NPRM's call for ETRAs to be conducted by either independent 
contractors or employees not responsible for development or operation 
of the systems or capabilities assessed drew no objections from 
commenters. The Commission also notes that the NPRM did not prescribe 
whether enterprise risk program staff, information security staff, or 
both should conduct ETRAs, but deliberately left flexibility to DCMs, 
SEFs, and SDRs in this regard, so long as the employees conducting the 
ETRA have the independence specified.

F. Scope of Testing and Assessment--Sec. Sec.  37.1401(k), 38.1051(k), 
and 49.24(l)

1. Proposed Rule
    The NPRM called for the scope of all system safeguards testing and 
assessment to 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 to take any of 
a number of undesirable actions.\111\ These actions were specified to 
include interfering with the regulatee's operations or fulfillment of 
its statutory and regulatory responsibilities; impairing or degrading 
the reliability, security, or capacity of the regulatee's automated 
systems; adding to, deleting, modifying, exfiltrating, or compromising 
the integrity of data; or taking any other unauthorized action 
affecting the regulatee's regulated activities or the hardware or 
software used in connection with them.\112\
---------------------------------------------------------------------------

    \111\ 80 FR 80139, 80159 (Dec. 23, 2015).
    \112\ Id.
---------------------------------------------------------------------------

2. Comments Received
    A number of commenters suggested that the scope provisions of the 
NPRM were overbroad, and that the proposed requirement to perform 
``all'' testing necessary to identify ``any'' vulnerability was 
impossible to achieve in practice. CME argued that it is infeasible to 
conduct testing to identify

[[Page 64289]]

``any'' potential vulnerability, and called for the final rule to 
provide that testing scope should be risk-based, to enable focus on the 
most likely scenarios and highest value information assets. CME 
suggested that the NPRM's overbroad scope provision could impose 
outsized costs without yielding commensurate benefits. ICE stated that 
it is impossible to predict and test for all cyber attack scenarios. 
Nadex agreed with the general thrust of the proposed scope provision, 
but argued that the requirement to identify ``any'' vulnerability was 
too broad, and that it is unrealistic and likely impossible to 
guarantee testing that could provide 100 percent security against all 
vulnerabilities or unauthorized actions. WMBAA stated concern that the 
proposed scope provision would set a standard impracticable for 
regulatees to achieve, because no regulatee could guarantee that 
``any'' vulnerability would be uncovered by testing, and because it is 
impracticable to test all potential avenues for penetrating regulatee 
systems. WMBAA questioned whether any penetration testing firm would be 
willing to certify that its testing procedures met such a standard. 
Nadex, CFE, Tradeweb, and WMBAA suggested that the NPRM scope provision 
could be read as imposing a strict liability standard under which any 
successful cyber attack would mean a violation of the testing scope 
provisions must have occurred. CME, Nadex, CFE, DDR, Tradeweb, and 
WMBAA requested that the Commission consider establishing ``safe 
harbor'' provisions under which an entity that has made good faith 
efforts to adhere to one or more designated cybersecurity frameworks or 
statements of cybersecurity best practices would be deemed to be in 
compliance with the system safeguards rules. Nadex called for the final 
rule scope provision to limit responsibility to a reasonableness 
standard. Nadex also asked the Commission to clarify that the current 
cybersecurity threat analysis a regulatee should consider in assessing 
potential cyber adversary capabilities to determine testing scope is 
limited to the organization's internal risk assessments.
3. Final Rule
    The Commission has considered and evaluated the comments concerning 
the testing scope provision of the NPRM.\113\ For the reasons discussed 
below, the Commission is modifying the scope provision in the final 
rule to call for the scope of testing to be based on appropriate risk 
and threat analysis.
---------------------------------------------------------------------------

    \113\ 80 FR 80139, 80159 (Dec. 23, 2015).
---------------------------------------------------------------------------

    The Commission does not intend the scope provision of the testing 
rule to create any sort of strict liability standard with respect to 
system safeguards testing. On the contrary, the Commission recognizes 
that in today's cybersecurity environment no entity can be expected to 
be immune from cyber intrusions. As noted in the NPRM, one fundamental 
goal of the Commission's system safeguards and cybersecurity testing 
rules is enhancing regulatees' ability to detect, contain, respond to, 
and recover from cyber intrusion when they happen.\114\ In conducting 
oversight of the system safeguards of DCMs, SEFs, and SDRs, the 
Commission looks and will continue to look to what a reasonable and 
prudent DCM, SEF, or SDR would do with respect to system safeguards in 
light of generally accepted standards and best practices, and in light 
of informed risk analysis appropriate to the circumstances and risks 
faced by the DCM, SEF or SDR in question. The Commission does not 
believe that the mere fact that a DCM, SEF, or SDR has suffered a cyber 
intrusion means that that entity has failed to comply with system 
safeguards rules. The Commission would be concerned when examination 
shows that a DCM, SEF, or SDR failed to follow the best practices that 
a reasonable entity in its circumstances and facing its risks should 
follow.
---------------------------------------------------------------------------

    \114\ Id. at 80156.
---------------------------------------------------------------------------

    The Commission also recognizes that no program of cybersecurity 
testing can be expected to detect every possible vulnerability or 
avenue of intrusion. Here, too, the touchstone is what system 
safeguards testing a reasonable and prudent DCM, SEF, or SDR would 
conduct in light of generally accepted standards and best practices, 
and in light of informed risk analysis appropriate to the circumstances 
and risks faced by the DCM, SEF or SDR in question. The Commission 
evaluates, and will continue to evaluate, system safeguards testing in 
that light.
    Given today's rapidly changing cyber threat environment and the 
resulting continuous evolution of generally accepted standards and best 
practices with respect to system safeguards, the Commission does not 
believe it would be appropriate to label compliance with any one source 
of best practices as written at a particular point in time as a ``safe 
harbor'' with respect to system safeguards compliance. The Commission 
believes that the appropriate way to address the concerns underlying 
the comments seeking designation of such safe harbors is the standard 
discussed above: Reasonable and prudent system safeguards testing in 
light of generally accepted standards and best practices, and in light 
of informed risk analysis appropriate to the circumstances and risks 
faced by the DCM, SEF or SDR in question.
    The Commission disagrees with the comment asking confirmation that 
the current cybersecurity threat analysis a DCM, SEF, or SDR should 
consider in designing its system safeguards testing is limited to the 
organization's internal risk assessments. As noted in the NPRM, a DCM, 
SEF, or SDR acting as a reasonable and prudent regulatee would act in 
light of best practices and the current cybersecurity threat 
environment should obtain and consider threat analysis available from 
outside sources in addition to conducting its own threat analysis.
    For those reasons, the Commission agrees with the comments 
suggesting that the scope provisions of the final rule should call for 
testing scope to be based on appropriate risk and threat analysis. In 
order to provide the clarity requested by commenters, the final rule 
calls for the scope of system safeguards testing to include the testing 
that the regulatee's program of risk analysis and oversight and its 
current cybersecurity threat analysis indicate is necessary to identify 
risks and vulnerabilities that could enable the deleterious actions by 
intruders or unauthorized users listed in the scope provisions of the 
proposed rules. The Commission agrees with the comments suggesting that 
this approach will avoid imposing undue burdens and costs, while 
supporting the purposes of the CEA and the Commission's system 
safeguards rule.

G. Internal Reporting and Review--Sec. Sec.  37.1401(l), 38.1051(l), 
and 49.24(m)

1. Proposed Rule
    The NPRM called for DCM, SEF, and SDR senior management and boards 
of directors to receive and review reports setting forth the results of 
the testing and assessment required by the system safeguards 
rules.\115\ It also called for these entities to establish and follow 
procedures for remediation of issues identified through such review, 
and for evaluation of the effectiveness of testing and assessment 
protocols.\116\
---------------------------------------------------------------------------

    \115\ 80 FR 80139, 80160 (Dec. 23, 2015).
    \116\ Id.

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

[[Page 64290]]

2. Comments Received
a. Board and Senior Management Oversight
    Several commenters agreed with the NPRM's call for oversight of 
system safeguards and cybersecurity by boards of directors and senior 
management. CME and MGEX recognized the importance of effective board 
oversight and the need to keep the board and senior management up to 
date in this regard. DDR said it agreed with the Commission that active 
board and senior management supervision of system safeguards promotes 
more efficient, effective, and reliable risk management. However, ICE 
argued that internal reporting and review of test results should be 
limited to reports to senior management, and that boards of directors 
should not be required to review even high-level, high-priority test 
findings, but instead should only be apprised of enterprise-level high 
risk issues when identified thresholds (unspecified by ICE) are 
crossed.
b. Level of Detail for Board and Senior Management Review
    Commenters requested clarification concerning what level of detail 
the NPRM called for boards and senior management to review in terms of 
test results. ICE, MGEX, and Nadex noted that test result reports can 
be voluminous, technical, and complex, and that requiring boards and 
senior management to review each such document could produce an undue 
burden without commensurate benefits. MGEX and Nadex therefore asked 
the Commission to clarify in the final rule that what is required is 
board and management review of appropriate summaries and compilations 
of test and assessment results. DDR suggested it should be the 
regulatee's responsibility to provide the board and senior management 
with the level of test result information appropriate for enabling 
their effective oversight of system safeguards. DDR asked the 
Commission to confirm in the final rule that there are multiple ways 
this can be done. Nadex also asked the Commission to clarify that board 
consideration of test results in the course of regularly scheduled 
meetings would be an acceptable way of fulfilling this requirement.
3. Final Rule
    The Commission has considered and evaluated the comments concerning 
the internal reporting and review provision of the NPRM.\117\ For the 
reasons discussed below, the Commission is adopting the provision as 
proposed.
---------------------------------------------------------------------------

    \117\ 80 FR 80139, 80160 (Dec. 23, 2015).
---------------------------------------------------------------------------

a. Board and Senior Management Oversight
    The Commission agrees with the comments recognizing the importance 
of effective board of directors and senior management of system 
safeguards, and the resulting need to keep the board and senior 
management informed appropriately concerning the results of 
cybersecurity testing and assessment. In today's cybersecurity threat 
environment, active board and senior management supervision of system 
safeguards is essential to the enterprise-wide, effective risk 
management that the CEA and Commission regulations require of DCMs, 
SEFs, and SDRs. Such active supervision would be impossible if board 
members and senior managers were not appropriately apprised of the 
results of cybersecurity testing and assessment, and thus lacked an 
essential level of knowledge of the organization's system safeguards 
risks. As noted in the NPRM, generally accepted standards and best 
practices emphasize the importance of board and senior management 
oversight of cybersecurity, and make it clear that the absence of 
proactive board and senior management involvement in cybersecurity can 
make regulatees more vulnerable to successful cyber attacks.\118\ 
Accordingly, best practices call for directors to either have the 
appropriate level of experience and knowledge of information technology 
and related risks themselves or obtain the assistance of expert 
consultants in this regard. In the Commission's view, protection of the 
public interest and the economic security of the United States with 
respect to derivatives markets in today's cybersecurity threat 
environment demands no less. For these reasons, the Commission 
disagrees with the suggestion that boards of directors should not be 
involved in internal reporting and review of cybersecurity test 
results.
---------------------------------------------------------------------------

    \118\ 80 FR 80139, 80160 (Dec. 23, 2015).
---------------------------------------------------------------------------

b. Level of Detail for Board and Senior Management Review
    The Commission also agrees with the comments suggesting that test 
result reports can be voluminous, technical, and complex, and that 
effective board of directors and senior management oversight of system 
safeguards does not require board or senior management review of every 
detail of each such report. The Commission further agrees with the 
comments suggesting that DCMs, SEFs, and SDRs should provide their 
boards and senior management with a level of test result information 
that enables their effective, knowledgeable oversight of cybersecurity 
and system safeguards in light of the risks faced by their 
organizations. While the internal reporting and review provision of the 
final rule requires that the board receive and review test results, it 
does not prevent an organization from including additional, clarifying 
documents, such as executive summaries or compilations, with the 
required reports. Board and senior management review of appropriate 
summaries and compilations of test and assessment results can be an 
effective and acceptable way of fulfilling the internal reporting and 
review requirement, provided that such summaries give board members and 
senior management sufficiently detailed information to enable them to 
conduct effective and informed oversight. The appropriate level of 
information should also enable boards and senior management to fulfill 
this provision's requirement for them to evaluate the overall 
effectiveness of testing and assessment protocols, and direct and 
oversee appropriate remediation of issues identified through their 
review of test results. As noted in the NPRM, best practices call for 
boards and senior management to review the overall effectiveness of the 
testing program.\119\
---------------------------------------------------------------------------

    \119\ 80 FR 80139, 80160 (Dec. 23, 2015).
---------------------------------------------------------------------------

H. Remediation--Sec. Sec.  37.1401(m), 38.1051(m), and 49.24(n)

1. Proposed Rule
    The NPRM called for each DCM, SEF, and SDR to analyze the results 
of the testing and assessment required by the system safeguards rules 
in order to identify all vulnerabilities and deficiencies in its 
systems.\120\ It proposed requiring each such entity to remediate those 
vulnerabilities and deficiencies to the extent necessary to enable the 
entity to meet the requirements of the system safeguards rules and of 
its statutory and regulatory responsibilities.\121\ It called for such 
remediation to be timely in light of appropriate risk analysis with 
respect to the risks presented.
---------------------------------------------------------------------------

    \120\ 80 FR 80139, 80160 (Dec. 23, 2015).
    \121\ Id.
---------------------------------------------------------------------------

2. Comments Received
    Nadex and Tradeweb suggested that the proposed requirement to 
identify and remediate ``all'' vulnerabilities and deficiencies in a 
regulatee's systems was impossible to achieve in practice. Nadex 
observed that other discussion in the NPRM indicated Commission intent 
to

[[Page 64291]]

require remediation of vulnerabilities and deficiencies identified in 
the testing results, and suggested amending the final rule to make this 
clear. Noting that remediation after a cyber attack often takes time, 
Tradeweb argued that regulatees should not be penalized for that fact, 
and requested Commission guidance on what constitutes timely 
remediation, perhaps including specification that remediation over nine 
to twelve months would be timely.
3. Final Rule
    The Commission has considered and evaluated the comments concerning 
the remediation provision of the NPRM. For the reasons discussed below, 
the Commission is modifying the remediation provision in the final rule 
require DCMs, SEFs, and SDRs to: (1) Identify and document the 
vulnerabilities and deficiencies revealed by the testing called for in 
the system safeguards rules; and (2) conduct and document an 
appropriate analysis of the risks presented, in order to determine and 
document whether to remediate or accept each such risk. The Commission 
is adopting the requirement for the entity to remediate such risks in a 
timely manner in light of appropriate risk analysis as proposed.
    The Commission agrees with commenters that a requirement calling 
for a DCM, SEF, or SDR to remediate all vulnerabilities and 
deficiencies could be read as overbroad and impossible in practice. As 
suggested in a comment, the intent of the NPRM remediation provision 
was in fact to require remediation of the vulnerabilities and 
deficiencies disclosed through the regulatee's program of risk analysis 
and oversight, which includes testing of appropriate scope. In response 
to the comments received, the Commission is narrowing the remediation 
requirement to address remediation or acceptance of the vulnerabilities 
and deficiencies of which the entity is aware or through an appropriate 
program of risk analysis and oversight should be aware, rather than the 
remediation of all vulnerabilities and deficiencies. This revision is 
being made to reduce burdens and costs to the extent possible without 
impairing the purposes of the CEA and the Commission's system 
safeguards regulations. Best practices call for organizations to 
conduct appropriate risk analysis with respect to vulnerabilities and 
deficiencies disclosed by testing, in order to determine whether to 
remediate or accept the risks presented.\122\ Documentation of such 
analysis and decisions is needed for both an effective program of risk 
analysis and effective Commission oversight of system safeguards. The 
NPRM proposal to require identification of vulnerabilities was intended 
to include their documentation. Effective remediation would be 
impossible without documentation of both the vulnerabilities in 
question and the remediation steps needed. Accordingly, the Commission 
believes regulatees would create such documentation in the normal 
course of business. However, because documentation was not explicitly 
required in the proposal, the Commission is treating the final rule 
documentation requirement as a possible, slight additional burden. The 
Commission notes, however, that in the context of the burden reduction 
resulting from requiring regulatees to identify and remediate the 
vulnerabilities of which they are or should be aware, rather than to 
identify ``all'' vulnerabilities as proposed in the NPRM, the overall 
effect of the final rule remediation provision represents a 
considerable reduction in burden and cost over what was proposed.
---------------------------------------------------------------------------

    \122\ For clarity, the Commission notes that it sees the term 
``remediation'' as including mitigation and avoidance of risks as 
discussed in some sources of best practices. See, e.g., NIST SP 800-
39, at 41-43.
---------------------------------------------------------------------------

    The Commission is aware that appropriate and effective remediation 
following a cyber attack often must proceed over a reasonable period of 
time, determined by the nature of the intrusion and the mitigation 
steps needed, and it takes this fact into account in determining 
whether remediation is timely. The Commission does not believe it is 
practicable to codify specific periods of time as constituting timely 
remediation, since what is timely and appropriate depends on the 
particular circumstances and risks involved in a given situation.

III. Related Matters

A. Regulatory Flexibility Act

    The Regulatory Flexibility Act (``RFA'') requires federal agencies, 
in promulgating rules, to consider the impact of those rules on small 
entities.\123\ The rules adopted herein will affect DCMs, SEFs, and 
SDRs. The Commission has previously established certain definitions of 
``small entities'' to be used by the Commission in evaluating the 
impact of its rules on small entities in accordance with the RFA.\124\ 
The Commission previously determined that DCMs, SEFs, and SDRs are not 
small entities for the purpose of the RFA.\125\ The Commission received 
no comments on the impact of the rules contained herein on small 
entities. Therefore, the Chairman, on behalf of the Commission and 
pursuant to 5 U.S.C. 605(b), certifies that the final rules will not 
have a significant economic impact on a substantial number of small 
entities.
---------------------------------------------------------------------------

    \123\ 5 U.S.C. 601 et seq.
    \124\ See 47 FR 18618 through 18621 (Apr. 30, 1982).
    \125\ 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'') \126\ 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. The final rules contain 
recordkeeping and reporting requirements that are collections of 
information within the meaning of the PRA. In accordance with the 
requirements of the PRA, the Commission may not conduct or sponsor, and 
a person is not required to respond to, a collection of information 
unless it displays a currently valid OMB control number.
---------------------------------------------------------------------------

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

    As discussed below, the final rules contain provisions that qualify 
as collections of information, for which the Commission has already 
sought and obtained control numbers from 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). With the exception of Sec.  38.1051(n) that requires all DCMs to 
submit annual trading volume information to the Commission, the final 
rules will not impose any new recordkeeping or reporting requirements 
that are not already accounted for in existing collections 3038-
0052,\127\ 3038-0074,\128\ and 3038-0086.\129\
---------------------------------------------------------------------------

    \127\ See OMB Control No. 3038-0052, available at http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0052.
    \128\ See OMB Control No. 3038-0074, available at http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0074.
    \129\ See OMB Control No. 3038-0086, available at http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0086.
---------------------------------------------------------------------------

2. Clarifications of Collections 3038-0052, 3038-0074, and 3038-0086
    As stated in the NPRM, all DCMs, SEFs, and SDRs are already subject 
to

[[Page 64292]]

system safeguard-related books and records obligations.\130\ The final 
rules 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 Commission is adopting these provisions as 
proposed. Specifically, Sec. Sec.  38.1051(g), 37.1041(g), and 49.24(i) 
require all DCMs, SEFs, and SDRs 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 NPRM invited public 
comment on the accuracy of its estimate that no additional 
recordkeeping or information collection requirements or changes to the 
existing collection requirements would result from the proposed 
clarifying amendments.\131\ The Commission did not receive any comments 
that addressed whether additional recordkeeping or information 
collection requirements or changes to existing collection requirements 
would result from the adoption of the proposed rules.\132\ In light of 
the above, the Commission believes that Sec. Sec.  38.1051(g), 
37.1041(g), and 49.24(i) do not impact the burden estimates currently 
provided for in OMB Control Numbers 3038-0052, 3038-0074, and 3038-
0086.
---------------------------------------------------------------------------

    \130\ 80 FR 80139, 80162 (Dec. 23, 2015).
    \131\ Id.
    \132\ As discussed in the preamble, the Commission received 
comment letters from WMBAA, CME, and ICE concerning the books and 
records obligations generally.
---------------------------------------------------------------------------

3. Revision to Collection 3038-0052
    The final DCM rules will require a new information collection which 
is covered by OMB Control No. 3038-0052. Commission regulation Sec.  
38.1051(n) requires each DCM to provide to the Commission its annual 
total trading volume for calendar year 2015 and each calendar year 
thereafter. This information is required for 2015 within 30 calendar 
days of the effective date of the final rules, and for 2016 and 
subsequent years by January 31 of the following calendar year.
    The Commission requested comment concerning the accuracy of its 
estimate concerning the proposed reporting requirements in Sec.  
38.1051(n).\133\ Although the Commission did not receive any comment 
concerning the accuracy of its estimate, the Commission received a 
comment from CME that the Commission should consider alternatives to 
the reporting requirements in proposed Sec.  38.1051(n) because the 
Commission currently receives daily trade reports regarding volume 
pursuant to DCM Core Principle 8 and part 16 of the Commission's 
regulations. The Commission notes that while it receives daily trade 
information from DCMs pursuant to part 16, it does not receive total 
annual trading volume from DCMs. Additionally, the Commission believes 
that Core Principle 8 is inapplicable because it requires DCMs to 
publish daily volume, but does not require submission of that 
information to the Commission. The Commission's rules do not currently 
require the submission of annual trading volume, which is essential for 
the Commission to accurately evaluate whether a particular DCM must 
comply with the enhanced system safeguard requirements. The Commission 
believes that DCMs generally calculate their annual trading volume in 
the usual course of business and any associated costs incurred by DCMs 
to comply with this provision will be minimal.
---------------------------------------------------------------------------

    \133\ 80 FR 80139, 80163 (Dec. 23, 2015).
---------------------------------------------------------------------------

    Currently, there are 15 registered DCMs that will be required to 
comply with the annual trading volume information. Consistent with its 
estimate in the NPRM, the Commission estimates that the information 
collection required associated with the final rule will impose an 
average of 0.5 hours annually per respondent.\134\ The estimated annual 
burden for 3038-0052 was calculated as follows:
---------------------------------------------------------------------------

    \134\ Id.
---------------------------------------------------------------------------

    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.
    The final rule requiring the submission of annual trading volume 
information to the Commission will result in an annual cost burden of 
approximately $24.80 per respondent.\135\ The Commission based its 
calculation on an hourly wage of $49.59 for a Compliance Officer.\136\
---------------------------------------------------------------------------

    \135\ Id.
    \136\ 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 (2015 Report). The 
hourly rate for a Compliance Officer in the Securities and Commodity 
Exchanges section as published in the 2015 Report was $49.59 per 
hour. In the NPRM, the Commission's estimate of $22.015 per 
respondent was based on the hourly wage of $44.03 for a Compliance 
Officer in the 2014 Report. 80 FR 80139, 80163 (Dec. 23, 2015).
---------------------------------------------------------------------------

    Accordingly, the Commission intends to amend existing collection 
3038-0052 to account for the submission of annual trading volume 
information to the Commission. The amendment will add an estimated 
annual burden of 7.5 hours to the existing collection, which currently 
includes an annual reporting burden of 8,670 hours. Therefore, the new 
annual reporting burden for collection 3038-0052 will be 8,677.5 hours.

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 discretionary actions before promulgating a 
regulation under the CEA or issuing certain orders.\137\ 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. In adopting the final system safeguard rules for DCMs, 
SEFs, and SDRs, the Commission has considered the costs and benefits 
resulting from its discretionary determinations with respect to the 
section 15(a) factors.
---------------------------------------------------------------------------

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

    To further the Commission's consideration of the costs and benefits 
imposed by its regulations, the Commission invited comments from the 
public on all aspects of the Consideration of Costs and Benefits 
section of the NPRM. The Commission specifically invited responses to a 
series of questions regarding costs and benefits, and specifically 
invited commenters to provide data or other information quantifying 
such costs and benefits. The Commission received one comment that 
provided quantitative information pertaining to the costs associated 
with certain proposed provisions.\138\ CME estimated that the

[[Page 64293]]

additional cost that it would incur over a two year period is over $7.2 
million.\139\ A number of other commenters did not provide specific 
cost estimates, but provided comments concerning the costs generally. 
The Commission is addressing both types of comments in the discussion 
that follows. As discussed more fully below, the Commission believes 
that the changes to the final regulations will reduce the overall costs 
of compliance as compared to the NPRM.
---------------------------------------------------------------------------

    \138\ CME provided cost estimates for the proposed independent 
contractor requirements, conducting ETRAs, and controls testing.
    \139\ CME noted that its cost estimate also includes costs 
associated with the Commission's parallel NPRM that addresses system 
safeguards for DCOs. Additionally, CME noted that its estimate 
``does not separate out the costs for clearing, trading, or data 
reporting.''
---------------------------------------------------------------------------

    As stated in the NRPM, Commission staff collected 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'').\140\ Some of the cost 
estimates provided by the DCMs and SDRs included estimates at the 
parent company level of the DCM and SDR because the entities were 
unable to apportion the actual costs to a particular entity within 
their corporate structure.\141\ 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 was difficult in some cases to distinguish 
between the system safeguard-related costs of DCMs, SEFs, SDRs, and 
DCOs. This distinction was highlighted by CME in its comment letter by 
noting that its cost estimates do not separate out costs for clearing, 
trading, or data reporting. Given the lack of quantitative data 
provided in the comments, the Commission is relying on the data 
collected from the DMO Preliminary Survey concerning the costs for 
conducting vulnerability testing, external and internal penetration 
testing, controls testing, and enterprise technology risk 
assessments.\142\
---------------------------------------------------------------------------

    \140\ 80 FR 80139, 80165 (Dec. 23, 2015). The Commission notes 
that the DCMs and SDRs that provided the information for the DMO 
Preliminary Survey requested confidential treatment.
    \141\ It is not uncommon for entities within the same corporate 
structure to share automated systems and system safeguard programs.
    \142\ The estimates from the DMO Preliminary Survey provided in 
this section are presented as simple cost averages of the affected 
entities', without regard to the type of entity. By definition, 
averages are meant to serve only as a reference point; the 
Commission understands that due to the nature of the 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.
---------------------------------------------------------------------------

2. Baseline for Final Rules
    The Commission recognizes that any economic effects, including 
costs and benefits, should be evaluated with reference to a baseline 
that accounts for current regulatory requirements. As stated in the 
NPRM, the baseline for this cost and benefit consideration is the set 
of current requirements under the Act and the Commission's regulations 
for DCMs, SEFs, and SDRs.\143\ 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.\144\ Additionally, the Act 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.\145\ The Commission's current 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.\146\
---------------------------------------------------------------------------

    \143\ 80 FR 80139, 80164 (Dec. 23, 2015).
    \144\ 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).
    \145\ Id.
    \146\ 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for 
SEFs); 17 CFR 49.24(j) (for SDRs).
---------------------------------------------------------------------------

    The final rules clarify the system safeguards and cybersecurity 
testing requirements 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. For 
the following reasons, the Commission believes that the final 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. Each of the types of testing and assessment required under the 
final rules--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. Moreover, the Commission believes that it is 
essentially impossible for a DCM, SEF, or SDR to fulfill its current 
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 final rules. 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 adopting the final rules.\147\ If compliance with the clarified 
testing requirements herein results in costs to DCMs, SEFs, and SDRs, 
the Commission believes that those are costs associated with compliance 
with current testing requirements and not the final rules.\148\
---------------------------------------------------------------------------

    \147\ The Commission's current 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 the final rules--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 final rule well before that date, as shown in the following 
examples. Regarding all five types of testing, see, e.g., NIST SP 
800-53A, Rev. 1, Guide for Assessing the Security Controls in 
Federal Information Systems and Organizations (``NIST 800-53A Rev. 
1''), at E1, F67, F230, F148, and F226, June 2010, available at 
http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding vulnerability testing, see, e.g., NIST SP 
800-53A Rev. 1, at F67, June 2010, available at http://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 http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. 
Regarding penetration testing, see, e.g., NIST Special Publication 
(``SP'') 800-53A, Rev. 1, at E1, June 2010, available at http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008, available at 
http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. 
Regarding controls testing, see, e.g., NIST 800-53A, Rev. 1, at 13 
and Appendix F1, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. 
Regarding security incident response plan testing, see, e.g., NIST 
800-53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding enterprise technology risk assessment, see, 
e.g., NIST 800-53A, Rev. 1, at F226, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
    \148\ MGEX commented that it has defined and implemented a 
system that it believes conforms to industry best practices. MGEX 
further commented that unless each organization's structure is 
identical to the CFTC's rulemakings, there will be a cost of 
compliance. Throughout this section, the Commission has articulated 
areas where it believes the new rules will impose new costs relative 
to the current requirements. Accordingly, unless otherwise stated, 
the Commission believes that any additional costs incurred by DCMs, 
SEFs, and SDRs are attributable to the current requirements.

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

[[Page 64294]]

    The Commission believes that new costs will be imposed by the 
minimum testing frequency and independent contractor requirements for 
covered DCMs and SDRs included in the final rules. In addition, the 
final rules that make it mandatory for all DCMs (covered and non-
covered), SEFs, and SDRs to follow best practices, ensure testing 
independence, and coordinate BC-DR plans will also impose new costs. As 
discussed more fully below in Section C.3.b., the language in the final 
rules make these currently recommended provisions mandatory and the 
Commission believes this modification will result in new costs relative 
to current practice. Finally, the Commission believes that the final 
rules requiring all DCMs (covered and non-covered), SEFs, and SDRs to 
update BC-DR plans and emergency procedures no less frequently than 
annually, and the requirement for all DCMs to report their total annual 
trading volume to the Commission each year will also impose new costs 
relative to the current requirements.
    The Commission expects that the costs and benefits may vary 
somewhat among the covered DCMs and SDRs. For example, some covered 
DCMs and SDRs are larger or more complex than others, and the new 
requirements may impact covered DCMs and SDRs differently depending on 
their size and the complexity of their systems.\149\ The Commission 
believes 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 how they choose to implement compliance with 
the new requirements.
---------------------------------------------------------------------------

    \149\ Based on information obtained from the DMO Preliminary 
Survey and the Commission's system safeguard compliance program, the 
Commission understands that most large DCMs (that are likely to be 
covered DCMs) and SDRs currently conduct system safeguard testing at 
the minimum frequency for most of the tests required by the final 
rules. Additionally, the Commission understands that most large DCMs 
and SDRs currently engage independent contractors for the testing 
required by the final rules.
---------------------------------------------------------------------------

    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 final 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.
    The discussion of costs and benefits that follows begins with a 
summary of each final rule and a consideration of the corresponding 
costs and benefits and the associated comments. At the conclusion of 
this discussion, the Commission considers the costs and benefits of the 
rules collectively in light of the five factors set forth in section 
15(a) of the CEA.
3. Summary of Final Rules and Discussion of Costs and Benefits
a. Categories of Risk Analysis and Oversight: Sec. Sec.  38.1051(a), 
37.1401(a), and 49.24(b)

(1) Summary of Final Rules

    The final rules concerning the categories of risk analysis and 
oversight clarify what is already required of all DCMs, SEFs, and SDRs 
regarding the categories which their programs of risk analysis and 
oversight must address by further defining the six categories addressed 
by the current rules. The six categories are: (1) Information security; 
(2) Business-continuity disaster recovery planning and resources; (3) 
Capacity and performance planning; (4) Systems operations; (5) Systems 
development and quality assurance; and (6) Physical security and 
environmental controls. In addition, the final rules add and define 
enterprise risk management as a seventh category.
(2) Costs and Discussion of Comments
    MGEX stated that because the categories of risk analysis and 
oversight identified by the Commission in the DCM, SEF, and SDR NPRM 
differ from the Commission's parallel DCO NPRM, the lack of consistency 
increases the compliance burden of a combined DCM and DCO entity. The 
Commission acknowledges that its DCM, SEF, and SDR NPRM included the 
additional category of enterprise risk management and governance.\150\
---------------------------------------------------------------------------

    \150\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------

    MGEX also argued that because the two NPRMs differ on the component 
parts of a program of risk analysis and oversight, it is difficult to 
conclude that these programs are pre-existing requirements that do not 
have a cost of compliance. The Commission disagrees with MGEX. As noted 
in the DCO NPRM, DCO's face a wider array of risks than DCMs, and 
therefore enterprise risk management requirements for DCOs are not 
limited to the system safeguards context, but need to be addressed in a 
more comprehensive fashion and possibly in a future rulemaking.\151\ 
The requirement for DCMs, SEFs, and SDRs to have a program of system 
safeguards risk analysis and oversight was mandated by Congress in the 
CEA itself, and thus is already required by law.\152\ The Commission's 
current system safeguards regulations define the program of risk 
analysis and oversight by specifying the categories of risk analysis 
and oversight which the program must address. The category of 
enterprise risk management and governance is implicit and inherent in 
the statutory requirement itself, and supported by generally accepted 
standards and best practices.\153\ The final rules make enterprise risk 
management and governance an explicitly listed category for the sake of 
clarity. If compliance with the clarifications regarding the categories 
of risk analysis and oversight results in additional costs, the 
Commission believes that those are costs associated with compliance 
with current requirements, not the final rules.
---------------------------------------------------------------------------

    \151\ Id. at 80123.
    \152\ CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20).
    \153\ See, e.g., NIST SP 800-39, Managing Information Security 
Risk: Organization, Mission, and Information System View (March 
2011) (``NIST SP 800-39''), available at http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf.
---------------------------------------------------------------------------

    MGEX further argued that the specific and itemized content of some 
of the categories of risk analysis and oversight are overly 
prescriptive and should be principles based. MGEX noted information 
security controls as one example that is overly prescriptive. The 
Commission agrees with MGEX that the categories of risk analysis and 
oversight should be principles based, but disagrees with MGEX's 
assertion that the NPRM lists of topics included in each category 
consist of a static list of controls. As set out in detail in the NPRM, 
each of the aspects of the various categories that the program of risk 
analysis and oversight must address is rooted in generally accepted 
standards and best practices.\154\ Because the Commission's current 
system safeguards rules and guidance provide that DCMs, SEFs, and SDRs 
should follow generally accepted best practices and standards regarding 
system safeguards, these entities' programs of risk analysis and 
oversight should already be addressing each of the aspects included in 
the NPRM for each risk analysis and oversight category.\155\
---------------------------------------------------------------------------

    \154\ 80 FR 80139, 80143 (Dec. 23, 2015).
    \155\ 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).

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

[[Page 64295]]

    CME requested that the Commission confirm that the final rule will 
allow regulated entities flexibility of organizational design 
concerning how their programs of risk analysis and oversight address 
enterprise risk management and governance, and will not require that an 
entity's enterprise risk management function conduct all components of 
this category. As discussed in the preamble, the Commission confirms 
that the addition of enterprise risk management and governance does not 
require that the listed elements of this category be conducted through 
a particular organizational structure; rather, the final rule provides 
flexibility in this regard.
(3) Benefits
    The primary benefit of the final rules is clarity to all DCMs, 
SDRs, and SEFs with regard to administering their programs of risk 
analysis and oversight. The final rules provide definitions for each 
category of risk analysis and oversight and highlight important aspects 
of each category that are recognized as best practices. An important 
benefit of the adherence-to-best-practices approach taken in the 
Commission's final system safeguards rules is that best practices can 
evolve over time as the cybersecurity field evolves. In addition, the 
Commission believes that all seven categories of risk analysis and 
oversight are essential to maintaining effective system safeguards in 
today's cybersecurity threat environment.
b. Requirements To Follow Best Practices, Ensure Testing Independence, 
and Coordinate BC-DR Plans: Sec. Sec.  38.1051(b), 37.1401(b), and 
49.24(c) (best practices); 38.1051(h)(2)(iii), (3)(iii), (4)(ii), 
(5)(iii), and (7)(ii), 37.1401(h)(2)(iii), (3)(ii), (4)(ii), (5)(ii), 
and (7)(ii), and 49.24(2)(iii), (4)(ii), and (7)(ii) (testing 
independence); 38.1051(i), 37.1401(i), and 49.24(k) (BC-DR plans)
(1) Summary of Final Rules
    The final rules make mandatory for DCMs, SEFs, and SDRs the 
provisions concerning best practices, testing independence, and 
coordination of BC-DR plans recommended but not made mandatory in the 
Commission's current rules.
(2) Costs
    The Commission did not receive any comments addressing the costs of 
these provisions. The Commission's current 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.\156\ The current rules 
and guidance also 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).\157\ They further provide that such entities should 
coordinate their BC-DR plans with the BC-DR plans of market 
participants and essential service providers.\158\ Because the final 
rules will make these currently recommended provisions mandatory, it is 
anticipated that they will impose new costs relative to current 
practice.
---------------------------------------------------------------------------

    \156\ 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).
    \157\ 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).
    \158\ 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).
---------------------------------------------------------------------------

(3) Benefits
    Making the provisions concerning following best practices, ensuring 
testing independence, and coordinating BC-DR plans 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. As stated in the preamble, the 
Commission believes that the requirement to follow generally accepted 
standards and best practices is one of the most important requirements 
of its system safeguards rules. Best practices can evolve over time, in 
light of the changing cybersecurity threat environment. The agility 
that a best practices approach provides is crucial to effective 
resilience with respect to cybersecurity and system safeguards. 
Further, the ongoing development and evolution of best practices 
benefits from private sector expertise and input, as well as from 
public sector contributions. Such private sector expertise and input is 
important to effective cybersecurity. The Commission also observes that 
requiring financial sector entities to follow best practices with 
respect to system safeguards and cybersecurity is an effective key to 
harmonizing the oversight of cybersecurity conducted by different 
financial regulators. The Commission also believes that clarity 
concerning what is required benefits DCMs, SEFs, and SDRs, and the 
public interest.
c. Updating of Business Continuity-Disaster Recovery Plans and 
Emergency Procedures: Sec. Sec.  38.1051(c), 37.1401(c), and 49.24(d)
(1) Summary of Final Rules
    The final rules 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.
(2) Costs
    The Commission did not receive any comments addressing the costs of 
this aspect of the proposed rules. The Commission's current system 
safeguards 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.\159\ As a result of the 
minimum annual frequency requirement, the final rules impose new costs 
relative to the requirements of the current rules.\160\ The entities 
will incur the additional recurring costs associated with investing in 
the resources and staff necessary to updating the BC-DR and emergency 
plans at least annually.
---------------------------------------------------------------------------

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

(3) 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.'' \161\
---------------------------------------------------------------------------

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

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

[[Page 64296]]

d. Required System Safeguards-Related Books and Records Obligations: 
Sec. Sec.  38.1051(g), 37.1041(g), and 49.24(i)
(1) Summary of Final Rules
    The final rules require a DCM, SEF, or SDR, in accordance with 
Commission regulation Sec.  1.31,\162\ 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 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.
---------------------------------------------------------------------------

    \162\ Commission regulation Sec.  1.31(a)(1) specifically 
provides that all books and records required to be kept by the Act 
or by the regulation 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. 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).
---------------------------------------------------------------------------

(2) Costs and Discussion of Comments
    The Commission believes that the final rules do not impose any new 
costs.\163\ All DCMs, SEFs, and SDRs are already subject to system 
safeguard-related books and records requirements. The final rules 
clarify the system safeguard recordkeeping and reporting requirements 
for these registered entities. Because the final rules only clarify 
current requirements and because the production of system-safeguard 
records is already required by the current rules, the Commission 
believes that the final rules do not impose any additional costs on 
DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \163\ See also PRA discussion above.
---------------------------------------------------------------------------

    Although the Commission did not receive any comments specifically 
addressing the costs of the books and records obligations, two 
commenters addressed whether, and in what circumstances, books and 
records obligations would reach the parent firm. ICE commented that 
with respect to parent firms that own both CFTC-regulated and non-CFTC-
regulated entities, the Commission should avoid requiring production of 
documents discussing risks at the firm-wide level. To this end, ICE 
argued that the Commission should limit its production requests to 
documents focused solely on the risks of CFTC-regulated entities. 
However, WMBAA observed that the automated systems, programs of system 
safeguards-related risk analysis and oversight, cybersecurity defenses 
and testing, and BC-DR plans and resources of CFTC-regulated DCMs, 
SEFs, and SDRs owned by parent financial sector companies that also own 
entities not regulated by the Commission are frequently shared across 
the parent company. The Commission agrees with WMBAA's comment, and 
notes that this is presently the case with respect to all DCMs, SEFs, 
and SDRs regulated by the Commission that are owned by the same parent 
company. Thus, the Commission disagrees with ICE's suggestion that 
production of books and records addressing parent-wide system 
safeguards risks and risk analysis and oversight programs should not be 
required. A system safeguards document that is a book and record of a 
DCM, SEF, or SDR is required to be produced as a book and record 
subject to the Commission's rules, regardless of whether the parent 
company decides to share resources among CFTC regulated and non-CFTC 
regulated entities. The production of all of the books and records 
specified in the NPRM books and records provisions is already required 
by the Act and Commission regulations.\164\
---------------------------------------------------------------------------

    \164\ 80 FR 80139, 80147 (Dec. 23, 2015).
---------------------------------------------------------------------------

(3) Benefits
    The recordkeeping requirements for DCMs, SEFs, and SDRs allow the 
Commission to 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 examinations of DCMs, SEFs, and SDRs, and identify practices 
that may be inconsistent with the Act and Commission regulations. 
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 DCMs, SEFs, and 
SDRs.
e. Definitions: Sec. Sec.  38.1051(h)(1), 37.1041(h)(1), and 
49.24(j)(1)
(1) Summary of Final Rules
    The final rules 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) includes the 
definition for covered DCM.
(2) Costs and Benefits
    The definitions specified in the final rules provide context to the 
specific system safeguard tests and assessments that a DCM, SEF, or SDR 
is required to conduct on an ongoing basis. Accordingly, the costs and 
benefits of these terms are attributable to the substantive testing 
requirements and are discussed in the cost and benefit considerations 
related to the final rules describing the requirements for each test. 
However, the Commission notes that some comments addressed terms that 
were used but not defined in the NPRM and are relevant to the 
consideration of costs for the final rules. In particular, as discussed 
in the preamble, CME, ICE, and MGEX commented concerning the NPRM's use 
of the terms ``independent contractor'' and ``independent 
professional.'' CME asserted that neither term is clearly defined in 
either the Commission's existing rules or the NPRM. ICE called on the 
Commission to clarify in the final rule that entity employee groups 
such as the internal audit function are considered to be independent 
professionals not responsible for the development of operation of the 
systems or capabilities tested or assessed in the area of system 
safeguards. ICE stated that not allowing internal auditors to conduct 
certain system safeguards or information security testing could add 
substantial costs to the regulated entities. While not commenting 
directly on these definitions, MGEX expressed the view that having 
independent testing performed is a key and costly feature proposed in 
the NPRM.
    The Commission's current system safeguards rules for DCMs and SDRs 
and its current system safeguards rules and guidance for SEFs provide 
that independent contractors are qualified system safeguards 
professionals who are not employees of the DCM, SEF, or SDR.\165\ The 
current rules use the terms independent contractor and employee as they 
are legally defined and generally used.\166\ The Commission believes 
that

[[Page 64297]]

the distinction between independent contractor and employee is well 
settled and understood, and does not need additional definition in the 
system safeguards rules. With respect to system safeguards testing, the 
current rules provide that employees conducting required testing must 
be independent in that they are not employees responsible for 
development or operation of the systems or capabilities being tested. 
The Commission believes that this distinction between employees with 
sufficient independence to appropriately conduct required system 
safeguards testing and those who lack such independence is also 
sufficiently clear, and does not require additional definition. The 
NPRM used, and the final rule will retain, this language from the 
current system safeguards rules. Where this requirement is included, 
the testing in question must be conducted by employees who are 
independent, which means employees not responsible for developing or 
operating what is being tested. Employees who are part of the internal 
audit function of a DCM, SEF, or SDR, are one example of employees 
having appropriate independence. Other employees who possess the 
specified degree of independence and have qualifications the DCM, SEF, 
or SDR believes are appropriate may also be suitable in such cases.
---------------------------------------------------------------------------

    \165\ 17 CFR Sec. Sec.  38.1051(h) (for DCMs); 37.1401(g) and 
Appendix B to Part 37, Core Principle 14 of Section 5h of the Act--
System Safeguards (C)(a)(2) (for SEFs); 49.24(j) (for SDRs).
    \166\ See, e.g., Black's Law Dictionary, Tenth Ed. (Thomson 
Reuters, St. Paul, MN, 2014) (``Employee. Someone who works in the 
service of another person (the employer) under an express or implied 
contract of hire, under which the employer has the right to control 
the details of work performance.'') (``Independent Contractor. 
Someone who is entrusted to undertake a specific project but who is 
left free to do the assigned work and to choose the method for 
accomplishing it.'')
---------------------------------------------------------------------------

    As discussed in the preamble, one clarification may be helpful with 
respect to testing required to be performed by independent contractors, 
as distinct from testing performed by persons performing the internal 
audit function. The internal audit function is a required aspect of the 
enterprise risk management governance category which must be included 
in the program of risk analysis and oversight that a DCM, SEF, or SDR 
must maintain. It is an integral part of, and a responsibility of, the 
regulated entity, whether carried out in-house or outsourced. The NPRM 
proposed required testing by independent contractors in part to give 
the Commission' system safeguards oversight a third source of system 
safeguards information on which to rely, in addition to the entity's 
employees and its internal audit function.\167\ It also proposed 
independent contractor testing to give the regulated entity the benefit 
of a truly outside perspective concerning system safeguards, not 
colored by beginning from the institutional point of view. Accordingly, 
testing performed by persons executing internal audit function will not 
fulfill the requirement for testing by independent contractors, whether 
it is performed by employees executing the internal audit function or 
by internal audit contractors to whom a DCM, SEF, or SDR outsources 
part or all of its internal audit function.
---------------------------------------------------------------------------

    \167\ 80 FR 80139, 80148 (Dec. 23, 2015).
---------------------------------------------------------------------------

f. Vulnerability Testing: Sec. Sec.  38.1051(h)(2), 37.1401(h)(2), and 
49.24(j)(2)
(1) Summary of Final Rules
    The final rules 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. Additionally, the 
final rules require a DCM, SEF, or SDR to conduct vulnerability testing 
that is sufficient to satisfy the testing scope requirements in new 
Sec. Sec.  38.1051(k), 37.1401(k), and 49.24(l), at a frequency 
determined by an appropriate risk analysis. Moreover, such 
vulnerability testing shall include automated vulnerability scanning 
and follow best practices in this regard. At a minimum, covered DCMs 
and SDRs are required to conduct vulnerability testing no less 
frequently than quarterly. For all DCMs, SEFs, and SDRs, vulnerability 
testing may be conducted by either independent contractors or employees 
of the entity that are not responsible for development or operation of 
the systems or capabilities being tested.
(2) Costs and Discussion of Comments
(a) Vulnerability Testing Requirement for All DCMs, SEFs, and SDRs
    As stated in the NPRM and above in the Baseline discussion, 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.\168\ 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.\169\
---------------------------------------------------------------------------

    \168\ 80 FR 80139, 80164, 80167 (Dec. 23, 2015). 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).
    \169\ Id.
---------------------------------------------------------------------------

    The Commission's current 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.\170\ The Commission believes, as 
the generally accepted standards and best practices noted in the NPRM 
make clear, that it is essentially impossible for a DCM, SEF, or SDR to 
fulfill its current obligation to conduct testing sufficient to ensure 
the reliability, security, and capacity of its automated systems 
without conducting vulnerability testing.\171\ If compliance with the 
current testing requirements as clarified by the final 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 are 
attributable to compliance with the current rules and not to the final 
rules. Accordingly, the Commission believes that clarifying the rules 
will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \170\ 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).
    \171\ 80 FR 80139, 80164 (Dec. 23, 2015). See, e.g., NIST SP 
800-53A Rev. 1, at F67, June 2010, available at http://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 http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

(b) Authenticated Scanning Requirement for All DCMs, SEFs, and SDRs
    The NPRM called for vulnerability testing to include automated 
vulnerability scanning, conducted on an authenticated basis where 
indicated by appropriate risk analysis, with compensating controls 
where scanning is conducted on an unauthenticated basis.\172\ No 
commenters disagreed with the proposed requirement for vulnerability 
testing to include automated vulnerability scanning. ICE argued that 
the Commission should remove the authenticated vulnerability scanning 
requirement from vulnerability testing because such scanning increases 
the quantity of findings, potentially diluting and obscuring important 
results. Additionally, ICE stated that introducing authentication 
increases the cost and time of a scan and increases risk by requiring 
an operating system login to be created and maintained on a new system. 
In light of the possibility that the proposed requirement for

[[Page 64298]]

automated scanning to include authenticated scanning could increase 
costs, burdens, and risks while having limited utility for DCMs, SEFs, 
and SDRs, the Commission is removing the authenticated scanning 
requirement from the final rules. Instead, the final rules provide that 
automated vulnerability scanning shall follow best practices.\173\ The 
Commission believes that removal of the authenticated scanning 
requirement will reduce the costs of compliance where best practices do 
not require authenticated scanning.
---------------------------------------------------------------------------

    \172\ Id. at 80150.
    \173\ To the extent that best practices require or come to 
require authenticated scanning, such scanning would be mandatory 
pursuant to the requirement to follow best practices, and would be 
addressed in system safeguards examinations.
---------------------------------------------------------------------------

(c) Vulnerability Testing Frequency Requirement for Covered DCMs and 
SDRs
    The final rules require covered DCMs and SDRs to conduct 
vulnerability testing no less frequently than quarterly.\174\ The 
Commission's current rules require DCMs and SDRs to conduct regular, 
periodic, objective testing of their automated systems.\175\ 
Accordingly, the final rules will impose new costs relative to the 
requirements of the current rules.\176\ MGEX stated that the frequency 
of conducting vulnerability testing should be determined by the 
regulatees and avoid prescriptive, static requirements.\177\ ICE argued 
that regulatees should not be subject to a formal risk assessment to 
potentially determine a higher vulnerability testing frequency. The 
Commission notes that the minimum frequency requirement is supported by 
generally accepted standards and best practices.\178\ Therefore, the 
Commission disagrees with the suggestion that the frequency of such 
testing should be left to the entities themselves. Accordingly, the 
Commission also notes that the final rule requires all DCMs, SEFs, and 
SDRs to conduct such testing as frequently as indicated by appropriate 
risk analysis.
---------------------------------------------------------------------------

    \174\ Based on the information collected in the DMO Preliminary 
Survey, the Commission understands that most large DCMs and SDRs 
currently conduct vulnerability testing at least quarterly.
    \175\ 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).
    \176\ As stated in the NPRM, the Commission's current 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 avoided applying the addition minimum frequency 
requirements to non-covered DCMs, in order to give smaller DCMs with 
fewer resources additional flexibility regarding the testing they 
must conduct. 80 FR 80168 (Dec. 23, 2015). For purposes of the final 
rules, the Commission continues to believe that such a reduced 
burden for smaller DCMs is appropriate.
    \177\ MGEX also commented that a smaller entity, such as MGEX, 
that is a combined DCM and DCO would not be able to take advantage 
of the reasonable carve-out for non-covered DCMs, because it would 
have to meet the highest common denominator of the DCM and DCO 
rulemakings. As stated in the Commission's parallel DCO rulemaking, 
the Commission has worked to harmonize the regulations applicable to 
DCOs and DCMs and the regulations track each other very closely. To 
the extent that an entity operating as a non-covered DCM incurs 
additional costs as a result of operating a DCO that must comply 
with the minimum frequency and independent contractor requirements, 
such costs are attributable to the final DCO regulations.
    \178\ PCI DSS, Requirement 11.2 Regularly test security systems 
and processes, at 51, available at https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf.
---------------------------------------------------------------------------

(d) Independent Contractor Requirement for Covered DCMs and SDRs
    The NPRM called for covered DCMs and SDRs to engage independent 
contractors to conduct two of the quarterly vulnerability tests each 
year.\179\ As explained in the preamble, a number of commenters argued 
that the use of independent contractors for vulnerability testing could 
undesirably increase risks. The Commission agrees with the commenters 
and the final rules do not include the requirement for covered DCMs and 
SDRs to have some vulnerability testing conducted by independent 
contractors. Instead, the final rules provide these entities with the 
flexibility to engage either independent contractors or use entity 
employees who are not responsible for the development or operation of 
the systems or capabilities being tested. The Commission believes that 
this will reduce costs and burdens for all covered DCMs and SDRs.\180\
---------------------------------------------------------------------------

    \179\ Id. at 80150.
    \180\ CME commented that the NPRM's independent contractor 
requirements that apply to vulnerability testing will result in an 
additional cost of $1.1 million every two years.
---------------------------------------------------------------------------

(e) Cost Estimates for Covered DCMs and SDRs
    The Commission did not receive comments addressing the total costs 
for conducting vulnerability testing. As discussed above in the costs 
section concerning the minimum frequency requirement, the final rules 
will impose new costs on covered DCMs and SDRs. The data collected from 
the DMO Preliminary Survey, suggests that on average, a covered DCM or 
SDR currently spends approximately $3,495,000 annually on vulnerability 
testing. As stated in the NPRM, 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.\181\ Additionally, although the Commission 
believes that all covered DCMs and SDRs have policies and procedures in 
place for vulnerability testing, the Commission acknowledges that 
affected entities may need to dedicate time to reviewing and revising 
their current policies and procedures to ensure that they are 
sufficient in the context of the final rules. The Commission believes 
that any costs incurred by the entities as result of such review will 
be minor.
---------------------------------------------------------------------------

    \181\ Id. at 80168.
---------------------------------------------------------------------------

(3) Benefits
    Vulnerability testing identifies, ranks, and reports 
vulnerabilities that, if exploited, may result in an intentional or 
unintentional compromise of a system.\182\ 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 understanding by 
management of the challenges the entity might face in a cyber threat 
scenario. In turn, the entity will be better prepared to address those 
challenges. Improved preparation 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, the entity's operations would have on market 
participants, 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.
---------------------------------------------------------------------------

    \182\ 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 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 organization and reduce the 
likelihood that attackers could exploit vulnerabilities. Best practices 
also 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

[[Page 64299]]

least quarterly,'' as well as after any significant network changes, 
new system component installations, firewall modifications, or product 
upgrades.\183\ Moreover, the Commission believes that the minimum 
frequency requirement provides additional clarity to covered DCMs and 
SDRs concerning what is required in this respect. As noted above in the 
costs section for this provision, the final rules also provide 
flexibility for DCMs, SEFs, and SDRs to have vulnerability testing 
conducted by either independent contractors or entity employees who are 
not responsible for development or operation of the systems or 
capabilities being tested.
---------------------------------------------------------------------------

    \183\ PCI DSS, Requirement 11.2 Regularly test security systems 
and processes, at 51, available at https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf.
---------------------------------------------------------------------------

g. External Penetration Testing: Sec. Sec.  38.1051(h)(3), 
37.1401(h)(3), and 49.24(j)(3)
(1) Summary of Final Rules
    The final rules 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. 
Additionally, the final rules require a DCM, SEF, or SDR to conduct 
external penetration testing that is sufficient to satisfy the scope 
requirements in new 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 are required to conduct external penetration 
testing no less frequently than annually. Covered DCMs and SDRs also 
are 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 who are not 
responsible for development or operation of the systems or capabilities 
being tested.
(2) Costs and Discussion of Comments
(a) External Penetration Testing for All DCMs, SEFs, and SDRs
    As stated in the NPRM and above in the Baseline discussion, 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.\184\ 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.\185\
---------------------------------------------------------------------------

    \184\ 80 FR 80139, 80164, 80169 (Dec. 23, 2015). 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).
    \185\ Id.
---------------------------------------------------------------------------

    The Commission's current 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.\186\ The Commission believes, as 
the generally accepted standards and best practices noted in the NPRM 
make clear, that it is essentially impossible for a DCM, SEF, or SDR to 
fulfill its current obligation to conduct testing sufficient to ensure 
the reliability, security, and capacity of its automated systems 
without conducting external penetration testing.\187\ If compliance 
with the current testing requirements as clarified by the final 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 
are attributable to compliance with the current rules and not to the 
final rules. Accordingly, the Commission believes that clarifying the 
rules will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \186\ 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).
    \187\ 80 FR 80139, 80164 (Dec. 23, 2015). See, e.g., NIST 
Special Publication (``SP'') 800-53A, Rev. 1, at E1, June 2010, 
available at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 
2008, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

(b) External Penetration Testing Frequency Requirement for Covered DCMs 
and SDRs
    The final rules require covered DCMs and SDRs to conduct external 
penetration testing no less frequently than annually. The Commission's 
current rules require DCMs and SDRs to conduct regular, periodic, 
objective testing of their automated systems.\188\ Because the current 
rules do not specify the frequency of such testing, the final rules 
will impose new costs relative to the requirements of the current 
rules.\189\ MGEX commented that the frequency of conducting external 
penetration testing should be left up to the organizations themselves. 
The Commission notes that external penetration testing is supported by 
generally accepted standards and best practices, which make it clear 
that testing at least annually is essential to adequate system 
safeguards in today's cybersecurity environment.\190\ Therefore, the 
Commission disagrees with the suggestion that the frequency should be 
left to the determination of the entities themselves. Accordingly, the 
Commission also notes that the final rule requires all DCMs, SEFs, and 
SDRs to conduct such testing as frequently as indicated by appropriate 
risk analysis.
---------------------------------------------------------------------------

    \188\ 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).
    \189\ Based on the information collected in the DMO Preliminary 
Survey, the Commission understands that most large DCMs and SDRs 
currently conduct external penetration testing at the minimum 
frequency specified in the final rule.
    \190\ NIST, SP 800-115, Technical Guide to Information Security 
Testing and Assessment, Section 5.2.2, at 5-5, available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

(c) Independent Contractor Requirement for Covered DCMs and SDRs
    The final rules also require that the annual external penetration 
test conducted by a covered DCM or SDR be conducted by an independent 
contractor. Current Commission regulations Sec. Sec.  38.1051(h) and 
49.24(j) provide that testing of automated systems should be conducted 
by qualified, independent professionals.\191\ 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 final rules 
will impose new costs relative to the requirements of the current 
rules.\192\
---------------------------------------------------------------------------

    \191\ Id.
    \192\ Based on the information collected in the DMO Preliminary 
Survey, the Commission understands that most large DCMs and SDRs 
currently engage independent contractors to conduct external 
penetration testing.
---------------------------------------------------------------------------

    DDR commented generally that an SDR should have flexibility 
regarding whether to have testing conducted by independent contractors 
or employees not responsible for the development or operation of the 
systems or capabilities being tested, based on the risks of that SDR. 
The Commission disagrees with DDR's comment. As discussed more fully in 
the preamble and noted below in the benefits section related to this 
provision, the Commission believes that the independent viewpoint and 
approach provided by independent contractors, who can conduct a 
penetration test from the perspective of an outside adversary uncolored 
by insider assumptions or blind spots, will benefit covered DCM and SDR 
programs of risk analysis and oversight. The Commission also notes that 
best

[[Page 64300]]

practices support using independent contractors.\193\
---------------------------------------------------------------------------

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

(d) Cost Estimates for Covered DCMs and SDRs
    The Commission did not receive any comments addressing the total 
costs for conducting external penetration testing. CME, however, 
estimated that the independent contractor requirements in the Proposal, 
which apply to external penetration testing, will result in an 
additional cost of $1.1 million every two years. The data collected 
from the DMO Preliminary Survey suggests that on average a covered DCM 
or SDR spends approximately $244,625 annually on external penetration 
testing. 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 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. Covered 
DCMs and SDRs that currently do not use independent contractors for the 
external penetration test may also need to dedicate time to reviewing 
and revising their current policies and procedures to ensure that they 
are sufficient in the context of the new requirements. The Commission 
believes that any costs incurred by the entities as result of such 
review will be minor.
(3) Benefits
    External penetration testing benefits DCMs, SEFs, and SDRs by 
identifying the extent to which their systems can be compromised before 
an attack is identified.\194\ Such testing is conducted from outside a 
DCM's, SEF's, or SDR's security perimeter to help reveal 
vulnerabilities that could be exploited by an external attacker. The 
Commission believes that external penetration testing strengthens DCM, 
SEF, and SDR systems, thereby protecting the entity and market 
participants from a disruption in services. A disruption in services at 
any of these entities could potentially disrupt the functioning of the 
broader financial markets.
---------------------------------------------------------------------------

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

    The requirement for annual external penetration testing at covered 
DCMs and SDRs to be performed by an independent contractor is intended 
to ensure that these entities' system safeguards programs of risk 
analysis and oversight include the benefits provided when independent 
contractors perform such testing. The Commission believes that 
independent contractor testing has particular value with respect to 
external penetration testing because the test is conducted 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.
h. Internal Penetration Testing: Sec. Sec.  38.1051(h)(4), 
37.1401(h)(4), and 49.24(j)(4)
(1) Summary of Final Rules
    The final rules 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. 
Additionally, the final rules require a DCM, SEF, or SDR to conduct 
internal penetration testing that is sufficient to satisfy the scope 
requirements in new 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 are required to conduct the internal penetration 
testing no less frequently than annually. All DCM, SEFs, or SDRs may 
engage independent contractors to conduct the test, or the entity may 
use employees of the entity who are not responsible for development or 
operation of the systems or capabilities being tested.
(2) Costs and Discussion of Comments
(a) Internal Penetration Testing for All DCMs, SEFs, and SDRs
    As stated in the NPRM and above in the Baseline discussion, 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.\195\ 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.\196\
---------------------------------------------------------------------------

    \195\ 80 FR 80139, 80164, 80170 (Dec. 23, 2015). 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).
    \196\ Id.
---------------------------------------------------------------------------

    The Commission's current 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.\197\ The Commission believes, as 
the generally accepted standards and best practices noted in the NPRM 
make clear, that it is essentially impossible for a DCM, SEF, or SDR to 
fulfill its current obligation to conduct testing sufficient to ensure 
the reliability, security, and capacity of its automated systems 
without conducting internal penetration testing.\198\ If compliance 
with the current testing requirements as clarified by the final 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 
are attributable to compliance with the current rules and not to the 
final rules. Accordingly, the Commission believes that clarifying the 
rules will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \197\ 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).
    \198\ 80 FR 80139, 80164 (Dec. 23, 2015). See, e.g., NIST 
Special Publication (``SP'') 800-53A, Rev. 1, at E1, June 2010, 
available at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 
2008, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

(b) Internal Penetration Testing by Independent Contractors or 
Employees of the DCM, SEF, or SDR
    The Commission continues to believe, as provided in the NPRM, that 
it is appropriate to give all DCMs, SEFs, and SDRs the flexibility of 
whether to have internal penetration testing performed by independent 
contractors or by employees not responsible for

[[Page 64301]]

development or operation of the systems or capabilities tested.\199\
---------------------------------------------------------------------------

    \199\ Id. at 80153.
---------------------------------------------------------------------------

(c) Internal Penetration Testing Frequency Requirement for Covered DCMs 
and SDRs
    The final rules require covered DCMs and SDRs to conduct internal 
penetration testing no less frequently than annually. The Commission's 
current rules require DCMs and SDRs to conduct regular, periodic, 
objective testing of their automated systems.\200\ Because the current 
rules do not specify the frequency of such testing, the final rules 
will impose new costs.\201\ CME commented that there is a scarcity of 
potential employees with the skill set required to conduct internal 
penetration testing without introducing risks into the production 
environment and other sensitive environments. For this reason, CME 
suggested making annual internal penetration testing an objective 
rather than a requirement, so that covered DCMs and SDRs can prioritize 
truly effective testing over less skilled testing done merely to check 
the annual requirement box. MGEX called for the final rule to leave the 
frequency of penetration testing to be determined by regulatees. The 
Commission notes that the minimum annual frequency requirement is 
supported by generally accepted standards and best practices, which 
make it clear that such testing at least annually is essential to 
adequate system safeguards in today's cybersecurity environment.\202\ 
Thus, the Commission disagrees with the suggestions that annual 
internal penetration should be a mere objective, or that the frequency 
of such testing by covered DCMs and SDRs should be left to 
determination by those entities themselves. The Commission also notes 
that the final rule requires all DCMs, SEFs, and SDRs to conduct such 
testing as frequently as indicated by appropriate risk analysis.
---------------------------------------------------------------------------

    \200\ 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).
    \201\ Based on the information from the DMO Preliminary Survey, 
the Commission understands that most large DCMs and SDRs currently 
conduct internal penetration testing at the minimum frequency 
specified in the final rule.
    \202\ PCI DSS standards, at 96 through 97, available at https://www.pcisecuritystandards.org/security_standards/index.php.
---------------------------------------------------------------------------

(d) Cost Estimates for Covered DCMs and SDRs
    The Commission did not receive comments addressing the total costs 
for conducting internal penetration testing. However, 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. 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. The 
Commission also recognizes that large DCMs and SDRs may undertake an 
evaluation, on an initial and ongoing basis, regarding internal 
policies and procedures for internal penetration testing that may need 
to be revised. The Commission believes that these costs will be minor.
(3) Benefits
    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.'' \203\
---------------------------------------------------------------------------

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

    As discussed above in the costs section for this provision, the 
final rules address the required minimum frequency for covered DCMs and 
SDRs to perform internal penetration testing. Best practices support 
both 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.\204\ 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.\205\ 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.\206\ The Commission 
believes the specified frequency levels will increase the likelihood 
that the affected entities will be adequately protected against the 
level of cybersecurity threat now affecting the financial sector.
---------------------------------------------------------------------------

    \204\ NIST, SP 800-115, Technical Guide to Information Security 
Testing and Assessment, Section 5.2.2, at 5-5, available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
    \205\ FFIEC, Information Security IT Examination Handbook, at 
82, available at http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
    \206\ PCI DSS, Requirements 11.3.1 and 11.3.2., available at 
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf.
---------------------------------------------------------------------------

i. Controls Testing: Sec. Sec.  38.1051(h)(5), 37.1401(h)(5), and 
49.24(j)(5)
(1) Summary of Final Rules
    The final rules 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. Additionally, the final rules 
require a DCM, SEF, or an SDR to conduct controls testing that is 
sufficient to satisfy the scope requirements in new Sec. Sec.  
38.1051(k), 37.1401(k), and 49.24(l), at a frequency determined by an 
appropriate risk analysis. Covered DCMs and SDRs are required to test 
the key controls in the entity's risk analysis and oversight no less 
frequently than every three years. Such testing may be conducted on a 
rolling basis over the course of the minimum three-year period or over 
a minimum period determined by an appropriate risk analysis, whichever 
is shorter. Covered DCMs and SDRs also are required to engage 
independent contractors to test and assess their key controls no less 
frequently than every three years. The entities may conduct any other 
controls testing by using either independent contractors or employees 
of the DCM or SDR who are not responsible for development or operation 
of the systems or capabilities being tested.
(2) Costs and Discussion of Comments
(a) Controls Testing for All DCMs, SEFs, and SDRs
    As stated in the NPRM and above in the Baseline discussion, the Act 
requires each DCM, SEF, and SDR to develop and maintain a program of 
system safeguards-related risk analysis and

[[Page 64302]]

oversight to identify and minimize sources of operational risk.\207\ 
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.\208\
---------------------------------------------------------------------------

    \207\ 80 FR 80139, 80164, 80172 (Dec. 23, 2015). 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).
    \208\ Id.
---------------------------------------------------------------------------

    The Commission's current 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.\209\ The Commission believes, as 
the generally accepted standards and best practices noted in the NPRM 
make clear, that it is essentially impossible for a DCM, SEF, or SDR to 
fulfill its current obligation to conduct testing sufficient to ensure 
the reliability, security, and capacity of its automated systems 
without conducting controls testing.\210\ If compliance with the 
current testing requirements as clarified by the final 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 are 
attributable to compliance with the current rules and not to the final 
rules. Accordingly, the Commission believes that clarifying the rules 
will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \209\ 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).
    \210\ 80 FR 80139, 80172 (Dec. 23, 2015). See, e.g., NIST 800-
53A, Rev. 1, at 13 and Appendix F1, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------

(b) Controls Testing Frequency Requirement for Covered DCMs and SDRs
    The final rules require a covered DCM or SDR to test each key 
control included in its program of system safeguards-related risk 
analysis and oversight no less frequently than every three years rather 
than the two-year cycle proposed in the NPRM. The Commission's current 
rules require DCMs and SDRs to conduct regular, periodic, objective 
testing of their automated systems.\211\ Therefore, the final rules 
will impose new costs relative to the requirements of the current 
rules.\212\ CME commented that some less critical controls do not 
warrant testing on a two-year cycle, and cited best practices 
permitting controls testing on a three-year cycle. CME suggested that 
the final rule should call for the minimum controls testing frequency 
for covered DCMs and SDRs to be determined by risk analysis (as the 
NPRM proposed for non-covered DCMs and SEFs), or alternatively that a 
minimum frequency cycle of three years would be a reasonable 
alternative to the NPRM's proposed two-year cycle. CME also suggested 
that, while many organizations will implement a two-year schedule for 
at least the testing of key controls, either of CME's proposed 
alternatives would make controls testing more cost effective, and 
increase focus on the most critical controls. The Commission agrees 
that a three-year rather than two-year minimum controls testing 
frequency requirement for covered DCMs and SDRs may reduce costs and 
burdens, while providing beneficial flexibility in overall controls 
testing program design and still ensuring that the fundamental purposes 
of the CEA and the Commission's system safeguards rules are achieved.
---------------------------------------------------------------------------

    \211\ 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).
    \212\ Based on the information collected in the DMO Preliminary 
Survey, the Commission understands that at least some of the large 
DCMs and SDRs currently conduct key controls testing at the 
frequency level specified in the final rule.
---------------------------------------------------------------------------

(c) Independent Contractor Requirement for Covered DCMs and SDRs
    The final rules also require a DCM or SDR to engage an independent 
contractor to test and assess the key controls no less frequently than 
every three years. Current Commission regulations Sec. Sec.  38.1051(h) 
and 49.24(j) provide that testing of automated systems should be 
conducted by qualified, independent professionals. 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 
final rules will impose new costs relative to the requirements of the 
current rules.\213\ CME commented that, while independent contractor 
controls testing may be beneficial, the final rule should not exclude 
controls testing by independent employees, such as internal audit 
staff. DDR also commented that, where the NPRM proposed to require 
independent contractor testing, the final rule should give flexibility 
to use either independent contractors or independent employees. ICE 
suggested that the final rule should not require key controls testing, 
by independent contractors or otherwise, because it imposes a large 
burden for little or no practical improvement in security. The 
Commission notes that generally accepted standards and best practices 
call for key controls testing by independent contractors.\214\ 
Therefore, the Commission disagrees with comments suggesting that the 
final rule should not require testing of key controls by independent 
contractors. Independent contractor testing of key controls will 
strengthen Commission oversight of system safeguards by providing an 
important, credible third source of information concerning crucial 
safeguards in addition to what is available from covered DCM or SDR 
staff and from the internal audit function of those entities. While the 
Commission recognizes that covered DCMs and SDRs will incur additional 
costs to engage independent contractors, the Commission believes that 
extending the minimum testing frequency for such testing by independent 
contractors from two to three years will reduce costs and burdens.
---------------------------------------------------------------------------

    \213\ Based on the information collected in the DMO Preliminary 
Survey, the Commission understands that most large DCMs and SDRs 
currently engage independent contractors to conduct key controls 
testing.
    \214\ NIST SP 800-53A Rev. 4, at 17-18, available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
---------------------------------------------------------------------------

(d) Cost Estimates for Covered DCMs and SDRs
    Based on the information from the DMO Preliminary Survey, the 
Commission estimates that the average cost for a covered DCM or SDR to 
conduct controls testing is approximately $2,724,000 annually.\215\ As 
discussed above in the costs section concerning the minimum frequency 
and independent contractor requirements, the final rules will impose 
new costs on covered DCMs and SDRs. CME estimated that conducting 
controls testing in the manner proposed by the Commission will result 
in an additional cost of $5.6 million over a two-year period. However, 
the Commission believes that the modification of the minimum frequency 
requirement from two to three years will reduce costs and burdens. 
Consistent with all of the system safeguard-related tests required

[[Page 64303]]

in the final rules, 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 
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 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 current policies and procedures to ensure that they 
are sufficient in the context of the new requirements. The Commission 
believes that any costs incurred by the entities as result of such 
review will be minor.
---------------------------------------------------------------------------

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

(3) Benefits
    Controls testing is essential in determining risk to an 
organization's operations and assets, to individuals, to other 
organizations, and to the nation resulting from the use of the 
organization's systems.\216\ In other words, controls testing is vital 
because it allows firms to be nimble in preventing, detecting, or 
recovering from an attack.\217\ The Commission believes that the 
complex analysis and plan preparation that DCMs, SEFs, and SDRs 
undertake with respect to controls testing, including designing and 
implementing changes to existing plans, likely contributes to a better 
understanding by management of the challenges the entity would face in 
a cyber threat scenario. Consequently, these entities should be better 
prepared to meet these challenges. This improved preparation also would 
help reduce the possibility of market disruptions and financial losses 
to market participants. Moreover, regularly conducting controls testing 
enables DCMs, SEFs, and SDRs to mitigate the impact that a cyber threat 
to, or a disruption of, operations would have on market participants, 
and more broadly, the stability of the U.S. financial markets. 
Accordingly, the Commission believes that such testing strengthens 
DCMs, SEFs, and SDRs automated systems, thereby protecting market 
participants and swaps data reporting parties from a disruption in 
services.
---------------------------------------------------------------------------

    \216\ 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: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
    \217\ CFTC Roundtable, at 43-44.
---------------------------------------------------------------------------

    As noted above in the costs section for this provision, the final 
rules require a covered DCM or SDR to test each key control included in 
its program of system safeguards-related risk analysis oversight no 
less frequently than every three years. The Commission believes that it 
is essential for each key 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 final rules also permit such testing to be conducted 
on a rolling basis over the course of the three-year period or over a 
minimum period determined by an appropriate risk analysis, whichever is 
shorter. The rolling basis provision is designed to provide a covered 
DCM or SDR flexibility in conducting the key controls testing during 
the required minimum frequency period. This flexibility is intended to 
reduce burdens 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.\218\
---------------------------------------------------------------------------

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

    Additionally, the final rules 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 three years. 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.\219\ Accordingly, in light of best 
practices and the current cyber threat level to the financial sector, 
the Commission believes that the covered DCM and SDR independent 
contractor testing requirement for key controls would provide these 
substantial benefits.
---------------------------------------------------------------------------

    \219\ Id.
---------------------------------------------------------------------------

j. Security Incident Response Plan Testing: Sec. Sec.  38.1051(h)(6), 
37.1401(h)(6), and 49.24(j)(6)
(1) Summary of Final Rules
    The final rules define security incident response testing as 
testing of a DCM's, SEF's, or SDR's security incident 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, the methods of conducting security 
incident response plan testing may include checklist completion, walk-
through or table-top exercises, simulations, and comprehensive 
exercises. The final rules 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. All DCMs, SEFs, and 
SDRs may conduct such testing by engaging either independent 
contractors or employees of the entity.
(2) Costs and Discussion of Comments
(a) Requirement To Maintain and Test a Security Incident Response Plan 
for All DCMs, SEFs, and SDRs
    As stated in the NPRM and above in the Baseline discussion, 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.\220\ 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.\221\
---------------------------------------------------------------------------

    \220\ 80 FR 80139, 80164, 80174 (Dec. 23, 2015). 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).
    \221\ Id.
---------------------------------------------------------------------------

    The Commission's current system safeguards rules for DCMs, SEFs, 
and SDRs mandate that, in order to achieve

[[Page 64304]]

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.\222\ The 
Commission believes, as the generally accepted standards and best 
practices noted in the NPRM make clear, that it is essentially 
impossible for a DCM, SEF, or SDR to fulfill its current obligation to 
conduct testing sufficient to ensure the reliability, security, and 
capacity of its automated systems without conducting security incident 
response plan testing.\223\ If compliance with the current testing 
requirements as clarified by the final 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 are attributable to 
compliance with the current rules and not to the final rules. 
Accordingly, the Commission believes that clarifying the rules will not 
impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \222\ 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).
    \223\ 80 FR 80139, 80174 (Dec. 23, 2015). See, e.g., NIST 800-
53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------

    As noted in the preamble, Tradeweb agreed that having a security 
incident response plan is essential to the functioning of a SEF, but 
suggested that the plan need only be reviewed annually and approved by 
an individual at the SEF in charge of information security. Tradeweb 
commented that requiring repeated testing of such plans is burdensome 
and unduly costly. The Commission disagrees with the suggestion that 
the requirement to test the security incident response plan should be 
reduced to mere annual review and approval of the plan by an employee 
responsible for information security. Best practices emphasize that 
security incident response plan testing is crucial to effective cyber 
incident response in today's cybersecurity environment.\224\ The 
Commission notes that failure to practice the cyber incident response 
process can delay or paralyze timely response and cause severe 
consequences. While the Commission recognizes that security incident 
response testing will impose costs, these costs are attributable to the 
current requirements.
---------------------------------------------------------------------------

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

(b) Security Incident Response Plan Testing by Independent Contractors 
or Employees of the DCM, SEF, or SDR
    The NPRM called for all DCMs, SEFs, and SDRs to have security 
incident response plan testing by either independent contractors or 
employees not responsible for development or operation of the systems 
or capabilities tested.\225\ CME suggested that the Commission permit 
an independent employee responsible for incident response both design 
an organization's security incident response plan and be responsible 
for testing the plan. CME stated that this would allow an entity to 
leverage its employees with expertise in crisis and risk management and 
in incident response and planning, for both planning and testing 
purposes, in a way that is optimal for the entity's system safeguards. 
The Commission has considered CME's suggestion and believes that this 
could provide useful benefits and flexibility to all DCMs, SEFs, and 
SDRs, without impairing the purposes of the CEA and the Commission's 
regulations which security incident response plan testing is designed 
to advance. Accordingly, the final rules require security incident 
response plan testing by all DCMs, SEFs, and SDRs to be conducted by 
either independent contractors or entity employees, without restricting 
which employees may lead or conduct the testing.
---------------------------------------------------------------------------

    \225\ Id. at 80157.
---------------------------------------------------------------------------

(c) Security Incident Response Plan Testing Frequency Requirement for 
Covered DCMs and SDRs
    The final rules require covered DCMs and SDRs to conduct security 
incident response plan testing at least annually. The Commission's 
current rules require DCMs and SDRs to conduct regular, periodic, 
objective testing of their automated systems.\226\ Accordingly, the 
final rules will impose new costs relative to the requirements of the 
current rules. The Commission notes that annual security incident 
response plan testing is consistent with industry best practices.\227\
---------------------------------------------------------------------------

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

(d) Cost Estimates for Covered DCMs and SDRs
    The Commission did not receive any comments addressing the costs of 
conducting security incident response plan testing for covered DCMs and 
SDRs. To the extent that the final rules 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 its automated systems, and the scope of 
the test.\228\ Additional costs incurred by the affected entities could 
include time in reviewing and revising current 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 new requirements. In such cases, the Commission believes that any 
costs would be minimal.
---------------------------------------------------------------------------

    \228\ Based on the Commission's experience in administering the 
system safeguard compliance program, the Commission believes that 
many large DCMs and SDRs currently conduct security incident 
response plan testing at the minimum frequency specified in the 
final rule.
---------------------------------------------------------------------------

(3) 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 an entity'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 final rules provide clarity to covered DCMs and SDRs concerning 
the minimum testing frequency for security incident response plans. The 
Commission believes that the 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 its automated system 
operation, reliability, security, or capacity; or the availability, 
confidentiality, or integrity of its futures and swaps data.
k. Enterprise Technology Risk Assessment: Sec. Sec.  38.1051(h)(7), 
37.1401(h)(7), and 49.24(j)(7)
(1) Summary of Final Rules
    The final rules define enterprise technology risk assessment as an 
assessment that includes an analysis of threats and vulnerabilities in 
the context

[[Page 64305]]

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 final rules require covered DCMs and SDRs to 
conduct an ETRA at a frequency determined by an appropriate risk 
analysis, but at a minimum no less frequently than annually. The final 
rules provide that all DCMs, SEFs, and SDRs may conduct ETRAs by using 
independent contractors, or employees of the entity who are not 
responsible for development or operation of the systems or capabilities 
being assessed.
(2) Costs and Discussion of Comments
(a) ETRAs for All DCMs, SEFs, and SDRs
    As stated in the NPRM and above in the Baseline discussion, 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.\229\ 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.\230\
---------------------------------------------------------------------------

    \229\ 80 FR 80139, 80164, 80175 (Dec. 23, 2015). 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).
    \230\ Id.
---------------------------------------------------------------------------

    The Commission's current 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.\231\ The Commission believes, as 
the generally accepted standards and best practices noted in the NPRM 
make clear, that it is essentially impossible for a DCM, SEF, or SDR to 
fulfill its current obligation to conduct testing sufficient to ensure 
the reliability, security, and capacity of its automated systems 
without conducting ETRAs.\232\ If compliance with the current testing 
requirements as clarified by the final 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 are attributable to 
compliance with the current rules and not to the final rules. 
Accordingly, the Commission believes that clarifying the rules will not 
impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------

    \231\ 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).
    \232\ 80 FR 80139, 80175 (Dec. 23, 2015). See, e.g., NIST 800-
53A, Rev.1, at F226, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------

(b) ETRAs by Independent Contractors or Employees of the DCM, SEF, or 
SDR
    The Commission did not receive any comments addressing the costs of 
the proposed rules which called for ETRAs to be conducted by either 
independent contractors or employees not responsible for development or 
operation of the systems or capabilities. The Commission is adopting 
the proposed requirements and all DCMs, SEFs, and SDRs will have the 
same flexibility in the final rules.
(c) ETRA Frequency Requirement for Covered DCMs and SDRs
    The final rules require covered DCMs and SDRs to conduct ETRAs at 
least annually. The Commission's current rules require DCMs and SDRs to 
conduct regular, periodic, objective testing of their automated 
systems.\233\ Therefore, the final rules will impose new costs relative 
to the requirements of the current rules.\234\ CME suggested that ETRAs 
would benefit from incorporating the results of controls testing and 
other testing, and suggested that it would be beneficial and less 
costly to align the requirement for completing an ETRA with the 
applicable frequency requirement for controls testing. Tradeweb 
suggested that an annual full assessment would be burdensome and 
costly, and suggested that, in lieu of repeated full assessments, 
annual review and approval of previous assessments should be 
sufficient. The Commission believes that, as best practices provide, 
regularly updated ETRAs are crucial to the effectiveness of system 
safeguards in today's rapidly changing cybersecurity environment.\235\ 
The Commission does not accept the suggestion that ETRAs should only be 
required as often as a complete cycle of controls testing is completed, 
not least because the final rule is adopting the suggestion to lengthen 
that cycle to three rather than two years. Because ETRAs that provide 
current assessment of current risks are essential to effective programs 
of system safeguards risk analysis and oversight, the Commission 
disagrees with the suggestion that annual review and re-approval of 
previous assessments would be sufficient. However, the Commission 
believes that thorough updating of a previous assessment conducted in 
compliance with the ETRA requirements set out in the NPRM can be 
sufficient to fulfill the purposes of an appropriate ETRA, and can 
reduce costs and burdens without impairment of the purposes of the CEA 
and the system safeguards rules. Accordingly, the final rules clarify 
that such updating of a previous fully compliant ETRA, in light of 
current risks and circumstances, can fulfill the ETRA requirement.
---------------------------------------------------------------------------

    \233\ 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).
    \234\ Based on the information from the DMO Preliminary Survey, 
the Commission understands that most large DCMs and SDRs currently 
conduct ETRAs at the minimum frequency specified in the final rule.
    \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.
---------------------------------------------------------------------------

(d) Cost Estimates for Covered DCMs and SDRs
    CME estimated that the Commission's proposed ETRA requirement would 
result in an additional cost of $500,000 every two years. Based on the 
information from the DMO Preliminary Survey, 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. 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 will be minor.
(3) 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 align their systems goals accordingly. The Commission believes that 
these requirements are necessary to support a strong risk management 
framework, thereby helping to protect DCMs, SEFs, SDRs, and market 
participants, and helping to mitigate the risk of market disruptions.
    The final rules provide clarity to covered DCMs and SDRs concerning 
the

[[Page 64306]]

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.\236\ The 
Commission believes that the frequency requirement would better 
position covered DCMs and SDRs to identify, estimate, and prioritize 
the risks facing them in today's cybersecurity threat environment.
---------------------------------------------------------------------------

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

l. Scope for Testing and Assessment: Sec. Sec.  38.1051(k), 37.1401(k), 
and 49.24(l)
(1) Summary of Final Rules
    The final rules provide that the scope for all system safeguards 
testing and assessment must be broad enough to include the testing of 
automated systems and controls that the entity's required program of 
risk analysis and oversight and its current cybersecurity threat 
analysis indicate is necessary to identify risks and vulnerabilities 
that 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 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.
(2) Costs and Benefits and Discussion of Comments
    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 generally 
discussed in the cost and benefit considerations related to the rules 
describing the requirements for each test or assessment. However, as 
discussed in the preamble, a number of commenters suggested that the 
scope provisions of the NPRM were overbroad, and that the proposed 
requirement to perform ``all'' testing necessary to identify ``any'' 
vulnerability was impossible to achieve in practice. CME suggested that 
the NPRM's overbroad scope provision could impose outsized costs 
without yielding commensurate benefits. In order to provide the clarity 
requested by commenters, the final rules call for the scope of system 
safeguards testing to be based on appropriate risk and threat analysis. 
In other words, it should include the testing that the regulatee's 
program of risk analysis and oversight and its current cybersecurity 
threat analysis indicate is necessary to identify risks and 
vulnerabilities that could enable the deleterious actions by intruders 
or unauthorized users listed in the scope provisions of the proposed 
rules. The Commission agrees with the comments suggesting that this 
approach avoids imposing undue burdens and costs, while supporting the 
purposes of the CEA and the Commission's system safeguards rules.
m. Internal Reporting and Review: Sec. Sec.  38.1051(l), 37.1401(l), 
and 49.24(m)
(1) Summary of Final Rules
    The final rules 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 the 
respective sections. In addition, the final rules require the DCM, SEF, 
or SDR to establish and follow appropriate procedures for the 
remediation of issues identified through such review, as provided in 
Sec. Sec.  38.1051(m), 37.1401(m), and 49.24(n) (Remediation), and for 
evaluation of the effectiveness of testing and assessment protocols.
(2) Costs and Discussion of Comments
    The final rules 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. As stated in the NPRM, 
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.\237\ The Commission believes, as the generally accepted 
standards and best practices noted in the NPRM make clear, that it is 
essentially impossible for a DCM, SEF, or SDR to fulfill its current 
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.\238\ If 
compliance with the current testing requirements as clarified by the 
final 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 current regulations and 
not to the final rules. Accordingly, the Commission believes that 
clarifying the rules will not impose any new costs for DCMs, SEFs, and 
SDRs.
---------------------------------------------------------------------------

    \237\ 80 FR 80139, 80176 (Dec. 23, 2015).
    \238\ See, e.g., NIST SP 800-115, Technical Guide to Information 
Security Testing and Assessment, at 6-10--6-12, September 2008, 
available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

    ICE, MGEX, and Nadex commented that test result reports can be 
voluminous, technical, and complex, and that requiring boards and 
senior management to review each such document could produce an undue 
burden without commensurate benefits. As discussed in the preamble, the 
Commission notes that effective board of directors and senior 
management oversight of system safeguards does not require board or 
senior management review of every detail of each such report. Board and 
senior management review of appropriate summaries and compilations of 
test and assessment results can be an effective and acceptable way of 
fulfilling the internal reporting and review requirement, provided that 
such summaries give board members and senior management sufficiently 
detailed information to enable them to conduct effective and informed 
oversight. The appropriate level of information should also enable 
boards and senior management to evaluate the overall effectiveness of 
testing and assessment protocols, and direct and oversee appropriate 
remediation of issues identified through their review of test results.
(3) 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,

[[Page 64307]]

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 their automated systems.
n. Remediation: Sec. Sec.  38.1051(m), 37.1401(m), and 49.24(n)
(1) Summary of Final Rules
    The final rules require DCMs, SEFs, and SDRs to identify and 
document the vulnerabilities and deficiencies in the entity's systems 
revealed by the testing and assessment in the respective sections. The 
entity shall conduct and document an appropriate risk analysis of the 
risks presented by such vulnerabilities and deficiencies, to determine 
and document whether to remediate or accept each risk. When an entity 
determines to remediate a vulnerability or deficiency, it must 
remediate in a timely manner given the nature and magnitude of the 
associated risk. The Commission did not receive any comments regarding 
the costs and benefits of the proposed rules.
(2) Costs and Discussion of Comments
    The final rules 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. As stated in the NPRM, remediation of 
vulnerabilities and deficiencies revealed by cybersecurity testing is a 
best practice and a fundamental purpose of such testing.\239\ The 
Commission believes, as the generally accepted standards and best 
practices noted in the NPRM make clear, that it is essentially 
impossible for a DCM, SEF, or SDR to fulfill its current obligation to 
conduct testing sufficient to ensure the reliability, security, and 
capacity of its automated systems without performing remediation.\240\ 
If compliance with the current testing requirements as clarified by the 
final 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 current regulations and 
not to the final rules. Accordingly, the Commission believes that 
clarifying the rules will not impose any new costs for DCMs, SEFs, and 
SDRs. However, as discussed below, the Commission is amending two 
aspects in the final rules where it believes the net effect will reduce 
the overall costs and burdens relative to the proposed rules.
---------------------------------------------------------------------------

    \239\ 80 FR 80139, 80167 (Dec. 23, 2015).
    \240\ See, e.g., NIST SP 800-115, Technical Guide to Information 
Security Testing and Assessment, at 6-10--6-12, September 2008, 
available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------

    Nadex and Tradeweb suggested that the proposed requirement to 
identify and remediate ``all'' vulnerabilities and deficiencies in a 
regulatee's systems was impossible to achieve in practice. Nadex 
observed that other discussion in the NPRM indicated Commission intent 
to require remediation of vulnerabilities and deficiencies identified 
in the testing results, and suggested amending the final rule to make 
this clear. Noting that remediation after a cyber attack often takes 
time, Tradeweb argued that regulatees should not be penalized for that 
fact, and requested Commission guidance on what constitutes timely 
remediation, perhaps including specification that remediation over nine 
to twelve months would be timely. As discussed in the preamble, the 
Commission agrees with commenters that a requirement calling for a DCM, 
SEF, or SDR to remediate all vulnerabilities and deficiencies could be 
read as overbroad and impossible in practice. Accordingly, the 
Commission is narrowing the remediation requirement to address 
remediation or acceptance of the vulnerabilities and deficiencies of 
which an entity is aware or through an appropriate program of risk 
analysis and oversight should be aware, rather than the remediation of 
all vulnerabilities and deficiencies. This revision is being made to 
reduce burdens and costs to the extent possible without impairing the 
purposes of the CEA and the Commission's system safeguards regulations.
    The aspect of the final rules that could impose a slight additional 
cost relative to the proposed rules is the explicit requirement that 
all DCMs, SEFs, and SDRs document the vulnerabilities and deficiencies 
in its systems revealed by the required testing and assessment, 
document an appropriate analysis of the risks presented by such 
vulnerabilities, and document its decision concerning whether to 
remediate or accept each risk and the remediation steps chosen. As 
stated in the preamble, the NPRM proposal to require identification of 
vulnerabilities was intended to include their documentation. Effective 
remediation would be impossible without documentation of both the 
vulnerabilities in question and the remediation steps needed. However, 
because documentation was not explicitly required in the proposal, the 
Commission is treating the documentation requirement in the final rules 
as a possible slight additional cost. The Commission notes, however, 
that the narrowing of remediation requirement in the final rules 
represents a considerable reduction in burdens and costs and will more 
than offset the burdens and costs associated with the documentation 
requirement.
(3) Benefits
    The Commission believes that effective remediation is a critical 
component of a comprehensive and effective system safeguard program. 
Moreover, remediation may reduce the frequency and severity of systems 
disruptions and breaches. In addition, remediation helps to ensure that 
DCMs, SEFs, and SDRs dedicate appropriate resources to address system 
safeguard-related deficiencies in a timely fashion. Remediation also 
places an emphasis on mitigating harm to market participants while 
promoting market integrity. Without a requirement for timely 
remediation, 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.
o. Required Production of Annual Trading Volume: Sec.  38.1051(n)
(1) Summary of Final Rule
    The final rule requires each DCM to provide its annual total 
trading volume to the Commission for calendar year 2015 and each 
calendar year thereafter. This information is required for 2015 within 
30 calendar days of the effective date of the final version of this 
rule, and required for 2016 and subsequent years by January 31 of the 
following calendar year.
(2) Costs and Discussion of Comments
    As discussed in the PRA section, the Commission did not receive any 
comments concerning the accuracy of its estimate that each DCM would 
spend approximately $22.00 annually to comply with the proposed 
requirement. However, CME stated that the Commission should consider 
alternatives to the reporting requirements in proposed Sec.  38.1051(n) 
because the Commission currently receives daily trade reports regarding 
volume pursuant to DCM Core Principle 8 and part 16 of the Commission's 
regulations. The Commission notes that while it receives daily trade 
information from DCMs pursuant to part 16, it does not receive total 
annual trading volume

[[Page 64308]]

from DCMs. Additionally, the Commission believes that Core Principle 8 
is inapplicable because it requires DCMs to publish daily volume, but 
does not require submission of that information to the Commission. The 
submission of annual trading volume is essential for the Commission to 
accurately evaluate whether a particular DCM must comply with the 
enhanced system safeguard requirements. 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. The Commission also believes that each 
DCM would spend approximately half an hour to prepare and file the 
trading volume information with Commission at a cost of approximately 
$24.80 annually.\241\
---------------------------------------------------------------------------

    \241\ 80 FR 80139, 80177 (Dec. 23, 2015). 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 (2015 Report). The hourly rate for a 
Compliance Officer in the Securities and Commodity Exchanges as 
published in the 2015 Report was $49.59 per hour. In the NPRM, the 
Commission's estimate of $22.00 per respondent was based on the 
hourly wage of $44.03 for a Compliance Officer in the 2014 Report. 
80 FR 80139, 80163 (Dec. 23, 2015).
---------------------------------------------------------------------------

(3) Benefits
    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 enhanced covered DCM 
requirements. As stated in the final 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 
within 60 calendar days of the effective date of the final rule, and 
for subsequent years by February 28. Therefore, all DCMs will receive 
certainty from the Commission regarding whether they must comply with 
the provisions applicable to covered DCMs. This requirement will 
support more accurate application of the final rules.
4. Section 15(a) Factors
a. Protection of Market Participants and the Public
    The Commission believes that the final rules will 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. Fewer disruptions mean that 
investors will be able to trade more predictably, reducing the 
likelihood of investors facing difficulty in, for example, liquidating 
positions. 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 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 is essential to mitigation of systemic 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 lost.\242\ 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. 
Because SDRs hold data needed by financial regulators from multiple 
jurisdictions, safeguarding such systems will also be essential to 
mitigation of systemic risk world-wide. Notice to the Commission 
concerning the results of system safeguard tests performed by 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.
---------------------------------------------------------------------------

    \242\ 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 by preventing prices from adjusting to new 
information. Similarly, any interruption in the operations of an SDR 
will reduce the transparency of swap prices, thereby making it more 
difficult for traders to observe prices, and leading to the potential 
for higher trading costs. Interruptions in SDR operations also 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 final 
rules will reduce the incidence and severity of automated system 
security breaches and functional failures. In addition, the Commission 
views the final 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.

[[Page 64309]]

d. Sound Risk Management Practices
    The final 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 likewise serve to allow participants to 
better observe swap prices, hence lowering trading costs. Fewer 
interruptions of SDR operations also 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.
5. Antitrust Considerations
    Section 15(b) of the CEA requires the Commission to take into 
consideration the public interest to be protected by the antitrust laws 
and endeavor to take the least anticompetitive means of achieving the 
objectives of the CEA in issuing any order or adopting any Commission 
rule or regulation. The Commission does not anticipate that the 
amendments adopted herein would promote or result in anticompetitive 
consequences or behavior.

IV. Compliance Dates

A. Comments Received

    For final rules issued by the Commission and published in the 
Federal Register, the Commission has discretion to set both the date on 
which a final rule becomes effective following its publication (the 
``effective date'') and the date on which it will begin enforcement of 
regulatory provisions (the ``compliance date'').\243\ In setting forth 
effective dates and compliance dates, the Commission considers the 
nature and particular provisions of the rule in question, comments 
received, available enforcement resources, and the goals and purposes 
of the CEA and the rule.
---------------------------------------------------------------------------

    \243\ See Heckler v. Chaney, 470 U.S. 821 (1985).
---------------------------------------------------------------------------

    The Commission received comments concerning when full compliance 
with the provisions of the system safeguards testing requirements rule 
should be enforced for designated contract markets, swap data 
repositories, and swap execution facilities. Tradeweb suggested that 
the Commission specify an adequate implementation period of 9 to 12 
months for the final rule, to allow regulatees sufficient time to 
prepare and implement additional policies and procedures needed to 
comply with the rule. CFE commented that the Commission should provide 
an implementation period sufficient to allow regulatees to review the 
final rules, compare them with their current testing and current risk 
analysis and oversight programs, and implement any changes needed. CFE 
noted that when the Securities and Exchange Commission (``SEC'') 
adopted its comparable Regulation Systems Compliance and Integrity 
(``Regulation SCI''), that regulation became effective 60 days after 
Federal Register publication, and the SEC adopted a compliance date of 
nine months after the effective date. CFE urged the Commission to take 
the same approach.
    The Commission has considered these comments, agrees with them, and 
has determined to provide an effective date and compliance dates for 
system safeguards testing effectively incorporating commenters' 
suggestions, as set forth below.
    The Commission notes that various aspects of the final rule require 
compliance within a specified period of time, such as performance of 
certain types of testing quarterly or annually. A starting point is 
needed for measurement of such periods. Because cybersecurity testing 
is crucial to resilience in today's cybersecurity threat environment, 
the Commission believes that prudence and protection of the public 
interest require starting the ``clock'' for measuring the periods 
within which the various types of testing required by the final rule 
must be conducted as soon as possible, by setting the earliest possible 
effective date for the rule. Starting the clock in this way does not 
mean that instant compliance is required; rather, the effective date 
provides the starting point for measuring the implementation period 
provided between the effective date and the compliance date on which a 
given provision of the rule is enforceable. Within this implementation 
period, a regulated entity can review the rule's requirements, compare 
them with current testing and risk analysis and oversight practices, 
implement any needed changes, and come into compliance with the rule.
    For these reasons, the Commission has determined to set the 
effective date of this final rule as the date of its publication in the 
Federal Register, and to set the compliance dates applicable to the 
various provisions of the final rule as set forth below.
    1. For vulnerability testing, the compliance date shall be 180 
calendar days after the effective date. DCMs, SEFs, and SDRs must be 
conducting vulnerability testing that complies with this final rule by 
that compliance date.
    2. For both external and internal penetration testing, the 
compliance date shall be one year after the effective date. DCMs, SEFs, 
and SDRs must conduct and complete penetration testing that complies 
with this final rule by that compliance date. Covered DCMs and SDRs 
must engage an independent contractor to conduct and complete 
penetration testing that complies with this final rule by that 
compliance date.
    3. For controls testing, the compliance date shall be one year 
after the effective date. DCMs, SEFs, and SDRs must be conducting 
controls testing that complies with this final rule by that compliance 
date. Covered DCMs and SDRs must engage an independent contractor to 
conduct and complete testing of all key controls within three years of 
the effective date.
    4. For SIRP testing, the compliance date shall be 180 days after 
the effective date. DCMs, SEFs, and SDRs must have a SIRP and complete 
testing of the SIRP by that compliance date.
    5. For enterprise technology risk assessment, the compliance date 
shall be one year after the effective date. DCMs, SEFs, and SDRs must 
complete an ETRA that complies with this final rule by that compliance 
date.
    6. For required updating of BC-DR plans and emergency procedures, 
the compliance date shall be one year after the effective date. DCMs, 
SEFs, and SDRs must complete an update of their BC-DR plans and 
emergency procedures by that compliance date.
    7. For required production by DCMs of their annual total trading 
volume, the compliance date shall be 30 calendar days after the 
effective date.

[[Page 64310]]

    8. For system safeguards books and records requirements, the 
compliance date shall be the effective date.
    9. For all other aspects of the final rule, the compliance date 
shall be one year after the effective date. DCMs, SEFs, and SDRs must 
be in full compliance with the final rule by that compliance date.

List of Subjects in 17 CFR Parts 37, 38, and 49

    System safeguards testing requirements.

    For the reasons set forth in the preamble, the Commodity Futures 
Trading Commission amends 17 CFR chapter I as follows:

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 shall 
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 (including 
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 (including network port control, boundary 
defenses, encryption); system and information integrity (including 
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 paragraph (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 (including 
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 (including 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 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 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. A 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 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.
* * * * *
    (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 shall 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;

[[Page 64311]]

    (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 Commission regulations, or in connection with Commission 
maintenance of a current profile of the swap execution facility's 
automated systems.
    (5) Nothing in Sec.  37.1401(g) shall be interpreted as reducing or 
limiting in any way a swap execution facility's obligation to comply 
with Core Principle 10 (Recordkeeping and Reporting) or with Sec.  1.31 
of this chapter or with Sec. Sec.  37.1000 or 37.1001.
    (h) 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. 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 (h) of this section.
    (1) Definitions. As used in this paragraph (h):
    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 requirements established by this section.
    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 jeopardizes or has a significant likelihood of 
jeopardizing 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.
    (i) A swap execution facility shall conduct such vulnerability 
testing at a frequency determined by an appropriate risk analysis.
    (ii) Such vulnerability testing shall include automated 
vulnerability scanning, which shall follow generally accepted best 
practices.
    (iii) A swap execution facility shall conduct vulnerability 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.
    (3) 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.
    (i) A swap execution facility shall conduct such external 
penetration testing at a frequency determined by an appropriate risk 
analysis.
    (ii) A swap execution facility shall conduct external 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.
    (4) 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.
    (i) A swap execution facility shall conduct such internal 
penetration testing at a frequency determined by an appropriate risk 
analysis.
    (ii) A swap execution facility shall 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.
    (5) 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.
    (i) A swap execution facility shall conduct controls testing, which 
includes testing of each control included in its program of risk 
analysis and oversight, at a frequency determined by an appropriate 
risk analysis. Such testing may be conducted on a rolling basis.

[[Page 64312]]

    (ii) A swap execution facility shall conduct controls 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) Security incident response plan testing. A swap execution 
facility shall conduct security incident response plan testing 
sufficient to satisfy the requirements set forth in paragraph (k) of 
this section.
    (i) A swap execution facility shall conduct such security incident 
response plan testing at a frequency determined by an appropriate risk 
analysis.
    (ii) 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.
    (iii) 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.
    (iv) A swap execution facility may conduct security incident 
response plan testing by engaging independent contractors or by using 
employees of the swap execution facility.
    (7) 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.
    (i) A swap execution facility shall conduct enterprise technology 
risk assessment at a frequency determined by an appropriate risk 
analysis. A swap execution facility that has conducted an enterprise 
technology risk assessment that complies with this section may conduct 
subsequent assessments by updating the previous assessment.
    (ii) 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.
    (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 shall be broad 
enough to include the testing of automated systems and controls that 
the swap execution facility's required program of risk analysis and 
oversight and its current cybersecurity threat analysis indicate is 
necessary to identify risks and vulnerabilities that 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 a swap execution facility shall receive and 
review reports setting forth the results of the testing and assessment 
required by this section. A 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 identify and 
document the vulnerabilities and deficiencies in its systems revealed 
by the testing and assessment required by this section. The swap 
execution facility shall conduct and document an appropriate analysis 
of the risks presented by such vulnerabilities and deficiencies, to 
determine and document whether to remediate or accept the associated 
risk. When the swap execution facility determines to remediate a 
vulnerability or deficiency, it must remediate in a timely manner given 
the nature and magnitude of the associated risk.

Appendix B to Part 37 [Amended]

0
3. In appendix B to part 37, in section 2, remove and reserve Core 
Principle 14 of Section 5h of the Act--System Safeguards.

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, 6d, 6e, 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. In Sec.  38.1051, revise paragraphs (a), (b), (c), (g), (h), and 
paragraph (i) introductory text and add paragraphs (k), (l), (m), and 
(n) to 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 shall 
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 (including 
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 (including network port control, boundary 
defenses, encryption); system and information integrity (including 
malware defenses, software integrity monitoring); vulnerability 
management;

[[Page 64313]]

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 designated contract 
market's systems to ensure adequate scalable capacity (including 
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 (including 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 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 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 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.
* * * * *
    (g) As part of a designated contract market's obligation to produce 
books and records in accordance with Sec.  1.31 of this chapter, Core 
Principle 18 (Recordkeeping), and Sec. Sec.  38.950 and 38.951, a 
designated contract market shall 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 Commission regulations, or in connection with Commission 
maintenance of a current profile of the designated contract market's 
automated systems.
    (5) Nothing in this paragraph (g) 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 with Sec.  38.950 or Sec.  38.951.
    (h) A designated contract market 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 this paragraph (h). 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 this paragraph (h).
    (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 requirements established by this section.
    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

[[Page 64314]]

designated contract markets regulated by the Commission for three 
consecutive calendar years ceases to be a covered designated contract 
market as of March 1 of the calendar year following such three 
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 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 jeopardizes or has a significant likelihood of 
jeopardizing 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 paragraph (k) of this section.
    (i) A designated contract market shall conduct such vulnerability 
testing at a frequency determined by an appropriate risk analysis. At a 
minimum, a covered designated contract market shall conduct such 
vulnerability testing no less frequently than quarterly.
    (ii) Such vulnerability testing shall include automated 
vulnerability scanning, which shall follow generally accepted best 
practices.
    (iii) A designated contract market shall conduct vulnerability 
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.
    (3) 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.
    (i) A designated contract market shall conduct such external 
penetration testing at a frequency determined by an appropriate risk 
analysis. At a minimum, a covered designated contract market shall 
conduct such external penetration testing no less frequently than 
annually.
    (ii) 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.
    (iii) A designated contract market which is not a covered 
designated contract market shall conduct external 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) 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.
    (i) A designated contract market shall conduct such internal 
penetration testing at a frequency determined by an appropriate risk 
analysis. At a minimum, a covered designated contract market shall 
conduct such internal penetration testing no less frequently than 
annually.
    (ii) A designated contract market shall 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.
    (5) 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.
    (i) A designated contract market shall conduct controls testing, 
which includes testing of each control included in its program of risk 
analysis and oversight, at a frequency determined by an appropriate 
risk analysis. Such testing may be conducted on a rolling basis. At a 
minimum, a covered designated contract market shall conduct testing of 
its key controls no less frequently than every three years. The covered 
designated contract market may conduct testing of its key controls on a 
rolling basis over the course of three years or the period determined 
by such 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 three 
years. The covered designated contract market may conduct any other 
controls testing required by this section by using independent 
contractors or employees of the covered designated contract market who 
are not responsible for development or

[[Page 64315]]

operation of the systems or capabilities being tested.
    (iii) A designated contract market which is not a covered 
designated contract market shall conduct controls 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) 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.
    (i) A designated contract market shall conduct such security 
incident response plan testing at a frequency determined by an 
appropriate risk analysis. At a minimum, a covered designated contract 
market shall conduct such security incident response plan testing no 
less frequently than annually.
    (ii) 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.
    (iii) 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.
    (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.
    (7) 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.
    (i) A designated contract market shall conduct an enterprise 
technology risk assessment at a frequency determined by an appropriate 
risk analysis. At a minimum, a covered designated contract market shall 
conduct an enterprise technology risk assessment no less frequently 
than annually. A designated contract market that has conducted an 
enterprise technology risk assessment that complies with this section 
may conduct subsequent assessments by updating the previous assessment.
    (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 shall be broad 
enough to include the testing of automated systems and controls that 
the designated contract market's required program of risk analysis and 
oversight and its current cybersecurity threat analysis indicate is 
necessary to identify risks and vulnerabilities that 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 a designated contract market shall receive 
and review reports setting forth the results of the testing and 
assessment required by this section. A designated contract market 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 designated contract market shall identify and 
document the vulnerabilities and deficiencies in its systems revealed 
by the testing and assessment required by this section. The designated 
contract market shall conduct and document an appropriate analysis of 
the risks presented by such vulnerabilities and deficiencies, to 
determine and document whether to remediate or accept the associated 
risk. When the designated contract market determines to remediate a 
vulnerability or deficiency, it must remediate in a timely manner given 
the nature and magnitude of the associated risk.
    (n) Required production of annual total trading volume. (1) As used 
in this paragraph, 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. No. 111-203, 
124 Stat. 1376 (2010), unless otherwise noted.

0
7. In Sec.  49.24, revise paragraphs (b), (c), (d), (i), (j), and 
paragraph (k) introductory text and add paragraphs (l), (m), and (n) to 
read as follows:


Sec.  49.24  System Safeguards.

* * * * *
    (b) A swap data repository's program of risk analysis and oversight 
with respect to its operations and automated systems shall 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;

[[Page 64316]]

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 (including 
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 (including network port control, boundary 
defenses, encryption); system and information integrity (including 
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 paragraph (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 swap data repository's 
systems to ensure adequate scalable capacity (including 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 (including 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 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 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 the 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 shall 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 and 45.2 of this chapter, or with Sec.  
49.12.
    (j) A 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 this paragraph.
    (1) Definitions. As used in this paragraph (j):
    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 requirements established by this section.
    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 identify and exploit vulnerabilities.

[[Page 64317]]

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 jeopardizes or has a significant likelihood of 
jeopardizing 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) A swap data repository shall conduct such vulnerability testing 
at a frequency determined by an appropriate risk analysis, but no less 
frequently than quarterly.
    (ii) Such vulnerability testing shall include automated 
vulnerability scanning, which shall follow generally accepted best 
practices.
    (iii) A swap data repository shall conduct vulnerability 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.
    (3) 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.
    (i) A swap data repository shall conduct such external penetration 
testing at a frequency determined by an appropriate risk analysis, but 
no less frequently than annually.
    (ii) A 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.
    (4) 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.
    (i) A swap data repository shall conduct such internal penetration 
testing at a frequency determined by an appropriate risk analysis, but 
no less frequently than annually.
    (ii) A swap data repository shall 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.
    (5) 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.
    (i) A swap data repository shall conduct controls testing, which 
includes testing of each control included in its program of risk 
analysis and oversight, at a frequency determined by an appropriate 
risk analysis. Such testing may be conducted on a rolling basis. A swap 
data repository shall conduct testing of its key controls no less 
frequently than every three years. The swap data repository may conduct 
testing of its key controls on a rolling basis over the course of three 
years or the period determined by such risk analysis, whichever is 
shorter.
    (ii) A swap data repository 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 three years. The 
swap data repository may conduct any other controls testing required by 
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.
    (6) 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) A swap data repository shall conduct such security incident 
response plan testing at a frequency determined by an appropriate risk 
analysis, but no less frequently than annually.
    (ii) A 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.
    (iii) A 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.
    (iv) A swap data repository may conduct security incident response 
plan testing by engaging independent contractors or by using employees 
of the swap data repository.
    (7) 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) A 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. A swap data repository 
that has conducted an enterprise technology risk assessment

[[Page 64318]]

that complies with this section may conduct subsequent assessments by 
updating the previous assessment.
    (ii) A 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 swap data repository shall:
* * * * *
    (l) Scope of testing and assessment. The scope for all system 
safeguards testing and assessment required by this part shall be broad 
enough to include the testing of automated systems and controls that 
the swap data repository's required program of risk analysis and 
oversight and its current cybersecurity threat analysis indicate is 
necessary to identify risks and vulnerabilities that 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 a swap data repository shall receive and 
review reports setting forth the results of the testing and assessment 
required by this section. A 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 identify and document 
the vulnerabilities and deficiencies in its systems revealed by the 
testing and assessment required by this section. The swap data 
repository shall conduct and document an appropriate analysis of the 
risks presented by such vulnerabilities and deficiencies, to determine 
and document whether to remediate or accept the associated risk. When 
the swap data repository determines to remediate a vulnerability or 
deficiency, it must remediate in a timely manner given the nature and 
magnitude of the associated risk.

    Issued in Washington, DC, on September 9, 2016, 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 Commissioner's Statement

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 the two rules the Commission has finalized 
today.
    The risk of cyberattack probably represents the single greatest 
threat to the stability and integrity of our markets today. 
Instances of cyberattacks are all too familiar both inside and 
outside the financial sector. Today, they often are motivated not 
just by those with a desire to profit, but by those with a desire 
deliberately to disrupt or destabilize orderly operations.
    That is why these system safeguard rules are so important. The 
rules we have finalized today will apply to the core infrastructure 
in our markets--the exchanges, clearinghouses, trading platforms, 
and trade repositories. And they will ensure that those private 
companies are regularly evaluating cyber risks and testing their 
cybersecurity and operational risk defenses. While our rules already 
require this generally, the measures we approved today add greater 
definition--not by being overly prescriptive, but by setting some 
principles-based standards, and requiring specific types of testing, 
all rooted in industry best practices.
    I've said many times that as regulators, we must not just look 
backwards to address the causes of past failures or crises. We also 
must look ahead--ahead to the new opportunities and challenges 
facing our markets. Financial markets constantly evolve, and we must 
ensure our regulatory framework is adapting to these changes.
    These new rules are one good example of how we are looking ahead 
and addressing these new challenges. They will serve as a strong and 
important complement to the many other steps being taken by 
regulators and market participants to address cybersecurity. For 
example, government agencies and market participants are already 
working together to share information about potential threats and 
risks--and learn from one another.
    I want to thank all those who provided feedback on the proposed 
rules the Commission approved last December. We received a number of 
thoughtful comments from market participants, most of which 
expressed broad support for the proposals. Commenters also 
highlighted some areas of concern, and we made adjustments based on 
that feedback. For example, we have reduced the frequency of 
controls testing and narrowed the instances where independent 
contractor testing is required. We have also clarified definitions 
of key terms, and made clear that the scope of required testing will 
be based on appropriate risk and threat analysis.
    I also thank Commission staff for their hard work on these 
measures, particularly our staff in the Division of Market Oversight 
and Division of Clearing and Risk, as well as the support that is 
always provided by staff in the Office of General Counsel, the 
Office of Chief Economist and other staff who comment on the rules. 
I also thank my fellow Commissioners Bowen and Giancarlo for their 
support of and suggestions regarding these final rules.

Appendix 3--Concurring Statement of Commissioner Sharon Y. Bowen

    I will be voting yes on both systems safeguards rules. There is 
not much more to say than what I said when these rules were proposed 
on December 10, 2015.\1\ Cybersecurity is a top concern for American 
companies, especially financial firms. These rules are a good step 
forward in addressing these concerns.
---------------------------------------------------------------------------

    \1\ Concurring Statement of Commissioner Sharon Y. Bowen 
Regarding Notice of Proposed Rulemaking on System Safeguards Testing 
Requirements (Dec. 10, 2015), available at http://www.cftc.gov/PressRoom/SpeechesTestimony/bowenstatement121615b.
---------------------------------------------------------------------------

    As I noted when they were proposed, 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

[[Page 64319]]

Infrastructure Cybersecurity (``NIST Framework'').\2\
---------------------------------------------------------------------------

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

    I was also an early proponent of including all registered 
entities, including SEFs, in this rule. I am glad to see them 
included, and look forward to the staff roundtable to discuss how to 
apply heightened standards to the significant SEFs. Thank you and I 
look forward to the staff's presentation.

[FR Doc. 2016-22174 Filed 9-16-16; 8:45 am]
BILLING CODE 6351-01-P