Security testing rules in the United States.

A regulation promulgated by the DFS Superintendent under the Banking, Insurance and Financial Services Laws. A single failure to meet an obligation is a violation.

“The commission of a single act prohibited by this Part or the failure to act to satisfy an obligation required by this Part shall constitute a violation hereof.”

§ 500.20(a)-(b)

Any person licensed or chartered under the New York Banking, Insurance or Financial Services Law. Entities with fewer than 20 staff, under $7.5 million revenue or under $15 million assets are exempt from § 500.5 under § 500.19(a). Class A companies (§ 500.1(d)) carry extra duties but the same penetration testing rule.

“Covered entity means any person operating under or required to operate under a license, registration, charter, certificate, permit, accreditation or similar authorization under the Banking Law, the Insurance Law or the Financial Services Law”

§ 500.1(e); § 500.19(a)

Penetration testing from inside and outside the system boundary at least once a year. Automated vulnerability scans run at a risk-based frequency and after material system changes (§ 500.5(a)(2)).

“penetration testing of their information systems from both inside and outside the information systems’ boundaries by a qualified internal or external party at least annually”

§ 500.5(a)(1)

No rule that threat intelligence drive test scenarios. Vulnerability management policies follow the risk assessment, which by definition incorporates threat and vulnerability analyses (§ 500.1(p)). The Second Amendment deleted the older wording that tied each year’s test to risks identified in the risk assessment.

Testers must be a qualified internal or external party. The rule names no accreditation, certification or independence test and does not define qualified.

“by a qualified internal or external party at least annually”

§ 500.5(a)(1)

In-house testers may run the annual test if qualified.

“by a qualified internal or external party”

§ 500.5(a)(1)

The rule requires annual awareness training that includes social engineering (§ 500.14(a)(3)), not social engineering testing. DFS guidance of October 16, 2024 lists simulated phishing and voice and video impersonation exercises as a way to deliver that training.

“Training on social engineering, including on deepfake attacks, can be effectively delivered through simulated phishing, and voice and video impersonation exercises.”

§ 500.14(a)(3); DFS Industry Letter, Oct. 16, 2024, Training section

Physical security appears only as a policy area (§ 500.3(j)). The penetration testing duty and definition (§ 500.1(l)) cover information systems only.

§ 500.11(a)(4) requires periodic assessment of third-party service providers, not testing of their systems. DFS’s October 21, 2025 letter says entities should request vulnerability management updates and review independent assessments such as SOC 2 or ISO 27001; it does not bring provider systems into the penetration test.

The annual test covers the entity’s information systems, and the definition of information system names industrial and process control systems and environmental control systems. So ICS the entity owns is in scope by definition. The rule gives no OT-specific method or safety rules.

“as well as any specialized system such as industrial/process controls systems, telephone switching and private branch exchange systems, and environmental control systems.”

§ 500.1(i); § 500.5(a)(1)

The regulation does not name payment, card or market infrastructure systems as a testing target. ‘Payment’ appears only in extortion payment reporting (§ 500.17(c)).

Cloud appears only in the MFA rule for remote access to cloud-based third-party applications (§ 500.12(a)(2)). DFS’s October 2025 letter discusses cloud providers under vendor risk, not testing.

No testing provision on foreign entities or data location. A covered entity may meet the Part by adopting an affiliate’s program (§ 500.2(d)), and class A thresholds count affiliates ‘no matter where located’ (§ 500.1(d)), but neither addresses how tests run across borders.

No provision on joint attacker and defender review of test results.

Entities must remediate vulnerabilities in a timely way, prioritized by risk. There is no fixed deadline and no retest requirement. An entity that cannot certify compliance must file an acknowledgment with a remediation timeline (§ 500.17(b)(1)(ii)).

“timely remediate vulnerabilities, giving priority to vulnerabilities based on the risk they pose to the covered entity.”

§ 500.5(c)

Test reports are not filed with DFS. Documentation must be available on request, and the CEO and CISO certify compliance each April 15 (§ 500.17(b)). DFS reviews programs in examinations and enforcement.

“All documentation and information relevant to the covered entity’s cybersecurity program”

§ 500.2(e); § 500.17(b)

Automated vulnerability scans are required, with manual review of systems scans do not cover. DFS guidance of October 2024 and a May 21, 2026 advisory on frontier AI models address AI-enabled attacks and urge faster vulnerability management; neither requires AI-driven testing or testing of AI systems.

“automated scans of information systems, and a manual review of systems not covered by such scans, for the purpose of discovering, analyzing and reporting vulnerabilities”

§ 500.5(a)(2)

Examiner guidance, not a rule. It tells examiners how to assess security programs. The binding testing duty sits in the Interagency Guidelines, which the booklet cites.

“This booklet provides guidance to examiners and addresses factors necessary to assess the level of security risks”

Introduction, p. 1; footnote 62

Banks, savings associations and credit unions supervised by FFIEC member agencies. Examiners also use the booklet to evaluate technology service providers (footnote 3).

“The term “financial institution” includes national banks, federal savings associations, state savings associations, state member banks, state nonmember banks, and credit unions.”

Introduction, footnotes 2-3

No fixed interval. Frequency follows the risk assessment. Factors that may raise it include network changes, new systems, shifts in attacker profiles and techniques, and prior results (IV.A.1).

“The frequency and scope of a penetration test should be a function of the level of assurance needed by the institution and determined by the risk assessment process.”

IV.A.2(b); IV.A.1

Threat intelligence appears under security operations (III.A, III.B), not as a driver of test scenarios. Penetration test attacks are ‘selected and conducted by the testers’ (IV.A.2(b)). Changes in attacker profiles and techniques may raise test frequency (IV.A.1).

Management should review tester qualifications, require background checks and bonding for contract testers, require NDAs, and decide the level of independence (IV.A.1, IV.A.3). No certification or accreditation is named.

“Management should review qualifications of testing personnel to verify testers’ capabilities are adequate to support the test objectives.”

IV.A.1 (Personnel; Confidentiality); IV.A.3

Internal teams may test; management decides how much independence a test needs. IV.A.3 says testers are independent only if they do not design, install, maintain or operate the tested system.

“The test can be performed internally by independent groups, internally by the organizational unit, or by an independent third party.”

IV.A.2(b); IV.A.3

Social engineering is listed as one type of penetration test. IV.A.1 also weighs the need to test personnel reactions to unexpected activities when deciding whom to notify.

“There are many types of penetration tests (e.g., network, client-side, web application, and social engineering), and management should determine the level and types of tests employed”

IV.A.2(b)

The booklet expects periodic testing that physical security devices work. It does not mention physical intrusion testing.

“Periodic testing provides assurance that the devices are operating correctly.”

II.C.8

Management should obtain independent review of a provider’s security through the provider’s audit and test reports. Examiners may also evaluate technology service providers directly (Introduction, footnote 3). No requirement to include provider systems in the institution’s own tests.

“Independent review of the third party’s security through appropriate reports from audits and tests.”

II.C.20 (Action Summary)

Neither the Information Security booklet nor the AIO booklet addresses testing of OT or ICS. The AIO booklet (VII.E) notes that IoT devices can make changes to physical systems but sets no testing expectation.

Payment systems appear only as network segments (e.g., funds transfer and ACH routers, II.C.9) and in cross-references to the Retail Payment Systems booklet, which was not reviewed for this slice. No payment-specific testing expectation in the booklet.

The AIO booklet lists penetration tests among third-party assurance reviews that help an institution understand a cloud provider’s controls. The IS booklet refers cloud oversight to the FFIEC Outsourced Cloud Computing statement (II.C.20(a)).

“Third-party assurance reviews (e.g., SOC reviews, penetration tests, and vulnerability assessments) can provide an understanding of the cloud service provider’s control environment”

AIO booklet VII.A.5

The only jurisdiction reference concerns where cloud-stored data resides and its legal jurisdiction (II.C.13), not testing.

III.D expects incident response testing through scenario planning and tabletop tests with internal and external parties. No provision on joint attacker and defender review of penetration test results.

Internal audit should track remediation of findings from penetration tests. Issues found in pre-launch tests of external-facing applications should be fixed before launch (II.C.17). Reports should suggest remediation options and flag repeat issues (IV.A.4). No deadline and no retest expectation.

“Internal audit should track the results and the remediation of control deficiencies reported in audits and additional technical reviews, such as penetration tests and vulnerability assessments.”

IV.A.2(d); IV.A.4; II.C.17

Examiners assess whether management uses penetration tests, vulnerability assessments, self-assessments and audits with adequate coverage, depth and independence. Results are not filed with the agencies.

“Determine whether assurance activities provide sufficient confidence that the security program is operating as expected and reaching intended goals.”

Appendix A, Objective 10

Scanners and other tools may run continuously. The booklet does not mention AI.

“Scanners and other tools can be run continuously, generating metrics that are reported and acted upon continuously.”

IV.A.2(c)

A voluntary self-assessment. The FFIEC says such tools are not examination programs. Sunset August 31, 2025.

“The CAT was released in June 2015 as a voluntary assessment tool to help financial institutions identify their risks and determine their cybersecurity preparedness.”

CAT Sunset Statement, p. 1

Designed for any financial institution supervised by FFIEC member agencies to self-assess inherent risk and maturity in five domains and five maturity levels.

“to help financial institutions identify their risks and determine their cybersecurity preparedness”

CAT Sunset Statement, p. 1

Baseline maturity calls for independent testing according to the risk assessment. Evolving calls for routine independent penetration tests of the network boundary and critical web-facing applications. No fixed interval.

“Independent testing (including penetration testing and vulnerability scanning) is conducted according to the risk assessment for external-facing systems and the internal network.”

Domain 3, Detective Controls, Threat and Vulnerability Detection, Baseline and Evolving (p. 41)

At Intermediate maturity, resilience testing should rest on realistic, likely and emerging threats. Domain 2 maturity statements use threat intelligence to update configuration standards and predict attacks.

“Resilience testing is based on analysis and identification of realistic and highly likely threats as well as new and emerging threats facing the institution.”

Domain 5, Incident Resilience Planning and Strategy, Testing, Intermediate (p. 53)

Testing is to be independent. At Intermediate maturity, audit or risk staff review test scope and results to decide whether to rotate testing firms based on quality. No certification named.

“Audit or risk management resources review the penetration testing scope and results to help determine the need for rotating companies based on the quality of the work.”

Domain 3, Detective Controls, Threat and Vulnerability Detection, Intermediate (p. 41)

