CA.L3-3.12.1e
Penetration Testing
Requirement
Assessment objectives
An assessor checks each lettered objective separately. The letters in brackets elsewhere on this page, such as [a] or [b,c], refer to these.
Determine if:
- aAutomated scanning tools are identified;
- bAd hoc tests using subject matter experts are identified; and
- cPenetration testing is conducted at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts.
From the CMMC Level 3 Assessment Guide v2.13 · publisher approved 2026-11-08.
How to implement
Have your CUI environment penetration tested at least once a year and after significant security changes, using both automated scanning tools and hands-on tests by skilled people. Level 2 vulnerability scanning is not enough on its own; Level 3 expects people trying to break in the way an attacker would, then remediating what they find. For almost every contractor this means hiring a qualified outside firm, which is a recurring cost; there is no free option that satisfies it on its own.
- 1PolicySet the penetration testing policy: at least annually and after significant security changes (new network segment, major cloud migration, new internet-facing service, replacement of a core security tool), with defined scope, rules of engagement, tester qualifications and independence, and how findings are remediated.[c]
- 2ProcessScope each test to the CUI environment and its supporting systems: external perimeter and internet-facing services, internal network from an assumed-breach position, identity and cloud tenant (Microsoft 365 GCC High or equivalent), wireless, custom web applications, and social engineering if the threat profile warrants it. Base scenarios on the threat-informed risk assessment.[c]
- 3ProcessEngage qualified testers (an outside firm, or an internal team independent of the system administrators) who combine automated scanning tools with manual, ad hoc testing by subject matter experts. Sign rules of engagement and an authorization letter, and handle the report as sensitive.[a][b][c]
- 4ProcessRemediate findings by risk, track them in the plan of action (CA.L2-3.12.2), and retest critical and high findings to confirm closure.[c]
- 5ProcessMaintain the change triggers: when a significant security change is approved through change management, decide and record whether an additional test is required.[c]
Evidence to collect
Artifacts that show the practice is implemented and operating. Tags show which assessment objectives each one supports.
Penetration testing policy[c]
policy · reviewed annually
Policy stating frequency, change triggers, scope, tester requirements and remediation process.
Rules of engagement and authorization[c]
record · for each test in the assessment period
Signed rules of engagement, scope and authorization letter for each test.
Penetration test report[a][b][c]
record · within the last 12 months, and after each significant change
Tester's report describing methodology (automated and manual), scope, findings, evidence and risk ratings.
Remediation and retest evidence[c]
record · current
Plan of action entries for findings and retest letters or reports confirming closure.
Change-triggered test decisions[c]
record · most recent 12 months
Change records noting whether a significant change required a penetration test and the outcome.
How assessors check
- Examine
- Penetration testing policy, test plans and rules of engagement, test reports, change records, remediation and retest records, tester qualifications.
- Interview
- The person who manages the testing engagement, the testers if available, and system administrators who remediated findings.
- Test
- Confirm a test occurred within 12 months and after the most recent significant change; check the report shows both automated tools and manual testing; trace high findings to remediation and retest.
Tools and products
Named options a contractor can adopt, with an honest cost tier. The industry standard is listed even when it is expensive, alongside what is free and acceptable for a very small shop.
The normal way to meet this practice. Price depends on scope; get quotes and look for testers with recognised qualifications (for example OSCP, GPEN, or CREST-accredited firms).
Autonomous internal pentest platforms that can run more often than annual manual tests; they cover the automated part, but the practice still calls for ad hoc testing by experts.
Industry-standard tool for manual web application testing, relevant if you have custom web apps and in-house testing skills.
Free tools used by professional testers; useful for an independent internal team, but free tools do not replace qualified people.
Free penetration testing service for eligible critical infrastructure organizations, but capacity is limited and waits can be long; do not rely on it alone to meet an annual deadline.
Editorial mentions, not endorsements. Pricing and tiers change; confirm with the vendor and check FedRAMP or GCC High availability where CUI is involved.
Common pitfalls
- Presenting an automated vulnerability scan as a penetration test.
- Testing only the external IP addresses and not the internal network or cloud tenant.
- Findings from last year's test still open with no plan of action entry.
- No retest after a major change such as moving to GCC High or replacing the firewall.
- Testers given no authorization letter, creating legal and operational risk.
Platform notes
Microsoft 365 (GCC / GCC High)
Microsoft's cloud penetration testing rules of engagement allow customers to test their own tenant without prior approval, within those rules; include identity attacks (password spraying limits, Conditional Access bypass attempts, OAuth consent abuse) in scope.
Google Workspace
Google permits customers to test their own configuration within its acceptable use policy; focus on account takeover, sharing settings and third-party app access.
On-premises or MSP-managed
Tell the MSP and MSSP before the test so alerts are handled correctly, and include MSP remote access paths in scope; the MSP should not be the tester for systems it administers.
Related practices: CA.L2-3.12.1, RA.L2-3.11.2, RA.L3-3.11.5e, CA.L2-3.12.2, CM.L2-3.4.4
Editorial implementation guidance published November 8, 2026. It is not part of the official requirement and does not replace the assessment guide.
Crosswalk
Full crosswalkThe NIST requirements this practice is built on, what NIST made of each in the newer edition, and the SP 800-53 controls behind them, each from an official NIST or DoD table. Open any one to read it and see every CMMC practice it supports.
NIST SP 800-172 (Feb 2021)
3.12.1eSP 800-172 Rev 3
03.12.01E—
SP 800-53 Rev 5
CA-8CSSR-6(1)CHow these were reachedHide how these were reached
- CA-8 · Penetration Testing
- S source control of the SP 800-171 Rev 3 or SP 800-172 Rev 3 requirement (NIST OSCAL) · via 800-172 Rev 3 03.12.01E → 800-53 Rev 5 CA-8
- C SP 800-172 (Feb 2021) Appendix C
- SR-6(1) · Supplier Assessments and Reviews | Testing and Analysis
- C SP 800-172 (Feb 2021) Appendix C
Rev 5 paths: D SP 800-171 Rev 2 Appendix D → SP 800-53 Rev 4 control → NIST's Rev 4 → Rev 5 comparison; S source control of the SP 800-171 Rev 3 or SP 800-172 Rev 3 requirement (NIST OSCAL); C SP 800-172 (Feb 2021) Appendix C. NIST also names this Rev 3 requirement as the successor of other withdrawn requirements: open “How these were reached” under the Rev 5 controls for which, in NIST's words.
Where each link comes from (5 links from 4 official documents)
32 CFR 170.14 Office of the Federal Register / GPO
- CA.L3-3.12.1e → 3.12.1e“Level 3 security requirement”32 CFR 170.14(c)(4), Table 1, item (xx)
Trace notes
Notes marked NIST state what the owners' own files say. Notes marked Expert CMMC note are our reading of the links, not official guidance. Neither is a crosswalk link.
About this practice
Expert CMMC note
SR-6(1) is in 800-172 Appendix C because it carries forward Rev 4 SA-12(11) (penetration testing/analysis of supply chain elements). It covers supply-chain testing, not penetration testing of the system; 800-172 Rev 3 dropped it.
Relies on: NIST SP 800-172 (Feb 2021); NIST SP 800-172 Rev 3; NIST SP 800-53 Rev 5 (OSCAL, release 5.2.0)
Further discussion
Practice guide notes
Implementation guidance
Editorial examples to help you plan. Adapt them to your environment; the official requirement and objectives remain authoritative.
In plain language
Have penetration tests done at least yearly and after significant security changes, using automated scanning plus manual testing by experts.
Implementation example
Example from the source assessment guide (not a mandatory implementation): You are responsible for information security in your organization. Leveraging a contract managed by the CIO, you hire an external expert penetration team annually to test the security of the organization’s enclave that stores and processes CUI [a,c]. You hire the same firm annually or on an ad hoc basis when significant changes are made to the architecture or components that affect security [b,c].
Evidence examples
Examples suggested by the source guide (not an exhaustive or mandatory checklist): Security assessment policy; procedures addressing penetration testing; security plan; security assessment plan; penetration test report; security assessment report; security assessment evidence; other relevant documents or records
Common mistakes
Treating an automated vulnerability scan as a penetration test.
Track this in a workspace
The compliance workspace tracks each objective, its evidence and the tasks to close gaps. It is open to invited contractors while in pilot: request access below.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Source: DoD CIO · https://dodcio.defense.gov/CMMC/