Requirement 11.4.7: what your customers may demand of you, and since when

Since 31 March 2025, a multi-tenant service provider assessed against PCI DSS has had to answer the customer who asks to penetration test the infrastructure it subscribes to. Two answers are acceptable. Refusal is not one of them.

Requirement 11.4.7 of PCI DSS v4.0.1 is a single sentence: “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.”

It was a best practice when v4.0 published, which is why most providers read it once and filed it. Its applicability note carries the deadline in the standard's own words: “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.” That date is behind us. It is now assessed on every assessment of a multi-tenant service provider.

Who this binds

The standard defines the term rather than leaving it to argument. From the v4.0.1 glossary, a multi-tenant service provider is “a type of Third-Party Service Provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases.”

The examples the Council lists are not edge cases: hosting multiple entities on a single shared server, e-commerce and shopping-cart services, web-based hosting, payment applications, cloud applications and services, and connections to payment gateways and processors. The Indian providers inside that definition are mostly not payment companies — SaaS platforms sitting behind a merchant's checkout, shared hosting, managed cloud and contact-centre services carry it too, and they carried it before any customer asked.

One exclusion is written down. Appendix A1's overview says providers offering only shared data centre services — colocation, where equipment, space and bandwidth are available on a rental basis — “are not considered multi-tenant service providers for purposes of this Appendix.” Read that as written: the carve-out is scoped to Appendix A1. What governs the term everywhere else is the glossary test above, and a colocation tenant renting rack space and power is not sharing system resources with the cage next door. Where a colocation contract has quietly grown a managed hypervisor or a shared load balancer, that test stops being satisfied.

Support means one of two things

The applicability note against 11.4.7 sets out the choice, and the list is closed. A multi-tenant service provider may either:

• Provide evidence to its customers showing that penetration testing has been performed according to Requirements 11.4.3 and 11.4.4 “on the customers' subscribed infrastructure”; or
• Provide prompt access to each of its customers, so customers can perform their own penetration testing.

The evidence route has a quality bar attached to it: “Evidence provided to customers can include redacted penetration testing results but needs to include sufficient information to prove that all elements of Requirements 11.4.3 and 11.4.4 have been met on the customer's behalf.” Redaction is permitted. Redacting until nothing is provable is not.

All elements is the load-bearing phrase. Requirement 11.4.3 lists them: 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, and with organisational independence of the tester — “(not required to be a QSA or ASV)”, in the standard's own parenthesis. Requirement 11.4.4 adds that exploitable vulnerabilities and security weaknesses were corrected in accordance with the entity's risk assessment under Requirement 6.3.1, and that “penetration testing is repeated to verify the corrections.” A first-run report with open criticals and no retest does not meet 11.4.4, so it cannot discharge 11.4.7 either.

Why refusal is foreclosed

The guidance printed alongside 11.4.7 explains why, and does not hedge:

“Multi-tenant service providers cannot forbid penetration testing because this would leave their customers' systems open to exploitation. Therefore, multi-tenant service providers must support customer requests to conduct penetration testing or for penetration testing results.”

Cite that precisely: it sits in the Guidance column of v4.0.1, which explains intent rather than adding obligation. The obligation is already in the requirement itself; the guidance names the two shapes support may take and rules out the third. The practical consequence is identical either way — a blanket prohibition on customer testing in a hosting or SaaS agreement is not a position that survives contact with a customer's assessor.

What moved on the same date, and what was already there

A1.1.4 is the one providers miss, and it is the more demanding of the pair that landed on 31 March 2025. Six-monthly penetration testing of the logical separation between customer environments, and its applicability note is explicit that this testing “is in addition to the penetration tests specified in Requirement 11.4.6.” A multi-tenant provider running one annual external test is short against three separate clocks, not one. Both 11.4.7 and A1.1.4 also appear in SAQ D for Service Providers, so this is not only a Report on Compliance problem — a provider self-assessing meets them on the same page.

Your AOC does not answer this

Requirement 12.9.2 obliges every third-party service provider to support customer requests for information needed under 12.8.4 and 12.8.5, and its guidance says that where a TPSP holds an Attestation of Compliance, “the expectation is that the TPSP should provide that to customers upon request to demonstrate their PCI DSS compliance status.”

Sending the AOC is the reflex, and it is the correct answer to 12.9.2. It is not an answer to 11.4.7. An AOC attests a compliance status as at a date; 11.4.7 asks for something narrower — proof that testing meeting every element of 11.4.3 and 11.4.4 was performed on that customer's subscribed infrastructure, or access so the customer can perform it. The two requests usually arrive in the same email and need different documents. If the vocabulary itself is the confusion, what a PCI DSS attestation actually is and who signs it is worth settling first.

Nor does meeting 11.4.7 discharge anything for your customer. Appendix A1 is blunt about the direction of travel: “Even though a multi-tenant service provider may meet these requirements, each customer is still responsible to comply with the PCI DSS requirements that are applicable to its environment and validate compliance as applicable.” Your evidence supports their assessment; it does not replace it, and their AOC covers none of you.

Answering the request before it arrives

The providers who handle this badly are the ones who meet 11.4.7 for the first time inside a customer's assessment window, with no test to point at and no time to run one. Two decisions made in advance settle it permanently.

If you take the evidence route, the pack has to state scope in the customer's terms — which infrastructure they subscribe to, and that it was inside the tested scope — alongside the methodology required by 11.4.1, tester independence, the test date, remediation ranked against 6.3.1, and the retest that closed it. Redacted findings are fine; a scope statement the customer cannot map onto their own environment is not. It is the same evidence discipline the rest of a PCI programme runs on, and what gets a PCI penetration test report rejected applies harder here, because the reader is an assessor who does not work for you.

If you take the access route, the standard's word is “prompt” and it does not define it. Publish a customer testing policy: notice period, rules of engagement, what a customer may test and what belongs to the shared platform, and how findings against shared components come back to you. A provider holding that document answers the request in a day. A provider without one negotiates it from scratch, per customer, against somebody else's deadline.

Either route ends in the same work — a penetration test against a defined external scope, delivered as evidence that somebody else's assessor will read. Security Brigade runs external penetration testing scoped to Requirement 11.4.3, including the 11.4.4 retest and the segmentation testing that 11.4.6 and A1.1.4 ask of a multi-tenant service provider.