Statements call for ‘independent’ testing without saying whether in-house staff can qualify.

At Evolving maturity, training effectiveness is validated with social engineering or phishing tests. At Advanced maturity, penetration tests include red team testing that looks for control gaps in employee behavior (Domain 3, p. 42).

“The institution validates the effectiveness of training (e.g., social engineering or phishing tests).”

Domain 1, Training and Culture, Evolving (p. 28)

Physical access appears only as a preventive control. No statement on testing physical security.

At Advanced maturity, incident response testing considers how assets at critical third parties may be targeted. At Baseline, business continuity testing involves critical third parties.

“Incident response testing evaluates the institution from an attacker's perspective to determine how the institution or its assets at critical third parties may be targeted.”

Domain 5, Incident Resilience Planning and Strategy, Testing, Advanced (p. 53); Baseline (p. 52)

No statement on OT or ICS.

At Intermediate maturity, the institution takes part in sector exercises, with a payment processor attack exercise given as the example.

“The institution participates in sector-specific cyber exercises or scenarios (e.g., FS-ISAC Cyber Attack (against) Payment Processors (CAPP)).”

Domain 5, Incident Resilience Planning and Strategy, Testing, Intermediate (p. 53)

Cloud appears only in the Inherent Risk Profile as a count of cloud providers, not in testing statements.

No statement on cross-border testing.

Intermediate maturity uses exercise results to improve the incident response plan, but no statement on joint attacker and defender review of test results.

Baseline: issues are resolved by criticality within set time frames. Intermediate: penetration tests are repeated to confirm medium- and high-risk findings are fixed. Advanced: unresolved medium and high findings go to the board for risk acceptance.

“Penetration testing is repeated to confirm that medium- and high-risk, exploitable vulnerabilities have been resolved.”

Domain 3, Corrective Controls, Remediation, Intermediate (p. 46)

The FFIEC states the self-assessment tools are not examination programs. Use was voluntary and results were not filed.

“The tools are not examination programs”

CAT Sunset Statement, pp. 1-2

Innovative maturity calls for weekly vulnerability scanning across all environments and automated code scanning in development. No AI statements.

“Vulnerability scanning is performed on a weekly basis across all environments.”

Domain 3, Detective Controls, Threat and Vulnerability Detection, Innovative (p. 42)

An SEC rule under the Exchange Act. SCI entities must run an annual SCI review that includes penetration test reviews.

“Conduct an SCI review of the SCI entity's compliance with Regulation SCI not less than once each calendar year”

§ 242.1003(b)(1)

Exchanges, registered securities associations, registered clearing agencies, the MSRB, SCI ATSs above volume thresholds, plan processors, exempt clearing agencies subject to ARP and SCI competing consolidators. Broker-dealers and advisers are outside it.

“SCI entity means an SCI self-regulatory organization, SCI alternative trading system, plan processor, exempt clearing agency subject to ARP, or SCI competing consolidator.”

§ 242.1000 (SCI entity)

The SCI review is annual, but penetration test reviews of the network, firewalls and production systems need only occur once every three years. Designated members must join BC/DR plan tests at least every 12 months (§ 242.1004(b)).

“Penetration test reviews of the network, firewalls, and production systems shall be conducted at a frequency of not less than once every three years”

§ 242.1003(b)(1)(i)

Policies must provide for regular reviews and testing to identify vulnerabilities to internal and external threats (§ 242.1001(a)(2)(iv)), but no rule that threat intelligence drive test scenarios.

The SCI review must be performed by objective personnel with appropriate experience, following established procedures and standards. No certification named.

“SCI review means a review, following established procedures and standards, that is performed by objective personnel having appropriate experience to conduct reviews of SCI systems and indirect SCI systems”

§ 242.1000 (SCI review)

The rule text does not require outside reviewers. Reviewers must be objective and experienced.

“performed by objective personnel having appropriate experience”

§ 242.1000 (SCI review)

No provision.

The SCI review must assess the design and effectiveness of physical security controls over SCI systems and indirect SCI systems. This is a controls assessment, not physical intrusion testing.

“An assessment of internal control design and effectiveness of its SCI systems and indirect SCI systems to include logical and physical security controls, development processes, and information technology governance”

§ 242.1000 (SCI review, para. (2))

SCI systems and indirect SCI systems include systems operated on behalf of the SCI entity, so vendor-operated systems fall inside the SCI review. § 242.1004 also requires designated members or participants to join BC/DR testing. The SEC’s FY2026 exam priorities name third-party vendor risk and vendor systems that qualify as SCI systems.

“SCI systems means all computer, network, electronic, technical, automated, or similar systems of, or operated by or on behalf of, an SCI entity”

§ 242.1000 (SCI systems; indirect SCI systems); § 242.1004(b)

No provision.

The regime covers securities market infrastructure itself: systems supporting trading, clearance and settlement, order routing and market data.

“that, with respect to securities, directly support trading, clearance and settlement, order routing, market data, market regulation, or market surveillance.”

§ 242.1000 (SCI systems)

No explicit cloud provision; cloud-hosted systems are covered only through the ‘operated by or on behalf of’ definition.

No provision.

No provision.

Entities must periodically review their policies and promptly remedy deficiencies. The SCI review report goes to senior management within 30 days and to the SEC and board with management’s response within 60 days (§ 242.1003(b)(2)-(3)). No deadline for fixing individual test findings and no retest rule.

“take prompt action to remedy deficiencies in such policies and procedures.”

§ 242.1001(a)(3)

The SEC receives each SCI review report, which covers penetration test reviews, and examines SCI entities.

“Submit to the Commission, and to the board of directors of the SCI entity or the equivalent of such board, a report of the SCI review required by paragraph (b)(1) of this section, together with any response by senior management”

§ 242.1003(b)(3)

‘Automated’ appears only in the SCI systems definition.

CFTC regulations implementing the system safeguards core principles. Parallel text binds DCMs (§ 38.1051), SEFs (§ 37.1401), DCOs (§ 39.18) and SDRs (§ 49.24).

“A designated contract market shall conduct regular, periodic, objective testing and review of its automated systems to ensure that they are reliable, secure, and have adequate scalable capacity.”

§ 38.1051(h); § 37.1401(h); § 39.18(e); § 49.24(j)

All four registrant types must run vulnerability, external and internal penetration, controls, incident response plan testing and technology risk assessments. Minimum frequencies apply to all DCOs and SDRs and to covered DCMs, those with 5% or more of total DCM trading volume. SEFs and non-covered DCMs test at risk-based frequencies.

“Covered designated contract market means a designated contract market whose annual total trading volume in calendar year 2015, or in any subsequent calendar year, is five percent (5%) or more of the combined annual total trading volume of all designated contract markets”

§ 38.1051(h)(1) (Covered designated contract market)

External and internal penetration tests at least annually and vulnerability testing at least quarterly for DCOs, SDRs and covered DCMs. Key controls tested at least every three years. SEFs and non-covered DCMs: risk-based.

“shall conduct such external penetration testing at a frequency determined by an appropriate risk analysis, but no less frequently than annually.”

§ 39.18(e)(2)-(5); § 49.24(j)(2)-(5); § 38.1051(h)(2)-(5)

Test scope must cover what the entity’s current cybersecurity threat analysis shows is needed to find paths for an intruder, unauthorized user or insider. This ties scope to threat analysis; it does not prescribe intelligence-led scenarios.

“shall be broad enough to include the testing of automated systems and controls that the designated contract market's required program of risk analysis and oversight and its current cybersecurity threat analysis indicate is necessary”

§ 38.1051(k); § 39.18(e)(8); § 49.24(l); § 37.1401(k)

DCOs, SDRs and covered DCMs must use independent contractors for the annual external penetration test and for key controls testing every three years. A DCO’s contractor must be independent of any outside provider that built or maintains the tested resources (§ 39.18(d)(3)). No certification named.

“A covered designated contract market shall engage independent contractors to conduct the required annual external penetration test.”

§ 38.1051(h)(3)(ii); § 39.18(e)(3)(ii); § 49.24(j)(3)(ii)

Employees may run internal penetration tests, vulnerability tests and other tests if they are not responsible for developing or operating the systems tested. The required annual external test at DCOs, SDRs and covered DCMs must be by independent contractors.

“by engaging independent contractors, or by using employees of the designated contract market who are not responsible for development or operation of the systems or capabilities being tested.”

§ 38.1051(h)(4)(ii)

Controls testing must include testing of each control in the program of risk analysis and oversight (§ 38.1051(h)(5)(i)), and the program’s information security category includes security awareness training and personnel security and screening (§ 38.1051(a)(2)). Parallel text binds SEFs (§ 37.1401), DCOs (§ 39.18) and SDRs (§ 49.24). No text names social engineering, phishing or pretexting as a test method.

“This category includes, but is not limited to, controls relating to: Access to systems and data (including least privilege, separation of duties, account monitoring and control); user and device identification and authentication; security awareness training”

§ 38.1051(a)(2), (h)(5)(i); § 39.18(b)(2)(i), (e)(5)

Corrected October 30, 2026 from Not addressed. Controls testing must cover each control in the program, and the information security category lists security awareness training and personnel security and screening. A mandatory test of people-reliant controls that names no method is controls_test, as for this row’s physical cell, DFSA GEN 5.5.15(a) and CMA VASP Art. 51(16)(a).

Controls testing must cover each control in the risk program, and that program must include physical access and monitoring. This is controls testing, not physical intrusion testing.

“Physical security and environmental controls. This category includes, but is not limited to: Physical access and monitoring”

§ 38.1051(a)(7), (h)(5)(i); § 39.18(b)(2)(vi), (e)(5)

For DCOs, testing must cover outsourced resources and confirm own and outsourced resources work together. The DCM, SEF and SDR rules list outsourcing and vendor management as a program category but have no equivalent clause.

“The testing referred to in paragraph (e) of this section shall apply to all of the derivatives clearing organization's own and outsourced resources, and shall verify that all such resources will work together effectively.”

§ 39.18(d)(3)

No provision.

The rules apply to derivatives market infrastructure itself: trading venues, clearing houses and trade repositories. Testing covers the automated systems that run these functions.

“Order processing and trade matching; transmission of matched orders to a designated clearing organization for clearing; price reporting; market surveillance; and maintenance of a comprehensive audit trail.”

§ 38.1051(c), (h)

No provision naming cloud.

No provision.

Incident response plan testing may use walk-throughs, tabletop exercises, simulations and comprehensive exercises (§ 38.1051(h)(1)), but no joint attacker and defender review.

