Network Penetration Testing for PCI DSS and CMMC Compliance: Scope, Requirements, and Best Practices

Compliance · PCI DSS · CMMC · April 2026

Network penetration testing for compliance is not the same as a general security assessment. PCI DSS 4.0 and CMMC each impose specific requirements for scope, methodology, frequency, and reporting. This guide ensures your engagements satisfy your assessor the first time.

💫 Key Takeaways

• PCI DSS 4.0 Requirement 11.4 mandates both external and internal network penetration testing at least annually and after significant changes
• PCI DSS 4.0 introduced a new requirement: penetration testing must validate segmentation controls every 6 months for service providers
• CMMC Level 2 requires penetration testing per NIST SP 800-171 CA.L2-3.12.1; Level 3 adds red team exercises
• The #1 reason organizations fail PCI pentest requirements is scope gaps — missing systems in the CDE or failing to test segmentation
• Your pentest provider does not need to be a QSA, but the report must meet specific criteria that generic pentest reports often lack
• Planning your compliance pentest timeline requires 4–8 weeks lead time — last-minute engagements frequently result in scope or quality compromises

PCI DSS 4.0, which became mandatory on March 31, 2025 (with some requirements having an extended deadline of March 31, 2025 for "best practice" items that are now enforced), significantly updated the penetration testing requirements from version 3.2.1. Here is what changed and what your assessor will verify:

Requirement 11.4.1 — Penetration testing methodology. You must define, document, and implement a penetration testing methodology that includes industry-accepted approaches (such as NIST SP 800-115, OWASP, or PTES), covers the entire CDE perimeter and critical systems, includes testing from both inside and outside the network, validates segmentation and scope-reduction controls, defines application-layer testing (including the OWASP Top 10 at minimum), and covers network-layer testing including all in-scope network components.

Requirement 11.4.2 — Internal penetration testing. Internal network penetration testing must be performed at least annually and after any significant infrastructure or application changes. The test must be performed by a qualified internal resource or qualified external third party. "Significant changes" includes new system components, network topology changes, firewall rule modifications, and product upgrades that affect the CDE.

Requirement 11.4.3 — External penetration testing. External penetration testing must be performed at least annually and after any significant infrastructure or application changes. The scope must include all externally accessible IP addresses and domains associated with the CDE.

Requirement 11.4.4 — Remediation and retesting. Exploitable vulnerabilities identified during penetration testing must be corrected, and the test must be repeated to verify the corrections. This is not optional — your assessor will look for evidence that findings were remediated and retested.

Requirement 11.4.5 — Segmentation testing (service providers). Service providers must validate segmentation controls through penetration testing at least every six months and after any changes to segmentation controls or methods. This is one of the most frequently missed requirements. If you are a service provider and your segmentation test is only annual, you will fail this control.

The Cybersecurity Maturity Model Certification (CMMC) 2.0 framework aligns with NIST SP 800-171 for Level 2 and adds NIST SP 800-172 enhanced requirements for Level 3. Penetration testing requirements differ by level:

CMMC Level 2 and penetration testing. While CMMC Level 2 (aligned with NIST SP 800-171) does not use the words "penetration testing" explicitly in every control, the Security Assessment (CA) family requires organizations to "develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems" and to conduct security assessments that include testing of security controls. In practice, C3PAOs expect to see penetration testing as evidence for CA.L2-3.12.1 (Security Assessment) and several other controls. Organizations preparing for Level 2 certification should include penetration testing in their assessment preparation.

CMMC Level 3 requirements. Level 3 explicitly requires adversary simulation and red team exercises derived from NIST SP 800-172. These are more extensive than standard penetration testing and include testing the organization's ability to detect and respond to advanced persistent threats (APTs). The testing must simulate threat actors relevant to the defense industrial base, which means understanding nation-state TTPs (tactics, techniques, and procedures) as documented in threat intelligence reports.

Scope is the number-one reason compliance-driven penetration tests fail to satisfy assessors. If your scope is too narrow, the assessor will find gaps. If it is too broad, you waste budget on systems that are not in scope for the compliance framework. Getting scope right requires understanding what each framework considers in-scope.

PCI DSS scope definition. For PCI DSS, the penetration test scope must include: the cardholder data environment (CDE) — all systems that process, store, or transmit cardholder data; all systems connected to the CDE (even if they do not directly handle card data); all systems that could affect the security of the CDE; all segmentation controls that reduce PCI scope; and all externally facing IP addresses and domains associated with the above. A common mistake is testing the payment application but not the network infrastructure it sits on, the databases it connects to, or the management networks that administrators use to access it.

