PCI DSS 11.4.7: Multi-tenant service providers support their customers for external penetration testing per
PCI DSS v4.0.1 control 11.4.7: 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
Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.
Summary
Multi-tenant service providers only: make it possible for your customers to penetration test, and support them when they do.
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.7 | Additional testing procedure for multi-tenant service providers only: Examine evidence to verify that multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4. |
The obligation is support, which is unusual: this control is not about testing your own environment but about not obstructing your customers testing theirs, per 11.4.3 and 11.4.4. In practice it means a documented route by which a customer can request a test, get it authorised and scoped, and receive whatever evidence the shared parts of the platform require, since a customer on shared infrastructure cannot test it unilaterally without affecting other tenants. The procedure examines evidence that this support exists, so a willingness to help is not the artefact: a published process, the authorisation form, and records of tests supported are. It sits alongside 12.8.5 on the customer side, which is where responsibilities get divided.
What to prepare
- The published process for customers requesting a penetration test.
- Records of tests supported, including scoping and authorisation.
- What you provide in place of a test for shared components, if that is the arrangement.
- How this is communicated to customers, since a process they cannot find is not support.
How to implement it
1. Publish the route rather than handling requests case by case. The procedure examines evidence, and a documented process with a form behind it is the cheapest evidence there is.
2. Say clearly what a customer may and may not test. Shared components usually cannot be tested by one tenant, and being explicit about that boundary is part of supporting the test rather than refusing it.
3. Offer your own results for the shared layer. Where a customer cannot test infrastructure directly, providing your own testing evidence is what lets them close 11.4.3 on their side.
4. Keep it consistent with the responsibility matrix in 12.8.5. Customers use that to work out what is theirs to test.
Where this commonly fails
- Requests handled ad hoc with no process and therefore no evidence.
- A blanket prohibition on customer testing with nothing offered in its place, which is the opposite of support.
- A process that exists internally and was never communicated to customers.
- Applying this when not multi-tenant, or missing that you are.
Related controls
This control refers to 11.4.3.
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.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.6 · All controls · 11.5.1 →
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.