Penetration testing for CMMC

Does penetration testing for CMMC apply to your contract?

CMMC Level 2 has no explicit penetration testing requirement, but Level 3 requirement CA.L3-3.12.1e does. If a buyer or prime contractor asks whether you need a penetration test, the honest first answer is that it depends on the CMMC level your contract requires and the terms written into it. Level 2 is based on NIST SP 800-171 Rev. 2, and its assessment expectations centre on security assessment and vulnerability management rather than a named penetration test. Level 3 adds CA.L3-3.12.1e, which calls for penetration testing at least annually or when significant security changes are made, using automated scanning tools and ad hoc tests by subject matter experts under 32 CFR 170.14. Confirm your certification level in the contract and the solicitation, because that setting decides whether this requirement applies to you. Even at Level 2, organizations commission tests for reasons that the regulation does not spell out. Assessors look for evidence that vulnerability scanning and assessment actually find and drive fixes, and a documented penetration test is often the clearest way to show that. Primes may flow requirements down to subcontractors, so a test may be requested in a subcontract even where the level does not mandate one. Testing also shows whether controls work in practice, such as segmentation between systems that handle Controlled Unclassified Information and the rest of your environment, and whether remote access or misconfigured identity services expose that data.

Ask three questions before you buy: which CMMC level and which contract clauses apply, whether your prime or customer has written a testing expectation into the subcontract, and which systems in the CUI boundary the test must cover. Keep the answers in writing, because they set the scope, the tester requirements and the evidence you will need at assessment time.

What a penetration testing for CMMC engagement can cover

Before any test starts, the assessed scope has to be pinned down, because CMMC assessments judge the boundary the organization declares. The cards below are the decisions that most shape the test, and each one should be checked against the system security plan and boundary documentation before a quote is requested.

CUI boundary and assets in scope

The first decision is whether the test covers the whole enterprise, a dedicated enclave or a named set of systems that store, process or transmit Controlled Unclassified Information. A narrow boundary lowers effort, but only if it matches what the assessment will certify. Confirm the boundary against the system security plan, the network diagram and the asset inventory, and ask the tester to list every asset in scope by name, address range or account before work begins. Any system that can reach the CUI boundary should be assessed as part of that boundary.

External and internal network tests

External tests examine what the internet sees, while internal tests start from a position inside the boundary, such as a workstation or a segment with user access. Both matter because CUI often sits behind a perimeter that is not the only path in. Confirm which address ranges, domains and internal segments the boundary diagram lists, and agree in writing whether internal testing starts from an unprivileged or a privileged foothold.

Web and API applications handling CUI

Portals, file transfer tools, ticketing systems and APIs that display, upload or export CUI are often where application logic flaws appear. Testing them requires a list of each application, its user roles and the data classes it touches. Confirm with the application owner which features handle CUI, which integrations pass data to third parties, and which test accounts the tester may use. Application testing is usually scoped separately from network testing, so agree on each one explicitly.

Identity and remote access

Single sign-on, directory services, multifactor authentication and VPN or remote desktop gateways control who can reach CUI. Weaknesses in these components often matter more than weaknesses in the data systems behind them. Confirm the identity providers, directory domains and remote access paths listed in the system security plan, and decide whether the test will attempt credential attacks, token misuse or privilege escalation within agreed limits.

Cloud tenants and their configuration

Where CUI is stored or processed in a cloud tenant, the configuration of that tenant is part of the boundary. Testing may combine configuration review with active tests of exposed services, and each cloud provider publishes its own testing rules that the engagement must follow. Confirm which subscriptions, accounts or projects hold CUI, which provider services are in use, and whether the provider's testing policy requires notice or prohibits certain tests.

Rules of engagement and contacts

The rules of engagement set testing windows, permitted techniques, named test accounts, the roles allowed to approve changes and emergency contacts who can stop the work. Without them, a test can disrupt production or trigger incident response that the assessment team then has to explain. Ask for a written document that names the people on each side, the hours when testing may run, how credentials are handled and destroyed, and how a critical finding during testing is reported before the final report.

How a CMMC penetration test runs, phase by phase

