CFTC System Safeguards (17 CFR 37, 38, 39, 49)

Where subject to the critical entity requirements, maintain infrastructure and personnel sufficient to meet the same day recovery objective that are located outside the relevant area and do not depend on the same critical transportation, telecommunications, power, water or other infrastructure components relied on for normal activities.

• Site location analysis showing separation of the primary and backup sites
• Dependency analysis for transportation, telecommunications, power and water at each site
• Evidence that recovery personnel live and work outside the relevant area
• Wide scale disruption test results

• Backup site in the same metropolitan area sharing utilities
• Personnel dispersal not addressed at all
• Dependency analysis limited to telecommunications

Conduct regular periodic testing and review of business continuity and disaster recovery capabilities, using protocols adequate to establish that backup resources are sufficient to meet the recovery requirements, and retain the results.

• Recovery test plan and schedule
• Test reports with scenario, scope, results and issues raised
• Evidence that backup resources were exercised rather than assumed
• Records of the results made available to the Commission on request

• Tabletop exercises only with no technical failover
• Backup resources not exercised
• Test issues not tracked to closure
• Results not retained

Update the business continuity and disaster recovery plan and emergency procedures at a frequency determined by an appropriate risk analysis and no less frequently than annually.

• Version history of the plan showing at least annual update
• Risk analysis determining the update frequency
• Approval record for each updated version
• Change log describing what was updated

• Plan reissued annually with no substantive change and no review record
• Update frequency not derived from a risk analysis
• Approval of the updated plan not recorded

Where determined by the Commission to be a critical financial market or a critical swap data repository, maintain a recovery plan and resources sufficient to achieve a same day recovery time objective even in a wide scale disruption.

• Record of the Commission determination of critical status
• Same day recovery time objective documented in the plan
• Test evidence demonstrating same day recovery
• Resource plan supporting same day recovery in a wide scale disruption

• Critical status determined but the plan still carries a next business day objective
• Same day recovery never tested against a wide scale disruption scenario
• Resource plan does not distinguish local from wide scale events

Satisfy the recovery requirement either through infrastructure and personnel resources of the registrant own, or through contractual arrangements with another registrant or a disaster recovery service provider sufficient to ensure continued fulfilment of all responsibilities and obligations.

• Statement of which route is relied on
• Contracts with recovery service providers including the service levels
• Evidence that the contracted arrangement covers all responsibilities and obligations
• Provider capability verification and test participation

• Contractual route relied on without confirming the provider can meet the recovery objective
• Contract covers infrastructure but not the regulatory obligations
• Provider never included in recovery testing

To the extent practicable, coordinate the business continuity and disaster recovery plan with those of the members, clearing members and other market participants on whom the registrant depends, so that activity can effectively resume following a disruption.

• Register of members and participants on whom the registrant depends
• Evidence of coordination such as shared recovery assumptions or joint planning documents
• Communication procedures for a disruption
• Assessment where coordination was judged impracticable

• No identification of the participants the registrant depends on
• Coordination asserted with no supporting record
• Impracticability claimed without assessment

To the extent practicable, initiate and coordinate periodic synchronised testing of the business continuity and disaster recovery plan with the plans of the members, clearing members and other market participants on whom the registrant depends.

• Schedule of industry wide or member facing recovery tests
• Participation records for members and participants
• Test reports and the issues raised
• Follow up records with participants who did not take part

• Testing performed internally only
• Member participation not tracked
• Issues raised by participants not followed up

To the extent practicable, ensure the business continuity and disaster recovery plan takes into account the plans of telecommunications, power, water and other essential service providers.

• Register of essential service providers per site
• Evidence of the provider continuity arrangements obtained
• Assessment of single points of failure across providers
• Contract terms covering provider continuity

• Provider continuity assumed from the service contract with no evidence
• Single points of failure across providers not analysed
• Water and physical services omitted

Where required resources are maintained through a contractual outsourcing arrangement, retain complete responsibility for any failure to meet the program and recovery requirements and employ personnel with the expertise necessary to supervise the provider delivery of the services.