Entities must document findings, decide whether to remediate or accept each risk, and remediate in a timely manner. Senior management and the board review results (§ 38.1051(l)). No fixed deadline and no retest rule.

“When the designated contract market determines to remediate a vulnerability or deficiency, it must remediate in a timely manner given the nature and magnitude of the associated risk.”

§ 38.1051(m); § 39.18(e)(10); § 49.24(n); § 37.1401(m)

Reports of all required tests must be given to the CFTC promptly on request. They are not filed routinely.

“All reports concerning system safeguards testing and assessment required by this chapter, whether performed by independent contractors or by employees of the designated contract market”

§ 38.1051(g)(3); § 39.18(f); § 37.1401(g)(3)

Vulnerability testing must include automated vulnerability scanning. No AI text.

“Such vulnerability testing shall include automated vulnerability scanning, which shall follow generally accepted best practices.”

§ 38.1051(h)(2)(ii); § 39.18(e)(2)(ii)

Guidelines codified in agency rules under FDIA section 39 and GLBA section 501(b). Institutions ‘shall’ test key controls; frequency and tester independence use ‘should’. Agencies can act under section 39.

“The OCC may take action under section 39 and these Guidelines independently of, in conjunction with, or in addition to, any other enforcement action available to the OCC.”

App. B, I.B; III.C.3

OCC: national banks, federal savings associations, federal branches and agencies of foreign banks. Fed: state member banks. FDIC: state nonmember banks. NCUA: federally insured credit unions. The same testing sentence appears in each text.

“national banks, Federal savings associations, Federal branches and Federal agencies of foreign banks, and any subsidiaries of such entities”

12 CFR 30 app. B, I.A; 208 app. D-2 and 364 app. B, III.C.3; 748 app. A, III.C.3

Regular testing of key controls; frequency and nature set by the risk assessment. No penetration test is named.

“Regularly test the key controls, systems and procedures of the information security program. The frequency and nature of such tests should be determined by the national bank's or Federal savings association's risk assessment.”

App. B, III.C.3

Institutions must identify reasonably foreseeable internal and external threats in the risk assessment (III.B.1). No rule on threat intelligence driving tests.

Tests should be run or reviewed by independent third parties or independent staff. No qualification or certification named.

“Tests should be conducted or reviewed by independent third parties or staff independent of those that develop or maintain the security programs.”

App. B, III.C.3

In-house staff may test if independent of those who develop or maintain the program.

“staff independent of those that develop or maintain the security programs”

App. B, III.C.3

Access controls must stop employees giving customer data to people using fraudulent means (III.C.1.a), but no testing provision.

Physical access restrictions are a control to consider (III.C.1.b). No specific physical testing text.

Where the risk assessment indicates, institutions monitor service providers, and should review audits, summaries of test results or equivalent evaluations. No duty to test provider systems directly.

“As part of this monitoring, a national bank or Federal savings association should review audits, summaries of test results, or other equivalent evaluations of its service providers.”

App. B, III.D.3

No provision.

No testing provision.

No provision.

Supplement A expects contracts with ‘domestic and foreign service providers’ to cover incident response, not testing.

No provision.

Institutions shall adjust the program as threats and technology change (III.E). The annual board report should cover results of testing and management’s responses. No deadline or retest rule.

“The reports should discuss material matters related to its program, addressing issues such as: risk assessment; risk management and control decisions; service provider arrangements; results of testing”

App. B, III.E; III.F

Test results are not filed. Agencies assess compliance in supervision, using the FFIEC Information Security booklet, and may act under section 39.

“The OCC may take action under section 39 and these Guidelines”

App. B, I.B

No provision.

A trade regulation rule implementing GLBA section 501(b) for financial institutions under FTC jurisdiction.

“In order to develop, implement, and maintain your information security program, you shall:”

§ 314.4 (introductory text); § 314.4(d)(2)

Mortgage brokers, lenders, finance companies, tax preparers and other non-bank firms engaged in financial activities. Firms with customer information on fewer than 5,000 consumers are exempt from the penetration testing paragraph (§ 314.6).

“Section 314.4(b)(1), (d)(2), (h), and (i) do not apply to financial institutions that maintain customer information concerning fewer than five thousand consumers.”

§ 314.1(b); § 314.6

Annual penetration testing and vulnerability assessments every six months, unless the firm runs effective continuous monitoring.

“Annual penetration testing of your information systems determined each given year based on relevant identified risks in accordance with the risk assessment”

§ 314.4(d)(2)(i)-(ii)

Each year’s test is set by ‘relevant identified risks in accordance with the risk assessment’ (§ 314.4(d)(2)(i)). No threat intelligence requirement.

The rule sets no tester qualification or independence rule. It requires qualified security personnel generally (§ 314.4(e)(2)); the penetration testing definition refers only to ‘assessors’ (§ 314.2(n)).

Silent on who may test.

Security awareness training is required (§ 314.4(e)(1)); no social engineering testing.

Penetration testing covers information systems only.

Firms must periodically assess service providers based on risk (§ 314.4(f)(3)); no testing of provider systems.

The annual test covers the firm’s information systems, and the definition includes industrial and process control systems that contain or connect to customer information.

“as well as any specialized system such as industrial/process controls systems, telephone switching and private branch exchange systems, and environmental controls systems that contains customer information or that is connected to a system that contains customer information.”

§ 314.2(j); § 314.4(d)(2)(i)

No testing provision.

No provision.

No provision.

No provision.

Firms must evaluate and adjust the program in light of test results. The annual board report covers results of testing (§ 314.4(i)(2)). No deadline or retest rule.

“Evaluate and adjust your information security program in light of the results of the testing and monitoring required by paragraph (d) of this section”

§ 314.4(g)

Test results go to the board, not the FTC (§ 314.4(i)). The FTC receives only notification events (§ 314.4(j)) and enforces through investigations.

Continuous monitoring can replace the annual penetration test and semiannual vulnerability assessments. No AI text.

“the monitoring and testing shall include continuous monitoring or periodic penetration testing and vulnerability assessments.”

§ 314.4(d)(2)

FISMA is a statute that obliges every agency to test controls at least annually. NIST states the SP 800-53 controls are mandatory for federal information systems under OMB Circular A-130 and FISMA; SP 800-53B baselines set which controls apply.

“The use of these controls is mandatory for federal information systems in accordance with Office of Management and Budget (OMB) Circular A-130 [OMB A-130] and the provisions of the Federal Information Security Modernization Act”

44 U.S.C. 3554(b)(5); SP 800-53 Rev. 5 Sec. 1.1

Every agency must test management, operational and technical controls of every system in its inventory. Penetration testing (CA-8) and an independent tester (CA-8(1)) are selected only in the High baseline of SP 800-53B; CA-8(2) red team and CA-8(3) facility testing sit in no baseline. National security systems are outside FISMA’s NIST mandate (SP 800-53 Sec. 1.1, fn. 11).

“shall include testing of management, operational, and technical controls of every information system identified in the inventory required under section 3505(c)”

44 U.S.C. 3554(b)(5)(A); SP 800-53B Table 3-4 (CA-8, CA-8(1), CA-8(2), CA-8(3))

FISMA sets a floor of at least annual testing and evaluation. CA-8 leaves penetration test frequency to the organization.

“to be performed with a frequency depending on risk, but no less than annually”

44 U.S.C. 3554(b)(5); SP 800-53 Rev. 5 CA-8

CA-8 discussion asks organizations to match rules of engagement to expected adversary tactics, and says red teams work best with knowledge of current adversary TTPs. No text requires threat intelligence to drive scenarios. The FY2026-27 CIO FISMA metrics ask agencies whether red team and penetration tests use TTPs from threat intelligence (CIO-FY26-0113), a reporting question only.

“Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries.”

SP 800-53 Rev. 5 CA-8 Discussion; CA-8(2) Discussion; FY26-27 CIO FISMA Metrics v1.1, CIO-FY26-0113

CA-8(1) requires an independent penetration testing agent or team and is selected in the High baseline. Independence means freedom from conflicts with the development, operation or management of the target. No accreditation or certification scheme is named; the discussion only asks for demonstrable skills and experience.

“Employ an independent penetration testing agent or team to perform penetration testing on the system or system components.”

SP 800-53 Rev. 5 CA-8(1) and Discussion; CA-8 Discussion; SP 800-53B Table 3-4

Agency staff may test if they are free of conflicts of interest with the target system, as CA-8(1) defines independence by impartiality, not by employer. Risk assessments set the level of independence.

“Impartiality implies that penetration testing agents or teams are free from perceived or actual conflicts of interest with respect to the development, operation, or management of the systems that are the targets of the penetration testing.”

SP 800-53 Rev. 5 CA-8(1) Discussion; CA-8 Discussion

CA-8(2) red team exercises may include social engineering by email, phone, shoulder surfing or conversation. CA-8(2) is optional: SP 800-53B puts it in no baseline.

“Such attempts may include technology-based attacks and social engineering-based attacks. Technology-based attacks include interactions with hardware, software, or firmware components and/or mission and business processes. Social engineering-based attacks include interactions via email, telephone, shoulder surfing, or personal conversations.”

SP 800-53 Rev. 5 CA-8(2) Discussion; SP 800-53B Table 3-4

CA-8(3) covers announced or unannounced attempts to bypass physical access points, and CA-8 says penetration tests can exercise physical controls. CA-8(3) is in no SP 800-53B baseline, so it is optional.

“Employ a penetration testing process that includes [Assignment: organization-defined frequency] [Selection: announced; unannounced] attempts to bypass or circumvent controls associated with physical access points to the facility.”

SP 800-53 Rev. 5 CA-8(3); CA-8 Discussion; SP 800-53B Table 3-4

The controls, including CA-8 at High, apply to federal information systems, which NIST defines to include systems operated by contractors. FISMA’s agency program also covers systems provided or managed by contractors. Testing of supply chain elements and actors (SR-6(1)) is optional and in no baseline.

“A federal information system is an information system used or operated by an agency, a contractor of an agency, or another organization on behalf of an agency.”

SP 800-53 Rev. 5 Sec. 1.1 fn. 10; 44 U.S.C. 3554(b); SR-6(1); SP 800-53B Table 3-20 (SR-6(1))

NIST states the catalog covers industrial control and cyber-physical systems, and CA-8 applies to organization-defined systems or components. No control sets OT-specific testing rules.

“safeguarding measures for all types of computing platforms, including general purpose computing systems, cyber-physical systems, cloud-based systems, ... environmental control systems, super computers, and industrial control systems.”

