Commodity Futures Trading Commission: Vol. 80 Wednesday, No. 246 December 23, 2015

Vol.
80
Wednesday,
No. 246
December 23, 2015
Part IV
Commodity Futures Trading Commission
asabaliauskas on DSK5VPTVN1PROD with PROPOSALS
17 CFR Part 39
System Safeguards Testing Requirements for Derivatives Clearing
Organizations; Proposed Rule
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
PO 00000
Frm 00001
Fmt 4717
Sfmt 4717
E:\FR\FM\23DEP3.SGM
23DEP3
80114
Federal Register / Vol. 80, No. 246 / Wednesday, December 23, 2015 / Proposed Rules
COMMODITY FUTURES TRADING

COMMISSION
17 CFR Part 39
RIN 3038AE29
System Safeguards Testing

Requirements for Derivatives Clearing
Organizations
Commodity Futures Trading
Commission.
ACTION: Notice of proposed rulemaking.
AGENCY:
The Commodity Futures

Trading Commission (Commission) is
proposing enhanced requirements for a
derivatives clearing organizations
testing 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: Comments must be received by
February 22, 2016.
ADDRESSES: You may submit comments,
identified by RIN 3038AE29, by any of
the following methods:
CFTC Web site: http://
comments.cftc.gov. Follow the
instructions for submitting comments
through the Comments Online process
on the Web site.
Mail: Send to Christopher
Kirkpatrick, Secretary of the
Commission, Commodity Futures
Trading Commission, Three Lafayette
Centre, 1155 21st Street NW.,
Washington, DC 20581.
Hand Delivery/Courier: Same as
Mail, above.
Federal eRulemaking Portal: http://
www.regulations.gov. Follow the
instructions for submitting comments.
Please submit your comments using
only one method. All comments must be
submitted in English, or if not,
accompanied by an English translation.
Comments will be posted as received to
http://www.cftc.gov. You should submit
only information that you wish to make
available publicly. If you wish the
Commission to consider information
that may be exempt from disclosure
under the Freedom of Information Act,
a petition for confidential treatment of
the exempt information may be
submitted under 145.9 of the
Commissions regulations (17 CFR
145.9).
The Commission reserves the right,
but shall have no obligation, to review,
pre-screen, filter, redact, refuse or
remove any or all of your submission
from http://www.cftc.gov that it may
deem to be inappropriate for
publication, such as obscene language.
SUMMARY:
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
All submissions that have been redacted

or removed that contain comments on
the merits of the rulemaking will be
retained in the public comment file and
will be considered as required under the
Administrative Procedure Act and other
applicable laws, and may be accessible
under the Freedom of Information Act.
FOR FURTHER INFORMATION CONTACT:
Eileen A. Donovan, Deputy Director,
2024185096, [email protected]; M.
Laura Astrada, Associate Director, 202
4187622, [email protected]; or Eileen
Chotiner, Senior Compliance Analyst,
(202) 4185467, [email protected], in
each case, at the 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) 5960568, jmohr@
cftc.gov; or Joseph Opron, Special
Counsel, (312) 5960653, jopron@
cftc.gov, in each case, at the 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 derivatives
clearing organization (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 DCOs
system safeguards.3 In 2013, the
Commission adopted additional
standards 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).
Regulation 39.18 implements Core
Principle I and, among other things,
specifies: (1) The requisite elements,
standards, and resources of a DCOs
program of risk analysis and oversight
17
U.S.C. 7a1.
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 DCOs operations
and the fulfillment of each of its obligations and
responsibilities; and (3) periodically conduct tests
to verify that the DCOs backup resources are
sufficient.
2 Derivatives
PO 00000
Frm 00002
Fmt 4701
Sfmt 4702
with respect to its operations and

automated systems; (2) the requirements
for a DCOs 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 DCOs clearing
members and service providers. As
discussed below, the Commission is
proposing clarifications and enhanced
requirements for a DCOs testing of its
system safeguards, as well as additional
amendments to reorder and renumber
certain paragraphs and make other
minor changes to improve the clarity of
the rule text. The Commission is also
proposing corresponding technical
corrections to 39.34.
B. Escalating and Evolving
Cybersecurity Threats
Recent studies have identified a
consistent, growing cybersecurity threat
to the financial sector. A survey of 46
global securities exchanges conducted
by the International Organization of
Securities Commissions (IOSCO) and
the World Federation of Exchanges
(WFE) found that as of July 2013, over
half of exchanges worldwide had
experienced a cyber attack during the
previous year.4 Indeed, cybersecurity
now ranks as the number one concern
for nearly half of financial institutions
in the United States.5 Further, the sheer
volume of cyber attacks today is
remarkable. The annual
Pricewaterhouse Coopers Global State of
Information Security Survey (PWC
Survey) for 2015, which included
9,700 participants, found that the total
number of security incidents detected in
2014 increased by 48% over 2013, for a
total of 42.8 million incoming attacks,
the equivalent of more than 117,000
attacks per day, every day.6 As the PWC
Survey pointed out, these numbers do
not include undetected attacks.
Verizons 2015 Data Breach
Investigations Report noted that during
4 OICVIOSCO and WFE, Cyber-crime, securities
markets and systemic risk, Staff Working Paper
(SWP2/2013), July 16, 2013 (IOSCOWFE Staff
Report), p. 3, available at: https://www.iosco.org/
library/pubdocs/pdf/IOSCOPD460.pdf.
5 Depository Trust & Clearing Corporation,
Systemic Risk Barometer Study, Q1 2015, p. 1,
available at: http://dtcc.com//media/Files/pdfs/
Systemic-Risk-Report-2015-Q1.pdf.
6 Pricewaterhouse Coopers, Managing Cyber Risks
in an Interconnected World: Key Findings from the
Global State of Information Security Survey 2015,
Sept. 30, 2014, p. 7, available at: www.pwc.com/
gsiss2015.
E:\FR\FM\23DEP3.SGM
23DEP3
2014, the financial services sector

experienced an average of 350 malware
attacks per week.7
Concerned about these developments,
in March 2015, Commission staff held a
Roundtable on Cybersecurity and
System Safeguards Testing (CFTC
Roundtable) to, among other things,
discuss the issue and identify critical
areas of concern.8 Similarly, a June 2015
Market Risk Advisory Committee
(MRAC) meeting focused on
cybersecurity. Commissioner Sharon
Bowen, the sponsor of MRAC, noted
that cyber attacks on U.S. businesses
have been alarmingly increasing and
stated that its critical that the financial
industry have strong protections in
place. 9
Experts have identified a number of
important topics surrounding
cybersecurity that financial institutions
should take into consideration. First, the
financial sector is facing increasing
numbers of more dangerous cyber
adversaries, with expanding and
worsening motivations and goals.10
Until recently, most cyber attacks on
financial sector institutions were
conducted by criminals whose aim was
monetary theft or fraud.11 While such
attacks continue, recently there has been
a rise in attacks by politically motivated
hacktivists or terrorists, and by statesponsored intruders, aimed at
disruption of their targets operations;
theft of data or intellectual property;
extortion, cyber espionage, corruption
or destruction of data; and degradation
or destruction of automated systems.12
IOSCO and the WFE note that attacks on
securities exchanges now tend to be
disruptive in nature, which suggests a
shift in motive for cyber-crime in
securities markets, away from financial
gain and towards more destabilizing
aims. 13
Second, financial institutions face
increasing cyber capabilities from both
non-state actors and state-sponsored
intruders. For example, there has been
an increase in sophistication on the part
of most actors in the cyber arena, both
7 Verizon, 2015 Data Breach Investigations
Report, p. 21, available at: http://
www.verizonenterprise.com/DBIR/2015/.
8 See generally CFTC Staff Roundtable on
Cybersecurity and System Safeguards Testing,
Transcript, Mar. 18, 2015 (CFTC Roundtable), pp.
1191, available at: http://www.cftc.gov/ucm/
groups/public/@newsroom/documents/file/
transcript031815.pdf.
9 See Market Risk Advisory Committee Meeting,
Transcript, June 2, 2015, p. 6, available at: http://
www.cftc.gov/ucm/groups/public/@aboutcftc/
documents/file/mrac_060215_transcript.pdf.
10 CFTC Roundtable, supra note 8, at 2224.
11 Id. at 1824, 4243.
12 Id. at 12, 1415, 1724, 4244, 47.
13 IOSCOWFE Staff Report, supra note 4, at 3
4.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
in terms of technical capability and the

capacity to organize and carry out
attacks.14
Third, the financial sector is
experiencing an increase in the duration
of cyber attacks.15 While attacks aimed
at monetary theft or fraud tend to
manifest themselves quickly, todays
more sophisticated attacks may involve
cyber adversaries having a presence
inside a targets automated systems for
an extended period of time, while
avoiding detection.16
Fourth, financial institutions face a
broadening cyber threat field. They
must consider cyber vulnerabilities not
only with respect to desktop computers
and their own automated systems, but
also with respect to mobile devices and
data in the cloud.17 Further, adequate
risk analysis must address not just the
vulnerabilities of the entitys automated
systems, but also the human
vulnerabilities posed by social
engineering 18 or disgruntled
employees.19 Notably, todays cyber
threat environment also includes
automated systems that are not directly
internet-facing.20 For example, internetfacing corporate information technology
and non-internet-facing operations
technology can be, and often are,
connected for maintenance purposes or
in error.21 Non-internet-facing systems
are also vulnerable to insertion of
malware-infected removable media,
14 Statement of Mr. Michael Daniel, White House
Cybersecurity Coordinator, CFTC Roundtable, supra
note 8, at 2123.
15 Id. at 77, 8283.
16 IOSCO and the WFE noted in 2013: The rise
of a relatively new class of cyber-attack is especially
troubling. This new class is referred to as an
Advanced Persistent Threat (APT). . . . [APTs]
are usually directed at business and political targets
for political ends. APTs involve stealth to
persistently infiltrate a system over a long period
of time, without the system displaying any unusual
symptoms. IOSCOWFE Staff Report, supra note
4, at 3.
17 CFTC Roundtable, supra note 8, at 22.
18 In a social engineering attack, an attacker uses
human interaction (social skills) to obtain or
compromise information about an organization or
its computer systems. An attacker may seem
unassuming and respectable, possibly claiming to
be a new employee, repairperson, or researcher and
even offering credentials to support that identity.
However, by asking questions, he or she may be
able to piece together enough information to
infiltrate an organizations network. If an attacker is
not able to gather enough information from one
source, he or she may contact another source within
the same organization and rely on the information
from the first source to add to his or her
credibility. See U.S. Computer Emergency
Readiness Team, Dept of Homeland Sec., Security
Tip (ST04014), Avoiding Social Engineering and
Phishing Attacks, available at: https://www.uscert.gov/ncas/tips/ST04-014 (last visited Sept. 14,
2015).
19 CFTC Roundtable, supra note 8, at 14, 7980.
20 Id. at 6070.
21 Id. at 73.
PO 00000
Frm 00003
Fmt 4701
Sfmt 4702
80115
phishing attacks, and other social

engineering techniques, and to supplychain risk involving both hardware and
software.22
Finally, financial institutions cannot
achieve cyber resilience by addressing
threats to themselves alone: They also
face threats due to the increasing
interconnectedness of financial services
firms.23 As such, a financial entitys risk
assessments need to consider
cybersecurity across the breadth of the
financial sector, from exchanges and
clearing organizations to counterparties
and customers, technology providers,
other third party service providers, and
the businesses and products in the
entitys supply chain.24
C. Need for Cybersecurity Testing
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.
An entitys testing should be informed
by how its controls and
countermeasures stack up against the
techniques, tactics, and procedures used
by its potential attackers.25 Adequate
testing needs to include periodic risk
assessments made in light of changing
business conditions, the changing threat
landscape, and changes to automated
systems. It also needs to include
recurring tests of controls and
automated system components to verify
their effectiveness and operability, as
well as continuous monitoring and
scanning of system operation and
vulnerabilities. Testing should include a
focus on the entitys ability to detect,
contain, respond to, and recover from
cyber attacks within its systems, not just
on its defenses designed to prevent
intrusions.26 This should include
detection, containment, and recovery
from compromise of data integrity
perhaps the greatest threat with respect
to financial sector datain addition to
addressing compromise of data
availability or confidentiality, which
tend to be the main focus of many best
22 Id.
at 6266, 7779.
at 2526.
24 Id. at 4857.
25 Id. at 4546.
26 Id. at 8084.
23 Id.
E:\FR\FM\23DEP3.SGM
23DEP3
80116
practices.27 Finally, both internal testing

by the entity itself and independent
testing by third party service providers
are essential components of an adequate
testing regime.28
Cybersecurity testing is a wellestablished best practice generally and
for financial sector entities. The Federal
Information Security Management Act
(FISMA), which is a source of
cybersecurity best practices and also
establishes legal requirements for
federal government agencies, calls for
periodic testing and evaluation of the
effectiveness of information security
policies, procedures, and practices, to
be performed with a frequency
depending on risk, but no less than
annually. . . . 29 The National
Institute of Standards and Technology
(NIST) Framework for Improving
Critical Infrastructure Cybersecurity
calls for testing of cybersecurity
response and recovery plans and
cybersecurity detection processes and
procedures.30 The Financial Industry
Regulatory Authority (FINRA) 2015
Report on Cybersecurity Practices notes
that [r]isk assessments serve as
foundational tools for firms to
understand the cybersecurity risks they
face across the range of the firms
activities and assets, and calls for firms
to develop, implement, and test
cybersecurity incident response plans.31
FINRA notes that one common
deficiency with respect to cybersecurity
is failure to conduct adequate periodic
cybersecurity assessments. 32 The
Council on Cybersecuritys Critical
Security Controls for Effective Cyber
Defense (the Controls) call for entities
to [c]ontinuously acquire, assess, and
take action on new information in order
to identify vulnerabilities, remediate,
and minimize the window of
opportunity for attackers. 33 The
Controls further state that
[o]rganizations that do not scan for
27 Id.
28 Id.
at 1516, 65, 7174, 8283.

at 8990, 101108, 167168, 172173, 244
253.
29 44
U.S.C. 3544(b)(5).
Framework for Improving Critical
Infrastructure Cybersecurity, Feb. 2014, v.1,
Subcategory PR.IP10, p. 28, and Category DE.DP,
p. 31, available at: http://www.nist.gov/
cyberframework/upload/cybersecurity-framework021214.pdf.
31 FINRA, Report on Cybersecurity Practices, Feb.
2015 (FINRA Report), pp. 12, available at:
https://www.finra.org/sites/default/files/p602363
%20Report%20on%20Cybersecurity%20
Practices_0.pdf.
32 Id. at 8.
33 Council on Cybersecurity, The Critical Security
Controls for Effective Cyber Defense, v. 5.1
(Council on Cybersecurity), p. 28, available at:
http://www.counciloncybersecurity.org/bcmsmedia/Files/Download?id=a52977d7-a0e7-462ea4c0-a3bd01512144.
30 NIST,
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
vulnerabilities and proactively address

discovered flaws face a significant
likelihood of having their computer
systems compromised. 34 The Controls
also call for entities to [t]est the overall
strength of an organizations defenses
(the technology, the processes, and the
people) by simulating the objectives and
actions of an attacker. 35 The Controls
recommend conducting regular
external and internal penetration tests to
identify vulnerabilities and attack
vectors that can be used to exploit
enterprise systems successfully, from
both outside and inside the boundaries
of the organizations network
perimeter,36 and also call for use of
vulnerability scanning and penetration
testing in concert.37
The Federal Financial Institutions
Examination Council (FFIEC),38
another important source of
cybersecurity best practices for financial
sector entities, summarized the need for
cybersecurity testing in todays cyber
threat environment:
Financial institutions should have a testing
plan that identifies control objectives;
schedules tests of the controls used to meet
those objectives; ensures prompt corrective
action where deficiencies are identified; and
provides independent assurance for
compliance with security policies. Security
tests are necessary to identify control
deficiencies. An effective testing plan
identifies the key controls, then tests those
controls at a frequency based on the risk that
the control is not functioning. Security
testing should include independent tests
conducted by personnel without direct
responsibility for security administration.
Adverse test results indicate a control is not
functioning and cannot be relied upon.
Follow-up can include correction of the
specific control, as well as a search for, and
correction of, a root cause. Types of tests
include audits, security assessments,
vulnerability scans, and penetration tests.39
Some experts further note that