• Register of outsourced system safeguards resources
• Contracts reflecting the retained responsibility
• Evidence of the in house expertise supervising each provider
• Provider performance and service review records

• Reliance on provider assurance reports with no in house supervisory capability
• Contracts transfer responsibility in substance
• Provider reviews not documented

Apply the required testing to all resources whether owned or outsourced, verify that they work together effectively, and where independent testing is required engage a contractor independent of both the registrant and any outside service provider used to design, develop or maintain the resources being tested.

• Test scope statements showing outsourced resources are included
• End to end test evidence covering combined own and outsourced resources
• Independence declarations from testing contractors covering the service providers
• Procurement records evidencing the independence check

• Testing scoped to internally hosted systems only
• Independence assessed against the registrant but not against the service provider
• No end to end verification that own and outsourced resources work together

Maintain a business continuity and disaster recovery plan, emergency procedures, backup facilities and physical, technological and personnel resources sufficient to enable timely recovery and resumption of operations and of the ongoing fulfilment of the registrant responsibilities and obligations following any disruption.

• Current business continuity and disaster recovery plan
• Emergency procedures and call trees
• Inventory of backup facilities and standby resources
• Mapping from each regulatory obligation to the recovery capability supporting it
• Personnel succession and standby arrangements

• Plan covers technology recovery only and omits regulatory obligations such as market surveillance and audit trail
• Personnel resources not addressed
• Plan not linked to the specific responsibilities of the registrant category

Maintain the capability to resume operations and the ongoing fulfilment of responsibilities and obligations during the next business day following a disruption, unless determined to be a critical entity subject to the more stringent same day objective.

• Documented recovery time objective and the analysis supporting it
• Test results demonstrating the objective is achievable
• Resource plan supporting the objective
• Record of the entity critical or non critical determination

• Recovery objective stated but never demonstrated by test
• Objective set for technology only and not for the regulatory obligations
• Critical determination status not recorded

Conduct vulnerability testing of a scope sufficient to satisfy the scope requirement, at a frequency determined by an appropriate risk analysis and no less frequently than quarterly for covered entities, including automated vulnerability scanning following generally accepted best practices.

• Vulnerability scan reports covering the required scope
• Scanning schedule evidencing the frequency achieved
• Risk analysis supporting the frequency
• Evidence the scanning method follows accepted practice
• Covered entity determination where the minimum frequency applies

• Scanning limited to external addresses
• Quarterly minimum missed for a covered entity
• Authenticated scanning not used so findings understate exposure
• Scan findings not fed to the remediation register

Conduct external penetration testing of a scope sufficient to satisfy the scope requirement, at a frequency determined by an appropriate risk analysis and no less frequently than annually for covered entities, with the required annual test performed by independent contractors for covered entities.

• External penetration test reports with scope and methodology
• Engagement letters evidencing contractor independence for the required annual test
• Frequency risk analysis
• Retest or closure evidence for findings

• Annual external test performed by internal staff at a covered entity
• Scope narrower than the scope requirement demands
• Findings not retested after remediation

Conduct controls testing covering each control included in the program of risk analysis and oversight, at a frequency determined by an appropriate risk analysis, with key controls tested no less frequently than every three years for covered entities and the key control testing performed by independent contractors for covered entities.

• Control inventory drawn from the program with the key control designation
• Risk analysis identifying which controls are key controls
• Testing schedule showing the rolling coverage of every control
• Independent contractor reports for key control testing
• Test results per control

• Controls testing covers a sample with no plan to reach full coverage
• Key controls not identified
• Rolling three year cycle asserted but coverage not tracked
• Key control testing performed in house at a covered entity

Maintain a written security incident response plan covering the definition and classification of security incidents, reporting policies and procedures, internal and external communication and information sharing, and hand off and escalation points, and test it at a frequency determined by an appropriate risk analysis and no less frequently than annually for covered entities.

• Security incident response plan containing each required element
• Test records with the method used and the participants
• Post test improvement actions
• Evidence of the definition and classification scheme in use
• Escalation and hand off matrix

