identified within the first prong of the definition, that provide
functionality to the securities markets for which the availability of
alternatives is significantly limited or nonexistent and without which
there would be a material impact on fair and orderly markets. The
Commission is not aware of any SCI systems that would fall under this
prong of the critical SCI systems definition at this time, and notes
that this prong of the definition is intended to account for further
technology advancements and the continual evolution of the securities
markets, in recognition that such developments could result in
additional or new types of systems that would, similar to the
enumerated categories of systems in the first prong of the definition,
become so critical to the continuous and orderly functioning of the
securities markets such that they should be subject to the requirements
of Regulation SCI imposed on those systems specifically enumerated in
the first prong of the definition.
    The Commission also notes that the definition applies to those
systems ``of, or operated by or on behalf of, an SCI entity.'' This
language mirrors the language in the definitions of SCI system and
indirect SCI system, and as discussed above, is intended to cover
systems that are third-party systems operated on behalf of SCI
entities.\299\
---------------------------------------------------------------------------

    \299\ See supra notes 254-260 and accompanying text.
---------------------------------------------------------------------------

d. Indirect SCI Systems (Proposed as ``SCI Security Systems'')
    Proposed Rule 1000 defined the term ``SCI security systems'' to
mean ``any systems that share network resources with SCI systems that,
if breached, would be reasonably likely to pose a security threat to
SCI systems.'' \300\ As adopted, Regulation SCI includes the new term
``indirect SCI systems,'' in place of the proposed term ``SCI security
systems.'' The term ``indirect SCI systems'' is defined to mean ``any
systems of, or operated by or on behalf of, an SCI entity that, if
breached, would be reasonably likely to pose a security threat to SCI
systems.''
---------------------------------------------------------------------------

    \300\ See proposed Rule 1000(a) and Proposing Release, supra
note 13, at Section III.B.2.
---------------------------------------------------------------------------

    As an initial matter, the Commission has determined to replace the
proposed term ``SCI security systems'' with the adopted term ``indirect
SCI systems'' because it believes that the latter term, in using the
word ``indirect,'' better reflects that it is intended to cover non-SCI
systems only if they are not appropriately secured and segregated from
SCI systems, and therefore could indirectly pose risk to SCI
systems.\301\ The adopted definition of indirect SCI systems includes
systems ``of, or operated by or on behalf of'' of an SCI entity that,
``if breached, would be reasonably likely to pose a security threat to
SCI systems.'' As discussed below, in response to comment that the
proposed term would cover too many systems unrelated to SCI systems,
the adopted term excludes the phrase ``share network resources.''
---------------------------------------------------------------------------

    \301\ The Commission also believes that eliminating the word
``security'' from the defined term will help clarify that the term
is not limited to systems relating only to security of the SCI
entity and its systems (e.g., firewalls, VPNs).
---------------------------------------------------------------------------

    One commenter expressly supported the definition of SCI security
systems and urged that it be expanded to include any technology system
that has direct market access.\302\ In response to this comment, the
Commission notes that the adopted definition includes any technology
system of, or operated by or on behalf of an SCI entity, that has
direct market access if that system meets the definition's test:
whether a breach of

that system would be reasonably likely to pose a security threat to SCI
systems.
---------------------------------------------------------------------------

    \302\ See Lauer Letter at 5.
---------------------------------------------------------------------------

    This commenter also suggested that the Commission additionally
require SCI entities to have independent security audits performed and
allow the auditor to have the ability to define which systems should be
included and which can be safely excluded.\303\ The Commission is not
requiring ``independent security audits'' to determine which systems
would fall within the definition of indirect SCI system as suggested by
this commenter,\304\ because the Commission believes its adopted rule
requiring an annual SCI review addresses the commenter's request. The
Commission notes that the adopted annual SCI review requirement
requires that such review be performed by objective, qualified
personnel, and that it include an assessment of logical and physical
security controls for SCI systems and indirect SCI systems. The
Commission believes that an SCI entity is generally in the best
position to assess in the first instance which of its systems may fall
within the definition of indirect SCI systems, and that having an
independent third party audit to make that determination should be
optional rather than required at this time.
---------------------------------------------------------------------------

    \303\ See id.
    \304\ See adopted Rule 1000 (definition of ``SCI review'') and
infra Section IV.B.5 (discussing the SCI review requirement).
---------------------------------------------------------------------------

    Contrary to the commenter urging expansion of the proposed
definition of SCI security systems, many commenters argued that the
proposed definition was overbroad,\305\ with several of these same
commenters suggesting that the term be deleted from the rule
entirely.\306\ The Commission believes that Regulation SCI warrants
inclusion of a definition of indirect SCI systems because an issue or
systems intrusion with respect to a non-SCI system still could cause or
increase the likelihood of an SCI event with respect to an SCI entity's
SCI systems.\307\ In particular, because systems that are not
adequately walled off from SCI systems may present potential entry
points to an SCI entity's network and thus represent potential
vulnerabilities to SCI systems, the Commission believes that it is
important that the provisions of Regulation SCI relating to security
standards and systems intrusions apply to such systems (i.e., indirect
SCI systems).
---------------------------------------------------------------------------

    \305\ See, e.g., NYSE Letter at 11; Omgeo Letter at 6; MFA
Letter at 6 (noting specifically that the definition could be read
to extend to broker-dealers or other third parties); SIFMA Letter at
8; ITG Letter at 5, 12; BIDS Letter at 16-17; MSRB Letter at 7; OCC
Letter at 4; FINRA Letter at 12-13; CME Letter at 6; DTCC Letter at
5; Oppenheimer Letter at 3; and Direct Edge Letter at 3.
    \306\ See, e.g., NYSE Letter at 11; Omgeo Letter at 6; MFA
Letter at 6; SIFMA Letter at 2; FIF Letter at 3; LiquidPoint Letter
at 3; KCG Letter at 18; OCC Letter at 3; and Joint SROs Letter at 5.
    \307\ See Proposing Release, supra note 13, at 18099.
---------------------------------------------------------------------------

    Many commenters objecting to the proposed definition as too broad
addressed particular elements of the proposed definition of SCI
security systems or provided specific recommendations for modifications
or limitations to the definition.\308\ For example, some commenters
criticized the use of the phrase ``share network resources,'' noting
that it was vague and too broad, potentially encompassing almost any
system of an SCI entity.\309\ Similarly, one commenter stated that the
definition of SCI security system should include only systems that
``directly'' share network resources with an SCI system.\310\ One
commenter argued that the definition should only include those systems
that are materially and directly connected to the trading operations of
an SCI entity.\311\ Several commenters recommended that systems that
are logically and/or physically separated from SCI systems should be
excluded from the definition.\312\ Some commenters qualified this
position by stating that such systems should be excluded, for example,
as long as SCI entities monitor those systems for security breaches and
have the ability to shut the system off if they detect a security
breach; \313\ or provided that the separation is routinely monitored
and has appropriate risk controls in place and the system is ``air
gapped'' (i.e., has no point of entry) from the public internet.\314\
One commenter believed that the definition should exclude any system
with ``compensatory controls in place,'' which it stated would protect
and secure SCI systems from vulnerabilities that could arise from
shared network links.\315\ Another commenter asked for greater clarity
on the extent to which SCI security systems that are isolated from
production, such as email and intranet sites, raise security issues
that are within the scope of the proposal.\316\
---------------------------------------------------------------------------

    \308\ See NYSE Letter at 12; BATS Letter at 5-6; ISE Letter at
7-8; BIDS Letter at 16-17; SROs Letter at 15; Direct Edge Letter at
3; FINRA Letter at 13; ISE Letter at 8; and DTCC Letter at 5; and
ITG Letter at 12.
    \309\ See NYSE Letter at 12; BATS Letter at 5; and ISE Letter at
7-8.
    \310\ See BIDS Letter at 16-17.
    \311\ See ITG Letter at 12 (stating that its suggested approach
would, in its case, cover systems for order handling and execution,
processing of market data, transaction reporting, and clearing and
settlement of trades).
    \312\ See, e.g., Joint SROs Letter at 15 (stating that the term
``SCI security systems'' should be deleted, but if retained, should
exclude those systems that are physically and logically separated);
BATS Letter at 5-6; Direct Edge Letter at 3; FINRA Letter at 13; ISE
Letter at 8; and DTCC Letter at 5.
    \313\ See BATS Letter at 5-6.
    \314\ See Direct Edge Letter at 3.
    \315\ See FINRA Letter at 13.
    \316\ See ISE Letter at 8.
---------------------------------------------------------------------------

    After careful consideration of these comments, the Commission
believes that inclusion of the phrase ``share network resources'' in
the proposed definition could be interpreted in a manner that would
include almost any system that is part of an SCI entity's network. In
response to commenters who expressed concern about the breadth of the
proposed definition, the Commission has determined to eliminate the
phrase ``share network resources'' from the definition, so that the
adopted result-oriented test depends on whether a system ``if breached,
would be reasonably likely to pose a security threat to SCI systems.''
As a result, the inquiry into whether any system is an indirect SCI
system will depend on whether it is effectively physically or logically
separated from SCI systems. Systems that are adequately physically or
logically separated (i.e., isolated from SCI systems, such that they do
not provide vulnerable points of entry into SCI systems) will not fall
within the definition of indirect SCI systems.
    The Commission believes that having adequate separation and
security controls should protect SCI systems from vulnerabilities
caused by other systems. To the extent that non-SCI systems are
sufficiently walled off from SCI systems using appropriate security
measures, and thus are not reasonably likely to pose a security threat
to SCI systems if breached, they would not be included in the
definition of indirect SCI systems, and thus would be outside of the
scope of Regulation SCI.
    The Commission notes that the definition of indirect SCI systems
will not include any systems of an SCI entity for which the SCI entity
establishes reasonably designed and effective controls that result in
SCI systems being logically or physically separated from such non-SCI
systems. Thus, the universe of an SCI entity's indirect SCI systems is
in the control of each SCI entity, and SCI entities should reasonably
expect Commission staff to assess its security controls around SCI
systems in connection with an inspection or examination for compliance
with Regulation SCI. If these controls are not present or are not
reasonably designed, the applicable non-SCI systems would be within the
scope of the definition of indirect SCI systems and subject to the
security

standards and systems intrusions provisions of Regulation SCI.
    Some commenters recommended that, rather than including SCI
security systems in the scope of the regulation, the Commission should
instead require SCI entities to establish policies and procedures
designed to ensure the security of their systems.\317\ According to
these commenters, such an approach would require an evaluation of the
risks posed to SCI systems by non-SCI systems. As noted, the Commission
believes that the adopted definition of ``indirect SCI systems'' will
effectively require SCI entities to evaluate the risks posed to SCI
systems by non-SCI systems. However, the Commission believes that the
adopted approach will incentivize SCI entities to seek to have in place
strong security controls around SCI systems. As noted, if an SCI entity
designs and implements security controls so that none of its non-SCI
systems would be reasonably likely to pose a security threat to SCI
systems, then it will have no indirect SCI systems. If, however, an SCI
entity does have indirect SCI systems, then certain provisions of
Regulation SCI will apply to those indirect SCI systems.\318\ The
Commission believes this approach to indirect SCI systems is more
appropriate than the policies and procedures approach suggested by some
commenters because the Commission believes that its approach is more
comprehensive as it includes, for example, the requirements to take
corrective action, provide notifications to the Commission, and
disseminate information for certain SCI events relating to indirect SCI
systems which, by definition, if breached, would be reasonably likely
to pose a security threat to SCI systems. Another commenter stated that
a more precise definition of SCI security systems is important and that
it would be valuable for the Commission to work with representatives
within the securities industry to collectively craft the most
appropriate definition that will ensure that critical security systems
are captured.\319\ In crafting the definition, the Commission has taken
into account comments received, with such commenters representing a
wide variety of types of participants in the securities markets, and
believes the adopted definition of indirect SCI systems, along with the
definition of SCI systems, is responsive to a broad range of
commenters' concerns.\320\
---------------------------------------------------------------------------

    \317\ See, e.g., NYSE Letter at 12; MFA Letter at 6; SIFMA
Letter at 2; FIF Letter at 3; LiquidPoint Letter at 3; KCG Letter at
18; OCC Letter at 3; and Joint SROs Letter at 5.
    \318\ See infra notes 323-328 (discussing the provisions of
Regulation SCI applicable to indirect SCI systems).
    \319\ See DTCC Letter at 5.
    \320\ See supra note 17 and accompanying text.
---------------------------------------------------------------------------

    Another commenter suggested that the definition be limited to