cybersecurity testing may become a
requirement for obtaining cyber
insurance. Under such an approach,
insurance coverage might be
conditioned on cybersecurity testing
and assessment, followed by
34 Id.
35 Id.
at 102.
36 Id.
37 Id.
at 103.
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.
39 See FFIEC, E-Banking Booklet: IT Examination
Handbook, Aug. 2003, p. 30, available at: http://
ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_
E-Banking.pdf.
38 The
PO 00000
Frm 00004
Fmt 4701
Sfmt 4702
implementation of appropriate
prevention and detection procedures.40
Cybersecurity testing is also
supported internationally. IOSCO has
emphasized the importance of testing to
ensure effective controls, in light of
risks posed by the complexity of
markets caused by technological
advances.41 According to IOSCO,
regulatory authorities have also
recognized the need for [t]rading
[v]enues to appropriately monitor
critical systems and have appropriate
control mechanisms in place. 42
Similarly, the European Securities and
Markets Authority (ESMA) guidelines
for automated trading systems call for
trading platforms to test trading systems
and system updates to ensure that
systems meet regulatory requirements,
that risk management controls work as
intended, and that the systems can
function effectively in stressed market
conditions.43 Further, the Principles for
Financial Market Infrastructures
published by the Bank for International
Settlements Committee on Payments
and Market Infrastructures (CPMI)
and IOSCOs Technical Committee
(together, CPMIIOSCO) note that
with respect to operational risks, which
include cyber risk, [a financial market
infrastructure]s arrangements with
participants, operational policies, and
operational procedures should be
periodically, and whenever necessary,
tested and reviewed, especially after
significant changes occur to the system
or a major incident occurs. . . . 44 The
Commission also notes that
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. Finally, the
Commission notes that this requirement
must be satisfied by following, at a
40 See PricewaterhouseCoopers, Insurance 2020
and Beyond: Reaping the Dividends of Cyber
Resilience, 2015, available at: http://www.pwc.com/
gx/en/insurance/publications/assets/reapingdividends-cyber-resilience.pdf.
41 IOSCO Consultation Report, Mechanisms for
Trading Venues to Effectively Manage Electronic
Trading Risks and Plans for Business Continuity,
Apr. 2015, p. 3, available at: https://www.iosco.org/
library/pubdocs/pdf/IOSCOPD483.pdf.
42 Id. at 9.
43 ESMA, Guidelines: Systems and controls in an
automated trading environment for trading
platforms, investment firms and competent
authorities, Feb. 24, 2012, p. 7, available at: http://
www.esma.europa.eu/system/files/
esma_2012_122_en.pdf.
44 CPMIIOSCO, Principles for Financial Market
Infrastructures, Apr. 2012, at 96, available at: http://
www.iosco.org/library/pubdocs/pdf/
IOSCOPD377.pdf. See also CPMI, Cyber resilience
in financial market infrastructures, Nov. 2014,
available at: http://www.bis.org/cpmi/publ/
d122.pdf.
E:\FR\FM\23DEP3.SGM
23DEP3
minimum, generally accepted standards
and industry best practices.45 As further
explained below, the proposed rules
would clarify existing system safeguards
requirements by identifying relevant
generally accepted standards and
industry best practices. With few
exceptions, such as requirements for
independent contractors to conduct
certain testing, the Commission is not
changing the regulatory requirement for
DCOs as it exists today.
II. Proposed Amendments

A. Enhanced Testing Requirements
As discussed above, 39.18 requires a
DCO to establish and maintain a
automated systems. As part of this
program, a DCO is required 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. DCOs
are specifically required, under
39.18(d), to follow generally accepted
standards and industry best practices
with respect to the development,
operation, reliability, security, and
capacity of automated systems in
addressing the categories of risk analysis
and oversight specified in 39.18. As
discussed in the Commissions
proposing release for 39.18, DCO
compliance with generally accepted
standards and best practices with
respect to the development, operation,
reliability, security, and capacity of
automated systems can reduce the
frequency and severity of automated
system security breaches or functional
failures, thereby augmenting efforts to
mitigate systemic risk. 46 This
requirement was further designed to
allow DCOs flexibility in adapting their
programs to current industry best
practices, which the Commission
recognized would evolve over time.
Similarly, the additional testing
provisions that the Commission is
proposing have been constructed to set
forth certain minimum requirements,
with the expectation that DCOs testing
may change as accepted standards and
industry best practices develop over
time and are reflected in the DCOs risk
analysis.
Specifically, the Commission is
proposing to strengthen the current
system safeguards regulatory framework
45 For
a more detailed discussion of current

testing requirements for DCOs, please see the
System Safeguards Requirements for DCOs in
section I.A. above and the Consideration of Costs
and Benefits in section IV.C. below.
46 See Risk Management Requirements for
Derivatives Clearing Organizations, 76 FR 3698,
3713 (Jan. 20, 2011).
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
by specifying five fundamental types of

systems testing and assessment that are
required under 39.18. The
Commission is proposing to require that
these types of testing and assessment be
conducted at a frequency determined by
an appropriate risk analysis, but no less
frequently than a proposed minimum,
which varies based on the particular
type of testing or assessment. To
strengthen the objectivity and reliability
of the testing, assessment, and
information available to the
Commission in this regard, the
Commission is proposing to require that
independent contractors perform a
significant portion of the testing and
assessment. In developing these
requirements, the Commission has
relied on various industry standards and
best practices for assessment of
information security systems, which are
referenced in the following discussion.
The Commission has not proposed a
definition of the term independent
contractor. Proposed definitions of
terms related to the proposed testing
requirements are discussed in the
respective section setting forth each
proposed testing requirement.
1. Vulnerability Testing
Identification of cyber and automated
system vulnerabilities is a critical
component of a DCOs ongoing
assessment of risks to its systems. NIST
standards call for organizations to scan
for automated system vulnerabilities
both on a regular and ongoing basis, and
when new vulnerabilities potentially
affecting their systems are identified
and reported.47 NIST adds that
organizations should employ
vulnerability scanning tools and
techniques that automate parts of the
vulnerability management process.48
NIST also calls for the organization to
remediate vulnerabilities identified by
vulnerability testing, in accordance with
its assessments of risk.49 Similarly, the
Controls recommend that organizations
continuously acquire, assess, and take
action on new information in order to
identify vulnerabilities, remediate, and
minimize the window of opportunity for
attackers. 50
The proposed minimum standards
and frequencies for vulnerability testing
are intended to strengthen a DCOs
systems oversight program.
47 NIST Special Publication 80053, Security and
Privacy Controls for Federal Information Systems
and Organizations, rev. 4 (NIST SP 80053),
Control RA5, available at: http://nvlpubs.nist.gov/
nistpubs/SpecialPublications/NIST.SP.80053r4.pdf.
48 Id.
49 Id.
50 Council on Cybersecurity, supra note 33, at 28.
PO 00000
Frm 00005
Fmt 4701
Sfmt 4702
80117
Accordingly, in 39.18(a) the

Commission is proposing to define
vulnerability testing as the testing of
a DCOs automated systems to
determine what information may be
discoverable through a reconnaissance
analysis of those systems and what
vulnerabilities may be present on those
systems. This definition is consistent
with NIST standards for such testing.51
For purposes of this definition, the term
reconnaissance analysis is used to
combine various aspects of vulnerability
testing.52 The proposed definition
deliberately refers broadly to
vulnerability testing in order to avoid
prescribing use of any particular
technology or tools, because
vulnerability assessments may not
always be automated, and technology
may change.53
Proposed 39.18(e)(2) would also
require that vulnerability testing include
automated vulnerability scanning, as
well as an analysis of the test results to
identify and prioritize all identified
vulnerabilities that require
remediation.54 Moreover, the
Commission recognizes that automated
scans may be authenticated (i.e.,
conducted using usernames or
passwords) or unauthenticated (i.e.,
conducted without using usernames or
51 See
NIST SP 80053, supra note 47, at F153.

e.g., NIST Special Publication 800115,
Technical Guide to Information Security Testing
and Assessment, Sept. 2008 (NIST SP 800115),
p. 24, available at: http://csrc.nist.gov/publications/
nistpubs/800-115/SP800-115.pdf (noting that
[e]xternal testing often begins with reconnaissance
techniques that search public registration data,
Domain Name System (DNS) server information,
newsgroup postings, and other publicly available
information to collect information (e.g., system
names, Internet Protocol [IP] addresses, operating
systems, technical points of contact) that may help
the assessor to identify vulnerabilities).
53 See SANS Institute, Penetration Testing:
Assessing Your Overall Security Before Attackers
Do, p. 7, available at: https://www.sans.org/readingroom/whitepapers/analyst/penetration-testingassessing-security-attackers-34635 (last visited
Sept. 30, 2015) (noting, A wide variety of tools
may be used in penetration testing. These tools are
of two main types; reconnaissance or vulnerability
testing tools and exploitation tools. While
penetration testing is more directly tied to the
exploitation tools, the initial scanning and
reconnaissance is often done using less intrusive
tools.).
54 See Security Standards Council, Payment Card
Industry Data Security Standards, Apr. 2015, v. 3.1
(PCIDSS), p. 94, available at: https://
www.pcisecuritystandards.org/documents/PCI_DSS
_v3-1.pdf (defining a vulnerability scan as a
combination of automated or manual tools,
techniques, and/or methods run against external
and internal network devices and servers, designed
to expose potential vulnerabilities that could be
found and exploited by malicious individuals).
See also NIST SP 800115, supra note 52, at 22
(noting that testing techniques that include
vulnerability scanning can identify systems, ports,
services, and potential vulnerabilities, and may be
performed manually but are generally performed
using automated tools).
52 See,
E:\FR\FM\23DEP3.SGM
23DEP3
80118
passwords). However, the Commission

proposes requiring that, where indicated
by appropriate risk analysis, a DCO
conduct such scanning on an
authenticated basis.55 Where scanning
is conducted on an unauthenticated
basis, a DCO would be required to
implement effective compensating
controls.56
Furthermore, the Commission is
proposing to require DCOs to conduct
vulnerability testing at a frequency
determined by an appropriate risk
analysis, but no less frequently than
quarterly.57 The Commission notes that
while [t]he frequency of testing should
be determined by the institutions risk
assessment, 58 best practices call for
risk assessments to include
consideration of a number of important
factors, including, for example, the
frequency and extent of changes in the
organizations automated systems and
operating environment; the potential
impact if risks revealed by testing are
not addressed appropriately; the degree
to which the relevant threat
environment or potential attacker
profiles and techniques are changing;
and the results of other testing.59
Frequency appropriate to risk analysis
can also vary depending on the type of
monitoring involved; for example, with
whether automated monitoring or
procedural testing is being conducted.60
Nonetheless, the Commission notes that
the PCIDSS standards provide that
55 See Securities Standards Council, The PCI
Monitor: Weekly news, updates and insights from
PCI SSC, June 25, 2014, available at: http://
training.pcisecuritystandards.org/the-pci-monitorweekly-news-updates-and-insights-from-pcissc2?ecid=ACsprvuuirRbrU3vDlk76s_
ngGKJKEYlvaBJzvvUMldZv4KKh6V1guIKOR5VL
TNfAqPQ_Gmox3zO&utm_campaign=Monitor&
utm_source=hs_email&utm_medium=email&utm_
content=13292865&_hsenc=p2ANqtz-_LIkkHURy
Umyq1p2OxB39R5nOpRh1XHE_jW6wCC6EE
UAow15E7AuExcIGwdYxyh_6YNxVvKorcurk6r90
E3d7dG71fbw&_hsmi=13292865#web.
56 See PCIDSS, supra note 54, app. B at 112
(Compensating controls may be considered . . .
when an entity cannot meet a requirement
explicitly as stated, due to legitimate technical or
documented business constraints, but has
sufficiently mitigated the risk associated with the
requirement through implementation of other, or
compensating, controls.).
57 See FFIEC, Information Security Booklet, IT
Examination Handbook, July 2006 (FFIEC
Handbook), p. 82, available at: http://
InformationSecurity.pdf (noting that firewall
policies and other policies addressing access
control between the financial institutions network
and other networks should be audited and verified
at least quarterly).
58 Id.
59 See NIST Special Publication 80039,
Managing Information Security Risk, Mar. 2011
(NIST SP 80039), pp. 4748, available at: http://
csrc.nist.gov/publications/nistpubs/800-39/SP80039-final.pdf; see also FFIEC Handbook, supra note
57, at 82.
60 Id.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
entities should run internal and external

network vulnerability scans at least
quarterly, as well as after any
significant network changes, new
system component installations, firewall
modifications, or product upgrades.61
Because best practices call for
analysis, and call for such testing to be
conducted no less than quarterly, this
proposed rule does not impose new
requirements on DCOs. Rather, it is
designed to give additional clarity to
DCOs concerning what is currently
required under existing regulations. In
light of these best practices and the
current level of cyber threat to the
financial sector discussed above, the
Commission believes that this proposed
rule is appropriate in todays
cybersecurity environment. For the
same reasons, and because the
Commission understands that DCOs
currently conduct vulnerability testing
on at least a quarterly basis and in many
cases more frequently, the Commission
also believes that this minimum
frequency requirement for vulnerability
testing will impose only de minimis
additional costs, if any, on DCOs.
In addition, the proposed rule would
require DCOs to engage independent
contractors to conduct two of the
required quarterly vulnerability tests
each year, while permitting DCOs to
conduct other vulnerability testing
using employees who are not
responsible for development or
operation of the systems or capabilities
being tested. The Commission believes
that important benefits are provided
when a testing program includes both
testing by independent contractors and
testing by entity employees not
responsible for building or operating the
system being tested. While testing needs
to be performed internally, it also needs
to be conducted from the viewpoint of
an outsider, particularly where testing
against the possible tactics or
techniques of a particular threat actor is
concerned.62 For example, entity
employees can use viewpoints that the
outside world would not have, based on
intimate knowledge of the entity.63
Conversely, independent contractors
provide an outsiders perspective, and
may search for vulnerabilities in a
system that entity employees may not
have contemplated during the design or
operation of the system involved.64
61 See Requirement 11.2, PCIDSS, supra note 54,
at 94.
62 See generally CFTC Roundtable, supra note 8,
at 8990.
63 Id. at 178.
64 Id. at 172173.
PO 00000
Frm 00006
Fmt 4701
Sfmt 4702
The Commission also notes that best