CMMC scope definition. For CMMC, the scope includes all systems that process, store, or transmit CUI, plus any systems that provide security protection for CUI systems. This includes the network infrastructure, authentication systems (Active Directory), monitoring infrastructure (SIEM), and any cloud services used for CUI processing. The CUI boundary must be documented in your System Security Plan (SSP), and the penetration test scope should align with the SSP's defined boundary.

Segmentation scope. Both frameworks require that segmentation controls be validated. For PCI DSS, this means testing that the CDE is properly isolated from out-of-scope networks. If the segmentation fails, the out-of-scope networks become in-scope, potentially expanding your compliance boundary significantly. Segmentation testing involves attempting to cross network boundaries from out-of-scope networks into the CDE, and from the CDE into out-of-scope networks. The test must verify that controls work in both directions.

A national retail chain with 150 locations — we will call them RetailMax — had been PCI DSS compliant for three years. Their penetration testing provider conducted annual external and internal tests of the payment processing servers and the e-commerce web application. The reports were clean, and their QSA signed off each year.

When PCI DSS 4.0 took effect, RetailMax's QSA raised concerns during the assessment. The new requirements demanded more rigorous validation of scope and segmentation. The QSA asked for evidence that the penetration test included the in-store point-of-sale (POS) network, the store management network that connected to the POS system, the VPN connections between stores and the central data center, and the segmentation between the POS VLAN and the guest Wi-Fi VLAN in each store.

RetailMax's previous penetration tests had only covered the central data center and the e-commerce application. None of the 150 store networks had ever been tested. The POS network segmentation from the guest Wi-Fi had never been validated. When we were brought in to conduct a properly scoped test, we discovered that 23 of the 150 stores had firewall rules that allowed traffic from the guest Wi-Fi VLAN to the POS VLAN on port 443 — a legacy rule from an initial deployment that was never cleaned up. An attacker on the guest Wi-Fi could have potentially accessed the POS management interface.

RetailMax failed their PCI assessment that year. They had to remediate the segmentation issues across 23 stores, conduct a full retest, and push their compliance certification back by four months. The cost of the emergency remediation, retesting, and delayed certification exceeded $180,000 — not counting the internal engineering time diverted from other projects.

Your penetration test report is the primary evidence your QSA (for PCI) or C3PAO (for CMMC) will review. A technically excellent report that lacks the documentation your assessor needs will still result in a finding. Here is what compliance assessors look for that generic pentest reports often omit:

Scope statement. The report must clearly document what was tested, including IP ranges, network segments, applications, and which compliance requirement the test addresses. The QSA needs to map the pentest scope to the documented CDE and confirm there are no gaps.

Methodology documentation. PCI DSS 4.0 explicitly requires a documented penetration testing methodology. The report should state which methodology was followed (e.g., PTES, NIST SP 800-115) and describe the testing phases: reconnaissance, enumeration, exploitation, post-exploitation, and reporting.

Segmentation validation results. If segmentation is used to reduce PCI scope, the report must include specific tests performed to validate segmentation and their results. This means documenting the source and destination of each segmentation test, the protocols tested, and the pass/fail result for each. A single sentence saying "segmentation was validated" is insufficient.

Remediation evidence. PCI DSS 11.4.4 requires that exploitable vulnerabilities be corrected and retested. The report (or an addendum) must document the original finding, the remediation performed, and the retest result confirming the fix. Your assessor will look for a closed loop on every exploitable finding.

Tester qualifications. Both frameworks expect the penetration test to be conducted by qualified individuals. The report should identify the testing organization and the qualifications of the testers (certifications, experience). PCI DSS requires the tester to be "organizationally independent" — meaning they cannot test systems they built or maintain.

Planning your compliance penetration test timeline requires working backward from your assessment date. Here is the typical timeline for a properly executed engagement:

Total timeline: 8–14 weeks from scoping to assessment-ready report. This means if your PCI assessment is scheduled for September, you should begin the penetration testing engagement no later than June. We regularly see organizations contact us 3–4 weeks before their assessment date expecting a complete penetration test with remediation and retesting. This is not achievable without compromising quality or scope, which defeats the purpose of the engagement.

For organizations with semi-annual segmentation testing requirements (PCI DSS service providers), you need to plan two testing cycles per year. We recommend aligning one cycle with your annual PCI assessment and scheduling the second cycle six months before or after. This ensures continuous coverage and prevents the common mistake of running both tests in the same quarter and leaving a gap for the rest of the year.

Need a Compliance-Aligned Network Penetration Test?

We deliver network penetration testing reports specifically designed to satisfy PCI DSS 4.0 and CMMC assessors. Our reports include scope validation, segmentation testing, methodology documentation, and remediation evidence — everything your QSA or C3PAO needs to close the control.