systems ``of, or operated by or on behalf of, an SCI entity,'' noting
that the definition of SCI security systems should have parallel
construction to the definition of ``SCI systems'' and without this
phrase, SCI entities would be tasked inappropriately with controlling
for systems outside of their effective control.\321\ As noted, the
adopted definition of ``indirect SCI systems'' applies to those systems
``of, or operated by or on behalf of, an SCI entity.'' As a result, the
adopted definition of indirect SCI systems provides (as is the case for
SCI systems) that systems ``of, or operated by or on behalf of'' an SCI
entity, are included in the definition of indirect SCI systems if their
breach would be reasonably likely to pose a security threat to SCI
systems.\322\ The Commission believes that the addition of this
language is warranted to make clear that security of SCI systems is not
limited solely to threats from systems operated directly by the SCI
entity. If it were, outsourced systems of SCI entities would not be
subject to the requirements of Regulation SCI, which would undermine
the goals of Regulation SCI.
---------------------------------------------------------------------------

    \321\ See MSRB Letter at 7.
    \322\ See supra Section IV.A.2.b (discussing the inclusion of
third party systems in the definition of ``SCI systems'').
---------------------------------------------------------------------------

    As discussed in further detail below, unlike SCI systems, those
systems meeting the definition of ``indirect SCI systems'' will only be
subject to certain provisions of Regulation SCI. Specifically,
references to ``indirect SCI systems'' are included in the definitions
of ``responsible SCI personnel,'' ``SCI review,'' and ``systems
intrusion'' in adopted Rule 1000.\323\ Rule 1001(a), requiring
reasonably designed policies and procedures to ensure operational
capability, will apply to indirect SCI systems only for purposes of
security standards.\324\ In addition, Rule 1002, which relates to an
SCI entity's obligations with regard to SCI events, will apply to
indirect SCI systems only with respect to systems intrusions.\325\
Further, pursuant to Rule 1003(a), the obligations related to systems
changes will apply to material changes to the security of indirect SCI
systems.\326\ In addition, the requirements regarding an SCI review
will apply to indirect SCI systems.\327\ Finally, Rules 1005 through
1007, relating to recordkeeping and electronic filing and submission of
Form SCI, respectively, will also apply to indirect SCI systems.\328\
The Commission believes that it is appropriate to subject indirect SCI
systems to only these specified provisions because the Commission
believes that the primary risk posed by indirect SCI systems is that
they may serve as vulnerable entry points to SCI systems. The
Commission's objective with respect to indirect SCI systems is to guard
against a non-SCI system being breached in a manner that threatens the
security of any SCI system. The Commission believes that its approach
to defining indirect SCI systems, and requiring SCI entities to
consider, address, and report on security changes and intrusions into
systems where vulnerabilities have been identified, is tailored to meet
this objective.
---------------------------------------------------------------------------

    \323\ See adopted Rule 1000.
    \324\ See adopted Rule 1001(a) and supra Section IV.B.1
(discussing the policies and procedures requirement under Rule
1001(a)).
    \325\ See adopted Rule 1000 (definitions of system compliance
and systems disruption, which do not include indirect SCI systems,
and the definition of systems intrusion, which includes indirect SCI
systems) and supra Section IV.B.3 (discussing an SCI entity's
obligations with respect to SCI events).
    \326\ See adopted Rule 1003(a)(i) and Section IV.B.4 (discussing
requirements relating to material systems changes).
    \327\ See adopted Rule 1003(b) and Section IV.B.5 (discussing
the SCI review requirement).
    \328\ See adopted Rules 1005-1007 and Section IV.C (discussing
the recordkeeping and electronic filing of Form SCI).
---------------------------------------------------------------------------

3. SCI Events
    Regulation SCI specifies the types of events--i.e., SCI events--
that give rise to certain obligations under the rule, including taking
corrective action, reporting to the Commission, and disseminating
information about such SCI events.\329\ Proposed Rule 1000(a) defined
the term ``SCI event'' as ``an event at an SCI entity that constitutes:
(1) A systems disruption; (2) a systems compliance issue; or (3) a
systems intrusion.'' \330\ The Commission is adopting the definition of
``SCI event'' as proposed.
---------------------------------------------------------------------------

    \329\ See infra Section IV.B.3 (discussing an SCI entity's
obligations with respect to SCI events).
    \330\ See proposed Rule 1000(a) and Proposing Release, supra
note 13, at Section III.B.3.
---------------------------------------------------------------------------

    Many commenters believed that the proposed definition of ``SCI
event'' was vague \331\ or overly broad because it was not limited to
capturing material SCI events \332\ or events that the commenters
believed are truly disruptive and pose a risk to the market.\333\
Specifically,

several commenters recommended that the definition of SCI event include
a materiality threshold, so that only events determined by the SCI
entity to be material would trigger certain obligations under the
rule.\334\ One commenter stated that the definition of SCI event could
be interpreted to include trivial events, and therefore believed that
the definition needed clarity.\335\ Finally, one commenter suggested
that SCI event be defined as outlined in Rule 301(b)(6)(ii)(G) under
Regulation ATS,\336\ which requires a qualifying ATS to notify the
Commission of material systems outages and significant systems
changes.\337\
---------------------------------------------------------------------------

    \331\ See ITG Letter at 12; and OTC Markets Letter at 16.
    \332\ See FIF Letter at 2; ITG Letter at 12; DTCC Letter at 5;
and OTC Markets Letter at 16.
    \333\ See NYSE Letter at 3; ICI Letter at 4; Oppenheimer Letter