The sequence turns a boundary and a system security plan into a written, verified set of findings that the organization can fix, retest and present to its assessor.

Scope the test against the system security plan
The provider and the client agree which systems sit inside the assessment boundary, using the system security plan (SSP) and the network diagram as the starting point. The team confirms which assets hold or transmit controlled unclassified information, which external addresses and internal segments are in scope, and which controls the test is expected to inform. Level 2 is based on NIST SP 800-171 Rev. 2, so the scope should map to that baseline. The step closes with a written scope document listing in-scope and out-of-scope assets, and the client's sign-off on it.
Agree rules of engagement and written authorization
Before any traffic reaches the environment, both parties sign rules of engagement covering testing windows, source addresses, prohibited actions, data handling, emergency contacts and how to stop testing if a system degrades. The client issues written authorization naming the testing firm and the in-scope assets, which protects the testers and gives the assessor evidence of who was permitted to test. Ask whether any third-party hosting or managed services need their own permission before testing starts. The step is complete when both documents are signed and the named contacts have been confirmed.
Map the attack surface and run automated scanning
Testers gather information about the in-scope systems from documentation, configuration exports and passive observation, then run automated vulnerability scanning and configuration checks. Automated tooling is a baseline, not the whole test, and it produces noise that must be triaged. For Level 3, the requirement under CA.L3-3.12.1e pairs automated scanning with ad hoc tests by subject matter experts, as 32 CFR 170.14 describes. The output is an inventory of hosts, services and candidate weaknesses, reviewed by a tester before anything is treated as a finding.
Test manually across the categories of weakness in scope
Subject matter experts examine the candidate weaknesses by hand, focusing on categories such as authentication and access control, remote access, misconfiguration, unsupported software, weak segmentation between the boundary and other networks, and exposure of controlled information. Testers record what they tried in terms the client can reproduce for remediation, without publishing exploit code. Where a weakness cannot be confirmed safely, the tester says so and records the uncertainty. The step ends with a list of confirmed and unconfirmed observations, each tied to an in-scope asset.
Validate and rate each finding
The team confirms that each candidate weakness is real, removes duplicates and false positives, and assigns a severity rating with a short rationale that considers exploitability, the data at risk and the asset's role in the boundary. The rating method should be agreed in the scope document so the client can apply it consistently. Findings that could affect controlled information are flagged for priority attention. The step closes with a validated findings register that the client has reviewed for factual accuracy.
Deliver the report and brief remediation owners
The provider issues a report that describes the scope, method, tools, dates, tester qualifications, validated findings, severity rationale and recommended corrections. A walkthrough with engineering and the SSP owner helps the client decide which findings need a system change, a documentation update or a documented risk decision. The report should separate the test record from the client's remediation plan, so the assessor can see both. The step is complete when the client confirms receipt and the findings are assigned to named owners.
Support remediation and track corrections
The client corrects the findings, and the provider can advise on fixes, review proposed changes and clarify reproduction steps where the client's team needs them. Remediation work is owned by the client, because the testing firm should not implement or operate the controls it tests. Changes are logged with dates and owners, and any risk accepted instead of fixed is recorded with an approver. The step closes with a remediation log showing the status of each finding.
Retest to confirm corrections
The testers repeat the relevant tests against the corrected systems to confirm that each finding is closed or that the residual risk matches the documented decision. The retest report lists each original finding, its status and the evidence used to verify it. Ask the provider whether the retest is included in the quote and how many rounds are covered. The assessor and the SSP should be updated to reflect the verified state of the boundary.

Why Level 2 has no explicit penetration test, and what still applies

CMMC Level 2 does not name penetration testing as a requirement. Level 2 is built on NIST SP 800-171 Rev. 2, and that baseline asks for practices around identifying weaknesses, tracking them and correcting them, rather than for a specific type of test. The practices that still apply are the ones covering vulnerability scanning, security assessment and the plan of action that records known weaknesses and how they will be closed. An assessor will look for evidence that the organization finds weaknesses in its systems, decides what to do about them, tracks the work to completion and can show the results. Confirm the exact Level 2 practice identifiers and assessment objectives against NIST SP 800-171 Rev. 2 and the current CMMC assessment guide before you scope anything, because this page does not restate them.

