# System Safeguards Testing Requirements > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2016-22174 ## Record - **Collection:** Federal Register - **Document type:** Rule - **Published:** September 19, 2016 - **Citation:** 81 FR 64272 ## Text 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 1 System Safeguards Testing Requirements, Proposed Rule, 80 FR 80139, 80140 (Dec. 23, 2015). As detailed in the NPRM, cyber threats to the financial sector continue to expand, increasing the need for enhanced cybersecurity testing. Such testing should focus on the entity's ability to detect, contain, respond to, and recover from cyber attacks. It should also address detection, containment, and recovery from compromise of data integrity—perhaps the greatest threat with respect to financial sector data—in addition to compromise of data availability or confidentiality. As noted in the NPRM, cybersecurity testing is a well-established best practice both generally and for financial sector entities. 2 2 Id. at 80142. Cybersecurity testing is also supported internationally. The recently published Guidance on cyber resilience for financial market infrastructures issued by the Committee on Payments and Market Infrastructures and the Board of the International Organization of Securities Commissions (“CPMI-IOSCO Guidance”) provides that: Testing is an integral component of any cyber resilience framework. All elements of a cyber resilience framework should be rigorously tested to determine their overall effectiveness before being deployed within an FMI, and regularly thereafter. This includes the extent to which the framework is implemented correctly, operating as intended and producing desired outcomes. Understanding the overall effectiveness of the cyber resilience framework in the FMI and its environment is essential in determining the residual cyber risk to the FMI's operations, assets, and ecosystem. 3 3 Committee on Payments and Market Infrastructures (CPMI) and Board of the International Organization of Securities Commissions (IOSCO), Guidance on cyber resilience for financial market infrastructures (June 2016) section 7.1, at 18, available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD535.pdf. The CPMI-IOSCO Guidance also states that a financial market infrastructure “should establish a comprehensive testing program to validate the effectiveness of its cyber resilience framework on a regular and frequent basis,” employing appropriate cyber threat intelligence to inform its testing methods, and using the results to support ongoing improvement of its cyber resilience. 4 4 Id., section 7.2 at 18. B. Summary of the Proposed System Safeguards Testing Requirements Rule 1. Fundamental Goals The NPRM identified two principal goals. The first goal was clarification of current cybersecurity testing requirements for all DCMs, SEFs, and SDRs, along with clarification, amplification, and harmonization of other current system safeguards rule provisions. The second goal was the addition of new rule provisions for covered DCMs (as defined) and SDRs, establishing minimum frequency requirements for conducting certain types of cybersecurity testing, and requiring performance of certain tests by independent contractors. 2. Categories of Risk Analysis and Oversight Applicable to All DCMs, SEFs, and SDRs The system safeguards provisions of the Commodity Exchange Act (“Act” or “CEA”) and Commission regulations applicable to all DCMs, SEFs, and SDRs require these entities to maintain a program of risk analysis and oversight to identify and minimize sources of operational risk. 5 Commission regulations concerning system safeguards provide that the program of risk analysis and oversight required of each such entity must address specified categories of risk analysis and oversight to identify and minimize sources of operational risk. 6 The NPRM proposed clarification of what is already required of all DCMs, SEFs, and SDRs regarding the six current categories which their programs of risk analysis and oversight must address, by further defining those categories. 7 It also added and defined another category, enterprise risk management and governance, in order to clarify a requirement already implicit in the statutory mandate to maintain a program of system safeguards risk analysis and oversight. As set out in the NPRM, all seven categories and their definitions are grounded in generally accepted best practices. 8 5 7 U.S.C. 5h(f)(14), 7(d)(20), and 24a(c)(8); 17 CFR 37.1400, 38.1050, and 49.24(a)(1). 6 17 CFR 38.1051(a) and (b) (for DCMs); 17 CFR 37.1401(a); Appendix A to Part 37, Core Principle 14 of Section 5h of the Act—System Safeguards (a) Guidance (1) Risk analysis and oversight program (for SEFs); 17 CFR 49.24(b) and (c) (for SDRs). 7 The six current categories include information security; business continuity-disaster recovery (“BC-DR”) planning and resources; capacity and performance planning; systems operations; systems development and quality assurance; and physical security and environmental controls. 8 80 FR 80139, 80143 (Dec. 23, 2015). 3. Requirements To Follow Best Practices, Ensure Testing Independence, and Coordinate BC-DR Plans The Commission's current regulations for DCMs and SDRs and its guidance for SEFs provide that such entities should follow best practices in addressing the categories which their programs of system safeguards risk analysis and oversight are required to include. 9 They provide that such entities should ensure that their system safeguards testing, whether conducted by contractors or employees, is conducted by independent professionals ( i.e. , persons not responsible for development or operation of the systems or capabilities being tested). 10 They further provide that such entities should coordinate their business continuity-disaster recovery (“BC-DR”) plans with the BC-DR plans of market participants and essential service providers. 11 The NPRM proposed making these provisions mandatory for all DCMs, SEFs, and SDRs, thus aligning the rules for these entities with the Commission's rules for derivatives clearing organizations (“DCOs”). 12 9 See § 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). 10 See § 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). 11 See § 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). 4. Updating of Business Continuity-Disaster Recovery Plans and Emergency Procedures The NPRM proposed amending the current system safeguards rules requiring all DCMs, SEFs, and SDRs to maintain a business continuity-disaster recovery plan and emergency procedures, by adding a requirement for such plans and procedures to be updated as frequently as required by appropriate risk analysis, but at a minimum at least annually. 13 13 Id. at 80147. 5. System Safeguards-Related Books and Records Obligations The Commission's current system safeguards rules for all DCMs, SEFs, and SDRs contain a provision addressing required production of system safeguards-related documents to the Commission on request. 14 As noted in the NPRM, production of all such books and records is already required by the Act and Commission regulations, notably by Commission regulation § 1.31. 15 The NPRM proposed amending these document production provisions to further clarify requirements for document production by all DCMs, SEFs, and SDRs relating to system safeguards. 16 14 17 CFR 38.1051(g) and (h) (for DCMs); 17 CFR 37.1401(f) and (g) (for SEFs); 17 CFR 49.24(i) and (j) (for SDRs). 15 17 CFR 1.31; see also 17 CFR 38.1051(g) and (h); 17 CFR 37.1401(f) and (g); 17 CFR 49.24(i) and (j). 16 80 FR 80139, 80147 (Dec. 23, 2015). The NPRM specified that the obligation to produce books and records includes production of: Current copies of BC-DR plans and emergency procedures; assessments of operational risks or system safeguards-related controls; reports concerning system safeguards testing and assessment, whether performed by independent contractors or employees; and all other books and records requested by Commission staff in connection with Commission oversight of system safeguards. 6. Cybersecurity Testing Requirements for DCMs, SEFs and SDRs a. Clarification of Current Testing Requirements for All DCMs, SEFs, and SDRs The Commission's current system safeguards rules for DCMs, SEFs, and SDRs mandate that each such entity must conduct testing and review sufficient to ensure that its automated systems are reliable, secure, and have adequate scalable capacity. 17 The NPRM proposed clarifying this system safeguards and cybersecurity testing requirement, by specifying and defining five types of system safeguards testing and assessment that a DCM, SEF, or SDR necessarily must perform to fulfill the requirement. 18 These testing and assessment types included vulnerability testing, both external and internal penetration testing, controls testing, security incident response plan testing, and enterprise technology risk assessment. As set out in the NPRM, each of these types of testing is a generally recognized best practice for system safeguards. 19 Providing this clarification of the testing provisions of the current system safeguards rules is a primary purpose of this final rule. The NPRM proposed high-level, minimum requirements for these types of testing, recognizing that the particular ways in which DCMs, SEFs, and SDRs conduct such testing may change as accepted standards and industry best practices develop over time and are reflected in the DCM's, SEF's, or SDR's risk analysis. The NPRM provisions regarding each of the testing types are set out in additional detail in the discussion below concerning comments received. 17 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for SEFs); 17 CFR 49.24(j) (for SDRs). 18 80 FR 80139, 80147 (Dec. 23, 2015). 19 The Commission's current rules and guidance provide that a DCM's, SEF's, or SDR's entire program of risk analysis and oversight, which includes testing, should be based on generally accepted standards and best practices with respect to the development, operation, reliability, security, and capacity of automated systems. See 17 CFR 38.1051(h) (for DCMs); Appendix A to Part 37, Core Principle 14 of Section 5h of the Act—System Safeguards (a) Guidance (1) Risk analysis and oversight program (for SEFs); 17 CFR 49.24(j) (for SDRs). Each of the types of testing addressed in this NPRM—vulnerability testing, penetration testing, controls testing, security incident response plan testing, and enterprise technology risk assessment—has been a generally recognized best practice for system safeguards since before the testing requirements of the Act and the current regulations were adopted. The current system safeguards provisions of the CEA and the Commission's regulations became effective in August 2012. Generally accepted best practices called for each type of testing specified in the proposed rule well before that date, as shown in the following examples. Regarding all five types of testing, see, e.g., NIST SP 800-53A, Rev. 1, Guide for Assessing the Security Controls in Federal Information Systems and Organizations (“NIST 800-53A Rev. 1”), at E1, F67, F230, F148, and F226, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding vulnerability testing, see, e.g., NIST SP 800-53A Rev. 1, at F67, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, at 5-2, September 2008, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. Regarding penetration testing, see, e.g., NIST Special Publication (“SP”) 800-53A, Rev. 1, at E1, June 2010, available at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. Regarding controls testing, see, e.g., NIST 800-53A, Rev. 1, at 13 and Appendix F1, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding security incident response plan testing, see, e.g., NIST 800-53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding enterprise technology risk assessment, see, e.g., NIST 800-53A, Rev.1, at F226, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. b. New Minimum Testing Frequency and Independent Contractor Testing Requirements for Covered DCMs and All SDRs The NPRM proposed that covered DCMs (as defined) and all SDRs would be subject to new minimum testing frequency requirements with respect to some of the proposed types of system safeguards testing. 20 To strengthen the objectivity and reliability of the testing, assessment, and information available to the Commission regarding covered DCM and SDR system safeguards, the NPRM also proposed that for certain types of testing, covered DCMs and SDRs would be subject to new independent contractor testing requirements. 21 Establishing such minimum frequency and independent contractor requirements regarding cybersecurity testing by covered DCMs and SDRs is a primary purpose of this final rule. As noted in the NPRM, the proposed minimum frequency requirements and the requirement for some testing to be conducted by independent contractors are grounded in generally accepted standards and best practices. 22 The NPRM provisions regarding the minimum frequency and independent contractor requirements are set out in additional detail below in the discussion of comments received. 20 80 FR 80139, 80148 (Dec. 23, 2015). 21 Id. 22 Id. 7. Additional Testing-Related Risk Analysis and Oversight Program Requirements Applicable to All DCMs, SEFs, and SDRs The NPRM also clarified the current testing requirements for DCMs, SEFs, and SDRs by specifying and defining three other aspects of risk analysis and oversight programs that are necessary to fulfillment of the testing requirements and achievement of their purposes. 23 These three aspects are: (1) The scope of testing and assessment, (2) internal reporting and review of test results, and (3) remediation of vulnerabilities and deficiencies revealed by testing. As set out in the NPRM, all three of these risk analysis and oversight program aspects are grounded in generally recognized best practices for system safeguards. 24 23 80 FR 80139, 80159 (Dec. 23, 2015). 24 Id. a. Scope of Testing and Assessment The NPRM proposed that the scope of all testing and assessment required by the Commission's system safeguards regulations for DCMs, SEFs, and SDRs should be broad enough to include all testing of automated systems and controls necessary to identify any vulnerability which, if exploited or accidentally triggered, could enable an intruder or unauthorized user or insider to interfere with the entity's operations or with fulfillment of its statutory and regulatory responsibilities; to impair or degrade the reliability, security, or capacity of the entity's automated systems; to add to, delete, modify, exfiltrate, or compromise the integrity of any data related to the entity's regulated activities; or to undertake any other unauthorized action affecting the entity's regulated activities or the hardware or software used in connection with those activities. 25 The NPRM noted that testing scope should be based on proper risk analysis. 26 25 Id. 26 Id. at 80160. b. Internal Reporting and Review The NPRM called for a DCM's, SEF's, or SDR's senior management and its Board of Directors receive and review reports of the results of all testing and assessment required by Commission rules. 27 It also called for DCMs, SEFs, and SDRs to establish and follow appropriate procedures for remediation of issues identified through such review, and for evaluation of the effectiveness of the organization's testing and assessment protocols. 28 As noted in the NPRM, these requirements are grounded in best practices. 29 27 Id. 28 Id. 29 Id. c. Remediation The NPRM called for each DCM, SEF, and SDR to analyze the results of the testing and assessment required by the applicable system safeguards rules, in order to identify all vulnerabilities and deficiencies in its systems, and to remediate those vulnerabilities and deficiencies to the extent necessary to enable it to fulfill the applicable system safeguards requirements and meet its statutory and regulatory obligations. 30 The NPRM proposed requiring that such remediation be timely in light of appropriate risk analysis with respect to the risks presented. 31 As noted in the NPRM, such remediation is grounded in best practices. 32 30 Id. 31 Id. 32 Id. 8. Required Production of Annual Total Trading Volume The NPRM defined “covered DCM” as a DCM whose annual total trading volume is five percent or more of the annual total trading volume of all DCMs regulated by the Commission. 33 It did so for the purpose of applying the proposed minimum system safeguards testing frequency and independent contractor testing requirements, discussed above, to such covered DCMs. The NPRM noted that this would give DCMs that have less than five percent of the annual total trading volume of all DCMs more flexibility regarding the testing they must conduct, while still requiring all DCMs to conduct testing of all the types addressed in the NPRM. 34 To provide certainty to DCMs as to whether they currently met the definition of a covered DCM, the NPRM called for each DCM to report to the Commission annually its annual total trading volume for the preceding year, and for the Commission to notify each DCM annually of the percentage of the annual total trading volume of all DCMs which is constituted by that DCM's annual total trading volume for the preceding year. 35 The NPRM therefore called for each DCM to report its annual total trading volume for 2015 to the Commission within 30 calendar days of the effective date of the final rule, and to report its annual total volume for 2016 and each subsequent year thereafter to the Commission by January 31 of 2017 and of each calendar year thereafter. 36 The NPRM's definition of covered DCM also addressed cases where a DCM that had been a covered DCM ceased to meet the definitional requirements for covered DCM status, by providing that a covered DCM having annual total trading volume of less than five percent of the combined annual total trading volume of all regulated DCMs for two consecutive calendar years would cease to be a covered DCM as of March 1 of the calendar year following such two consecutive calendar years. 37 This two-year period permitted completion of the proposed two-year cycle for independent contractor-conducted controls testing. 33 Id. at 80148. 34 Id. 35 Id. at 80160, 80161. 36 Id. 37 Id. at 80148. C. Overview of Comments Received The comment period for the NPRM closed on February 23, 2016. The Commission received nine comment letters addressing the NPRM. Comments were provided by: The Chicago Mercantile Exchange (“CME”) Group DCMs, the CME SEF, and the CME SDR (collectively, “CME”); Intercontinental Exchange, Inc. (“ICE”) Futures U.S., ICE Swap Trade, and ICE Trade Vault (collectively, “ICE”); the Minneapolis Grain Exchange (“MGEX”); the North American Derivatives Exchange (“Nadex”); the CBOE Futures Exchange (“CFE”); the Depository Trust and Clearing Corporation Data Repository (“DDR”); Tradeweb Markets LLC (“Tradeweb”); the Wholesale Markets Broker's Association, Americas (“WMBAA”), whose members include BGC SEF, GFI SEF, Tradition SEF, and Tullett Prebon SEF; and FireEye, a third-party cybersecurity service provider. 38 38 All comment letters are available on the Commission Web site at: http://comments.cftc.gov/PublicComments/CommentList.aspx?id=1650. Most commenters expressed broad support for the proposed system safeguards testing rules. ICE stated that it supports the Commission's efforts to improve, clarify, and enhance its rules relating to system safeguards and address cybersecurity testing, calling clarification and enhancement of these rules in response to escalating and evolving cybersecurity threats “timely and welcome,” and noting that cybersecurity and system safeguards are paramount to the functioning of the derivatives markets. MGEX said it appreciates and supports the efforts the Commission has put forth to address the growing risk that cyber threats pose to trading markets. Nadex stated that it “commends the Commission's undertaking of this endeavor,” that it agrees with the general thrust of the proposed rule, and that it appreciates the Commission's efforts to clarify and enhance the current system safeguards regulations, align requirements with industry standards, and ensure that registrants are meeting compliance thresholds. CFE noted its agreement with the NPRM's approach featuring principles-based testing standards deeply rooted in industry best practices. DDR commended the Commission for its efforts to strengthen system safeguards and cybersecurity testing, and called the proposed rules “constructive steps in addressing key issues.” Tradeweb stated that it strongly supports the principles-based testing standards in the NPRM. WMBAA said that it appreciates the Commission's efforts to clarify current system safeguards rule and cybersecurity testing requirements. Many commenters also offered suggestions and recommendations for clarification or modification of specific NPRM provisions. These comments are addressed as appropriate in connection with the discussion below of the final rule provisions to which they relate. Certain comments requested further clarification relating to definitions provided in the NPRM. Any definitional changes in the final rule are provided for clarification only and do not impose new substantive obligations not included in the NPRM. D. Advanced Notice of Proposed Rulemaking Regarding Minimum Testing Frequency and Independent Contractor Testing Requirements for Covered SEFs 1. ANPRM Provisions The NPRM included an Advanced Notice of Proposed Rulemaking (“ANPRM”) concerning Commission consideration of whether to propose in a future NPRM that the most systemically important SEFs should be subject to the same minimum testing frequency and independent contractor testing requirements proposed in the NPRM for covered DCMs and SDRs. 39 In announcing its intent to consider such a proposal, the Commission expressed its belief that, because these requirements were essential to the effectiveness of covered DCM cybersecurity testing and the adequacy of their programs of risk analysis and oversight, it is appropriate to consider whether the same requirements should be applied to the most systemically important SEFs. In the ANPRM, the Commission took note that the SEF market is still in the early stages of development. It also suggested that one possible definition of “covered SEF” could be SEFs for which the annual total notional value of all swaps traded on or pursuant to the rules of the SEF is ten percent or more of the annual total notional value of all swaps traded on or pursuant to the rules of all SEFs regulated by the Commission. However, the ANPRM stated that the Commission would also consider whether annual total notional value or annual total number of swaps traded would provide a more appropriate definition, and whether any definition should apply to swaps in each asset class separately or to all swaps combined regardless of asset class. The Commission requested comments regarding each of these considerations, possible costs and benefits and how they could be quantified or estimated, and any other aspects of the ANPRM. 39 80 FR 80139, 80148 (Dec. 23, 2015). 2. Comments Received The Commission received several comments concerning the ANPRM. Tradeweb called for careful consideration by the Commission, in dialogue with the SEFs to whom any proposal would potentially apply, before issuance of an NPRM on this subject. Tradeweb suggested that, because the SEF market is still in an early stage of development and a covered SEF concept could have a disproportionate impact on the commercial viability of certain SEFs, both the definition of “covered SEF” and the potential costs and benefits involved would require further study and discussion with the industry. To that end, Tradeweb urged the Commission to convene a roundtable or working group of SEFs to discuss the nature and scope of any future SEF-specific system safeguards NPRM before moving forward with such a proposal. Tradeweb advised the Commission to consider the cross-border scope and impact of any future NPRM, and to solicit comment from international regulators either independently or as part of the suggested roundtable or working group. Several commenters suggested that any future requirements proposed should apply to all SEFs. Tradeweb called for any future proposal to avoid putting certain SEFs at a competitive disadvantage, and to cover all SEFs rather than only systemically important SEFS. WMBAA recommended that the Commission decline to propose a “covered SEF” concept, arguing that: (1) SEF operations do not raise the same systemic concerns attendant on failure of major DCMs or DCOs; (2) products traded on SEFs are fungible across multiple platforms; (3) in the present early stage of the SEF market, individual SEFs could be “covered” one year but not the next, leading to uncertainty; and (4) the present unsettled nature of the SEF regulatory environment would make adoption of a “covered SEF” concept premature. CME called for the Commission to adopt the same risk based system safeguards requirements for all SEFs, leaving testing frequency to be determined by risk analysis, and avoiding an independent contractor testing requirement. Tradeweb and WMBAA also suggested that the costs associated with imposition of “covered SEF” requirements could well exceed any benefits derived. However, no commenters offered specific information concerning possible costs. 3. Further Commission Consideration The Commission has considered and evaluated the comments received concerning the ANPRM. The Commission agrees with the comments suggesting that further consideration and consultation with both the industry and other relevant regulators and stakeholders would be appropriate and helpful before issuance of any future NPRM regarding “covered SEFs.” The Commission also notes the current lack of specific cost and benefit information regarding this concept, and the current absence of a consensus on how “covered SEF” would be best defined in light of the characteristics of swaps and the swap market. Accordingly, the Commission will engage in appropriate consultation prior to determining whether to issue a future NPRM regarding “covered SEFs.” II. The Final Rules A. Categories of Risk Analysis and Oversight—§§ 37.1401(a), 38.1051(a), and 49.24(b). 1. Proposed Rule As noted above, the NPRM proposed clarification of what is already required of all DCMs, SEFs, and SDRs regarding the categories which their programs of risk analysis and oversight must address, by further defining the six categories addressed by the current rules. 40 It also added and defined another category, enterprise risk management and governance, doing so to clarify a requirement already implicit in the statutory mandate to maintain a program of system safeguards risk analysis and oversight. 41 As set out in the NPRM, all seven categories and their definitions are grounded in generally accepted best practices. 42 40 80 CFR 80139, 80147 (Dec. 23, 2015). 41 Id. at 80143. 42 Id. 2. Comments Received The Commission received three comments on this topic. Two commenters, CME and DDR, concurred with the NPRM's addition of the category of enterprise risk analysis and governance to the list of categories that programs of risk analysis and oversight must address, and suggested clarifications in this respect. CME stated that it recognizes the importance of effective Board oversight, and asked the Commission to confirm that such oversight may appropriately be delegated to Board level committees. CME also asked the Commission to confirm that the final rule will allow regulated entities flexibility of organizational design concerning how their programs of risk analysis and oversight address the enterprise risk management and governance category, and will not require that an entity's enterprise risk management function conduct all components of this category. DDR agreed with the Commission that active supervision of system safeguards by both senior management and the Board of Directors promotes more efficient, effective, and reliable risk management, and will better position regulated entities to strengthen the integrity, resiliency, and availability of their automated systems. Noting its agreement that regulated entities should give their boards access to the appropriate system safeguards and cyber resiliency information so as to enable effective oversight, DDR suggested that the final rules should acknowledge that there are multiple ways a regulated entity can ensure that its board is appropriately informed. One commenter, MGEX, questioned why this NPRM proposed adding the category of enterprise risk management and governance, while the Commission's parallel Notice of Proposed Rulemaking addressed to DCOs did not, citing this as an inconsistency between the two NPRMs. 43 43 See 80 FR 80139, 80113 (Dec. 23, 2015). MGEX commented that the NPRM proposed a requirement for all DCMs, SEFs, and SDRs to have a program of risk analysis and oversight, without defining such a program. MGEX also stated that the lists of topics specified in the NPRM as included in each category to be addressed in the required program of risk analysis and oversight were overly prescriptive, citing as an example the list of topics the NPRM specified as included in the category of information security. MGEX suggested that the specified categories should be principles-based and should look to evolving best practices. 3. Final Rule The Commission has considered and evaluated the comments concerning addition of the category of enterprise risk analysis and governance to the list of categories which must be addressed by the program of system safeguards-related risk analysis and oversight which the CEA requires all DCMs, SEFs, and SDRs to establish and maintain. For the reasons set forth below, the Commission is adopting the list of categories as proposed. The Commission continues to believe that addition of the category of enterprise risk analysis and governance is appropriate because this clarifies a requirement already implicit in the statutory mandate to maintain a program of system safeguards risk analysis and oversight. 44 The Commission confirms that the addition of this category does not require that the listed elements of this category be conducted through a particular organizational structure or by particular DCM, SEF, or SDR staff; rather, the final rule provides flexibility in this regard. 44 80 FR 80139, 80143 (Dec. 23, 2015). The Commission agrees with the comments acknowledging the importance of effective Board of Directors oversight of system safeguards, which the Commission believes is essential to establishing and maintaining the top-down, organization-wide culture of adherence to cybersecurity principles that is required for resilience in today's cybersecurity threat environment. In addition, the Commission agrees with CME's comment that Board of Directors oversight of system safeguards may appropriately be delegated to a Board-level committee or committees, and with DDR's comment that there are a variety of ways in which a DCM, SEF, or SDR can ensure that its Board is sufficiently and appropriately informed to enable it to provide appropriate system safeguards and cybersecurity oversight. In the Commission's view, providing the Board with information sufficient to enable it to provide active, appropriate, knowledgeable, and effective oversight of system safeguards and cybersecurity is the key in this regard. The Commission has also considered and evaluated MGEX's comment asserting that the NPRM proposed establishment of a requirement for DCMs, SEFs, and SDRs to have a program of system safeguards risk analysis and oversight, without defining such a program, and its comment concerning the lists of topics specified in the NPRM as included in each category to be addressed in the required program of risk analysis and oversight. The requirement for regulatees to have a program of system safeguards risk analysis and oversight was mandated by Congress in the CEA itself, and thus is required by law. 45 The NPRM's references to it did not propose creation of a new requirement in this regard. The Commission's current system safeguards regulations define the program of risk analysis and oversight by specifying the categories of risk analysis and oversight which the program must address. As noted above and in the NPRM, the category of enterprise risk management and governance is implicit and inherent in the statutory requirement itself, and supported by generally accepted standards and best practices. 46 45 CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20). 46 80 FR 80139, 80143 (Dec. 23, 2015). The Commission agrees with MGEX that the required categories of risk analysis and oversight should be principles-based, but disagrees that the NPRM lists of topics included in each category consist of static lists of controls. As set out in detail in the NPRM, each of the aspects cited in the NPRM for the various categories that the required program of risk analysis and oversight must address is rooted in generally accepted standards and best practices. 47 Because the Commission's current system safeguards rules and guidance provide that DCMs, SEFs, and SDRs should follow generally accepted best practices and standards regarding system safeguards, these entities' programs of risk analysis and oversight should already be addressing each of the aspects included in the NPRM for each risk analysis and oversight category. As the NPRM explicitly states, the aspects specified in the NPRM for each category do not provide all-inclusive or static lists; rather, they highlight important aspects of the categories that are already recognized as best practices. 48 An important benefit of the adherence-to-best-practices approach taken in the Commission's current system safeguards rules, the NPRM generally, and the NPRM provisions addressing the categories in particular, is precisely that such best practices can evolve over time as the cybersecurity field evolves. In addition, the Commission continues to believe, as it stated in the NPRM, that risk analysis and oversight programs that address each of the aspects listed in the NPRM for the risk analysis and oversight categories are essential to maintaining effective system safeguards in today's cybersecurity threat environment. 49 47 Id. 48 Id. 49 Id. at 80145. B. Requirement To Follow Generally Accepted Standards and Best Practices—§§ 37.1401(b), 38.1051(b), and 49.24(c) 1. Proposed Rule The NPRM retained the substance of the Commission's current system safeguards rule provision calling for DCMs, SEFs, and SDRs to adhere to generally accepted standards and best practices in their required programs of system safeguards risk analysis and oversight. The only change proposed in the NPRM was language adjustment to clarify that such adherence is mandatory for all DCMs, SEFs, and SDRs. 50 50 Id. at 80146. 2. Comments Received Several commenters, including CME, Nadex, DDR, Tradeweb, and WMBAA, agreed with the Commission that an entity's program of risk analysis and oversight should follow generally accepted standards and best practices. CME requested that the Commission confirm that generally accepted best practices not explicitly cited in the NPRM may also be used in this regard. CME also asked the Commission to confirm that the intent of this provision is that a regulated entity should take generally accepted best practices into account as it designs a program of risk analysis and oversight tailored to its risks and its appropriate analysis of those risks, rather than to codify particular best practices. 3. Final Rule The Commission has considered and evaluated the comments concerning the requirement that a DCM's, SEF's, or SDR's required program of risk analysis and oversight should follow generally accepted standards and best practices. For the reasons set forth below, the Commission is adopting this provision as proposed. As CME asked the Commission to confirm, the best practices cited in the NPRM do not constitute an exclusive or codified list. 51 DCMs, SEFs, and SDRs should take generally accepted best practices and standards into account as they conduct appropriate and current analysis of individual risks and conducts appropriate and effective oversight with respect to such risks. A program of risk analysis and oversight should consider all generally accepted sources of best practices in addressing the particular risks and circumstances of the entity in question in an effective and appropriate way. In the Commission's view, the requirement to follow generally accepted standards and best practices is one of the most important requirements of the Commission's system safeguards rules. Best practices evolve over time in conjunction with the changing cybersecurity threat environment. The agility that a best practices approach therefore provides is crucial to effective resilience with respect to cybersecurity and system safeguards. In addition, ongoing development of best practices benefits from private sector expertise and input, as well as from public sector contributions. Such private sector expertise and input is important to effective cybersecurity. The Commission also observes that requiring financial sector entities to follow best practices with respect to system safeguards and cybersecurity is an effective key to harmonizing the oversight of cybersecurity conducted by different financial regulators. Some financial regulators, such as the FFIEC agencies, are themselves sources of generally accepted best practices. Regulatory oversight of cybersecurity generally follows best practices, most sources of which are largely consonant with each other. 51 Id. C. Business Continuity-Disaster Recovery Plan—§§ 37.1401(c), 38.1051(c), and 49.24(d) 1. Proposed Rule The Commission's current rules concerning the business continuity-disaster recovery (“BC-DR”) plans of DCMs, SEFs, and SDRs require that these entities maintain BC-DR plans and resources, emergency procedures, and backup facilities sufficient to enable timely recovery and resumption of their operations and fulfillment of their responsibilities and obligations as registrants, and specify recovery time. The NPRM proposed further alignment of these provisions with generally accepted standards and best practices by adding a requirement for DCMs, SEFs, and SDRs to update their BC-DR plans and emergency procedures at a frequency determined by an appropriate risk analysis, but at a minimum no less frequently than annually. 52 52 Id. at 80147. 2. Comments Received CME stated that it agreed with the Commission's proposal to require updating of BC-DR plans and emergency procedures at least annually and more frequently if necessitated by other circumstances. 3. Final Rule The Commission has considered and evaluated the comment concerning the frequency of updates to BC-DR plans and emergency procedures, with which it agrees. As noted above, updating such plans at a frequency determined by risk analysis but no less frequently than annually is supported by generally accepted standards and best practices. The Commission is adopting this provision as proposed. D. Books and Records Requirements—§§ 37.1401(g), 38.1051(g), and 49.24(i) 1. Proposed Rule As noted above, the Commission's current system safeguards rules for all DCMs, SEFs, and SDRs contain a provision addressing required production of system safeguards-related documents to the Commission on request. 53 The NPRM proposed amending these document production provisions to further clarify requirements for system safeguards-related document production. 54 Specifically, the NPRM proposed requiring each DCM, SEF, or SDR to provide to the Commission, promptly on the request of Commission staff: Current copies of its BC-DR plans and emergency procedures; all assessments of its operational risks or system safeguards-related controls; all reports concerning system safeguards testing and assessment; and all other books and records requested in connection with Commission oversight of system safeguards. 55 53 17 CFR 38.1051(g) and (h) (for DCMs); 17 CFR 37.1401(f) and (g) (for SEFs); 17 CFR 49.24(i) and (j) (for SDRs). 54 80 FR 80139, 80147 (Dec. 23, 2015). 55 Id. 2. Comments Received Two commenters, CME and WMBAA, recognized the Commission's established authority to require production of records, but asked the Commission to continue to work with DCMs, SEFs, and SDRs to find ways that highly sensitive system safeguards-related materials can be made available to Commission staff in ways that maximize protection of their confidentiality. WMBAA suggested that this could be accomplished in appropriate cases by having CFTC staff review highly sensitive information at a registrant's location or in a non-electronic, non-reproducible format. ICE, suggested that, with respect to parent firms that own both CFTC-regulated and non-CFTC-regulated entities, the Commission should avoid requiring production of documents discussing risks at the firm-wide level, and limit its production requests to documents focused solely on the risks of CFTC-regulated entities. In contrast, WMBAA noted that a registrant's systems, such as SEF systems, are often a subset of a larger financial services company's systems, and share cybersecurity defenses, procedures, and testing with the parent entity as a whole, rather than standing alone with respect to cybersecurity. WMBAA suggested that it would be contrary to best practices for CFTC oversight to focus solely on the risks and cybersecurity protections of the CFTC-regulated entity's systems, without considering the related systems and protections of the parent entity. 3. Final Rule The Commission has considered and evaluated the comments concerning the books and records provisions of the NPRM. For the reasons set forth below, the Commission is adopting these provisions as proposed. The established requirements of the Commission's regulations regarding production of books and records are essential to the Commission's ability to fulfill its oversight responsibilities. The Commission also recognizes that the cybersecurity and system safeguards information of DCMs, SEFs, and SDRs can be sensitive. As noted by commenters, Commission staff conducting cybersecurity oversight work regularly with regulated entities to find ways for sensitive cybersecurity information to be made available to the Commission while minimizing the risk of inappropriate disclosure. The Commission has also considered and evaluated the comments concerning production of books and records that address the system safeguards risks and cybersecurity protections of parent companies. The Commission agrees with WMBAA's observation that the automated systems, programs of system safeguards-related risk analysis and oversight, cybersecurity defenses and testing, and BC-DR plans and resources of CFTC-regulated DCMs, SEFs, and SDRs owned by parent financial sector companies that also own entities not regulated by the Commission are frequently shared across the parent company. Indeed, this is presently the case with respect to the parent companies of all DCMs, SEFs, and SDRs regulated by the Commission which are subsidiaries of a parent company. The Commission disagrees with ICE's suggestion that production of books and records addressing parent-wide system safeguards risks and risk analysis and oversight programs should not be required. Production of all of the books and records specified in the NPRM books and records provision is already required by the Act and Commission regulations, notably by Commission regulation § 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 plans, and other system safeguards and cybersecurity resources with their parent companies, the suggested limitation would in many cases—including the case of ICE itself—cripple the oversight of system safeguards risks and risk analysis and oversight programs for which the CEA makes the Commission responsible, and thus would harm the public interest. The Commission will continue to exercise its authority to require production of all books and records relating to the system safeguards of DCMs, SEFs, and SDRs, including those relating to the system safeguards risks and risk analysis and oversight programs of parent companies where such risks or such programs are shared in whole or in part by a DCM, SEF, or SDR. 56 80 FR 80139, 80147 (Dec. 23, 2015). E. System Safeguards Testing—§§ 37.1401(h), 38.1051(h), and 49.24(j) The provisions of the NPRM addressing automated system testing by DCMs, SEFs, and SDRs retained the language of the Commission's current rules requiring these entities to conduct regular, periodic, objective testing and review of their automated systems to ensure their reliability, security, and adequate scalable capacity. 57 They also retained the language of the current rules requiring regular, periodic testing and review of the business continuity-disaster recovery capabilities of such entities. The NPRM proposed further clarification of the current rules by specifying that such testing and review must include vulnerability testing, penetration testing, controls testing, security incident response plan testing, and enterprise technology risk assessment, and defining certain terms related to such testing. 58 57 Id. at 80147, 80148. 58 Id. 1. Definitions—§§ 37.1401(h)(1), 38.1051(h)(1), and 49.24(j)(1) a. Proposed Rule For the purposes of the testing sections of the Commission's system safeguards rules, the NPRM defined the following terms relating to system safeguards testing and assessment by DCMs, SEFs, and SDRs: Controls; controls testing; enterprise technology risk assessment; external penetration testing; internal penetration testing; key controls; security incident; security incident response plan; security incident response plan testing; and vulnerability testing. With respect to testing by DCMs, the NPRM also defined the following term: Covered designated contract market. 59 59 Id. at 80148. b. Comments Received Five commenters, CME, ICE, MGEX, DDR, and WMBAA, provided comments concerning some of the definitions proposed in the NPRM. (1) External and internal penetration testing. ICE recommended that the definitions of external and internal penetration testing specify that such testing should include scenario or capture-the-flag testing intended to compromise the system holistically via all available means including technical exploit, social engineering, and lateral traversal. ICE also suggested that the Commission clarify that penetration testing is not intended to include application-specific tests, and recommended that the final rule should avoid specifying parameters for internal penetration testing, in order to allow each regulated entity to determine its own testing methodology. Tradeweb suggested that external penetration testing should be defined to mean penetration testing conducted over the internet. WMBAA suggested that the final rule should not focus on testing from a SEF system's perimeter, but should focus on all the systems supporting the SEF's functionality, whether those of the SEF itself or of its parent company. (2) Controls and Key Controls As part of its recommendation that the final rule eliminate all requirements for controls testing (addressed in the discussion of controls testing below), ICE recommended that the final rule should remove the proposed definitions of controls and key controls. (3) Covered Designated Contract Market MGEX commented that the definitional distinction between covered and non-covered DCMs is a valuable concept that recognizes the lower systemic risk posed by smaller entities. 60 However, CME commented that the distinction is unnecessarily complex and imposes undue burdens, and suggested that the final rule adopt a uniform set of standards for all DCMs. CME also suggested that if the covered DCM concept were to be retained, the Commission should consider alternatives to annual DCM reporting of total annual trading volume, because the Commission currently receives volume reports pursuant to DCM Core Principle 8 and part 16 of the Commission's regulations. 60 MGEX commented that the Commission should use a similar definition to distinguish between larger and smaller derivatives clearing organizations (“DCOs”). MGEX also made these comments in its comment letter concerning the Commission's NPRM regarding system safeguards testing by DCOs, available at: http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60651&SearchText= . Since testing by DCOs is not addressed by this final rule, but will be addressed in the final rule regarding DCO system safeguards testing, these comments are most appropriately addressed in the DCO system safeguards testing final rule, and are addressed there. (4) Security Incident The NPRM defined “security incident” as a cyber security or physical security event that actually or potentially jeopardizes automated system operation, reliability, security, or capacity, or the availability, confidentiality, or integrity of data. No comments were received concerning the NPRM definition. However, the Commission received a comment from the Options Clearing Corporation (“OCC”) concerning the identical definition included in the parallel Notice of Proposed Rulemaking issued by the Commission on December 15, 2015, proposing to amend its system safeguards rules for DCOs. 61 OCC argued that including in the definition events that “potentially” jeopardize automated systems or data renders the definition vague, and could be interpreted to include most, if not all, cybersecurity events experienced by a DCO. OCC suggested amending the definition to replace “potentially jeopardizes” with “has a significant likelihood of jeopardizing.” 61 80 FR 80113 (Dec. 23, 2015). The OCC comment letter is available at http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60650&SearchText= . Some comments also addressed terms that were used but not defined in the NPRM. Although the NPRM did not define the terms “recovery” or “resumption,” DDR commented that, in its view, the NPRM distinguished between resumption of critical functions following a cyber incident on the one hand, and recovery in the sense of restoration of capabilities or services impaired due to a cyber event. Noting that this distinction is consistent with the definitions of these terms in the CMPI-IOSCO Guidance on Cyber Resilience for Financial Market Infrastructures—Consultative Report of November 24, 2015, 62 DDR stated that in this respect the NPRM appropriately recognized differences among financial market infrastructures with respect to varying requirements for recovery and resumption timeframes. 62 CPMI-IOSCO, Guidance on Cyber Resilience for Financial Market Infrastructures—Consultative Report (Nov. 2015), at 26, available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD513.pdf . CME, ICE, and MGEX commented concerning the NPRM's use of the terms “independent contractor” and “independent professional.” CME asserted that neither term is clearly defined in either the Commission's current rules or the NPRM. ICE called on the Commission to clarify in the final rule that entity employee groups such as the internal audit function are considered to be independent professionals not responsible for the development of operation of the systems or capabilities tested or assessed in the area of system safeguards. While not commenting directly on these definitions, MGEX expressed the view that having independent testing performed is a key and costly feature proposed in the NPRM. c. Final Rule The Commission has considered and evaluated the comments concerning the definitions proposed in the NPRM. For the reasons discussed below, the final rule will amend the definition of security incident, and otherwise retain the definitions as proposed. (1) External and Internal Penetration Testing The Commission agrees with ICE's suggestion that penetration testing that attempts to compromise an entity's systems holistically through means including technical exploit, social engineering, and lateral traversal is appropriate to today's cybersecurity threat environment. The Commission also agrees with ICE's recommendation that the final rule should avoid specifying particular internal penetration testing parameters in order to give DCMs, SEFs, and SDRs flexibility in determining their particular methodology for such testing, and believes that approach is also appropriate regarding external penetration testing. Best practices indicate that with respect to penetration testing, entities should regularly “update the list of attack techniques and exploitable vulnerabilities used in penetration testing based on an organizational assessment of risk or when significant new vulnerabilities or threats are identified and reported.” 63 Where penetration testing that attempts to compromise systems holistically through means including technical exploit, social engineering, and lateral traversal is called for by appropriate risk analysis, as it may be in most or even all cases, the final rule will require penetration testing using such means, by virtue of its requirement for all DCMs, SEFs, and SDRs to follow best practices, and its requirement for all DCMs, SEFs, and SDRs to make the scope of their cybersecurity testing broad enough to include all testing that their programs of risk analysis and current cybersecurity threat analysis indicate is necessary. The Commission notes that essential penetration testing methods and techniques may change over time, based on an entity's appropriate risk analysis, technological changes, and the evolving nature of cybersecurity threats. The Commission disagrees with Tradeweb's suggestion that external penetration testing should be defined as testing conducted over the Internet. Best practices indicate that external penetration testing should be conducted from multiple vectors including remote access, virtual private network connections, and any separate environments or local area network segments, as well as the internet. 64 In addition, such testing should include not only Iinternet based or network-layer based tests but also application-layer assessments. The Commission agrees with WMBAA's comment that penetration testing must include testing of all systems supporting a regulated entity's functionality or involved in the entity's system safeguards, whether the systems belong to the entity itself or to the entity's parent company. 63 NIST SP 800-53A, Rev. 4, Assessing Security and Privacy Controls in Federal Information Systems and Organizations—Building Effective Assessment Plans, at E-1, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf . 64 See, e.g., Security Standards Council, Payment Card Industry Data Security Standards, Apr. 2016, v. 3.2 (“PCI DSS”), available at https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf , Information Supplement: Penetration Testing Guidance, at 5-8, available at https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf ; and Center for Internet Security, Critical Security Controls, at 68-69, available at https://www.cisecurity.org/critical-controls/ . (2) Covered Designated Contract Market The Commission has considered and evaluated the comments for and against the NPRM's definitional distinction between covered and non-covered DCMs. The Commission continues to believe that the NPRM's proposed requirements regarding the minimum frequencies at which various types of cybersecurity testing should be conducted and regarding the use of independent contractors to perform specified tests are important and appropriate in today's cybersecurity threat environment. As noted in the NPRM, these requirements aim to strengthen the objectivity and reliability of the testing and assessment information available to the Commission regarding system safeguards, and to ensure the effectiveness and timeliness of both cybersecurity testing and programs of risk analysis and oversight. 65 Additionally, the use of independent contractors for many types of testing is consonant with best practices. The Commission also continues to believe that application of these requirements to DCMs whose annual total trading volume is five percent or more of the annual total trading volume of all DCMs regulated by the Commission is appropriate. This approach reduces possible costs and burdens for smaller and less systemically critical DCMs, by giving them additional flexibility regarding their cybersecurity testing. The fact that smaller DCMs will still be required to conduct testing of all the types addressed in the final rule means that this approach will not impair the fundamental goals of the CEA and the Commission's system safeguards regulations. The NPRM also proposed offering such added flexibility to SEFs, which like non-covered DCMs are required to conduct all of the specified types of testing but not made subject to the minimum frequency and independent contractor requirements. The Commission continues to believe this to be appropriate as well, for the same reasons. 66 65 80 FR 80139, 80148 (Dec. 23, 2015). 66 Id. The Commission declines CME's suggestion that it rely on DCM volume reports submitted pursuant to part 16 of the Commission's regulations. The Commission notes that while it receives daily trade information from DCMs pursuant to part 16, it does not receive total annual trading volume information from DCMs. 67 The Commission believes that DCM submission of annual trading volume requirement is essential for the Commission to accurately evaluate whether a particular DCM must comply with the frequency and independent contractor requirements as a covered DCM. The Commission believes that annual total trading volume information is readily available to DCMs, and that DCMs generally calculate their annual trading volume in the usual course of business. The Commission does not believe that looking up the amount of a DCM's annual total trading volume and reporting that amount to the Commission once a year, something that can be done by email in thirty minutes or less, can reasonably be said to impose an undue burden on a DCM. 67 Core Principle 8 is inapplicable here, because it requires DCMs to publish daily volume information but does not require submission of that information to the Commission. (3) Security Incident The Commission has considered and evaluated OCC's comment concerning the definition of “security incident” included in the Commission's parallel NPRM proposing amendment of its system safeguards rules for DCOs. The Commission is amending the definition as the comment suggested, defining security incident as a cyber security or physical security event that “actually jeopardizes or has a significant likelihood of jeopardizing” automated systems or data. The definition included in the DCO NPRM is identical to the one included in the NPRM regarding DCMs, SEFs, and SDRs. The Commission issued the two NPRMs simultaneously and in parallel, and intended that the final rules issued in connection with both NPRMs should be closely aligned. Accordingly, the Commission believes the comment received is germane to both final rules. The Commission also notes that the amendment of this definition does not expand the definition's reach but rather narrows it somewhat, and therefore lightens any costs or burdens involved to at least some degree. (4) Recovery and Resumption With respect to DDR's comment regarding the terms “recovery” and “resumption,” the Commission notes that the NPRM did not, and the final rule will not, define these terms or make any change to the language or the requirements of the Commission's current system safeguards rules for DCMs, SEFs, or SDRs regarding recovery and resumption of operations and fulfillment of responsibilities and obligations as a registered entity. (5) Independent Contractor and Independent Professional The Commission has considered and evaluated the various comments concerning the terms “independent contractor” and “independent professional” used in the NPRM. 68 The Commission notes that both terms are effectively defined in the Commission's current system safeguards rules for DCMs and SDRs and its current system safeguards rules and guidance for SEFs. 69 These current provisions call for the system safeguards testing required of all DCMs, SEFs, and SDRs to be conducted by qualified, independent professionals, who may be independent contractors or employees of the DCM, SEF, or SDR, but should not be persons responsible for development or operation of the systems or capabilities being tested. 70 68 80 FR 80139, 80146 through 80161 (Dec. 23, 2015). 69 17 CFR §§ 38.1051(h) (for DCMs); 37.1401 (g) and Appendix B to Part 37, Core Principle 14 of Section 5h of the Act—System Safeguards (C)(a)(2) (for SEFs); 49.24(j) (for SDRs). 70 Id. Accordingly, for purposes of the current system safeguards rules, independent contractors are qualified system safeguards professionals who are not employees of the DCM, SEF, or SDR. The current rules use the terms independent contractor and employee as they are legally defined and generally used. 71 The Commission believes that the distinction between independent contractor and employee is well settled and understood, and does not need additional definition in the system safeguards rules. 71 See, e.g., Black's Law Dictionary, Tenth Ed. (Thomson Reuters, St. Paul, MN, 2014) (“Employee. Someone who works in the service of another person (the employer) under an express or implied contract of hire, under which the employer has the right to control the details of work performance.”) (“Independent Contractor. Someone who is entrusted to undertake a specific project but who is left free to do the assigned work and to choose the method for accomplishing it.”) With respect to system safeguards testing, the current rules provide that employees conducting required testing must be independent in that they are not employees responsible for development or operation of the systems or capabilities being tested. The Commission believes that this distinction between employees with sufficient independence to appropriately conduct required system safeguards testing and those who lack such independence is also sufficiently clear, and does not require additional definition. The NPRM used, and the final rule will retain, this language from the current system safeguards rules. Where this requirement is included, the testing in question must be conducted by employees who are independent, which means employees not responsible for developing or operating what is being tested. 72 Employees who are part of the internal audit function of a DCM, SEF, or SDR, are one example of employees having appropriate independence. Other employees who possess the specified degree of independence and have qualifications the DCM, SEF, or SDR believes are appropriate may also be suitable in such cases. 72 This requirement is included in the final rule provisions concerning most types of testing, but as discussed below is not included in the SIRP testing provision. One clarification may be helpful with respect to testing required to be performed by independent contractors, as distinct from testing performed by persons performing the internal audit function. As noted above, the internal audit function is a required aspect of the enterprise risk management and governance category which must be included in the program of risk analysis and oversight that a DCM, SEF, or SDR must maintain. It is an integral part of, and a responsibility of, the regulated entity, whether carried out in-house or outsourced. The NPRM proposed required testing by independent contractors in part to give the Commission's system safeguards oversight a third source of system safeguards information on which to rely, in addition to the entity's employees and its internal audit function. 73 It also proposed independent contractor testing to give the regulated entity the benefit of a truly outside perspective concerning system safeguards, not colored by beginning from the institutional point of view, something that best practices say is important as noted earlier. Accordingly, testing performed by persons executing the internal audit function will not fulfill the requirement for testing by independent contractors, whether it is performed by employees executing the internal audit function or by internal audit contractors to whom a DCM, SEF, or SDR outsources part or all of its internal audit function. 73 80 FR 80139, 80148 (Dec. 23, 2015). 2. Vulnerability Testing—§§ 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 year. 76 It provided that all other vulnerability testing by covered DCMs and SDRs, and all vulnerability testing by non-covered DCMs and SEFs, should be conducted either by independent contractors or by employees not responsible for development or operation of the systems or capabilities being tested. 77 74 80 FR 80139, 80148 through 80151 (Dec. 23, 2015). 75 Id. at 80149, 80150. 76 Id. at 80150. 77 Id. at 80150, 80151. b. Comments Received (1) Requirement for Vulnerability Testing Several commenters, including CME, ICE, and Nadex, agreed that the NPRM's call for vulnerability testing was appropriate, because such testing is critical to identification and remediation of cybersecurity vulnerabilities. CME stated that vulnerability testing, of a scope aligned with risk analysis, should be embedded in an organization's systems development life cycle, in order to promote a culture of awareness as early and close to the first line of defense as possible. (2) Vulnerability Testing Frequency Commenters, including CME and ICE, supported the minimum quarterly vulnerability testing frequency requirement for covered DCMs and SDRs. CME noted that at least quarterly testing is likely to be an appropriate frequency for most organizations where critical assets are concerned. Regarding the requirement to test as often as indicated by appropriate risk analysis, CME agreed that vulnerability testing frequency should be aligned with appropriate risk analysis. MGEX called for the final rule to leave the frequency of vulnerability testing to be determined by regulatees. ICE argued that regulatees should not be subject to a formal risk assessment to potentially determine a higher vulnerability testing frequency. Nadex asked the Commission to confirm that the level of detail in the risk assessment used to determine appropriate vulnerability testing frequency is that called for by generally accepted standards and best practices. (3) Automated Scanning and Authenticated Scanning Commenters raised no issue with the NPRM requirement for vulnerability testing to include automated vulnerability scanning. ICE called for removal of the requirement for automated scanning to include authenticated scanning, arguing that this requirement would increase the cost and time of a scan, increase risk through creation of an operating system login on a new system, and have limited utility in the context of financial system infrastructure. (4) Vulnerability Testing by Independent Contractors A number of commenters argued that the use of independent contractors for vulnerability testing could undesirably increase risks. CME suggested that outsider access to systems can broaden both operations risk and the risk of disclosure of sensitive information, and noted that there is a limited supply of independent contractors with appropriate qualifications for vulnerability testing. ICE commented that vulnerability scanners can be hazardous to systems, can cause issues during deployment, and require a high level of care to avoid live system jeopardy, including both intimate network knowledge and change control interaction. In short, ICE stated, third-party vulnerability scanning would be costly and potentially dangerous without adding value. DDR stated that vulnerability testing by independent contractors would introduce unnecessary risk to critical infrastructure and heighten the risk of systems outages. These commenters therefore requested that the final rule eliminate the independent contractor requirement for vulnerability testing, and permit such testing to be conducted by entity employees not responsible for development or operation of the systems or capabilities tested. CME suggested that allowing such employees to conduct vulnerability testing has been proven effective, allows testing by those with the greatest knowledge and experience concerning the systems tested, and has the benefit of promoting an organizational culture of cybersecurity awareness. DDR recommended that SDR employees conduct vulnerability testing, and that independent contractors review testing procedures to confirm that they are effective and consonant with industry standards. c. Final Rule The Commission has considered and evaluated the comments concerning vulnerability testing. For the reasons set out below, the final rule will call for vulnerability testing and include the proposed vulnerability testing frequency requirements, but will not require that automated vulnerability scanning include authenticated scanning, and will not require the use of independent contractors as proposed. (1) Requirement for Vulnerability Testing The Commission agrees with commenters that vulnerability testing is critical to identification and remediation of cybersecurity vulnerabilities. It is an essential component of an effective program of risk analysis and oversight, and an essential means of fulfilling the testing requirements of the Commission's current system safeguards rules. (2) Vulnerability Testing Frequency The Commission agrees with the comments supporting the minimum quarterly vulnerability testing requirement for covered DCMs and SDRs, and agrees that, in today's cybersecurity environment, most organizations should conduct such testing at least quarterly. The Commission also agrees that, beyond the minimum frequency proposed for covered DCMs and SDRs, all DCMs, SEFs, and SDRs should conduct vulnerability testing as frequently as indicated by appropriate risk analysis. The Commission disagrees with the suggestion that the frequency of vulnerability testing should simply be left to these entities themselves. It is essential for such testing to be conducted as frequently as indicated by analysis of a particular entity's risks, which is likely in most cases to call for testing at least quarterly. The risk analysis referred to in the NPRM in this connection is the appropriate risk analysis which each DCM, SEF, and SDR must conduct and maintain as an integral part of the program of risk analysis and oversight that the CEA requires. ICE apparently misunderstood the NPRM as calling for a separate, formal risk analysis made for the specific purpose of determining vulnerability testing frequency. That is not required; what is required is vulnerability testing as often as indicated by the ongoing, appropriate risk analysis inherent in a regulatee's required program of risk analysis and oversight. As provided in the current system safeguards rules and in the NPRM, the program of risk analysis required of a DCM, SEF, or SDR, and the risk analyses inherent in that program, are indeed to be conducted in light of generally accepted standards and best practices. 78 78 80 FR 80139, 80149, 80150 (Dec. 23, 2015). (3) Automated Scanning and Authenticated Scanning No commenters disagreed with the proposed requirement for vulnerability testing to include automated 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 79 80 FR 80139, 80152 (Dec. 23, 2015). 80 Id. at 80152, 80153. 81 Id. at 80153. 82 Id. at 80152, 80153. b. Comments Received (1) Requirement for External Penetration Testing Commenters raised no issue with the NPRM's call for external penetration testing. CME noted that penetration testing is a significant component of the program to identify and minimize sources of operational risk required of all DCMs, SEFs, and SDRs. CME also approved the flexibility concerning penetration test design provided in the NPRM. Nadex noted its agreement with the NPRM's penetration testing requirement. (2) External Penetration Testing Frequency Commenters also raised no issue with the requirement for all DCMs, SEFs, and SDRs to conduct external penetration testing at a frequency determined by appropriate risk analysis. CME noted that many risk based factors should inform the frequency of such testing. Several commenters also supported the annual minimum frequency requirement for external penetration testing by covered DCMs and SDRs. CME stated that annual external penetration testing generally will be appropriate, ICE stated that it agrees with the annual requirement, and Nadex agreed with the NPRM's penetration testing requirements. MGEX called for the final rule to leave the frequency of external penetration testing to be determined by regulatees. ICE argued that regulatees should not be subject to a formal risk assessment to potentially determine a higher penetration testing frequency. (3) External Penetration Testing by Independent Contractors Most commenters raised no issue with the requirement for covered DCMs and SDRs to have the required annual external penetration test conducted by independent contractors. DDR commented generally that an SDR should have flexibility regarding whether to have testing conducted by independent contractors or employees not responsible for development or operation of the systems or capabilities tested, based on the risks of that SDR. c. Final Rule The Commission has considered and evaluated the comments concerning external penetration testing. For the reasons discussed below, the final rule will include the NPRM provisions regarding such testing as proposed. (1) Requirement for External Penetration Testing The Commission agrees with commenters that external penetration testing is a significant and essential component of an effective program of system safeguards risk analysis and oversight. Such testing is an essential means of fulfilling the testing requirement in the Commission's current system safeguards rules. (2) External Penetration Testing Frequency The Commission agrees with the comment that many risk based factors should inform the frequency of external penetration testing, and notes that this is true for all DCMs, SEFs, and SDRs. The Commission also agrees with the comments supporting the minimum frequency requirement of annual external penetration testing by covered DCMs and SDRs. As noted in the NPRM, this requirement is supported by generally accepted standards and best practices, which make it clear that such testing at least annually is essential to adequate system safeguards in today's cybersecurity environment. For this reason, the Commission disagrees with the suggestion that the frequency of such testing by covered DCMs and SDRs should be left to determination by those entities themselves. The proposal's minimum requirement was for a single annual test; although, as noted in the NPRM, adequate risk analysis could well require more frequent testing in light of the risks faced by a particular regulatee. 83 A separate, formal risk analysis made for the specific purpose of determining external penetration testing frequency is not required. Rather, external penetration testing is required as often as indicated by the ongoing, appropriate risk analysis inherent in a regulatee's statutorily-required program of risk analysis and oversight, conducted in light of generally accepted standards and best practices. 83 Id. at 80152. (3) External Penetration Testing by Independent Contractors In determining the final rule's provisions regarding external penetration testing by independent contractors, the Commission has noted that, as set forth above, most commenters raised no issue with this requirement for covered DCMs and SDRs. As noted in the NPRM, generally accepted standards and best practices make it clear that independent testing by third party service providers is an essential component of an adequate testing regime, and that this is notably the case with respect to penetration testing. 84 The Commission believes that the independent viewpoint and approach provided by independent contractors, who can conduct a penetration test from the perspective of an outside adversary uncolored by insider assumptions or blind spots, will benefit covered DCM and SDR programs of risk analysis and oversight. Independent contractor penetration testing will strengthen Commission oversight of system safeguards, by providing an important, credible third source of information in addition to what is available from covered DCM or SDR staff and from the internal audit function of those entities. In light of these considerations, the Commission disagrees with the comments suggesting elimination of the requirement for the minimum annual external penetration test of a covered DCM or SDR to be conducted by independent contractors. 84 Id. at 80153. 4. Internal Penetration Testing—§§ 37.1401(h)(4), 38.1051(h)(4), and 49.24(j)(4) a. Proposed Rule The NPRM called for all DCMs, SEFs, and SDRs to conduct internal penetration testing of a scope sufficient to satisfy the requirements in the proposed rule. 85 It proposed requiring all such entities to conduct external penetration testing at a frequency determined by an appropriate risk analysis, with a minimum frequency requirement of annual internal penetration testing for covered DCMs and SDRs. 86 The NPRM provided that all internal penetration testing by DCMs, SEFs, or SDRs should be conducted either by independent contractors or by employees not responsible for development or operation of the systems or capabilities being tested. 87 85 80 FR 80139, 80152 (Dec. 23, 2015). 86 Id. at 80152, 80153. 87 Id. b. Comments Received (1) Requirement for Internal Penetration Testing Commenters raised no issue with the NPRM's call for internal penetration testing. As noted above concerning external penetration testing, CME noted that penetration testing generally is a significant component of the program to identify and minimize sources of operational risk required of all DCMs, SEFs, and SDRs, and approved the flexibility concerning penetration test design provided in the NPRM. Also as noted above, Nadex stated its agreement with the NPRM's penetration testing requirements. (2) Internal Penetration Testing Frequency Commenters also raised no issue with the requirement for all DCMs, SEFs, and SDRs to conduct internal penetration testing at a frequency determined by appropriate risk analysis. As noted above, CME stated that many risk based factors should inform the frequency of penetration testing generally. With respect to the requirement for covered DCMs and SDRs to conduct internal penetration testing at least annually, ICE stated agreement with the proposal. Nadex agreed with the proposed penetration testing requirements generally. On the basis that that there is a scarcity of potential employees with the skill set required to conduct internal penetration testing without introducing risks into the production environment and other sensitive environments, CME suggested making annual internal penetration testing an objective rather than a requirement, so that covered DCMs and SDRs can prioritize truly effective testing over less skilled testing done merely to satisfy the annual requirement. As noted above, MGEX called for the final rule to leave the frequency of penetration testing to be determined by regulatees. ICE argued that regulatees should not be subject to a formal risk assessment to potentially determine a higher penetration testing frequency. (3) Who Should Perform Internal Penetration Testing Commenters raised no issue with the NPRM provision giving all DCMs, SEFs, and SDRs the choice of whether to have internal penetration testing performed by independent contractors or by employees not responsible for development or operation of the systems or capabilities tested. c. Final Rule The Commission has considered and evaluated the comments concerning internal penetration testing. For the reasons discussed below, the final rule will include the NPRM's internal penetration testing provisions as proposed. 88 88 80 FR 80139, 80152, 80153 (Dec. 23, 2015). (1) Requirement for Internal Penetration Testing The Commission agrees with commenters that external penetration testing is a significant and essential component of an effective program of system safeguards risk analysis and oversight. Such testing is an essential means of fulfilling the testing requirement in the Commission's current system safeguards rules. (2) Internal Penetration Testing Frequency The Commission agrees with the comment that many risk based factors should inform the frequency of internal penetration testing, and notes that this is true for all DCMs, SEFs, and SDRs. It also agrees with the comments supporting the minimum frequency requirement of annual internal penetration testing by covered DCMs and SDRs. As noted in the NPRM, this requirement, like the parallel requirement regarding external penetration testing, is supported by generally accepted standards and best practices, which make it clear that such testing at least annually is essential to adequate system safeguards in today's cybersecurity environment. 89 Accordingly, the Commission disagrees with the suggestions that annual internal penetration testing by covered DCMs and SDRs should be a mere objective, or that the frequency of such testing by covered DCMs and SDRs should be left to determination by those entities themselves. The Commission also notes, as it stated in the NPRM, that adequate risk analysis could well require more frequent testing in light of the risks faced by a particular regulatee. 90 A separate, formal risk analysis made for the specific purpose of determining internal penetration testing frequency is not required. Rather, internal penetration testing is required as often as indicated by the ongoing, appropriate risk analysis inherent in a regulatee's required program of risk analysis and oversight, conducted in light of generally accepted standards and best practices. 89 Id. 90 Id. (3) Who Should Perform Internal Penetration Testing The Commission continues to believe, as provided in the NPRM, that it is appropriate to give all DCMs, SEFs, and SDRs the choice of whether to have internal penetration testing performed by independent contractors or by employees not responsible for development or operation of the systems or capabilities tested. 91 Commenters raised no issue with this provision. 91 Id. at 80153. 5. Controls Testing—§§ 37.1401(h)(5), 38.1051(h)(5), and 49.24(j)(5) a. Proposed Rule The NPRM called for each DCM, SEF, and SDR to conduct controls testing of a scope sufficient to satisfy the scope requirements in the proposed rule, including testing of each control included in the entity's program of risk analysis and oversight. 92 It proposed each such entity to conduct controls testing at frequency determined by an appropriate risk analysis, with a minimum frequency requirement for covered DCMs and SDRs calling for testing of all controls every two years. 93 The NPRM provided that covered DCMs and SDRs could conduct such testing on a rolling basis over the minimum two-year period or over the minimum period determined by appropriate risk analysis, whichever is shorter. 94 The NPRM called for covered DCMs and SDRs to engage independent contractors to conduct testing of key controls no less frequently than every two years. 95 It provided that all other controls testing by covered DCMs and SDRs, and all controls testing by non-covered DCMs and SEFs, should be conducted either by independent contractors or by employees not responsible for development or operation of the systems or capabilities being tested. 96 92 Id. at 80153, 80154. 93 Id. at 80154. 94 Id. 95 Id. 96 Id. at 80154, 80155. b. Comments Received (1) Requirement for Controls Testing CME and Nadex approved of the NPRM's call for controls testing. CME stated that the NPRM correctly identified controls testing as a crucial part of a program of risk analysis and oversight, and agreed with the categories which the current rules and the NPRM specify as included in such a program. CME also agreed with the NPRM's flexible approach to using best practices to inform the design and implementation of controls testing in light of risk analysis. ICE called for the final rule to eliminate the requirement for controls testing, arguing that many controls do not require testing, that few organizations have a static universe of controls, and that control weaknesses will come to light in vulnerability and penetration testing. Tradeweb asked the Commission to provide further guidance on how controls testing differs from vulnerability testing, whether Service Organization Controls (“SOC”) 1 and 2 reports prepared in accordance with the American Institute of Certified Public Accountants' Statement on Standards for Attestation Engagements (“SSAE”) Number 16 could be used for controls testing purposes, and whether penetrations tests could be used to fulfill controls testing requirements. (2) Controls Testing Frequency Regarding the minimum controls testing frequency of every two years proposed for covered DCMs and SDRs, CME commented that some less critical controls do not warrant testing on a two-year cycle, and cited best practices permitting controls testing on a three-year cycle. CME suggested that the final rule should call for the minimum controls testing frequency for covered DCMs and SDRs to be determined by risk analysis (as the NPRM proposed for non-covered DCMs and SEFs), or alternatively that a minimum frequency cycle of three years would be a reasonable alternative to the NPRM's proposed two-year cycle. CME suggested that, while many organizations will implement a two-year schedule for at least the testing of key controls, either of CME's proposed alternatives would make controls testing more cost effective, and increase focus on the most critical controls. (3) Who Should Perform Controls Testing CME commented that effective testing of key controls can be done by employees not responsible for development or operation of the controls tested, as well as by independent contractors, and that such independent employees' familiarity with the organization's controls can improve the efficiency and effectiveness of controls testing. Accordingly, CME suggested that, while independent contractor controls testing may be beneficial, the final rule should not exclude controls testing by independent employees, for example employees such as internal audit staff. DDR also commented that, where the NPRM proposed to require independent contractor testing, the final rule should give flexibility to use either independent contractors or independent employees. ICE suggested that the final rule should not require key controls testing at all. In support, ICE argued that the concept of key controls is not universally adopted; that risk analysis relies on testing of all controls in concert; that a testing requirement directed at key controls could result in organizations documenting fewer controls; and that the key controls testing proposal would impose a large burden for little or no practical improvement in security. MGEX stated that the NPRM required testing of all controls on a rolling basis by independent contractors every two years. c. Final Rule The Commission has considered and evaluated the comments concerning controls testing. For the reasons discussed below, the Commission is adopting the NPRM's requirement for all DCMs, SEFs, and SDRs to conduct testing of all their system safeguards-related controls, its requirement for such testing by all such entities to be conducted as often as indicated by appropriate risk analysis, and its requirement for independent contractor testing of the key controls of covered DCMs and SDRs. However, for the reasons discussed below concerning controls testing frequency, the Commission is modifying the proposed controls testing minimum frequency requirement for covered DCMs and SDRs, to call for testing of their key controls—including independent contractor testing of such controls—within a three-year rather than a two-year period. (1) Requirement for Controls Testing The Commission agrees with commenters that controls testing is a crucial part of a program of risk analysis and oversight and that best practices should inform the design and implementation of controls testing in light of risk analysis. In today's rapidly-changing cybersecurity threat environment, regular, ongoing controls testing that verifies over time the effectiveness of each system safeguards control used by a DCM, SEF, or SDR is essential to ensuring the continuing overall efficacy of the entity's system safeguards. The Commission disagrees with the suggestion that the final rule should not require any controls testing. As noted in the NPRM, generally accepted standards and best practices call for such testing. 97 Moreover, in conducting oversight of system safeguards, Commission staff have found a significant number of instances, at both larger and smaller entities, where (a) system malfunctions, market halts, and the success of cyber intrusions were caused by failures of both key and non-key controls; (b) such problems could have been prevented had the controls in question been tested; and (c) testing of the relevant controls had been entirely omitted or not done for substantial periods of time. The controls testing requirement set out in the NPRM is designed to remedy such situations, and ensure that controls testing by all DCMs, SEFs, and SDRs follows best practices. By design, the NPRM did not prescribe the design of the overall program of controls testing or the particular tests it may include. Various forms of testing, including vulnerability testing, penetration testing, SSAE16 SOC1 or SOC2 assessments, and others, may well contribute in varying degrees—subject to their particular natures and limitations—to an overall program for the testing of controls as called for by the NPRM. The Commission notes that the depth and coverage of a single assessment may not be sufficient to meet the final rule's testing scope requirements discussed below. It also notes that the proposed controls testing requirement gives DCMs, SEFs, and SDRs the flexibility to determine the appropriate combination of testing methods and techniques necessary to determine whether their controls are implemented correctly, operating as intended, and enabling them to meet the system safeguards requirements of the Commission's rules. 97 80 FR 80139, 80152 (Dec. 23, 2015). (2) Controls Testing Frequency The Commission has noted the best practices cited by CME supporting controls testing on a three-year cycle. After due consideration, the Commission agrees that a three-year rather than two-year minimum controls testing frequency requirement for covered DCMs and SDRs may reduce costs and burdens, while providing beneficial flexibility in overall controls testing program design and still ensuring that the fundamental purposes of the CEA and the Commission's system safeguards rules are achieved. The NPRM called for covered DCMs and SDRs, as well as non-covered DCMs and SEFs, to conduct controls testing as frequently as appropriate risk analysis requires. 98 The Commission notes that this fundamental frequency requirement could well require a controls testing cycle shorter than three years, as acknowledged in the comment on this point. In light of these considerations, the final rule requires all DCMs, SEFs, and SDRs to test the controls included in their programs of risk analysis and oversight as frequently as appropriate risk analysis requires. At a minimum, it will require covered DCMs and SDRs to conduct the required key controls testing—including key controls testing by independent contractors as discussed below—no less frequently than every three years. As proposed in the NPRM, it will permit covered DCMs and SDRS to conduct such testing on a rolling basis, but require this to be done over the course of the minimum period or the period determined by an appropriate risk analysis, whichever is shorter. 98 80 FR 80139, 80154 (Dec. 23, 2015). (3) Who Should Perform Controls Testing The Commission agrees with the comments noting that testing of key controls by both independent contractors and employees not responsible for development or operation of the controls tested can be valuable and effective. As noted in the NPRM, best practices recognize the value of, and recommend, both such approaches. 99 The Commission notes that the NPRM did not propose barring covered DCM or SDR employees from testing key controls; rather, it proposed that covered DCM and SDR testing of key controls include independent contractor testing of all such controls within the minimum period. As with penetration testing, the Commission believes that independent contractor testing of key controls will strengthen covered DCM and SDR programs of risk analysis and oversight, by providing a valuable outsider perspective concerning crucial safeguards uncolored by insider assumptions or blind spots. The Commission further believes that independent contractor testing of key controls will strengthen Commission oversight of system safeguards, by providing an important, credible third source of information concerning crucial safeguards in addition to what is available from covered DCM or SDR staff and from the internal audit function of those entities. As noted above, because best practices call for controls testing, the Commission disagrees with the comment suggesting that the final rule should not require testing of key controls by either independent contractors or employees. The NPRM did not require independent contractor testing of all controls, but rather required independent contractor testing of the key controls of covered DCMs and SDRs. 100 99 Id. at 80154, 80155. 100 Id. 6. Security Incident Response Plan Testing—§§ 37.1401(h)(6), 38.1051(h)(6), and 49.24(j)(6) a. Proposed Rule The NPRM called for each DCM, SEF, and SDR to conduct security incident response plan (“SIRP”) testing of a scope sufficient to satisfy the scope requirements in the proposed rule. 101 It called for each such entity's SIRP to include, without limitation, the entity's definition and classification of security events, its policies and procedures for reporting and communicating internally and externally concerning security incidents, and the hand-off and escalation points in its security incident response process. 102 It proposed permitting each such entity to coordinate its SIRP testing with its BC-DR plan or other testing required by the applicable system safeguards rules. 103 The NPRM proposed requiring all DCMs, SEFs, and SDRs to conduct SIRP testing at a frequency determined by an appropriate risk analysis, with a minimum frequency requirement of annual SIRP testing for covered DCMs and SDRs. 104 Finally, the NPRM called for all DCMs, SEFs, and SDRs to have SIRP testing conducted by either independent contractors or employees not responsible for development or operation of the systems or capabilities tested. 105 101 Id. at 80155 through 80157. 102 Id. 103 Id. at 80157. 104 Id. 105 Id. b. Comments Received (1) Requirement To Maintain and Test a SIRP Several commenters agreed with the NPRM's call for each DCM, SEF, and SDR to maintain and test a SIRP meeting the requirements in the proposal. CME called SIRPs an important tool for all entities in their efforts to be ready to face inevitable cyber attacks. CME noted its appreciation for the proposal's flexibility for entities to design their SIRP testing in light of their risk analysis, and for the proposal's approval of coordination of SIRP testing with other types of testing. ICE and Nadex also stated support for the NPRM's SIRP testing provision. However, while Tradeweb stated that having a SIRP is essential to the functioning of a SEF, it argued that the SIRP testing requirement should be reduced to annual review and approval of the SIRP by a SEF employee responsible for information security. (2) SIRP Testing Frequency No commenters expressed disagreement with the proposed requirement for all DCMs, SEFs, and SDRs to conduct SIRP testing as often as indicated by appropriate risk analysis. Regarding the proposed requirement for covered DCMs and SDRs to test their SIRPs once a year at a minimum, CME commented that at least annual SIRP testing is appropriate in today's cybersecurity environment. (3) Who Should Conduct SIRP Testing No commenters expressed disagreement with the proposed general requirement giving DCMs, SEFs, and SDRs the choice of whether to have SIRP testing conducted by independent contractors or employees. However, CME suggested that the final rule should permit SIRP testing to be led by an independent employee who is not responsible for development or operation of what is tested but who is responsible for design of the SIRP itself. CME stated that this would allow the entity to leverage its employees with expertise in crisis and risk management and in incident response and planning, for both planning and testing purposes, in a way that is optimal for the entity's system safeguards. c. Final Rule The Commission has considered and evaluated the comments concerning SIRP testing. For the reasons discussed below, the Commission is adopting the proposed requirements for each DCM, SEF, and SDR to maintain a SIRP (as defined and described) and test it as often as indicated by appropriate risk analysis, and the proposed requirement for each covered DCM and SDR to conduct SIRP testing at least annually. It is modifying the proposed provisions regarding who may conduct SIRP testing, to permit testing to be led or conducted either by independent contractors or by any entity employee. (1) Requirement To Maintain and Test a SIRP The Commission agrees with commenters that maintaining and testing a SIRP is important for effective system safeguards in today's cybersecurity environment. The Commission confirms that the proposed SIRP testing requirement is indeed intended to give DCMs, SEFs, and SDRs flexibility concerning the format and design of their SIRP testing, and concerning its coordination with other types of testing, so long as the entity's SIRP testing is consonant with appropriate risk analysis and enables fulfillment of the proposed scope requirements. The Commission disagrees with the suggestion that the requirement to test the SIRP should be reduced to mere annual review and approval of the SIRP by an employee responsible for information security. As noted in the NPRM, best practices emphasize that SIRP testing is crucial to effective cyber incident response in today's cybersecurity environment. 106 Failure to practice the cyber incident response process can delay or paralyze timely response and cause severe consequences. 106 80 FR 80139, 80155 through 80156 (Dec. 23, 2015). (2) SIRP Testing Frequency The Commission notes that no commenters disagreed with the requirement to conduct SIRP testing as often as indicated by appropriate risk analysis, and agrees with the comment that at least annual SIRP testing is appropriate for covered DCMs and SDRs in today's cybersecurity environment. (3) Who Should Conduct SIRP Testing The Commission has considered the suggestion that allowing SIRP testing to be led by an employee responsible for design of the SIRP itself could improve system safeguards in general and SIRP testing in particular. The Commission believes that this could provide useful benefits and flexibility to DCMs, SEFs, and SDRs, without impairing the purposes of the CEA and the Commission's regulations which SIRP testing is designed to advance. In addition, SIRP testing differs from the other types of testing specified in the final rule, in that what is tested is not automated systems but the security incident response plan itself, or in other words what people do if a security incident happens. Accordingly, the final rule calls for SIRP testing by all DCMs, SEFs, and SDRs to be conducted by either independent contractors or employees, without restricting which employees may lead or conduct the testing. 7. Enterprise Technology Risk Assessment—§§ 37.1401(h)(7), 38.1051(h)(7), and 49.24(j)(7) a. Proposed Rule The NPRM called for each DCM, SEF, and SDR to conduct enterprise technology risk assessment (“ETRA”) of a scope sufficient to satisfy the scope requirements in the proposed rule. 107 It called for each DCM, SEF, and SDR to conduct an ETRA as often as required by appropriate risk analysis, and for covered DCMs and SDRs to do this at least annually. 108 It stated that all regulatees could conduct ETRAs by using independent contractors or employees not responsible for development or operation of the systems or capabilities being assessed. 109 107 Id. at 80157 through 80159. 108 Id. at 80158. 109 Id. at 80158, 80159. b. Comments Received (1) ETRA Requirement CME agreed that regular risk assessments should drive ongoing efforts to address cyber risks. Nadex stated its general agreement with the proposed ETRA requirement. ICE argued that the ETRA requirement is already adequately addressed by current Commission rules, and called for omission of the ETRA requirement in the final rule. ICE also argued that the proposed ETRA requirement is not cyber-specific and does not focus on the confidentiality, availability, or integrity of data. Tradeweb agreed that assessment of technology risks is essential, but argued that the ETRA requirement is duplicative of the other proposed testing requirements. (2) ETRA Frequency and Scope CME suggested that ETRAs would benefit from incorporating the results of controls testing and other testing, and suggested that it would be beneficial and less costly to align the requirement for completing an ETRA with the applicable frequency requirement for controls testing. Nadex requested clarification of whether the ETRA could incorporate the results of other required testing as reported to management and the board of directors, or whether a full stand-alone assessment is required. Tradeweb suggested that an annual full assessment would be burdensome and costly, and suggested that, in lieu of repeated full assessments, annual review and approval of previous assessments should be sufficient. (3) Who Should Conduct ETRAs No commenters expressed disagreement with the NPRM provision calling for ETRAs to be conducted by either independent contractors or employees not responsible for development or operation of the systems or capabilities assessed. ICE suggested that ETRAs should be carried out by enterprise risk program staff rather than information security staff. c. Final Rule The Commission has considered and evaluated the comments concerning ETRAs. For the reasons discussed below, the Commission is adopting the proposed requirements, but is adding a provision in the final rule stating that a DCM, SEF, or SDR that has conducted an enterprise technology risk assessment as required may conduct subsequent assessments by updating the previous assessment. (1) ETRA Requirement The Commission agrees with the comment that regular risk assessments should drive ongoing efforts to address cyber risks. The Commission continues to believe that conducting regular ETRAs is essential to meeting the testing requirements of its current system safeguards rules and maintaining system safeguards resiliency in today's cybersecurity environment. Regular, ongoing identification, estimation, and prioritization of risks that could result from impairment of the confidentiality, integrity, or availability of data and information or the reliability, security, and capacity of automated systems is crucial to effective system safeguards. As noted in the NPRM, regular performance of ETRAs is a well-established best practice. 110 The proposed ETRA requirement is designed to provide an overarching vehicle through which a DCM, SEF, or SDR draws together and uses the results and lessons learned from each of the types of cybersecurity and system safeguards testing addressed in the proposed rule, in addition to other methods of risk identification, in order to identify and mitigate its system safeguards-related risks. ETRAs can also inform the design of the other types of testing. As such, the ETRA requirement it is not duplicative of the other testing requirements, but rather an enhancement of their value. The Commission also notes that, as discussed above, multiple NPRM provisions to be adopted in the final rule call for determinations made in light of the appropriate risk analysis that is required by the CEA. Accordingly, a regulatee's current ETRA summarizing in writing both its analysis of its system safeguards risks and the basis for that analysis and for the entity's system safeguards decisions will be a key tool for Commission determination of the adequacy of the entity's compliance with system safeguards requirements. The Commission therefore disagrees with the suggestion that the final rule should omit the ETRA requirement. 110 Id. at 80158. (2) ETRA Frequency and Scope While the Commission agrees that the results of other types of testing can usefully inform ETRAs, the Commission believes that, as best practices provide, regularly updated ETRAs are crucial to the effectiveness of system safeguards in today's rapidly changing cybersecurity environment. The Commission therefore does not accept the suggestion that ETRAs should only be required as often as a complete cycle of controls testing is completed, not least because the final rule is adopting the suggestion to lengthen that cycle to three rather than two years. The Commission reiterates that the results of other required forms of system safeguards testing can and should be incorporated in ETRAs, and in turn should be informed and driven by ETRAs. Because ETRAs that provide current assessment of current risks are essential to effective programs of system safeguards risk analysis and oversight, as discussed above, the Commission disagrees with the suggestion that annual review and reapproval of previous assessments would be sufficient. However, the Commission believes that thorough updating of a previous assessment conducted in compliance with the ETRA requirements set out in the NPRM can be sufficient to fulfill the purposes of an appropriate ETRA, and can reduce costs and burdens without impairment of the purposes of the CEA and the system safeguards rules. Accordingly the final rule clarifies that such updating of a previous fully compliant ETRA, in light of current risks and circumstances, can fulfill the ETRA requirement. The Commission emphasizes that best practices require all DCMs, SEFs, and SDRs to conduct risk assessment and monitoring on an ongoing basis, as frequently as the entity's risks and circumstances require. The final rule requirement for covered DCMs and SDRs to prepare a written assessment on at least an annual basis does not eliminate the need for a covered DCM or SDR to conduct risk assessment and monitoring on an ongoing basis, as best practices require. Rather, the minimum frequency requirement is intended to formalize the risk assessment process and ensure that it is documented at a minimum frequency. (3) Who Should Conduct ETRAs The NPRM's call for ETRAs to be conducted by either independent contractors or employees not responsible for development or operation of the systems or capabilities assessed drew no objections from commenters. The Commission also notes that the NPRM did not prescribe whether enterprise risk program staff, information security staff, or both should conduct ETRAs, but deliberately left flexibility to DCMs, SEFs, and SDRs in this regard, so long as the employees conducting the ETRA have the independence specified. F. Scope of Testing and Assessment—§§ 37.1401(k), 38.1051(k), and 49.24(l) 1. Proposed Rule The NPRM called for the scope of all system safeguard [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2016-22174. Public record. Not legal advice.