• Plan lacks the classification scheme or the escalation points
• Testing limited to a walkthrough every few years
• External communication and information sharing not addressed
• Test findings not used to update the plan

Conduct a written enterprise technology risk assessment analysing threats and vulnerabilities in the context of mitigating controls and identifying, estimating and prioritising risks to operations, assets, market participants and others arising from impairment of data confidentiality, integrity and availability or of system reliability, security or capacity, at a frequency determined by an appropriate risk analysis and no less frequently than annually for covered entities.

• Written enterprise technology risk assessment
• Threat and vulnerability analysis set against the mitigating controls
• Risk prioritisation covering effects on market participants and third parties
• Evidence of annual refresh or documented update of the previous assessment

• Assessment covers internal impact only and omits market participants
• Threats listed without reference to mitigating controls
• Assessment not refreshed annually at a covered entity

Perform the required testing either by engaging independent contractors or by using employees who are not responsible for the development or operation of the systems or capabilities being tested, and engage independent contractors where the rules require it.

• Independence declaration for each test engagement
• Organisation chart or role evidence showing testers are not responsible for the systems tested
• Procurement records for independent contractor engagements
• Assessment of contractor independence from any outside service provider involved

• Testing performed by the operating team
• Independence claimed on the basis of a separate reporting line within the same function
• Contractor independence from the service provider not assessed

Conduct regular, periodic and objective testing and review of automated systems to establish that they are reliable, secure and have adequate scalable capacity, covering all of the required types of testing.

• Testing programme covering all required test types with their frequencies
• Risk analysis determining each testing frequency
• Test calendar and completion tracking
• Evidence of objectivity in how testing is commissioned and reported

• Testing programme covers penetration testing only
• Frequencies set by convention rather than risk analysis
• Completion against the calendar not tracked

Conduct internal penetration testing of a scope sufficient to satisfy the scope requirement, at a frequency determined by an appropriate risk analysis and no less frequently than annually for covered entities, performed by independent contractors or by employees not responsible for development or operation of the systems tested.

• Internal penetration test reports with scope and methodology
• Evidence that testers are independent of development and operation of the tested systems
• Frequency risk analysis
• Findings tracked to closure

• Internal testing omitted entirely because external testing is performed
• Testing performed by the team that operates the systems
• Annual minimum missed for a covered entity

Set the scope of all system safeguards testing and assessment broadly enough to include the automated systems and controls that the program and the current cybersecurity threat analysis indicate are necessary to identify risks and vulnerabilities that could enable an intruder, unauthorised user or insider to interfere with operations or regulatory responsibilities, impair reliability, security or capacity, alter or exfiltrate regulated activity data, or take other unauthorised action.

• Documented scoping rationale for each test referencing the program and the threat analysis
• Current cybersecurity threat analysis
• Systems and controls in scope and the justification for any exclusion
• Evidence the four risk outcomes in the rule were considered in scoping

• Scope carried forward year on year without reference to the threat analysis
• Exclusions undocumented
• Insider risk outcomes not considered in scoping

Ensure that both senior management and the board receive and review reports setting out the results of the required testing and assessment, and establish and follow procedures for remediation of the issues identified and for evaluating the effectiveness of the testing and assessment protocols.

• Board and senior management papers presenting the testing and assessment results
• Minutes evidencing review and any decisions taken
• Documented remediation procedure
• Records of the evaluation of the effectiveness of the testing protocols

• Results presented to management only and not to the board
• Reports tabled but no evidence of review or challenge
• No periodic evaluation of whether the testing protocols are effective

Notify Commission staff promptly of electronic trading halts and significant systems malfunctions, hardware or software malfunctions, security incidents or targeted threats that jeopardise or are likely to jeopardise system operation, reliability, security or capacity, and of any activation of the business continuity and disaster recovery plan.

• Notification procedure naming the trigger events, the recipient division and the timeframe
• Log of notifications made with timestamps
• Assessment records for events judged not notifiable
• Escalation path and out of hours arrangements