practices support having testing
conducted by both independent
contractors and entity employees.
Regarding the benefits provided by
independent contractor testing, NIST
notes that engaging third parties (e.g.,
auditors, contractor support staff) to
conduct the assessment offers an
independent view and approach that
internal assessors may not be able to
provide. Organizations may also use
third parties to provide specific subject
matter expertise that is not available
internally.65 FFIEC states that testing by
independent contractors provides
credibility to test results.66
Acknowledging the use of entity
employees to conduct testing, FFIEC
calls for such tests to be performed by
individuals who are also independent of
the design, installation, maintenance,
and operation of the tested system. 67
Similarly, with respect to system
safeguards testing by internal auditors,
FFIEC further states that the auditors
should have both independence and
authority from the Board of Directors to
access all records and staff necessary for
their audits, and that auditors should
not participate in activities that may
compromise or appear to compromise
their independence.68 Further, the data
security standards of the Payment Card
Industry Security Standards Council
call for conducting both internal and
external vulnerability scans, with
external scans performed by an
approved vendor.69
Accordingly, following consideration
of the recommendations set forth in the
standards mentioned above, the
Commission believes that requiring two
of the four tests to be conducted by
independent contractors is a balanced
approach. Other vulnerability tests may
be performed by employees of the DCO
who are not responsible for
development or operation of the systems
or capabilities being tested. In light of
the best practices and the current level
of cyber threat to the financial sector
discussed above, the Commission
believes that the proposed rule
provisions regarding vulnerability
testing by independent contractors are
65 NIST SP 800115, supra note 52, at 66. NIST
also notes that giving outsiders access to an
organizations systems can introduce additional
risk, and recommends proper vetting and attention
to contractual responsibility in this regard.
66 FFIEC Handbook, supra note 57, at 81.
67 Id.
68 FFIEC, Audit Booklet: IT Examination
Handbook, Apr. 2012, p.6, available at: http://
Audit.pdf.
69 See Requirement 11, PCIDSS, supra note 54,
at 9496.
E:\FR\FM\23DEP3.SGM
23DEP3
the potential damage this type of
attacker could cause.76
In addition, generally accepted
2. Penetration Testing
standards and industry best practices
support annual penetration testing. For
Though complementary to
vulnerability testing, penetration testing example, NIST calls for at least annual
differs from vulnerability testing in that penetration testing of an organizations
network and systems.77 Moreover, the
its purpose is to identify ways that the
vulnerabilities identified above could be FFIEC calls for independent penetration
exploited.70 In other words, penetration testing of high risk systems at least
annually, and for quarterly testing and
testing attempts to exploit cyber and
verification of the efficacy of firewall
automated system vulnerabilities, and
78
subjects the system to real-world attacks and access control defenses. Data
security
standards
for
the
payment
card
by testing personnel in order to identify
industry provide that entities should
both the extent to which an attacker
could compromise the system before the perform both external and internal
penetration testing at least annually, as
organization detects and counters the
well as after any significant network
attack, and the effectiveness of the
changes, new system component
organizations response mechanisms.71
installations, firewall modifications, or
NIST defines penetration testing as
product upgrades.79
[a] test methodology in which
The primary benefit of a penetration
assessors, typically working under
test is that it identifies the extent to
specific constraints, attempt to
which a system can be compromised
circumvent or defeat the security
before the attack is identified and
72
features of an information system. As assesses the effectiveness of the
noted in the FINRA Report, [a]n
response mechanism.80 Accordingly,
advanced persistent attack may involve
the Commission is proposing to require
an outsider gaining a progressively
both external and internal penetration
greater foothold in a firms environment, testing. In 39.18(a), the Commission
effectively becoming an insider in the
proposes to define external penetration
process. For this reason, it is important
testing as attempts to penetrate a
to perform penetration testing against
DCOs automated systems or networks
both external and internal interfaces and from outside the system and network
systems. 73 As further explained,
boundaries to identify and exploit
external security testing is conducted
vulnerabilities (including, but not
from outside the organizations security limited to, methods for circumventing
perimeter[, which] offers the ability to
the security features of an application,
view the environments security posture system, or network).81 Proposed
as it appears outside the security
39.18(e)(3) would require external
perimeterusually as seen from the
penetration testing to be conducted at a
Internetwith the goal of revealing
frequency determined by an appropriate
vulnerabilities that could be exploited
risk analysis, but no less frequently than
by an external attacker. 74 Internal
annually.82 The Commission proposes
penetration testing, on the other hand,
to define internal penetration testing
is conducted from the internal network in 39.18(a) as attempts to penetrate a
and [assessors] assume the identity of a
DCOs automated systems or networks
trusted insider or an attacker who has
from inside the system and network
penetrated the perimeter defenses. 75
Internal penetration testing can
76 See NIST SP 800115, supra note 52, at 25.
therefore reveal vulnerabilities that
77 Id. at 56.
could be exploited, and demonstrates
appropriate in todays cybersecurity
environment.
78 FFIEC
70 See
Security Standards Council, PCIDSS

Information Supplement: Penetration Testing
Guidance, Mar. 2015 (PCIDSS Penetration
Testing), p. 3, available at: https://
www.pcisecuritystandards.org/documents/
Penetration_Testing_Guidance_March_2015.pdf.
71 See FFIEC Handbook, supra note 57, at 81.
72 NIST SP 80053, supra note 47, app. B at B
16.
73 FINRA Report, supra note 31, at 22.
74 NIST SP 800115, supra note 52, at 24.
75 Id. at 25. See also, e.g., SANS, Penetration
Testing in the Financial Services Industry, 2010, p.
17, available at: https://www.sans.org/readingroom/whitepapers/testing/penetration-testingfinancial-services-industry-33314 (Penetration
testing is essential given the context of high
operational risk in the financial services
industry.).
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
Handbook, supra note 57, at 82.

Requirements 11.3.1 and 11.3.2, PCIDSS,
supra note 54.
81 See NIST SP 80053, supra note 47, app. B at
B16 (defining penetration testing as [a] test
methodology in which assessors, typically working
under specific constraints, attempt to circumvent or
defeat the security features of an information
system); see also NIST Special Publication 800
137, Information Security Continuous Monitoring
for Federal Information Systems and Organizations,
Sept. 2011 (NIST SP 800137), app. B, p. B10,
available at: http://csrc.nist.gov/publications/
nistpubs/800-137/SP800-137-Final.pdf.
82 See PCIDSS Penetration Testing, supra note
70, at 8 (noting that [p]enetration testing should be
performed at least annually and after any significant
changefor example, infrastructure or application
upgrade or modificationor new system
component installations).
79 See
PO 00000
Frm 00007
Fmt 4701
Sfmt 4702
80119
vulnerabilities (including, but not

limited to, methods for circumventing
the security features of an application,
system, or network).83 In 39.18(e)(4),
the Commission also proposes to require
that internal penetration testing be
conducted at a frequency determined by
an appropriate risk analysis, but no less
frequently than annually.
As discussed above, the Commission
notes that generally accepted standards
and industry best practices require
annual penetration testing. Moreover,
DCOs currently are required to follow
industry best practices, which support a
minimum frequency of annually for
internal penetration testing, and as
discussed in more detail in the CostBenefit Analysis in Section IV.C. below,
DCOs are conducting penetration testing
on at least an annual basis. However,
the Commission acknowledges that
Securities and Exchange Commission
(SEC) Regulation SCI, which is
applicable to DCOs that are registered
with the SEC as clearing agencies,84
requires that penetration testing be
conducted every three years.85
Nonetheless, given the importance of
DCOs to the U.S. financial system, the
Commission believes that annual
internal penetration testing is
appropriate in order to sufficiently
address risks to a DCOs systems.
In addition, and consistent with
industry best practices, proposed
39.18(e)(3) would require DCOs to
engage independent contractors to
perform the required annual external
penetration tests. Independent testing
provides for impartiality, meaning that
penetration testers are free from
conflicts of interest with respect to the
development, operation, or management
of the system(s) that are the targets of
the testing.86 The Commission believes
that the impartiality provided by
independent contractors, including their
lack of a stake in the outcome, is an
83 Id.
at 2.
the 15 DCOs currently registered with the
Commission, four also are registered with the SEC
as clearing agencies: Chicago Mercantile Exchange,
Inc. (CME), ICE Clear Credit LLC, ICE Clear
Europe Limited, and Options Clearing Corporation.
However, on August 3, 2015, CME filed with the
SEC a written request to withdraw from registration
as a clearing agency. See Securities Exchange Act
Release No. 3475762 (Aug. 26, 2015), 80 FR 52815
(Sept. 1, 2015).
85 17 CFR 240.1003. The SEC noted in its
adopting release that SCI entities may, however,
determine that based on its [sic] risk assessment, it
is appropriate and/or necessary to conduct such
penetration test reviews more frequently than once
every three years. Regulation Systems Compliance
and Integrity, 79 FR 72252, 72344 (Dec. 5, 2014).
86 NIST SP 80053, supra note 47, app. FCA at
F62.
84 Of
E:\FR\FM\23DEP3.SGM
23DEP3
80120
important factor in conducting external

penetration testing and enhances the
credibility of the test results.87 Proposed
39.18(e)(4) would, however, permit
internal penetration testing to be
conducted by either independent
contractors or employees of the DCO
or capabilities being tested.88
3. Controls Testing
Controls provide reasonable assurance
that security management is effective,
and adequate control testing is therefore
critical to ensuring the confidentiality,
integrity, and availability of information
and information systems.89 Regular,
ongoing testing of all of an
organizations system safeguards-related
controls for these purposes is a crucial
part of a DCOs risk analysis and
oversight program.90
Generally accepted standards and
industry best practices call for
organizations to conduct regular,
ongoing controls testing that over time
includes testing of all their system
safeguards-related controls. For
example, NIST calls for organizations to
assess the security controls in the
information system and its environment
of operation to determine the extent to
which the controls are implemented
correctly, operating as intended, and
producing the desired outcome with
respect to meeting established security
requirements. 91 NIST notes that the
results of such testing can allow
organizations to, among other things,
identify potential cybersecurity
problems or shortfalls, identify securityrelated 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.92 FFIEC calls for
controls testing because [c]ontrols
should not be assumed to be completely
effective, and states that a controls
testing program is sound industry
practice and should be based on an
assessment of the risk of non87 FFIEC Handbook, supra note 57, at 81 (noting
that [i]ndependence provides credibility to the test
results).
88 See, e.g., PCIDSS, supra note 54, at 97.
89 See generally U.S. Govt Accountability Office,
GAO09232G, Federal Information System
Controls Audit Manual, Feb. 2009, available at:
http://www.gao.gov/assets/80/77142.pdf.
90 See generally 17 CFR 39.18 and 17 CFR 39.34.
91 NIST SP 80053, supra note 47, app. FCA at
F55.
92 NIST Special Publication 80053A, Assessing
Security and Privacy Controls in Federal
Information Systems and Organizations, rev. 4
(NIST SP 80053A), p. 3, available at: http://
nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-53Ar4.pdf.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
compliance or circumvention of the

institutions controls. 93
Consistent with industry best
practices, the Commission proposes to
define controls testing in 39.18(a) as
an assessment of a DCOs controls to
determine whether such controls are
implemented correctly, are operating as
intended, and are enabling the DCO to
meet the system safeguards
requirements set forth in 39.18.94
Furthermore, the Commission proposes
to define controls as the safeguards or
countermeasures 95 employed by the
DCO in order to protect the reliability,
security, or capacity of its automated
systems or the confidentiality, integrity,
or availability of its data and
information, in order to enable the DCO
to fulfill its statutory and regulatory
responsibilities. Regulation 39.18(a)
would also define key controls as
those controls that an appropriate risk
analysis determines are either critically
important for effective system
safeguards or intended to address risks
that evolve or change more frequently
and therefore require more frequent
review to ensure their continuing
effectiveness in addressing such risks.
In todays cybersecurity threat
environment, the Commission believes
that effective testing of this subset of the
system safeguards controls maintained
by a DCO is particularly important.
In addition, the Commission is
proposing to require controls testing in
39.18(e)(5), which would include
testing of each control included in the
DCOs risk analysis and oversight
program, to be conducted at a frequency
indicated by an appropriate risk
every two years. The Commission
believes that this would ensure that
each such control is tested with
sufficient frequency to confirm the
continuing adequacy of the DCOs
system safeguards. The Commission
recognizes, however, that appropriate
risk analysis may well determine that
more frequent testing of either certain
key controls or all controls is necessary.
The Commission notes that industry
best practices support information
security continuous monitoring
(ISCM), which is defined as
maintaining ongoing awareness of
information security, vulnerabilities,
and threats to support organizational
93 FFIEC

generally NIST SP 80053A, supra note 92.
95 NIST SP 80053, supra note 47, app. B at B
5 (defining countermeasures as [a]ctions,
devices, procedures, techniques, or other measures
that reduce the vulnerability of an information
system. Synonymous with security controls and
safeguards).
94 See
PO 00000
Frm 00008
Fmt 4701
Sfmt 4702
risk management decisions. 96

Nonetheless, recognizing that it is
impractical to test every security control
at all times, these standards note that
[t]he frequency of assessments should
be sufficient to assure adequate security
commensurate with risk, as determined
by system categorization and ISCM
strategy requirements. 97 Thus,
consistent with industry best practices,
the Commission is proposing minimum
frequency for the testing of each control
of no less than every two years.
The Commission also proposes to
permit such testing to be conducted on
a rolling basis over the course of the
period determined by appropriate risk
analysis in recognition of the fact that
an adequate system safeguards program
for a DCO must necessarily include
large numbers of controls, and therefore
it could be impracticable and unduly
burdensome to require testing of all
controls in a single test. This provision
is designed to give a DCO flexibility
concerning how and when to test
controls during the applicable minimum
period, and is intended to reduce
burdens associated with testing every
control to the extent possible while still
safeguarding and managing the DCOs
security.98
The proposed rule would also require
testing of key controls to be conducted
by independent contractors. As noted
above, the Commission believes that the
impartiality and credibility provided by
independent testing supports the
proposed requirement that testing of key
controls be done by independent
contractors. However, the Commission
is proposing to give DCOs the discretion
to test other controls using either
independent contractors or employees
of the DCO who are independent of the
systems being tested.99
4. Security Incident Response Plan
Testing
The Commission recognizes that
adequate cyber resilience requires
organizations to have sufficient capacity
to detect, contain, eliminate, and
recover from a cyber intrusion, and
believes that security incident response
plans,100 and testing of those plans, are
essential to such capabilities.
96 NIST
SP 800137, supra note 81, at vi.

at 11.
98 Id. at 2527.
99 See discussion supra section II.A.1.
100 As discussed in more detail below, the
Commission proposes to define security incident
response plan testing as the testing of a DCOs
security incident response plan to determine the
plans effectiveness, identify potential weaknesses
or deficiencies, enable regular plan updating and
improvement, and maintain organizational
preparedness and resiliency with respect to security
incidents.
97 Id.
E:\FR\FM\23DEP3.SGM
23DEP3
NIST urges organizations to have a

security incident response plan that
establishes procedures to address cyber
attacks against an organizations
information systems. These procedures
are designed to enable security
personnel to identify, mitigate, and
recover from malicious computer
incidents, such as unauthorized access
to a system or data, denial of service, or
unauthorized changes to system
hardware, software, or data (e.g.,
malicious logic, such as a virus, worm,
or Trojan horse). 101
In addition, NIST states that
organizations should test their security
incident response capabilities, at
appropriate frequencies, to determine
their effectiveness, and to document test
results.102
FINRAs best practices also call for
firms to have security incident response
plans. FINRAs 2015 Report on
Cybersecurity Practices states: Firms
should establish policies and
procedures, as well as roles and
responsibilities for escalating and
101 NIST Special Publication 80034, Contingency
Planning Guide for Federal Information Systems,
rev. 1 (NIST SP 80034), p. 10, available at:
http://csrc.nist.gov/publications/nistpubs/800-34rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
Specifically, NIST recommends that an organization
develop, document, and distribute to the
appropriate personnel [a]n incident response
policy that addresses purpose, scope, roles,
responsibilities, management commitment,
coordination among organizational entities, and
compliance, as well as [p]rocedures to facilitate
the implementation of the incident response policy
and associated incident response controls. NIST
SP 80053, supra note 47, at F103. See also NIST
Special Publication 80061, Computer Security
Incident Handling Guide, rev. 2 (NIST SP 800
61), p. 8, available at: http://nvlpubs.nist.gov/
nistpubs/SpecialPublications/NIST.SP.80061r2.pdf. Such incident response plan should:
a. Provide the organization with a roadmap for
implementing its incident response capability;
b. Describe the structure and organization of the
incident response capability;
c. Provide a high-level approach for how the
incident response capability fits into the overall
organization;
d. Meet the unique requirements of the
organization, which relate to mission, size,
structure, and functions;
e. Define reportable incidents;
f. Provide metrics for measuring the incident
response capability within the organization;
g. Define the resources and management support
needed to effectively maintain and mature an
incident response capability; and
h. Be reviewed and approved by [appropriate
organization-defined personnel or roles].
Id. at F109. Finally, copies of the plan should
be distributed to appropriate personnel; reviewed at
an appropriate frequency; updated to address
system or organizational changes, or problems
encountered during plan implementation,
execution, or testing, with plan changes
communicated to appropriate personnel; and
protected from unauthorized disclosure and
modification. Id.
102 NIST SP 80053, supra note 47, app. FIR at
F104.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
responding to cybersecurity incidents.