SP 800-53 Rev. 5 Executive Summary; Chapter One; CA-8

FISMA and the NIST testing controls do not mention payment systems, SWIFT, card data or market infrastructure.

The catalog covers cloud-based systems, and systems run by other organizations on an agency’s behalf are federal information systems. No testing control mentions cloud. Cloud services used by agencies are tested under FedRAMP (see us-fedramp-rev5 and us-fedramp-cr26).

“safeguarding measures for all types of computing platforms, including general purpose computing systems, cyber-physical systems, cloud-based systems”

SP 800-53 Rev. 5 Executive Summary; Sec. 1.1 fn. 10

No provision on multi-country tests, foreign group entities or data location during testing.

Red team results feed awareness training and control assessment, but no text calls for purple teaming or joint replay with defenders.

FISMA requires a remedial action process. CA-5 plans of action and milestones are in every baseline, and RA-5(d) requires remediation within organization-defined response times. No fixed deadline or mandated retest.

“a process for planning, implementing, evaluating, and documenting remedial action to address any deficiencies in the information security policies, procedures, and practices of the agency”

44 U.S.C. 3554(b)(6); SP 800-53 Rev. 5 CA-5, RA-5(d); SP 800-53B Table 3-4 (CA-5)

Each Inspector General or independent auditor must evaluate the agency every year, including testing a representative subset of systems. OMB’s FY2025 IG metrics tell IGs to weigh penetration test results. CISA (DHS) may hunt for threats and run vulnerability assessments on agency systems under 44 U.S.C. 3553(b)(6)(D) and (b)(7).

“testing of the effectiveness of information security policies, procedures, and practices of a representative subset of the agency’s information systems”

44 U.S.C. 3555(a)(2)(A); 44 U.S.C. 3553(b)(6)(D) and (b)(7); FY2025 IG FISMA Reporting Metrics v2.0, p. 9

FISMA requires automated tools in annual testing. CA-8 says penetration testing goes beyond automated scanning. The FY2026-27 CIO FISMA metrics add pilot questions on AI systems, including whether assessments cover AI-specific risks (CIO-FY26-0170).

“shall include using automated tools, consistent with standards and guidelines promulgated under section 11331 of title 40”

44 U.S.C. 3554(b)(5)(C); SP 800-53 Rev. 5 CA-8 Discussion; FY26-27 CIO FISMA Metrics v1.1, CIO-FY26-0170

Agencies must obtain and maintain a FedRAMP authorization for in-scope cloud services (OMB M-24-15 Sec. III under the FedRAMP Authorization Act). The Rev5 baselines set CA-8 with a FedRAMP parameter of at least annually.

“Agencies must obtain and maintain a FedRAMP authorization when the cloud product or service falls within the scope of this section.”

OMB M-24-15 Sec. III (as published in FedRAMP Consolidated Rules 2026, authority/m-24-15/scope)

Cloud IaaS, PaaS and SaaS that create, collect, process, store or maintain federal information for an agency. CA-8 is in the FedRAMP Low, Moderate and High baselines and LI-SaaS (‘Document and Assess’).

“The scope of FedRAMP is cloud computing products and services (such as IaaS, Platform-as-a-Service (PaaS), and SaaS) that create, collect, process, store, or maintain Federal information on behalf of a Federal agency”

OMB M-24-15 Sec. III; FedRAMP Rev5 baseline workbook, sheets Low/Moderate/High (CA-08) and LI-SaaS row 35

Code confirmed by v3.0 Sec. 7.0: initial test no more than 6 months before the assessment report, then at least every 12 months unless an authorizing body approves otherwise.

“Once within the continuous monitoring phase of the FedRAMP process, additional penetration testing activities must be performed at least every 12 months, unless otherwise approved by an authorizing body with documented rationale.”

FedRAMP Penetration Test Guidance v3.0, Sec. 7.0; Rev5 baseline workbook CA-08

Code confirmed against the controlling v3.0 text. Section 2.1 sets minimum threat models aligned with current adversary tactics in “should” language, and Section 2.2 points to MITRE ATT&CK. Cite moves from draft v4.0 to v3.0. Confidence moves from unverified to verified.

“FedRAMP penetration testing follows multiple threat models developed to align with current adversarial tactics and techniques.”

FedRAMP Penetration Test Guidance v3.0 (06/30/2022), Sec. 2.1 and 2.2

Code unchanged. v3.0 Sec. 8.0 requires the assessor to show penetration testing proficiency and keep a defined methodology, and the test team lead to hold an industry-recognized penetration testing credential. A FedRAMP recognized 3PAO is mandatory for JAB P-ATO systems; for agency ATOs, v3.0 lets ‘3PAO’ mean any assessment organization the agency AO designates (About This Document). The September cell cited draft v4.0 Sec. 8 for this point.

“All penetration test activities must be performed by a 3PAO that has demonstrated penetration testing proficiency and maintains a defined penetration test methodology.”

FedRAMP Penetration Test Guidance v3.0, Sec. 8.0

Code unchanged, detail corrected. v3.0 has no provider-run red team option; that was a draft v4.0 proposal. In v3.0 the 3PAO runs the test (Sec. 7.0), and for agency ATOs the agency AO may designate the assessment organization. The 3PAO may use the provider’s established phishing program if it provides or approves the templates and landing pages, and it must either run the campaign itself or independently evaluate a third party campaign (Sec. 3.1.1).

“3PAOs must either perform this attack vector themselves, or independently evaluate the effectiveness of a third party phishing campaign.”

FedRAMP Penetration Test Guidance v3.0, Sec. 3.1.1 and 8.0; Rev5 baseline workbook CA-08 (01)

Code confirmed against v3.0. External to Corporate is one of six mandatory attack vectors, and it requires a phishing attack on the provider’s system administrators and the managers who can influence them. Deviations need authorizing official approval. v3.0 sets no minimum campaign length; the one-week minimum was in draft v4.0 only. Confidence moves from unverified to verified.

“The External to Corporate attack vector requires the execution of a social engineering (phishing) attack against a CSP’s system administrators”

FedRAMP Penetration Test Guidance v3.0, Sec. 3.1 and 3.1.1

Code confirmed against v3.0. Physical based attack and unauthorized physical access are listed threat models in “should” language (Sec. 2.1). The rules of engagement should include physical penetration constraints (Sec. 5.0), and test planning must “include or account for” physical penetration (App. D). No physical test is mandatory. CA-8(3) is in no FedRAMP Rev5 baseline. Confidence moves from unverified to verified.

“Penetration test planning must include or account for the following considerations: Penetration Network penetration Wireless network penetration Physical penetration Social engineering penetration”

FedRAMP Penetration Test Guidance v3.0, Sec. 2.1, Sec. 5.0 and Appendix D

Code unchanged. The supplier seam here is the agency’s cloud supplier: every FedRAMP authorized offering must be penetration tested at least annually (Rev5 baseline workbook CA-08 parameter; PTG v3.0 Sec. 3.1 and 7.0). v3.0 adds, in ‘should’ language, that for IaaS the provider’s corporate shared services and their interconnections be assessed (Sec. 3.1.2). The provider must obtain permission for any third-party assets in scope (Sec. 4.0).

“CA-8-1 [at least annually]”

FedRAMP Rev5 baseline workbook CA-08; Penetration Test Guidance v3.0, Sec. 3.1.2 and 4.0

Code confirmed against v3.0. No OT or industrial control content.

Code confirmed against v3.0. No payment, card or market infrastructure content.

Code unchanged; cite moves to v3.0. Tenant to CSP Management System and Tenant-to-Tenant are mandatory vectors for IaaS, PaaS and SaaS, run in production with two customer tenants.

“Environments are required to be set up to test all aspects of the service provided, to include authentication, data access, user permissions, and sessions.”

FedRAMP Penetration Test Guidance v3.0, Sec. 3.1, 3.1.3 and 3.1.4

The penetration test guidance lists foreign adversaries pivoting from interconnected international networks into the US offering enclave as a minimum threat model for the CSP corporate attack vector. That is a test scenario, not a rule on the reach of the testing duty abroad, on tests run elsewhere or on where testers sit.

Corrected October 30, 2026 from Addressed. A threat model naming foreign adversaries is a test scenario, not a rule on reach, recognition or tester location.

Code confirmed against v3.0. No purple team, replay or red team provision; v3.0 has no red team appendix.

The provider records residual risks from the assessment report in a plan of action and milestones, and the schedule includes assessor remediation testing before the final report.

“be sure to build in time for developing the draft SAR, CSP remediation activities, assessor remediation testing, and final SAR development.”

FedRAMP legacy playbook, Annual Assessments, ‘Conduct the Security Assessment and Develop SAR’ and ‘Complete Plan of Action and Milestones (POA&M)’

Code kept. The report goes into the security assessment report for FedRAMP and agency customers, and the rules of engagement go to FedRAMP in the assessment plan. v3.0 also requires the authorizing official (the customer agency) to approve the rules of engagement and any deviation, which could support leads_or_oversees_test if the agency official is treated as the regulator.

“Penetration test assessment activities and results must be organized and compiled into a comprehensive penetration test report to be included in the SAR.”

FedRAMP Rev5 baseline workbook CA-02 parameter; Penetration Test Guidance v3.0, Sec. 1.0, 5.0, 6.0 and Appendix D

Code unchanged; cite moves to v3.0. The test must not be limited to automated scanning. No AI provision.

“The penetration test should not be strictly limited to automated scanning techniques, but manual techniques as well.”

FedRAMP Penetration Test Guidance v3.0, Sec. 2.2 and Appendix B

Rules use MUST and SHOULD. Providers must follow them to keep FedRAMP certification once mandatory adoption starts on Jan. 1, 2027; until then adoption is optional.

“The Consolidated Rules for 2026 take mandatory effect for all stakeholders, subject to specific overall applicability and effective dates within certain areas.”

FedRAMP Consolidated Rules 2026, Important Dates (timeline)

Cloud service offerings seeking or holding FedRAMP certification, graded by assurance class (A to D) rather than by impact level. Rev5 rulesets apply to Classes B, C and D; 20x to Classes A to D.

“A Certification Class describes the level of assurance information a cloud service provider supplies through FedRAMP for a cloud service offering.”

FedRAMP Consolidated Rules 2026, Certification Classes (agencies/use/classes); IVV-CSO-FIA