The practical consequence is that a penetration test is an optional way to produce that evidence, not a checkbox. For a contractor whose in-scope environment is a single cloud tenant or a small on-premises network, a scan program with documented triage and remediation may satisfy the assessment on its own. A penetration test becomes more useful when scanners miss logic flaws, misconfigured access paths or chained weaknesses, or when the organization wants an independent view of its boundary. Some primes or assessors may still ask for one in a subcontract or pre-assessment discussion, so ask your prime and your assessment organization early whether they expect a test and, if so, what format they want.

Decide what evidence you will keep before you commission anything. Ask the provider to tie each finding to an affected asset inside the CUI boundary, a severity, an owner and a retest result, and ask for the scope statement to name the systems and accounts it covers. If a test covers only part of the environment, record why the rest was excluded. Clear, scoped records of this kind serve the assessment better than a long report that cannot be traced back to the system boundary.

What Level 3 requirement CA.L3-3.12.1e adds

CA.L3-3.12.1e sits in the Level 3 security assessment practice and applies only to organizations seeking Level 3 certification. In plain terms, it asks for penetration testing on a recurring basis and whenever significant security changes are made. The rule implementing CMMC in 32 CFR Part 170 is where the requirement is set out, and it is the authoritative text to read with your assessor. The requirement sets cadence and method at a high level only. It does not define what a penetration test must cover, how deep it goes, who must perform it, or what counts as a significant change, so those decisions fall to you and must be written down.

Annual baseline: the test must recur at least once every year, so the calendar date of your last test should be easy to show.
Change-triggered testing: a significant security change also triggers a test, which means the test is tied to your change process, not only the calendar.
Scope definition: the requirement does not fix the boundary, so document which assets are in the assessed environment and which are tested.
Method left open: the requirement does not name a specific tool or technique, so your method statement carries the weight.

Confirm with your assessor how they expect cadence and scope to be evidenced before the first test is commissioned.

What drives the cost and duration of a CMMC penetration test

This table lists the factors that move the effort and cost of a CMMC penetration test, why each one matters and how to keep it proportionate. Read it as a checklist for the written scope you will ask for, since DeployOpen does not publish a price list and a quote follows from that scope. Most of the cost sits in the initial scoping and baseline test, while retests after remediation and change-driven tests recur.

Driver	Why it moves cost or effort	How to scope efficiently
Number and complexity of in-scope systems	Each external address, host, application and enclave adds discovery, manual testing and reporting. Complex applications with many workflows take longer than simple ones.	Limit scope to systems that store, process or transmit CUI and the security protection assets that guard them, and confirm the boundary with your assessor before work starts.
User roles and identity paths	Each role, login method, single sign-on path and privilege level needs its own testing. Federated and multi-factor flows add test cases.	List roles that actually reach CUI and test the highest-privilege paths in depth, rather than every low-value role equally.
Cloud and hybrid environments	Cloud tenants, hybrid directory links and remote access paths add configuration review and must be tested within each provider's published testing rules and the shared responsibility model.	Confirm which cloud accounts are inside the boundary and which controls the provider inherits, so testing covers only your responsibilities.
Test depth and method	Automated scanning with manual validation costs less than a broader ad hoc exercise by subject matter experts. CMMC Level 3 requirement CA.L3-3.12.1e names both automated tools and ad hoc testing, so Level 3 scopes cost more.	Match depth to the certification level and to the risk you need to evidence, and ask for the method in writing.
One-time versus recurring testing	The initial scoping and baseline test carries most of the setup effort. Later tests reuse the scope, so recurring work is usually smaller, though a significant change can widen it.	Document the baseline scope and the change triggers so that each annual or change-driven test starts from a known boundary.
Retest scope after remediation	Retesting checks that corrected findings are closed. Narrow retests are cheaper, while findings that touch shared components can widen the work.	Agree in advance how many retest rounds are included and which findings each round covers.
Client-side access and coordination	Test accounts, network access, change windows and staff time for questions slow the work. Delays extend the calendar and can add cost to a fixed-scope engagement.	Prepare test accounts, network paths and a named contact before the start date, and confirm who approves production testing windows.
Documentation available at start	Current network diagrams, asset inventories, data flow maps and the system security plan shorten discovery. Missing documentation shifts time into discovery and boundary questions.	Share current documentation with the proposal request, and state any gaps so the quote accounts for them.