Effective practices for incident response
include . . . involvement in industrywide and firm-specific simulation
exercises as appropriate to the role and
scale of a firms business. 103 Similarly,
the FFIEC also calls for security incident
response plan testing, stating that
[f]inancial institutions should assess
the adequacy of their preparation by
testing incident response guidelines to
ensure that the procedures correspond
with business continuity strategies. 104
Moreover, the Controls argue that
organizations should protect their
information, as well as their reputations,
by developing and implementing a
security incident response plan,105 and
conduct[ing] periodic incident
scenario sessions for personnel
associated with the incident handling
team, to ensure that they understand
current threats and risks, as well as their
responsibilities in supporting the
incident handling teams. 106
The Commission believes that
industry best practices require the
development, implementation, and
testing of a security incident response
plan.107 Proposed 39.18(e)(6) would
require that DCOs have a security
incident response plan that is tested at
a frequency determined by an
appropriate risk analysis, but no less
frequently than annually. Because
39.18 already calls for a DCOs risk
analysis and oversight program to
follow best practices, this requirement
should not impose any additional
burdens or costs on DCOs. In addition,
the Commission notes that having such
plans regularly tested will help DCOs
address security incidents more quickly
and effectively when they actually
happen. Moreover, the Commission
notes that annual testing is consistent
with industry best practices and an
important part of a DCOs business
continuity and disaster recovery plan.
The proposed rule would define a
security incident as a cybersecurity or
physical security event that actually or
potentially jeopardizes automated
system operation, reliability, security, or
capacity, or the availability,
103 FINRA
Report, supra note 31, at 23.

Business Continuity Planning Booklet:
IT Examination Handbook, Feb. 2015 (FFIEC BCP
Booklet), p. 26, available at: http://
BusinessContinuityPlanning.pdf.
105 Council on Cybersecurity, supra note 33, at 96.
106 Id. at 97.
107 See, e.g., FINRA Report, supra note 31, at 23;
and FFIEC BCP Booklet, supra note 104, at 25
(noting that [e]very financial institution should
develop an incident response policy that is properly
integrated into the business continuity planning
process).
104 FFIEC,
PO 00000
Frm 00009
Fmt 4701
Sfmt 4702
80121
confidentiality, or integrity of data.108

The Commission further proposes
defining a security incident response
plan as a written plan documenting the
DCOs 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. Under the proposed
definition, 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. However,
the Commission proposes requiring the
DCOs security incident response plan
to include the DCOs definition and
classification of security incidents; its
policies and procedures for reporting
security incidents and for internal and
external communication and
information sharing regarding security
incidents; and the hand-off and
escalation points in its security incident
response process.
The Commission proposes to define
security incident response plan
testing in 39.18(a) as the testing of a
DCOs security incident response plan
to determine the plans effectiveness,
identify 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 would not be limited
to, checklist completion, walk-through
or table-top exercises, simulations, and
comprehensive exercises.109 Pursuant to
108 NIST defines an incident as [a]n
occurrence that actually or potentially jeopardizes
the confidentiality, integrity, or availability of an
information system or the information the system
processes, stores, or transmits, or that constitutes a
violation or imminent threat of violation of security
policies, security procedures, or acceptable use
policies. NIST SP 80053, supra note 47, at B9.
NIST further defines a computer security
incident as a violation or imminent threat of
violation of computer security policies, acceptable
use policies, or standard security practices. NIST
SP 80061, supra note 101, at 6. The FFIEC notes
that a security incident represents the attempted
or successful unauthorized access, use,
modification, or destruction of information systems
or customer data. If unauthorized access occurs, the
financial institutions computer systems could
potentially fail and confidential information could
be compromised. FFIEC BCP Booklet, supra note
104, at 25.
109 See NIST SP 80053, supra note 47, app. F
IR at F104 (stating that [i]ncident response testing
includes, for example, the use of checklists, walkthrough or tabletop exercises, simulations (parallel/
full interrupt), and comprehensive exercises.
Incident response testing can also include a
determination of the effects on organizational
E:\FR\FM\23DEP3.SGM
Continued
23DEP3
80122
proposed 39.18(e)(6), a DCO would

also be permitted to coordinate its
with other testing required by proposed
39.18(e),110 or with the testing of its
other business continuity-disaster
recovery and crisis management plans.
In addition, a DCO would be permitted
to conduct security incident response
plan testing by engaging independent
contractors or by using employees of the
DCO who are not responsible for
or capabilities being tested. The
Commission notes that discussion at the
CFTC Roundtable included concerns
about performing tests in a production
environment, as the tests could have the
unintended consequence of disrupting
business as usual and potentially cause
an event.111 Accordingly, the
Commission proposes to give DCOs
discretion to decide whether the testing
is completed in a production or nonproduction environment.
5. Enterprise Technology Risk
Assessment (ETRA)
ETRA is an important part of a DCOs

risk assessment program because it
helps the DCO produce a broad
determination of its system safeguardsrelated risks.112 In a sense, ETRA can be
seen as a strategic approach through
which a DCO identifies risks and aligns
its systems goals accordingly. A wellconducted ETRA, and the knowledge
and prioritization of risks that it
provides, can also inform and guide the
ongoing testing process and result in
more effective cybersecurity risk
management.
The Commission notes that with
respect to ETRA, best practices provide
a number of sources for such risk
assessment frameworks,113 and a DCO
would generally be free to choose the
assessment framework it believes most
appropriate to its particular
circumstances, provided that its choice
is congruent with best practices and is
consistent with the DCOs risk profile.
For example, FINRA notes that
approaches to integrating threats and
vulnerabilities in an overall risk
assessment report often differ, with
some organizations following
proprietary risk assessment
operations (e.g., reduction in mission capabilities),
organizational assets, and individuals due to
incident response).
110 In addition to the changes proposed herein,
the Commission is proposing to renumber 39.18(j)
as 39.18(e).
111 CFTC Roundtable, supra note 8, at 8788, 118,
321326, 345346.
112 NIST SP 80039, supra note 59, at 1.
113 See, e.g., FFIEC Handbook, supra note 57;
NIST SP 80039, supra note 59.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
methodologies and other using vendor

products tailored to their particular
needs, and with firms using a variety of
cyber incident and threat intelligence
inputs for their risk assessments.114
The Commission proposes to define
ETRA in 39.18(a) as a written
assessment that includes, but is not
limited to, an analysis of threats and
vulnerabilities in the context of
mitigating controls. An ETRA identifies,
estimates, and prioritizes risks to a
DCOs operations or assets (which
include, for example, mission,
functions, image, and reputation risks),
or to market participants, individuals,
and other entities, resulting from
impairment of the confidentiality,
integrity, or availability of data and
information or the reliability, security,
or capacity of automated systems.115
Proposed 39.18(e)(7) would provide
DCOs flexibility by permitting the ETRA
to be completed by independent
contractors or employees of the DCO not
being assessed. The proposal would,
however, require an ETRA to be
completed at a frequency determined by
an appropriate risk analysis by the DCO,
but no less frequently than annually.116
As noted in the PCIDSS standards,
[p]erforming risk assessments at least
annually and upon significant changes
allows the organization to keep up to
date with organizational changes and
evolving threats, trends, and
technologies. 117 However, the
Commission emphasizes that the
proposed requirement to prepare a
written assessment on at least an annual
basis is not intended to substitute for
the DCOs obligation to conduct risk
assessment and monitoring on an
ongoing basis; rather, its purpose is to
formalize the risk assessment process
and ensure that it is documented at a
minimum frequency. As noted in the
FFIEC Handbook: Monitoring and
updating the security program is an
important part of the ongoing cyclical
security process. Financial institutions
should treat security as dynamic with
active monitoring; prompt, ongoing risk
assessment; and appropriate updates to
controls. 118
114 FINRA
115 NIST

SP 80053, supra note 47, app. B at B
19.
116 See, e.g., FINRA Report, supra note 31, at 14
(stating that firms conducting defined risk
assessment processes do so either annually or on an
ongoing basis throughout the year, in either case
culminating in an annual risk assessment report).
117 See, e.g., PCIDSS, supra note 54, at 100.
PO 00000
Frm 00010
Fmt 4701
Sfmt 4702
B. Scope of Testing and Assessment

The Commission believes that the
scope of a DCOs testing should be
based on a proper risk analysis that
takes into account the DCOs particular
automated systems and networks and
vulnerabilities, including any recent
changes to them, as well as the nature
of the DCOs possible adversaries and
their capabilities as revealed by current
cybersecurity threat analysis.119 The
Commission recognizes that, however,
the scope set for particular instances of
the various types of cybersecurity
testing can vary appropriately.120 Thus,
proposed 39.18(e)(8) would give a
DCO flexibility in setting the scope of
particular cybersecurity tests, so long as
its overall testing program is sufficient
to provide adequate assurance of the
overall effectiveness of its cybersecurity
controls with respect to its system
safeguards-related risks. The
Commission believes that such
flexibility should reduce costs and
burdens associated with the proposed
scope while still effectively measuring
the resilience of the DCO system
safeguards.
Accordingly, the Commission is
proposing that the scope of all testing
and assessment required by its system
safeguards regulations for DCOs should
be broad enough to include all testing of
automated systems and controls
necessary to identify any vulnerability
which, if exploited or accidentally
triggered, could enable an intruder or
unauthorized user or insider to:
Interfere with the DCOs operations or
with fulfillment of its statutory and
regulatory responsibilities; impair or
degrade the reliability, security, or
capacity of the DCOs automated
systems; add to, delete, modify,
exfiltrate, or compromise the integrity of
any data related to the DCOs regulated
activities; or undertake any other
unauthorized action affecting the DCOs
regulated activities or the hardware or
software used in connection with those
activities. The Commission believes that
this proposed scope is broad enough to
address all significant threats to the
DCO, while still providing sufficient
guidance regarding the elements of the
DCOs program.
C. Internal Reporting, Review, and
Remediation
Under current 39.18(j)(3) 121 reports
on testing protocols and results must be
communicated to, and reviewed by,
119 CFTC Roundtable, supra note 8, at 98, 101
103, 108113, 128130, 140142, 173180.
120 Id.
121 The Commission is further proposing to
renumber 39.18(j)(3) as 39.18(e)(9).
E:\FR\FM\23DEP3.SGM
23DEP3
senior management of the DCO.

However, consistent with industry best
practices, in 39.18(e)(9) the
Commission is proposing to expand this
reporting requirement to include
communication to, and review by, the
DCOs board of directors. The
Commission notes that active
management with board level
involvement is an essential effective
practice to address cybersecurity
threats[, because] [w]ithout that
involvement and commitment, a firm is
unlikely to achieve its cybersecurity
goals. 122 Further, the Commission
notes that FINRA observes that
[b]oards should play a leadership role
in overseeing firms cybersecurity
efforts, and states that the board of
directors should understand and
approach cybersecurity as an enterprisewide risk management issue rather than
merely an information technology
issue.123 The Commission also notes
that FFIEC states that regular reports to
the board of directors should address
the results of the organizations risk
assessment process and of its security
monitoring and testing, including both
internal and external audits and
reviews.124 In addition, FFIEC calls for
boards to review recommendations for
changes to the information security
program resulting from testing and
assessment, and to review the overall
effectiveness of the program.125
Accordingly, proposed 39.18(e)(10)
would also require DCOs to establish
and follow appropriate procedures for
the remediation of issues identified
through such review, and for evaluation
of the effectiveness of testing and
assessment protocols. The proposed rule
would also add a provision requiring a
DCO to analyze the results of the testing
and assessment required by the
applicable system safeguards rules, in
order to identify all vulnerabilities and
deficiencies in its systems, and to
remediate those vulnerabilities and
deficiencies to the extent necessary to
enable the DCO to fulfill the
requirements of part 39 and meet its
statutory and regulatory obligations. The
proposed rule would require such
remediation to be timely in light of
appropriate risk analysis with respect to
the risks presented.
D. Additional Amendments
In addition to the changes discussed
above, the Commission is proposing to
reorder and renumber certain
paragraphs in 39.18 to make certain
122 FINRA
123 Id.
124 FFIEC
125 Id.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
80123
technical corrections to improve the

clarity of the rule text.
3. Business Continuity and Disaster

Recovery Plan
1. Definitions
Regulation 39.18(e)(1) requires that a

DCO maintain a business continuity and
and personnel resources sufficient to
enable the timely recovery and
resumption of operations and the
fulfillment of each obligation and
responsibility of the DCO following any
disruption of its operations. Regulation
39.18(e)(2) explains that the
responsibilities and obligations
described in 39.18(e)(1) include the
daily processing, clearing, and
settlement of transactions. Because
these provisions are so closely linked,
the Commission is proposing to
combine them into a new
39.18(c)(1).128
The Commission is proposing to

amend the introductory text of
39.18(a) to make clear that the
definitions therein are also applicable to
39.34, which sets forth additional
system safeguards requirements for
SIDCOs and Subpart C DCOs.
The Commission also is proposing to
revise the definitions of relevant area
and recovery time objective to make
the language consistent with that used
elsewhere in 39.18.
Finally, the Commission is proposing
to change references to the clearing
and settlement of existing and new
products to the processing, clearing,
and settlement of transactions and a
single reference to an entity to a
[DCO].
2. Program of Risk Analysis and
Oversight
Regulation 39.18(b) requires a DCO to
have a program of risk analysis and
oversight with respect to its operation
and systems that addresses the
following elements, set forth in
39.18(c): (1) Information security; (2)
business continuity and disaster
recovery planning and resources; (3)
capacity and performance planning; (4)
systems operations; (5) systems
development and quality assurance; and
(6) physical security and environmental
controls. Specific requirements
concerning business continuity and
disaster recovery are addressed in
39.18(e), but the regulation does not
provide any further guidance on the
other five elements. Therefore, the
Commission is proposing to amend
39.18(c) (renumbered as
39.18(b)(2)) 126 to provide more detail
for each of those other five elements.127
renumber 39.18(d) as 39.18(b)(3); renumber
39.18(e)(2) as 39.18(b)(4); and delete 39.18(e)(3)
and fold its requirements into 39.18(c)(2). The
Commission is also proposing conforming changes
to the text of the renumbered provisions.
127 Although the Commission is proposing, in a
concurrent notice of proposed rulemaking, to
require that the program of risk analysis and
oversight for designated contract markets (DCMs)
include enterprise risk management and governance
applicable specifically to security and technology,
at this time the Commission is not proposing such
a requirement for DCOs. The Commission believes
that DCOs face a wider array of risks than DCMs,
and therefore any enterprise risk management
requirements for DCOs would not be limited to the
system safeguards context but rather would need to
be addressed in a more comprehensive fashion. The
Commission is considering this issue and may
address it in a future rulemaking.
PO 00000
Frm 00011
Fmt 4701
Sfmt 4702
4. Location of Resources; Outsourcing

Regulation 39.18(f) allows a DCO to
satisfy the resource requirement in
39.18(e)(1) (renumbered as
39.18(c)(1)) using its own employees
and property or through written
contractual arrangements with another
DCO or other service provider (i.e.,
outsourcing). The Commission is
proposing to amend this provision (and
renumber it as 39.18(d)) to clarify that
a DCO is also permitted to use
outsourcing to satisfy 39.18(b)(2)
(renumbered as 39.18(b)(4)), which
requires a DCO to establish and
maintain resources that allow for the
responsibility of the DCO in light of the
risks identified by the DCOs program of
risk analysis and oversight.
In addition, the Commission is
proposing to amend 39.18(f)(2)(i)
(renumbered as 39.18(d)(2)), which
states that, if a DCO chooses to use
outsourced resources, the DCO retains
liability for any failure to meet the
responsibilities specified in 39.18(e)(1)
(renumbered as 39.18(c)(1)), although
it is free to seek indemnification from
the service provider. Regulation 39.18
contains no restrictions that would
prevent a DCO from seeking
indemnification from its service
provider; therefore, the Commission is
proposing to delete this unnecessary
language.
5. Recordkeeping
Under current 39.18(i), a DCO is
required to maintain, and provide to
Commission staff upon request, current
renumber 39.18(e)(3) as 39.18(c)(2), and
39.18(k) as 39.18(c)(3). The Commission is also
proposing conforming changes to the text of the
renumbered provisions.
E:\FR\FM\23DEP3.SGM
23DEP3
80124
copies of its business continuity plan