at 3. See also supra note 231 and accompanying text (discussing
comment that the definition of SCI systems should be revised to
cover only those systems where a disruption, compliance issue,
intrusion or material systems change would impact investors and
markets that are subject to the Commission's jurisdiction).
    \334\ See, e.g., FIF Letter at 2 (suggesting factors for
determining what is a material SCI event, and urging that only
material SCI events be subject to notification requirements); ITG
Letter at 12 (suggesting that a Commission notification requirement
apply only to those events that have a material impact on the
ongoing maintenance of fair and orderly markets in an NMS security);
and DTCC Letter at 5 (recommending that each component of the term
SCI event be limited by a materiality threshold and be ``risk-
based'' so that the term includes events that cause a disruption to
the SCI entity's ability to conduct its core functions).
    \335\ See ITG Letter at 12.
    \336\ 17 CFR 242.301(b)(6)(ii)(G).
    \337\ See OTC Markets Letter at 16. In addition, some commenters
objected to the inclusion of systems compliance issues within the
definition of SCI events. See infra notes 403-405 and accompanying
text.
---------------------------------------------------------------------------

    After careful consideration of the views of commenters, although
the Commission is adopting the definition of ``SCI event'' as proposed,
the requirements of Regulation SCI are tiered in a manner that the
Commission believes is responsive to the concerns of commenters about
the breadth of the definition.\338\ Specifically, and as explained in
further detail below, the Commission is incorporating a risk-based
approach to the obligations of SCI entities with respect to SCI
events.\339\
---------------------------------------------------------------------------

    \338\ See supra notes 331-337 and accompanying text.
    \339\ Under this risk-based approach, for example, de minimis
SCI events will not be subject to the immediate Commission reporting
requirements as proposed, but rather, SCI entities will only be
required to make, keep, and preserve records regarding de minimis
SCI events and submit de minimis systems disruptions and de minimis
systems intrusions to the Commission in quarterly summary reports.
See Rule 1002(b)(5).
---------------------------------------------------------------------------

    The Commission is not incorporating a materiality threshold as
requested by some commenters,\340\ including by limiting the definition
of SCI event to only those events that are considered by SCI entities
to be truly disruptive to the market.\341\ Rather, the Commission
believes that the adopted Commission notification and information
dissemination requirements for SCI events will help to focus the
Commission's and SCI entities' resources on the more significant SCI
events by providing appropriate exceptions from reporting and
dissemination for events that have no or de minimis impacts on an SCI
entity's operations or market participants. In addition, the Commission
believes that SCI event should not be defined as outlined in Rule
301(b)(6)(ii)(G) under Regulation ATS as suggested by one
commenter,\342\ because Rule 301(b)(6)(ii)(G) requires Commission
notification of ``material systems outages.'' \343\ Such an approach
would exclude any systems compliance issues or systems intrusions, two
types of events that the Commission believes should be included as SCI
events. This approach would also create a materiality threshold for
systems disruptions, which the Commission believes would not be
appropriate, as discussed below.
---------------------------------------------------------------------------

    \340\ See supra notes 334 and 337 and accompanying text.
    \341\ See supra note 333 and accompanying text.
    \342\ See supra note 337 and accompanying text.
    \343\ See 17 CFR 242.301(b)(6)(ii)(G). Rule 301(b)(6)(ii)(G)
also requires that ATSs promptly notify the Commission of
significant systems changes.
---------------------------------------------------------------------------

    In addition, by not including a materiality threshold within the
definition, SCI entities will be required to assess, take corrective
action, and keep records of all such events, some of which may
initially seem insignificant to an SCI entity, but which may later
prove to be the cause of significant systems issues at the SCI entity.
An SCI entity's records of de minimis SCI events may also be useful to
the Commission in that they may, for example, aid the Commission in
identifying patterns of de minimis SCI events that together might
result in a more impactful SCI event, either at an SCI entity or across
a group of SCI entities, or circumstances in which an SCI event causes
de minimis systems issues for one particular SCI entity but results in
significant issues for another SCI entity. The Commission also believes
that the ability to view such events in the aggregate and across
multiple SCI entities is important to allow the Commission and its
staff to be able to gather information about trends related to SCI
events that could not otherwise be properly discerned. Information
about trends will assist the Commission in fulfilling its oversight
role by keeping Commission staff informed about the nature and
frequency of the types of de minimis SCI events that SCI entities
encounter. Moreover, information about trends and notifications of de
minimis SCI events generally can also inform the Commission of areas of
potential weaknesses, or persistent or recurring problems, across SCI
entities and also should help the Commission better focus on common
types of SCI events or issues with certain types of SCI systems across
SCI entities. This information also will permit the Commission and its
staff to issue industry alerts or guidance if appropriate. In addition,
this information would allow the Commission and its staff to review SCI
entities' classification of SCI events as de minimis SCI events.
    In addition, although the definition of SCI event is unchanged, to
address commenters' concerns, the Commission has determined to modify
the various components of that definition (i.e., the definition of
systems disruption, systems compliance issue, and systems intrusion),
in certain respects, as discussed below.
a. Systems Disruption
    Proposed Rule 1000(a) would have defined ``systems disruption'' as
``an event in an SCI entity's SCI systems that results in: (1) A
failure to maintain service level agreements or constraints; (2) a
disruption of normal operations, including a switchover to back up
equipment with near-term recovery of primary hardware unlikely; (3) a
loss of use of any SCI system; (4) a loss of transaction or clearance
and settlement data; (5) significant backups or delays in processing;
(6) a significant diminution of ability to disseminate timely and
accurate market data; or (7) a queuing of data between systems
components or queuing of messages to or from customers of such duration
that normal service delivery is affected.'' \344\ As discussed below,
in response to comments, the Commission is substantially modifying the
proposed definition of systems disruption in adopted Rule 1000.
---------------------------------------------------------------------------

    \344\ See proposed Rule 1000(a) and Proposing Release, supra
note 13, at Section III.B.3.a.
---------------------------------------------------------------------------

    One commenter stated that the proposed definition of systems
disruption was reasonable, but recommended that it be expanded to
encompass disruptions originating from a third party.\345\ However,
many other commenters believed that the definition of systems
disruption was too broad and would include minor events that they
believed should be excluded from the

definition.\346\ Several commenters suggested ways to limit the scope
of the defined term. For example, some commenters suggested limiting
the definition to material disruptions.\347\ One of these commenters
added that systems disruptions should exclude any regularly planned
outages occurring during the normal course of business.\348\ Another
commenter recommended that development and testing environments should
be excluded from the definition of systems disruption.\349\ One
commenter suggested modifying the definition to include only two
elements: (1) Disruptions of either the SCI systems or of the
operations of the SCI entity that have the effect of disrupting the
delivery of the SCI service provided by those systems; and (2)
degradations of SCI systems processing creating backups or delays of
such a degree and duration that the delivery of service is effectively
disrupted or unusable by the market participants who use the
systems.\350\
---------------------------------------------------------------------------

    \345\ See Lauer Letter at 5-6.
    \346\ See, e.g., FINRA Letter at 16; BATS Letter at 9; Omgeo
Letter at 7; NYSE Letter at 14; Joint SROs Letter at 6; OCC Letter
at 6; SIFMA Letter at 9-10; and OTC Markets Letter at 21.
    \347\ See DTCC Letter at 6; SIFMA Letter at 9; OCC Letter at 6;
OTC Markets Letter at 21; and Joint SROs Letter at 6.
    \348\ See DTCC Letter at 7.
    \349\ See FINRA Letter at 11, 16 (noting also that the many
elements of the defined term were vague). See also Section IV.A.2.b
(discussing the definition of ``SCI systems,'' including the
elimination of test and development systems from its definition).
    \350\ See Omgeo Letter at 11.
---------------------------------------------------------------------------

    Two commenters believed that the proposed definition of systems
disruption was too rigid and should provide for more flexibility and
discretion.\351\ Both commenters were skeptical that an event should be
reportable solely because it matched the description of one of the
seven elements of the definition.\352\ One of these commenters noted
that the Commission's proposed definition seeks to codify as a formal
definition language used by the ARP Inspection Program that was meant
to provide flexibility and latitude in determining what constitutes a
systems disruption.\353\ The other commenter thought that the seven
prongs of the proposed definition of ``systems disruption'' were
appropriate considerations in determining whether a systems disruption
had occurred, but that an SCI entity should be afforded more discretion
and flexibility in determining whether a particular issue meets the
definition.\354\
---------------------------------------------------------------------------

    \351\ See Omgeo Letter at 7; and OCC Letter at 6-8.
    \352\ See Omgeo Letter at 7; and OCC Letter at 6-8.
    \353\ See Omgeo Letter at 7.
    \354\ See OCC Letter at 6. This commenter also critiqued or
requested clarification for each prong of the definition, as
discussed further below.
---------------------------------------------------------------------------

Service Level Agreements
    Two commenters believed that the first element of the definition
regarding service level agreements should be eliminated.\355\ One of
these commenters stated that an SCI entity's regulatory requirements
should not depend upon the negotiated language of an agreement between
business partners, while the other commenter noted that, in some cases,
a private contract might have more stringent requirements than required
by regulation, which would, in effect, transform such agreements into
new regulatory obligations.\356\ Other commenters stated this element
should be revised to capture only the most significant disruptions to a
service level agreement.\357\ In addition, one commenter expressed
concern that SCI entities may forgo negotiating detailed and stringent
service level agreements if the first element were to be adopted as
proposed.\358\
---------------------------------------------------------------------------

    \355\ See NYSE Letter at 13; and BATS Letter at 9.
    \356\ See NYSE Letter at 13; and BATS Letter at 9.
    \357\ See DTCC Letter at 7 (suggesting that the definition
capture only the most significant disruptions to a service level
agreement that are caused by the SCI entity and that impede its
ability to perform its core functions and critical operations); and
OCC Letter at 7. See also Omgeo Letter at 9 (noting concerns that
this element could require reporting of events too minor to be
noticed by participants and that do not cause any disruptions of
service or material risks to the entity or users).
    \358\ See OCC Letter at 7.
---------------------------------------------------------------------------

Disruptions of Normal Operations
    Two commenters stated that the second element of the definition
needs clarification because the phrase ``disruption of normal
operations'' is vague and overbroad and therefore could potentially
include minor events.\359\ Two commenters stated that, if a switchover
is utilized and there is no material impact on the core services, then
there should not be a requirement to notify the Commission of a systems
disruption.\360\ One of these commenters added that programming errors
that occur prior to production and regularly scheduled maintenance
should not be considered disruptions.\361\ Several commenters also
recommended that testing errors should not be included in the
definition,\362\ and one commenter stated that testing errors should
only be included if they result in a material impact on an SCI entity's
operations.\363\
---------------------------------------------------------------------------

    \359\ See NYSE Letter at 13; and Omgeo Letter at 8.
    \360\ See BATS Letter at 9; and SIFMA Letter at 10.
    \361\ See BATS Letter at 10.
    \362\ See BATS Letter at 11; SIFMA Letter at 10; and NYSE Letter
at 13.
    \363\ See Omgeo Letter at 9 (noting that inclusion of testing
errors would discourage SCI entities from conducting effective
quality assurance programs and could undermine good quality
engineering practices).
---------------------------------------------------------------------------

Loss of Use of Any System
    One commenter stated that the term ``loss of use of any SCI
system'' is unclear and expressed concern that the lack of clarity may
lead to interpretive differences and inconsistencies in application
among SCI entities.\364\ Three commenters discussed failovers to backup
systems, with one commenter stating the Commission should clarify
whether this constitutes a loss of use of a system,\365\ another
commenter stating that it should not be considered a systems
disruption,\366\ and the third commenter stating that it should only be
considered a systems disruption if there is an impact on normal
operations.\367\
---------------------------------------------------------------------------

    \364\ See OCC Letter at 7.
    \365\ See id.
    \366\ See NYSE Letter at 13.
    \367\ See Direct Edge Letter at 3.
---------------------------------------------------------------------------

Loss of Data
    Several commenters stated that losses of transaction or clearance
and settlement data that are immediately retrieved, promptly corrected,
or, for clearance and settlement data, resolved prior to the close of
the trading day should not be systems disruptions.\368\ One commenter
suggested that the rule be revised to include as a systems disruption
data that is altered or corrupted in some way.\369\ Another commenter
stated that this prong of the definition should include a materiality
qualifier.\370\
---------------------------------------------------------------------------

    \368\ See, e.g., OCC Letter at 7; DTCC Letter at 7; SIFMA Letter
at 10; and Omgeo Letter at 11.
    \369\ See Omgeo Letter at 11.
    \370\ See NYSE Letter at 14.
---------------------------------------------------------------------------

Backups or Delays and Market Data Dissemination
    With respect to the fifth and sixth elements of the definition
regarding significant backups or delays in processing and a significant
diminution of ability to disseminate timely and accurate market data,
one commenter expressed support for the inclusion of such performance
degradations in the definition of systems disruptions but stated that
it believed that the Commission's interpretation of the term
``significant'' in the SCI Proposal was overly broad because it would
encompass delays that are small and, in fact, insignificant.\371\
---------------------------------------------------------------------------

    \371\ See Omgeo Letter at 9. See also Proposing Release, supra
note 13, at 18101-02.

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

Data Queuing
    With respect to the seventh element, one commenter stated that
queuing of data is a very good indicator of a problem, but also noted
that it is not necessarily being properly monitored by most firms and
suggested that the Commission require SCI entities to monitor queue
depth.\372\ However, several other commenters stated that queuing of
data is normal and necessary.\373\ Some commenters suggested that the
Commission should only require reporting of such queuing if it
materially affects the delivery of core services to customers.\374\ One
commenter asked for additional clarification on this element because
all systems have queues to some extent with normal functionality and
only certain queues should trigger recovery actions.\375\ One commenter
expressed concern that language in the SCI Proposal stating that
``queuing of data is a warning signal of significant disruption'' \376\
would make events that are precursors to system disruptions themselves
become system disruptions.\377\
---------------------------------------------------------------------------

    \372\ See Lauer Letter at 5.
    \373\ See, e.g., BATS Letter at 10; DTCC Letter at 7; SIFMA
Letter at 10; Omgeo Letter at 10; and Joint SROs Letter at 6.
    \374\ See, e.g., BATS Letter at 10-11; DTCC Letter at 7; Omgeo
Letter at 10; and OCC Letter at 8.
    \375\ See NYSE Letter at 14.
    \376\ See Proposing Release, supra note 13, at 18102.
    \377\ See Omgeo Letter at 9.
---------------------------------------------------------------------------

Customer Complaints
    Several commenters objected to the Commission's discussion in the
SCI Proposal regarding customer complaints,\378\ stating that the
Commission should not consider each instance in which a customer or
systems user complains or inquires about a slowdown or disruption of
operations as an indicator of a systems disruption.\379\ For example,
one commenter noted that customer complaints are often ultimately
determined to be the result of system errors or discrepancies on the
customer's end, and stated that requiring an SCI entity to treat these
complaints as significant systems disruptions simply because they are
made would impose an unnecessary burden on the SCI entity.\380\
---------------------------------------------------------------------------

    \378\ See Proposing Release, supra note 13, at 18102.
    \379\ See, e.g., DTCC Letter at 7; Omgeo Letter at 10; BATS
Letter at 11; NYSE Letter at 14; and OCC Letter at 8.
    \380\ See Omgeo Letter at 10-11.
---------------------------------------------------------------------------

Definition of ``Systems Disruption'' as Adopted
    After careful consideration of the views of commenters, the
Commission is removing the seven specific types of systems malfunctions
that were proposed to define systems disruption. As adopted, ``systems
disruption'' is defined in Rule 1000 to mean ``an event in an SCI
entity's SCI systems that disrupts, or significantly degrades, the
normal operation of an SCI system.'' The Commission has considered
commenters' suggestions and feedback with respect to the proposed
definition, including the criticisms of various aspects of the seven
specific types of systems malfunctions delineated in the SCI Proposal
and believes that the adopted definition, which largely follows the
definition suggested by a commenter, is appropriate.\381\ Specifically,
this commenter recommended that the definition of systems disruption be
revised to have two elements: (1) Disruptions of either the SCI systems
or of the operations of the SCI entity that have the effect of
disrupting the delivery of the SCI service provided by those systems;
and (2) degradations of SCI systems processing creating backups or
delays of such a degree and duration that the delivery of service is
effectively disrupted or unusable by the market participants who use
the systems.\382\
---------------------------------------------------------------------------

    \381\ See id. at 11.
    \382\ See supra note 353 and accompanying text.
---------------------------------------------------------------------------

    The Commission agrees with commenters that the proposed definition
of systems disruption had the potential to be both over-inclusive and
under-inclusive. The Commission believes that the adopted definition
appropriately represents a change in focus of the definition from the
prescriptive seven prongs in the SCI Proposal's definition that
represented the effects caused by a disruption of an SCI entity's
systems to, instead, whether a system is halted or degraded in a manner
that is outside of its normal operation. The Commission believes the
revised definition sets forth a standard that SCI entities can apply in
a wide variety of circumstances to determine in their discretion
whether a systems issue should be appropriately categorized as a
systems disruption. Further, because the adopted definition of systems
disruption takes into account whether a systems problem is outside of
normal operations, the Commission also believes that partly addresses
the concerns of the commenters suggesting that the definition of
systems disruption include a materiality qualifier.\383\
---------------------------------------------------------------------------

    \383\ As discussed more fully below, an SCI entity's assessment
of the impact of an event meeting the definition of a systems
disruption will affect whether it is subject to an immediate
Commission notification obligation, or a recordkeeping and quarterly
reporting obligation. See infra Section IV.B.3.c (discussing the
exclusion of de minimis systems disruptions from immediate
Commission notification requirements in Rule 1002(b)(5)).
---------------------------------------------------------------------------

    Because the Commission agrees with commenters regarding the
difficulties of the proposed definition of ``systems disruption,'' it
is not including any of the specific types of systems malfunctions in
the adopted definition of ``systems disruption.'' Thus, the Commission
believes SCI entities would likely find it helpful to establish
parameters that can aid them and their staff in determining what
constitutes the ``normal operation'' \384\ of each of its SCI systems,
and when such ``normal operation'' has been disrupted or significantly
degraded because those parameters have been exceeded. The Commission
agrees with commenters who noted that, given its voluntary nature,
entities that participate in the ARP Inspection Program are afforded a
certain degree of flexibility and discretion in reporting systems
outages, and agrees that, given its proposed application to a mandatory
rule, the proposed definition limited the flexibility and discretion of
SCI entities in a manner that was overly rigid.\385\ Although the
specific types of systems malfunctions have been removed from the
adopted definition of systems disruption, the Commission nonetheless
continues to believe, as suggested by one commenter,\386\ that the
types of systems malfunctions that comprised the proposed definition
may be useful to SCI entities to consider as indicia of a systems
disruption.
---------------------------------------------------------------------------

    \384\ The Commission notes that, for certain SCI systems,
``normal operation'' may include a certain degree of operational
variability that would allow for a given amount of degradation of
functionality (e.g., some data queuing or some slowing of response
times) before the system's operations reach the point of being
``significantly degraded.'' However, such variability parameters may
be included as part of an SCI entity's policies and procedures so
that the SCI entity and its personnel would be aware of them before
the occurrence of systems issues.
    \385\ Commenters highlighted many examples where a rigid
interpretation of the proposed definition had the potential to
incorporate into the definition events that could be considered part
of normal operation. See, e.g., supra notes 361, 364, 368, 369, 374,
and 379 and accompanying text. As adopted, however, such events
would not be captured by the definition of systems disruptions
because an event that disrupts, or significantly degrades, the
normal operation of an SCI system would not be considered the
``normal operation'' of such SCI system.
    \386\ See supra note 354 and accompanying text.

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

    As discussed in the SCI Proposal \387\ and by certain
commenters,\388\ the seven categories of malfunctions in the proposed
definition of ``systems disruption'' have their origin in ARP staff
guidance regarding when ARP participants should notify the Commission
of system outages and represent practical examples that SCI entities
should consider to be systems disruptions in many circumstances. The
Commission notes that the revised definition is intended to address
some commenters' concerns with the particular elements of the
definition of systems disruption as originally proposed. For example,
under the modified definition, if an SCI system experiences an
unplanned outage but fails over smoothly to its backup system such that
there is no disruption or significant degradation of the normal
operation of the system, the outage of the primary system would not
constitute a systems disruption. On the other hand, an SCI entity may
determine that, even when a primary system fails over smoothly to its
backup system such that users are not impacted by the failover,
operating from the backup system without additional redundancy would
not constitute normal operation. In this case, the outage of the
primary system would fall within the definition of systems disruption.
Further, the Commission believes it would be appropriate for an SCI
entity to take into account regularly scheduled outages or scheduled
maintenance as part of ``normal operations.'' \389\ In particular, a
planned disruption to an SCI system that is a part of regularly
scheduled outages or scheduled maintenance would not constitute a
systems disruption or be subject to the requirements of Regulation SCI,
if such regularly scheduled outages or scheduled maintenance are part
of the SCI entity's normal operations. With regard to data queuing, to
the extent that such queuing is part of the normal functionality of a
system and does not cause a disruption or significant degradation of
normal operations, it would not be captured by the rule, which is
limited to events occurring to an SCI system that are outside its
normal operations.\390\ Additionally, by eliminating the seven types of
malfunctions from the definition as proposed, the Commission has
responded to commenters who expressed concern that events that are
precursors to system disruptions, such as the queuing of data, would
themselves be systems disruptions.\391\ Similarly, by eliminating the
seven types of malfunctions, the Commission has addressed comments that
called for the elimination of specific elements of the proposed
definition, such as service level agreements.\392\
---------------------------------------------------------------------------

    \387\ See Proposing Release, supra note 13, at 18101.
    \388\ See supra note 353 and accompanying text.
    \389\ See supra note 361 and accompanying text.
    \390\ See supra notes 372-377 and accompanying text.
    \391\ See supra note 377 and accompanying text.
    \392\ See supra notes 355 and 358 and accompanying text.
---------------------------------------------------------------------------

    Further, the Commission agrees with commenters that customer
complaints may be indicia of a systems issue,\393\ but that a customer
complaint alone would not be determinative of whether a system problem
has occurred that meets the definition of systems disruption under
Regulation SCI.\394\ With respect to the commenters who stated that
losses of transaction or clearance and settlement data that are
immediately retrieved, promptly corrected, or, for clearance and
settlement data, resolved prior to the close of the trading day should
not be systems disruptions, the adopted definition would exclude these
events if they do not disrupt or significantly degrade the normal
operations of an SCI system.\395\ However, if loss of transaction or
clearance and settlement data disrupts or significantly degrades the
normal operation of an SCI system, it would constitute a systems
disruption and be subject to the requirements of Regulation SCI (e.g.,
immediate or quarterly Commission notification, depending on the impact
of the disruption).
---------------------------------------------------------------------------

    \393\ The Commission agrees, as noted by some commenters, that
in some instances, customer complaints may be the result of a
problem at a system not operated by (or on behalf of) an applicable
SCI entity, but rather a system operated by the customer itself. See
supra note 380 and accompanying text.
    \394\ See supra notes 379-380 and accompanying text.
    \395\ See supra note 368. The Commission notes that for
clearance and settlement systems, normal operations would include
all steps necessary to effectuate timely and accurate end of day
settlement. In response to the commenter who stated that the
definition of systems disruption should be revised to include data
that is altered or corrupted in some way, because the Commission has
determined to eliminate the pronged approach to the definition of
systems disruption, the Commission notes that, under the adopted
definition, data that is altered or corrupted in some way may be a
systems disruption if such altered or corrupted data disrupt or
significantly degrade the affected SCI system's normal operation.
See supra note 369.
---------------------------------------------------------------------------

    Several commenters also suggested that testing errors or other
disruptions in development and testing environments should be excluded
from the definition of systems disruption.\396\ The Commission notes
that, as discussed above, development and testing systems have been
excluded from the definition of SCI systems, and thus such disruptions
would not be subject to the requirements of Regulation SCI.\397\
---------------------------------------------------------------------------

    \396\ See supra notes 361-363 and accompanying text.
    \397\ See supra Section IV.A.2.b (discussing the definition of
``SCI systems'').
---------------------------------------------------------------------------

    The Commission is not incorporating a materiality threshold into
the definition of systems disruption as requested by some
commenters.\398\ Rather, as discussed below, the requirements of
Regulation SCI are tiered in a manner that the Commission believes is
responsive to commenters' concerns regarding the breadth of the
definition of systems disruption (while stopping short of including a
materiality standard).\399\ In particular, the Commission believes that
the adopted Commission notification and information dissemination
requirements for SCI events (i.e., quarterly Commission reporting of de
minimis systems disruptions, and an exception for de minimis systems
disruptions from the information dissemination requirement) will help
to focus the Commission's and SCI entities' resources on the more
significant systems disruptions. In addition, by not including a
materiality threshold within the definition, SCI entities will be
required to assess, take corrective action, and keep records of all
systems disruptions, some of which may initially seem insignificant to
an SCI entity, but which may later prove to be the cause of significant
systems disruptions at the SCI entity. An SCI entity's records of de
minimis systems disruptions may also be useful to the Commission in
that they may, for example, aid the Commission in identifying patterns
of de minimis systems disruptions that together might result in a more
impactful SCI event, either at an SCI entity or across a group of SCI
entities, or circumstances in which a systems disruption causes de
minimis systems issues for one particular SCI entity but results in
significant issues for another SCI entity. The Commission also believes
that the ability to view de minimis SCI events in the aggregate and
across multiple SCI

entities is important to the Commission and its staff to be able to
gather information about trends related to such systems disruptions
that could not otherwise be properly discerned. Information about
trends will assist the Commission in fulfilling its oversight role by
keeping Commission staff informed about the nature and frequency of the
types of de minimis systems disruptions that SCI entities encounter.
Moreover, information about trends can also inform the Commission of
areas of potential weaknesses, or persistent or recurring problems,
across SCI entities and also should help the Commission better focus on
common types of systems disruptions with certain types of SCI systems
across SCI entities. This information also would permit the Commission
and its staff to issue industry alerts or guidance if appropriate. In
addition, this information would allow the Commission and its staff to
review SCI entities' classification of events as de minimis systems
disruptions. Moreover, the Commission believes that, even without
adopting a materiality threshold, the adopted definition of SCI systems
further focuses the scope of the definition of systems disruption.\400\
---------------------------------------------------------------------------

    \398\ See supra note 347 and accompanying text.
    \399\ See Rule 1002(b)(5) and infra Section IV.B.3.c (discussing
the Commission notification requirement for SCI events and requiring
a quarterly summary report for de minimis systems disruptions). See
also Rule 1002(c)(4) and infra Section IV.B.3.d (discussing
information dissemination requirement for certain SCI events, but
excluding de minimis systems disruptions).
    \400\ See supra Sections IV.A.2.b (discussing the definition of
``SCI systems'').
---------------------------------------------------------------------------

    The Commission also believes that it is unnecessary to modify the
definition of systems disruption specifically to encompass disruptions
originating from a third party, as one commenter suggested.\401\ The
definition of systems disruption does not limit such events with
respect to the source of the disruption, whether an internal source at
the SCI entity or an external third party source.
---------------------------------------------------------------------------

    \401\ See supra note 345.
---------------------------------------------------------------------------

b. Systems Compliance Issue
    Proposed Rule 1000(a) would have defined the term ``systems
compliance issue'' as ``an event at an SCI entity that has caused any
SCI system of such entity to operate in a manner that does not comply
with the federal securities laws and rules and regulations thereunder
or the entity's rules or governing documents, as applicable.'' \402\
The Commission is adopting the definition of systems compliance issue
substantially as proposed, with modifications to refine its scope.
---------------------------------------------------------------------------

    \402\ See proposed Rule 1000(a) and Proposing Release, supra
note 13, at Section III.B.3.b.
---------------------------------------------------------------------------

    Two commenters stated that the term ``systems compliance issue''
should be deleted from the definition of SCI event entirely.\403\ One
of these commenters stated that the inclusion of systems compliance
issue as an SCI event would be a departure from the ARP Inspection
Program and ARP Policy Statements.\404\ The other commenter argued that
any report regarding a systems compliance issue is an admission that
the SCI entity has violated a law, rule, or one of its governing
documents, creating a risk of an enforcement action or other liability
for the SCI entity.\405\
---------------------------------------------------------------------------

    \403\ See Omgeo Letter at 13; and NYSE Letter at 16.
    \404\ See Omgeo Letter at 14.
    \405\ See NYSE Letter at 16.
---------------------------------------------------------------------------

    Other commenters stated that the proposed definition is too broad
and should be refined to include only those issues that are material or
significant.\406\ Commenters' specific recommendations included
limiting the definition to those systems compliance issues that: have a
material and significant effect on members; \407\ can be reasonably
expected to result in significant harm or loss to market participants
or impact the operation of a fair and orderly market; \408\ or have a
materially negative impact on the SCI entity's ability to perform its
core functions.\409\ One commenter also noted that the term should be
specifically defined to take account of an SCI entity's function, such
as clearing agencies' ability to comply with Section 17A.\410\
---------------------------------------------------------------------------

    \406\ See, e.g., Joint SROs Letter at 2, 8; ISE Letter at 6;
SIFMA Letter at 13; Liquidnet Letter at 3; CME Letter at 8; DTCC
Letter at 6; OCC Letter at 13; and FINRA Letter at 17 (stating that
systems compliance issues should be reportable only if they would
directly impact the market or a member firm's ability to comply with
FINRA rules). See also BATS Letter at 13.
    \407\ See ISE Letter at 6-7.
    \408\ See Liquidnet Letter at 3; and CME Letter at 8. See also
FINRA Letter at 17.
    \409\ See DTCC Letter at 6; and OCC Letter at 13.
    \410\ See DTCC Letter at 6. See also infra Sections IV.B.3.c and
IV.B.3.d (discussing comments with respect to systems compliance
issues and their relation to Commission notification and information
dissemination to members or participants).
---------------------------------------------------------------------------

    After considering the view of commenters that the proposed
definition of systems compliance issue is too broad,\411\ the
Commission is revising the definition to mean an event that has caused
an SCI system to operate ``in a manner that does not comply with the
Act'' and the rules and regulations thereunder and the entity's rules
and governing documents, as applicable.\412\ The Commission believes
the refinement from ``federal securities laws'' to ``the Act'' (i.e.,
the Securities Exchange Act of 1934) will appropriately focus the
definition on Exchange Act compliance rather than other areas of the
federal securities laws. Although the Commission did not receive
specific comment suggesting that it amend the definition of systems
compliance issue by using the term ``the Act'' instead of the broader
``federal securities laws,'' commenters did suggest that the Commission
limit the scope of the definition to only apply to those sections of
the Act that are applicable to a particular SCI entity \413\ or the SCI
entity's rules.\414\ The Commission agrees with these commenters
insofar as they advocated for focusing the scope to a more specific set
of securities laws and for reducing the burden on SCI entities, and
further believes this refinement does not compromise the objective of
the definition, which is to capture systems compliance issues with
respect to SCI entities' obligations under the Exchange Act. The
Commission believes that the refinement provides additional clarity to
SCI entities that, for purposes of Regulation SCI, their obligations
are with respect to compliance with the Exchange Act and the rules and
regulations thereunder and the entity's rules and governing
documents.\415\
---------------------------------------------------------------------------

    \411\ See supra note 406 and accompanying text.
    \412\ As noted above, proposed Rule 1000 defined systems
compliance issue as an event at an SCI entity that has caused any
SCI system of such entity to operate ``in a manner that does not
comply with the federal securities laws'' and rules and regulations
thereunder or the entity's rules and governing documents, as
applicable.
    \413\ See supra note 410 and accompanying text.
    \414\ See supra note 406 and accompanying text.
    \415\ Notwithstanding this provision's focus on compliance with
the Exchange Act and the rules and regulations thereunder and the
entity's rules and governing documents, the Commission notes that
its objective in adopting Regulation SCI is not, for example, to
change the obligations of SCI entities that are public companies
with respect to their disclosure obligations under the Securities
Act of 1933. See 15 U.S.C. 77a et seq.
---------------------------------------------------------------------------

    The Commission disagrees with commenters who suggested removing
systems compliance issues from the definition of SCI event
altogether.\416\ Although systems compliance issues have not been
within the scope of the ARP Inspection Program,\417\ the Commission
believes that inclusion of systems compliance issues in the definition
of SCI event and the resulting applicability of the Commission
reporting, information dissemination, and recordkeeping requirements to
systems compliance issues is important to help ensure that SCI systems
are operated by SCI entities in compliance with the Exchange Act, rules
thereunder, and their own rules and governing documents.
---------------------------------------------------------------------------

    \416\ See supra notes 403-405 and accompanying text.
    \417\ See supra note 404 and accompanying text. See also
Proposing Release, supra note 13, at 18087.

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

    In addition, the Commission is not adopting a materiality qualifier
\418\ or other limiting threshold \419\ in the definition of systems
compliance issue as suggested by some commenters. Instead, the
requirements of Regulation SCI are tiered in a manner that the
Commission believes is responsive to commenters' concerns regarding the
breadth of the definition of systems compliance issue.\420\ In
particular, the Commission believes that the adopted Commission
notification requirement and the information dissemination requirement
(each of which provides an exception for systems compliance issues that
have no or de minimis impacts on an SCI entity's operations or market
participants) will help to focus the Commission's and SCI entities'
resources on those systems compliance issues with more significant
impacts. In addition, by not including a materiality threshold within
the definition, SCI entities will be required to assess, take
corrective action, and keep records of all systems compliance issues,
some of which may initially seem to have little or no impact, but which
may later prove to be the cause of significant systems compliance
issues at the SCI entity. The Commission notes that all SCI entities
are required to comply with the Exchange Act, the rules and regulations
thereunder, and their own rules, as applicable. Therefore, even if an
SCI entity determines that a systems compliance issue has no or a de
minimis impact, the Commission believes that it is important that it
have ready access to records regarding such de minimis systems
compliance issues to allow it to more effectively oversee SCI entities'
compliance with the Exchange Act and relevant rules. An SCI entity's
records of de minimis systems compliance issues may also be useful to
the Commission in that they may, for example, aid the Commission in
identifying areas of potential weaknesses, or persistent or recurring
problems, at an SCI entity or across multiple SCI entities. This
information also would permit the Commission and its staff to issue
industry alerts or guidance if appropriate. In addition, this
information would allow the Commission and its staff to review SCI
entities' classification of events as de minimis systems compliance
issues.
---------------------------------------------------------------------------

    \418\ See supra notes 406-407 and 409 and accompanying text.
    \419\ See supra note 408.
    \420\ See Rule 1002(b)(5) and infra Section IV.B.3.c (discussing
the Commission notification requirement for SCI events and the
exclusion for de minimis systems compliance issues). See also Rule
1002(c)(4) and infra Section IV.B.3.d (discussing the information
dissemination requirement for certain SCI events, but excluding de
minimis systems compliance issues).
---------------------------------------------------------------------------

    Finally, the Commission believes that, even without adopting a
materiality threshold, the adopted definition of SCI systems, as
described in Section IV.A.2 above, further focuses the scope of the
definition of systems compliance issue.
    With respect to a commenter's concern that any report regarding a
systems compliance issue would be an admission of a violation and thus
create a risk of enforcement action or other liability,\421\ the
Commission notes that the Commission notification requirement is not
triggered until a responsible SCI personnel has a reasonable basis to
conclude that a systems compliance issue has occurred.\422\ The
Commission acknowledges that it could consider the information provided
to the Commission in determining whether to initiate an enforcement
action. However, the Commission notes that the occurrence of a systems
compliance issue also does not necessarily mean that the SCI entity
will be subject to an enforcement action. Rather, the Commission will
exercise its discretion to initiate an enforcement action if the
Commission determines that action is warranted, based on the particular
facts and circumstances of an individual situation.\423\ With respect
to the potential for other types of liability as suggested by this
commenter, many entities that fall within the definition of SCI entity
already currently disclose to the Commission and their members or
participants certain information regarding systems issues, including
issues that may potentially give rise to liability.\424\ Moreover, the
Commission recognizes that compliance with Regulation SCI will increase
the amount of information about SCI events available to the Commission
and SCI entities' members and participants, and that the greater
availability of this information has some potential to increase
litigation risks for SCI entities, including the risk of private civil
litigation. The Commission believes that the value of disclosure to the
Commission, market participants and investors justifies the potential
increase in litigation risk. Moreover, the Commission notes that, to
the extent members and participants or the public suffer damages when
SCI events occur, SCI entities are already subject to litigation risk.
---------------------------------------------------------------------------

    \421\ See supra note 405 and accompanying text.
    \422\ See supra Section IV.B.3.a (discussing the triggering
standard).
    \423\ See, e.g., infra notes 626-628 and accompanying text.
    \424\ See supra Section II.B (discussing recent events related
to systems issues).
---------------------------------------------------------------------------

    As adopted, Rule 1000 defines ``systems compliance issue'' as ``an
event at an SCI entity that has caused any SCI system of such entity to
operate in a manner that does not comply with the Act and the rules and
regulations thereunder or the entity's rules or governing documents, as
applicable.'' As noted in the SCI Proposal, a systems compliance issue
could, for example, occur when a change to an SCI system is made by
information technology staff, without the knowledge or input of
regulatory staff, that results in the system operating in a manner that
does not comply with the Act and rules thereunder or the entity's rules
and other governing documents.\425\ For an SCI SRO, systems compliance
issues would include SCI systems operating in a manner that does not
comply with the SCI SRO's rules as defined in the Act and the rules
thereunder.\426\ For a plan processor, systems compliance issue would
include SCI systems operating in a manner that does not comply with an
applicable effective national market system plan. For an SCI ATS or
exempt clearing agency subject to ARP, a systems compliance issue would
include SCI systems operating in a manner that does not comply with
documents such as subscriber agreements and any rules provided to
subscribers and users and, for an ATS, described in its Form ATS
filings with the Commission.\427\
---------------------------------------------------------------------------

    \425\ See Proposing Release, supra note 13, at 18103.
    \426\ The rules of an SCI SRO include, among other things, its
constitution, articles of incorporation, and bylaws. See 15 U.S.C.
78c(a)(27)-(28). See also 17 CFR 240.19b-4(c).
    \427\ Subscriber agreements and other similar documents that
govern operations of SCI ATSs and exempt clearing agencies subject
to ARP are generally not publicly available, but are typically
provided to subscribers and users of such entities. See 17 CFR
242.301(b) for a description of the filing requirements for ATSs.
---------------------------------------------------------------------------

c. Systems Intrusion
    Proposed Rule 1000(a) defined ``systems intrusion'' as ``any
unauthorized entry into the SCI systems or SCI security systems of an
SCI entity.'' \428\ The proposed definition is being adopted as
proposed, with one technical modification to replace the term ``SCI
security systems'' with ``indirect SCI systems.'' \429\
---------------------------------------------------------------------------

    \428\ See proposed Rule 1000(a) and Proposing Release, supra
note 13, at Section III.B.3.c.
    \429\ See supra Section IV.A.2.d (discussing the definition of
``indirect SCI systems'').
---------------------------------------------------------------------------

    While one commenter noted its general support for the inclusion of
systems intrusions within the scope of

Regulation SCI,\430\ this commenter and others stated that the proposed
definition was too broad or vague.\431\ Several commenters asserted
that the proposed definition would capture too many insignificant and
minor incidents.\432\ Some commenters recommended limiting the
definition to material systems intrusions, and offered various
suggestions for how to do so.\433\
---------------------------------------------------------------------------

    \430\ See NYSE Letter at 15.
    \431\ See, e.g., NYSE Letter at 15; BATS Letter at 12; DTCC
Letter at 7; Omgeo Letter at 11; SIFMA Letter at 10-11; and Joint
SROs Letter at 7.
    \432\ See, e.g., BATS Letter at 12; DTCC Letter at 7; Omgeo
Letter at 11; SIFMA Letter at 10-11; and Joint SROs Letter at 7.
    \433\ See, e.g., NYSE Letter at 15 (recommending that the
definition include only major intrusions that pose a plausible risk
to the trading, routing, or clearance and settlement operations of
the exchange or to required market data transmission); Omgeo Letter
at 11-12 (expressing concern that the definition did not contain a
reference to the materiality of an intrusion, nor the intrusion's
impact on markets or market participants); DTCC Letter at 7
(suggesting that the definition capture only unauthorized entries
where the SCI entity has reason to believe such entry could
materially impact its ability to perform its core functions or
critical operations); Joint SROs Letter at 7 (stating that the
definition should include only those intrusions that the SCI entity
reasonably estimated would result in significant harm or loss to
market participants); FINRA Letter at 18 (arguing that only
intrusions that have a material impact on the SCI system or a direct
impact on the market or market participants should be included); and
OCC Letter at 13 (suggesting, as an alternative to a ``risk-based''
approach, that the definition be limited to any unauthorized entry
into the SCI systems or SCI security systems of an SCI entity, which
the SCI entity reasonably believes may materially impact its ability
to perform its core functions or critical operations).
---------------------------------------------------------------------------

    One commenter stated that the proposed definition was overbroad
because it would include both intentional and unintentional conduct, as
well as events that have no adverse impact.\434\ Another commenter also
stated that the definition should be modified to make clear that an
intrusion that is inadvertent would not qualify as a systems
intrusion.\435\ This commenter further stated that a systems intrusion
should be limited to unauthorized access to confidential information or
to the SCI systems of an SCI entity that materially disrupts the
operations of such systems.\436\ Another commenter suggested that the
definition focus on the unauthorized control of the confidentiality,
integrity, or availability of an SCI system and/or its data.\437\
---------------------------------------------------------------------------

    \434\ See, e.g., BATS Letter at 12.
    \435\ See SIFMA Letter at 11.
    \436\ See id.
    \437\ See NYSE Letter at 15.
---------------------------------------------------------------------------

    Some commenters noted that the proposed definition of systems
intrusion did not take into account the multi-layered nature of today's
technology systems. Two commenters stated that the multi-layered
protections of systems architecture are designed to anticipate
intrusions into the outer layer without material risk or impact, thus
intrusions into such a peripheral system should not constitute a
systems intrusion under the rule.\438\
---------------------------------------------------------------------------

    \438\ See SIFMA Letter at 11; and Omgeo Letter at 12. The
Commission discusses below the comments that advocated greater
Commission use of FS-ISAC for reporting systems intrusions.
---------------------------------------------------------------------------

    Several commenters stated that only successful systems intrusions
should be covered in the definition.\439\ One commenter suggested that
this concept be made explicit in the rule text by adding the term
``successful'' to the definition.\440\ Two commenters, while supporting
the inclusion of only successful systems intrusions in the definition,
pointed out the value of sharing information regarding unsuccessful
systems intrusions, stating that this practice already occurs today
among SCI entities, their regulators, and appropriate law enforcement
agencies.\441\
---------------------------------------------------------------------------

    \439\ See BIDS Letter at 17; SIFMA Letter at 11; NYSE Letter at
15; DTCC Letter at 8.
    \440\ See NYSE Letter at 15.
    \441\ See BIDS Letter at 17; and DTCC Letter at 8.
---------------------------------------------------------------------------

    As adopted, Rule 1000 defines ``systems intrusion'' to mean ``any
unauthorized entry into the SCI systems or indirect SCI systems of an
SCI entity.'' This definition is intended to cover any unauthorized
entry into SCI systems or indirect SCI systems, regardless of the
identity of the person committing the intrusion (whether they are
outsiders, employees, or agents of the SCI entity), and regardless of
whether or not the intrusion was part of a cyber attack, potential
criminal activity, or other unauthorized attempt to retrieve,
manipulate, or destroy data, or access or disrupt systems of SCI
entities. Thus, for example, this definition is intended to cover the
introduction of malware or other attempts to disrupt SCI systems or
indirect SCI systems provided that such systems were actually breached.
In addition, the definition is intended to cover unauthorized access,
whether intentional or inadvertent, by employees or agents of the SCI
entity that resulted from weaknesses in the SCI entity's access
controls and/or procedures. In response to comments, the Commission
emphasizes that the definition of systems intrusion does not include
unsuccessful attempts at unauthorized entry because an unsuccessful
systems intrusion is much less likely to disrupt the systems of an SCI
entity than a successful intrusion. The Commission believes that it is
unnecessary and redundant to specifically state in the definition of
systems intrusion that unauthorized entries must be ``successful''
because the term ``entry'' incorporates the concept of successfully
gaining access to an SCI system or indirect SCI system.
    Further, the Commission is not incorporating a materiality
threshold for the definition of systems intrusion or otherwise limiting
the definition of systems intrusion to only those systems intrusions
that are major or significant as requested by some commenters. The
Commission believes that, even without adopting a materiality
threshold, the adopted definitions of SCI systems and indirect SCI
systems further focus the scope of the definition of systems intrusion.
Further, because any unauthorized entry into an SCI system or indirect
SCI system is a security breach of which the Commission, having
responsibility for oversight of the U.S. securities markets, should be
notified, the Commission is not including a materiality threshold. In
addition, as discussed below, the requirements of Regulation SCI are
tiered in a manner that the Commission believes is responsive to
commenters' concerns regarding the breadth of the definition of systems
intrusion.\442\ By not including a materiality threshold within the
definition, SCI entities will be required to assess, take corrective
action, and keep records of all systems intrusions, some of which may
initially seem insignificant to an SCI entity, but which may later
prove to be the cause of significant systems issues at the SCI entity.
An SCI entity's records of de minimis systems intrusions may also be
useful to the Commission in that they may, for example, aid the
Commission in identifying patterns of de minimis systems intrusions
that together might result in a more impactful SCI event, either at an
SCI entity or across a group of SCI entities, or circumstances in which
a systems intrusion causes de minimis systems issues for one particular
SCI entity but results in significant issues for another SCI entity.
The Commission also believes that the ability to view de minimis
systems intrusions in the aggregate and across multiple SCI entities is
important to allow the Commission and its staff to be able to gather
information about trends related to such systems intrusions that could
not otherwise be properly discerned. Information about trends will

assist the Commission in fulfilling its oversight role by keeping
Commission staff informed about the nature and frequency of the types
of de minimis systems intrusions that SCI entities encounter. Moreover,
information about trends and notifications of de minimis systems
intrusions generally can also inform the Commission of areas of
potential weaknesses, or persistent or recurring problems, across SCI
entities and also should help the Commission better focus on common
types of systems intrusions or issues with certain types of SCI systems
across SCI entities. This information also would permit the Commission
and its staff to issue industry alerts or guidance if appropriate. In
addition, this information would allow the Commission and its staff to
review SCI entities' classification of events as de minimis systems
intrusions.
---------------------------------------------------------------------------

    \442\ See Rule 1002(b)(5) and infra Section IV.B.3.c (discussing
the Commission notification requirement for SCI events and requiring
a quarterly summary report for de minimis systems intrusions). See
also Rule 1002(c)(4) and infra Section IV.B.3.d (discussing
information dissemination requirement for certain SCI events, but
excluding de minimis systems intrusions).
---------------------------------------------------------------------------

    The Commission also is not distinguishing between intentional and
unintentional systems intrusions, as suggested by some commenters.\443\
The Commission acknowledges that intentional systems intrusions may
result in more severe disruptions to the systems of an SCI entity than
unintentional or inadvertent intrusions. On the other hand, the
Commission believes that it should be notified of successful
unintentional or inadvertent systems intrusions because they can still
indicate weaknesses in a system's security controls. To the extent that
these systems intrusions have no or a de minimis impact on the SCI
entity's operations or on market participants, they will only be
subject to a quarterly reporting requirement and will be excepted from
the information dissemination requirement.\444\
---------------------------------------------------------------------------

    \443\ See supra notes 434-435 and accompanying text.
    \444\ See Rule 1002(b)(5) and infra Section IV.B.3.c (discussing
the Commission notification requirement for SCI events and requiring
a quarterly summary report for de minimis systems intrusions). See
Rule 1002(c)(4), and infra Sections IV.B.3.d (discussing the
information dissemination requirements for certain SCI events, but
excluding de minimis systems intrusions).
---------------------------------------------------------------------------

    Additionally, the Commission does not agree that the definition of
systems intrusion should be limited to unauthorized access to
confidential information \445\ or should be focused on the unauthorized
control of the confidentiality, integrity, or availability of an SCI
system and/or its data \446\ because the Commission believes that these
modifications would create a definition that would limit the
Commission's ability to be aware of events that fall outside the
limited definition that commenters suggested but that could, for
example, have industry-wide implications. Similarly, with respect to
the comment that intrusions into a peripheral system should not
constitute a systems intrusion because the multi-layered protections of
systems architecture are designed to anticipate intrusions into the
outer layer and help prevent material risk or impact,\447\ the
Commission believes that its discussion of indirect SCI systems in
Section IV.A.2.d above responds to commenters' concerns by explaining
that systems intrusions into an indirect SCI system could cause or
increase the likelihood of an SCI event with respect to an SCI system.
And to the extent a system intrusion occurs with respect to an SCI
system or indirect SCI system but the SCI entity's multi-layered
systems architecture helps prevent material risk or impact, the
Commission notes that de minimis systems intrusions (if such a system
intrusion was determined to be de minimis) would be subject to less
frequent Commission reporting requirements and would not be subject to
the information dissemination requirements.
---------------------------------------------------------------------------

    \445\ See supra note 436 and accompanying text.
    \446\ See supra note 437 and accompanying text.
    \447\ See supra note 438 and accompanying text.
---------------------------------------------------------------------------

B. Obligations of SCI Entities--Rules 1001-1004

    Proposed Rules 1000(b)(1)-(9) are renumbered as adopted Rules 1001-
1004. Adopted Rule 1001 corresponds to proposed Rules 1000(b)(1)-(2)
and contains the policies and procedures requirements for SCI entities
with respect to operational capability and the maintenance of fair and
orderly markets (Rule 1001(a)), systems compliance (Rule 1001(b)), and
identification and designation of responsible SCI personnel and
escalation procedures (Rule 1001(c)).\448\ Adopted Rule 1002
corresponds to proposed Rules 1000(b)(3)-(5) and contains the
obligations of SCI entities with respect to SCI events, which include
corrective action, Commission notification, and information
dissemination. Adopted Rule 1003 corresponds to proposed Rules
1000(b)(6)-(8) and contains requirements relating to material systems
changes and SCI reviews. Finally, adopted Rule 1004 corresponds to
proposed Rule 1000(b)(9) and contains requirements relating to business
continuity and disaster recovery plan testing, including requiring
participation of designated members or participants of SCI entities in
such testing.
---------------------------------------------------------------------------

    \448\ The discussion of Rule 1001(c), which relates to the
triggering standard for Rule 1002, is discussed below in Section
IV.B.3.a.
---------------------------------------------------------------------------

1. Policies and Procedures To Achieve Capacity, Integrity, Resiliency,
Availability and Security--Rule 1001(a)
a. Proposed Rule 1000(b)(1)
    Proposed Rule 1000(b)(1) would have required an SCI entity to: (1)
Establish, maintain, and enforce written policies and procedures
reasonably designed to ensure that its SCI systems and, for purposes of
security standards, SCI security systems, have levels of capacity,
integrity, resiliency, availability, and security, adequate to maintain
the SCI entity's operational capability and promote the maintenance of
fair and orderly markets; and (2) include certain required elements in
such policies and procedures. As proposed, these policies and
procedures were required to provide for: (A) The establishment of
reasonable current and future capacity planning estimates; (B) periodic
capacity stress tests of systems to determine their ability to process
transactions in an accurate, timely, and efficient manner; (C) a
program to review and keep current systems development and testing
methodology; (D) regular reviews and testing of systems, including
backup systems, to identify vulnerabilities pertaining to internal and
external threats, physical hazards, and natural or manmade disasters;
(E) business continuity and disaster recovery plans that include
maintaining backup and recovery capabilities sufficiently resilient and
geographically diverse to ensure next business day resumption of
trading and two-hour resumption of clearance and settlement services
following a wide-scale disruption; and (F) standards that result in
systems being designed, developed, tested, maintained, operated, and
surveilled in a manner that facilitates the successful collection,
processing, and dissemination of market data.
    Proposed Rule 1000(b)(1)(i) also provided that an SCI entity's
applicable policies and procedures would be deemed to be reasonably
designed if they were consistent with ``current SCI industry
standards.'' Proposed Rule 1000(b)(1)(ii) provided that ``current SCI
industry standards'' were to be comprised of ``information technology
practices that are widely available for free to information technology
professionals in the financial sector . . . and issued by an
authoritative body that is a U.S. governmental entity or agency,
association of U.S. governmental entities or agencies, or widely

recognized organization.'' \449\ The SCI Proposal also included, on
``Table A,'' a list of publications that the Commission had
preliminarily identified as examples of current SCI industry standards
in each of nine information security domains.\450\ The SCI Proposal
stated that an SCI entity, taking into account its nature, size,
technology, business model, and other aspects of its business, could,
but would not be required to, use the publications listed on Table A to
establish, maintain, and enforce reasonably designed policies and
procedures that satisfy the requirements of proposed Rule
1000(b)(1).\451\ The SCI Proposal also stated that ``current SCI
industry standards'' were not limited to those identified in the
publications on Table A and could include other publications meeting
the proposed criteria for ``current SCI industry standards.'' \452\ In
addition, proposed Rule 1000(b)(1)(ii) stated that compliance with
``current SCI industry standards'' would not be the exclusive means to
comply with the requirements of proposed Rule 1000(b)(1).\453\
---------------------------------------------------------------------------

    \449\ See Proposing Release, supra note 13, at 18178.
    \450\ The domains covered in Table A of the SCI Proposal are:
application controls; capacity planning; computer operations and
production environment controls; contingency planning; information
security and networking; audit; outsourcing; physical security; and
systems development methodology. See id. at 18111.
    \451\ See id. at 18110.
    \452\ See id. at 18110 (stating that an SCI entity could elect
standards contained in publications other than those identified on
proposed Table A to comply with the rule).
    \453\ See id. at 18109.
---------------------------------------------------------------------------

b. Comments Received on Proposed Rule 1000(b)(1) and Commission
Response
i. Policies and Procedures Generally--Rules 1001(a)(1) and (3)
    The Commission received a wide range of comments on proposed Rule
1000(b)(1). With respect to policies and procedures generally, some
commenters believed the proposal was too prescriptive.\454\ Several
characterized it as a ``one-size-fits-all'' approach that did not
adequately take into account differences between SCI entities and SCI
entity systems.\455\ Several commenters objecting to the rule as too
prescriptive urged that the adopted rule incorporate a risk-based
framework, so that SCI entities and/or systems of greater criticality
would be required to adhere to a stricter set of policies and
procedures than SCI entities and/or systems of lesser criticality.\456\
These commenters maintained that each SCI entity should have discretion
to calibrate its policies and procedures based on its own assessment of
the criticality of the SCI entity and its systems to market stability,
or that the Commission should ``tier'' the obligations of SCI entities
or SCI entity systems based on their market function.\457\
---------------------------------------------------------------------------

    \454\ See, e.g., Angel Letter at 2, 8; BIDS Letter at 7; FIF
Letter at 3-4; Joint SROs Letter at 4; LiquidPoint Letter at 3-4;
MFA Letter at 3; and SIFMA Letter at 12-13.
    \455\ See, e.g., FIF Letter at 3-4; FINRA Letter at 31; Joint
SROs Letter at 4; KCG Letter at 2-3, 6-8; Liquidpoint Letter at 3-4;
MFA Letter at 3; OCC Letter at 3-4; SIFMA Letter at 12-13; UBS
Letter at 2-4; Tellefsen Letter at 13; and BIDS Letter at 2-3, 6-9.
    \456\ See, e.g., Joint SROs Letter at 4; LiquidPoint Letter at
3; MFA Letter at 3; and SIFMA Letter at 8, 12-13. See also FIF
Letter at 4; MSRB Letter at 3; Fidelity Letter at 2; NYSE Letter at
3, 4, 21; FINRA Letter at 13-14; and OCC Letter at 3.
    \457\ See, e.g., Joint SROs Letter at 4; FINRA Letter at 13-14;
MSRB Letter at 3; MFA Letter at 6; NYSE Letter at 3, 4, and 21;
SIFMA Letter at 12-13; FIF Letter at 4; Fidelity Letter at 2; and
OCC Letter at 3.
---------------------------------------------------------------------------

    In contrast, some commenters stated that the Commission's proposed
approach was too vague or insufficient.\458\ For example, one commenter
characterized the minimum elements of policies and procedures in
proposed Rule 1000(b)(1)(A)-(F) as ``so vague that they will fail to
provide any meaningful improvement in technological systems.'' \459\
Another commenter stated that the proposed scope of required policies
and procedures was appropriate, but that further elaboration on the
details was warranted.\460\ One commenter stated that the proposed rule
lacked adequate discussion of what it means for policies and procedures
to be reasonably designed ``to maintain . . . operational capability
and promote the maintenance of fair and orderly markets.'' \461\
---------------------------------------------------------------------------

    \458\ See Better Markets Letter at 3-5; CAST Letter at 4; CISQ
Letter at 2, 5; CISQ2 Letter at 5; and Direct Edge Letter at 4.
    \459\ See Better Markets Letter at 3.
    \460\ See CISQ Letter at 2.
    \461\ See Direct Edge Letter at 4.
---------------------------------------------------------------------------

    The Commission has carefully considered the views of commenters on
its proposed policies and procedures approach to ensuring adequate
capacity, integrity, resiliency, availability, and security of SCI
systems (and security for indirect SCI systems). The Commission agrees
with commenters who stated that requiring SCI entities to have policies
and procedures relating to the capacity, integrity, resiliency,
availability, and security of SCI systems (and security for indirect
SCI systems) should not be a ``one-size-fits-all'' approach and, as
discussed in detail below, is therefore clarifying that the adopted
rule is consistent with a risk-based approach, as it allows an SCI
entity's policies and procedures to be tailored to a particular
system's criticality and risk. As noted above, while some commenters
characterized the proposed rule as too vague and sought further
specificity, others found the rule to be too prescriptive. The
Commission believes that the adopted rule provides an appropriate
balance between these two opposing concerns by providing a framework
that identifies the minimum areas that are required to be addressed by
an SCI entity's policies and procedures without prescribing the
specific policies and procedures that an SCI entity must follow, or
detailing how each element in Rule 1001(a)(2) should be addressed.
Given the various types of systems at SCI entities, each of which
represent a different level of criticality and risk to each SCI entity
and to the securities markets more broadly, the adopted rule seeks to
provide flexibility to SCI entities to design their policies and
procedures consistent with a risk-based approach, as discussed in
further detail below. At the same time, because the Commission believes
that additional guidance on how an SCI entity may comply with the rule
is warranted in certain areas, the Commission is providing further
guidance below. In response to comment, the Commission is adopting Rule
1001(a) with modifications that it believes will better provide SCI
entities with sufficient flexibility to develop their policies and
procedures to achieve robust systems, while also providing guidance on
how an SCI entity may comply with the final rule. Specifically, adopted
Rule 1001(a) is modified to: (i) Clarify that the rule is consistent
with a risk-based approach that requires more robust policies and
procedures for higher-risk systems and provides an SCI entity with
flexibility to tailor its policies and procedures to the nature of its
business, technology, and the relative criticality of each of its SCI
systems; (ii) make clear that an SCI entity's reasonable policies and
procedures remain subject to ongoing self-assessment; (iii) provide
increased flexibility in the manner in which an SCI entity may satisfy
the minimum elements of required policies and procedures; and (iv)
revise the criteria for ``current SCI industry standards.'' In
addition, proposed Table A is recharacterized and will be issued as
staff guidance that will evolve over time.
Response to Commenters Advocating a Risk-Based Approach
    Adopted Rule 1001(a)(1) requires each SCI entity to establish,
maintain, and enforce written policies and procedures

reasonably designed to ensure that its SCI systems and, for purposes of
security standards, indirect SCI systems, have levels of capacity,
integrity, resiliency, availability, and security, adequate to maintain
the SCI entity's operational capability and promote the maintenance of
fair and orderly markets. The text of this part of the rule is largely
unchanged from the proposal. Although several commenters expressed
concern that the proposed rule would have imposed a ``one-size-fits-
all'' approach, requiring all SCI entities to hold all of their SCI
systems to the same standards,\462\ this was not the intent of proposed
Rule 1000(b)(1), nor is it what adopted Rule 1001(a)(1) requires. By
requiring an SCI entity to have policies and procedures ``reasonably
designed'' and ``adequate'' to maintain operational capability and
promote the maintenance of fair and orderly markets, the adopted rule
provides an SCI entity with flexibility to determine how to tailor its
policies and procedures to the nature of its business, technology, and
the relative criticality of each of its SCI systems.\463\ Although the
adopted rule does not assign differing obligations to an SCI entity
based on its registration status, or its general market function, as
some commenters urged, by allowing each SCI entity to tailor its
policies and procedures accordingly, the adopted approach recognizes
that there are differences between, and varying roles played by,
different systems at various SCI entities. In tandem with the refined
definition of ``SCI systems,'' the modified definition of ``SCI
security systems'' (adopted as ``indirect SCI systems''), and the new
definition of ``critical SCI systems,\464\ adopted Rule 1001(a)(1)
explicitly recognizes that policies and procedures that are
``reasonably designed'' and ``adequate'' to maintain operational
capability and promote the maintenance of fair and orderly markets for
critical SCI systems may differ from those that are ``reasonably
designed'' and ``adequate'' to maintain operational capability and
promote the maintenance of fair and orderly markets for other SCI
systems, or indirect SCI systems. As such, the Commission believes that
its adopted approach in Regulation SCI is consistent with a risk-based
approach, and that adopted Regulation SCI may result in the systems of
certain SCI entities (for example, those that have few or no critical
SCI systems) generally being subject to less stringent policies and
procedures than the systems of other SCI entities. Thus, a risk
assessment is appropriate for an SCI entity to determine how to tailor
its policies and procedures for its SCI systems and indirect SCI
systems.
---------------------------------------------------------------------------

    \462\ See supra note 455 and accompanying text.
    \463\ See Proposing Release, supra note 13, at 18109 (stating:
``The Commission intends to . . . provide SCI entities sufficient
flexibility, based on the nature, size, technology, business model,
and other aspects of their business, to identify appropriate
policies and procedures that would meet the articulated standard,
namely that they be reasonably designed to ensure that their systems
have levels of capacity, integrity, resiliency, availability, and
security adequate to maintain the SCI entity's operational
capability and promote the maintenance of fair and orderly
markets.'').
    \464\ As a result of these changes, the adopted rule applies to
fewer systems than as proposed, and only to those types of systems
that the Commission believes pose significant risk to market
integrity if not adequately safeguarded.
---------------------------------------------------------------------------

    The Commission also believes that requiring an SCI entity to tailor
its policies and procedures so that they are reasonably designed and
adequate will entail that an SCI entity assess the relative criticality
and risk of each of its SCI systems and indirect SCI systems.
Evaluation of the risk posed by any particular SCI system to the SCI
entity's operational capability and the maintenance of fair and orderly
markets will be the responsibility of the SCI entity in the first
instance. The Commission believes this approach will achieve the goal
of improving Commission review and oversight of U.S. securities market
infrastructure, but will do so within a more focused framework than as
proposed. By being subject to requirements for a more targeted set of
SCI systems, and guided by consideration of the relative risk of each
of its SCI systems, SCI entities may more easily determine how to
allocate their resources to achieve compliance with the regulation than
they would have under the proposed regulation.
    As noted above, one commenter urged the Commission to discuss what
it means for policies and procedures to be reasonably designed ``to
maintain . . . operational capability and promote the maintenance of
fair and orderly markets.'' \465\ This commenter characterized the
proposed standard of ``maintaining operational capability'' as an
``introspective standard relevant to the applicable SCI entity,'' and
the proposed standard of ``promoting the maintenance of fair and
orderly markets'' as implying ``some incremental responsibility to the
collective market.'' \466\ The Commission agrees with this commenter's
characterization and believes that it is appropriate for SCI entities
to assess the risk of their systems taking into consideration both
objectives, which are related and complementary.\467\ Specifically, the
Commission believes that it is important that an SCI entity's policies
and procedures are reasonably designed to ensure its own operational
capability, including the ability to maintain effective operations,
minimize or eliminate the effect of performance degradations, and have
sufficient backup and recovery capabilities. At the same time, an SCI
entity's own operational capability can have broader effects and, as
entities that play a significant role in the U.S. securities markets
and/or have the potential to impact investors, the overall market, or
the trading of individual securities,\468\ the Commission believes that
the policies and procedures should also be reasonably designed to
promote the maintenance of fair and orderly markets.
---------------------------------------------------------------------------

    \465\ See supra note 461 and accompanying text.
    \466\ See Direct Edge Letter at 4.
    \467\ The Commission notes that the identification of ``critical
SCI systems'' in Regulation SCI emphasizes that some systems pose
greater risk than others to the maintenance of fair and orderly
markets if they malfunction, and that it is appropriate for an SCI
entity to consider the risk to other SCI entities and market
participants in the event of a systems malfunction.
    \468\ See supra note 59 and accompanying text.
---------------------------------------------------------------------------

Periodic Review
    Some commenters expressed concern that, when an SCI entity's
policies and procedures fail to prevent an SCI event, the Commission
might use such failure as the basis for an enforcement action, charging
that the policies and procedures were not reasonable.\469\ One
commenter suggested that the Commission's focus should be on an
entity's adherence to its own set of policies and procedures, developed
based on ``experience, annual SCI reviews, and other inputs,'' rather
than a ``set of generic standards.'' \470\
---------------------------------------------------------------------------

    \469\ See, e.g., BATS Letter at 3-4; Angel Letter at 2; and FSR
Letter at 5. See also ITG Letter at 14 (stating that no set of
policies and procedures could guarantee perfect operational
compliance); and NYSE Letter at 32 (urging inclusion of a good faith
safe harbor).
    \470\ See FIF Letter at 4.
---------------------------------------------------------------------------

    In response to these comments, the Commission notes that the
reasonably designed policies and procedures approach taken in adopted
Rule 1001(a) does not require an entity to guarantee flawless systems.
But the Commission believes it should be understood to require
diligence in maintaining a reasonable set of policies and procedures
that keeps pace with changing technology and circumstances and does not
become outdated over time. The Commission is therefore adopting a
requirement for periodic review by an SCI entity of the effectiveness
of its policies and procedures required by Rule 1001(a), and prompt
action by the SCI entity to

remedy deficiencies in such policies and procedures.\471\ An SCI entity
will not be found to be in violation of this maintenance requirement
solely because it failed to identify a deficiency in its policies and
procedures immediately after the deficiency occurred if the SCI entity
takes prompt action to remedy the deficiency once it is discovered, and
the SCI entity had otherwise reviewed the effectiveness of its policies
and procedures and took prompt action to remedy those deficiencies that
were discovered, as required by Rule 1001(a)(3).
---------------------------------------------------------------------------

    \471\ See Rule 1001(a)(3).
---------------------------------------------------------------------------

    Further, the occurrence of a systems disruption or systems
intrusion will not necessarily mean that an SCI entity has violated
Rule 1001(a), or that it will be subject to an enforcement action for
violation of Regulation SCI. The Commission will exercise its
discretion to initiate an enforcement action if the Commission
determines that such action is warranted, based on the particular facts
and circumstances. While a systems problem may be probative as to the
reasonableness of an SCI entity's policies and procedures, it is not
determinative.
ii. Minimum Elements of Reasonable Policies and Procedures--Rule
1001(a)(2)
    Proposed Rule 1000(b)(1)(i) would have required that an SCI
entity's policies and procedures provide for, at a minimum: (A) The
establishment of reasonable current and future capacity planning
estimates; (B) periodic capacity stress tests of systems to determine
their ability to process transactions in an accurate, timely, and
efficient manner; (C) a program to review and keep current systems
development and testing methodology; (D) regular reviews and testing of
systems, including backup systems, to identify vulnerabilities
pertaining to internal and external threats, physical hazards, and
natural or manmade disasters; (E) business continuity and disaster
recovery plans that include maintaining backup and recovery
capabilities sufficiently resilient and geographically diverse to
ensure next business day resumption of trading and two-hour resumption
of clearance and settlement services following a wide-scale disruption;
and (F) standards that result in systems being designed, developed,
tested, maintained, operated, and surveilled in a manner that
facilitates the successful collection, processing, and dissemination of
market data. References to ``systems'' in the proposed rule were to the
proposed definition of SCI systems, and with respect to security
standards only, the proposed definition of SCI security systems.
    Adopted Rule 1001(a)(2) includes the items formerly proposed as
Rules 1001(b)(1)(i)(A)-(F) as renumbered Rules 1001(2)(i)-(vi) and a
new item (vii), relating to monitoring of SCI systems. Proposed items
(A), (D), and (E) are revised in certain respects in response to
comment. In addition, the Commission discusses below each of the
adopted provisions of Rule 1001(a)(2) in the context of the adopted
definitions of SCI systems and indirect SCI systems, where
relevant.\472\
---------------------------------------------------------------------------

    \472\ In particular, the Commission is adopting the language of
items (B) and (C) as proposed (renumbered as Rule 1001(a)(2)(ii) and
(iii), respectively) but elaborates on the scope of these
provisions, as well as the scope of revised item (D) (renumbered as
Rule 1001(a)(2)(iv)) and in the context of the adopted definitions
of SCI systems and indirect SCI systems.
---------------------------------------------------------------------------

Capacity Planning
    The SCI Proposal stated that policies and procedures for the
establishment of reasonable current and future capacity planning
(proposed item (A)) would help an SCI entity determine its systems'
ability to process transactions in an accurate, timely, and efficient
manner, and thereby help ensure market integrity.\473\ One commenter
expressed support for the requirement in proposed item (A),\474\ and
another commenter recommended that proposed item (A) be revised to make
clear that SCI entity capacity planning estimates apply to ``technology
infrastructure'' capacity, as opposed to capacity with respect to non-
technology infrastructure of an SCI entity.\475\ Because the Commission
intended proposed item (A) to relate to capacity planning for SCI
systems, rather than capacity planning more broadly (for example, in
relation to an SCI entity's office space), the Commission is including
this suggested clarification in adopted Rule 1001(a)(2)(i), and thus
requires that an SCI entity's policies and procedures include the
establishment of reasonable current and future technology
infrastructure capacity planning estimates.
---------------------------------------------------------------------------

    \473\ See Proposing Release, supra note 13, at 18107.
    \474\ See MSRB Letter at 9.
    \475\ See DTCC Letter at 14-15. The Commission also received
comments in regard to capacity planning as it relates to proposed
industry standards on the capacity planning domain set out in
proposed Table A. See, e.g., infra note 580 and accompanying text.
---------------------------------------------------------------------------

Stress Testing
    A few commenters raised concerns about proposed item (B), which
required periodic capacity stress tests.\476\ Some of these commenters
urged that the adopted rule provide an SCI entity with flexibility to
determine, using a risk-based assessment, when capacity stress tests
are appropriate.\477\ Others suggested that capacity stress tests be
required in specified circumstances or time frames, such as when new
capabilities are released into production,\478\ whenever required
system capacity increases by 10 percent, on a quarterly basis, or in
conjunction with any material systems change.\479\ One commenter
suggested that SCI entities should supplement dynamic stress and load
testing with static analysis, a technique used to help uncover
structural weaknesses in software.\480\ In proposing item (B), the
Commission intended for SCI entities to engage in a careful risk-based
assessment (as suggested by some commenters) \481\ of its SCI systems
to determine when to stress test its systems.\482\ Rule 1001(a)(2)(ii),
as adopted, affords SCI entities the flexibility to consider the
factors suggested by commenters, as appropriate for their specific
systems and circumstances.\483\ The adopted rule does not prescribe a
particular frequency or trigger for stress testing; however, because
the Commission believes that, in light of the variability in SCI
systems, an SCI entity's experience with its particular systems

and assessment of risk in this area will dictate when capacity stress
testing is warranted. The requirement for periodic capacity stress
tests of systems to determine their ability to process transactions in
an accurate, timely, and efficient manner is therefore adopted as
proposed as Rule 1001(a)(2)(ii).
---------------------------------------------------------------------------

    \476\ See, e.g., CISQ Letter at 5; DTCC Letter at 14; Lauer
Letter at 6; MSRB Letter at 9; OCC Letter at 10; and SIFMA Letter at
12.
    \477\ See DTCC Letter at 14; and OCC Letter at 10. See also
SIFMA Letter at 12 (suggesting that periodic capacity monitoring
would be more appropriate and cost-effective than periodic capacity
stress testing).
    \478\ See MSRB Letter at 9.
    \479\ See Lauer Letter at 6.
    \480\ See CISQ Letter at 5. See also infra notes 491 and 497,
and 498 and accompanying text (further discussing this comment and
the commenter's views on the value of assessing the structural
quality of software).
    \481\ See supra note 477 and accompanying text.
    \482\ In response to the commenter that suggested periodic
capacity monitoring would be more appropriate and cost-effective
than periodic capacity stress testing, see supra note 477 and
accompanying text, the Commission believes that such monitoring is
appropriate and may play an important role in an SCI entity's
assessing when to stress tests its systems. However, the Commission
continues to believe that stress testing is necessary to help an SCI
entity determine its systems' ability to process transactions in an
accurate, timely, and efficient manner, and thereby help ensure
market integrity. See Proposing Release, supra note 13, at 18107.
While monitoring may be a cost-effective method to determine when a
stress test is warranted, the Commission does not believe monitoring
alone will be an effective substitute for stress testing, which,
unlike monitoring, is designed to challenge systems capacity.
    \483\ See supra notes 478-479 and accompanying text.
---------------------------------------------------------------------------

Systems Development and Testing Methodology
    In the SCI Proposal, the Commission explained that proposed item
(C), which would require SCI entities to have policies and procedures
for a ``program to review and keep current systems development and
testing methodology,'' would help an SCI entity monitor and maintain
systems capacity and availability.\484\ The Commission is adopting the
language of this item as proposed as Rule 1001(a)(2)(iii).
---------------------------------------------------------------------------

    \484\ See Proposing Release, supra note 13, at 18107.
---------------------------------------------------------------------------

    Two commenters supported this requirement as proposed.\485\ Another
commenter argued that sufficient controls were in place with respect to
production systems, as proposed, and therefore that separate policies
and procedures specifically for the development and testing environment
would be unnecessary and duplicative.\486\ This commenter added that,
if development and testing systems were not excluded from the
definition of SCI systems altogether, then the policies and procedures
requirements regarding systems development and testing methodology
should not apply separately to these environments. The Commission
agrees with this comment, and believes it logically follows that
policies and procedures requiring a program to review and keep current
systems development and testing methodology for SCI systems, and
indirect SCI systems, as applicable, are important if development and
testing systems are excluded from the definition of SCI systems, as
they are under the adopted regulation.\487\ An SCI entity's systems
development and testing methodology is a core part of the systems
development life cycle for any SCI system. Therefore, the Commission
believes that if an SCI entity did not have a program to review and
keep current systems development and testing methodology for SCI
systems, and indirect SCI systems, as applicable, its ability to assess
the capacity, integrity, reliability, availability and security of its
SCI systems and indirect SCI systems, as applicable, would be
undermined. In complying with this adopted requirement, an SCI entity
may wish to consider how closely its testing environment simulates its
production environment; whether it designs, tests, installs, operates,
and changes SCI systems through use of appropriate development,
acquisition, and testing controls by the SCI entity and/or its third-
party service providers, as applicable; whether it identifies and
corrects problems detected in the development and testing stages;
whether it verifies change implementation in the production stage;
whether development and test environments are segregated from SCI
systems in production; and whether SCI entity personnel have adequately
segregated roles between the development and/or test environment, and
the production environment.
---------------------------------------------------------------------------

    \485\ See CISQ Letter at 2; and MSRB Letter at 9.
    \486\ See FINRA Letter at 12.
    \487\ See supra Section IV.A.2.b (discussing the definition of
``SCI systems''). Because development and testing systems are not
part of the adopted definition of ``SCI systems,'' systems issues
with regard to development and testing systems would not be subject
to the requirements of adopted Rule 1002 relating to corrective
action, Commission notification, and dissemination of information on
SCI events; or Rule 1003(a) regarding notification of systems
changes.
---------------------------------------------------------------------------

Reviews of SCI Systems and Indirect SCI Systems
    The SCI Proposal explained that proposed item (D), which would have
required an SCI entity to establish, maintain, and enforce policies and
procedures to review and test regularly SCI systems (and SCI security
systems, as applicable), including backup systems, to identify
vulnerabilities pertaining to internal and external threats, physical
hazards, and natural or manmade disasters, would assist an SCI entity
in ascertaining whether such systems are and remain sufficiently secure
and resilient.\488\ Proposed item (D) garnered a range of comments.
Some commenters addressing this item focused on internal SCI entity
testing,\489\ whereas others focused more broadly on industry-wide
testing and testing of backup systems.\490\
---------------------------------------------------------------------------

    \488\ See Proposing Release, supra note 13, at 18107.
    \489\ See, e.g., CAST Letter at 4; CISQ Letter at 3-7; FIA PTG
Letter at 4; Lauer Letter at 6; and MSRB Letter at 10.
    \490\ See, e.g., Angel Letter at 2; CoreOne Letter at 3-5; DTCC
Letter at 13; FIA PTG Letter at 2; FIX Letter at 1-2; Tradebook
Letter at 1-4; UBS Letter at 4; and CISQ Letter at 6. See also infra
Section IV.B.6 (discussing adopted Rule 1004, requiring business
continuity and disaster recovery testing, including required
participation of designated members or participants of SCI entities
in such testing).
---------------------------------------------------------------------------

    With respect to comments on internal testing, one commenter
suggested that the proposed requirement be expanded beyond testing to
cover a range of ``quality assurance activities'' with each release of
software into production.\491\ Two commenters advocated for requiring
an SCI entity to focus on identifying structural deficiencies, which
they stated pose much greater risks than functional deficiencies.\492\
A few commenters urged that groups independent of the team that
designed and developed the systems should be involved in testing to
offer a diverse perspective.\493\ One of these commenters further
suggested that enforcement of the policies governing development and
testing activities should be conducted by a ``process audit'' role that
evaluates compliance with policies, provides guidance to development
and testing teams on how to comply, and reports on compliance to senior
management.\494\
---------------------------------------------------------------------------

    \491\ See CISQ Letter at 3-7 (encouraging the Commission to
require quality assurance activities other than testing, including
that an SCI entity evaluate and measure the structural quality of
its SCI systems because ``the attributes of an SCI system most
critically affecting its capacity, integrity, resiliency,
availability, and security are predominantly structural
(engineering) rather than functional (correctness)'').
    \492\ See CAST Letter at 4; and CISQ Letter at 3-7.
    \493\ See, e.g., CISQ Letter at 7; and Lauer Letter at 6.
    \494\ See CISQ Letter at 7. This commenter further recommended
that such process audits be conducted at least annually for each SCI
system, and more often for SCI systems with operational problems, a
record of non-compliance, or those being developed, tested, or
operated by an inexperienced staff, and stated that process auditors
who perform a mentoring role to software teams have proven a cost-
effective mechanism for on-the-job training.
---------------------------------------------------------------------------

    After careful consideration of the comments, the Commission is
adopting this provision with modifications as Rule 1001(a)(2)(iv).
Specifically, adopted Rule 1001(a)(2)(iv) requires an SCI entity's
reasonably designed policies and procedures to include ``[r]egular
reviews and testing, as applicable, of [its SCI systems and, for
purposes of security standards, indirect SCI systems], including backup
systems, to identify vulnerabilities pertaining to internal and
external threats, physical hazards, and natural or manmade disasters.''
    As adopted, this provision will afford an SCI entity greater
flexibility, through the addition of the phrase ``as applicable,'' to
determine how to identify vulnerabilities pertaining to internal and
external threats, physical hazards, and natural or manmade disasters.
Specifically, the adopted rule replaces the proposed rule's requirement
that an SCI entity conduct ``regular reviews and testing'' of relevant
systems (including backup systems) with a more flexible requirement
that an SCI entity conduct ``regular reviews and

testing, as applicable'' of relevant systems, including backup systems.
In response to some commenters' concerns that the proposed requirement
focused too much on regular testing and not enough on other methods to
assess systems operation,\495\ the adopted rule provides an SCI entity
the flexibility to determine an assessment methodology that would be
most appropriate for a given system, or particular functionality of a
system. Thus, consistent with commenters' views, the adopted provision
does not specifically require both regular reviews and regular testing
in connection with an SCI entity's identification of vulnerabilities.
Instead, the provision requires reviews or testing (or both) to occur
as applicable, so long as the approach is effective to identify
vulnerabilities in SCI systems, and indirect SCI systems, as
applicable.
---------------------------------------------------------------------------

    \495\ See supra notes 491-492 and accompanying text.
---------------------------------------------------------------------------

    While Rule 1001(a)(2)(iv) specifically identifies reviews and
testing as means to identify vulnerabilities pertaining to internal and
external threats, physical hazards, and natural or manmade disasters,
it does not dictate the precise manner or frequency of reviews and
testing, and does not prohibit an SCI entity from determining that
there are methods other than reviews and testing that may be effective
in identifying vulnerabilities. For example, reviews and testing would
each be one of the methods that an SCI entity could employ, and each