Frameworks and buyers that ask for testing alongside CMMC

Many organizations pursuing CMMC also answer to other frameworks, regulators and customers that ask for penetration testing. The cards below summarize what each one expects, so you can see where a single well-scoped test can answer several requests. None of them replaces CMMC or its assessment.

HHS proposed HIPAA Security Rule revision

The January 2025 proposal would require penetration testing by a qualified person at least every 12 months and vulnerability scans at least every six months. It is a proposal, not a final rule, so today the HIPAA Security Rule still relies on periodic evaluation. If your organization handles ePHI, confirm the current status of the rulemaking and scope the test to the systems that hold or transmit ePHI, so the same report can serve a future requirement.

NIST SP 800-53 CA-8 at the high baseline

Control CA-8, Penetration Testing, is selected only in the high security baseline, and CA-8(1) adds an independent tester. If your federal system is categorized at the high baseline, the test must be planned as a control activity with its own scope and frequency. Confirm the baseline your system authorization uses before you assume CA-8 applies, since moderate-baseline environments that adopt 800-53 controls may not carry it.

CIS Controls v8.1 Safeguards 18.2 and 18.5

These safeguards ask for external and internal penetration tests at least annually. Customers and insurers often recognize the CIS Controls as a baseline, so a test that covers the external perimeter and the internal network can answer both. Check that your scope document names the external IP ranges, internal segments and test dates, because a reviewer will match those details to the safeguard wording.

ISO/IEC 27001:2022 control A.8.8

Annex A control A.8.8, Management of technical vulnerabilities, asks the organization to obtain information about vulnerabilities, evaluate its exposure and act on the results. A penetration test report with prioritized findings and documented remediation supports that evaluation, but it does not replace a vulnerability management process. Confirm with your certification body how it expects the test to be recorded within the ISMS scope.

PCI DSS v4.x requirement 11.4

Requirement 11.4 applies to the cardholder data environment and requires a defined methodology, internal and external tests, segmentation validation and correction of exploitable findings with retesting. If the same network segment processes cardholder data, a single test can cover CMMC and PCI DSS scope, but the PCI DSS scope must be documented separately. Confirm with your qualified assessor which systems count as in scope for the cardholder data environment.

Prime contractor and customer security reviews

Prime contractors and customers often ask for a summary of recent penetration testing, the scope covered and evidence that findings were closed before they accept a subcontractor or renew a contract. Agree in advance whether they receive a summary letter or the full report, and confirm that the report wording does not overstate the scope of the assessment. Retest evidence for critical findings is the item reviewers ask for most often.

How penetration testing evidence supports a CMMC assessment

An assessor reviewing penetration test evidence for CMMC will first check that the test was scoped to the CUI boundary: the systems that store, process or transmit controlled unclassified information, plus the security protection assets that defend them. The report should name those assets, state the test dates, identify who authorized the work and who performed it, and explain the methods used at a level of detail the assessor can follow and repeat. Findings should carry a clear severity rating and list the affected assets, so the assessor can connect each one to the environment in scope. Remediation records should show what changed, when, and under which change ticket, and a retest result should confirm that each corrected finding no longer reproduces. Ask the assessor, before testing starts, which formats they accept (full report, executive summary, signed letter, or raw tool output) and whether they need the testing firm's qualifications documented.

Test evidence supports a practice's implementation of the relevant NIST SP 800-171 Rev. 2 requirements, but it does not establish that implementation on its own. The organization must still show its own vulnerability management and assessment processes: how it identifies vulnerabilities through routine scanning, how it prioritizes and tracks them, how it decides what is accepted as risk, and how those decisions are recorded in the System Security Plan. A single penetration test report with no surrounding process will leave gaps the assessor can question. Confirm with your assessor, or with the assessment guidance from the CMMC program, how they expect a test report to be cross-referenced to specific security requirements in your SSP, and keep a short map from each test finding to the affected control and the remediation evidence that closes it.