and other emergency procedures, its
assessments of its operational risks, and
records of testing protocols and results.
renumber 39.18(i) as 39.18(f), and to
amend the language to conform with the
testing requirements proposed herein.
6. Notice of Exceptional Events
Under current 39.18(g)(1), a DCO is
required to promptly notify Commission
staff of any cybersecurity incident that
materially impairs, or creates a
significant likelihood of material
impairment of, automated system
operation, reliability, security, or
capacity. The Commission is proposing
a conforming amendment to
39.18(g)(1), to replace the term
cybersecurity incident with security
incident, as the proposed definition of
security incident would include a
cybersecurity incident.
7. System Safeguards for SIDCOs and

Subpart C DCOs
amend 39.34 to update several crossreferences to various provisions of
39.18.
III. Request for Comment
The Commission requests comment
on all aspects of the proposed
amendments to 39.18 and 39.34.
With respect to testing, the Commission
is particularly interested in the
following:
Are the testing requirements being
proposed in 39.18 consistent with the
DCO core principles set forth in the
CEA, particularly the goals of Core
Principle I? If so, in what ways? If not,
why not?
Are the proposed testing frequencies
sufficient to safeguard DCOs against
cyber attacks? In particular, should the
proposed control testing be done more
frequently, or less frequently? In each
case, please provide any data you may
have that supports an alternate
frequency for such testing.
Should the Commission define the
term independent contractor? If so,
how should such term be defined? If
not, why not?
What alternatives, if any, would be
more effective in reducing systemic risk,
mitigating the growing cybersecurity
threats faced by DCOs, and achieving
compliance with the DCO core
principles set forth in the CEA?
The Commission requests that
commenters include a detailed
description of any such alternatives and
estimates of the costs and benefits of
such alternatives. Can the proposed
changes to 39.18 be effectively
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
implemented and complied with? If not,

what changes could be made to increase
the likelihood of effective
implementation and compliance?
reporting requirements that are not

already accounted for in collection
30380076.133 Accordingly, the
Commission invites public comment on
the accuracy of its estimate that no
IV. Related Matters
additional recordkeeping or information
A. Regulatory Flexibility Act
collection requirements or changes to
existing collection requirements would
The Regulatory Flexibility Act
(RFA) requires that agencies consider result from the proposal.
The Commission will protect
whether the regulations they propose
proprietary
information according to the
will have a significant economic impact
on a substantial number of small entities Freedom of Information Act (FOIA)
and 17 CFR part 145, Commission
and, if so, provide a regulatory
Records and Information. In addition,
flexibility analysis respecting the
section 8(a)(1) of the CEA strictly
129
impact.
The rules proposed by the
prohibits the Commission, unless
Commission will impact DCOs. The
specifically authorized by the Act, from
Commission has previously established
certain definitions of small entities to making public data and information
that would separately disclose the
be used by the Commission in
business transactions or market
evaluating the impact of its regulations
on small entities in accordance with the positions of any person and trade
RFA.130 The Commission has previously secrets or names of customers. The
Commission is also required to protect
determined that DCOs are not small
certain information contained in a
entities for the purpose of the RFA.131
Accordingly, the Chairman, on behalf of government system of records according
to the Privacy Act of 1974.
the Commission, hereby certifies
pursuant to 5 U.S.C. 605(b) that the
1. Clarification of Collection 30380076
proposed rules will not have a
The Commission notes that DCOs are
significant economic impact on a
already subject to system safeguardsubstantial number of small entities.
related recordkeeping and reporting
requirements. As discussed above in
B. Paperwork Reduction Act
The Paperwork Reduction Act of 1995 section II, the Commission is proposing
to amend and renumber current
(PRA) 132 imposes certain
39.18(i) as 39.18(f), to clarify the
requirements on Federal agencies,
system safeguard recordkeeping and
including the Commission, in
reporting requirements for DCOs. The
connection with their conducting or
proposed regulation would require
sponsoring any collection of
DCOs, in accordance with 1.31,134 to
information, as defined by the PRA. An
provide the Commission with the
agency may not conduct or sponsor, and
following documents promptly upon
a person is not required to respond to,
request of Commission staff: (1) Current
a collection of information unless it
copies of the DCOs business continuity
displays a currently valid control
and disaster recovery plan and other
number. This proposed rulemaking
emergency procedures; (2) all
contains recordkeeping and reporting
assessments of the DCOs operational
requirements that are collections of
risks or system safeguard-related
information within the meaning of the
controls; (3) all required reports
PRA.
concerning system safeguards testing
The proposed rulemaking contains
and assessment, whether conducted by
provisions that would qualify as
collections of information, for which the
of the DCO; and (4) all other documents
Commission has already sought and
requested by staff of the Division of
obtained a control number from the
Clearing and Risk, or any successor
Office of Management and Budget
division, in connection with
(OMB). The title for this collection of
Commission oversight of system
information is Risk Management
Requirements for Derivatives Clearing
133 See Risk Management Requirements for
Organizations (OMB Control Number
Derivatives Clearing Organizations, OMB Control
No. 30380076, available at: http://
30380076). If adopted, responses to
www.reginfo.gov/public/do/
this collection of information would be
PRAOMBHistory?ombControlNumber=3038-0076.
mandatory. As discussed below, the
134 Regulation 1.31(a)(1) specifically provides that
Commission believes the proposal will
all books and records required to be kept by the
CEA or by these regulations shall be kept for a
not impose any new recordkeeping or
129 5
U.S.C. 601 et seq.

130 See 47 FR 18618, 1861821 (Apr. 30, 1982).
131 See New Regulatory Framework for Clearing
Organizations, 66 FR 45604, 45609 (Aug. 29, 2001).
132 44 U.S.C. 3501 et seq.
PO 00000
Frm 00012
Fmt 4701
Sfmt 4702
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).
E:\FR\FM\23DEP3.SGM
23DEP3
safeguards pursuant to the CEA or

Commission regulations, or in
connection with Commission
maintenance of a current profile of the
DCOs automated systems. The
pertinent recordkeeping and reporting
requirements of proposed 39.18(f) are
contained in the provisions of current
39.18(i), which was adopted on
November 8, 2011.135 Accordingly, the
Commission believes that proposed
39.18(f) would not impact the burden
estimates currently provided for in
collection 30380076.
2. Information Collection Comments
The Commission invites comment on
any aspect of the proposed information
collection requirements discussed
above. Pursuant to 44 U.S.C.
3506(c)(2)(B), the Commission will
consider public comments on such
proposed requirements in: (1)
Evaluating whether the proposed
collection of information is necessary
for the proper performance of the
functions of the Commission, including
whether the information will have a
practical use; (2) evaluating the
accuracy of the Commissions estimate
of the burden of the proposed collection
of information, including the validity of
the methodology and assumptions used;
(3) enhancing the quality, utility, and
clarity of the information proposed to be
collected; and (4) minimizing the
burden of collection of information on
those who are to respond, including
through the use of appropriate
automated, electronic, mechanical, or
other technological information
collection techniques.
Copies of the submission from the
Commission to OMB are available from
the CFTC Clearance Officer, 1155 21st
Street NW., Washington, DC 20581,
(202) 4185160 or from http://
RegInfo.gov. Persons desiring to submit
comments on the proposed information
collection requirements should send
those comments to: The Office of
Information and Regulatory Affairs,
Office of Management and Budget,
Room 10235, New Executive Office
Building, Washington, DC 20503,
Attention: Desk Officer of the
Commodity Futures Trading
Commission; (202) 3956566 (fax); or
[email protected] (email).
Please provide the Commission with a
copy of submitted comments so that all
comments can be summarized and
addressed in the final rulemaking, and
please refer to the ADDRESSES section of
this rulemaking for instructions on
submitting comments to the
Commission. OMB is required to make
135 76
FR 69334.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
a decision concerning the proposed

information collection requirements
between thirty (30) and sixty (60) days
after publication of the proposal in the
Federal Register. Therefore, a comment
to OMB is best assured of receiving full
consideration if OMB (as well as the
Commission) receives it within thirty
(30) days of publication of the proposal.
C. Consideration of Costs and Benefits
1. Introduction
Section 15(a) of the CEA requires the
Commission to consider the costs and
benefits of its actions before
promulgating a regulation under the
CEA or issuing certain orders.136
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
Commissions cost and benefit
considerations in accordance with
section 15(a) are discussed below.
As an initial matter, the Commission
considers the incremental costs and
benefits of these regulations, that is the
costs and benefits that are above the
current system safeguard practices and
requirements under the CEA and the
Commissions 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.137
on the costs and benefits associated
with the proposed regulations. As
discussed below, the Commission has
identified certain costs and benefits
associated with the proposed
regulations and requests comment on all
aspects of its proposed consideration of
costs and benefits, including
identification and assessment of any
costs and benefits not discussed herein.
In addition, the Commission requests
that commenters provide data and any
other information or statistics that the
commenters relied on to reach any
conclusions regarding the Commissions
proposed consideration of costs and
benefits, including the series of
questions in section 3(f).
136 7
U.S.C. 19(a).
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.
137 For
PO 00000
Frm 00013
Fmt 4701
Sfmt 4702
80125
2. Background and Baseline for the

Proposal
As discussed above, the Commission
believes that the current cyber threats to
the financial sector have expanded
dramatically over recent years.138
Accordingly, 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
proposed amendments would likely
result in some additional costs for
DCOs, the proposal 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.139 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.140
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 Commissions regulations for
DCOs. Currently, 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.141 This requirement,
which forms part of the DCO risk
analysis program required under
39.18(b), must be satisfied by
following, at a minimum, generally
accepted standards and industry best
practices. 142 In addition to the
industry best practices discussed in
section II above, this cost and benefit
discussion uses information provided
by DCOs in connection with a recent
survey of DCO system safeguard costs
and practices conducted by Commission
staff (February 2015 DCR Survey).143
138 See
supra section I.B.

also supra section I.C.
140 See supra section II.A.
141 17 CFR 39.18(j).
142 See 17 CFR 39.18(d).
143 On February 19, 2015, the Division of Clearing
and Risk requested, pursuant to 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,
139 See
E:\FR\FM\23DEP3.SGM
Continued
23DEP3
80126
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 Commissionregulated 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.
The Commission believes that certain
entities that would be subject to the
proposal already comply with most of
the testing requirements while others
may need some modest enhancements
to their system safeguard program to
achieve compliance. In this same regard,
the Commission notes that some DCOs
are larger or more complex than others,
and the proposed 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 also believes that to the
extent the new requirements impose
additional costs, the primary costs will
be in the form of more frequent testing,
including some testing that would have
to be carried out by independent
contractors on behalf of the DCO. As a
result, the proposed rules may increase
operational costs for DCOs by requiring
additional resources. The Commission
is sensitive to the economic effects of
the proposed regulations, including
costs and benefits. Accordingly, the
Commission seeks comment on the
costs and benefits of the proposed
regulations, including where possible,
quantitative data.
While certain costs are amenable to
quantification, other costs are not easily
estimated, such as the costs to the
public or market participants in the
event of a cybersecurity incident at a
DCO. The Commissions proposed
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.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
regulations are 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 Commissions
mission to protect market participants
and the public and to promote market
integrity.
The discussion of costs and benefits
that follows begins with a summary of
the current testing requirements and
sources for industry best practices as
well as a summary of each proposed
regulation and a consideration of the
corresponding costs and benefits. At the
conclusion of this discussion, the
Commission considers the costs and
benefits of the proposed regulations
collectively in light of the five factors
set forth in section 15(a) of the CEA.
3. Consideration of Costs and Benefits
Related to the Proposed Rules
a. Regulation 39.18(a)Definitions
(i) Summary of Proposed Regulations
As discussed above in section II,
proposed 39.18(a) would add to the
existing list of definitions, definitions
for the following terms: (1) Controls; (2)
controls testing; (3) enterprise
technology risk assessment; (4) external
penetration testing; (5) internal
penetration testing; (6) key controls; (7)
security incident; (8) security incident
response plan; (9) security incident
response plan testing; and (10)
vulnerability testing.
(ii) Costs and Benefits
The proposed definitions simply
provide context to the specific system
safeguard tests and assessments that a
DCO would be required to conduct on
an ongoing basis. Accordingly, the costs
and benefits of these terms are
attributable to the substantive testing
requirements and, therefore, are
discussed in the cost and benefit
considerations related to the rules
describing the requirements for each
test.
b. Regulation 39.18(e)(2)Vulnerability
Testing
As discussed above in section II(A)(1),
proposed 39.18(a) defines
vulnerability testing as testing of a
DCOs 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.
PO 00000
Frm 00014
Fmt 4701
Sfmt 4702
Regulation 39.18(e)(2) requires such

testing to be of a scope sufficient to
satisfy the testing scope requirements of
proposed 39.18(e)(8). Regulation
39.18(e)(2)(i) requires a DCO to conduct
analysis, but at a minimum no less
frequently than quarterly. Among the
four vulnerability tests conducted
annually, the proposed regulations
would require a DCO to engage
independent contractors to perform two
of the required quarterly tests each year
for the DCO, although other
vulnerability testing may be conducted
by employees of the DCO who are not
being tested. The vulnerability test
would also require automated
vulnerability scanning, which may be
authenticated or unauthenticated.
(ii) Costs
scope requirement of proposed
39.18(e)(2) will not impose new costs
on DCOs. Comprehensive vulnerability
testing is an industry best practice,144
and therefore required to be conducted
under current Commission regulations.
Moreover, the Commission believes,
based on the representations made by
DCOs to Commission staff in
administering the Commissions
examination program and DCO
responses to the February 2015 DCR
Survey, that most DCOs are currently
conducting vulnerability testing
sufficient to meet the scope
requirements of proposed 39.18(e)(2).
The Commission also believes that the
frequency requirement of proposed
39.18(e)(2)(i) will not impose new
costs on DCOs. The Commission notes
that industry best practices state that
vulnerability testing should be
conducted at least quarterly. 145
Accordingly, current 39.18 requires
DCOs to conduct vulnerability testing
on a quarterly basis. In addition, the
Commission notes that all 13 DCOs
responding to the February 2015 DCR
Survey conduct vulnerability testing on
a quarterly basis at a minimum.146
Proposed 39.18(e)(2)(ii) would
require a DCO to conduct vulnerability
tests that include automated
vulnerability scanning on an
144 See, e.g., NIST SP80053, supra note 47, at
F153; FFIEC Handbook, supra note 57, at 10
(Financial institutions should assess potential
threats and vulnerabilities of their information
systems.); PCIDSS, supra note 54, at 94.
145 See supra section II.A.1.; see also supra note
57 and accompanying text.
146 The frequency of vulnerability testing ranged
from 5 to 200 tests per year.
E:\FR\FM\23DEP3.SGM
23DEP3
authenticated basis, or, where not
conducted on an authenticated basis, to
implement compensating controls.147
The Commission notes that industry
best practices specifically recommend
authenticated scanning.148 Likewise,
current 39.18 requires DCOs to
conduct authenticated scanning and
Commission staff has examined DCOs
for compliance with such requirement.
Accordingly, the Commission does not
believe that DCOs will incur additional
costs as a result of the adoption of
proposed 39.18(e)(2)(ii).
Under proposed 39.18(e)(2)(iii), for
at least two of the required quarterly
vulnerability tests each year,
vulnerability testing must be conducted
by an independent contractor. However,
the remaining two vulnerability tests
may be conducted by a DCOs
employees so long as those employees
are not responsible for development or
being tested.149 The Commission notes
that at least 9 of the 13 DCOs
responding to the February 2015 DCR
Survey currently conduct at least some
of their vulnerability testing using
independent contractors. The
Commission does not, however, have
quantification or estimation of the costs
associated with proposed
39.18(e)(2)(iii). Nonetheless, in
qualitative terms, the Commission
recognizes that, compared to the status
quo, this proposed requirement may
impose some costs on DCOs equal to the
difference between conducting
vulnerability testing in-house and hiring
an independent contractor. In
particular, these proposed regulations
may require DCOs to establish and
implement internal policies and
procedures that are reasonably designed
to address the workflow associated with
the test, which may include the
communication and cooperation
between the entity and independent
contractor, communication and
cooperation between the entitys legal,
business, technology, and compliance
departments, appropriate authorization
to remediate vulnerabilities identified
by the independent contractor,
implementation of the measures to
address such vulnerabilities, and
verification that these measures are
effective and appropriate. The
Commission requests comment on the
potential costs of proposed
147 See
supra notes 55 and 56 and accompanying
text.
148 See, e.g., NIST SP 80053, supra note 47, at
F154 (Privileged access authorization to selected
system components facilitates more thorough
vulnerability scanning and also protects the
sensitive nature of such scanning.).
149 See supra section II.A.1.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
80127
39.18(e)(2)(iii) on DCOs, including,