Class B to D providers must complete an independent assessment at least once per year (optional for Class A). For Rev5, the annual assessment must include CA-08 for Class B and CA-08(01) and CA-08(02) for Classes C and D; all applicable controls must be covered every 3 years. CA-08 itself no longer carries a FedRAMP frequency parameter and is folded into vulnerability detection.

“Providers with Class B Certifications MUST persistently complete an independent verification and validation assessment of all applicable FedRAMP rules with a FedRAMP Recognized independent assessment service OR FedRAMP at least once per year”

IVV-CSO-FIA; IVV-CSF-AIA; IVV-CSF-MCA; reference/controls CA-08

Providers must discover vulnerabilities using techniques such as assessment, scanning, threat intelligence, bug bounties and penetration testing (VDR-CSO-DET). Threat intelligence is a parallel discovery technique, not an input to test design, scope or timing. Coded not_addressed under R5, like threat intelligence used only for prioritization or risk mitigation (NCSA vulnerability guidelines, QCB § 5.3.4).

Corrected October 30, 2026 from Recommended. VDR-CSO-DET lists threat intelligence as one technique for discovering vulnerabilities, next to penetration testing, and does not tie test scenarios, scope or timing to it; coded as NCSA’s vulnerability guidelines and QCB § 5.3.4.

Independent assessments must be done by a FedRAMP Recognized assessment service or FedRAMP itself. Recognition requires A2LA accreditation under R311, an annual A2LA surveillance, full reassessment every 2 years, staffing to R311 roles, and annual foreign ownership reports.

“Assessors MUST obtain and maintain accreditation through the American Association for Laboratory Accreditation (A2LA) Cybersecurity Inspection Body Program to qualify for FedRAMP Recognition.”

REC-IAS-ACC; REC-IAS-ANR; REC-IAS-RAS; REC-IAS-RQU; REC-IAS-AFI

Providers run their own vulnerability detection, which includes penetration testing. The annual independent assessment must be done by a recognized assessor or FedRAMP, and for Rev5 Classes C and D it must cover CA-08(01), the independent tester control.

“Providers with Rev5 Class C Certifications MUST include the following Rev5 Controls in a FedRAMP independent assessment at least once per year”

VDR-CSO-DET; IVV-CSF-AIA (Class C and D control lists)

The consolidated rules do not mention social engineering or phishing tests. Phishing appears only in phishing-resistant MFA requirements. The prescriptive attack vectors of the legacy guidance are gone.

No physical penetration testing rule. PE-03 physical access control is in the annual assessment list, and CA-08(03) facility testing appears in the control reference with no class baseline.

The whole regime tests agencies’ cloud suppliers. Providers must also detect vulnerabilities through supply chain monitoring.

“Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering”

VDR-CSO-DET; OMB M-24-15 Sec. III

No OT or industrial control content.

No payment, card or market infrastructure content.

Every certified cloud offering must run vulnerability detection that includes penetration testing among its techniques and undergo annual independent assessment.

“Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering using appropriate techniques such as assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, penetration testing”

VDR-CSO-DET; IVV-CSO-FIA

No rule on multi-country tests or data location during testing. Foreign ownership reporting applies to assessors, not to test scope.

No purple teaming or replay provision.

Providers must track, mitigate and remediate all detected vulnerabilities, with class-based target timeframes (SHOULD). Controls with negative findings must be reassessed in the next independent assessment.

“Providers MUST have Rev5 Controls with negative findings from the previous FedRAMP independent assessment included in the next FedRAMP independent assessment.”

VDR-CSO-RES; VDR-TFR-PVR; IVV-CSF-ACF

Under Program Certification FedRAMP completes the official assessment, and the independent assessor must take part in FedRAMP’s assessment. FedRAMP itself may perform the independent assessment.

“FedRAMP will expect the independent assessment service to participate in FedRAMP's assessment alongside the cloud service provider and explain their process, findings, concerns, etc.”

FedRAMP Consolidated Rules 2026, assessors/updating/changes (‘The Program Certification Process’); IVV-CSO-FIA

Detection must be persistent, and providers should automate it, with class-based cycles down to daily sampling for Class D. No provision on AI-driven testing or on testing AI systems.

“Providers SHOULD use automated services to improve and streamline vulnerability detection and response.”

VDR-CSO-ADT; VDR-TFR-PSD

BOD 18-02 is a compulsory directive under FISMA, and M-19-03 uses ‘shall’ for HVA assessment and remediation. Both do not apply to national security systems or certain DoD and IC systems.

“A binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems.”

BOD 18-02 (preamble); M-19-03 p. 5-6

Federal civilian executive branch agencies must report HVAs; CISA and OMB select HVAs for assessment. ‘Related systems’ include the network infrastructure that the HVA depends on, as DHS decides. Tier 1 HVAs are of critical impact to the agency and the nation; Non-Tier 1 of significant impact.

“Agencies shall impose no restrictions on the timing and/or frequency of the assessments, the services to be provided by DHS, or the scope of systems that are part of or related to the HVA being assessed.”

BOD 18-02 Actions One to Three and fn. 6; HVA PMO Overview

Each HVA must be assessed at least once every 3 years: CISA leads Tier 1 assessments; an AES-qualified assessor may do Non-Tier 1. M-19-03 leaves frequency to DHS.

“HVA Assessment | Each HVA | CISA-Led once every 3 years | Assessment Evaluation and Standardization (AES) Qualified Assessor once every 3 years”

HVA PMO Table 1 ‘HVA Assessment and Frequency Requirements’; M-19-03 p. 5 (Assessment item 1)

CISA’s Risk and Vulnerability Assessment blends national threat information with its own findings and tests with current real-world TTPs. No text requires agencies to run intelligence-led scenarios.

“RVAs combine open-source national threat and vulnerability information with data that the CISA RVA team collects through remote and onsite stakeholder assessment activities.”

CISA RVA Fact Sheet (Feb. 2022), Overview

Only DHS (CISA), a third-party assessor bound by a legally binding agreement that follows DHS requirements, or an independent agency assessment entity may assess. Non-Tier 1 assessors must be AES-qualified; only CISA staff may run official CISA assessments.

“DHS, third-party assessor, or an agency’s independent assessment entity shall conduct the assessments, incorporating them as part of existing agency cybersecurity programs.”

M-19-03 p. 6 (Assessment item 1); HVA PMO Table 1; CISA AES Program page

An agency’s own independent assessment entity may assess if it reports to the CIO and C-suite, and only for Non-Tier 1 HVAs; Tier 1 assessments are CISA-led.

“Independent assessment entities within an agency may perform an HVA assessment provided the entity reports to the CIO and the remaining C-Suite.”

M-19-03 fn. 16; HVA PMO Table 1

CISA’s RVA service includes an email phishing campaign as one option, and BOD 18-02 bars agencies from limiting the services DHS provides. No rule makes phishing mandatory in every HVA assessment.

“Specific types of testing and assessments include network, web application, wireless, war dial, and social engineering in the form of an email phishing campaign.”

CISA RVA Fact Sheet (Feb. 2022), ‘RVA service includes’; BOD 18-02 Action Three

None of the HVA texts mention physical intrusion or facility testing. The RVA includes onsite activity, but not physical penetration.

Agencies must write HVA assessment rights into all contracts and service agreements, including contractor-owned, contractor-operated systems.

“Incorporate requirements into all existing and future contracts and service-level agreements (SLAs) that enable the execution of HVA assessments for Federal information systems, including cloud-managed services and contractor-owned, contractor-operated systems.”

M-19-03 p. 6 (Assessment item 3)

A Validated Architecture Design Review is an optional, CISA-led assessment for HVAs with OT components, including SCADA, available on agency request.

“Validated Architecture Design Review (VADR) | Optional - Each HVA that includes operational technology components including SCADA systems | CISA-Led available by agency request”

HVA PMO Table 1 (VADR row)

No payment or market infrastructure provision.

Contracts and service agreements for cloud-managed services must allow HVA assessments.

“including cloud-managed services and contractor-owned, contractor-operated systems.”

M-19-03 p. 6 (Assessment item 3)

No cross-border provision.

No purple teaming or replay provision. CISA lists a Red Team Assessment only as a recommended supplemental assessment at agency or sub-component level.

Major or critical weaknesses must be fixed within 30 days of the RVA or SAR report. If not, the agency files a remediation plan signed by its senior risk official, capped at one year, and reports status every 30 days. Findings the agency will not fix need a risk acceptance letter signed by the agency head.

“Within 30 days of receipt of the RVA and/or SAR reports identifying major or critical weakness to an assessed HVA, remediate all major or critical weaknesses and provide notification to DHS that each identified weakness was addressed.”

BOD 18-02 Action Four; M-19-03 p. 7 (Remediation item 4)

CISA plans and conducts RVAs and Security Architecture Reviews on OMB-selected HVAs and leads all Tier 1 assessments. Results of third-party or agency assessments must go to DHS.

“DHS plans and conducts RVAs and SARs for OMB-selected Agency HVAs, and provides formal reports containing assessment findings and recommendations to the designated Agency HVA POCs.”

BOD 18-02 ‘DHS Actions’; HVA PMO Table 1; M-19-03 p. 6 (Assessment item 2)

Only mention is continuous monitoring: annual testing does not mean every control each year, because agencies must continuously monitor controls. No AI provision.

“agencies must continuously monitor all implemented security and privacy controls (i.e., system-specific, hybrid, and common controls) with a frequency determined by the agency”

M-19-03 fn. 15

OMB memorandum to agency heads; the application actions use ‘must’.

“Agencies must operate dedicated application security testing programs.”

M-22-09 Sec. III.D, Actions 1-3

Executive departments and agencies; every application is to be treated as internet-accessible and tested whether built in-house or by a vendor.

“agencies must analyze their software and its deployed functionality with a comprehensive and rigorous approach, whether their software is built internally or by a contracted vendor.”

M-22-09 Sec. III.D.1

No fixed cycle. Agencies should move to continuous monitoring with periodic manual assessments as applications and their dependencies change.

“Agencies are expected to continue moving toward continuous monitoring and ongoing authorizations while employing periodic manual security assessments as applications, dependencies, components, and infrastructure evolve.”

M-22-09 Sec. III.D.1

The memo asks agencies to scrutinize applications as adversaries do, but says nothing on threat intelligence driving tests.

Agencies must use specialized application security firms for independent evaluation. No accreditation is named; CISA and GSA were to set up rapid procurement.

“Agencies must utilize high-quality firms specializing in application security for independent third-party evaluation.”

M-22-09 Sec. III.D, Action 2; Sec. III.D.2

