81 FR 64321 - System Safeguards Testing Requirements for Derivatives Clearing Organizations
COMMODITY FUTURES TRADING COMMISSION Federal Register Volume 81, Issue 181 (September 19, 2016)
Federal Register Volume 81, Issue 181 (September 19, 2016)
| Page Range | 64321-64340 | |
| FR Document | 2016-22413 |
[Federal Register Volume 81, Number 181 (Monday, September 19, 2016)] [Rules and Regulations] [Pages 64321-64340] From the Federal Register Online [www.thefederalregister.org] [FR Doc No: 2016-22413] [[Page 64321]] Vol. 81 Monday, No. 181 September 19, 2016 Part III Commodity Futures Trading Commission ----------------------------------------------------------------------- 17 CFR Part 39 System Safeguards Testing Requirements for Derivatives Clearing Organizations; Final Rule Federal Register / Vol. 81 , No. 181 / Monday, September 19, 2016 / Rules and Regulations [[Page 64322]] ----------------------------------------------------------------------- COMMODITY FUTURES TRADING COMMISSION 17 CFR Part 39 RIN 3038-AE29 System Safeguards Testing Requirements for Derivatives Clearing Organizations AGENCY: Commodity Futures Trading Commission. ACTION: Final rule. ----------------------------------------------------------------------- SUMMARY: The Commodity Futures Trading Commission (``Commission'') is adopting enhanced requirements for testing by a derivatives clearing organization (``DCO'') of its system safeguards, as well as additional amendments to reorder and renumber certain paragraphs within the regulations and make other minor changes to improve the clarity of the rule text. DATES: Effective date: This rule is effective September 19, 2016. Compliance dates: DCOs must comply with Sec. 39.18(e)(2) and (6) by March 20, 2017; Sec. 39.18(e)(3) through (5), and (7) by September 19, 2017; and all other provisions of Sec. 39.18 by September 19, 2016. FOR FURTHER INFORMATION CONTACT: Eileen A. Donovan, Deputy Director, 202-418-5096, [email protected], Division of Clearing and Risk, Commodity Futures Trading Commission, Three Lafayette Centre, 1155 21st Street NW., Washington, DC 20581; or Julie A. Mohr, Deputy Director, (312) 596-0568, [email protected]; Tad Polley, Associate Director, (312) 596-0551, [email protected]; or Scott Sloan, Attorney-Advisor, (312) 596-0708, [email protected], Division of Clearing and Risk, Commodity Futures Trading Commission, 525 West Monroe Street, Chicago, Illinois 60661. SUPPLEMENTARY INFORMATION: I. Background A. System Safeguards Requirements for DCOs Section 5b(c)(2) of the Commodity Exchange Act (``CEA'') \1\ sets forth core principles with which a DCO must comply in order to be registered and to maintain registration with the Commission. In November 2011, the Commission adopted regulations \2\ to establish standards for compliance with the core principles, including Core Principle I, which concerns a DCO's system safeguards.\3\ In 2013, the Commission adopted additional standards, including additional system safeguards requirements,\4\ for compliance with the core principles for systemically important DCOs (``SIDCOs'') and DCOs that elect to opt-in to the SIDCO regulatory requirements (``Subpart C DCOs'').\5\ --------------------------------------------------------------------------- \1\ 7 U.S.C. 7a-1. \2\ Derivatives Clearing Organization General Provisions and Core Principles, 76 FR 69334 (Nov. 8, 2011) (codified at 17 CFR part 39). \3\ Core Principle I requires a DCO to: (1) Establish and maintain a program of risk analysis and oversight to identify and minimize sources of operational risk; (2) establish and maintain emergency procedures, backup facilities, and a plan for disaster recovery that allows for the timely recovery and resumption of the DCO's operations and the fulfillment of each of its obligations and responsibilities; and (3) periodically conduct tests to verify that the DCO's backup resources are sufficient. \4\ 17 CFR 39.34. \5\ Derivatives Clearing Organizations and International Standards, 78 FR 72476 (Dec. 2, 2013) (codified at 17 CFR part 39). --------------------------------------------------------------------------- Regulation 39.18 implements Core Principle I and, among other things, specifies: (1) The requisite elements, standards, and resources of a DCO's program of risk analysis and oversight with respect to its operations and automated systems; (2) the requirements for a DCO's business continuity and disaster recovery plan, emergency procedures, and physical, technological, and personnel resources described therein; (3) the responsibilities, obligations, and recovery time objective of a DCO following a disruption of its operations; and (4) other system safeguards requirements related to reporting, recordkeeping, testing, and coordination with a DCO's clearing members and service providers. On December 23, 2015, the Commission proposed to enhance its system safeguards requirements for DCOs by revising Sec. 39.18 to require specific types of testing, and specifying the minimum frequency with which such testing must be performed. The Commission also proposed additional amendments to reorder and renumber certain paragraphs and make other minor changes to improve the clarity of the rule text, as well as corresponding technical corrections to Sec. 39.34 (the ``Proposal'').\6\ --------------------------------------------------------------------------- \6\ See System Safeguards Testing Requirements for Derivatives Clearing Organizations; Proposed Rule, 80 FR 80114 (Dec. 3, 2015) (to be codified at 17 CFR part 39). --------------------------------------------------------------------------- The comment period for the Proposal ended on February 22, 2016. The Commission received seven substantive comment letters in response to the Proposal \7\ and, in consideration of those comments, is adopting the Proposal subject to certain changes, as noted below. --------------------------------------------------------------------------- \7\ All comment letters are available through the Commission's Web site at: http://comments.cftc.gov/PublicComments/CommentList.aspx?id=1649. The Commission received comments from the following parties: Intercontinental Exchange, Inc.; NGX; The Options Clearing Corporation; Minneapolis Grain Exchange; North American Derivatives Exchange; LCH.Clearnet Group; and CME Group, Inc. --------------------------------------------------------------------------- B. Need for Cybersecurity Testing In the Proposal, the Commission described the well-documented increase in cyber threats, and the need to enhance its existing requirements for cybersecurity testing in light of this increase.\8\ In the current environment, cybersecurity testing is crucial to efforts by exchanges, clearing organizations, swap data repositories, and other entities in the financial sector to strengthen cyber defenses; mitigate operational, reputational, and financial risk; and maintain cyber resilience and the ability to recover from cyber attacks. To maintain the effectiveness of cybersecurity controls, such entities must regularly test their system safeguards in order to find and fix vulnerabilities before an attacker exploits them. --------------------------------------------------------------------------- \8\ 80 FR 80114, at 80114-80115. --------------------------------------------------------------------------- Cybersecurity testing is a well-established best practice generally and for financial sector entities. The National Institute of Standards and Technology (``NIST'') Framework for Improving Critical Infrastructure Cybersecurity calls for testing of cybersecurity response and recovery plans and cybersecurity detection processes and procedures.\9\ The Financial Industry Regulatory Authority (``FINRA'') 2015 Report on Cybersecurity Practices notes that ``[r]isk assessments serve as foundational tools for firms to understand the cybersecurity risks they face across the range of the firm's activities and assets,'' and calls for firms to develop, implement, and test cybersecurity incident response plans.\10\ The Federal Financial Institutions Examination Council (``FFIEC''),\11\ another important source of [[Page 64323]] cybersecurity best practices for financial sector entities, notes that financial institutions should have a testing plan that identifies control objectives; schedules tests of the controls used to meet those objectives; ensures prompt corrective action where deficiencies are identified; and provides independent assurance for compliance with security policies.\12\ --------------------------------------------------------------------------- \9\ NIST, Framework for Improving Critical Infrastructure Cybersecurity, Feb. 2014, v. 1, Subcategory PR.IP-10, p. 28, and Category DE.DP, p. 31, available at: http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf. \10\ FINRA, Report on Cybersecurity Practices, Feb. 2015 (``FINRA Report''), pp. 1-2, available at: https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf. \11\ The FFIEC includes the Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation, the Office of the Comptroller of the Currency, the Consumer Financial Protection Bureau, the National Credit Union Administration, and the State Liaison Committee of the Conference of State Bank Supervision. \12\ See FFIEC, E-Banking Booklet: IT Examination Handbook, Aug. 2003, p. 30, available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_E-Banking.pdf. --------------------------------------------------------------------------- The Commission notes that Sec. 39.18(j)(1)(i) currently requires DCOs to conduct regular, periodic, and objective testing and review of their automated systems to ensure that these systems are reliable, secure, and have adequate scalable capacity. This requirement must be satisfied by following, at a minimum, generally accepted standards and industry best practices. The final rule being adopted by the Commission herein clarify these requirements by identifying particular types of testing required by relevant generally accepted standards and industry best practices. The Commission is requiring that independent contractors conduct certain testing and specifying a minimum frequency for each testing type, but otherwise is not changing the regulatory requirement for DCOs as it exists today. The additional clarity provided by the specific testing and frequency requirements as well as the independent contractor requirements will help DCOs increase their cyber resiliency and operate in a safe and efficient manner. II. Comments on the Notice of Proposed Rulemaking A. Vulnerability Testing Proposed Sec. 39.18(a) would define ``vulnerability testing'' as testing of a DCO's automated systems to determine what information may be discoverable through a reconnaissance analysis of those systems and what vulnerabilities may be present on those systems. Proposed Sec. 39.18(e)(2) would require the testing to be of a scope sufficient to satisfy the testing scope requirements of proposed Sec. 39.18(e)(8). Proposed Sec. 39.18(e)(2)(i) would require a DCO to conduct vulnerability testing at a frequency determined by an appropriate risk analysis, but at a minimum no less frequently than quarterly. Under proposed Sec. 39.18(e)(2)(ii), the vulnerability tests would have to include automated vulnerability scanning, which would have to be conducted on an authenticated basis where indicated by an appropriate risk analysis. Proposed Sec. 39.18(e)(2)(iii) would require a DCO to engage independent contractors to conduct two of the required quarterly tests each year. The other vulnerability tests could be conducted by employees of the DCO who are not responsible for development or operation of the systems or capabilities being tested. 1. Frequency CME Group, Inc. (``CME'') supported the proposed frequency for the required vulnerability testing. CME stated that testing on at least a quarterly basis is likely an appropriate frequency for most organizations for their most critical assets. Intercontinental Exchange, Inc. (``ICE'') supported a quarterly requirement, but believes that DCOs that meet the quarterly requirement should not be subject to a formal risk assessment to potentially determine a higher testing frequency as the Commission has not provided evidence that a higher frequency is warranted. Minneapolis Grain Exchange (``MGEX'') stated that frequency of testing should be determined by the frequency of system changes and the scope of exposure, and should not be reduced to a static minimum. NGX stated that quarterly vulnerability testing is too costly for smaller DCOs, and should be required semi-annually instead. The Commission does not believe it is prudent to change the frequency requirement for vulnerability tests. The requirement to conduct vulnerability tests at a frequency based on a risk analysis and at least quarterly is based on industry standards \13\ and will help ensure that DCOs are responsive to new vulnerabilities as they arise. --------------------------------------------------------------------------- \13\ See NIST Special Publication 800-39, Managing Information Security Risk, Mar. 2011 (``NIST SP 800-39''), pp. 47-48, available at: http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf; Security Standards Council, Payment Card Industry Data Security Standards, Apr. 2016, v. 3.2 (``PCI-DSS''), p. 98, available at: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf; FFIEC, Information Security Booklet, IT Examination Handbook, July 2006 (``FFIEC Handbook''), p. 82, available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf. --------------------------------------------------------------------------- 2. Risk Assessment North American Derivatives Exchange, Inc. (``Nadex'') stated that the rule should be clarified to provide that the expected level of detail contained in the risk analysis used to determine the required frequency of overall testing should be based on what is considered reasonable in the industry. The Commission does not believe a clarification is necessary because the rule as proposed is appropriately based on industry standards.\14\ --------------------------------------------------------------------------- \14\ See FFIEC Handbook, supra note 13, at 82. --------------------------------------------------------------------------- 3. Authenticated Scanning ICE argued that the Commission should eliminate the authenticated vulnerability scanning requirement on the basis that it will increase the cost and time of a scan, increase risk by requiring an operating system login to be created and maintained on a new system, and increase the quantity of findings, potentially diluting and obscuring important results. The Commission agrees with ICE that an explicit requirement for authenticated scanning should be removed from the regulation. Therefore, the Commission is revising proposed Sec. 39.18(e)(2)(ii) as follows (added text in italics), ``Such vulnerability testing shall include automated vulnerability scanning, which shall follow generally accepted best practices.'' The regulation as adopted thus only requires authenticated scanning to the extent it is required by industry standards. 4. Independence Requirements Several DCOs did not support the independent contractor requirement, arguing that internal teams should be allowed to conduct vulnerability testing. ICE noted that internal parties have the most knowledge and experience with the systems. CME, ICE, and MGEX argued that there are inherent risks in providing outside parties access to critical systems and sensitive information. Specifically, MGEX stated that it is concerned about the breadth and volume of proprietary information that vendors would have access to in order to perform the testing required, because having vast quantities of industry information in the hands of vendors may actually cause greater risk of harm as vendors may be at greater risk of a cyber incident. ICE, LCH.Clearnet Group (``LCH''), The Options Clearing Corporation (``OCC''), and MGEX all noted significant costs associated with hiring outside contractors to conduct vulnerability tests. LCH and MGEX further stated that this requirement is especially burdensome to smaller DCOs. MGEX opposed the proposed requirement that only independent contractors or employees who are not responsible for development or operation of the systems or capabilities being tested may conduct vulnerability testing. Specifically, MGEX stated that smaller organizations like itself may not have qualified individuals outside of the IT department who would have the [[Page 64324]] needed background and skills while also having the level of independence which the Commission would require. Therefore, an entity like MGEX would be forced to either bear significant cost to hire dedicated employees exclusively for regulatory testing compliance or bear significant cost to have independent contractors perform all four tests. OCC believes that requiring a DCO to use an independent contractor to perform vulnerability testing during the same year that such person is performing external penetration testing would unnecessarily increase costs without an added benefit, because vulnerability testing is largely subsumed within external penetration testing. As explained in the Proposal, the Commission believes it is important that vulnerability testing be conducted from the perspective of an outsider, and as a result does not agree with MGEX that internal employees responsible for development or operation of the tested systems or capabilities should be permitted to conduct the tests. The Commission agrees with various commenters, however, that the regulation should permit but not require a DCO to use independent contractors to conduct the required vulnerability testing. As a result, the Commission is revising proposed Sec. 39.18(e)(2)(iii) as follows (added text in italics), ``A derivatives clearing organization shall conduct vulnerability testing by engaging independent contractors, or by using employees of the derivatives clearing organization who are not responsible for development or operation of the systems or capabilities being tested.'' This revision aligns the regulation more closely with industry standards, which call for vulnerability testing to be conducted by independent employees while recognizing the benefits and potential risks of engaging independent contractors.\15\ --------------------------------------------------------------------------- \15\ FFIEC Handbook, supra note 13, at 81 (calling for such tests to be performed ``by individuals who are also independent of the design, installation, maintenance, and operation of the tested system''); NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, Sept. 2008 (``NIST SP 800-115''), p. 6-6, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf (recognizing the benefits and risks of engaging third parties to conduct testing). --------------------------------------------------------------------------- B. External Penetration Testing Proposed Sec. 39.18(a) would define ``external penetration testing'' as ``attempts to penetrate a [DCO's] automated systems from outside the systems' boundaries to identify and exploit vulnerabilities,'' and proposed Sec. 39.18(e)(3) would require the testing to be of a scope sufficient to satisfy the testing scope requirements of proposed Sec. 39.18(e)(8). Proposed Sec. 39.18(e)(3)(i) would require a DCO to conduct external penetration testing at a frequency determined by an appropriate risk analysis, but at a minimum no less frequently than annually. The proposed rule would also provide that independent contractors must perform the required annual external penetration test on behalf of the DCO. However, other external penetration testing could be performed by appropriately qualified DCO employees not responsible for development or operation of the systems or capabilities being tested. ICE and Nadex supported requiring external penetration testing as a part of a DCO's program of risk analysis and oversight. OCC generally supported external penetration testing by independent third parties. ICE and CME supported performing the testing annually. ICE suggested that the Commission should amend the definition of ``external penetration testing'' to include specific types of testing. The Commission is declining to do so. Requiring specific tests would be overly prescriptive and could stifle the development of new, more advanced testing methods. Accordingly, upon review of the comments, the Commission is adopting Sec. 39.18(e)(3) and the definition of ``external penetration testing'' as proposed. C. Internal Penetration Testing Proposed Sec. 39.18(a) would define ``internal penetration testing'' as ``attempts to penetrate a [DCO's] automated systems from inside the systems' boundaries to identify and exploit vulnerabilities.'' Proposed Sec. 39.18(e)(4) would require the testing to be of a scope sufficient to satisfy the testing scope requirements of proposed Sec. 39.18(e)(8). Proposed Sec. 39.18(e)(4)(i) would require a DCO to conduct internal penetration testing at a frequency determined by an appropriate risk analysis, but no less frequently than annually. The test could be conducted by independent contractors, or by appropriately qualified DCO employees not responsible for development or operation of the systems or capabilities being tested. ICE and Nadex supported requiring internal penetration testing as a part of a DCO's program of risk analysis and oversight. ICE suggested that the Commission should amend the definition of ``internal penetration testing'' to include specific types of testing. As with external penetration testing, the Commission is declining to require specific forms of internal penetration tests. Requiring specific tests would be overly prescriptive and could stifle the development of new, more advanced testing methods. CME stated that DCOs may find it challenging to recruit and retain employees capable of conducting internal penetration testing without introducing unnecessary risks into production and other sensitive environments, because there is a scarcity of qualified professionals with those skills. As a result, CME argued the Commission should clarify that conducting annual internal penetration tests should be an objective, and not a strict requirement, so that DCOs can prioritize effective testing done by independent employees over conducting testing at least annually simply to comply with a prescriptive testing frequency requirement. ICE stated that the Commission should be silent on parameters for voluntary internal testing, allowing each DCO to determine its own methodology for such testing. The Commission disagrees with CME's suggestion that internal penetration testing should be merely an objective. The requirement for internal penetration testing is based on industry standards.\16\ In addition, because the regulation provides sufficient flexibility regarding the individuals who are permitted to conduct the internal penetration tests, the Commission does not believe a change to the regulation based on CME's comment is necessary. In response to ICE's comment regarding voluntary internal testing, the Commission notes that the final rule does not impose any requirements on testing DCOs conduct on a voluntary basis, beyond the requirements of the regulation. Therefore, the Commission declines to make any changes in response to these comments and confirms that final Sec. 39.18(e)(4) sets forth requirements rather than objectives or a voluntary program. --------------------------------------------------------------------------- \16\ See NIST SP 800-115, supra note 15, at 2-5. --------------------------------------------------------------------------- MGEX stated that the required frequency of testing should be determined by the frequency of systems changes and the scope of exposure, and should not be reduced to a static minimum. The Commission declines to amend the regulation in response to MGEX's comment, and notes that that the frequency requirement in final Sec. 39.18(e)(4)(i) is based on industry standards and is not overly prescriptive.\17\ --------------------------------------------------------------------------- \17\ See id.; FFIEC Handbook, supra note 13, at 82. --------------------------------------------------------------------------- Accordingly, upon review of the comments, the Commission is adopting Sec. 39.18(e)(4) and the definition of [[Page 64325]] ``internal penetration testing'' as proposed. D. Controls Testing Proposed Sec. 39.18(a) would define ``controls testing'' as an assessment of the DCO's controls to determine whether such controls are implemented correctly, are operating as intended, and are enabling the DCO to meet the requirements of Sec. 39.18. Proposed Sec. 39.18(e)(5) would require such testing to be of a scope sufficient to satisfy the testing scope requirements of proposed Sec. 39.18(e)(8). Proposed Sec. 39.18(e)(5)(i) would require a DCO to conduct controls testing, which includes testing of each control included in its program of risk analysis and oversight, at a frequency determined by an appropriate risk analysis, but no less frequently than every two years. Pursuant to proposed Sec. 39.18(e)(5)(ii), a DCO would be required to engage independent contractors to test and assess its ``key controls,'' which would be defined in proposed Sec. 39.18(a) as controls that an appropriate risk analysis determines are either critically important for effective system safeguards or intended to address risks that evolve or change more frequently and therefore require more frequent review to ensure their continuing effectiveness in addressing such risks. A DCO may conduct any other non-key controls testing by using independent contractors or employees of the DCO who are not responsible for development or operation of the systems or capabilities being tested. CME and Nadex supported requiring controls testing as a part of a DCO's program of risk analysis and oversight. ICE recommended that the Commission remove the controls testing requirements and the definition of ``key controls.'' ICE stated that attempting to mandate controls testing will result in inconsistent and confused implementation, distract from useful security activity, and generate a superset of results that are already published in a more focused fashion through vulnerability, external penetration, internal penetration, or security response plan testing. Moreover, ICE believes that the proposed controls testing requirements are already adequately addressed in existing rules, both in the U.S. and globally, and through current examination coverage. ICE added that the concept of a key control is not universally adopted, and that the goal is not to test such controls, but to eliminate reliance on them. ICE believes that the key controls proposal imposes a large burden for little to no practical improvement in security. Despite ICE's comments, the Commission is adopting the controls testing requirement, which is based on industry standards.\18\ The Commission continues to believe that regular, ongoing testing of all of an organization's system safeguards-related controls is a crucial part of a DCO's risk analysis and oversight program. As NIST notes, the results of such testing can allow organizations to, among other things, identify potential cybersecurity problems or shortfalls, identify security-related weaknesses and deficiencies, prioritize risk mitigation decisions and activities, confirm that weaknesses and deficiencies have been addressed, and inform related budgetary decisions and capital investment.\19\ The Commission notes that the definition of ``key controls'' provides adequate flexibility for a DCO to determine which of its controls constitute key controls. While ICE believes that the goal should be to eliminate reliance on key controls, the Commission believes that so long as DCOs continue to rely on them, it is crucial for DCOs to test their effectiveness. --------------------------------------------------------------------------- \18\ See, NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, rev. 4 (``NIST SP 800-53''), pp. app. F-CA at F-55, available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.; FFIEC Handbook, supra note 13, at 12. \19\ NIST Special Publication 800-53A, Assessing Security and Privacy Controls in Federal Information Systems and Organizations, rev. 4 (``NIST SP 800-53A''), p. 3, available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf. --------------------------------------------------------------------------- 1. Frequency CME and OCC stated that the costs of requiring controls testing every two years outweigh the benefits. CME stated that DCOs should be able to test in line with their risk analysis, which may result in a cycle of longer than two years. CME stated that a three-year cycle requirement would be more appropriate. OCC agreed with the proposed testing frequency as applied to key controls. However, OCC stated that, consistent with relevant industry best practices, the Commission should alternatively consider permitting a DCO to determine the frequency of controls testing based on the level of risk a control is determined to present following an appropriate controls risk analysis. The Commission agrees with CME and OCC that requiring controls testing no less frequently than every two years is not necessary. The Commission further agrees with CME that three years is a more appropriate minimum requirement and is revising proposed Sec. 39.18(e)(5)(i) as follows (added text in italics), ``A [DCO] shall conduct controls testing, which includes testing of each control included in its program of risk analysis and oversight, at a frequency determined by an appropriate risk analysis, but shall test and assess key controls no less frequently than every three years. A [DCO] may conduct such testing on a rolling basis over the course of the required period.'' The final rule would thus require key controls testing to occur at least every three years rather than every two and would not prescribe a minimum frequency for testing of non-key controls. The Commission reiterates, however, that if a DCO's risk analysis indicates a key control should be tested more frequently than every three years, the DCO must comply with the shorter testing frequency. The changes would further clarify that both key controls and non-key controls can be tested on a rolling basis over the applicable time period. 2. Independence Requirements CME stated that requiring non-employee independent contractors to test key controls, without involvement by employees, may not provide the most effective or efficient means for continued key controls testing and enhancement. CME also stated that internal audit staff can provide a strong and independent third line of defense where the department is independent from management, objective in its findings, professional, and able to have free and unlimited access to the books, records, and people of a company. CME further stated that while involving external resources may be beneficial, doing so should not exclude participation by employees not involved in the development or operation of the controls, systems, or capabilities being tested. OCC recommended that DCOs be permitted to use independent contractors or independent employees to test and assess the effectiveness of key controls because, in contrast to penetration testing, key controls testing does not require specialized expertise. Moreover, OCC believes independent employees are more knowledgeable about the DCO's business, risk profile, and control environment generally, making them better positioned to perform effective testing of key controls. OCC suggests that, at a minimum, the Commission should make clear that whenever an independent contractor is used to perform testing, the independent contractor is not required to work in isolation but rather alongside independent employees of the DCO. The Commission believes that independent testing provides critical [[Page 64326]] impartiality and credibility, and notes that generally accepted best practices recognize the benefits of using independent contractors.\20\ The Commission is clarifying, however, that when a DCO must engage independent contractors to conduct key controls testing, those independent contractors may consult with independent employees of the DCO when conducting the required testing so long as they produce an independent report. --------------------------------------------------------------------------- \20\ NIST SP 800-115, supra note 15, at 6-6 (NIST also notes that giving outsiders access to an organization's systems can introduce additional risk, and recommends proper vetting and attention to contractual responsibility in this regard); FFIEC Handbook, supra note 13, at 81. --------------------------------------------------------------------------- Based on the changes to proposed Sec. 39.18(e)(5)(i), the Commission is revising proposed Sec. 39.18(e)(5)(ii) in part as follows (added text in italics), ``A [DCO] shall engage independent contractors to test and assess the key controls included in the [DCO]'s program of risk analysis and oversight no less frequently than every three years.'' The regulation as finalized would thus require a DCO to engage independent contractors to test each key control at least every three years. If, however, a DCO's risk analysis concludes that certain key controls must be tested more frequently than every three years, the resulting additional tests may be conducted by independent contractors or employees of the DCO who are not responsible for development or operation of the systems or capabilities being tested. E. Security Incident Response Plan Testing Proposed Sec. 39.18(a) would define ``security incident response plan testing'' as testing of a DCO's security incident response plan to determine the plan's effectiveness, identifying its potential weaknesses or deficiencies, enabling regular plan updating and improvement, and maintaining organizational preparedness and resiliency with respect to security incidents. Methods of conducting security incident response plan testing would include, but not be limited to, checklist completion, walk-through or table-top exercises, simulations, and comprehensive exercises. Proposed Sec. 39.18(e)(6)(i) would require a DCO to conduct the testing at a frequency determined by an appropriate risk analysis, but at a minimum no less frequently than annually. Proposed Sec. 39.18(e)(6)(ii) would require the DCO's security incident response plan to include, without limitation, the DCO's definition and classification of security incidents, its policies and procedures for reporting security incidents and for internal and external communication and information sharing regarding security incidents, and the hand-off and escalation points in its security incident response process. Proposed Sec. 39.18(e)(6)(iii) would also permit the DCO to coordinate its security incident response plan testing with other testing required by the regulation or with testing of its other business continuity- disaster recovery and crisis management plans. Moreover, proposed Sec. 39.18(e)(6)(iv) would permit the DCO to conduct security incident response plan testing by engaging independent contractors or by using employees who are not responsible for development or operation of the systems or capabilities being tested. CME, ICE, and Nadex supported requiring security incident response plan testing as a part of a DCO's program of risk analysis and oversight. CME stated that employees responsible for incident response, who would not be responsible for the development or operation of the functional systems or capabilities being tested, should be permitted to both design a DCO's plan and be responsible for testing the plan. CME stated that a DCO should be able to leverage its employees with expertise in crisis and risk management, and incident response and planning, for both planning and testing purposes. The Commission agrees with CME that the employees who develop a security incident response plan should be permitted to test the plan. To allow DCOs additional flexibility regarding security incident response plan testing, the Commission is revising proposed Sec. 39.18(e)(6)(iv) by deleting ``who are not responsible for development or operation of the systems or capabilities being tested.'' This revision allows security incident response plan testing to be conducted by either independent contractors or employees, without restricting which employees may lead or conduct the testing. OCC noted that under the proposed rules, ``security incident'' is defined as ``a cybersecurity or physical security event that actually or potentially jeopardizes automated system operation, reliability, security, or capacity, or the availability, confidentiality or integrity of data.'' OCC argued that the inclusion of the term ``potentially'' renders the definition vague, and could be interpreted to include most, if not all, cybersecurity events experienced by a DCO. OCC suggested that the Commission revise its definition to either: (i) Defer to the DCO's definition as set forth in its risk analysis plan; or (ii) replace ``potentially jeopardizes'' with ``has a significant likelihood of jeopardizing.'' The Commission recognizes OCC's concern and is amending the proposed definition of ``security incident'' as follows (added text in italics), ``Security incident means a cybersecurity or physical security event that actually jeopardizes or has a significant likelihood of jeopardizing automated system operation, reliability, security, or capacity, or the availability, confidentiality or integrity of data.'' This change provides additional clarity regarding which cybersecurity events are considered a security incident for the purposes of the regulation. F. Enterprise Technology Risk Assessment Proposed Sec. 39.18(a) would define an ``enterprise technology risk assessment'' as a written assessment that includes, but is not limited to, an analysis of threats and vulnerabilities in the context of mitigating controls. Proposed Sec. 39.18(a) would also provide that an enterprise technology risk assessment identifies, estimates, and prioritizes risks to a DCO's operations or assets, or to market participants, individuals, or other entities, resulting from impairment of the confidentiality, integrity, or availability of data and information or the reliability, security, or capacity of automated systems. Proposed Sec. 39.18(e)(7) would require such assessment to be of a scope sufficient to satisfy the requirements of proposed Sec. 39.18(e)(8). Proposed Sec. 39.18(e)(7)(i) would require DCOs to conduct an enterprise technology risk assessment at a frequency determined by an appropriate risk analysis, but no less frequently than annually. Proposed Sec. 39.18(e)(7)(ii) would permit a DCO to use independent contractors or employees of the DCO not responsible for development or operation of the systems or capabilities being assessed to conduct an enterprise technology risk assessment. Nadex requested that the Commission clarify whether information related to the enterprise technology risk assessment could be combined with the regular testing results presented to management and the board of directors based on the internal reporting and review requirements. In response to Nadex's comment, the Commission is clarifying that the information required under the regulation can be presented to management and the board of directors in the manner each DCO deems [[Page 64327]] appropriate, including by presenting it together with other information DCOs must provide to management and the board of directors. 1. Frequency ICE recommended that the Commission not adopt the enterprise technology risk assessment requirements. ICE stated that attempting to mandate enterprise technology risk assessments will result in inconsistent and confused implementation, distract from useful security activity, and generate a superset of results that are already published in a more focused fashion through vulnerability, external penetration, internal penetration or security response plan testing. Moreover, ICE believes that the proposed enterprise technology risk assessment requirements are already adequately addressed in existing rules, both in the U.S. and globally, and through current examination coverage. CME supported requiring DCOs to conduct an enterprise technology risk assessment as a part of a DCO's program of risk analysis and oversight, but believes an assessment should be required at least every two years, rather than annually, to match the controls testing cycle. The Commission is adopting the enterprise technology risk assessment requirements generally as proposed. The regulation is based on industry standards \21\ and will help each DCO produce a broad determination of its system safeguards-related risks, regardless of the source of the risks. --------------------------------------------------------------------------- \21\ See PCI-DSS, supra note 13, at 105; FINRA Report, supra note 10, at 14. --------------------------------------------------------------------------- The Commission is, however, revising proposed Sec. 39.18(e)(7)(i) to read as follows (added text in italics), ``A [DCO] shall conduct an enterprise technology risk assessment at a frequency determined by an appropriate risk analysis, but no less frequently than annually. A [DCO] that has conducted an enterprise technology risk assessment that complies with this section may conduct subsequent assessments by updating the previous assessment.'' This change responds to a comment received by the Commission on its system safeguards proposal for DCMs and SDRs \22\ and clarifies that the required enterprise technology risk assessment may build upon previous assessments. The comment noted the burden and cost of an annual full assessment, and the Commission believes this is a reasonable means to reduce both. --------------------------------------------------------------------------- \22\ Tradeweb Markets, LLC, Comment Letter on System Safeguards Testing Requirements Proposed Rule (Feb. 22, 2016), http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60657&SearchText. --------------------------------------------------------------------------- 2. Independence Requirements CME suggested that the Commission permit DCOs to allow internal groups outside of the enterprise risk management function to handle components of the enterprise technology risk assessment. ICE stated that the enterprise technology risk assessment should be the function of an enterprise risk program separate from the information security groups. In response to the comments, the Commission emphasizes that the final regulation provides flexibility regarding who may conduct the enterprise technology risk assessment. If a DCO chooses not to use independent contractors, the enterprise technology risk assessment may be conducted by employees who are not responsible for the development or operation of the systems or capabilities being assessed. G. Scope of Testing Proposed Sec. 39.18(e)(8) would provide that the scope of all system safeguards testing and assessment required by Sec. 39.18 must be broad enough to include all testing of automated systems, networks, and controls necessary to identify any vulnerability which, if exploited or accidentally triggered, could enable an intruder or unauthorized user or insider to: (1) Interfere with the entity's operations or with fulfillment of the entity's statutory and regulatory responsibilities; (2) impair or degrade the reliability, security, or adequate scalable capacity of the entity's automated systems; (3) add to, delete, modify, exfiltrate, or compromise the integrity of any data related to the entity's regulated activities; or (4) undertake any other unauthorized action affecting the entity's regulated activities or the hardware or software used in connection with those activities. CME and Nadex stated that the requirement to identify ``any vulnerability'' that could compromise ``any data,'' or allow an intruder to undertake ``any other unauthorized action'' is too broad. CME argued that in being so broad, the Commission undermines the value of a risk-based approach. Nadex suggested that the proposed requirement be amended to limit responsibility to a reasonableness standard. The Commission agrees that the proposed language is overly broad and undermines a risk-based approach to system safeguards testing. Therefore, the Commission is revising proposed Sec. 39.18(e)(8) as follows (added text in italics), ``The scope of testing and assessment required by this section shall be broad enough to include the testing of automated systems and controls that a [DCO]'s required program of risk analysis and oversight and its current cybersecurity threat analysis indicate is necessary to identify risks and vulnerabilities that could enable an intruder or unauthorized user or insider. . . .'' The revisions reinforce a risk-based approach to system safeguards testing by basing the scope of testing on the DCO's program of risk analysis and oversight and current cybersecurity threat assessment. Nadex noted that the ``current cybersecurity threat analysis'' the DCO would use to assess its possible adversaries' capabilities could be interpreted to include not only the DCO's internal risk assessment, but also warnings/notices generated from third party entities. Nadex requested that the Commission confirm that the ``current cybersecurity threat analysis'' refers only to the DCO's internal risk assessment. The Commission does not believe that a DCO preparing a cybersecurity threat assessment can appropriately ignore available external warnings or notices. Thus, contrary to Nadex's recommendation, the Commission is clarifying that a DCO is required to consider reasonably available external analyses when preparing a current cybersecurity threat assessment. CME stated that adopting regulations requiring DCOs to identify ``any vulnerability'' underlies an assumption that DCOs falling victim to the most sophisticated threats are singularly responsible for being attacked. Therefore, CME recommended that the Commission adopt safe harbors for DCOs who seek to comply with their core principle responsibilities in order to encourage DCOs to seek out partnerships and best serve the common goal of improving the industry's overall state of cyber resilience. In light of the revisions to proposed Sec. 39.18(e)(8) discussed above, the Commission declines to provide a ``safe harbor'' for DCOs ``who seek to comply with their core principle responsibilities.'' As the revisions make clear, the Commission is not seeking to hold DCOs strictly liable for every cyber attack they might face. H. Internal Reporting and Review Proposed Sec. 39.18(e)(9) would provide that both the senior management and the board of directors of the DCO must receive and review reports setting forth the results of the testing and assessment [[Page 64328]] required by Sec. 39.18. Moreover, the DCO would be required to establish and follow appropriate procedures for the remediation of issues identified through this review, as provided in proposed Sec. 39.18(e)(10), and for evaluation of the effectiveness of testing and assessment protocols. Nadex stated that reports generated based on system testing are often lengthy and technical, and that requiring management and the board to review technical testing results would require individuals in those positions to have a level of technical knowledge and sophistication that may not otherwise be required of the position. Therefore, Nadex requested that the Commission clarify whether a narrative executive summary would satisfy the proposed requirement. Additionally, Nadex requested that the Commission clarify whether the reports may be presented to the board at its regularly scheduled quarterly meetings. CME, MGEX, and OCC stated that a DCO's board of directors should be able to delegate the review required by proposed Sec. 39.18(e)(9) to a board-level committee. In response to Nadex, the Commission notes that providing a DCO's board with a narrative executive summary is not sufficient to satisfy the requirements of the regulation. Consistent with generally accepted best practices, the final regulation requires that the board must instead receive and review the technical reports containing testing results and assessments.\23\ To the extent there is concern regarding management's or the board of directors' ability to understand the required reports, the Commission notes that nothing in the regulation prevents a DCO from including additional, clarifying documents, such as executive summaries or compilations, with the required reports. The Commission believes that providing management or the board of directors with appropriate summaries or compilations can be an effective way to help a DCO fulfill the requirement in final Sec. 39.18(e)(9). The Commission is further clarifying that the board may receive the materials at a regularly scheduled board meeting and that the board may delegate the review required under final Sec. 39.18(e)(9) to an appropriate board-level committee. The Commission is adopting Sec. 39.18(e)(9) as proposed. --------------------------------------------------------------------------- \23\ FFIEC Handbook, supra note 13, at 5. --------------------------------------------------------------------------- I. Remediation Proposed Sec. 39.18(e)(10) would require a DCO to analyze the results of the testing and assessment required by Sec. 39.18 to identify all vulnerabilities and deficiencies in its systems. The proposed regulation would require a DCO to remediate those vulnerabilities and deficiencies to the extent necessary to enable it to fulfill its statutory and regulatory obligations. In addition, the remediation would have to be timely in light of appropriate risk analysis with respect to the risks presented by such vulnerabilities and deficiencies. Nadex stated that while it agrees with the proposed remediation requirements generally, the language requiring identification of ``all'' vulnerabilities and deficiencies would essentially impose strict liability on the firm for any breach of its security. In response to Nadex's comment, the Commission is revising proposed Sec. 39.18(e)(10) as follows, ``A [DCO] shall identify and document vulnerabilities and deficiencies in its systems revealed by the testing and assessment required by this section. The [DCO] shall conduct and document an appropriate analysis of the risks presented by each vulnerability or deficiency to determine and document whether to remediate the vulnerability or deficiency or accept the associated risk. When a [DCO] determines to remediate a vulnerability or deficiency, it must remediate in a timely manner given the nature and magnitude of the associated risk.'' The revisions require a DCO to determine whether to remediate or accept the risks presented by a vulnerability or deficiency based on an analysis of those risks, and to document that analysis. The changes acknowledge that in some instances, depending on the results of an appropriate risk analysis, a DCO may reasonably choose to accept a given risk. The changes also remove any suggestion that testing would necessarily identify every vulnerability, or that a DCO must remediate all vulnerabilities. The Commission believes that the terms ``remediate'' and ``accept'' provide the universe of appropriate responses to identified vulnerabilities and deficiencies. Industry standards outlining potential responses to cyber risks speak in terms of mitigating, accepting, avoiding, and sharing or transfer \24\ of risk.\25\ NIST describes risk mitigation as risk reduction, and the appropriate risk response for that portion of risk that cannot be accepted, avoided, shared, or transferred.\26\ The Commission believes that the term ``remediate'' as used in final Sec. 39.18(e)(10) captures mitigation. NIST describes risk avoidance as taking specific actions to eliminate the activities or technologies that are the basis for the risk or to revise or reposition these activities or technologies in the organizational mission/business processes to avoid the potential for unacceptable risk.\27\ The Commission believes these types of avoidance actions are also properly considered risk remediation. --------------------------------------------------------------------------- \24\ The Commission does not believe that risk sharing or transfer is an appropriate response to systems risks, and does not intend for it to constitute remediation under Sec. 39.18(e)(10) as finalized. NIST describes risk sharing or transfer as the appropriate risk response when organizations desire and have the means to shift risk liability and responsibility to other organizations. NIST SP 800-39, supra note 13, at 43. The Commission's regulatory approach in this area, however, requires that a DCO retain complete responsibility for its risk program. See 17 CFR 39.18(f)(2)(i) (to be re-codified as Sec. 39.18(d)(2)). Additionally, NIST cautions that risk transfer reduces neither the likelihood of harmful events occurring nor the consequences in terms of harm to organizational operations and assets, individuals, other organizations, or the nation. NIST SP 800-39, supra note 13, pp. 43. The Commission does not believe that a risk response that does not address the likelihood of a harmful event or its consequences is an appropriate response. \25\ See, e.g., NIST SP 800-39, supra note 13, at 41-43. \26\ Id. at 42-43. \27\ Id. at 42. --------------------------------------------------------------------------- Nadex also urged the Commission to establish safe harbor provisions offering protection where it is apparent the DCO has acted in good faith and maintains reasonable standards, consistent with at least the minimum requirements prescribed by the regulations, to prevent, monitor, detect, and address internal and external cyber threats. In light of the revisions to Sec. 39.18(e)(10), the Commission does not believe the addition of any safe harbor provision is necessary. The final regulation imposes specific system safeguards testing and remediation requirements, and does not seek to hold DCOs strictly liable for every cyber attack. J. Recovery Time Objective Proposed Sec. 39.18(a) would revise the definition of ``recovery time objective'' to make the language consistent with that used elsewhere in Sec. 39.18. OCC stated that it agrees with the 2-hour recovery time objective for physical events, but believes that a reasonableness standard is more appropriate for cybersecurity events. [[Page 64329]] OCC's comment relates to the recovery time objective period, which is addressed in Sec. 39.34, rather than the ``recovery time objective'' definition that is at issue here. The Commission will take the comment under advisement, but it is beyond the scope of this rulemaking. Accordingly, the Commission is adopting the definition of ``recovery time objective'' as proposed. K. Additional Comments The Commission received several general comments on the proposed rule. CME, ICE, LCH, MGEX, and Nadex generally expressed support for the Commission's rulemaking efforts. 1. Principles-Based Requirements ICE, MGEX, and OCC favored a principles-based approach, and argue that the Commission's approach is overly prescriptive. Specifically, OCC suggested that the Commission adopt a framework similar to SEC Regulation Systems Compliance and Integrity, which allows registrants to design their own compliance plans using industry standards that meet specified requirements that further the goals intended by the regulation. CME noted that it is important to allow entities, especially those operating within multiple jurisdictions, the flexibility to look to the best practices and standards that are most appropriate for addressing their unique risks, noting that best practices and generally accepted standards were not designed for the financial services industry. MGEX stated that the expanded definition of ``information security'' in proposed Sec. 39.18(b)(2) is overly prescriptive, and that this ``check-the-box'' list would not keep up with evolving markets, potentially giving the Commission a false sense of security. The Commission declines to alter its approach of basing this regulation on industry standards. This approach results in a regulation that is not overly prescriptive and will provide DCOs with flexibility to design systems and testing procedures based on the best practices that are most appropriate for that DCO's risks. 2. International Harmonization ICE, LCH, and OCC stated that it is important for the Commission to consider harmonizing its regulations with international standards for system safeguards testing. Specifically, OCC stated that it is concerned that systemically important clearing houses that are subject to multiple regulatory regimes will face compliance challenges, particularly during regulatory exams, if regulators fail to coordinate and align on a common set of guidelines or standards. As stated above, the Commission believes that this regulation's reliance on industry standards will provide DCOs, including those subject to multiple regulatory regimes, with flexibility to design systems and testing procedures based on the best practices that are most appropriate for that DCO's risks. Additionally, the Commission notes that the rule is consistent with the Guidance on Cyber Resilience for Financial Market Infrastructures published by the Committee on Payments and Market Infrastructures (``CPMI'') and the International Organization of Securities Commissions (``IOSCO'') (together, ``CPMI- IOSCO''). The report sets out internationally agreed upon guidelines designed to help financial market infrastructures, including central counterparties, enhance their cyber resilience.\28\ --------------------------------------------------------------------------- \28\ CPMI-IOSCO Guidance on Cyber Resilience for Financial Market Infrastructures, June 29, 2016, available at: https://www.iosco.org/library/pubdocs/pdf/IOSCOPD535.pdf. --------------------------------------------------------------------------- 3. DCO/DCM Harmonization MGEX noted that because it is registered with the Commission as both a DCO and a DCM, it cannot avail itself of the benefits of the 5% carve-out from the definition of ``covered designated contract market'' provided in the Commission's proposed regulation applicable to DCMs.\29\ MGEX recommended that a 5% threshold be added to the DCO rulemaking, and that the Commission provide adequate ramp-up and ramp- down periods for organizations moving above or below this threshold. --------------------------------------------------------------------------- \29\ System Safeguards Testing Requirements, 80 FR 80140 (Dec. 23, 2015) (to be codified at 17 CFR part 38). --------------------------------------------------------------------------- MGEX also stated that the Commission should more closely harmonize its DCO and DCM cybersecurity requirements. For example, with respect to business continuity and disaster recovery plans, DCMs are required to coordinate with members and other market participants upon whom the DCM depends to provide liquidity, while a DCO is required to coordinate with its clearing members. MGEX believes these requirements should be harmonized and provide for coordination with other entities deemed appropriate by an organization. MGEX is concerned that if clearing members or other participants are required to coordinate extensively with DCMs or DCOs there will be an incentive for them to work with fewer organizations. The Commission has worked to harmonize the regulations applicable to DCOs and DCMs, and as a result, the regulations track each other very closely. The Commission declines, however, to impose lighter regulation on those DCOs that are also DCMs, but are not covered DCMs. Unlike DCMs, DCOs hold member and customer funds, as well as records of member and customer positions, which would be at risk in the event of a cyber attack. Therefore the Commission believes that all DCOs must satisfy a uniform set of requirements with respect to system safeguards. With respect to the coordination requirement, DCMs and DCOs by their nature have different interested parties, and the need for a DCO to coordinate its business continuity and disaster recovery plan with its clearing members has not changed as a result of this rulemaking. 4. Independence Generally CME, ICE, and MGEX stated that internal audit groups should be permitted to continue in their current roles at those DCOs. CME noted that industry standards and best practices recognize that independence is determined not by employment, but impartiality. MGEX stated that the independence requirements present a competitive disadvantage for smaller entities that cannot afford full-time independent staff. The Commission believes that the regulation adequately addresses the use of independent employees in carrying out the requirements of the regulation, and declines to make any changes to specifically address the use of internal audit personnel. In addition, the Commission does not believe it is necessary to change the independence requirements for DCOs that do not want to pay for full-time independent staff to conduct various required activities, as those DCOs are free to engage outside consultants to conduct activities that do not warrant full-time hires. In the Proposal, the Commission requested comment on whether it should define the term ``independent contractor'' and if so, how it should define the term. LCH recommended that the Commission provide further guidance or a specific definition of ``independent contractor'' to maintain a consistent approach by all DCOs, but did not identify any specific lack of clarity that may result from use of the term absent a Commission definition. After consideration, the Commission is clarifying that as used in Sec. 39.18, the term independent contractor does not include employees of a DCO's parent or [[Page 64330]] affiliate company or co-sourced individuals.\30\ In light of this clarification, the Commission does not believe that a definition of ``independent contractor'' is necessary. --------------------------------------------------------------------------- \30\ Co-sourced individuals are non-employees who are integrated directly into a business's organizational structure to perform an ongoing function. The co-sourced individuals typically work in collaboration with the business's employees. --------------------------------------------------------------------------- 5. Books and Records ICE stated that the Commission should only require regulated entities, and not the entire firm of which the regulated entity is a part, to produce books and records relevant to a particular examination. According to ICE, overly burdensome production requirements will limit the regulated entities from having open and honest conversations related to risk. For example, risk is often discussed at a firm-wide level and not by a specific regulated entity. ICE contends that discussion regarding risks for non-CFTC regulated companies is not of interest to the Commission, and jeopardizes the confidentiality of those non-CFTC regulated companies. Further, ICE believes that CFTC requests for information from non-CFTC regulated companies would likely cause conflicts with other regulators and could violate foreign laws or regulations. The Commission believes that document production obligations during the course of an examination are beyond the scope of the rulemaking, but notes that Commission registrants are expected to produce required materials to the Commission regardless of whether that information resides at the registrant, at a related entity, or at an outside consultant. In many cases, a DCO shares system safeguard programs with other entities within the corporate structure. In these instances, the Commission will continue to require production of all books and records relating to the system safeguards of DCOs, 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 DCO. 6. Indemnification CME stated that removing language from the current version of Sec. 39.18 that expressly provides that a DCO is ``free to seek indemnification'' from outside service providers reduces certainty for the industry. CME added that because there is nothing within the regulation to prohibit the use of indemnification, as the Commission itself acknowledges, the Commission should not unnecessarily remove the certainty the current language provides. The Commission does not believe the ``free to seek indemnification'' language suggested by CME is necessary and is not changing the proposed regulation in this regard. Nothing in the final rule suggests that a DCO could not seek indemnification, and the Commission need not address the legal rights of DCOs with respect to third parties. 7. Systems Developments MGEX stated that the systems development requirements contained in proposed Sec. 39.18(b)(2)(v) should be required on an ``as needed'' or ``as reasonable'' basis. The Commission is declining to make changes to Sec. 39.18(b)(2)(v) based on MGEX's suggestion. Information regarding systems development and quality assurance is appropriately part of the DCO's program of risk analysis and oversight. If a DCO believes that it does not have any information to include on this topic in its program of risk analysis and oversight, it can document that position, and the basis for it, in the program. III. Dates LCH stated that in setting a compliance date, the Commission should consider the size and complexity of a DCO as well as the resources a DCO will need to procure in order to comply with the new regulations. The Commission has determined the following compliance dates on a provision-by-provision basis, determining appropriate compliance dates that it believes all DCOs, regardless of their size, complexity, or resources, should reasonably be able to meet. All of the regulations adopted herein will be effective upon publication in the Federal Register. Except as otherwise provided below, DCOs must comply with the requirements in Sec. 39.18 as of the effective date. Based on comments that discussed a DCO's need for time to develop appropriate policies and procedures to come into compliance, the Commission is extending the date by which DCOs must come into compliance for certain provisions as follows: DCOs must comply with the following provisions 180 days after the effective date: Vulnerability testing--Sec. 39.18(e)(2); and security incident response plan testing--Sec. 39.18(e)(6). DCOs must comply with the following provisions 1 year after the effective date: external penetration testing--Sec. 39.18(e)(3); internal penetration testing--Sec. 39.18(e)(4); controls testing-- Sec. 39.18(e)(5); and enterprise technology risk assessment--Sec. 39.18(e)(7). IV. Related Matters A. Regulatory Flexibility Act The Regulatory Flexibility Act (``RFA'') requires that agencies consider whether the regulations they propose will have a significant economic impact on a substantial number of small entities and, if so, provide a regulatory flexibility analysis respecting the impact.\31\ The final rule adopted by the Commission will impact DCOs. The Commission has previously established certain definitions of ``small entities'' to be used by the Commission in evaluating the impact of its regulations on small entities in accordance with the RFA.\32\ The Commission has previously determined that DCOs are not small entities for the purpose of the RFA.\33\ Accordingly, the Chairman, on behalf of the Commission, hereby certifies pursuant to 5 U.S.C. 605(b) that the rule adopted herein will not have a significant economic impact on a substantial number of small entities. The Chairman made the same certification in the proposed rulemaking, and the Commission did not receive any comments on the RFA. --------------------------------------------------------------------------- \31\ 5 U.S.C. 601 et seq. \32\ See 47 FR 18618, 18618-21 (Apr. 30, 1982). \33\ See New Regulatory Framework for Clearing Organizations, 66 FR 45604, 45609 (Aug. 29, 2001). --------------------------------------------------------------------------- B. Paperwork Reduction Act The Paperwork Reduction Act of 1995 (``PRA'') \34\ imposes certain requirements on Federal agencies, including the Commission, in connection with their conducting or sponsoring any collection of information, as defined by the PRA. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid control number. This rulemaking contains recordkeeping and reporting requirements that are collections of information within the meaning of the PRA. --------------------------------------------------------------------------- \34\ 44 U.S.C. 3501 et seq. --------------------------------------------------------------------------- The final rule contains provisions that would qualify as collections of information, for which the Commission has already sought and obtained a control number from the Office of Management and Budget (``OMB''). The title for this collection of information is ``Risk Management Requirements for Derivatives Clearing Organizations'' (OMB Control Number 3038-0076). Responses to this collection of information are mandatory. As discussed in the Proposal, the [[Page 64331]] Commission believes that the final rule does not impose any new recordkeeping or reporting requirements that are not already accounted for in collection 3038-0076.\35\ The Commission did not receive any comments on its assumptions regarding the recordkeeping or information collection requirements resulting from the rule as proposed. --------------------------------------------------------------------------- \35\ See Risk Management Requirements for Derivatives Clearing Organizations, OMB Control No. 3038-0076, available at: http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0076. --------------------------------------------------------------------------- The Commission notes that DCOs are already subject to system safeguard-related recordkeeping and reporting requirements. As discussed in the Proposal, the Commission is amending and renumbering current Sec. 39.18(i) as Sec. 39.18(f), to clarify the system safeguard recordkeeping and reporting requirements for DCOs. The regulation requires DCOs, in accordance with Sec. 1.31,\36\ to provide the Commission with the following documents promptly upon request of Commission staff: (1) Current copies of the DCO's business continuity and disaster recovery plan and other emergency procedures; (2) all assessments of the DCO's operational risks or system safeguard-related controls; (3) all required reports concerning system safeguards testing and assessment, whether conducted by independent contractors or employees of the DCO; and (4) all other documents requested by staff of the Division of Clearing and Risk, or any successor division, in connection with Commission oversight of system safeguards pursuant to the CEA or Commission regulations, or in connection with Commission maintenance of a current profile of the DCO's automated systems. The pertinent recordkeeping and reporting requirements of final Sec. 39.18(f) are contained in the provisions of current Sec. 39.18(i), which was adopted on November 8, 2011.\37\ Accordingly, the Commission believes that final Sec. 39.18(f) would not impact the burden estimates currently provided for in collection 3038-0076. --------------------------------------------------------------------------- \36\ Regulation 1.31(a)(1) specifically provides that all books and records required to be kept by the CEA or by these regulations shall be kept for a period of five years from the date thereof and shall be readily accessible during the first 2 years of the 5-year period. The rule further provides that all such books and records shall be open to inspection by any representative of the Commission or the United States Department of Justice. See 17 CFR 1.31(a)(1). \37\ 76 FR 69334, at 69428. --------------------------------------------------------------------------- C. Consideration of Costs and Benefits 1. Introduction Section 15(a) of the CEA requires the Commission to consider the costs and benefits of its actions before promulgating a regulation under the CEA or issuing certain orders.\38\ Section 15(a) further specifies that the costs and benefits shall be evaluated in light of five broad areas of market and public concern: (1) Protection of market participants and the public; (2) efficiency, competitiveness and financial integrity of futures markets; (3) price discovery; (4) sound risk management practices; and (5) other public interest considerations. The Commission's cost and benefit considerations in accordance with section 15(a) are discussed below. --------------------------------------------------------------------------- \38\ 7 U.S.C. 19(a). --------------------------------------------------------------------------- To further the Commission's consideration of the costs and benefits imposed by its regulation, the Commission invited comments from the public on the costs and benefits associated with the proposed regulation, and included a series of specific requests for comment related to the potential costs and benefits resulting from, or arising out of, requiring DCOs to comply with the proposed changes to Sec. 39.18.\39\ A number of commenters addressed the costs and benefits of the Proposal, which the Commission addresses in the discussion that follows. The Commission believes that the changes in the final regulation will reduce the costs of compliance as compared to the Proposal, which itself imposed only modest costs relative to those that already exist under current Sec. 39.18. --------------------------------------------------------------------------- \39\ 80 FR 80114, at 80133. --------------------------------------------------------------------------- 2. Background and Baseline for the Final Rule As an initial matter, the Commission considers the incremental costs and benefits of this regulation, meaning the costs and benefits that are above the current system safeguard practices and requirements under the CEA and the Commission's regulations for DCOs. Where reasonably feasible, the Commission has endeavored to estimate quantifiable costs and benefits. Where quantification is not feasible, the Commission identifies and describes costs and benefits qualitatively.\40\ --------------------------------------------------------------------------- \40\ For example, to quantify benefits such as enhanced protections for market participants and the public and financial integrity of the futures and swaps markets would require information, data, and/or metrics that either do not exist, or to which the Commission generally does not have access. --------------------------------------------------------------------------- As discussed in the Proposal, the Commission believes that cyber threats to the financial sector have expanded dramatically in recent years.\41\ The current cyber threat environment highlights the need to consider an updated regulatory framework with respect to cybersecurity testing for DCOs. Although the Commission acknowledges that the amendments would likely result in some additional costs for DCOs, the final rule would also bring several overarching benefits to the futures and swaps industry. As discussed more fully below, a comprehensive cybersecurity testing program is crucial to efforts by DCOs to strengthen cyber defenses, to mitigate operational, reputational, and financial risk, and to maintain cyber resilience and ability to recover from cyber attack. Significantly, to ensure the effectiveness of cybersecurity controls, a DCO must test in order to find and fix its vulnerabilities before an attacker exploits them. --------------------------------------------------------------------------- \41\ See 80 FR 80114, at 80114-80115. --------------------------------------------------------------------------- The Commission recognizes that any economic effects, including costs and benefits, should be compared to a baseline that accounts for current regulatory requirements. The baseline for this cost and benefit consideration is the set of requirements under the CEA and the Commission's regulations for DCOs. Currently, Sec. 39.18(j)(1)(i) requires a DCO to conduct regular, periodic, and objective testing and review of its automated systems to ensure that they are reliable, secure, and have adequate scalable capacity.\42\ This requirement, which forms part of the DCO risk analysis program required under Sec. 39.18(b), must be satisfied by following, at a minimum, ``generally accepted standards and industry best practices.'' \43\ Further, current Sec. 39.18(j)(2) requires that this testing be conducted by independent contractors or employees of the DCO not responsible for development or operation of the systems or capabilities being tested.\44\ --------------------------------------------------------------------------- \42\ 17 CFR 39.18(j). \43\ See 17 CFR 39.18(d). \44\ 17 CFR 39.18(j). --------------------------------------------------------------------------- In addition to referencing generally accepted standards and industry best practices, this cost and benefit discussion uses information provided by DCOs in connection with a survey of DCO system safeguard costs and practices conducted by Commission staff (``February 2015 DCR Survey'').\45\ [[Page 64332]] The Commission notes, however, that in certain instances the cost estimates provided by the DCOs included estimates at the parent company level of the DCO. Where parent-level estimates were provided, the DCOs explained that they generally share the same automated systems and system safeguard programs with other entities within the corporate structure and were therefore unable to apportion the actual costs to particular entities. The Commission further notes that some of the DCOs that supplied cost information are also registered with the Commission in other capacities (as DCMs and/or swap data repositories). These DCOs provided cost estimates that cover all of their Commission-regulated functions because they generally share the same automated systems and system safeguard programs. Therefore, the Commission has attempted to account for these distinctions, where appropriate. --------------------------------------------------------------------------- \45\ On February 19, 2015, the Division of Clearing and Risk requested, pursuant to Sec. 39.19(c)(5)(i), information from each registered DCO regarding the scope and costs of its current system safeguard testing. Of the 14 DCOs contacted, 13 responded. ICE Clear Credit, ICE Clear Europe, Ice Clear US, and the Clearing Corporation, each subsidiaries of Intercontinental Exchange, Inc., provided a single response, indicating that their testing costs are shared. LCH.Clearnet Ltd, LCH.Clearnet LLC, and LCH.Clearnet SA, each subsidiaries of LCH.Clearnet Group Ltd., also provided a single response, indicating that their testing costs are shared. --------------------------------------------------------------------------- In general, the final regulation clarifies existing system safeguards requirements under current Sec. 39.18 by identifying specific testing required by industry best practices. To the extent the final rule imposes new requirements and thus additional costs, the primary costs will result from more frequent testing, including some testing that must be carried out by independent contractors on behalf of the DCO. As a result, the final rule may increase operational costs for DCOs by requiring additional resources. In addition, the Commission notes that some DCOs are larger or more complex than others, and the requirements may impact DCOs differently depending on their size and the complexity of their systems. Thus, the Commission expects that the costs and benefits may vary somewhat among DCOs. The Commission is sensitive to the economic effects of the regulation, including costs and benefits. While certain costs are amenable to quantification, other costs cannot be reasonably estimated, such as the costs to the public or market participants in the event of a cybersecurity incident at a DCO. The Commission's final regulation is intended to further mitigate the frequency and severity of system security breaches or functional failures, and therefore, serve an important, if unquantifiable, public benefit. Although the benefits of effective regulation are difficult to value in dollar terms, the Commission believes that they are no less important to consider given the Commission's mission to protect market participants and the public and to promote market integrity. The discussion of costs and benefits that follows begins with a discussion of the comments received regarding the costs and benefits of the Proposal generally. Following the general discussion, the Commission provides a summary of changes to the proposed rule that resulted in the final rule, discusses the costs and benefits of the final rule, and where relevant, the costs of the final rule relative to the Proposal and addresses comments specific to the costs and benefits of each proposal. At the conclusion of this discussion, the Commission considers the costs and benefits of the final regulation collectively in light of the five factors set forth in section 15(a) of the CEA. 3. General Comments Received CME estimates that the proposed rule would cost CME Group approximately $7.2 million over a two-year period. CME noted that its cost estimate also includes the Commission's proposal applicable to DCMs and does not separately estimate costs for clearing, trading, or data reporting. As described more fully below, the Commission is adopting the final regulation with modifications in certain key areas, which should result in less cost and burden for DCOs relative to the Proposal. LCH recommended that the Commission consider the complexity created by multiple standards coming into effect in different major jurisdictions within the same timeframe. LCH stated that although international DCOs will achieve compliance against the highest minimum standards, the lead time for building testing programs and supportive compliance controls to meet many sets of new standards could be longer for larger and more complex DCOs than for smaller, regional DCO operations. The Commission agrees with LCH and, as discussed above in section III, has set individualized compliance dates for different aspects of the regulation. The Commission believes that all DCOs, regardless of their size, complexity, or resources, should generally be able to comply by the specified dates. MGEX stated that some entities may incur additional costs due to the divergence between the Commission's proposed rules for DCMs and DCOs, including the programs of risk analysis and oversight and coordination of the business continuity and disaster recovery plan with industry participants. The Commission notes that the rules for DCMs and DCOs are largely harmonized, and that differences in the programs of risk analysis and oversight for DCOs and DCMs are largely attributable to the different risks faced by the two types of entities. The new rules applicable to DCMs require that the program of risk analysis and oversight include enterprise risk management and governance applicable specifically to security and technology, but as noted in the Proposal, any parallel requirements for DCOs must be addressed in a more comprehensive fashion involving more than the system safeguards context alone, and thus are not appropriate for this rulemaking.\46\ Additionally, the requirement for a DCO to coordinate its business continuity and disaster recovery plan with clearing members is not a new requirement, and has not been amended by this rulemaking. That requirement has only been renumbered, and any compliance costs are not properly attributed to this rulemaking. --------------------------------------------------------------------------- \46\ 80 FR 80114, at 80123 n. 127. --------------------------------------------------------------------------- LCH and MGEX stated that the Commission should consider the size and complexity of the DCO in calculating the cost of the proposed requirements. Specifically, MGEX noted that $8,383,222, a figure drawn from the notice of proposed rulemaking for the system safeguards rules applicable to DCMs, is ``excessively punitive'' for smaller entities. It further stated that organizations like MGEX cannot bear these costs, and that the Commission should not require them to comply because they present lower overall risk to the industry, and have dramatically smaller exposure to vulnerabilities compared to SIDCOs. The Commission notes that the figure cited by MGEX is not an estimate of new costs arising from this rulemaking. It was instead an average calculated from preliminary information collected from some DCMs and SDRs regarding their current costs associated with conducting vulnerability testing, external and internal penetration testing, controls testing, and enterprise technology risk assessments. The Commission nevertheless acknowledges that this rulemaking will impose new costs on DCOs beyond the current cost of compliance, and recognizes that the actual costs may vary widely as a result of numerous factors including the size of the organization, the complexity of the automated systems, and the scope of the test. The Commission has attempted to limit costs for smaller DCOs by providing the flexibility to design systems and testing procedures that are [[Page 64333]] appropriate for each DCO's individual risks. CME and LCH noted that the shortage of skilled professionals could increase costs directly and indirectly as a result of the proposed rule. The Commission notes that where appropriate, the final rule provides additional flexibility regarding the ability of DCOs to choose whether to use internal or external personnel to conduct certain tests. MGEX noted that implementation on the scale required by this rulemaking will include significant personnel and non-personnel resources. These additional costs include IT and operations personnel costs, purchase of software and hardware, legal and compliance costs, and the cost of third-party testing vendors. MGEX anticipated that its costs will go up two or three times if the rulemakings are made final in their proposed form, explaining that the highest cost of compliance would result from hiring of independent contractors/professionals. As discussed more fully below and in the Proposal, the Commission acknowledges that there will be some increases in the costs described by MGEX. In the final rule, the Commission, where appropriate, has provided DCOs with additional flexibility regarding who may conduct certain tests. The Commission notes, however, that many of the costs described by MGEX are attributable to compliance with the current rule and not to additional requirements imposed by this rulemaking. For example, the requirement to conduct testing with independent contractors or independent employees already exists under current Sec. 39.18(j)(2). Further, based on industry standards, current Sec. 39.18 requires DCOs to conduct external penetration testing using an independent contractor. 4. Consideration of Costs and Benefits Related to the Final Rule This section discusses cost and benefit considerations related to the final rule, including those aspects of the regulation that have changed since the proposed rule, and those aspects of the regulation on which the Commission received comments. a. Regulation 39.18(e)(2)--Vulnerability Testing i. Summary of Final Regulation As discussed above in section II(A), the Commission is revising proposed Sec. 39.18(e)(2)(ii) to remove the explicit requirement for authenticated scanning where indicated by appropriate risk analysis. The final rule requires that a DCO conduct automated vulnerability scanning, which complies with generally accepted best practices. The Commission is also revising Sec. 39.18(e)(2)(iii) to remove the proposed requirement that two of the required quarterly vulnerability tests be conducted by independent contractors. Under the final rule, all four required tests may be conducted by independent contractors or employees of the DCO who are not responsible for development or operation of the systems or capabilities being tested. The Commission is otherwise finalizing Sec. 39.18(e)(2) and the definition of ``vulnerability testing'' as proposed, and the Commission's consideration of the costs and benefits associated with those sections does not differ from those discussed in the Proposal. ii. Costs NGX commented that compliance with the proposed rule would not be inordinately costly relative to the benefits, with the exception of the requirements in Sec. 39.18(e)(2)(i) to conduct vulnerability testing on a quarterly basis. NGX estimates that testing quarterly would cost over $100,000 more per year than testing annually, and stated that the costs were not warranted because little changes from quarter to quarter. The Commission notes that industry best practices state that vulnerability testing should be conducted ``at least quarterly.'' \47\ Accordingly, current Sec. 39.18 requires DCOs to conduct vulnerability testing on a quarterly basis. Therefore, the Commission does not believe that the frequency requirement of Sec. 39.18(e)(2)(i) will impose new costs on DCOs. --------------------------------------------------------------------------- \47\ See FFIEC Handbook supra note 13 at 82. --------------------------------------------------------------------------- The Commission has determined not to adopt the proposed requirement for authenticated scanning where indicated by appropriate risk analysis in the final Sec. 39.18(e)(2)(ii). The rule as adopted will require automated vulnerability scanning to comply with best practices. Because current Sec. 39.18 requires DCOs to comply with industry best practices, the Commission does not believe that DCOs will incur additional costs as a result of the adoption of Sec. 39.18(e)(2)(ii). ICE, LCH, OCC, and MGEX all noted significant costs associated with hiring outside contractors to conduct vulnerability tests. OCC believes that requiring a DCO to use an independent contractor to perform vulnerability testing during the same year that such person is performing external penetration testing would unnecessarily increase costs without an added benefit, because vulnerability testing is largely subsumed within external penetration testing. As discussed above, the Commission has determined not to adopt the proposed independent contractor requirement in final Sec. 39.18(e)(2)(iii). Under the final rule, all required testing may be done by an independent contractor or by independent employees. The final rule is thus consistent with current Sec. 39.18(j)(2), which requires systems safeguards testing to be conducted by independent contractors or independent employees of the DCO. Because final Sec. 39.18(e)(2)(iii) does not change the current requirement, it will not impose additional costs on DCOs. iii. Benefits The Commission did not receive any comments specific to the benefits of vulnerability testing and believes the benefits of final Sec. 39.18(e)(2) do not differ from those discussed in the Proposal. b. Regulation 39.18(e)(3)--External Penetration Testing As discussed above in section II(B), the Commission is adopting Sec. 39.18(e)(3) and the definition of ``external penetration testing'' as proposed. The Commission did not receive any comments specific to the costs or benefits of external penetration testing. The Commission believes that the costs and benefits of Sec. 39.18(e)(3) do not differ from those discussed in the Proposal. c. Regulation 39.18(e)(4)--Internal Penetration Testing As discussed above in section II(C), the Commission is adopting Sec. 39.18(e)(4) and the definition of ``internal penetration testing'' as proposed. The Commission did not receive any comments specific to the costs or benefits of internal penetration testing. The Commission believes that the costs and benefits of Sec. 39.18(e)(4) do not differ from those discussed in the Proposal. d. Regulation 39.18(e)(5)--Controls Testing i. Summary of Final Regulation As discussed above in section II(D), the Commission is revising proposed Sec. 39.18(e)(5)(i) to remove a prescribed two-year minimum testing period for all controls testing, and instead require that (a) key controls be tested every three years; and (b) non-key controls be tested at a frequency determined by an appropriate risk analysis. The Commission is making a corresponding change to proposed Sec. 39.18(e)(5)(ii) to require that independent contractors test each key control at least every three [[Page 64334]] years rather than every two. The Commission is otherwise finalizing Sec. 39.18(e)(5) as well as the definitions of ``controls,'' ``controls testing,'' and ``key controls'' as proposed, and the Commission's consideration of the costs and benefits associated with those sections does not differ from those discussed in the Proposal. ii. Costs CME and OCC stated that the costs of requiring controls testing every two years outweigh the benefits. As discussed above, the Commission is adopting proposed Sec. 39.18(e)(5)(i) with modifications to require key controls testing to be conducted at a frequency determined by an appropriate risk analysis, but no less frequently than every three years. The Commission has determined not to adopt the proposed minimum frequency requirement for non-key controls. As discussed in the Proposal, the Commission acknowledges that the minimum frequency requirement for key controls testing may increase costs for DCOs. The Commission notes, however, that the February 2015 DCR Survey indicated that most DCOs currently conduct controls testing at least annually and some DCOs may not face an increase in costs based on this requirement. Further, because of the modifications from the Proposal, the testing frequency for some DCOs could be reduced, and therefore may be less costly relative to the Proposal. iii. Benefits The Commission did not receive any comments specific to the benefits of controls testing and believes the benefits of final Sec. 39.18(e)(5) do not differ from those discussed in the Proposal. e. Regulation 39.18(e)(6)--Security Incident Response Plan Testing i. Summary of Final Regulation As discussed above in section II(E), the Commission is amending the definition of ``security incident'' in proposed Sec. 39.18(a) in order to provide additional clarity. Further, the Commission is adopting proposed Sec. 39.18(e)(6)(iv) with modifications to remove the restrictions on which employees are permitted to conduct security incident response plan testing. The Commission is otherwise finalizing Sec. 39.18(e)(6) as well as the definitions of ``security incident response plan'' and ``security incident response plan testing'' as proposed, and the Commission's consideration of the costs and benefits associated with those sections does not differ from those discussed in the Proposal. ii. Costs The Commission does not believe that the changes to the definition of ``security incident'' will affect the costs of the rule. As explained in the Proposal, the Commission does not believe proposed Sec. 39.18(e)(6)(iv) will impose new costs on DCOs, because it is consistent with current Sec. 39.18(j)(2). Further, without the proposed restrictions regarding which employees may conduct security incident response plan testing, Sec. 39.18(e)(6)(iv) as finalized may lower costs for some DCOs by providing flexibility that does not exist in the current rule. The Commission did not receive any comments related to the costs of security incident response plan testing. iii. Benefits The Commission did not receive any comments specific to the benefits of security incident response plan testing and believes that the benefits of final Sec. 39.18(e)(6) do not differ from those discussed in the Proposal. f. Regulation 39.18(e)(7)--Enterprise Technology Risk Assessment In the Proposal, the Commission concluded that proposed Sec. 39.18(e)(7) is consistent with current industry standards \48\ and would not impose additional costs on DCOs. As discussed above in section II(F), the Commission is adopting Sec. 39.18(e)(7) and the definition of ``enterprise technology risk assessment'' as proposed, except for changes to Sec. 39.18(e)(7)(i) to clarify that a DCO that has conducted an enterprise technology risk assessment that complies with this section may conduct subsequent assessments by updating the previous assessment. This was intended as a clarification rather than a substantive change, and in any event will not impose any additional costs on DCOs. --------------------------------------------------------------------------- \48\ See, e.g., PCI-DSS, supra note 13, at 105. --------------------------------------------------------------------------- The Commission did not receive any comments specific to the costs or benefits of enterprise technology risk assessment testing. The Commission believes that the costs and benefits of final Sec. 39.18(e)(7) do not differ from those discussed in the Proposal. g. Regulation 39.18(e)(8)--Scope of Testing and Assessment i. Summary of Proposed Regulation As discussed above in section II(G), the Commission is revising proposed Sec. 39.18(e)(8) to state that that the scope of testing and assessment required by Sec. 39.18 shall be broad enough to include the testing of automated systems and controls that a DCO's required program of risk analysis and oversight and its current cybersecurity threat analysis indicate is necessary to identify risks and vulnerabilities that could enable an intruder or unauthorized user or insider to: (1) Interfere with the entity's operations or with fulfillment of the entity's statutory and regulatory responsibilities; (2) impair or degrade the reliability, security, or adequate scalable capacity of the entity's automated systems; (3) add to, delete, modify, exfiltrate, or compromise the integrity of any data related to the entity's regulated activities; and (4) undertake any other unauthorized action affecting the entity's regulated activities or the hardware or software used in connection with those activities. ii. Costs and Benefits In the Proposal, the Commission discussed the costs of proposed Sec. 39.18(e)(8) in relation to each substantive testing requirement. In each case, the Commission concluded that proposed Sec. 39.18(e)(8) would not impose new costs on DCOs. The Commission believes that the changes to proposed Sec. 39.18(e)(8) narrow the scope of testing in the final rule. Rather than requiring that DCOs test all automated systems and controls necessary to identify any of the enumerated risks and vulnerabilities, the scope of testing under the final rule is determined by a DCO's required program of risk analysis and oversight and its current cybersecurity threat analysis. Therefore, the Commission does not believe that final Sec. 39.18(e)(8) will impose new costs on DCOs compared to the proposed rule or the current rule. The Commission believes this risk-based approach will result in improved and more cost-effective testing. The Commission did not receive any comments specific to the costs or benefits of the scope of testing. h. Regulation 39.18(e)(9)--Internal Reporting and Review As discussed above in section II(H), the Commission is adopting Sec. 39.18(e)(9) as proposed. The Commission did not receive any comments specific to the costs or benefits of internal reporting and review. The Commission believes that the costs and benefits of final Sec. 39.18(e)(9) do not differ from those discussed in the Proposal. i. Regulation 39.18(e)(10)--Remediation i. Summary of Final Regulation As discussed above in section II(I), the Commission is revising proposed Sec. 39.18(e)(10) to require a DCO to [[Page 64335]] identify and document the vulnerabilities and deficiencies in its systems revealed by the testing and assessment required by the regulation and to conduct and document an appropriate analysis of the risks presented by such vulnerabilities and deficiencies to determine and document whether to remediate or accept each risk. ii. Costs The final rule makes clear that a DCO is only required to consider remediation of those vulnerabilities and deficiencies revealed through testing, rather than all vulnerabilities and deficiencies. Further, the final rule specifically allows DCOs to accept certain risks presented by vulnerabilities and deficiencies when that is appropriate based on an analysis of the risk presented. These changes to the Proposal will, if anything, result in lower costs to DCOs relative to the proposed rule. In any event, responding to vulnerabilities and deficiencies revealed by cybersecurity testing is an industry best practice,\49\ and DCOs are already required to comply with this requirement under current Sec. 39.18. --------------------------------------------------------------------------- \49\ See, e.g., NIST SP 800-39, supra note 13, at 41-43; FFIEC Handbook, supra note 13, at 5. --------------------------------------------------------------------------- The aspect of the final rule that could impose additional costs on DCOs relative to the current rule is the express requirement that DCOs document the vulnerabilities and deficiencies in its systems revealed by the required testing and assessment, document an appropriate analysis of the risks presented by such vulnerabilities, and document whether to remediate or accept each risk. DCOs would have been required under the proposed rule to analyze their testing results to determine the extent of their required remediation, so the difference in the final rule is the express documentation requirement. The express requirement that DCOs document their analysis imposes at most a slight additional cost on DCOs, particularly given that DCOs would likely have documented the required analysis even absent the express requirement. The Commission did not receive any comments specific to the costs of remediation. iii. Benefits The documentation requirement described above has the joint benefits of helping to ensure that DCOs carefully consider whether to remediate or accept risks, and of allowing the Commission to review the thought process behind these significant decisions. The Commission did not receive any comments specific to the benefits of remediation. 5. Section 15(a) Factors In addition to the discussion above, the Commission has evaluated the costs and benefits of Sec. 39.18 in light of the specific considerations identified in section 15(a) of the CEA as follows: a. Protection of Market Participants and the Public Automated systems are critical to a DCO's operations, which provide essential counterparty credit risk protection to market participants and the investing public. Final Sec. 39.18 is designed to further enhance DCOs' risk analysis programs in order to ensure that such automated systems are reliable, secure, and have an adequate scalable capacity. Accordingly, the Commission believes that the final rule will further help protect the derivatives markets by promoting more robust automated systems and therefore fewer disruptions and market-wide closures, systems compliance issues, and systems intrusions. Preventing disruptions helps to ensure that market participants will have continuous access to central clearing. Additionally, providing the Commission with reports concerning the system safeguards testing and assessments required by the final regulation will further facilitate the Commission's oversight of derivatives markets, augment the Commission's efforts to monitor systemic risk, and will further the protection of market participants and the public by helping to ensure that a DCO's automated systems are available, reliable, secure, have adequate scalable capacity, and are effectively overseen. The costs of this rulemaking would be mitigated by the countervailing benefits of improved design, more efficient and effective processes, and enhanced planning that would lead to increased safety and soundness of DCOs and the reduction of systemic risk, which protect market participants and the public from the adverse consequences that would result from a DCO's failure or a disruption in its functioning. b. Efficiency, Competitiveness and Financial Integrity The amendments to Sec. 39.18 will help preserve the efficiency and financial integrity of the derivatives markets by promoting comprehensive oversight and testing of a DCO's operations and automated systems. Specifically, the amendments will further reduce the probability of a cyber attack that could lead to a disruption in clearing services which could, in turn, cause disruptions to the efficient functioning and financial integrity of the derivatives markets. Preventing cyber attacks could prevent monetary losses to DCOs, and thereby help protect their financial integrity. The Commission does not anticipate the final rule to have a significant impact on the competitiveness of the derivatives markets. c. Price Discovery The Commission does not anticipate the amendments to Sec. 39.18 to have a direct effect on the price discovery process. However, ensuring that DCOs' automated systems function properly to clear trades protects the price discovery process to the extent that a prolonged disruption or suspension in clearing at a DCO may cause potential market participants to refrain from trading. d. Sound Risk Management Practices The amendments to Sec. 39.18 will strengthen and promote sound risk management practices across DCOs. Specifically, the amendments will build upon the current system safeguards requirements by ensuring that tests of DCOs' key system safeguards are conducted at minimum intervals and, where appropriate, by independent professionals. The applicable tests are each recognized by industry best practices as essential components of a sound risk management program. Moreover, the benefits of the final rule will be shared by market participants and the investing public as DCOs, by their nature, serve to provide such parties with counterparty credit risk protection. In addition, reliably functioning computer systems and networks are crucial to comprehensive risk management, and being able to request reports of the system safeguards testing required by the final regulation will assist the Commission in its oversight of DCOs and will bolster the Commission's ability to assess systemic risk levels. e. Other Public Interest Considerations The Commission notes the public interest in promoting and protecting public confidence in the safety and security of the financial markets. DCOs are essential to risk management in the financial markets, both systemically and on an individual firm level. Regulation 39.18, by explicating current requirements and identifying several additional key tests and assessments, promotes the ability of DCOs to perform these functions free from disruption due to both internal and external threats to its systems. [[Page 64336]] List of Subjects in 17 CFR Part 39 Commodity futures, Reporting and recordkeeping requirements, System safeguards. For the reasons stated in the preamble, the Commodity Futures Trading Commission amends 17 CFR part 39 as follows: PART 39--DERIVATIVES CLEARING ORGANIZATIONS 0 1. The authority citation for part 39 continues to read as follows: Authority: 7 U.S.C. 2, 7a-1, and 12a; 12 U.S.C. 5464; 15 U.S.C. 8325. 0 2. Revise Sec. 39.18 to read as follows: Sec. 39.18 System safeguards. (a) Definitions. For purposes of this section and Sec. 39.34: Controls mean the safeguards or countermeasures employed by the derivatives clearing organization in order to protect the reliability, security, or capacity of its automated systems or the confidentiality, integrity, or availability of its data and information, and in order to enable the derivatives clearing organization to fulfill its statutory and regulatory responsibilities. Controls testing means assessment of the derivatives clearing organization's controls to determine whether such controls are implemented correctly, are operating as intended, and are enabling the derivatives clearing organization to meet the requirements established by this section. Enterprise technology risk assessment means a written assessment that includes, but is not limited to, an analysis of threats and vulnerabilities in the context of mitigating controls. An enterprise technology risk assessment identifies, estimates, and prioritizes risks to a derivatives clearing organization's operations or assets, or to market participants, individuals, or other entities, resulting from impairment of the confidentiality, integrity, or availability of data and information or the reliability, security, or capacity of automated systems. External penetration testing means attempts to penetrate a derivatives clearing organization's automated systems from outside the systems' boundaries to identify and exploit vulnerabilities. Methods of conducting external penetration testing include, but are not limited to, methods for circumventing the security features of an automated system. Internal penetration testing means attempts to penetrate a derivatives clearing organization's automated systems from inside the systems' boundaries to identify and exploit vulnerabilities. Methods of conducting internal penetration testing include, but are not limited to, methods for circumventing the security features of an automated system. Key controls means those controls that an appropriate risk analysis determines are either critically important for effective system safeguards or intended to address risks that evolve or change more frequently and therefore require more frequent review to ensure their continuing effectiveness in addressing such risks. Recovery time objective means the time period within which a derivatives clearing organization should be able to achieve recovery and resumption of processing, clearing, and settlement of transactions, after those capabilities become temporarily inoperable for any reason up to or including a wide-scale disruption. Relevant area means the metropolitan or other geographic area within which a derivatives clearing organization has physical infrastructure or personnel necessary for it to conduct activities necessary to the processing, clearing, and settlement of transactions. The term ``relevant area'' also includes communities economically integrated with, adjacent to, or within normal commuting distance of that metropolitan or other geographic area. Security incident means a cybersecurity or physical security event that actually jeopardizes or has a significant likelihood of jeopardizing automated system operation, reliability, security, or capacity, or the availability, confidentiality or integrity of data. Security incident response plan means a written plan documenting the derivatives clearing organization's policies, controls, procedures, and resources for identifying, responding to, mitigating, and recovering from security incidents, and the roles and responsibilities of its management, staff, and independent contractors in responding to security incidents. A security incident response plan may be a separate document or a business continuity-disaster recovery plan section or appendix dedicated to security incident response. Security incident response plan testing means testing of a derivatives clearing organization's security incident response plan to determine the plan's effectiveness, identify its potential weaknesses or deficiencies, enable regular plan updating and improvement, and maintain organizational preparedness and resiliency with respect to security incidents. Methods of conducting security incident response plan testing may include, but are not limited to, checklist completion, walk-through or table-top exercises, simulations, and comprehensive exercises. Vulnerability testing means testing of a derivatives clearing organization's automated systems to determine what information may be discoverable through a reconnaissance analysis of those systems and what vulnerabilities may be present on those systems. Wide-scale disruption means an event that causes a severe disruption or destruction of transportation, telecommunications, power, water, or other critical infrastructure components in a relevant area, or an event that results in an evacuation or unavailability of the population in a relevant area. (b) Program of risk analysis and oversight--(1) General. A derivatives clearing organization shall establish and maintain a program of risk analysis and oversight with respect to its operations and automated systems to identify and minimize sources of operational risk through: (i) The development of appropriate controls and procedures; and (ii) The development of automated systems that are reliable, secure, and have adequate scalable capacity. (2) Elements of program. A derivatives clearing organization's program of risk analysis and oversight with respect to its operations and automated systems, as described in paragraph (b)(1) of this section, shall address each of the following elements: (i) Information security, including, but not limited to, controls relating to: Access to systems and data (including, least privilege, separation of duties, account monitoring and control); user and device identification and authentication; security awareness training; audit log maintenance, monitoring, and analysis; media protection; personnel security and screening; automated system and communications protection (including, network port control, boundary defenses, encryption); system and information integrity (including, malware defenses, software integrity monitoring); vulnerability management; penetration testing; security incident response and management; and any other elements of information security included in generally accepted best practices; (ii) Business continuity and disaster recovery planning and resources, including, but not limited to the controls and capabilities described in paragraph (c) of this section; and any other elements of business continuity [[Page 64337]] and disaster recovery planning and resources included in generally accepted best practices; (iii) Capacity and performance planning, including, but not limited to, controls for monitoring the derivatives clearing organization's systems to ensure adequate scalable capacity (including, testing, monitoring, and analysis of current and projected future capacity and performance, and of possible capacity degradation due to planned automated system changes); and any other elements of capacity and performance planning included in generally accepted best practices; (iv) Systems operations, including, but not limited to, system maintenance; configuration management (including, baseline configuration, configuration change and patch management, least functionality, inventory of authorized and unauthorized devices and software); event and problem response and management; and any other elements of system operations included in generally accepted best practices; (v) Systems development and quality assurance, including, but not limited to, requirements development; pre-production and regression testing; change management procedures and approvals; outsourcing and vendor management; training in secure coding practices; and any other elements of systems development and quality assurance included in generally accepted best practices; and (vi) Physical security and environmental controls, including, but not limited to, physical access and monitoring; power, telecommunication, and environmental controls; fire protection; and any other elements of physical security and environmental controls included in generally accepted best practices. (3) Standards for program. In addressing the elements listed under paragraph (b)(2) of this section, a derivatives clearing organization shall follow generally accepted standards and industry best practices with respect to the development, operation, reliability, security, and capacity of automated systems. (4) Resources. A derivatives clearing organization shall establish and maintain resources that allow for the fulfillment of each obligation and responsibility of the derivatives clearing organization, including the daily processing, clearing, and settlement of transactions, in light of any risk to its operations and automated systems. The derivatives clearing organization shall periodically verify the adequacy of such resources. (c) Business continuity and disaster recovery--(1) General. A derivatives clearing organization shall establish and maintain a business continuity and disaster recovery plan, emergency procedures, and physical, technological, and personnel resources sufficient to enable the timely recovery and resumption of operations and the fulfillment of each obligation and responsibility of the derivatives clearing organization, including, but not limited to, the daily processing, clearing, and settlement of transactions, following any disruption of its operations. (2) Recovery time objective. A derivatives clearing organization's business continuity and disaster recovery plan, as described in paragraph (c)(1) of this section, shall have, and the derivatives clearing organization shall maintain physical, technological, and personnel resources sufficient to meet, a recovery time objective of no later than the next business day following a disruption. (3) Coordination of plans. A derivatives clearing organization shall, to the extent practicable: (i) Coordinate its business continuity and disaster recovery plan with those of its clearing members, in a manner adequate to enable effective resumption of daily processing, clearing, and settlement of transactions following a disruption; (ii) Initiate and coordinate periodic, synchronized testing of its business continuity and disaster recovery plan with those of its clearing members; and (iii) Ensure that its business continuity and disaster recovery plan takes into account the plans of its providers of essential services, including telecommunications, power, and water. (d) Outsourcing. (1) A derivatives clearing organization shall maintain the resources required under paragraphs (b)(4) and (c)(1) of this section either: (i) Using its own employees as personnel, and property that it owns, licenses, or leases; or (ii) Through written contractual arrangements with another derivatives clearing organization or other service provider. (2) Retention of responsibility. A derivatives clearing organization that enters into a contractual outsourcing arrangement shall retain complete responsibility for any failure to meet the requirements specified in paragraphs (b) and (c) of this section. The derivatives clearing organization must employ personnel with the expertise necessary to enable it to supervise the service provider's delivery of the services. (3) Testing of resources. The testing referred to in paragraph (e) of this section shall apply to all of the derivatives clearing organization's own and outsourced resources, and shall verify that all such resources will work together effectively. Where testing is required to be conducted by an independent contractor, the derivatives clearing organization shall engage a contractor that is independent from both the derivatives clearing organization and any outside service provider used to design, develop, or maintain the resources being tested. (e) Testing--(1) General. A derivatives clearing organization shall conduct regular, periodic, and objective testing and review of: (i) Its automated systems to ensure that they are reliable, secure, and have adequate scalable capacity; and (ii) Its business continuity and disaster recovery capabilities, using testing protocols adequate to ensure that the derivatives clearing organization's backup resources are sufficient to meet the requirements of paragraph (c) of this section. (2) Vulnerability testing. A derivatives clearing organization shall conduct vulnerability testing of a scope sufficient to satisfy the requirements set forth in paragraph (e)(8) of this section. (i) A derivatives clearing organization shall conduct such vulnerability testing at a frequency determined by an appropriate risk analysis, but no less frequently than quarterly. (ii) Such vulnerability testing shall include automated vulnerability scanning, which shall follow generally accepted best practices. (iii) A derivatives clearing organization shall conduct vulnerability testing by engaging independent contractors or by using employees of the derivatives clearing organization who are not responsible for development or operation of the systems or capabilities being tested. (3) External penetration testing. A derivatives clearing organization shall conduct external penetration testing of a scope sufficient to satisfy the requirements set forth in paragraph (e)(8) of this section. (i) A derivatives clearing organization shall conduct such external penetration testing at a frequency determined by an appropriate risk analysis, but no less frequently than annually. (ii) A derivatives clearing organization shall engage independent contractors to conduct the required annual external penetration test. A derivatives clearing organization may conduct other external penetration testing by using employees of the derivatives clearing organization [[Page 64338]] who are not responsible for development or operation of the systems or capabilities being tested. (4) Internal penetration testing. A derivatives clearing organization shall conduct internal penetration testing of a scope sufficient to satisfy the requirements set forth in paragraph (e)(8) of this section. (i) A derivatives clearing organization shall conduct such internal penetration testing at a frequency determined by an appropriate risk analysis, but no less frequently than annually. (ii) A derivatives clearing organization shall conduct internal penetration testing by engaging independent contractors, or by using employees of the derivatives clearing organization who are not responsible for development or operation of the systems or capabilities being tested. (5) Controls testing. A derivatives clearing organization shall conduct controls testing of a scope sufficient to satisfy the requirements set forth in paragraph (e)(8) of this section. (i) A derivatives clearing organization shall conduct controls testing, which includes testing of each control included in its program of risk analysis and oversight, at a frequency determined by an appropriate risk analysis, but shall test and assess key controls no less frequently than every three years. A derivatives clearing organization may conduct such testing on a rolling basis over the course of the required period. (ii) A derivatives clearing organization shall engage independent contractors to test and assess the key controls included in the derivatives clearing organization's program of risk analysis and oversight no less frequently than every three years. A derivatives clearing organization may conduct any other controls testing required by this section by using independent contractors or employees of the derivatives clearing organization who are not responsible for development or operation of the systems or capabilities being tested. (6) Security incident response plan testing. A derivatives clearing organization shall conduct security incident response plan testing sufficient to satisfy the requirements set forth in paragraph (e)(8) of this section. (i) The derivatives clearing organization shall conduct such security incident response plan testing at a frequency determined by an appropriate risk analysis, but no less frequently than annually. (ii) The derivatives clearing organization's security incident response plan shall include, without limitation, the derivatives clearing organization's definition and classification of security incidents, its policies and procedures for reporting security incidents and for internal and external communication and information sharing regarding security incidents, and the hand-off and escalation points in its security incident response process. (iii) The derivatives clearing organization may coordinate its security incident response plan testing with other testing required by this section or with testing of its other business continuity-disaster recovery and crisis management plans. (iv) The derivatives clearing organization may conduct security incident response plan testing by engaging independent contractors or by using employees of the derivatives clearing organization. (7) Enterprise technology risk assessment. A derivatives clearing organization shall conduct enterprise technology risk assessments of a scope sufficient to satisfy the requirements set forth in paragraph (e)(8) of this section. (i) A derivatives clearing organization shall conduct an enterprise technology risk assessment at a frequency determined by an appropriate risk analysis, but no less frequently than annually. A derivatives clearing organization that has conducted an enterprise technology risk assessment that complies with this section may conduct subsequent assessments by updating the previous assessment. (ii) A derivatives clearing organization may conduct enterprise technology risk assessments by using independent contractors or employees of the derivatives clearing organization who are not responsible for development or operation of the systems or capabilities being assessed. (8) Scope of testing and assessment. The scope of testing and assessment required by this section shall be broad enough to include the testing of automated systems and controls that a derivatives clearing organization's required program of risk analysis and oversight and its current cybersecurity threat analysis indicate is necessary to identify risks and vulnerabilities that could enable an intruder or unauthorized user or insider to: (i) Interfere with the derivatives clearing organization's operations or with fulfillment of its statutory and regulatory responsibilities; (ii) Impair or degrade the reliability, security, or capacity of the derivatives clearing organization's automated systems; (iii) Add to, delete, modify, exfiltrate, or compromise the integrity of any data related to the derivatives clearing organization's regulated activities; or (iv) Undertake any other unauthorized action affecting the derivatives clearing organization's regulated activities or the hardware or software used in connection with those activities. (9) Internal reporting and review. Both the senior management and the board of directors of the derivatives clearing organization shall receive and review reports setting forth the results of the testing and assessment required by this section. The derivatives clearing organization shall establish and follow appropriate procedures for the remediation of issues identified through such review, as provided in paragraph (e)(10) of this section, and for evaluation of the effectiveness of testing and assessment protocols. (10) Remediation. A derivatives clearing organization shall identify and document the vulnerabilities and deficiencies in its systems revealed by the testing and assessment required by this section. The derivatives clearing organization shall conduct and document an appropriate analysis of the risks presented by each vulnerability or deficiency to determine and document whether to remediate the vulnerability or deficiency or accept the associated risk. When a derivatives clearing organization determines to remediate a vulnerability or deficiency, it must remediate in a timely manner given the nature and magnitude of the associated risk. (f) Recordkeeping. A derivatives clearing organization shall maintain, and provide to staff of the Division of Clearing and Risk, or any successor division, promptly upon request, pursuant to Sec. 1.31 of this chapter: (1) Current copies of the derivatives clearing organization's business continuity and disaster recovery plan and other emergency procedures. Such plan and procedures shall be updated at a frequency determined by an appropriate risk analysis, but no less frequently than annually; (2) All assessments of the derivatives clearing organization's operational risks or system safeguards-related controls; (3) All reports concerning testing and assessment required by this section, whether conducted by independent contractors or by employees of the derivatives clearing organization; and (4) All other documents requested by staff of the Division of Clearing and Risk, or any successor division, in connection with Commission oversight of system safeguards pursuant to the Act or Commission regulations, or in connection with Commission maintenance of a current profile of the [[Page 64339]] derivatives clearing organization's automated systems. (5) Nothing in paragraph (f) of this section shall be interpreted as reducing or limiting in any way a derivatives clearing organization's obligation to comply with Sec. 1.31 of this chapter. (g) Notice of exceptional events. A derivatives clearing organization shall notify staff of the Division of Clearing and Risk, or any successor division, promptly of: (1) Any hardware or software malfunction, security incident, or targeted threat that materially impairs, or creates a significant likelihood of material impairment, of automated system operation, reliability, security, or capacity; or (2) Any activation of the derivatives clearing organization's business continuity and disaster recovery plan. (h) Notice of planned changes. A derivatives clearing organization shall provide staff of the Division of Clearing and Risk, or any successor division, timely advance notice of all material: (1) Planned changes to the derivatives clearing organization's automated systems that may impact the reliability, security, or capacity of such systems; and (2) Planned changes to the derivatives clearing organization's program of risk analysis and oversight. 0 3. In Sec. 39.34, revise paragraphs (a), (b)(3), and (c) to read as follows: Sec. 39.34 System safeguards for systemically important derivatives clearing organizations and subpart C derivatives clearing organizations. (a) Notwithstanding Sec. 39.18(c)(2), the business continuity and disaster recovery plan described in Sec. 39.18(c)(1) for each systemically important derivatives clearing organization and subpart C derivatives clearing organization shall have the objective of enabling, and the physical, technological, and personnel resources described in Sec. 39.18(c)(1) shall be sufficient to enable, the systemically important derivatives clearing organization or subpart C derivatives clearing organization to recover its operations and resume daily processing, clearing, and settlement no later than two hours following the disruption, for any disruption including a wide-scale disruption. (b) * * * (3) The provisions of Sec. 39.18(d) shall apply to these resource requirements. (c) Each systemically important derivatives clearing organization and subpart C derivatives clearing organization must conduct regular, periodic tests of its business continuity and disaster recovery plans and resources and its capacity to achieve the required recovery time objective in the event of a wide-scale disruption. The provisions of Sec. 39.18(e) shall apply to such testing. * * * * * Issued in Washington, DC, on September 9, 2016, by the Commission. Christopher J. Kirkpatrick, Secretary of the Commission. Note: The following appendices will not appear in the Code of Federal Regulations. Appendices to System Safeguards Testing Requirements for Derivatives Clearing Organizations--Commission Voting Summary, Chairman's Statement, and Commissioners' Statements Appendix 1--Commission Voting Summary On this matter, Chairman Massad and Commissioners Bowen and Giancarlo voted in the affirmative. No Commissioner voted in the negative. Appendix 2--Statement of Chairman Timothy G. Massad I strongly support the two rules the Commission has finalized today. The risk of cyberattack probably represents the single greatest threat to the stability and integrity of our markets today. Instances of cyberattacks are all too familiar both inside and outside the financial sector. Today, they often are motivated not just by those with a desire to profit, but by those with a desire deliberately to disrupt or destabilize orderly operations. That is why these system safeguard rules are so important. The rules we have finalized today will apply to the core infrastructure in our markets--the exchanges, clearinghouses, trading platforms, and trade repositories. And they will ensure that those private companies are regularly evaluating cyber risks and testing their cybersecurity and operational risk defenses. While our rules already require this generally, the measures we approved today add greater definition--not by being overly prescriptive, but by setting some principles-based standards, and requiring specific types of testing, all rooted in industry best practices. I've said many times that as regulators, we must not just look backwards to address the causes of past failures or crises. We also must look ahead--ahead to the new opportunities and challenges facing our markets. Financial markets constantly evolve, and we must ensure our regulatory framework is adapting to these changes. These new rules are one good example of how we are looking ahead and addressing these new challenges. They will serve as a strong and important complement to the many other steps being taken by regulators and market participants to address cybersecurity. For example, government agencies and market participants are already working together to share information about potential threats and risks--and learn from one another. I want to thank all those who provided feedback on the proposed rules the Commission approved last December. We received a number of thoughtful comments from market participants, most of which expressed broad support for the proposals. Commenters also highlighted some areas of concern, and we made adjustments based on that feedback. For example, we have reduced the frequency of controls testing and narrowed the instances where independent contractor testing is required. We have also clarified definitions of key terms, and made clear that the scope of required testing will be based on appropriate risk and threat analysis. I also thank Commission staff for their hard work on these measures, particularly our staff in the Division of Market Oversight and Division of Clearing and Risk, as well as the support that is always provided by staff in the Office of General Counsel, the Office of Chief Economist and other staff who comment on the rules. I also thank my fellow Commissioners Bowen and Giancarlo for their support of and suggestions regarding these final rules. Appendix 3--Concurring Statement of Commissioner Sharon Y. Bowen I will be voting yes on both systems safeguards rules. There is not much more to say than what I said when these rules were proposed on December 10, 2015.\1\ Cybersecurity is a top concern for American companies, especially financial firms. These rules are a good step forward in addressing these concerns. --------------------------------------------------------------------------- \1\ Concurring Statement of Commissioner Sharon Y. Bowen Regarding Notice of Proposed Rulemaking on System Safeguards Testing Requirements (Dec. 10, 2015), available at http://www.cftc.gov/PressRoom/SpeechesTestimony/bowenstatement121615b. --------------------------------------------------------------------------- As I noted when they were proposed, there are many aspects of these proposals that I like: First, they set up a comprehensive testing regime by: (a) defining the types of cybersecurity testing essential to fulfilling system safeguards testing obligations, including vulnerability testing, penetration testing, controls testing, security incident response plan testing, and enterprise technology risk assessment; (b) requiring internal reporting and review of testing results; and (c) mandating remediation of vulnerabilities and deficiencies. Further, for certain significant entities, based on trading volume, it requires heightened measures such as minimum frequency requirements for conducting certain testing, and specific requirements for the use of independent contractors. Second, there is a focus on governance--requiring, for instance, that firms' Board of Directors receive and review all reports setting forth the results of all testing. And third, these rulemakings are largely based on well-regarded, accepted best practices for cybersecurity, including The National Institute of Standards and Technology [[Page 64340]] Framework for Improving Critical Infrastructure Cybersecurity (``NIST Framework'').\2\ --------------------------------------------------------------------------- \2\ Id. See also NIST Framework, Subcategory PR.IP-10, at 28, and Category DE.DP, at 31, available at http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf. I was also an early proponent of including all registered entities, including SEFs, in this rule. I am glad to see them included, and look forward to the staff roundtable to discuss how to apply heightened standards to the significant SEFs. Thank you and I look forward to the staff's presentation. Appendix 4--Statement of Commissioner J. Christopher Giancarlo Good regulation should be balanced. It should have a positive impact on the marketplace while mitigating costs to the extent possible. I believe today's system safeguards final rule for derivatives clearing organizations (DCOs) generally achieves such balance although I have concerns about the cost impact on smaller DCOs. As I have said, cyber and system security is one of the most important issues facing markets today in terms of integrity and financial stability.\1\ Given its importance, it is right that the Commission implements rules requiring DCOs and other registrants to conduct regular testing of their systems. I am pleased that the final rule requires DCOs to follow industry adopted standards and best practices. I believe this approach recognizes the rapid evolution of cyber threats and will allow DCOs the flexibility to continually update their cyber defenses in response to these threats. I also recognize that the final rule addresses my concern that being hacked by itself cannot be considered a rule violation subject to enforcement. The final rule clarifies that the Commission it is not seeking to hold DCOs strictly liable for being attacked. --------------------------------------------------------------------------- \1\ System Safeguards Testing Requirements, 80 FR 80140, 80190- 191 (Dec. 23, 2015). --------------------------------------------------------------------------- While the final rule generally takes the right approach, I am concerned about its cost on smaller DCOs. I have expressed my concern about the cost of regulation on smaller market participants on numerous past occasions.\2\ One commenter to this rulemaking noted that its costs will likely increase two to three times if these rules are finalized as proposed.\3\ The independent contractor and employee testing requirement is especially costly for these small DCOs. While the parallel designated contract market (DCM) system safeguards rulemaking addresses this cost concern through the ``covered-DCM'' concept, the DCO rule does not. Although the DCO rule does not have such a concept, I understand from our Division of Clearing and Risk that they are willing to discuss the concerns of smaller DCOs. I encourage those DCOs to raise their concerns with the Division and encourage the Division to act with appropriate practicality. --------------------------------------------------------------------------- \2\ See e.g., Regulation Automated Trading, 80 FR 78824, 78946 (Dec. 17, 2015); Guest Lecture of Commissioner J. Christopher Giancarlo, Harvard Law School, Fidelity Guest Lecture Series on International Finance, Dec. 1, 2015. \3\ Minneapolis Grain Exchange, Inc. Comment Letter at 13, Feb. 22, 2016. --------------------------------------------------------------------------- I note approvingly that the Commission has alleviated some burdens from the proposed rulemaking such as increasing the frequency of key controls testing from two years to three years, removing the requirement for independent contractors to conduct vulnerability testing and removing the explicit requirement for authenticated scanning, among other requirements. I support the final DCO system safeguards rule despite concerns about its costs. Although I would have preferred that the rule take a less one-size-fits-all approach, I am a firm supporter of effective cyber and system security policies and procedures given the serious threat that cyber belligerents pose. I commend staff for their hard work and generally practical approach to system safeguards for DCOs. I also appreciate that they responded to many comments in an effort to reduce some of the burdens of the final rule. I therefore vote to adopt this rule. [FR Doc. 2016-22413 Filed 9-16-16; 8:45 am] BILLING CODE 6351-01-P
![64322 Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations
COMMODITY FUTURES TRADING Principle I, which concerns a DCO’s comments, is adopting the Proposal
COMMISSION system safeguards.3 In 2013, the subject to certain changes, as noted
Commission adopted additional below.
17 CFR Part 39 standards, including additional system
B. Need for Cybersecurity Testing
safeguards requirements,4 for
RIN 3038–AE29 In the Proposal, the Commission
compliance with the core principles for
systemically important DCOs described the well-documented increase
System Safeguards Testing
(‘‘SIDCOs’’) and DCOs that elect to opt- in cyber threats, and the need to
Requirements for Derivatives Clearing
in to the SIDCO regulatory requirements enhance its existing requirements for
Organizations
(‘‘Subpart C DCOs’’).5 cybersecurity testing in light of this
AGENCY: Commodity Futures Trading Regulation 39.18 implements Core increase.8 In the current environment,
Commission. Principle I and, among other things, cybersecurity testing is crucial to efforts
ACTION: Final rule. specifies: (1) The requisite elements, by exchanges, clearing organizations,
standards, and resources of a DCO’s swap data repositories, and other
SUMMARY: The Commodity Futures program of risk analysis and oversight entities in the financial sector to
Trading Commission (‘‘Commission’’) is with respect to its operations and strengthen cyber defenses; mitigate
adopting enhanced requirements for automated systems; (2) the requirements operational, reputational, and financial
testing by a derivatives clearing for a DCO’s business continuity and risk; and maintain cyber resilience and
organization (‘‘DCO’’) of its system disaster recovery plan, emergency the ability to recover from cyber attacks.
safeguards, as well as additional procedures, and physical, technological, To maintain the effectiveness of
amendments to reorder and renumber and personnel resources described cybersecurity controls, such entities
certain paragraphs within the therein; (3) the responsibilities, must regularly test their system
regulations and make other minor obligations, and recovery time objective safeguards in order to find and fix
changes to improve the clarity of the of a DCO following a disruption of its vulnerabilities before an attacker
rule text. operations; and (4) other system exploits them.
DATES: Effective date: This rule is safeguards requirements related to Cybersecurity testing is a well-
reporting, recordkeeping, testing, and established best practice generally and
effective September 19, 2016.
for financial sector entities. The
Compliance dates: DCOs must comply coordination with a DCO’s clearing
members and service providers. National Institute of Standards and
with § 39.18(e)(2) and (6) by March 20,
On December 23, 2015, the Technology (‘‘NIST’’) Framework for
2017; § 39.18(e)(3) through (5), and (7)
Commission proposed to enhance its Improving Critical Infrastructure
by September 19, 2017; and all other
system safeguards requirements for Cybersecurity calls for testing of
provisions of § 39.18 by September 19,
DCOs by revising § 39.18 to require cybersecurity response and recovery
2016.
specific types of testing, and specifying plans and cybersecurity detection
FOR FURTHER INFORMATION CONTACT: processes and procedures.9 The
the minimum frequency with which
Eileen A. Donovan, Deputy Director, such testing must be performed. The Financial Industry Regulatory Authority
202–418–5096, edonovan@cftc.gov, Commission also proposed additional (‘‘FINRA’’) 2015 Report on
Division of Clearing and Risk, amendments to reorder and renumber Cybersecurity Practices notes that
Commodity Futures Trading certain paragraphs and make other ‘‘[r]isk assessments serve as
Commission, Three Lafayette Centre, minor changes to improve the clarity of foundational tools for firms to
1155 21st Street NW., Washington, DC the rule text, as well as corresponding understand the cybersecurity risks they
20581; or Julie A. Mohr, Deputy technical corrections to § 39.34 (the face across the range of the firm’s
Director, (312) 596–0568, jmohr@ ‘‘Proposal’’).6 activities and assets,’’ and calls for firms
cftc.gov; Tad Polley, Associate Director, The comment period for the Proposal to develop, implement, and test
(312) 596–0551, tpolley@cftc.gov; or ended on February 22, 2016. The cybersecurity incident response plans.10
Scott Sloan, Attorney-Advisor, (312) Commission received seven substantive The Federal Financial Institutions
596–0708, ssloan@cftc.gov, Division of comment letters in response to the Examination Council (‘‘FFIEC’’),11
Clearing and Risk, Commodity Futures Proposal 7 and, in consideration of those another important source of
Trading Commission, 525 West Monroe
Street, Chicago, Illinois 60661. 3 Core Principle I requires a DCO to: (1) Establish Intercontinental Exchange, Inc.; NGX; The Options
SUPPLEMENTARY INFORMATION: and maintain a program of risk analysis and Clearing Corporation; Minneapolis Grain Exchange;
oversight to identify and minimize sources of North American Derivatives Exchange;
I. Background operational risk; (2) establish and maintain LCH.Clearnet Group; and CME Group, Inc.
emergency procedures, backup facilities, and a plan 8 80 FR 80114, at 80114–80115.
A. System Safeguards Requirements for for disaster recovery that allows for the timely 9 NIST, Framework for Improving Critical
DCOs recovery and resumption of the DCO’s operations Infrastructure Cybersecurity, Feb. 2014, v. 1,
and the fulfillment of each of its obligations and Subcategory PR.IP–10, p. 28, and Category DE.DP,
Section 5b(c)(2) of the Commodity responsibilities; and (3) periodically conduct tests p. 31, available at: http://www.nist.gov/cyber
Exchange Act (‘‘CEA’’) 1 sets forth core to verify that the DCO’s backup resources are framework/upload/cybersecurity-framework-
sufficient. 021214.pdf.
principles with which a DCO must 4 17 CFR 39.34. 10 FINRA, Report on Cybersecurity Practices, Feb.
comply in order to be registered and to 5 Derivatives Clearing Organizations and
2015 (‘‘FINRA Report’’), pp. 1–2, available at:
maintain registration with the International Standards, 78 FR 72476 (Dec. 2, 2013) https://www.finra.org/sites/default/files/
Commission. In November 2011, the
asabaliauskas on DSK3SPTVN1PROD with RULES
(codified at 17 CFR part 39). p602363%20Report%20on%20Cybersecurity%20
Commission adopted regulations 2 to 6 See System Safeguards Testing Requirements for Practices_0.pdf.
establish standards for compliance with Derivatives Clearing Organizations; Proposed Rule, 11 The FFIEC includes the Board of Governors of
80 FR 80114 (Dec. 3, 2015) (to be codified at 17 CFR the Federal Reserve System, the Federal Deposit
the core principles, including Core part 39). Insurance Corporation, the Office of the
7 All comment letters are available through the Comptroller of the Currency, the Consumer
17 U.S.C. 7a–1. Commission’s Web site at: http:// Financial Protection Bureau, the National Credit
2 Derivatives Clearing Organization General comments.cftc.gov/PublicComments/Comment Union Administration, and the State Liaison
Provisions and Core Principles, 76 FR 69334 (Nov. List.aspx?id=1649. The Commission received Committee of the Conference of State Bank
8, 2011) (codified at 17 CFR part 39). comments from the following parties: Supervision.
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/2.svg)
![64324 Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations
needed background and skills while § 39.18(e)(8). Proposed § 39.18(e)(3)(i) tests. Requiring specific tests would be
also having the level of independence would require a DCO to conduct overly prescriptive and could stifle the
which the Commission would require. external penetration testing at a development of new, more advanced
Therefore, an entity like MGEX would frequency determined by an appropriate testing methods.
be forced to either bear significant cost risk analysis, but at a minimum no less CME stated that DCOs may find it
to hire dedicated employees exclusively frequently than annually. The proposed challenging to recruit and retain
for regulatory testing compliance or bear rule would also provide that employees capable of conducting
significant cost to have independent independent contractors must perform internal penetration testing without
contractors perform all four tests. the required annual external penetration introducing unnecessary risks into
OCC believes that requiring a DCO to test on behalf of the DCO. However, production and other sensitive
use an independent contractor to other external penetration testing could environments, because there is a
perform vulnerability testing during the be performed by appropriately qualified scarcity of qualified professionals with
same year that such person is DCO employees not responsible for those skills. As a result, CME argued the
performing external penetration testing development or operation of the systems Commission should clarify that
would unnecessarily increase costs or capabilities being tested. conducting annual internal penetration
without an added benefit, because ICE and Nadex supported requiring tests should be an objective, and not a
vulnerability testing is largely subsumed external penetration testing as a part of strict requirement, so that DCOs can
within external penetration testing. a DCO’s program of risk analysis and prioritize effective testing done by
As explained in the Proposal, the oversight. OCC generally supported independent employees over
Commission believes it is important that external penetration testing by conducting testing at least annually
vulnerability testing be conducted from independent third parties. ICE and CME simply to comply with a prescriptive
the perspective of an outsider, and as a supported performing the testing testing frequency requirement. ICE
result does not agree with MGEX that annually. stated that the Commission should be
internal employees responsible for ICE suggested that the Commission silent on parameters for voluntary
development or operation of the tested should amend the definition of internal testing, allowing each DCO to
systems or capabilities should be ‘‘external penetration testing’’ to include determine its own methodology for such
permitted to conduct the tests. The specific types of testing. The testing.
Commission agrees with various Commission is declining to do so. The Commission disagrees with
commenters, however, that the Requiring specific tests would be overly CME’s suggestion that internal
regulation should permit but not require prescriptive and could stifle the penetration testing should be merely an
a DCO to use independent contractors to development of new, more advanced objective. The requirement for internal
conduct the required vulnerability testing methods. Accordingly, upon penetration testing is based on industry
testing. As a result, the Commission is review of the comments, the standards.16 In addition, because the
revising proposed § 39.18(e)(2)(iii) as Commission is adopting § 39.18(e)(3) regulation provides sufficient flexibility
follows (added text in italics), ‘‘A and the definition of ‘‘external regarding the individuals who are
derivatives clearing organization shall penetration testing’’ as proposed. permitted to conduct the internal
conduct vulnerability testing by penetration tests, the Commission does
C. Internal Penetration Testing
engaging independent contractors, or by not believe a change to the regulation
using employees of the derivatives Proposed § 39.18(a) would define based on CME’s comment is necessary.
clearing organization who are not ‘‘internal penetration testing’’ as In response to ICE’s comment regarding
responsible for development or ‘‘attempts to penetrate a [DCO’s] voluntary internal testing, the
operation of the systems or capabilities automated systems from inside the Commission notes that the final rule
being tested.’’ This revision aligns the systems’ boundaries to identify and does not impose any requirements on
regulation more closely with industry exploit vulnerabilities.’’ Proposed testing DCOs conduct on a voluntary
standards, which call for vulnerability § 39.18(e)(4) would require the testing to basis, beyond the requirements of the
testing to be conducted by independent be of a scope sufficient to satisfy the regulation. Therefore, the Commission
employees while recognizing the testing scope requirements of proposed declines to make any changes in
benefits and potential risks of engaging § 39.18(e)(8). Proposed § 39.18(e)(4)(i) response to these comments and
independent contractors.15 would require a DCO to conduct confirms that final § 39.18(e)(4) sets
internal penetration testing at a forth requirements rather than
B. External Penetration Testing
frequency determined by an appropriate objectives or a voluntary program.
Proposed § 39.18(a) would define risk analysis, but no less frequently than MGEX stated that the required
‘‘external penetration testing’’ as annually. The test could be conducted frequency of testing should be
‘‘attempts to penetrate a [DCO’s] by independent contractors, or by determined by the frequency of systems
automated systems from outside the appropriately qualified DCO employees changes and the scope of exposure, and
systems’ boundaries to identify and not responsible for development or should not be reduced to a static
exploit vulnerabilities,’’ and proposed operation of the systems or capabilities minimum. The Commission declines to
§ 39.18(e)(3) would require the testing to being tested. amend the regulation in response to
be of a scope sufficient to satisfy the ICE and Nadex supported requiring MGEX’s comment, and notes that that
testing scope requirements of proposed internal penetration testing as a part of the frequency requirement in final
a DCO’s program of risk analysis and § 39.18(e)(4)(i) is based on industry
asabaliauskas on DSK3SPTVN1PROD with RULES
15 FFIEC Handbook, supra note 13, at 81 (calling
oversight. standards and is not overly
for such tests to be performed ‘‘by individuals who
are also independent of the design, installation,
ICE suggested that the Commission prescriptive.17
maintenance, and operation of the tested system’’); should amend the definition of Accordingly, upon review of the
NIST Special Publication 800–115, Technical Guide ‘‘internal penetration testing’’ to include comments, the Commission is adopting
to Information Security Testing and Assessment, specific types of testing. As with
Sept. 2008 (‘‘NIST SP 800–115’’), p. 6–6, available
§ 39.18(e)(4) and the definition of
at: http://csrc.nist.gov/publications/nistpubs/800-
external penetration testing, the
115/SP800-115.pdf (recognizing the benefits and Commission is declining to require 16 See NIST SP 800–115, supra note 15, at 2–5.
risks of engaging third parties to conduct testing). specific forms of internal penetration 17 See id.; FFIEC Handbook, supra note 13, at 82.
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/4.svg)
![Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations 64325
‘‘internal penetration testing’’ as Despite ICE’s comments, the italics), ‘‘A [DCO] shall conduct controls
proposed. Commission is adopting the controls testing, which includes testing of each
testing requirement, which is based on control included in its program of risk
D. Controls Testing
industry standards.18 The Commission analysis and oversight, at a frequency
Proposed § 39.18(a) would define continues to believe that regular, determined by an appropriate risk
‘‘controls testing’’ as an assessment of ongoing testing of all of an analysis, but shall test and assess key
the DCO’s controls to determine organization’s system safeguards-related controls no less frequently than every
whether such controls are implemented controls is a crucial part of a DCO’s risk three years. A [DCO] may conduct such
correctly, are operating as intended, and analysis and oversight program. As testing on a rolling basis over the course
are enabling the DCO to meet the NIST notes, the results of such testing of the required period.’’ The final rule
requirements of § 39.18. Proposed can allow organizations to, among other would thus require key controls testing
§ 39.18(e)(5) would require such testing things, identify potential cybersecurity to occur at least every three years rather
to be of a scope sufficient to satisfy the problems or shortfalls, identify security- than every two and would not prescribe
testing scope requirements of proposed related weaknesses and deficiencies, a minimum frequency for testing of non-
§ 39.18(e)(8). Proposed § 39.18(e)(5)(i) prioritize risk mitigation decisions and key controls. The Commission
would require a DCO to conduct activities, confirm that weaknesses and reiterates, however, that if a DCO’s risk
controls testing, which includes testing deficiencies have been addressed, and analysis indicates a key control should
of each control included in its program inform related budgetary decisions and be tested more frequently than every
of risk analysis and oversight, at a capital investment.19 The Commission three years, the DCO must comply with
frequency determined by an appropriate notes that the definition of ‘‘key the shorter testing frequency. The
risk analysis, but no less frequently than controls’’ provides adequate flexibility changes would further clarify that both
every two years. for a DCO to determine which of its key controls and non-key controls can
Pursuant to proposed § 39.18(e)(5)(ii), controls constitute key controls. While be tested on a rolling basis over the
a DCO would be required to engage ICE believes that the goal should be to applicable time period.
independent contractors to test and eliminate reliance on key controls, the
assess its ‘‘key controls,’’ which would 2. Independence Requirements
Commission believes that so long as
be defined in proposed § 39.18(a) as DCOs continue to rely on them, it is CME stated that requiring non-
controls that an appropriate risk crucial for DCOs to test their employee independent contractors to
analysis determines are either critically effectiveness. test key controls, without involvement
important for effective system by employees, may not provide the most
safeguards or intended to address risks 1. Frequency effective or efficient means for
that evolve or change more frequently CME and OCC stated that the costs of continued key controls testing and
and therefore require more frequent requiring controls testing every two enhancement. CME also stated that
review to ensure their continuing years outweigh the benefits. CME stated internal audit staff can provide a strong
effectiveness in addressing such risks. A that DCOs should be able to test in line and independent third line of defense
DCO may conduct any other non-key with their risk analysis, which may where the department is independent
controls testing by using independent result in a cycle of longer than two from management, objective in its
contractors or employees of the DCO years. CME stated that a three-year cycle findings, professional, and able to have
who are not responsible for requirement would be more appropriate. free and unlimited access to the books,
development or operation of the systems OCC agreed with the proposed testing records, and people of a company. CME
or capabilities being tested. frequency as applied to key controls. further stated that while involving
CME and Nadex supported requiring However, OCC stated that, consistent external resources may be beneficial,
controls testing as a part of a DCO’s with relevant industry best practices, doing so should not exclude
program of risk analysis and oversight. the Commission should alternatively participation by employees not involved
ICE recommended that the consider permitting a DCO to determine in the development or operation of the
Commission remove the controls testing the frequency of controls testing based controls, systems, or capabilities being
requirements and the definition of ‘‘key on the level of risk a control is tested.
controls.’’ ICE stated that attempting to determined to present following an OCC recommended that DCOs be
mandate controls testing will result in appropriate controls risk analysis. permitted to use independent
inconsistent and confused The Commission agrees with CME contractors or independent employees
implementation, distract from useful and OCC that requiring controls testing to test and assess the effectiveness of
security activity, and generate a superset no less frequently than every two years key controls because, in contrast to
of results that are already published in is not necessary. The Commission penetration testing, key controls testing
a more focused fashion through further agrees with CME that three years does not require specialized expertise.
vulnerability, external penetration, is a more appropriate minimum Moreover, OCC believes independent
internal penetration, or security requirement and is revising proposed employees are more knowledgeable
response plan testing. Moreover, ICE § 39.18(e)(5)(i) as follows (added text in about the DCO’s business, risk profile,
believes that the proposed controls and control environment generally,
testing requirements are already 18 See, NIST Special Publication 800–53, Security making them better positioned to
adequately addressed in existing rules, and Privacy Controls for Federal Information perform effective testing of key controls.
both in the U.S. and globally, and Systems and Organizations, rev. 4 (‘‘NIST SP 800– OCC suggests that, at a minimum, the
asabaliauskas on DSK3SPTVN1PROD with RULES
through current examination coverage. 53’’), pp. app. F–CA at F–55, available at: http://
nvlpubs.nist.gov/nistpubs/SpecialPublications/
Commission should make clear that
ICE added that the concept of a key NIST.SP.800-53r4.pdf.; FFIEC Handbook, supra whenever an independent contractor is
control is not universally adopted, and note 13, at 12. used to perform testing, the
that the goal is not to test such controls, 19 NIST Special Publication 800–53A, Assessing
independent contractor is not required
but to eliminate reliance on them. ICE Security and Privacy Controls in Federal to work in isolation but rather alongside
Information Systems and Organizations, rev. 4
believes that the key controls proposal (‘‘NIST SP 800–53A’’), p. 3, available at: http:// independent employees of the DCO.
imposes a large burden for little to no nvlpubs.nist.gov/nistpubs/SpecialPublications/ The Commission believes that
practical improvement in security. NIST.SP.800-53Ar4.pdf. independent testing provides critical
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/5.svg)
![64326 Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations
impartiality and credibility, and notes its policies and procedures for reporting either: (i) Defer to the DCO’s definition
that generally accepted best practices security incidents and for internal and as set forth in its risk analysis plan; or
recognize the benefits of using external communication and (ii) replace ‘‘potentially jeopardizes’’
independent contractors.20 The information sharing regarding security with ‘‘has a significant likelihood of
Commission is clarifying, however, that incidents, and the hand-off and jeopardizing.’’
when a DCO must engage independent escalation points in its security incident The Commission recognizes OCC’s
contractors to conduct key controls response process. Proposed concern and is amending the proposed
testing, those independent contractors § 39.18(e)(6)(iii) would also permit the definition of ‘‘security incident’’ as
may consult with independent DCO to coordinate its security incident follows (added text in italics), ‘‘Security
employees of the DCO when conducting response plan testing with other testing incident means a cybersecurity or
the required testing so long as they required by the regulation or with physical security event that actually
produce an independent report. testing of its other business continuity- jeopardizes or has a significant
Based on the changes to proposed disaster recovery and crisis management likelihood of jeopardizing automated
§ 39.18(e)(5)(i), the Commission is plans. Moreover, proposed system operation, reliability, security, or
revising proposed § 39.18(e)(5)(ii) in § 39.18(e)(6)(iv) would permit the DCO capacity, or the availability,
part as follows (added text in italics), ‘‘A to conduct security incident response confidentiality or integrity of data.’’
[DCO] shall engage independent plan testing by engaging independent This change provides additional clarity
contractors to test and assess the key contractors or by using employees who regarding which cybersecurity events
controls included in the [DCO]’s are not responsible for development or are considered a security incident for
program of risk analysis and oversight operation of the systems or capabilities the purposes of the regulation.
no less frequently than every three being tested. F. Enterprise Technology Risk
years.’’ The regulation as finalized CME, ICE, and Nadex supported
Assessment
would thus require a DCO to engage requiring security incident response
independent contractors to test each key plan testing as a part of a DCO’s Proposed § 39.18(a) would define an
control at least every three years. If, program of risk analysis and oversight. ‘‘enterprise technology risk assessment’’
however, a DCO’s risk analysis CME stated that employees as a written assessment that includes,
concludes that certain key controls must responsible for incident response, who but is not limited to, an analysis of
be tested more frequently than every would not be responsible for the threats and vulnerabilities in the context
three years, the resulting additional tests development or operation of the of mitigating controls. Proposed
may be conducted by independent functional systems or capabilities being § 39.18(a) would also provide that an
contractors or employees of the DCO tested, should be permitted to both enterprise technology risk assessment
who are not responsible for design a DCO’s plan and be responsible identifies, estimates, and prioritizes
development or operation of the systems for testing the plan. CME stated that a risks to a DCO’s operations or assets, or
or capabilities being tested. DCO should be able to leverage its to market participants, individuals, or
employees with expertise in crisis and other entities, resulting from
E. Security Incident Response Plan risk management, and incident response impairment of the confidentiality,
Testing and planning, for both planning and integrity, or availability of data and
Proposed § 39.18(a) would define testing purposes. information or the reliability, security,
‘‘security incident response plan The Commission agrees with CME or capacity of automated systems.
testing’’ as testing of a DCO’s security that the employees who develop a Proposed § 39.18(e)(7) would require
incident response plan to determine the security incident response plan should such assessment to be of a scope
plan’s effectiveness, identifying its be permitted to test the plan. To allow sufficient to satisfy the requirements of
potential weaknesses or deficiencies, DCOs additional flexibility regarding proposed § 39.18(e)(8). Proposed
enabling regular plan updating and security incident response plan testing, § 39.18(e)(7)(i) would require DCOs to
improvement, and maintaining the Commission is revising proposed conduct an enterprise technology risk
organizational preparedness and § 39.18(e)(6)(iv) by deleting ‘‘who are assessment at a frequency determined
resiliency with respect to security not responsible for development or by an appropriate risk analysis, but no
incidents. Methods of conducting operation of the systems or capabilities less frequently than annually. Proposed
security incident response plan testing being tested.’’ This revision allows § 39.18(e)(7)(ii) would permit a DCO to
would include, but not be limited to, security incident response plan testing use independent contractors or
checklist completion, walk-through or to be conducted by either independent employees of the DCO not responsible
table-top exercises, simulations, and contractors or employees, without for development or operation of the
comprehensive exercises. restricting which employees may lead or systems or capabilities being assessed to
Proposed § 39.18(e)(6)(i) would conduct the testing. conduct an enterprise technology risk
require a DCO to conduct the testing at OCC noted that under the proposed assessment.
a frequency determined by an rules, ‘‘security incident’’ is defined as Nadex requested that the Commission
appropriate risk analysis, but at a ‘‘a cybersecurity or physical security clarify whether information related to
minimum no less frequently than event that actually or potentially the enterprise technology risk
annually. Proposed § 39.18(e)(6)(ii) jeopardizes automated system assessment could be combined with the
would require the DCO’s security operation, reliability, security, or regular testing results presented to
incident response plan to include, capacity, or the availability, management and the board of directors
asabaliauskas on DSK3SPTVN1PROD with RULES
without limitation, the DCO’s definition confidentiality or integrity of data.’’ based on the internal reporting and
and classification of security incidents, OCC argued that the inclusion of the review requirements.
term ‘‘potentially’’ renders the In response to Nadex’s comment, the
20 NIST SP 800–115, supra note 15, at 6–6 (NIST definition vague, and could be Commission is clarifying that the
also notes that giving outsiders access to an interpreted to include most, if not all, information required under the
organization’s systems can introduce additional
risk, and recommends proper vetting and attention
cybersecurity events experienced by a regulation can be presented to
to contractual responsibility in this regard); FFIEC DCO. OCC suggested that the management and the board of directors
Handbook, supra note 13, at 81. Commission revise its definition to in the manner each DCO deems
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/6.svg)
![Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations 64327
appropriate, including by presenting it believes this is a reasonable means to § 39.18(e)(8) as follows (added text in
together with other information DCOs reduce both. italics), ‘‘The scope of testing and
must provide to management and the assessment required by this section
2. Independence Requirements
board of directors. shall be broad enough to include the
CME suggested that the Commission testing of automated systems and
1. Frequency permit DCOs to allow internal groups controls that a [DCO]’s required
ICE recommended that the outside of the enterprise risk program of risk analysis and oversight
Commission not adopt the enterprise management function to handle and its current cybersecurity threat
technology risk assessment components of the enterprise analysis indicate is necessary to identify
requirements. ICE stated that attempting technology risk assessment. risks and vulnerabilities that could
to mandate enterprise technology risk ICE stated that the enterprise enable an intruder or unauthorized user
assessments will result in inconsistent technology risk assessment should be or insider. . . .’’ The revisions reinforce
and confused implementation, distract the function of an enterprise risk a risk-based approach to system
from useful security activity, and program separate from the information safeguards testing by basing the scope of
generate a superset of results that are security groups. testing on the DCO’s program of risk
already published in a more focused In response to the comments, the analysis and oversight and current
fashion through vulnerability, external Commission emphasizes that the final cybersecurity threat assessment.
penetration, internal penetration or regulation provides flexibility regarding Nadex noted that the ‘‘current
security response plan testing. who may conduct the enterprise cybersecurity threat analysis’’ the DCO
Moreover, ICE believes that the technology risk assessment. If a DCO would use to assess its possible
proposed enterprise technology risk chooses not to use independent adversaries’ capabilities could be
assessment requirements are already contractors, the enterprise technology interpreted to include not only the
adequately addressed in existing rules, risk assessment may be conducted by DCO’s internal risk assessment, but also
both in the U.S. and globally, and employees who are not responsible for warnings/notices generated from third
through current examination coverage. the development or operation of the party entities. Nadex requested that the
CME supported requiring DCOs to systems or capabilities being assessed. Commission confirm that the ‘‘current
conduct an enterprise technology risk cybersecurity threat analysis’’ refers
G. Scope of Testing
assessment as a part of a DCO’s program only to the DCO’s internal risk
of risk analysis and oversight, but Proposed § 39.18(e)(8) would provide assessment.
believes an assessment should be that the scope of all system safeguards The Commission does not believe that
required at least every two years, rather testing and assessment required by a DCO preparing a cybersecurity threat
than annually, to match the controls § 39.18 must be broad enough to include assessment can appropriately ignore
testing cycle. all testing of automated systems, available external warnings or notices.
The Commission is adopting the networks, and controls necessary to Thus, contrary to Nadex’s
enterprise technology risk assessment identify any vulnerability which, if recommendation, the Commission is
requirements generally as proposed. The exploited or accidentally triggered, clarifying that a DCO is required to
regulation is based on industry could enable an intruder or consider reasonably available external
standards 21 and will help each DCO unauthorized user or insider to: (1) analyses when preparing a current
produce a broad determination of its Interfere with the entity’s operations or cybersecurity threat assessment.
system safeguards-related risks, with fulfillment of the entity’s statutory CME stated that adopting regulations
regardless of the source of the risks. and regulatory responsibilities; (2) requiring DCOs to identify ‘‘any
The Commission is, however, revising impair or degrade the reliability, vulnerability’’ underlies an assumption
proposed § 39.18(e)(7)(i) to read as security, or adequate scalable capacity that DCOs falling victim to the most
follows (added text in italics), ‘‘A [DCO] of the entity’s automated systems; (3) sophisticated threats are singularly
shall conduct an enterprise technology add to, delete, modify, exfiltrate, or responsible for being attacked.
risk assessment at a frequency compromise the integrity of any data Therefore, CME recommended that the
determined by an appropriate risk related to the entity’s regulated Commission adopt safe harbors for
analysis, but no less frequently than activities; or (4) undertake any other DCOs who seek to comply with their
annually. A [DCO] that has conducted unauthorized action affecting the core principle responsibilities in order
an enterprise technology risk entity’s regulated activities or the to encourage DCOs to seek out
assessment that complies with this hardware or software used in partnerships and best serve the common
section may conduct subsequent connection with those activities. goal of improving the industry’s overall
assessments by updating the previous CME and Nadex stated that the state of cyber resilience.
assessment.’’ This change responds to a requirement to identify ‘‘any In light of the revisions to proposed
comment received by the Commission vulnerability’’ that could compromise § 39.18(e)(8) discussed above, the
on its system safeguards proposal for ‘‘any data,’’ or allow an intruder to Commission declines to provide a ‘‘safe
DCMs and SDRs 22 and clarifies that the undertake ‘‘any other unauthorized harbor’’ for DCOs ‘‘who seek to comply
required enterprise technology risk action’’ is too broad. CME argued that in with their core principle
assessment may build upon previous being so broad, the Commission responsibilities.’’ As the revisions make
assessments. The comment noted the undermines the value of a risk-based clear, the Commission is not seeking to
burden and cost of an annual full approach. Nadex suggested that the hold DCOs strictly liable for every cyber
asabaliauskas on DSK3SPTVN1PROD with RULES
assessment, and the Commission proposed requirement be amended to attack they might face.
limit responsibility to a reasonableness
21 See PCI–DSS, supra note 13, at 105; FINRA standard. H. Internal Reporting and Review
Report, supra note 10, at 14. The Commission agrees that the Proposed § 39.18(e)(9) would provide
22 Tradeweb Markets, LLC, Comment Letter on
proposed language is overly broad and that both the senior management and
System Safeguards Testing Requirements Proposed
Rule (Feb. 22, 2016), http://comments.cftc.gov/
undermines a risk-based approach to the board of directors of the DCO must
PublicComments/ system safeguards testing. Therefore, the receive and review reports setting forth
ViewComment.aspx?id=60657&SearchText. Commission is revising proposed the results of the testing and assessment
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/7.svg)
![64328 Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations
required by § 39.18. Moreover, the DCO § 39.18 to identify all vulnerabilities and transfer 24 of risk.25 NIST describes risk
would be required to establish and deficiencies in its systems. The mitigation as risk reduction, and the
follow appropriate procedures for the proposed regulation would require a appropriate risk response for that
remediation of issues identified through DCO to remediate those vulnerabilities portion of risk that cannot be accepted,
this review, as provided in proposed and deficiencies to the extent necessary avoided, shared, or transferred.26 The
§ 39.18(e)(10), and for evaluation of the to enable it to fulfill its statutory and Commission believes that the term
effectiveness of testing and assessment regulatory obligations. In addition, the ‘‘remediate’’ as used in final
protocols. remediation would have to be timely in § 39.18(e)(10) captures mitigation. NIST
Nadex stated that reports generated describes risk avoidance as taking
light of appropriate risk analysis with
based on system testing are often specific actions to eliminate the
respect to the risks presented by such
lengthy and technical, and that activities or technologies that are the
requiring management and the board to vulnerabilities and deficiencies.
basis for the risk or to revise or
review technical testing results would Nadex stated that while it agrees with reposition these activities or
require individuals in those positions to the proposed remediation requirements technologies in the organizational
have a level of technical knowledge and generally, the language requiring mission/business processes to avoid the
sophistication that may not otherwise be identification of ‘‘all’’ vulnerabilities potential for unacceptable risk.27 The
required of the position. Therefore, and deficiencies would essentially Commission believes these types of
Nadex requested that the Commission impose strict liability on the firm for avoidance actions are also properly
clarify whether a narrative executive any breach of its security. considered risk remediation.
summary would satisfy the proposed Nadex also urged the Commission to
In response to Nadex’s comment, the
requirement. Additionally, Nadex establish safe harbor provisions offering
requested that the Commission clarify Commission is revising proposed protection where it is apparent the DCO
whether the reports may be presented to § 39.18(e)(10) as follows, ‘‘A [DCO] shall has acted in good faith and maintains
the board at its regularly scheduled identify and document vulnerabilities reasonable standards, consistent with at
quarterly meetings. and deficiencies in its systems revealed least the minimum requirements
CME, MGEX, and OCC stated that a by the testing and assessment required prescribed by the regulations, to
DCO’s board of directors should be able by this section. The [DCO] shall conduct prevent, monitor, detect, and address
to delegate the review required by and document an appropriate analysis internal and external cyber threats. In
proposed § 39.18(e)(9) to a board-level of the risks presented by each light of the revisions to § 39.18(e)(10),
committee. vulnerability or deficiency to determine the Commission does not believe the
In response to Nadex, the Commission and document whether to remediate the addition of any safe harbor provision is
notes that providing a DCO’s board with vulnerability or deficiency or accept the necessary. The final regulation imposes
a narrative executive summary is not associated risk. When a [DCO] specific system safeguards testing and
sufficient to satisfy the requirements of determines to remediate a vulnerability remediation requirements, and does not
the regulation. Consistent with generally or deficiency, it must remediate in a seek to hold DCOs strictly liable for
accepted best practices, the final timely manner given the nature and every cyber attack.
regulation requires that the board must
magnitude of the associated risk.’’ The J. Recovery Time Objective
instead receive and review the technical
revisions require a DCO to determine Proposed § 39.18(a) would revise the
reports containing testing results and
assessments.23 To the extent there is whether to remediate or accept the risks definition of ‘‘recovery time objective’’
concern regarding management’s or the presented by a vulnerability or to make the language consistent with
board of directors’ ability to understand deficiency based on an analysis of those that used elsewhere in § 39.18.
the required reports, the Commission risks, and to document that analysis. OCC stated that it agrees with the 2-
notes that nothing in the regulation The changes acknowledge that in some hour recovery time objective for
prevents a DCO from including instances, depending on the results of physical events, but believes that a
additional, clarifying documents, such an appropriate risk analysis, a DCO may reasonableness standard is more
as executive summaries or compilations, reasonably choose to accept a given risk. appropriate for cybersecurity events.
with the required reports. The The changes also remove any suggestion
24 The Commission does not believe that risk
Commission believes that providing that testing would necessarily identify
sharing or transfer is an appropriate response to
management or the board of directors every vulnerability, or that a DCO must systems risks, and does not intend for it to
with appropriate summaries or remediate all vulnerabilities. constitute remediation under § 39.18(e)(10) as
compilations can be an effective way to The Commission believes that the
finalized. NIST describes risk sharing or transfer as
the appropriate risk response when organizations
help a DCO fulfill the requirement in terms ‘‘remediate’’ and ‘‘accept’’ provide desire and have the means to shift risk liability and
final § 39.18(e)(9). The Commission is the universe of appropriate responses to responsibility to other organizations. NIST SP 800–
further clarifying that the board may identified vulnerabilities and 39, supra note 13, at 43. The Commission’s
receive the materials at a regularly regulatory approach in this area, however, requires
deficiencies. Industry standards that a DCO retain complete responsibility for its risk
scheduled board meeting and that the
outlining potential responses to cyber program. See 17 CFR 39.18(f)(2)(i) (to be re-codified
board may delegate the review required as § 39.18(d)(2)). Additionally, NIST cautions that
under final § 39.18(e)(9) to an risks speak in terms of mitigating, risk transfer reduces neither the likelihood of
appropriate board-level committee. The accepting, avoiding, and sharing or harmful events occurring nor the consequences in
terms of harm to organizational operations and
Commission is adopting § 39.18(e)(9) as
asabaliauskas on DSK3SPTVN1PROD with RULES
assets, individuals, other organizations, or the
proposed. nation. NIST SP 800–39, supra note 13, pp. 43. The
Commission does not believe that a risk response
I. Remediation that does not address the likelihood of a harmful
Proposed § 39.18(e)(10) would require event or its consequences is an appropriate
response.
a DCO to analyze the results of the 25 See, e.g., NIST SP 800–39, supra note 13, at 41–
testing and assessment required by 43.
26 Id. at 42–43.
23 FFIEC Handbook, supra note 13, at 5. 27 Id. at 42.
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/8.svg)
![64340 Federal Register / Vol. 81, No. 181 / Monday, September 19, 2016 / Rules and Regulations
Framework for Improving Critical pleased that the final rule requires DCOs to ‘‘covered-DCM’’ concept, the DCO rule does
Infrastructure Cybersecurity (‘‘NIST follow industry adopted standards and best not. Although the DCO rule does not have
Framework’’).2 practices. I believe this approach recognizes such a concept, I understand from our
I was also an early proponent of including the rapid evolution of cyber threats and will Division of Clearing and Risk that they are
all registered entities, including SEFs, in this allow DCOs the flexibility to continually willing to discuss the concerns of smaller
rule. I am glad to see them included, and update their cyber defenses in response to DCOs. I encourage those DCOs to raise their
look forward to the staff roundtable to these threats. I also recognize that the final concerns with the Division and encourage
discuss how to apply heightened standards to rule addresses my concern that being hacked the Division to act with appropriate
the significant SEFs. Thank you and I look by itself cannot be considered a rule violation practicality.
forward to the staff’s presentation. subject to enforcement. The final rule I note approvingly that the Commission
clarifies that the Commission it is not seeking has alleviated some burdens from the
Appendix 4—Statement of to hold DCOs strictly liable for being
Commissioner J. Christopher Giancarlo proposed rulemaking such as increasing the
attacked. frequency of key controls testing from two
Good regulation should be balanced. It While the final rule generally takes the years to three years, removing the
should have a positive impact on the right approach, I am concerned about its cost
requirement for independent contractors to
marketplace while mitigating costs to the on smaller DCOs. I have expressed my
conduct vulnerability testing and removing
extent possible. I believe today’s system concern about the cost of regulation on
the explicit requirement for authenticated
safeguards final rule for derivatives clearing smaller market participants on numerous
past occasions.2 One commenter to this scanning, among other requirements.
organizations (DCOs) generally achieves such I support the final DCO system safeguards
balance although I have concerns about the rulemaking noted that its costs will likely
increase two to three times if these rules are rule despite concerns about its costs.
cost impact on smaller DCOs.
finalized as proposed.3 The independent Although I would have preferred that the rule
As I have said, cyber and system security
is one of the most important issues facing contractor and employee testing requirement take a less one-size-fits-all approach, I am a
markets today in terms of integrity and is especially costly for these small DCOs. firm supporter of effective cyber and system
financial stability.1 Given its importance, it is While the parallel designated contract market security policies and procedures given the
right that the Commission implements rules (DCM) system safeguards rulemaking serious threat that cyber belligerents pose. I
requiring DCOs and other registrants to addresses this cost concern through the commend staff for their hard work and
conduct regular testing of their systems. I am generally practical approach to system
2 See e.g., Regulation Automated Trading, 80 FR safeguards for DCOs. I also appreciate that
2 Id.See also NIST Framework, Subcategory 78824, 78946 (Dec. 17, 2015); Guest Lecture of they responded to many comments in an
PR.IP–10, at 28, and Category DE.DP, at 31, Commissioner J. Christopher Giancarlo, Harvard effort to reduce some of the burdens of the
available at http://www.nist.gov/cyberframework/ Law School, Fidelity Guest Lecture Series on final rule. I therefore vote to adopt this rule.
upload/cybersecurity-framework-021214.pdf. International Finance, Dec. 1, 2015.
1 System Safeguards Testing Requirements, 80 FR 3 Minneapolis Grain Exchange, Inc. Comment [FR Doc. 2016–22413 Filed 9–16–16; 8:45 am]
80140, 80190–191 (Dec. 23, 2015). Letter at 13, Feb. 22, 2016. BILLING CODE 6351–01–P
asabaliauskas on DSK3SPTVN1PROD with RULES
VerDate Sep<11>2014 20:52 Sep 16, 2016 Jkt 238001 PO 00000 Frm 00020 Fmt 4701 Sfmt 9990 E:\FR\FM\19SER3.SGM 19SER3](https://thefederalregister.org/doc/81_FR_64502/page/20.svg)
Document Created: 2016-09-17 02:30:05
Document Modified: 2016-09-17 02:30:05
| Category | Regulatory Information | |
| Collection | Federal Register | |
| sudoc Class | AE 2.7: GS 4.107: AE 2.106: | |
| Publisher | Office of the Federal Register, National Archives and Records Administration | |
| Section | Rules and Regulations | |
| Action | Final rule. | |
| Contact | Eileen A. Donovan, Deputy Director, 202-418-5096, [email protected], Division of Clearing and Risk, Commodity Futures Trading Commission, Three Lafayette Centre, 1155 21st Street NW., Washington, DC 20581; or Julie A. Mohr, Deputy Director, (312) 596-0568, [email protected]; Tad Polley, Associate Director, (312) 596-0551, [email protected]; or Scott Sloan, Attorney-Advisor, (312) 596-0708, [email protected], Division of Clearing and Risk, Commodity Futures Trading Commission, 525 West Monroe Street, Chicago, Illinois 60661. | |
| FR Citation | 81 FR 64321 | |
| RIN Number | 3038-AE29 | |
| CFR Associated | Commodity Futures; Reporting and Recordkeeping Requirements and System Safeguards |
2025 Federal Register | Disclaimer | Privacy Policy
USC | CFR | eCFR