where possible, quantitative data.
c. Regulation 39.18(e)(3)External
Penetration Testing
(iii) Benefits
Vulnerability testing identifies, ranks,

and reports vulnerabilities that, if
exploited, may result in an intentional
or unintentional compromise of a
system.150 The complex analysis and
plan preparation that a DCO undertakes
to complete vulnerability testing,
including designing and implementing
changes to existing plans, are likely to
contribute to a better ex ante
understanding by the DCOs
management of the challenges the DCO
would face in a cyber threat scenario,
and thus better preparation to meet
those challenges. This improved
preparation helps reduce the possibility
of market disruptions and financial
losses to clearing members and their
customers. Regularly conducting
vulnerability tests enables a DCO to
mitigate the impact that a cyber threat
to, or a disruption of, a DCOs
operations would have on customers,
clearing members, and, more broadly,
the stability of the U.S. financial
markets. Accordingly, the Commission
believes that such testing strengthens
DCOs systems, thereby protecting
clearing members and their customers
from a disruption in clearing services.
The Commission acknowledges, as
described above, that some DCOs may
incur additional costs as a result of the
new requirement in proposed
39.18(e)(2)(iii) that independent
contractors complete the vulnerability
testing. Nevertheless, the Commission
believes that the use of independent
contractions for vulnerability testinga
practice that many DCOs report already
doingwill strengthen this important
system safeguard, significantly
benefitting the DCO, financial markets,
and the public by mitigating systemic
risk.
The Commission requests comments
on the potential benefits to a DCO in
complying with all aspects of proposed
39.18(e)(2), and any benefits that
would be realized by members of DCOs
and their customers, as well as other
market participants or the financial
system more broadly. The Commission
specifically requests comment on
alternative means to address these
issues, and the benefits associated with
such alternatives.

proposed 39.18(a) defines external
penetration testing as attempts to
penetrate a [DCOs] automated systems
from outside the systems boundaries to
identify and exploit vulnerabilities,
and proposed 39.18(e)(3) requires such
proposed 39.18(e)(8). Proposed
39.18(e)(3)(i) would require a DCO to
conduct external penetration testing at a
risk analysis, but at a minimum no less
frequently than annually. The proposed
rule also provides that independent
contractors must perform the required
annual external penetration test on
behalf of the DCO. However, other
external penetration testing may be
performed by appropriately qualified
DCO employees not responsible for
or capabilities being tested.
150 PCIDSS
Penetration Testing, supra note 70, at
3.
PO 00000
Frm 00015
Fmt 4701
Sfmt 4702
(ii) Costs
on DCOs. Comprehensive external
penetration testing is an industry best
practice 151 and, based on the
representations made by DCOs to
Commission staff in administering the
Commissions examination program and
DCO responses to the February 2015
DCR Survey, the Commission believes
that most DCOs are currently
conducting external penetration testing
In addition, the Commission believes
that the frequency requirement of
proposed 39.18(e)(3)(i) will not impose
new costs on DCOs. The Commission
notes that industry best practices
specifically state that external
penetration testing should be conducted
at least annually. 152 Therefore
current Commission regulations require
annual penetration testing. Moreover,
the Commission notes that at least 11 of
the 13 DCOs responding to the February
2015 DCR Survey conduct, at a
minimum, annual external penetration
testing, with two DCOs responding that
they conduct periodic external
penetration testing.
151 See, e.g., NIST SP 80053, supra note 47, app.
FCA at F62; FFIEC Handbook, supra note 57, at
81; PCIDSS, supra note 54, at 9697; see also
section II.A.2.
152 See, e.g., PCIDSS, supra note 54, at 9697;
see also section II.A.2.
E:\FR\FM\23DEP3.SGM
23DEP3
80128

requirement of proposed 39.18(e)(3)(ii)
to use an independent contractor will
not impose new costs on DCOs. Current
39.18(j)(2) requires external
penetration testing to be conducted by
a qualified, independent professional,
who can be employed by the DCO so
long as he or she is not responsible for
or capabilities being tested. However, as
discussed above,153 the Commission
notes that it is industry best practice for
DCOs to employ independent
contractors to conduct their external
penetration testing, and therefore it is
currently required under 39.18. The
Commission notes that at least 11 of the
13 DCOs responding to the February
2015 DCR Survey already employ
their external penetration testing. The
Commission is proposing
39.18(e)(3)(ii) to make clear that
independent contractors must conduct
the required annual external penetration
test.
on the potential costs of proposed
39.18(e)(3) on DCOs, including, where
possible, quantitative data.
(iii) Benefits
External penetration testing benefits
DCOs by identifying the extent to which
its systems can be compromised before
an attack is identified.154 Such testing is
conducted outside a DCOs security
perimeter to help reveal vulnerabilities
that could be exploited by an external
attacker. Accordingly, the Commission
believes that the external penetration
testing strengthens DCOs systems,
thereby protecting clearing members
and their customers from a disruption in
clearing services, which could
potentially disrupt the functioning of
the broader financial markets.
As stated above, industry best
practices require DCOs to engage
annual external penetration testing.
Further, to the extent there is a lack of
clarity regarding the applicability of
certain industry best practices in light of
the language in current 39.18(j)(2),
proposed 39.18(e)(3)(ii) would provide
additional clarity. Moreover, the
Commission believes that testing by an
independent contractor has particular
value with respect to external
penetration testing because the test
comes from the viewpoint of an
outsider, which may differ from the
views of current tactics, techniques, and
153 See
supra section II.A.2.

154 FFIEC Handbook, supra note 57, at 81; see
also supra section II.A.2.
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
threat vectors of current threat actors

held by DCO employees. The
Commission believes that external
penetration testing helps DCOs, which
constitute critical infrastructures
important to the national economy, to
be adequately protected against the level
of cybersecurity threat now affecting the
financial sector.
such alternatives.
d. Regulation 39.18(e)(4)Internal
Penetration Testing
proposed 39.18(a) defines internal
penetration testing as attempts to
penetrate a [DCOs] automated systems
from inside the systems boundaries to
identify and exploit vulnerabilities.
Proposed 39.18(e)(4) requires such
proposed 39.18(e)(8). Proposed
39.18(e)(4)(i) requires a DCO to
conduct internal penetration testing at a
annually. The test may be conducted by
independent contractors, or by
appropriately qualified DCO employees
not responsible for development or
being tested.
(ii) Costs
on DCOs. Comprehensive internal
penetration testing is an industry best
practice,155 and is therefore required
under current regulations. In addition,
based on the representations made by
DCOs to Commission staff in
administering the Commissions
examination program and responses to
the February 2015 DCR Survey, the
Commission believes that most DCOs
are currently conducting internal
penetration testing sufficient to meet the
F62; FFIEC Handbook, supra note 57, at 81; PCI
DSS, supra note 54, at 9697; see also supra section
II.A.2.
PO 00000
Frm 00016
Fmt 4701
Sfmt 4702
scope requirements of proposed

39.18(e)(4).
Proposed 39.18(e)(4)(i) would
require a DCO to conduct internal
penetration testing at a frequency
annually. As discussed above, industry
best practices require annual internal
penetration testing, as well as after any
significant infrastructure or application
upgrade or modification. 156 Moreover,
the Commission notes that the February
2015 DCR Survey indicated that most
DCOs conduct internal penetration
testing at least annually.
The Commission also believes that
proposed 39.18(e)(4)(ii) will not
impose new costs on DCOs. Proposed
39.18(e)(4)(ii) requires DCOs to
conduct internal penetration testing by
engaging independent contractors, or by
using employees of the DCO who are
not responsible for development or
being tested. Regulation 39.18(j)(2)
currently requires testing to be
conducted by a qualified, independent
professional, who can be employed by
the DCO so long as he or she is not
being tested. Accordingly, proposed
39.18(e)(4)(ii) would not change
current regulatory requirements.
(iii) Benefits
By attempting to penetrate a DCOs
automated systems from inside the
systems boundaries, internal
penetration tests allow DCOs to assess
system vulnerabilities from attackers
that penetrate the DCOs perimeter
defenses and from trusted insiders, such
as former employees and contractors. In
addition to being an industry best
practice, the Commission believes that
an annual internal penetration testing is
important because such potential
attacks by trusted insiders generally
pose a unique and substantial threat due
to their more sophisticated
understanding of a DCOs systems.
Moreover, [a]n advanced persistent
attack may involve an outsider gaining
a progressively greater foothold in a
firms environment, effectively
becoming an insider in the process. For
this reason, it is important to perform
penetration testing against both external
and internal interfaces and systems. 157
156 See, e.g., PCIDSS, supra note 54, at 9697;
see also supra section II.A.2.
157 FINRA Report, supra note 31, at 22.
E:\FR\FM\23DEP3.SGM
23DEP3
The Commission also believes that
internal penetration testing strengthens
from a disruption in clearing services,
which could potentially disrupt the
functioning of the broader financial
markets.
such alternatives.
e. Regulation 39.18(e)(5)Controls
Testing

proposed 39.18(a) defines controls
testing as an assessment of the DCOs
controls to determine whether such
controls are implemented correctly, are
operating as intended, and are enabling
the DCO to meet the requirements of
proposed 39.18, and proposed
39.18(e)(5) requires such testing to be
of a scope sufficient to satisfy the testing
39.18(e)(8). Proposed 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
every two years.
Pursuant to proposed 39.18(e)(5)(ii),
a DCO would be required to engage
independent contractors to test and
assess its key controls, which are
defined in proposed 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.
DCOs may conduct any other non-key
controls testing by using independent
contractors or employees of the DCO
(ii) Costs
The Commission does not believe that
the scope requirement of proposed
39.18(e)(5) will impose new costs on
DCOs. Comprehensive controls testing
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
is an industry best practice.158

Accordingly, current 39.18 requires
DCOs to conduct comprehensive
controls testing. In addition, based on
the representations made by DCOs to
Survey, the Commission believes that
most DCOs are currently conducting
controls testing sufficient to meet the
39.18(e)(5).
require control testing to be conducted
at a frequency determined by an
frequently than every two years. The
Commission recognizes, however, that
appropriate risk analysis may well
determine that more frequent testing of
either certain key controls or all controls
is necessary. For example, the
Commission notes that the February
2015 DCR Survey indicated that most
DCOs conduct controls testing at least
annually.159
Proposed 39.18(e)(5)(ii) would
require DCOs to engage independent
contractors to test and assess its key
controls. Regulation 39.18(j)(2) currently
requires testing to be conducted by a
qualified, independent professional,
who can be employed by the DCO so
long as he or she is not responsible for
or capabilities being tested. The
Commission notes that at least 11 of the
13 DCOs responding to the February
2015 DCR Survey already employ
independent contractors to conduct key
controls testing.
The Commission does not have
quantification or estimation of the costs
associated with proposed 39.18(e)(5)(i)
or proposed 39.18(e)(5)(ii).
Nonetheless, in qualitative terms, the
Commission recognizes that, compared
to the status quo, this proposed
requirement may impose some costs on
DCOs equal to the difference between
conducting controls testing every two
years in-house and hiring an
independent contractor to do so. In
addition, with respect to the frequency
requirement in the proposed rule, a
DCO would be required to test each
control included in its program of
system safeguards-related risk analysis
oversight, at a frequency determined by
vi; PCIDSS, supra note 54, at 13; see also supra
section II.A.3.
159 Seven of the responding DCOs conduct
controls testing annually, three DCOs conduct
controls testing biannually, two DCOs conduct
controls testing triennially, and one DCO does not
conduct controls testing.
PO 00000
Frm 00017
Fmt 4701
Sfmt 4702
80129
frequently than every two years. The

Commission further recognizes that
actual costs may vary as a result of
numerous factors, including the size of
the DCO and the complexity of the
automated systems. Moreover, these
proposed regulations may require DCOs
to establish and implement internal
policies and procedures that are
reasonably designed to address the
workflow associated with the controls
test, which may include the
communication and cooperation
between the DCO and independent
contractor, communication and
cooperation between the DCOs legal,
business, technology, and compliance
departments, appropriate authorization
to remediate vulnerabilities identified
by the independent contractor,
implementation of the measures to
address such vulnerabilities, and
verification that these measures are
effective and appropriate.
(iii) Benefits
Controls testing is essential in
determining risk to an organizations
operations and assets, to individuals,
and to other organizations, and to the
Nation resulting from the use of the
organizations systems.160 In other
words, controls testing is vital because
it allows firms to be nimble in
preventing, detecting, or recovering
from an attack.161 The Commission
believes that the complex analysis and
plan preparation that a DCO undertakes
with respect to controls testing,
including designing and implementing
changes to existing plans, likely
contributes to a better ex ante
understanding by the DCOs
management of the challenges the DCO
would face in a cyber threat scenario,
and thus better preparation to meet
those challenges. This improved
preparation would help reduce the
possibility of market disruptions and
financial losses to clearing members and
their customers. Moreover, regularly
conducting controls testing enables a
DCO to mitigate the impact that a cyber
threat to, or a disruption of, a DCOs
operations would have on customers,
clearing members, and, more broadly,
the stability of the U.S. financial
markets. Accordingly, the Commission
believes that such testing strengthens a
160 See NIST SP 80053A, supra note 92, at 1; see
also supra section II.A.3.
161 Statement of Mr. Mark Clancy, Chief Executive
Officer, Soltra, CFTC Roundtable, supra note 8.
E:\FR\FM\23DEP3.SGM
23DEP3
80130

from a disruption in clearing services
In addition, the Commission
acknowledges that, as described above,
some DCOs may incur some additional
costs as a result of the need to conduct
testing by an independent contractor.
However, the Commission believes that
testing by an independent contractor
has particular value because the test
comes from the viewpoint of an
outsider, which may differ from the
views of current tactics, techniques, and
threat vectors of current threat actors
held by DCO employees. The
Commission also acknowledges that, as
described above, some DCOs may incur
some additional costs as a result of the
need to accelerate the testing of some
controls in order to comply with the
two-year cycle requirement.
Nevertheless, the Commission believes
that it is essential for each control to be
tested within the two-year cycle
requirement in order to confirm the
continuing adequacy of the DCOs
system safeguards and maintain market
stability. Additionally, the Commission
notes that the proposed rule would
permit such testing to be conducted on
a rolling basis over the course of a two
year period or period determined by
appropriate risk analysis. The rolling
basis provision in the proposed rule is
designed to give a DCO flexibility
concerning when controls are tested
during the required minimum frequency
period. This flexibility is intended to
reduce burdens associated with testing
every control while still ensuring the
needed minimum testing frequency. The
Commission also notes that testing on a
rolling basis is consistent with best
practices.
such alternatives.
f. Regulation 39.18(e)(6)Security
Incident Response Plan Testing
proposed 39.18(a) defines security
incident response plan testing as testing
of a DCOs security incident response
plan to determine the plans
effectiveness, identifying its potential
weaknesses or deficiencies, enabling
regular plan updating and improvement,
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
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, walkthrough or table-top exercises,
simulations, and comprehensive
exercises.
require DCOs to conduct such testing at
appropriate risk analysis, but at a
minimum no less frequently than
annually. Proposed 39.18(e)(6)(ii)
would require the DCOs security
incident response plan to include,
without limitation, the entitys
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
response process. Under proposed
39.18(e)(6)(iii), the DCO 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.
Moreover, proposed 39.18(e)(6)(iv)
would permit the DCO to conduct
by engaging independent contractors or
by using its own employees.
(ii) Costs
proposed 39.18(e)(6)(i) will not impose
new costs on DCOs. Security incident
response plan testing is an industry best
practice and therefore is required to be
conducted under current Commission
regulations.162 Moreover, the
Commission notes that industry best
practices state that security incident
response plan testing should be
conducted annually.163 Accordingly,
162 See e.g., NIST SP 80034, supra note 101, at
11; FINRA Report, supra note 31, at 23; FFIEC BCP
Booklet, supra note 104, at 25; and Council on
Cybersecurity, supra note 33, at CSC 18; see also
supra section II.A.4. Similarly, the Commission
proposes to expressly require DCOs to update their
business continuity and disaster recovery plans and
other emergency plans at least annually. The
Commission notes that updating such plans and
procedures at least annually is an industry best
practice. See NIST SP 80061, supra note 101, at
8. Thus, annual updates are required under current
Commission regulations. Therefore, the
Commission does not believe that this proposal
would impose new costs on DCOs. The Commission
acknowledges that this proposal could impose
additional burdens or costs on DCOs. The
Commission believes, however, that DCOs must be
adequately protected in todays environment.
163 See, e.g., NIST Special Publication 80084,
Guide to Test, Training, and Exercise Programs for
IT Plans and Capabilities, Sept. 2006, p. ES2,
PO 00000
Frm 00018
Fmt 4701
Sfmt 4702
proposed 39.18(e)(6)(ii) will not