• Notification triggers not defined so events are assessed case by case
• Notifications made by informal contact with no record
• No record of the assessment for events judged not notifiable
• Plan activation not treated as a notifiable event

Provide to the Commission promptly on request the current business continuity and disaster recovery plans and other emergency procedures, all assessments of operational risks or system safeguards related controls, all reports concerning system safeguards testing and assessment whether by independent contractors or employees, and all other books and records requested in connection with system safeguards oversight.

• Records inventory covering each listed category
• Retention schedule meeting the recordkeeping rules
• Evidence records can be produced promptly, such as a prior production log
• Records of testing performed by employees as well as contractors

• Contractor test reports retained but employee performed testing not documented
• Records held by individuals rather than a managed repository
• Retention shorter than the applicable recordkeeping period

Identify and document the vulnerabilities and deficiencies revealed by the required testing and assessment, analyse and document the risks they present in order to decide and document whether to remediate or accept the risk, and remediate in a timely manner given the nature and magnitude of the risk.

• Findings register capturing every vulnerability and deficiency from testing
• Risk analysis for each finding with the remediate or accept decision and its approver
• Remediation timescales tied to the risk rating
• Evidence of closure and of risk acceptances being revisited

• Findings tracked without a documented risk analysis
• Risk acceptances granted with no owner, rationale or expiry
• Remediation timescales not linked to risk magnitude
• Findings from employee performed testing not entered in the register

Give Commission staff timely advance notice of all material planned changes to automated systems that may affect their reliability, security or adequate scalable capacity, and of material planned changes to the program of risk analysis and oversight.

• Change management procedure identifying which changes require advance notice
• Register of notices given with dates relative to the change
• Materiality criteria for change notification
• Notices covering changes to the program itself

• Materiality criteria undefined
• Notices given after implementation
• Changes to the program of risk analysis and oversight never notified

A swap data repository must, with respect to all data in its custody, maintain the program of risk analysis and oversight, maintain emergency procedures, backup facilities and a recovery plan allowing timely recovery and resumption of its duties, and periodically test that backup resources are sufficient to continue fulfilling all of its statutory and regulatory duties.

• Inventory of the data held in custody and its criticality
• Recovery plan mapped to the specific duties of a swap data repository
• Backup sufficiency test results referenced to those duties
• Access and integrity controls over the repository data

• Recovery plan written for the platform rather than for the data duties
• Backup testing does not demonstrate the duties can continue to be met
• Data in custody not inventoried

A designated contract market must provide its annual total trading volume to the Commission for each calendar year by the prescribed date, the figure that determines whether it is a covered designated contract market subject to the minimum testing frequency and independent contractor testing requirements.

• Annual total trading volume submission records with the date submitted
• Calculation basis for the volume figure
• Record of the percentage returned by the Commission
• Determination of covered status and its effect on the testing programme

• Submission made late or not evidenced
• Covered status never determined so the enhanced testing frequencies are not applied
• Calculation basis undocumented

Where the Commission has determined the registered entity to be a critical financial market, comply with the additional obligations governing maintenance and geographic dispersal of disaster recovery resources sufficient to meet a same day recovery time objective in a wide scale disruption.

• Record of the Commission determination and the date it took effect
• Compliance assessment against the additional obligations
• Evidence of the geographic dispersal and same day capability
• Notification and reporting records arising from the designation

• Designation status not tracked
• Additional obligations assumed to be met by the standard recovery plan
• No assessment against the specific requirements that follow the designation

Establish and maintain a program of risk analysis and oversight covering operations and automated systems, to identify and minimise sources of operational risk through appropriate controls and procedures and through systems that are reliable, secure and have adequate scalable capacity.

• Written program of risk analysis and oversight approved by the board
• Mapping of the program to each prescribed category
• Board and senior management approval records
• Annual review record of the program

• Program exists as separate policies with no single documented program
• Not all prescribed categories addressed
• No evidence of board approval or review

Address capacity and performance planning within the program, including controls for monitoring systems to ensure adequate scalable capacity and testing, monitoring and analysis of current and projected capacity and performance and of possible degradation from planned system changes.