What you receive from a CMMC penetration test

A CMMC penetration test produces a set of records that connect the testing to your System Security Plan, your assessment evidence and your contracting relationships. Each item below serves a different reader, so agree on the format and distribution of every one before testing begins.

Full technical report

The full report contains the executive summary, the agreed scope, the methodology used, and each finding with its severity, affected asset, supporting evidence and remediation guidance. Ask for findings to be mapped to the NIST SP 800-171 requirements they touch, so your team can connect them to the System Security Plan. Confirm the report is written for internal and assessor use, since it describes exploitable weaknesses in your environment and should be handled as controlled information.

Scope and authorization letter

This document records which systems, networks, addresses and accounts were in scope, the testing windows, the source addresses the testers used, and who at your organization authorized the work. Assessors and your own auditors will look for it to confirm that the test covered the boundary described in your assessment scope. Check that the scope letter matches the CUI environment you defined, and that any excluded systems are named with the reason.

Retest report and closed findings

After remediation, the retest report shows which findings were verified as closed, which remain open, and what evidence supported each decision. Retesting is what turns a list of weaknesses into a record of corrective action. Ask the provider to state the retest date and the version of the environment tested, so the closure can be tied to the configuration your assessor reviews.

Remediation tracker export

A tracker export lists each finding with its identifier, owner, status, target date and closure evidence in a spreadsheet or structured file. Your team keeps this record for its own planning and for the assessment. Confirm the export format before testing, and confirm that it can be updated after the retest so the closure history stays in one place.

Summary letter for primes and customers

A summary letter states that a test was performed, when, by whom, against what scope and with what overall outcome, without listing exploitable detail. Primes and customers may accept it as an interim view of your security testing. Whether to share it, and with whom, is your decision to make with your contracting officer or prime, and you should confirm the letter's wording with them before it leaves your organization.

Questions buyers ask before commissioning a CMMC penetration test

Does CMMC Level 2 require a penetration test?

No. CMMC Level 2 is based on NIST SP 800-171 Rev. 2, and it has no explicit penetration testing requirement. Assessors still expect evidence that vulnerabilities are identified, evaluated and addressed, and that the system security plan matches what the environment actually looks like. Vulnerability scanning, assessment results and a remediation trail are the core evidence. A penetration test is a strong way to support that evidence, particularly for externally facing systems and remote access, but it is a choice you make on the basis of your risk and your assessor's expectations. Confirm with your assessor which scanning and assessment records they will ask to see before you decide whether a penetration test is needed for your boundary.

What does CMMC Level 3 requirement CA.L3-3.12.1e require?

CA.L3-3.12.1e requires penetration testing at least annually or whenever significant security changes are made to the environment. The regulation in 32 CFR 170.14 describes the testing as a combination of automated scanning tools and ad hoc tests carried out by subject matter experts. The automated scanning gives coverage and repeatability, while the expert-led tests look for weaknesses that tools miss, such as chained misconfigurations and logic flaws. Plan both parts in the written scope, define what counts as a significant change for your environment, and keep the schedule, scope and results together so they can be shown to the assessor. Read the regulation directly for the exact applicability to your contract.

What drives the cost of a CMMC penetration test?

The main cost drivers are scope, depth and the number of environments. Scope means how many systems, networks, cloud accounts, applications and enclaves sit inside the assessment boundary. Depth covers whether the work includes authenticated testing, wireless or remote access, or social engineering, and how many hours the testers spend on manual analysis. Environments matter because on-premises, cloud and hybrid estates each follow their own testing rules and require separate setup. Retesting is also a cost driver, so ask whether the quote includes a retest allowance. Recurring costs come from the annual test and any test after significant change. Ask for a quote that itemizes these elements, lists assumptions, and states how out-of-scope changes are priced.