impose new costs on DCOs because
conduct security incident response plan
testing on an annual basis. Finally, as
stated above, 39.18(e)(6)(iii) and (iv)
do not contain explicit requirements,
but rather provide a DCO with
flexibility to: (1) Coordinate its security
incident response plan testing with
other testing required by 39.18 or with
testing of its other business continuitydisaster recovery and crisis management
plans; and (2) consistent with current
39.18(j)(2), engage independent
contractors or use employees of the DCO
Accordingly, these provisions will not
impose new costs on DCOs.
(iii) Benefits
Security incident response plans, and
adequate testing of such plans, reduce
the damage caused by breaches of a
DCOs network security. Network
security breaches are highly likely to
have a substantial negative impact on a
DCOs operations. They can increase
costs through lost productivity, lost
current and future market participation
or swap data reporting, compliance
penalties, and damage to the DCOs
reputation and brand. Moreover, the
longer a cyber intrusion continues, the
more its impact may be compounded.
As noted above, and consistent with
industry best practices, the Commission
believes that annual security incident
response testing increases the ability of
a DCO to mitigate the duration and
impact in the event of a security
incident.164 Thus, a DCO may be better
positioned to minimize any potential
impacts to automated system
operations, reliability, security, or
capacity, or the availability,
confidentiality, or integrity of its
derivatives data.
available at: http://csrc.nist.gov/publications/
nistpubs/800-84/SP800-84.pdf; PCIDSS, supra
note 54, at 108; see also supra section II.A.4.
164 As noted above, the proposed provision that
would require DCOs to update their business
continuity and disaster recovery plans and other
emergency plans at least annually reflects what is
already considered an industry best practice.
Further, annual updates are important because once
an organization has developed a business
continuity and disaster recovery plan, the
organization should implement the plan and review
it at least annually to ensure the organization is
following the roadmap for maturing the capability
and fulfilling their [sic] goals for incident
response. NIST SP 80061, supra note 101, at 8.
E:\FR\FM\23DEP3.SGM
23DEP3
such alternatives.
g. Regulation 39.18(e)(7)Enterprise
Technology Risk Assessment

Proposed 39.18(a) defines 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
39.18(a) also provides that an
identifies, estimates, and prioritizes
risks to a DCOs operations or assets, or
to market participants, individuals, or
other entities, resulting from
or capacity of automated systems.
Proposed 39.18(e)(7) requires such
assessment to be of a scope sufficient to
satisfy the requirements of proposed
39.18(e)(8). Proposed 39.18(e)(7)(i)
requires DCOs to conduct an enterprise
technology risk assessment at a
annually. Proposed 39.18(e)(7)(ii)
provides that DCOs may use
of the DCO not responsible for
or capabilities being assessed to conduct
an enterprise technology risk
assessment.
(ii) Costs
The Commission does not believe that
the scope requirement of proposed
39.18(e)(7) will impose new costs on
DCOs. Comprehensive enterprise
technology risk assessments are an
industry best practice.165 Accordingly,
conduct enterprise technology risk
assessments. In addition, based on the
representations made by DCOs to
Survey, the Commission believes that
most DCOs are currently conducting
e.g., NIST SP 80039, supra note 59;
FFIEC Handbook, supra note 57, at 86; PCIDSS,
supra note 54, at 100; see also supra section II.A.5.
enterprise technology risk assessments

require a DCO to conduct an enterprise
technology risk assessment at a
annually. As discussed above,166
industry best practices require
at least annually and upon significant
changes to the environment.167 Thus,
current regulations require DCOs to
conduct enterprise technology risk
assessments on an annual basis.
Accordingly, the Commission does not
believe that proposed 39.18(e)(7)(i)
will impose new costs on DCOs.
Moreover, the Commission notes that
Survey indicated that most DCOs
conduct an enterprise technology risk
assessment at least annually.
Proposed 39.18(e)(7)(ii) requires
DCOs to conduct enterprise technology
risk assessments by using independent
contractors or employees of the DCO not
being assessed. Regulation 39.18(j)(2)
currently requires testing to be
conducted by a qualified, independent
professional, who can be employed by
the DCO so long as he or she is not
being tested. Accordingly, the
Commission does not believe that DCOs
will incur additional costs as a result of
the adoption of proposed
39.18(e)(7)(ii).
(iii) Benefits
are essential components of a
comprehensive system safeguard
program. Enterprise technology risk
assessments can be viewed as a strategic
approach through which a DCO
identifies risks and aligns its systems
goals accordingly. The Commission
believes that these requirements are
necessary to support a strong risk
management framework for DCOs,
thereby helping to protect DCOs, their
members, and other market participants,
and helping to mitigate the risk of
market disruptions.
165 See,
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
166 See
supra section II.A.5.

supra note 54, at 100.
167 PCIDSS,
PO 00000
Frm 00019
Fmt 4701
Sfmt 4702
80131

such alternatives.
h. Regulation 39.18(e)(8)Scope of
Testing and Assessment
As discussed above in section II(B),
proposed 39.18(e)(8) provides that the
scope for all system safeguards testing
and assessment required by proposed
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 entitys operations or
with fulfillment of the entitys statutory
and regulatory responsibilities; (2)
impair or degrade the reliability,
security, or adequate scalable capacity
of the entitys automated systems; (3)
add to, delete, modify, exfiltrate, or
compromise the integrity of any data
related to the entitys regulated
activities; and (4) undertake any other
unauthorized action affecting the
entitys regulated activities or the
hardware or software used in
connection with those activities.
(ii) Costs and Benefits
costs and benefits associated with the
scope for testing and assessment are
generally attributable to the substantive
testing requirements, and therefore, are
discussed above in the cost and benefit
considerations related to the rules
describing the requirements for each test
or assessment.
i. Regulation 39.18(e)(9)Internal
Reporting and Review
As discussed above in section II(C),
proposed 39.18(e)(9) provides 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
required by proposed 39.18. Moreover
the DCO would be required to establish
and follow appropriate procedures for
the remediation of issues identified
through such review, as provided in
proposed 39.18(e)(10), and for
evaluation of the effectiveness of testing
and assessment protocols.
(ii) Costs
As discussed above, review of system
safeguard testing and assessments by
E:\FR\FM\23DEP3.SGM
23DEP3
80132
senior management and the DCOs

board of directors is an industry best
practice and is therefore required to be
conducted under current Commission
regulations.168 Accordingly, the
the adoption of the proposed rules.
Nevertheless, the Commission
requests comment on any potential costs
of proposed 39.18(e)(9) on DCOs,
including, where possible, quantitative
data.
(iii) Benefits
internal reporting and review are an
essential component of a comprehensive
and effective system safeguard program.
While senior management and the
DCOs board of directors may have to
devote resources to reviewing testing
and assessment reports, active
supervision by these individuals
promotes responsibility and
accountability by ensuring they receive
and review the results of all system
safeguard testing and assessments,
thereby affording them the opportunity
to evaluate the effectiveness of the
testing and assessment protocols.
Moreover, the attention by the board of
directors and senior management
should help to promote a focus on such
reviews and issues, and enhance
communication and coordination
regarding such reviews and issues
among the business, technology, legal,
and compliance personnel of the DCO.
Such focus could cause a DCO to
internalize and/or more appropriately
allocate certain costs that would
otherwise be borne by clearing
members, customers of clearing
members, and other relevant
stakeholders. Active supervision by
senior management and the board of
directors also promotes a more efficient,
effective, and reliable DCO risk
management and operating structure.
Consequently, the DCO should be better
positioned to strengthen the integrity,
resiliency, and availability of its
automated systems.
such alternatives.
168 See
19:39 Dec 22, 2015

As discussed above in section II(C),
proposed 39.18(e)(10) requires a DCO
to analyze the results of the testing and
assessment required by proposed
39.18 to identify all vulnerabilities and
deficiencies in its systems. The DCO
would also be required to remediate
those vulnerabilities and deficiencies to
the extent necessary to enable the DCO
to fulfill its statutory and regulatory
obligations. The remediation would
have to be timely in light of appropriate
risk analysis with respect to the risks
presented by such vulnerabilities and
deficiencies.
(ii) Costs
The Commission believes that, based
on a DCOs risk analysis, the DCO
generally remediates the vulnerabilities
and deficiencies revealed by testing and
assessment in the ordinary course of
business to mitigate harm to the DCO
and to satisfy current statutory and
regulatory requirements. As discussed
above, remediation of vulnerabilities
and deficiencies revealed by
cybersecurity testing is an industry best
practice,169 and DCOs are already
required to comply with this
requirement. Accordingly, the
the adoption of the proposed rules.
on any potential costs of proposed
39.18(e)(10) on DCOs, including,
where possible, quantitative data.
(iii) Benefits
effective remediation is a critical
component of a comprehensive and
effective system safeguard program. As
discussed above, the Commission
believes that the remediation of
vulnerabilities and deficiencies revealed
by cybersecurity testing is a current
industry best practice and therefore
already required under current
regulations. Moreover, remediation may
reduce the frequency and severity of
systems disruptions and breaches for
DCOs. In addition, remediation helps
ensure that DCOs dedicate appropriate
resources to timely address system
safeguard-related deficiencies and
would place an emphasis on mitigating
harm to market participants while
promoting market integrity. Without a
timely remediation requirement, the
impact of the vulnerabilities or
deficiencies identified by the testing or
169 See, e.g., FFIEC Handbook, supra note 57, at
5; see also supra section II.C.
supra section II.C.
VerDate Sep<11>2014
j. Regulation 39.18(e)(10)Remediation
Jkt 238001
PO 00000
Frm 00020
Fmt 4701
Sfmt 4702
assessment could persist and have a

detrimental effect on the derivatives
markets generally, as well as market
participants. The Commission also
believes that remediation could
potentially result in DCOs reviewing
and revising their existing policies and
procedures to ensure that they are
sufficiently thorough in the context of
the new regulatory requirements, which
would also assist their staffs in
responding appropriately to
vulnerabilities or deficiencies identified
by the testing and assessments.
such alternatives.
4. Section 15(a) Factors
a. Protection of Market Participants and
the Public
Automated systems are critical to a
DCOs operations, which provide
essential counterparty credit risk
protection to market participants and
the investing public. Proposed 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 proposed
rules 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.
Additionally, providing the
Commission with reports concerning
the system safeguards testing and
assessments required by the proposed
regulations will further facilitate the
Commissions oversight of derivatives
markets, augment the Commissions
efforts to monitor systemic risk, and will
further the protection of market
participants and the public by helping
to ensure that a DCOs automated
systems are available, reliable, secure,
have adequate scalable capacity, and are
effectively overseen.
The costs of this proposed 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
E:\FR\FM\23DEP3.SGM
23DEP3
systemic risk, which protect market
participants and the public from the
adverse consequences that would result
from a DCOs failure or a disruption in
its functioning.
b. Efficiency, Competitiveness and
Financial Integrity
The proposed amendments to 39.18
would help preserve the efficiency and
financial integrity of the derivatives
markets by promoting comprehensive
oversight and testing of a DCOs
operations and automated systems.
Specifically, the proposed 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 proposed amendments to have a
significant impact on the
competitiveness of the derivatives
markets.
c. Price Discovery
The Commission does not anticipate
the proposed amendments to 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 proposed amendments to 39.18
would strengthen and promote sound
risk management practices across DCOs.
Specifically, the proposed amendments
would 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 proposed rules 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 proposed regulations
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
will assist the Commission in its

oversight of DCOs and will bolster the
Commissions 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. Proposed
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.
5. Request for Comment
In addition to the requests for
comment specified above, the
Commission requests comment on the
following:
What are the potential costs and
benefits resulting from, or arising out of,
requiring DCOs to comply with the
proposed changes to 39.18? In
considering costs and benefits,
commenters are requested to address the
effect of the proposed regulation not
only on a DCO, but also on the DCOs
clearing members, the customers of
clearing members, and the financial
requests that, where possible,
commenters provide quantitative data in
their comments, particularly with
respect to estimates of costs and
benefits.
The Commission has identified the
baseline as current regulatory
requirements. Is this baseline correct? If
not, what should the baseline be, and
how would the alternative baseline
change the costs and benefits associated
with the proposed changes to 39.18?
Do rules impose costs above those
required by current system safeguards
rule and identified by the Commission?
Specify and provide data to support.
Do rules provide benefits above those
required by current system safeguards
rule and identified by the Commission?
Specify and provide data to support.
Do the costs or impacts of the
proposed rules differ depending on the
size of a DCO? Do they differ depending
on the complexity of a DCOs systems?
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
PO 00000
Frm 00021
Fmt 4701
Sfmt 4702
80133
Trading Commission proposes to amend

17 CFR part 39 as follows:
PART 39DERIVATIVES CLEARING
ORGANIZATIONS
1. The authority citation for part 39
continues to read as follows:
Authority: 7 U.S.C. 2, 7a1, and 12a; 12

U.S.C. 5464; 15 U.S.C. 8325.
2. Revise 39.18 to read as follows:
39.18
System safeguards.
(a) Definitions. For purposes of this

