PCI DSS 11.4.4: Exploitable vulnerabilities and security weaknesses found during penetration testing
PCI DSS v4.0.1 control 11.4.4: 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
Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:
- In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.
- Penetration testing is repeated to verify the corrections.
Summary
Fix what a penetration test finds, on a timescale set by your own risk ranking, and test again to prove it is fixed.
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.4 | Examine penetration testing results to verify that noted exploitable vulnerabilities and security weaknesses were corrected in accordance with all elements specified in this requirement. |
The half of penetration testing that is not the test. The correction timescale comes from your assessment of risk under 6.3.1, which is the third control to lean on that ranking, and the retest is not optional: the requirement says testing is repeated to verify the corrections. A report with findings, remediation tickets and no retest is the common shape here, and it fails the second bullet outright.
What to prepare
- The findings list from 11.4.3, with the risk assigned to each.
- Remediation evidence per finding.
- The retest report confirming corrections.
- The risk-based timescales, so "corrected in accordance with the assessment" is measurable.
How to implement it
1. Book the retest with the test. Retesting is the part that slips, and a test late in the cycle leaves no room for it. This is the practical reason to test early in the year.
2. Rank findings with 6.3.1, not with the tester’s labels. The requirement points at your own assessment. Where you disagree with the tester’s severity, record why.
3. Accept risk explicitly where you must. A documented, approved risk acceptance is defensible; a finding quietly left open is not.
4. Keep the chain intact. Finding, decision, fix, retest. Any missing link is where this control is failed, and it is usually the last one.
Where this commonly fails
- Findings remediated and never retested, which is the named second bullet.
- Tester severity used instead of the entity’s own risk assessment.
- A retest covering only some findings, with no statement about the rest.
- Remediation tracked in a ticket system with no link back to the report an assessor reads.
Related controls
This control refers to 6.3.1.
Others in section 11.4:
| Control | What it requires |
|---|---|
| 11.4.1 | A penetration testing methodology is defined, documented, and implemented by the entity… |
| 11.4.2 | Internal penetration testing is performed… |
| 11.4.3 | External penetration testing is performed… |
| 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.4.3 · All controls · 11.4.5 →
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.