PCI DSS 11.4.1: A penetration testing methodology is defined, documented, and implemented by the entity
PCI DSS v4.0.1 control 11.4.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 11.4.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.4
A penetration testing methodology is defined, documented, and implemented by the entity, and includes:
- Industry-accepted penetration testing approaches.
- Coverage for the entire CDE perimeter and critical systems.
- Testing from both inside and outside the network.
- Testing to validate any segmentation and scope-reduction controls.
- Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
- Network-layer penetration tests that encompass all components that support network functions as well as operating systems.
- Review and consideration of threats and vulnerabilities experienced in the last 12 months.
- Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.
- Retention of penetration testing results and remediation activities results for at least 12 months.
Summary
Write down how you test: the approach, the coverage, inside and outside, segmentation validation, and how long you keep the results.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.4.1 | Examine documentation and interview personnel to verify that the penetration-testing methodology defined, documented, and implemented by the entity includes all elements specified in this requirement. |
The methodology 11.4.3 is measured against, so it has to exist before a test is commissioned rather than be reverse-engineered from a report. Its elements are specific: an industry-accepted approach, coverage of the entire CDE perimeter and critical systems, testing from both inside and outside, validation of segmentation and scope-reduction controls, application and network-layer testing, and defined retention for results. Segmentation validation is the element most often absent, and it is the one that keeps a reduced scope defensible.
What to prepare
- The documented methodology covering every element.
- The scope definition it refers to, from 12.5.2.
- Retention arrangements for results and remediation records.
How to implement it
1. Name the approach. Referencing a recognised methodology satisfies "industry-accepted" and saves arguing the point; describing your own is acceptable but has to be complete.
2. Cover segmentation explicitly. If segmentation reduces your scope, testing that it holds is what makes the reduction defensible, and it is a distinct exercise from testing the CDE.
3. Say what "critical systems" means for you. Undefined, it is decided by whoever scopes the next test, and it will not match what an assessor expects.
4. Set retention deliberately. Reports and remediation evidence are what 11.4.4 is assessed on, and a year is usually the minimum that is useful.
Where this commonly fails
- A methodology written after the first test, describing what happened to be done.
- Segmentation validation missing while scope reduction is claimed.
- Internal testing omitted, when both directions are named.
- No retention period, so last cycle’s evidence is gone when it is needed.
Related controls
This control refers to 6.2.4.
Others in section 11.4:
| Control | What it requires |
|---|---|
| 11.4.2 | Internal penetration testing is performed… |
| 11.4.3 | External penetration testing is performed… |
| 11.4.4 | Exploitable vulnerabilities and security weaknesses found during penetration testing… |
| 11.4.5 | If segmentation is used to isolate the CDE from other networks… |
| 11.4.6 | Service providers: If segmentation is used to isolate the CDE from other networks… |
| 11.4.7 | Multi-tenant service providers support their customers for external penetration testing per… |
← 11.3.2.1 · All controls · 11.4.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.