section and 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,
in order to enable the derivatives
clearing organization to fulfill its
statutory and regulatory responsibilities.
Controls testing means assessment of
the derivatives clearing organizations
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
identifies, estimates, and prioritizes
risks to a derivatives clearing
organizations operations or assets, or to
market participants, individuals, or
other entities, resulting from
or capacity of automated systems.
External penetration testing means
attempts to penetrate a derivatives
clearing organizations automated
systems from outside the systems
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
systems from inside the systems
vulnerabilities. Methods of conducting
internal penetration testing include, but
are not limited to, methods for
circumventing the security features of
an automated system.
E:\FR\FM\23DEP3.SGM
23DEP3
80134
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 or potentially jeopardizes
automated system operation, reliability,
security, or capacity, or the availability,
confidentiality or integrity of data.
Security incident response plan
means a written plan documenting the
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 organizations security incident
response plan to determine the plans
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, walkthrough or table-top exercises,
simulations, and comprehensive
exercises.
Vulnerability testing means testing of
a derivatives clearing organizations
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
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
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 (e.g., least
privilege, separation of duties, account
monitoring and control); user and
device identification and
authentication; security awareness
training; audit log maintenance,
monitoring, and analysis; media
protection; personnel security and
screening; automated system and
communications protection (e.g.,
network port control, boundary
defenses, encryption); system and
information integrity (e.g., malware
defenses, software integrity monitoring);
vulnerability management; penetration
testing; security incident response and
management; and any other elements of
information security included in
generally accepted best practices;
(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
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 organizations systems to
ensure adequate scalable capacity (e.g.,
PO 00000
Frm 00022
Fmt 4701
Sfmt 4702
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 (e.g.,
baseline configuration, configuration
change and patch management, least
functionality, inventory of authorized
and unauthorized devices and software);
event and problem response and
management; and any other elements of
system operations included in generally
accepted best practices;
(v) Systems development and quality
assurance, including, but not limited to,
requirements development; preproduction 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
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
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
and personnel resources sufficient to
enable the timely recovery and
resumption of operations and the
E:\FR\FM\23DEP3.SGM
23DEP3
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
recovery plan, as described in paragraph
(c)(1) of this section, shall have, and the
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
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
providers 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 organizations 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
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
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 organizations
backup resources are sufficient to meet
the requirements of paragraph (c) of this
section.
(2) Vulnerability testing. A derivatives
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
frequently than quarterly.
(ii) Such vulnerability testing shall
include automated vulnerability
scanning. Where indicated by
appropriate risk analysis, such scanning
shall be conducted on an authenticated
basis, e.g., using log-in credentials.
Where scanning is conducted on an
unauthenticated basis, the derivatives
clearing organization shall implement
effective compensating controls.
(iii) A derivatives clearing
organization shall engage independent
contractors to conduct two of the
required quarterly vulnerability tests
each year. A derivatives clearing
organization may conduct other
vulnerability testing by using employees
of the derivatives clearing organization
(3) External penetration testing. A
conduct external penetration testing of a
scope sufficient to satisfy the
requirements set forth in paragraph
(e)(8) of this section.
shall conduct such external penetration
testing at a frequency determined by an
(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
PO 00000
Frm 00023
Fmt 4701
Sfmt 4702
80135

(4) Internal penetration testing. A
conduct internal penetration testing of a
scope sufficient to satisfy the
requirements set forth in paragraph
(e)(8) of this section.
shall conduct such internal penetration
testing at a frequency determined by an
shall conduct internal penetration
testing by engaging independent
contractors, or by using employees of
the derivatives clearing organization
(5) Controls testing. A derivatives
controls testing of a scope sufficient to
satisfy the requirements set forth in
paragraph (e)(8) of this section.
shall conduct controls testing, which
includes testing of each control
included in its program of risk analysis
and oversight, at a frequency
every two years. A derivatives clearing
organization may conduct such testing
on a rolling basis over the course of the
period determined by such risk analysis.
shall engage independent contractors to
test and assess the key controls, as
determined by appropriate risk analysis,
included in the derivatives clearing
organizations program of risk analysis
and oversight no less frequently than
every two 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
(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
annually.
(ii) The derivatives clearing
organizations security incident
response plan shall include, without
limitation, the derivatives clearing
organizations definition and
E:\FR\FM\23DEP3.SGM
23DEP3
80136
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
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 who are not
being tested.
(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.
shall conduct an enterprise technology
risk assessment at a frequency
annually.
may conduct enterprise technology risk
assessments by using independent
contractors or employees of the
derivatives clearing organization not
being assessed.
(8) Scope of testing and assessment.
The scope of all testing and assessment
required by this section shall be broad
enough to include testing of all
automated systems and controls
necessary to identify any vulnerability
which, if exploited or accidentally
triggered, could enable an intruder or
unauthorized user or insider to:
(i) Interfere with the derivatives
clearing organizations operations or
with fulfillment of its statutory and
regulatory responsibilities;
(ii) Impair or degrade the reliability,
security, or capacity of the derivatives
systems;
(iii) Add to, delete, modify, exfiltrate,
or compromise the integrity of any data
related to the derivatives clearing
organizations regulated activities; or
(iv) Undertake any other unauthorized
action affecting the derivatives clearing
organizations regulated activities or the
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
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 analyze the
results of the testing and assessment
required by this section to identify all
vulnerabilities and deficiencies in its
systems. The derivatives clearing
organization shall remediate those
vulnerabilities and deficiencies to the
extent necessary to enable the
derivatives clearing organization to
fulfill the requirements of this chapter
and meet its statutory and regulatory
obligations. Such remediation must be
timely in light of appropriate risk
analysis with respect to the risks
presented by such vulnerabilities and
deficiencies.
(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 1.31 of this chapter:
(1) Current copies of the derivatives
clearing organizations business
and other emergency procedures. Such
plan and procedures shall be updated at
frequently than annually;
(2) All assessments of the derivatives
clearing organizations 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
automated systems.
(5) Nothing in this paragraph (f) of
this section shall be interpreted as
reducing or limiting in any way a
PO 00000
Frm 00024
Fmt 4701
Sfmt 4702
obligation to comply with 1.31 of this

chapter.
(g) Notice of exceptional events. A
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 organizations business
continuity and disaster recovery plan.
(h) Notice of planned changes. A
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
systems that may impact the reliability,
security, or capacity of such systems;
and
(2) Planned changes to the derivatives
clearing organizations program of risk
analysis and oversight.
3. Revise paragraphs (a), (b)(3), and (c)
of 39.34 to read as follows:
39.34 System safeguards for
systemically important derivatives clearing
organizations and subpart C derivatives
clearing organizations.
(a) Notwithstanding 39.18(c)(2), the

recovery plan described in 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 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 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
E:\FR\FM\23DEP3.SGM
23DEP3
applies the same standards to other critical
market infrastructure.
Since the 2009 G20 agreement and the
enactment of Dodd-Frank, clearinghouses
have become increasingly important the
financial system. As a result, I believe we
must do all we can to ensure their strength
and stability. This proposed rule is a critical
component of this effort.
I thank the staff for their hard work on this
proposal. Of course, we welcome public
comment on both our system safeguards
proposals, which will be carefully taken into
account before we take any final action.
provisions of 39.18(e) shall apply to

such testing.
*
*
*
*
*
Issued in Washington, DC, on December
17, 2015, by the Commission.
Christopher J. Kirkpatrick,
Secretary of the Commission.
Note: The following appendices will not
appear in the Code of Federal Regulations.
Appendices to System Safeguards

Testing Requirements for Derivatives
Clearing OrganizationsCommission
Voting Summary, Chairmans
Statement, and Commissioners
Statement
Appendix 3Statement of
Commissioner Sharon Y. Bowen
Appendix 1Commission Voting

Summary
On this matter, Chairman Massad and
Commissioners Bowen and Giancarlo voted
in the affirmative. No Commissioner voted in
the negative.
Appendix 2Statement of Chairman

Timothy G. Massad
I strongly support this proposed rule.
The risk of cyberattacks is perhaps the
most important single issue we face in terms
of financial market stability and integrity.
The examples of cyberattacks or significant
technological disruptions from inside and
outside the financial sector are all too
frequent and familiar.
Today, the aims of these attacks can go
beyond traditional financial motives. Today,
we must be concerned about the possibility
of attacks intended to destroy information
and disrupt or destabilize our markets.
The risk to American businesses and the
economy is dramatic. And the
interconnectedness of our financial
institutions and markets means that a failure
in one institution can have significant
repercussions throughout the system.
The proposed rule that we are issuing
today is an important step toward enhancing
the protections in our markets. It builds on
our core principleswhich already require
clearinghouses to focus on system
safeguardsby setting standards consistent
with best practices. It requires robust testing
of cyber protections, setting forth the types of
testing that must be conducted, the frequency
of testing and whether tests should be
conducted by independent parties. In
addition, it enhances standards for incident
response planning and enterprise technology
risk assessments.
Our requirements should come as no
surpriseclearinghouses should already be
doing extensive testing. Indeed, we hope that
todays proposal sets a baseline that is
already being met.
The proposal also complements what we as
a Commission already do. We focus on these
issues in our examinations to determine
whether an institution is following good
practices and paying adequate attention to
these risks at the board level and on down.
This rule is largely in line with another
system safeguards proposal that the
Commission also approved today, which
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
Today, we are considering two rule

proposals that address an issue which is right
at the heart of systemic risk in our markets
cybersecurity. The question that we face is:
with a problem as immense as cybercrime,
and the many measures already being
employed to combat it, what would todays
proposed rules accomplish? In answer to that
question, I want to say a few words about our
cybercrime challenge, what is currently being
done to address it, and what I hope these
proposed regulations would add to these
efforts.
The problem is clearour firms are facing
an unrelenting onslaught of attacks from
hackers with a number of motives ranging
from petty fraud to international
cyberwarfare. We have all heard of notable
and sizable companies that have been the
victim of cybercrime, including: Sony, eBay,
JPMorgan, Target, and Stapleseven the U.S.
government has fallen victim.
In recent testimony before the House
Committee on Financial Services,
Subcommittee on Oversight and
Investigations about cybercrime, the Director
of the Center for Cyber and Homeland
Security noted that the U.S. financial
services sector in particular is in the
crosshairs as a primary target. 1 He cited one
US bank which stated that it faced 30,000
cyber-attacks in one weekaveraging an
attack every 34 seconds.2
Given the magnitude of the problem, it is
not at all surprising that a lot is already being
done to address it. The Department of
Homeland Security and others have been
working with private firms to shore up
defenses. Regulators have certainly been
active. The Securities and Exchange
1 Testimony of Frank J. Cilluffo, Director, Center
for Cyber and Homeland Security, Before the U.S.
House of Representatives, Committee on Financial
Services, Subcommittee on Oversight and
Investigations, 1 (June 16, 2015) (noting that the
following figures which were provided to me
recently by a major U.S. bank on a not-forattribution basis: just last week, they faced 30,000
cyber-attacks. This amounts to an attack every 34
seconds, each and every day. And these are just the
attacks that the bank actually knows about, by
virtue of a known malicious signature or IP address.
As for the source of the known attacks,
approximately 22,000 came from criminal
organizations; and 400 from nation-states.),
available at https://cchs.gwu.edu/sites/cchs.gwu.
edu/files/downloads/A%20Global%20Perspective
%20on%20Cyber%20Threats%20-%2015%20June
%202015.pdf.
2 Id.
PO 00000
Frm 00025
Fmt 4701
Sfmt 4702
80137
Commission (SEC), the Federal Deposit

Insurance Corporation (FDIC), the Federal
Reserve Board (FRB), the Federal Housing
Finance Agency (FHFA), and our selfregulatory organization, the National Futures
Association (NFA), have issued cybersecurity
guidance. In Europe, the Bank of England
(BOE) introduced the CBEST program to
conduct penetration testing on firms, based
on the latest data on cybercrime. We heard
a presentation from the BOE about CBEST at
a meeting of the Market Risk Advisory
Committee this year.
I wanted to hear what market participants
were doing to address the challenge of our
cybersecurity landscape so I met with several
of our large registrant dealers and asked them
about their cybersecurity efforts. After these
discussions, I was both alarmed by the
immensity of the problem and heartened by
efforts of these larger participants to meet
that problem head on. They were employing
best practices such as reviewing the practices
of their third party providers, using third
parties to audit systems, sharing information
with other market participants, integrating
cybersecurity risk management into their
governance structure, and staying in
communication with their regulators.
We have also been vigilant in our efforts
to address cybersecurity. Under our current
rule structure, many of our registrants have
system safeguards requirements. They
require, among other things, that the
registrants have policies and resources for
risk analysis and oversight with respect to
their operations and automated systems, as
well as reporting, recordkeeping, testing, and
coordination with service providers. These
requirements clearly include appropriate
cybersecurity measures. We also regularly
examine registrants for their adherence to the
system safeguards requirements, including
effective governance, use of resources,
appropriate policies, and vigilant response to
attacks.
So if all of this is happening, what would
more regulation accomplish? In other words,
what is the value add of the rules being
proposed today? The answer is: A great deal.
While some firms are clearly engaging in best
practices, we have no guarantee that all of
them are. And as I have said before, in a
system as electronically interconnected as
our financial markets, were collectively
only as strong as our weakest link, and so we
need a high baseline level of protection for
everyone . . . 3 We need to incentivize all
firms under our purview to engage in these
effective practices.
We have to do this carefully though
because once a regulator inserts itself into the
cybersecurity landscape at a firmthe firm
now has two concerns: Not just fighting the
attackers, but managing its reputation with
its regulator. So, if not done carefully, a
regulators attempt to bolster cybersecurity at
a firm can instead undermine it by
incentivizing the firm to cover up any
weaknesses in its cybersecurity
3 Commissioner Sharon Y. Bowen, Commodity
Futures Trading Commission, Remarks of CFTC
Commissioner Sharon Y. Bowen Before the 17th
Annual OpRisk North America, March 25, 2015,
available at http://www.cftc.gov/PressRoom/
SpeechesTestimony/opabowen-2.
E:\FR\FM\23DEP3.SGM
23DEP3
80138
infrastructure, instead of addressing them.

Further, we must be careful not to mandate
a one-size-fits-all standard because firms are
different. Thus, we must be thoughtful about
how to engage on this issue. We need to
encourage best practices, while not
hampering firms ability to customize their
risk management plan to address their
cybersecurity threats.
I think these rulemakings are a great first
step in accomplishing that balance. There are
many aspects of these proposals that I like.
First, they set up a comprehensive testing
regime by: (a) Defining the types of
cybersecurity testing essential to fulfilling
system safeguards testing obligations,
including vulnerability testing, penetration
testing, controls testing, security incident
response plan testing, and enterprise
technology risk assessment; (b) requiring
internal reporting and review of testing
results; and (c) mandating remediation of
VerDate Sep<11>2014
19:39 Dec 22, 2015
Jkt 238001
vulnerabilities and deficiencies. Further, for

certain significant entities, based on trading
volume, it requires heightened measures
such as minimum frequency requirements for
conducting certain testing, and specific
requirements for the use of independent
contractors.
Second, there is a focus on governance
requiring, for instance, that firms Board of
Directors receive and review all reports
setting forth the results of all testing. And
third, these rulemakings are largely based on
well-regarded, accepted best practices for
cybersecurity, including The National
Institute of Standards and Technology
Framework for Improving Critical
Infrastructure Cybersecurity (NIST
Framework).4
In all, I think the staff has put together two

thoughtful proposals. Clearly, however, this
is only a first step since all our registrants,
not just exchanges, SEFs, SDRs and DCOs,
need to have clear cybersecurity measures in
place. I am also very eager to hear what the
general public has to say about these
proposals. Do they go far enough to
incentivize appropriate cybersecurity
measures? Are they too burdensome for firms
that do not pose significant risk to the
system? And given that this is a dynamic
field with a constantly evolving set of threats,
what next steps should we take to address
cybercrime? Please send in all your thoughts
for our consideration.
4 NIST Framework, Subcategory PR.IP10, at 28,

and Category DE.DP, at 31, available at http://
www.nist.gov/cyberframework/upload/
cybersecurity-framework-021214.pdf.
PO 00000
Frm 00026
Fmt 4701
Sfmt 9990
[FR Doc. 201532144 Filed 122215; 8:45 am]

BILLING CODE 635101P
E:\FR\FM\23DEP3.SGM
23DEP3

Commodity Futures Trading Commission: Vol. 80 Wednesday, No. 246 December 23, 2015

Uploaded by

Copyright:

Available Formats

Commodity Futures Trading Commission: Vol. 80 Wednesday, No. 246 December 23, 2015

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Commodity Futures Trading Commission: Vol. 80 Wednesday, No. 246 December 23, 2015

Uploaded by

Copyright:

Available Formats

Vol.

December 23, 2015

Commodity Futures Trading Commission

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

19:39 Dec 22, 2015

COMMODITY FUTURES TRADING

System Safeguards Testing

The Commodity Futures

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

19:39 Dec 22, 2015

All submissions that have been redacted

with respect to its operations and

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

2014, the financial services sector

19:39 Dec 22, 2015

in terms of technical capability and the

phishing attacks, and other social

practices.27 Finally, both internal testing

at 1516, 65, 7174, 8283.

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

19:39 Dec 22, 2015

vulnerabilities and proactively address

Some experts further note that

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

II. Proposed Amendments

a more detailed discussion of current

19:39 Dec 22, 2015

by specifying five fundamental types of

Accordingly, in 39.18(a) the

NIST SP 80053, supra note 47, at F153.

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

passwords). However, the Commission

19:39 Dec 22, 2015

entities should run internal and external

The Commission also notes that best

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

Security Standards Council, PCIDSS

19:39 Dec 22, 2015

Handbook, supra note 57, at 82.

vulnerabilities (including, but not

important factor in conducting external

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

19:39 Dec 22, 2015

compliance or circumvention of the

Handbook, supra note 57, at 12.

risk management decisions. 96

SP 800137, supra note 81, at vi.

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

NIST urges organizations to have a

19:39 Dec 22, 2015

responding to cybersecurity incidents.

Report, supra note 31, at 23.

confidentiality, or integrity of data.108

proposed 39.18(e)(6), a DCO would

asabaliauskas on DSK5VPTVN1PROD with PROPOSALS

ETRA is an important part of a DCOs

19:39 Dec 22, 2015

methodologies and other using vendor

Report, supra note 31, at 14.