• Capacity monitoring configuration and thresholds
• Capacity and performance trend reporting
• Projected capacity analysis against expected volumes
• Assessment of capacity impact for planned changes

• Capacity monitored reactively with no projection
• Change assessments omit capacity impact
• No documented capacity thresholds

Address enterprise risk management and governance within the program, covering assessment, mitigation and monitoring of security and technology risk, security and technology capital planning and investment, board and management oversight, technology audit and controls assessments, and remediation of deficiencies.

• Technology and security risk register with assessment and monitoring evidence
• Technology capital plan and investment approvals
• Board technology and security oversight papers
• Internal audit reports on technology and controls
• Deficiency remediation tracker

• Technology risk not represented in the enterprise risk register
• No technology capital planning tied to security
• Board oversight limited to incident reporting

Address business continuity and disaster recovery planning and resources within the program, including regular periodic testing and review of those capabilities and the controls described in the recovery paragraphs of the section.

• Program section covering business continuity and disaster recovery
• Testing and review schedule for continuity capabilities
• Linkage from the program to the recovery plan and resources

• Continuity treated as a separate plan not represented in the program
• Testing schedule absent from the program
• Program references the plan without describing the controls

Establish and maintain resources that allow each obligation and responsibility to be fulfilled, including daily processing, clearing and settlement of transactions, in light of any risk to operations and automated systems, and periodically verify that those resources are adequate.

• Resource assessment covering personnel, infrastructure and capacity
• Periodic verification of resource adequacy with dates and outcomes
• Link from the assessment to the daily processing obligations

• Resource adequacy assumed rather than verified
• Verification performed without a documented outcome
• Personnel resources not covered

Address information security within the program, covering access to systems and data with least privilege, separation of duties and account monitoring, user and device identification and authentication, security awareness training, audit log maintenance and analysis, media protection, personnel security and screening, system and communications protection, system and information integrity, vulnerability management, penetration testing and security incident response.

• Information security policy set covering each listed element
• Access control and privileged access review records
• Authentication standards for users and devices
• Security awareness training records
• Audit log configuration, retention and review evidence
• Vulnerability management and remediation reporting
• Security incident response plan and incident records

• One or more listed elements absent, commonly media protection and personnel screening
• Least privilege stated but not evidenced by access reviews
• Audit logs collected but not analysed

Address systems operations within the program, covering system maintenance, configuration management including baseline configuration, configuration change and patch management, least functionality and inventory of authorised and unauthorised devices and software, and event and problem response and management.

• Configuration baselines and compliance reporting
• Patch management records with timescales
• Asset inventory covering authorised and unauthorised devices and software
• Event and problem management records

• Inventory covers authorised assets only
• Baselines defined but conformance not measured
• Problem management not distinguished from incident handling

Address systems development and quality assurance within the program, covering requirements development, pre production and regression testing, change management procedures and approvals, outsourcing and vendor management, and training in secure coding practices.

• Software development lifecycle procedure
• Pre production and regression test evidence
• Change approval records
• Vendor management procedure for development suppliers
• Secure coding training records

• Emergency changes bypass approval with no retrospective record
• Regression testing not evidenced
• Secure coding training absent

Address physical security and environmental controls within the program, covering physical access and monitoring, power, telecommunication and environmental controls, and fire protection.

• Physical access control and monitoring records for data centres and technical areas
• Environmental and power system maintenance and test records
• Fire detection and suppression test records
• Access list reviews

• Colocation and cloud facilities excluded on the basis that they are third party managed
• Environmental system tests not retained
• Access lists not reviewed

In addressing the prescribed categories, follow generally accepted standards and best practices with respect to the development, operation, reliability, security and capacity of automated systems.

• Statement of the standards and frameworks adopted
• Mapping from the program to the adopted standard
• Gap assessment against the adopted standard and its remediation plan
• Evidence the standard version in use is current

• Standards named but no mapping to the program
• Gap assessment performed once and never repeated
• Adopted standard version out of date