Agencies must run their own testing programs, but must add external testers to find what internal staff miss.

“In addition to their own testing programs, agencies must increase their reliance on external perspectives to identify vulnerabilities that internal staff may not identify.”

M-22-09 Sec. III.D.2

Phishing appears only as the threat that phishing-resistant MFA addresses; no social engineering test.

No physical testing provision.

Vendor-built agency software is in scope for the same rigorous analysis.

“whether their software is built internally or by a contracted vendor.”

M-22-09 Sec. III.D.1

No OT provision.

No payment provision.

FedRAMP was tasked to confirm with cloud platforms that agencies may authorize testing of agency applications hosted on those platforms.

“FedRAMP will assist agencies by working with cloud platform providers to clarify that Federal agency customers are permitted to authorize vulnerability testing on customer-operated applications and infrastructure hosted on provider platforms.”

M-22-09 Sec. III.D.3

No cross-border provision.

No purple teaming or replay provision.

Agencies must prioritize and fix vulnerabilities found through these methods; no deadline or retest rule.

“Agencies must prioritize and address vulnerabilities identified in their SAR through these methods.”

M-22-09 Sec. III.D.1

OMB may ask any agency at any time for an application’s latest security assessment.

“OMB may at any time ask an agency to produce an application’s most recent security assessment.”

M-22-09 Sec. III.D.1

Authorization must combine automated tools and manual expert analysis; scanners alone do not give confidence.

“Agency system authorization processes must employ both automated analysis tools and manual expert analysis.”

M-22-09 Sec. III.D.1

A final OCC rule. Its testing duties use “must”. It takes effect on January 18, 2027, the same day as the GENIUS Act, so no issuer is bound by it yet.

“A permitted payment stablecoin issuer must implement a comprehensive written information security risk and control framework, including a program that assesses and manages information technology and information security risks.”

§ 15.13(b)(1); preamble, III. Effective Date

Stablecoin subsidiaries of national banks and federal savings associations, federal qualified issuers, and state qualified issuers that fall under OCC authority. Foreign issuers register with the OCC but are not bound by § 15.13.

“Subsidiary of an insured national bank or Federal savings association that has been approved to issue payment stablecoins under Sec. 15.30; (2) Federal qualified payment stablecoin issuer; or (3) State qualified payment stablecoin issuer subject to the OCC's regulatory or enforcement authority under section 4 of the GENIUS Act”

§ 15.1(b); § 15.2 (Permitted payment stablecoin issuer)

The program must include periodic independent testing. The rule sets no interval and does not name penetration testing. Section 15.13(b)(8) adds testing for vulnerabilities as a resilience measure.

“Periodic independent testing; and (v) A comprehensive and effective incident identification and assessment process and incident response program.”

§ 15.13(b)(3)(iv); § 15.13(b)(8)

Issuers must monitor internal and external threats and adjust the program (§ 15.13(b)(6)). Nothing ties test scenarios or scope to threat intelligence.

Testing must be independent. The internal audit system must provide independence, objectivity and qualified persons (§ 15.13(a)(2)(ii)-(iii)). No certification or accreditation is named.

“Adequate independent testing and review of internal controls and information systems, verification of published information available to customers, calculations for required reserves, and regulatory filings;”

§ 15.13(a)(2)(iv); § 15.13(b)(3)(iv)

Independent testing and review of internal controls and information systems is an element of the internal audit system (§ 15.13(a)(2)(iv)), which must provide independence, objectivity and qualified persons. In-house auditors may test if they meet those conditions. Smaller issuers may use a system of independent reviews of key controls instead of a full internal audit function.

“Adequate monitoring of the system of internal controls through an internal audit function, or, if the size, complexity, or scope of operations of the permitted payment stablecoin issuer does not warrant a full-scale internal audit function, a system of independent reviews of key internal controls;”

§ 15.13(a)(2)(i)-(ii)

The rule text does not mention social engineering or staff training.

The program must include physical safeguards for customer records (§ 15.13(b)(4)). No text on testing physical controls.

Issuers must review audits, summaries of test results or equivalent evaluations of service providers, and the resilience program must include testing with critical service providers. Provider systems are not placed inside the issuer’s own security test.

“As part of this monitoring, a permitted payment stablecoin issuer must review audits, summaries of test results, or other equivalent evaluations of its service providers.”

§ 15.13(a)(7)(iii); § 15.13(b)(8)

No provision.

The regime covers payment stablecoin issuers, so the issuer’s own payment systems are the subject. Key systems and controls, including smart contracts, must be evaluated and validated to confirm they work as intended.

“Evaluation, validation, and reporting processes to ensure that key information technology systems and controls, including smart contracts, are operating as intended;”

§ 15.13(b)(3)(iii)

“Cloud” appears only in a preamble summary of comments on licensing, not in the rule text.

A foreign payment stablecoin issuer is not subject to the GENIUS Act prohibitions if its home regulator runs a regime the Treasury finds comparable and it registers with the OCC (§ 15.31(a)). The § 15.13 testing duties do not bind it. Nothing on cross-border tests or where testers sit.

“The foreign payment stablecoin issuer is subject to regulation and supervision by a foreign payment stablecoin regulator that has a regulatory and supervisory regime comparable to the GENIUS Act with respect to payment stablecoins”

12 CFR 15.31(a)(1) and (2)

No provision.

Internal audit must document tests, findings and corrective actions, and verify management’s fixes. The program must be adjusted after monitoring (§ 15.13(b)(6)(ii)). No deadline.

“Adequate documentation of tests and findings and any corrective actions; (vi) Verification and review of management actions to address deficiencies; and”

§ 15.13(a)(2)(v)-(vi)

The OCC runs a full-scope examination at least every 12 months (18 to 24 months for small issuers that qualify) and gets access to all records. Test results are not filed routinely.

“The OCC will conduct a full-scope examination of every permitted payment stablecoin issuer subject to its supervision at least once during each 12-month period, unless otherwise specified in paragraph (d) of this section.”

§ 15.14(a)-(d)

No provision in the rule text. Smart contracts are named as systems to validate, but nothing addresses automated testing or AI.

Advisory bulletins state FHFA supervisory expectations and are used in examinations. They are not regulations. A cell is coded required only where FHFA uses its own expectation words (‘FHFA expects’); its ‘should’ is coded recommended, or permitted on the seam dimensions (R3).

“Advisory bulletins describe FHFA supervisory expectations for safe and sound operations in particular areas and are used in FHFA examinations of the regulated entities.”

AB 2023-02, p. 13 (closing note)

Fannie Mae, Freddie Mac, the Federal Home Loan Banks and their Office of Finance. AB 2023-02 also applies to Common Securitization Solutions, LLC, an affiliate of both Enterprises (AB 2023-02, n. 2).

“guidance on information security management for supporting a safe and sound operational environment and promoting the resilience of Fannie Mae, Freddie Mac, the Federal Home Loan Banks, and the Office of Finance (OF)”

AB 2017-02, Purpose

Management sets the scope and frequency of tests in risk-based policies, with triggers such as major technology changes or a security incident. AB 2023-02 adds that penetration tests should run periodically after deployment.

“Management should develop and maintain risk-based policies that define the scope and frequency of regular tests.”

AB 2017-02, III.B; AB 2023-02, Q11

Threat intelligence sharing is a program area (AB 2017-02, III.J) and threat modeling is an option in development (AB 2023-02, Q11). Neither ties test scenarios to threat intelligence.

FHFA says the regulated entities should engage third parties to perform independent penetration testing (AB 2023-02, Q11). Coded recommended under R3, as the FFIEC booklet’s ‘should review qualifications’ text. No certification or accreditation is named.

“The regulated entities should engage third parties to perform independent penetration testing”

AB 2023-02, Q11 (Penetration Testing)

Internal penetration testing is expected “as necessary” in addition to, not instead of, independent third-party testing. AB 2017-02 says independent parties “may” conduct and review tests.

“as well as perform internal penetration testing as necessary.”

AB 2023-02, Q11; AB 2017-02, III.B

AB 2023-02 says the regulated entities should, as a matter of routine, conduct social engineering testing, with phishing simulations as the example. Coded permitted under R3: a supervisory bulletin’s ‘should’ on a seam dimension, with legal_force recording that the bulletin is guidance.

“the regulated entities should, as a matter of routine, ensure they update security awareness trainings regularly, conduct social engineering testing (e.g., phishing simulations), and review network device configurations to ensure only legitimate traffic is allowed.”

AB 2023-02, Q2 (Social Engineering)

Physical facilities are monitored (AB 2017-02, III) and incident plans cover physical events (III.F). No text on testing physical controls or physical intrusion.

Entities monitor providers, conduct on-site reviews where necessary, obtain attestations and review independent reports such as ISO 27001, PCI and SOC reports. Provider systems stay outside the entity’s own test.

“The regulated entities should also review independent reports on a third-party provider's security program, such as ISO 27001 certification, and PCI compliance and control reports (e.g., Service Organization Control).”

AB 2023-02, Q4 (information security at third-party providers); AB 2017-02, III.I

No provision.

No provision.

AB 2023-02 applies AB 2017-02 vulnerability management to the cloud, and in IaaS and PaaS models the entity is responsible for it. That vulnerability management includes regular penetration testing in ‘should’ language (AB 2017-02, III.B). AB 2018-04, III.B says the entity ‘should assess compliance with its security policies through regular tests of key controls, systems, and procedures it uses for its cloud environment(s).’ Coded permitted under R3. SaaS and provider infrastructure stay with the provider.

“The vulnerability management concepts outlined in AB 2017-02: Information Security Management apply to the cloud environment. Vulnerability management of cloud infrastructure is typically managed by the CSP; however, in a platform-as-a-service and infrastructure-as-a-service model, the customer is responsible for vulnerability management in the cloud.”

AB 2023-02, Q9 (Vulnerability Management)

No testing provision. FHFA AB 2018-04 (cloud) asks entities to weigh legal and security risk before hosting data outside the United States; it says nothing on testing.

Incident analyses should identify improvements (AB 2017-02, III.F). No joint attacker and defender review of test results.

FHFA expects a continual practice of cyber hygiene that includes scanning for and timely patching of vulnerabilities and conducting penetration tests (AB 2023-02, p. 2). Procedures should also be in place to track and independently validate remediation, and accepted vulnerabilities need management approval and justification (AB 2017-02, III.B); that retest is a ‘should’. No deadline. A supervisory bulletin, not a binding rule (see legal_force).

