PCI DSS 11.4.3: External penetration testing is performed
PCI DSS v4.0.1 control 11.4.3: the requirement in full, the 2 testing procedures 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
External penetration testing is performed:
- Per the entity’s defined methodology
- At least once every 12 months
- After any significant infrastructure or application upgrade or change
- By a qualified internal resource or qualified external third party
- Organizational independence of the tester exists (not required to be a QSA or ASV)
Summary
Have external penetration testing done at least once a year and after significant changes, by someone competent and organisationally independent.
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.3.a | Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement. |
| 11.4.3.b | Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV). |
Four conditions, and three of them are where entities fall short. Per your defined methodology points at 11.4.1, which has to exist first and to specify scope, techniques and retention. Organisational independence does not require a QSA or ASV: the standard says so explicitly, but it does mean the tester cannot be the person who built or maintains the thing. And after any significant infrastructure or application upgrade or change is an event trigger sitting beside the annual one. Distinguish this from 11.3.2, the quarterly ASV scan: scanning is automated and external by an approved vendor, penetration testing is manual, deeper, and may be internal staff.
What to prepare
- The penetration testing methodology from 11.4.1, which this control is measured against.
- The report itself, covering the full external attack surface in scope.
- Evidence of the tester’s qualification and independence from the systems tested.
- Retest evidence for anything found, and the record of significant changes that triggered an out-of-cycle test.
How to implement it
1. Write the methodology before booking the test. 11.4.3.a checks the test followed it. Commissioning a test with no methodology to follow means the report cannot be assessed against anything.
2. Agree the scope against your own scope document. The commonest finding is a test that covered the main application and not an API host or a legacy subdomain that 12.5.2 had already identified as in scope.
3. Use independence you can describe. An internal tester is acceptable if they did not build or run the target and do not report to whoever did. Write that down; it is easier than arguing it later.
4. Plan for the retest. Findings have to be corrected and verified under 11.4.4, so a test late in the year leaves no room to close them.
Where this commonly fails
- A vulnerability scan presented as a penetration test. Scanning is 11.3.2; this control expects manual testing against a methodology.
- Annual testing with no out-of-cycle test after a major change, when both triggers are named.
- The tester being the team that built the application.
- Findings reported and never retested, which fails 11.4.4 even where this control passes.
Related controls
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.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.4.2 · All controls · 11.4.4 →
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.