System Safeguards Testing Requirements

1System Safeguards Testing Requirements, Proposed Rule, 80 FR 80139, 80140 (Dec. 23, 2015). 2 Id. at 80142. 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, rberdansky@cftc.gov; David Taylor, Associate Director, Division of Market Oversight, 202–418–5488, dtaylor@cftc.gov, or David Steinberg, Associate Director, Division of Market Oversight, 202–418–5102, dsteinberg@ cftc.gov; Commodity Futures Trading Commission, Three Lafayette Centre, 1155 21st Street NW., Washington, DC 20851. SUPPLEMENTARY INFORMATION:
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 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 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

3Committee 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. 4 Id., section 7.2 at 18. 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). 7The 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). 9See § 38.1051(b) (for DCMs); Appendix A to Part 37, Core Principle 14 of Section 5h of the Act— System Safeguards (a) Guidance (1) Risk analysis and oversight program (for SEFs); § 49.24 (c) (for SDRs). 10See § 38.1051(h) (for DCMs); Appendix A to
Part 37, Core Principle 14 of Section 5h of the Act—
System Safeguards (a) Guidance (2) Testing (for SEFs); § 49.24(j) (for SDRs). 11See § 38.1051(i) (for DCMs); Appendix A to Part 37, Core Principle 14 of Section 5h of the Act— System Safeguards (a) Guidance (3) Coordination (for SEFs); § 49.24(k) (for SDRs). 12 80 FR 80139, 80146 (Dec. 23, 2015). 13 Id. at 80147. 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. 17 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for SEFs); 17 CFR 49.24(j) (for SDRs). 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 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 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
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
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
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 § 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
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

18 80 FR 80139, 80147 (Dec. 23, 2015). 19The 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. 20 80 FR 80139, 80148 (Dec. 23, 2015). 21 Id. 22 Id. 23 80 FR 80139, 80159 (Dec. 23, 2015). 24 Id. 25 Id. 26 Id. at 80160. 27 Id. 28 Id. 29 Id. 30 Id. 31 Id. 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. 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.
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 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 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
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

32 Id.
33 Id. at 80148.
34 Id.
35 Id. at 80160, 80161.
36 Id.
37 Id. at 80148.
38All comment letters are available on the Commission Web site at: http://comments.cftc.gov/ PublicComments/CommentList.aspx?id=1650. 39 80 FR 80139, 80148 (Dec. 23, 2015). NPRM, such remediation is grounded in best practices.32
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.
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 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

40 80 CFR 80139, 80147 (Dec. 23, 2015). 41 Id. at 80143. 42 Id. 43See 80 FR 80139, 80113 (Dec. 23, 2015). considerations, possible costs and benefits and how they could be quantified or estimated, and any other aspects of the ANPRM.
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—§§ 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
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 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.

44 80 FR 80139, 80143 (Dec. 23, 2015). 45CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20). 46 80 FR 80139, 80143 (Dec. 23, 2015). 47 Id. 48 Id. 49 Id. at 80145. 50 Id. at 80146. 51 Id. 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. 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 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 B. Requirement To Follow Generally Accepted Standards and Best Practices—§§ 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
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

52 Id. at 80147.
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. 56 80 FR 80139, 80147 (Dec. 23, 2015). 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.
C. Business Continuity-Disaster
Recovery Plan—§§ 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
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— §§ 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
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 § 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

57 Id. at 80147, 80148.
58 Id.
59 Id. at 80148.
60MGEX 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. 61 80 FR 80113 (Dec. 23, 2015). The OCC comment letter is available at http:// comments.cftc.gov/PublicComments/ ViewComment.aspx?id=60650&SearchText=. 62CPMI–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. 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. E. System Safeguards Testing— §§ 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