How long does a CMMC penetration test take?

Duration depends on the same drivers as cost: how many systems are in scope, the testing depth, how many environments are involved, and how quickly access, documentation and test windows are provided. Time is also spent on test planning, rules of engagement, change coordination, reporting and the review meeting after the report is issued. Remediation and retesting run on a separate clock controlled by your team. DeployOpen agrees a written scope before work starts, and the schedule is part of that document. Ask for the schedule to show the phases, the dependencies on your inputs and the retest window, so you can align the test with your assessment date and any planned significant changes.

What must our team provide before a CMMC penetration test starts?

The test depends on inputs that only your organization can provide. Start with named technical and business contacts, an escalation path for critical findings, and an emergency stop process. Provide the asset inventory, network and data-flow diagrams, and the system boundary documentation that describes what is in scope. Supply test accounts for any authenticated testing, along with the access paths needed for remote and cloud environments. Agree test windows and any change freeze that production teams must observe, and confirm who approves changes during the test. For cloud environments, confirm the provider's testing rules before scheduling. Missing inputs usually delay the start and can reduce coverage, so review this list during scoping.

Can our internal team run the penetration test for CMMC?

Your internal team may be able to perform some of the work, but you need to confirm that the result will be accepted before you rely on it. Assessors look at whether testers have the skills, a documented methodology and suitable independence from the administrators who operate the systems being tested. Independence is a common expectation in other frameworks, including the independence requirement for penetration testers in PCI DSS requirement 11.4.3, so treat it as a question to confirm rather than an assumption. Internal teams also need time to write the report and to verify retests. An external provider can add an independent view and a report written for assessment use. Confirm with your assessor what they will accept before you decide.

How does retesting work, and what closes a finding?

A finding closes when the fix is verified, not when a ticket is marked complete. The usual sequence is that the tester reports the finding with severity and reproduction detail at a defensive level, your team remediates it, and the tester retests the same weakness to confirm the correction. The retest result, date and tester identity go into the record. Findings you decide not to fix need a documented risk acceptance with an owner and a review date. PCI DSS requirement 11.4.4 uses the same logic: exploitable findings are corrected and testing is repeated to verify the corrections. Ask the provider how retests are scoped, whether they are included in the quote, and how long retest evidence is kept.

Can one penetration test serve a prime contractor, an insurer and an assessor?

One test can often support several audiences, but the scope and the report format must be designed for each use. The assessor needs the results mapped to the assessment boundary and to the evidence they will review. A prime contractor or customer usually asks for a summary letter that states scope, dates, method and whether critical findings were closed. An insurer questionnaire asks about external testing, vulnerability management and remediation, which can usually be answered from the same records. Decide early who will receive the full report, who receives a summary, and what confidentiality terms apply. Avoid sending a full report to parties who only need a summary. Confirm the distribution plan during scoping so the test is sized correctly for all parties.

How DeployOpen scopes, tests, reports and retests

DeployOpen approaches Penetration testing for CMMC as a fixed-scope engagement, with the systems, boundaries and evidence needs agreed in writing before any testing starts. The work is documented so that results can be read alongside your System Security Plan and assessment preparation.

How we scope

Written scope names the systems inside the CUI boundary, the test types and the environments covered.
Scope records which assets are excluded, such as systems outside the assessed environment, and why.
Ask whether the scope also covers any Level 3 requirement you intend to meet, so the statement of work matches it.

How we test

Testing combines automated scanning with manual tests performed by experienced testers against the agreed scope.
Test methods are documented so the approach can be reviewed by your assessor and internal security team.
Testing rules and any provider or hosting restrictions are confirmed with you before testing begins.

How we report

Deliverables include a report with findings, affected assets, severity and recommended corrective actions.
Findings are mapped to the relevant NIST SP 800-171 requirements so they can be cross-referenced in your SSP.
Reports are shared with your team, and you decide which versions are provided to assessors or customers.

How we support retesting

Retesting verifies that corrected findings are closed, and the retest result is documented alongside the original report.
Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Confirm with DeployOpen how retest scope, timing and any retainer terms are written into the statement of work.