“FHFA expects a continual practice of cyber hygiene such as scanning for and timely patching of vulnerabilities and conducting penetration tests.”

AB 2023-02, p. 2; AB 2017-02, III.B

FHFA examiners use the bulletins. Test results are not filed with FHFA.

“Advisory bulletins communicate guidance to FHFA supervision staff and the regulated entities on specific supervisory matters pertaining to the Federal Home Loan Banks, the Office of Finance, Fannie Mae, and Freddie Mac.”

AB 2017-02, p. 12 (closing note); AB 2023-02, p. 13

Testing includes vulnerability scanning, and the program includes continuous monitoring (AB 2017-02, III.A). FHFA AB 2022-02 (revised May 2025) lists, among controls Fannie Mae and Freddie Mac ‘should also consider’, whether an independent assessment of third-party AI/ML models covers their security (III.A), and testing of in-house and third-party AI/ML tools to assess integrity, security and business resiliency (III.C). No text covers AI-driven testing or red teaming of AI.

“The regulated entity should regularly test the effectiveness of key controls, systems, and procedures used to protect against information security risks through vulnerability scanning, internal and external audits, and penetration testing.”

AB 2017-02, III.B; AB 2022-02, III.A

A binding FCA regulation. Its testing duties use “must”.

“Each System institution must implement a comprehensive, written cyber risk management program consistent with the size, risk profile, and complexity of the institution's operations.”

§ 609.930(a)

Farm Credit System institutions. Each must run a written cyber risk management program.

“The final rule requires each Farm Credit System (System or FCS) institution to implement a comprehensive, written cyber risk management program”

88 FR 85825 (Summary); § 609.930(a)

Regular testing of key controls, systems and procedures. The risk assessment sets the frequency and nature. No penetration test is named.

“The frequency and nature of such tests are to be determined by the institution's risk assessment.”

§ 609.930(c)(6)(i)

An annual risk assessment covers internal and external factors (§ 609.930(c)(1)). Nothing ties tests to threat intelligence.

Tests must be run or reviewed by independent third parties or by staff independent of those who build or maintain the program. No certification is named.

“Tests must be conducted or reviewed by independent third parties or staff independent of those who develop or maintain the cyber risk management program.”

§ 609.930(c)(6)(ii)

In-house staff may test if they are independent of those who develop or maintain the program.

“Tests must be conducted or reviewed by independent third parties or staff independent of those who develop or maintain the cyber risk management program.”

§ 609.930(c)(6)(ii)

The program must describe a training plan for employees, vendors, contractors and the board (§ 609.930(c)(4)). No testing of people.

No provision.

Institutions assess and monitor vendors and may review their audits and test summaries. Vendor systems are not placed inside the institution’s test.

“Monitor its IT and cyber risk management related vendors to ensure they have satisfied agreed upon expectations and deliverables. Monitoring may include reviewing audits, summaries of test results, or other equivalent evaluations of its vendors.”

§ 609.930(c)(5)(iv)

No provision.

No provision.

No provision.

No provision.

No provision.

Institutions must remediate vulnerabilities in a timely way (§ 609.930(c)(2)) and their controls must give reasonable assurance that material deficiencies are fixed on time. No deadline or retest rule.

“Internal systems and controls must provide reasonable assurances that System institutions will prevent, detect, and remediate material deficiencies on a timely basis.”

§ 609.930(c)(2); § 609.930(c)(6)(iii)

The board receives quarterly reports on the program (§ 609.930(e)) and FCA receives incident notices within 36 hours (§ 609.930(c)(3)(v)). The section does not provide for FCA to receive or review test results.

No provision.

A Federal Reserve regulation under Title VIII of the Dodd-Frank Act. The 2024 amendments require a documented testing framework.

“A designated financial market utility must implement rules, procedures, or operations designed to ensure that it meets or exceeds the following risk-management standards with respect to its payment, clearing, and settlement activities.”

§ 234.3(a)

Payment, clearing and settlement utilities designated as systemically important for which the Board is the Supervisory Agency. Designated clearing agencies and DCOs follow SEC or CFTC standards instead.

“The risk management standards do not apply, however, to a designated financial market utility that is a derivatives clearing organization registered under section 5b of the Commodity Exchange Act (7 U.S.C. 7a-1) or a clearing agency registered with the Securities and Exchange Commission”

§ 234.1(b)

Controls are tested periodically and after major changes under a documented framework that sets scope and frequency. Business continuity arrangements, including live production at the second site, are tested at least once a year.

“Provides for testing, pursuant to the requirements under paragraphs (a)(17)(i)(A) and (C) of this section, at least annually, of the designated financial market utility's business continuity arrangements, including the people, processes, and technologies of the sites”

§ 234.3(a)(17)(i)(A); § 234.3(a)(17)(viii)(E)

The rule text requires a documented testing framework but not threat intelligence. The adopting release says tests “could include” cyber scenario-based testing, penetration tests and red team tests (89 FR 18752, n. 23). That is an example list, not a requirement.

Independence rules cover the risk-management and internal audit functions (§ 234.3(a)(2)(iv)(H)-(I)) and model validation, not security tests.

The rule does not say who may run tests.

No provision.

Tests cover the systems, policies, procedures and controls required under paragraph (a)(17), which include physical security controls. No physical intrusion method is required.

“Has comprehensive physical, information, and cyber security policies, procedures, and controls that enable the designated financial market utility to identify, monitor, and manage potential and evolving vulnerabilities and threats;”

§ 234.3(a)(17)(i), (v)

Third parties that provide material services must be addressed in business continuity management and testing, and outsourced services must be risk-managed as if the FMU performed them. The text does not place provider systems inside security tests.

“Addresses in its business continuity management and testing, as appropriate, third parties that provide services material to any of the designated financial market utility's critical operations or services.”

§ 234.3(a)(17)(ix)

No provision.

The rule governs payment, clearing and settlement utilities themselves, so their core systems are the subject of the testing standard.

“This part establishes risk-management standards governing the operations related to the payment, clearing, and settlement activities of designated financial market utilities.”

§ 234.1(b)

No provision.

The legal basis standard covers “all relevant jurisdictions” (§ 234.3(a)(1)). No testing provision on foreign entities or tester location.

Lessons learned are folded in after incidents and in the annual business continuity review (§ 234.3(a)(17)(vi), (viii)(F)). No joint attacker and defender review of tests.

Deficiencies found in review or testing must be fixed as soon as possible through governance processes. Design and testing are reviewed again after material incidents.

“The designated financial market utility remediates as soon as possible, following established governance processes, deficiencies in systems, policies, procedures, or controls identified in the process of review or testing;”

§ 234.3(a)(17)(i)(B)-(C)

The FMU must notify the Board immediately of material incidents (§ 234.3(a)(17)(vi)(A)). Section 234.3 does not provide for the Board to receive or review test results.

“Automated” appears only in a list of systems in the incident rule. No provision on automated testing.

An SEC rule. Testing duties use “shall”.

“A security-based swap execution facility shall conduct regular, periodic, objective testing and review of its automated systems to ensure that they are reliable, secure, and have adequate scalable capacity.”

§ 242.830(b)(8)

SEC-registered SBSEFs. The text mirrors the CFTC rule for swap execution facilities (17 CFR 37.1401).

“Establish and maintain a program of risk analysis and oversight to identify and minimize sources of operational risk, through the development of appropriate controls and procedures, and automated systems”

§ 242.830(a)

Vulnerability, external and internal penetration, controls and incident response plan tests each run at a frequency set by risk analysis. No fixed minimum.

“A security-based swap execution facility shall conduct such external penetration testing at a frequency determined by an appropriate risk analysis.”

§ 242.830(b)(8)(ii)-(vi)

Test scope must cover what the facility’s current cybersecurity threat analysis shows is needed. Same wording and same code as the CFTC row.

“The scope for all system safeguards testing and assessment required by this section shall be broad enough to include the testing of automated systems and controls that the security-based swap execution facility's required program of risk analysis and oversight and its current cybersecurity threat analysis indicate is necessary”

§ 242.830(b)(10)

Penetration, vulnerability and controls tests must use independent contractors or employees not responsible for the systems tested. No certification is named.

“A security-based swap execution facility shall conduct external penetration testing by engaging independent contractors or by using employees of the security-based swap execution facility who are not responsible for development or operation of the systems or capabilities being tested.”

§ 242.830(b)(8)(iii)(B)

Employees may test if they are not responsible for developing or operating the systems tested.

“A security-based swap execution facility shall conduct internal penetration testing by engaging independent contractors, or by using employees of the security-based swap execution facility who are not responsible for development or operation of the systems or capabilities being tested.”

§ 242.830(b)(8)(iv)(B)

Controls testing must include testing of each control in the program of risk analysis and oversight (§ 242.830(b)(8)(v)(A)), and the program’s information security category includes security awareness training and personnel security and screening (§ 242.830(b)(1)(ii)). No text names social engineering, phishing or pretexting as a test method.

“This category includes, but is not limited to, controls relating to: Access to systems and data (including least privilege, separation of duties, account monitoring, and control); user and device identification and authentication; security awareness training”

§ 242.830(b)(1)(ii); § 242.830(b)(8)(v)(A)

Controls testing covers each control in the program, and the program includes physical access and monitoring. No physical intrusion method.

“Physical security and environmental controls. This category includes, but is not limited to: Physical access and monitoring; power, telecommunication, and environmental controls; fire protection;”

§ 242.830(b)(1)(vii); § 242.830(b)(8)(v)(A)

Outsourcing and vendor management is listed as a program category (§ 242.830(b)(1)(vi)). No text places provider systems in the test or requires provider reports.

No provision.

The rule applies to security-based swap trading venues themselves, and testing covers the automated systems that run them.

“Periodically conduct tests to verify that the backup resources of the security-based swap execution facility are sufficient to ensure continued: (i) Order processing and trade matching;”

§ 242.830(a)(3)

No provision.

No provision in § 242.830.

Incident response plan tests may use walk-throughs, tabletop exercises, simulations and comprehensive exercises. No joint attacker and defender review.

Findings must be documented and either remediated in a timely manner or accepted. Senior management and the board review results (§ 242.830(b)(11)). No deadline or retest rule.

“When the security-based swap execution facility determines to remediate a vulnerability or deficiency, it must remediate in a timely manner given the nature and magnitude of the associated risk.”

§ 242.830(b)(12)

Test reports go to the SEC promptly on request. They are not filed routinely.

“the security-based swap execution facility shall provide to the Commission the following system-safeguards-related books and records, promptly upon the request of any Commission representative:”