1. Definitions—§§ 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 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. (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.’’ 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.

63NIST 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. 64See, 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/. 65 80 FR 80139, 80148 (Dec. 23, 2015). 66 Id. 67Core 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. 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. (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 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

68 80 FR 80139, 80146 through 80161 (Dec. 23, 2015). 69 17 CFR §§ 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. 71See, 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.’’) 72This 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. 73 80 FR 80139, 80148 (Dec. 23, 2015). 74 80 FR 80139, 80148 through 80151 (Dec. 23, 2015). 75 Id. at 80149, 80150. or less, can reasonably be said to impose an undue burden on a DCM. (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 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. 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. 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.
2. Vulnerability Testing—
§§ 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

76 Id. at 80150.
77 Id. at 80150, 80151. 78 80 FR 80139, 80149, 80150 (Dec. 23, 2015). 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 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 (3) Automated Scanning and Authenticated Scanning No commenters disagreed with the proposed requirement for vulnerability testing to include automated

79 80 FR 80139, 80152 (Dec. 23, 2015). 80 Id. at 80152, 80153. 81 Id. at 80153. 82 Id. at 80152, 80153. 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—
§§ 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 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

83 Id. at 80152.
84 Id. at 80153.
85 80 FR 80139, 80152 (Dec. 23, 2015). 86 Id. at 80152, 80153. 87 Id. 88 80 FR 80139, 80152, 80153 (Dec. 23, 2015). 89 Id. 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. (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.
4. Internal Penetration Testing—
§§ 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 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 (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

90 Id.
91 Id. at 80153.
92 Id. at 80153, 80154.
93 Id. at 80154.
94 Id.
95 Id. 96 Id. at 80154, 80155. 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. (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.
5. Controls Testing—§§ 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 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.

97 80 FR 80139, 80152 (Dec. 23, 2015). 98 80 FR 80139, 80154 (Dec. 23, 2015). 99 Id. at 80154, 80155. 100 Id. 101 Id. at 80155 through 80157. 102 Id. 103 Id. at 80157. 104 Id. 105 Id. (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. (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. (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
6. Security Incident Response Plan
Testing—§§ 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

106 80 FR 80139, 80155 through 80156 (Dec. 23, 2015). 107 Id. at 80157 through 80159. 108 Id. at 80158. 109 Id. at 80158, 80159. 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. (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—§§ 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 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

110 Id. at 80158.
111 80 FR 80139, 80159 (Dec. 23, 2015). 112 Id. 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. (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— §§ 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
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

113 80 FR 80139, 80159 (Dec. 23, 2015). 114 Id. at 80156. 115 80 FR 80139, 80160 (Dec. 23, 2015). 116 Id. ‘‘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. 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. 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— §§ 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

117 80 FR 80139, 80160 (Dec. 23, 2015). 118 80 FR 80139, 80160 (Dec. 23, 2015). 119 80 FR 80139, 80160 (Dec. 23, 2015). 120 80 FR 80139, 80160 (Dec. 23, 2015). 121 Id.
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. 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. 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 H. Remediation—§§ 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.
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

122For 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. 123 5 U.S.C. 601 et seq. 124See 47 FR 18618 through 18621 (Apr. 30, 1982). 125See 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. 126 44 U.S.C. 3501 et seq. 127See OMB Control No. 3038–0052, available at http://www.reginfo.gov/public/do/ PRAOMBHistory?ombControlNumber=3038-0052. 128See OMB Control No. 3038–0074, available at http://www.reginfo.gov/public/do/ PRAOMBHistory?ombControlNumber=3038-0074. 129See OMB Control No. 3038–0086, available at http://www.reginfo.gov/public/do/ PRAOMBHistory?ombControlNumber=3038-0086. 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. 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. 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. 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 § 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
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

130 80 FR 80139, 80162 (Dec. 23, 2015). 131 Id. 132As discussed in the preamble, the Commission received comment letters from WMBAA, CME, and ICE concerning the books and records obligations generally. 133 80 FR 80139, 80163 (Dec. 23, 2015). 134 Id. 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). 137 7 U.S.C. 19(a). 138CME provided cost estimates for the proposed independent contractor requirements, conducting ETRAs, and controls testing. system safeguard-related books and records obligations.130 The final rules amend §§ 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, §§ 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 §§ 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.
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
§ 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 § 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 § 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. 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:
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 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. 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

139CME 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.’’ 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. 142The 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. 143 80 FR 80139, 80164 (Dec. 23, 2015). 144CEA 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). 147The 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. 148MGEX 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. 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. 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
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 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

149Based 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. 150 80 FR 80139, 80143 (Dec. 23, 2015). 151 Id. at 80123. 152CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20). 153See, 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. 154 80 FR 80139, 80143 (Dec. 23, 2015). 155See § 38.1051(b) (for DCMs); Appendix A to
Part 37, Core Principle 14 of Section 5h of the Act—
System Safeguards (a) Guidance (1) Risk analysis and oversight program (for SEFs); § 49.24(c) (for SDRs). 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. 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: §§ 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 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. 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

156See § 38.1051(b) (for DCMs); Appendix A to
Part 37, Core Principle 14 of Section 5h of the Act—
System Safeguards (a) Guidance (1) Risk analysis and oversight program (for SEFs); § 49.24(c) (for SDRs). 157See § 38.1051(h) (for DCMs); Appendix A to
Part 37, Core Principle 14 of Section 5h of the Act—
System Safeguards (a) Guidance (2) Testing (for SEFs); § 49.24(j) (for SDRs). 158See § 38.1051(i) (for DCMs); Appendix A to
Part 37, Core Principle 14 of Section 5h of the Act—
System Safeguards (a) Guidance (3) Coordination (for SEFs); § 49.24(k) (for SDRs). 159Commission regulations §§ 38.1051(c) (for DCMs), 37.1401(b) (for SEFs), and 49.24(d) (for SDRs); 17 CFR 38.1051(c); 17 CFR 37.1401(b); 17 CFR 49.24(d). 160The 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. 161NIST 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. 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:
§§ 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. (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: §§ 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. (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

162Commission regulation § 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). 163See also PRA discussion above. 164 80 FR 80139, 80147 (Dec. 23, 2015). 165 17 CFR §§ 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). 166See, e.g., Black’s Law Dictionary, Tenth Ed. (Thomson Reuters, St. Paul, MN, 2014) (‘‘Employee. Someone who works in the service of another d. Required System Safeguards-Related Books and Records Obligations:
§§ 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 § 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. (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. 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 (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: §§ 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, § 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

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.’’) 167 80 FR 80139, 80148 (Dec. 23, 2015). 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. 170Commission regulations §§ 38.1051(h) (for DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 17 CFR 49.24(j). 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. 172 Id. at 80150. 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. 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. f. Vulnerability Testing:
§§ 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 §§ 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 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. (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

173To 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. 174Based 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. 175See Commission regulations §§ 38.1051(h) (for DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j). 176As 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. 177MGEX 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. 178PCI DSS, Requirement 11.2 Regularly test security systems and processes, at 51, available at https://www.pcisecuritystandards.org/documents/ navigating_dss_v20.pdf. 179 Id. at 80150. 180CME 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. 181 Id. at 80168. 182See 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. 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. (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. (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 (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. (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. 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

183PCI DSS, Requirement 11.2 Regularly test security systems and processes, at 51, available at https://www.pcisecuritystandards.org/documents/ navigating_dss_v20.pdf. 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. 186Commission regulations §§ 38.1051(h) (for DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 17 CFR 49.24(j). 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. 188See Commission regulations §§ 38.1051(h) (for DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j). 189Based 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. 190NIST, 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. 191 Id. 192Based 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. 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. g. External Penetration Testing:
§§ 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 §§ 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 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. (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. (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 §§ 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 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

193Council on CyberSecurity, CSC 20–1, available at http://www.counciloncybersecurity.org/critical￾controls/. 194FFIEC, Information Security IT Examination Handbook, at 81, available at http:// ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_ InformationSecurity.pdf. 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. 197Commission regulations §§ 38.1051(h) (for DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 17 CFR 49.24(j). 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. practices support using independent contractors.193 (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. 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:
§§ 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 §§ 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 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. (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

199 Id. at 80153.
200See Commission regulations §§ 38.1051(h) (for DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j). 201Based 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. 202PCI DSS standards, at 96 through 97, available at https://www.pcisecuritystandards.org/security_ standards/index.php. 203FINRA, Report on Cybersecurity Practices (February 2015), at 22, available at https:// www.finra.org/sites/default/files/p602363%20 Report%20on%20Cybersecurity%20Practices_ 0.pdf. 204NIST, 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. 205FFIEC, Information Security IT Examination Handbook, at 82, available at http:// ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_ InformationSecurity.pdf. 206PCI DSS, Requirements 11.3.1 and 11.3.2., available at https://www.pcisecuritystandards.org/ documents/PCI_DSS_v3-1.pdf. development or operation of the systems or capabilities tested.199 (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. (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 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.
i. Controls Testing: §§ 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 §§ 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

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. 209Commission regulations §§ 38.1051(h) (for DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 17 CFR 49.24(j). 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. 211See Commission regulations §§ 38.1051(h) (for DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j). 212Based 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. 213Based 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. 214NIST SP 800–53A Rev. 4, at 17–18, available at http://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-53Ar4.pdf. 215One 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. 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 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. (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. (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 §§ 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. (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

216NIST 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. 217CFTC Roundtable, at 43–44. 218NIST SP 800–53A Rev. 4, at 17–18, available at http://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-53Ar4.pdf. 219 Id. 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. 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. (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. 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 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. j. Security Incident Response Plan Testing: §§ 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 The Commission’s current system safeguards rules for DCMs, SEFs, and SDRs mandate that, in order to achieve

222Commission regulations §§ 38.1051(h) (for DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 17 CFR 49.24(j). 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. 224NIST 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). 225 Id. at 80157. 226See Commission regulations §§ 38.1051(h) (for DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j). 227NIST 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). 228Based 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. 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. 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. (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. (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 (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. (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: §§ 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

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. 231Commission regulations §§ 38.1051(h) (for DCMs), 37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h); 17 CFR 37.1401(g); and 17 CFR 49.24(j). 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. 233See Commission regulations §§ 38.1051(h) (for DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j). 234Based 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. 235FINRA, Report on Cybersecurity Practices (February 2015), at 14, available at https:// www.finra.org/sites/default/files/ p602363%20Report%20on%20Cybersecurity%20 Practices_0.pdf. 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 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. (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. (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

236FINRA, Report on Cybersecurity Practices (February 2015), at 14, available at https:// www.finra.org/sites/default/files/ p602363%20Report%20on%20Cybersecurity%20 Practices_0.pdf. 237 80 FR 80139, 80176 (Dec. 23, 2015). 238See, 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. 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.
l. Scope for Testing and Assessment:
§§ 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:
§§ 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 §§ 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. 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,

239 80 FR 80139, 80167 (Dec. 23, 2015). 240See, 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. 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: §§ 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. 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: § 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 § 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

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

243See Heckler v. Chaney, 470 U.S. 821 (1985). 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. 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.

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

• 1. The authority citation for part 37
     continues to read as follows:
     Authority: 7 U.S.C. 1a, 2, 5, 6, 6c, 7, 7a– 2, 7b–3, and 12a, as amended by Titles VII and VIII of the Dodd Frank Wall Street Reform and Consumer Protection Act, Pub. L. 111–203, 124 Stat. 1376.
• 2. Amend § 37.1401 as follows:
• a. Revise paragraphs (a) and (b);
• b. Remove paragraph (f);
• c. Redesignate paragraphs (c) through
  (e) as paragraphs (d) through (f);
• d. Add new paragraph (c);
• e. Revise paragraph (g);
• f. Redesignate paragraph (h) as
  paragraph (j); and
• g. Add new paragraphs (h), (i), (k), (l),
  and (m).
  The revisions and additions read as follows:
  § 37.1401 Requirements.
  (a) A swap execution facility’s program of risk analysis and oversight with respect to its operations and automated systems 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 § 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 § 1.31 of this chapter, Core Principle 10 (Recordkeeping and Reporting), and §§ 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;

(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 § 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 § 1.31 of this chapter or with §§ 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.

(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]

• 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
• 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.
• 5. In § 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:
     § 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;

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

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

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

• 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.
• 7. In § 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:
     § 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;

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 § 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 §§ 1.31 and 45.2 of this chapter, and § 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 §§ 1.31 and 45.2 of this chapter, or with § 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.

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

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

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. Infrastructure Cybersecurity (‘‘NIST Framework’’).2 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