PCI DSS 11.4.2: Internal penetration testing is performed
PCI DSS v4.0.1 control 11.4.2: 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
Internal 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
Penetration test from inside the network as well as outside, yearly and after significant changes.
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.2.a | Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed in accordance with all elements specified in this requirement. |
| 11.4.2.b | Interview personnel to verify that the internal 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). |
The counterpart to 11.4.3, and the one entities are most likely to have skipped. External testing is familiar and often contractual; internal testing means someone starting from a position inside the network, which is the position an attacker reaches after the first successful phish. Five elements, and they include organisational independence of the tester, explicitly not requiring a QSA or an ASV, so a competent internal team from outside the group that runs the systems can do this. The methodology it is performed against is the one 11.4.1 requires you to write, so an entity without that document cannot really satisfy this one.
What to prepare
- The defined methodology from 11.4.1, which this test is performed against.
- Scope of work and results from the most recent internal test.
- The trigger record for any significant infrastructure or application change since.
- The tester's qualifications and reporting line.
How to implement it
1. Start the test from inside. A test that begins at the perimeter and works in is an external test, however far it gets.
2. Define the internal starting position deliberately. An unprivileged user on the corporate network is the usual and most useful assumption, and stating it makes the results comparable year to year.
3. Use the same significant-change definition as the scanning controls. One trigger serving 11.3.1.3, 11.3.2.1 and this is far easier to operate and to evidence.
4. Keep independence demonstrable. Interviewed in 11.4.2.b, so it needs to be a structural fact rather than an assurance.
Where this commonly fails
- External testing only, with the internal element never commissioned.
- An internal test performed by the team that built and runs the environment.
- Annual testing with nothing after a major change, which is a separate element of the same control.
- No documented methodology, leaving "per the entity's defined methodology" unmeetable.
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.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.4.1 · All controls · 11.4.3 →
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.