§ 242.830(b)(7)(iii)

Vulnerability testing must include automated scanning. No AI text.

“Such vulnerability testing shall include automated vulnerability scanning, which shall follow generally accepted best practices.”

§ 242.830(b)(8)(ii)(B)

The controls are a condition of receiving federal tax information (FTI) under IRC 6103(p)(4). The IRS can withhold FTI from an agency that does not meet them.

“This document contains the managerial, operational, and technical security controls that must be implemented as a condition of receipt of FTI.”

Publication 1075 (Rev. 11-2021), Introduction (Overview of Publication 1075), p. 24; Sec. 1.1; Sec. 1.7.2

Every federal, state and local agency that receives FTI, including its consolidated data centers and contractors. Penetration testing applies to the FTI environment.

“Requirements throughout this document apply to all organizational segments of an agency receiving FTI.”

Publication 1075, Introduction, p. 24; Sec. 4.4 CA-8

Penetration test of the FTI environment every three years. Vulnerability scanning every 30 days (RA-5).

“Conduct penetration testing every 3 years on the FTI environment.”

Publication 1075, Sec. 4.4, CA-8 (p. 110)

Supplemental guidance to CA-8 links the rules of engagement to adversary tactics. No rule requires intelligence-led scenarios.

“Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries.”

Publication 1075, Sec. 4.4, CA-8 Supplemental Guidance

Supplemental guidance describes testers with demonstrable skills. No accreditation or certification is named. Contracts or rules of engagement must protect any FTI the testers see.

“Penetration testing goes beyond automated vulnerability scanning and is conducted by agents and teams with demonstrable skills and experience that include technical expertise in network, operating system, and/or application level security.”

Publication 1075, Sec. 4.4, CA-8 Supplemental Guidance

No independent tester is required. The agency sets the level of tester independence through its risk assessment.

“Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing.”

Publication 1075, Sec. 4.4, CA-8 Supplemental Guidance

Agencies must run phishing email simulation exercises at least quarterly (AT-2, IRS-defined requirement). Awareness training must also include practical exercises that simulate incidents, with social engineering and spear phishing as examples (Sec. 2.D.2.1). This sits in the awareness control, not in the penetration test. Coded required, as for ARC-AMPE AT-02 b and CBK CORF 4.5.2.8.

“Conduct phishing email simulation exercises on at least a quarterly basis.”

Publication 1075, Sec. 4.2, AT-2 (IRS-Defined), p. 100; Sec. 2.D.2.1 Disclosure Awareness Training, p. 63

Agencies must inspect physical safeguards for FTI in internal inspections: every 18 months for headquarters, computer facilities and contractors, every 3 years for field offices. No intrusion test is required.

“Required items to review during internal inspections include recordkeeping, secure storage, limited access, disposal, and cybersecurity.”

Publication 1075, Sec. 2.D.3 Internal Inspections and On-Site Reviews

The requirements, including CA-8 on the FTI environment, extend to consolidated data centers, contractors and sub-contractors with FTI access. Agencies must also inspect contractors at least every 18 months.

“It is the agency’s responsibility to ensure all functions within the agency, including consolidated data centers, contractors, and sub-contractors (where allowed by federal statute) with access to FTI, understand and implement the requirements in this publication.”

Publication 1075, Introduction, p. 24; Sec. 2.D.3

No OT testing content. SCADA appears once, in a wireless networking control, not in testing.

No payment system content. “Payment” appears only for tax refund offset payments.

FTI in the cloud needs prior notice to the IRS and a FedRAMP authorized provider. The agency relies on the provider’s FedRAMP authorization rather than testing the provider.

“Document the cloud service provider's FedRAMP authorization such that Safeguards does not have the responsibility to assess the physical security of cloud service provider facilities”

Publication 1075, Sec. 2.E.6.1 Cloud Computing, p. 76; Sec. 3.3.1 (a), p. 82

Residency limit. Nobody located outside the United States, its territories, embassies or military installations may access FTI, and FTI systems must be run by people in the United States.

“FTI cannot be accessed by agency employees, agents, representatives, contractors, or sub-contractors located outside of the legal jurisdictional boundary of the United States”

Publication 1075, Sec. 2.C.7 Offshore Operations

No purple team or replay provision. “Replay” appears only for replay-resistant authentication.

Findings go into a plan of action and milestones updated at least quarterly (CA-5). Scans must also confirm remediation (RA-5). IRS review findings go into a corrective action plan.

“The POA&M must comprise of an all-inclusive tool or document for the agency to track vulnerabilities identified by the self-assessments, internal inspections, external audits and any other vulnerabilities identified”

Publication 1075, Sec. 4.4 CA-5; Sec. 2.D.9; Sec. 4.16 RA-5; Sec. 2.E.5

The IRS Office of Safeguards reviews agencies on site or remotely, including automated scanning. Agencies send internal inspection results with the annual Safeguard Security Report, and a new recipient sends a security assessment report.

“A safeguard review is an on-site, remote, or a combination of both (hybrid) evaluation of the use of FTI and the measures employed by the receiving agency and its agents (where authorized) to protect the data.”

Publication 1075, Sec. 1.6 Safeguard Reviews; Sec. 2.D.3; Sec. 2.E.4 Table 3 (CA-2)

Monthly automated vulnerability scanning (RA-5). CA-8 guidance says penetration testing goes beyond automated scanning. No AI provision.

“Monitor and scan for vulnerabilities in the system and hosted applications every thirty (30) days”

Publication 1075, Sec. 4.16 RA-5; Sec. 4.4 CA-8 Supplemental Guidance

ACA Administering Entities must implement the Volume II controls under 45 CFR 155.260 and 155.280 and their agreements with CMS. Compliance date March 4, 2026.

“Table 2 lists the ARC-AMPE users that must comply with ARC-AMPE Volume II by implementing the operational, technical, and physical controls documented in the ARC-AMPE.”

ARC-AMPE Volume I v1.02, Sec. 3.1 and Table 2; CMS regulations and guidance page (release and compliance dates)

ACA Administering Entities: the federal and state exchanges, state Medicaid and CHIP agencies and state Basic Health Program agencies. Some private partner entities follow their own overlays.

“ACA Administering Entity (ACA AE) – Exchanges, whether federal or state, state Medicaid agencies, state CHIP agencies, or state agencies administering a BHP.”

ARC-AMPE Volume I, Sec. 1.3.2

Penetration test of the full system boundary at least once a year, and when new threats are reported or CMS asks.

“Conduct penetration testing at least every one (1) year on organization-defined systems or system components as agreed with the penetration testers in the Rules of Engagement.”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-08 control text

Tests are triggered when new threats are reported. A threat awareness program with threat intelligence sharing is required (PM-16), but no rule says intelligence must shape test scenarios. Coded recommended on the trigger language; not_addressed is a defensible alternative.

“Penetration tests are performed when new risks and threats potentially affecting the system/applications are identified and reported or upon request from CMS.”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-08 supplemental guidance; PM-16

The test must be run by an independent assessor or team approved by the organization’s CISO (CA-08, CA-08(01)). No named certification.

“The penetration testing must be conducted by an independent assessor or assessor team.”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-08 supplemental guidance; CA-08(01)

The tester must be independent and CISO-approved. The text does not say whether an independent in-house team qualifies; it points to a separate CMS independent assessment framework that was not reviewed. Coded as for FedRAMP Rev5 CA-08(01).

“The independent penetration agent or penetration team must be approved by the organization's Chief Information Security Officer (CISO) or equivalent.”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-08(01)

Phishing email tests of system users are a mandatory awareness technique (AT-02 b). They sit in the awareness control, not in the penetration test. Coded required as for CBK CORF 4.5.2.8.

“Employ the following techniques to increase the security and privacy awareness of system users: phishing email tests and other organization-defined techniques.”

ARC-AMPE Volume II, AE Mandatory Baseline, AT-02 (b)

All controls, physical ones included, must be independently assessed over each three-year cycle. No physical intrusion test.

“A complete independent assessment of all security and privacy controls must be conducted over a three (3) year period”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-02 supplemental guidance; PE-03

Providers of external system services must comply with the organization’s controls, and the organization monitors their compliance (SA-09). No rule puts supplier systems inside the test beyond the documented system boundary.

“Require that providers of external system services comply with organizational security and privacy requirements and employ the organization-defined controls”

ARC-AMPE Volume II, AE Mandatory Baseline, SA-09 (a) and (c)

No OT content.

No payment system content. “Payment” appears only for advance premium tax credit applications.

Volume II assumes most systems are hosted in an outsourced facility or a cloud environment, and CA-08 requires a penetration test of the documented system and its full boundary. Cloud-hosted components in that boundary are therefore in the test. No rule names cloud or SaaS testing as such.

“Most of the systems will be hosted in an outsourced computing facility or cloud environment.”

ARC-AMPE Volume II, Assumptions sheet, item 2; AE Mandatory Baseline, CA-08 supplemental guidance

PII must be processed and stored within the continental U.S., Hawaii, or U.S. territories (SA-09(05), SA-09(08)), while support, development and IT services may be off-shored, and an ACA AE must notify CMS 60 days before outsourcing system services outside the U.S. These are data location and outsourcing conditions. SA-09(08) points organizations that process FTI to IRS Publication 1075, whose residency limit is coded in that row. Nothing in ARC-AMPE itself limits where testers or people with system access sit, reaches foreign entities or addresses tests across borders.

No purple team or replay provision.

Penetration test reports must give remediation plans. Findings go into the POA&M (CA-05). Scan findings have fixed deadlines: critical 15 days, high 30, moderate 90, low one year (RA-05 d).

“Penetration Testing reports must be provided to CMS and must summarize the findings and articulate the significance, impact, and risk of the findings and provide remediation plans.”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-08 supplemental guidance; CA-05; RA-05 (d)

CMS receives penetration test reports with raw results, can ask for a test, and reviews the artifacts before granting the connection to the federal data hub.

“Penetration Testing reports provided to CMS must include the underlying raw security information/results in unaltered format.”

ARC-AMPE Volume II, AE Mandatory Baseline, CA-08 supplemental guidance; Volume I Sec. 4.1 and Table 4

Vulnerability scans every 30 days with tools that automate parts of vulnerability management (RA-05). No AI provision.

“Monitor and scan for vulnerabilities in the system and hosted applications every thirty (30) calendar days”

ARC-AMPE Volume II, AE Mandatory Baseline, RA-05 (a) and (b)