Multi-Tenant Service Provider Penetration Testing

PCI DSS 4.0.1 requires multi-tenant service providers to support their customers’ external penetration testing so customers can test their in-scope environments without breaking your platform or other tenants. Operationalize this by creating a governed customer pen-test program with scoped test paths, written authorization, safe-testing controls, and evidence that each request was reviewed, approved, monitored, and closed out. (PCI DSS v4.0.1 Requirement 11.4.7)

Key takeaways:

• You must enable customer external penetration testing in a controlled way, not block it by default. (PCI DSS v4.0.1 Requirement 11.4.7)
• The “support” obligation is operational: rules of engagement, approvals, safe test windows, and isolation safeguards. (PCI DSS v4.0.1 Requirement 11.4.7)
• Auditors will look for repeatable process evidence, not informal email approvals.

Multi-tenant platforms have a built-in conflict during penetration testing: each customer has a legitimate need to test their own attack surface, but one customer’s testing can degrade service, create noisy alerts, or accidentally cross tenant boundaries. PCI DSS 4.0.1 addresses that tension directly for multi-tenant service providers by adding an explicit requirement: you must support customers performing external penetration testing under the broader pen-test expectations in Requirements 11.4.3 and 11.4.4. (PCI DSS v4.0.1 Requirement 11.4.7)

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this requirement is to treat it like a customer-facing security program with clear intake, authorization, technical guardrails, and closure criteria. You are building a “yes, but safely” motion: customers can test what they’re entitled to test, you can protect other tenants, and both sides can produce evidence for their assessors.

This page gives requirement-level implementation guidance you can hand to Security, Product, and Support teams to implement quickly, then defend during a PCI assessment.

Regulatory text

Requirement (excerpt): “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.” (PCI DSS v4.0.1 Requirement 11.4.7)

Operator interpretation: You need a defined way for customers to conduct external penetration testing against the portions of your service they use (and that are in PCI scope for them), without violating your acceptable use terms or creating risk to other tenants. “Support” is not satisfied by telling customers “no testing allowed” or by pointing them to a generic policy. It means you provide a workable path to request, approve, and execute tests with boundaries and monitoring. (PCI DSS v4.0.1 Requirement 11.4.7)

Practical implication: Your obligations are both contractual and technical:

• Contractual: written authorization, a documented process, and clear responsibilities.
• Technical: tenant isolation protection, rate limiting / safe testing constraints, and coordinated monitoring so tests do not look like unmanaged attacks.

Plain-English interpretation (what the requirement is really asking)

If you are a multi-tenant service provider, you must be ready for customers to hire external testers and run an external penetration test against the customer’s use of your service. You do not have to allow unsafe or unlimited testing, but you do have to provide a controlled mechanism that makes testing feasible and evidenceable. (PCI DSS v4.0.1 Requirement 11.4.7)

A good mental model: you are running a “customer pen-test concierge” program. Customers submit a request, you confirm scope, you authorize the activity, you define safe-testing rules, and you capture artifacts that show the test happened within guardrails and any issues were handled.

Who this applies to

In-scope entity types

• Multi-tenant service providers whose people, processes, or systems can affect the security of the cardholder data environment. (PCI DSS v4.0.1)

In-scope operational contexts (common examples)

• SaaS platforms where multiple customers share application infrastructure.
• Managed service providers that host shared WAF, shared logging, shared gateways, or shared admin planes.
• Cloud platforms offering shared services where customer environments are logically separated, not physically dedicated.

Out-of-scope (often misunderstood)

• Single-tenant hosted environments where the customer has exclusive infrastructure may still need pen-testing coordination, but the “multi-tenant support” obligation is specifically called out for multi-tenant providers. (PCI DSS v4.0.1 Requirement 11.4.7)

What you actually need to do (step-by-step)

Below is a practical build-out you can assign to owners (Security, Legal, Support, SRE) and track to completion.

1) Define the “Customer External Pen-Test Policy” (customer-facing)

Create a short policy that answers:

• Who can request testing (customer roles, authorized contacts).
• What types of testing are allowed (external only, no social engineering unless separately approved, etc.).
• Default prohibited activities (tenant hopping attempts, denial-of-service, credential stuffing).
• How to request exceptions.
• Required notice period (your choice, but make it explicit).
• Your right to pause/stop testing if it risks other tenants or stability.

Map this policy to the requirement language and keep it version-controlled. (PCI DSS v4.0.1 Requirement 11.4.7)

2) Build a request + authorization workflow (intake to approval)

Implement a standard workflow (ticketing system or GRC tool) with required fields:

• Customer identifier and environment(s)
• Tester firm name and points of contact
• Test dates/window
• Source IP ranges (or cloud regions)
• Targets (hostnames, URLs, API endpoints)
• Test methods (scanners, manual testing, exploit attempts)
• Data handling statement (how findings and evidence will be secured)

Issue a written authorization letter (LOA) or equivalent approval artifact that the customer can share with their testers. Keep it specific to scope and dates. (PCI DSS v4.0.1 Requirement 11.4.7)

3) Publish a “pen-test scope boundary” for multi-tenant safety

This is where most programs fail. You need an explicit boundary that lets customers test what they touch while protecting shared components.

Create and maintain:

• Customer-testable surfaces: customer-specific subdomains, tenant-specific endpoints, customer-owned integrations.
• Provider-managed shared components: administrative planes, shared routing layers, shared identity services, shared databases.
• Conditional surfaces: components that are shared but testable under special supervision (for example, a shared edge where you provide a dedicated test window).

Give customers a clear statement of “you can test A/B/C; you cannot test X/Y/Z without explicit supervision.” (PCI DSS v4.0.1 Requirement 11.4.7)

4) Add technical guardrails to make testing safe and observable

Coordinate with Security Engineering / SRE on guardrails such as:

• Allowlisting test source IPs in WAF where appropriate (or creating a “test mode” profile).
• Rate limiting that prevents stress testing from impacting other tenants.
• Alert tuning during approved windows (do not silence everything; tag and route events).
• Dedicated test tenants or sandbox environments when production testing is too risky.
• Strong tenant isolation verification steps post-test (log review for cross-tenant access attempts).

These guardrails are part of “support” because they make customer testing realistically possible without platform harm. (PCI DSS v4.0.1 Requirement 11.4.7)

5) Coordinate communications and incident handling

You need an operational playbook:

• Who gets notified internally when testing starts (SOC, on-call, support).
• What happens if the tester finds a critical issue in shared components.
• How to handle “unapproved testing” detection (escalate, validate customer identity, stop if needed).

Ensure Support can recognize approved testing and route quickly to Security. (PCI DSS v4.0.1 Requirement 11.4.7)

6) Close-out: findings intake, remediation, and customer responses

Define closure criteria:

• Customer confirms testing completion.
• You receive a testing summary or attestation of completion (even if the customer will not share full report).
• For findings in your responsibility area: triage, ticket, remediation, retest evidence, and customer communication.

Your assessors will expect you to demonstrate that the program exists and operates, not that you fix every customer’s findings instantly. Track outcomes and decisions. (PCI DSS v4.0.1 Requirement 11.4.7)

Required evidence and artifacts to retain

Maintain an audit-ready package. Recommended artifacts:

• Customer-facing pen-test policy and rules of engagement (version history).
• Request intake records (tickets/forms) showing required fields completed.
• Written authorization letters (LOAs) with scope and dates.
• Internal approvals (Security + operations sign-off where required).
• Any temporary configuration changes (WAF allowlists, rate limit changes) and rollback evidence.
• Monitoring records: SOC notes, alert tags, incident tickets if triggered.
• Post-test closure record: completion confirmation, findings received (if shared), remediation tickets, and retest/validation notes.
• Exception register: denied requests, special approvals, compensating controls.

A practical tip: store these per customer per test cycle, then aggregate into a program-level dashboard for assessor walkthroughs. Daydream can help structure the evidence set and keep approvals, exceptions, and follow-ups tied to a single requirement record so you can answer assessor sampling quickly. (PCI DSS v4.0.1 Requirement 11.4.7)

Common exam/audit questions and hangups

Expect assessors (or customer due diligence teams) to ask:

• “Show me your process for customer external penetration testing in a multi-tenant environment.” (PCI DSS v4.0.1 Requirement 11.4.7)
• “How do you prevent one tenant’s test from impacting another tenant?”
• “Do you ever deny testing? Under what criteria, and what alternative do you provide?”
• “How do you authorize third-party testers and verify identity?”
• “How do you ensure logging/monitoring stays effective during approved tests?”
• “Provide a sample of recent customer pen-test requests and the associated approvals and closure evidence.”

Hangups that cause delays:

• No written authorization artifacts (approvals happen in chat).
• No clear boundary on “shared services” vs “customer surfaces.”
• Support/SOC not aware of the program, resulting in unnecessary incident escalation or blocked traffic.

Frequent implementation mistakes (and how to avoid them)

1. Blanket “no testing” contract clauses.
   Fix: Replace with a governed process: permitted with authorization, scope, and safeguards. (PCI DSS v4.0.1 Requirement 11.4.7)

2. Treating this as a one-time FAQ page.
   Fix: Build an operating workflow with intake, approvals, and closure evidence.

3. Over-allowlisting that blinds detection.
   Fix: Tag approved testing and tune alerts without turning off monitoring broadly.

4. No exception path.
   Fix: Some customers will need to test areas you classify as “shared.” Offer supervised windows, a dedicated test environment, or provider-run testing in that zone, then document the decision. (PCI DSS v4.0.1 Requirement 11.4.7)

5. No linkage to remediation.
   Fix: If a customer finding implicates provider-controlled components, open internal tickets, track to closure, and retain proof of fix validation.

Enforcement context and risk implications

No public enforcement cases were provided for this specific requirement in the source catalog, so treat enforcement risk here as indirect: failure typically shows up as a PCI assessment finding, customer due diligence failure, or contractual dispute after an incident.

Operational risk is straightforward:

• If customers cannot test, they may miss exploitable exposures on their external footprint.
• If testing is uncontrolled, you risk cross-tenant impact, stability events, and noisy security operations.
• If evidence is weak, you will struggle during assessor sampling to prove the support obligation exists and is repeatable. (PCI DSS v4.0.1 Requirement 11.4.7)

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable program)

• Name an owner (Security/GRC) and publish a customer-facing pen-test policy with allowed/prohibited actions. (PCI DSS v4.0.1 Requirement 11.4.7)
• Implement a request form/ticket with mandatory fields and a standard LOA template.
• Define and publish scope boundaries: customer-testable surfaces vs shared components.
• Create internal comms: SOC/on-call notification checklist for approved tests.

Days 31–60 (add guardrails and make it repeatable)

• Implement technical controls for approved testing (WAF workflows, rate limit profiles, alert tagging).
• Train Support and SOC on “approved testing” handling and escalation paths.
• Add a closure checklist and integrate findings intake with your vulnerability management process.
• Start an exception register with documented approvals/denials and rationale.

Days 61–90 (prove it works under sampling)

• Run at least one tabletop or pilot with a friendly customer or internal red team acting as “customer tester,” then capture artifacts end-to-end.
• Build an assessor-ready evidence pack template for each test (request → approval → monitoring → closure).
• Review and tighten contract language so it matches your program (no conflicting “no testing” terms).
• Use Daydream (or your GRC system) to centralize evidence, approvals, exceptions, and remediation follow-up for fast retrieval during PCI assessment sampling. (PCI DSS v4.0.1 Requirement 11.4.7)

Frequently Asked Questions

Do we have to allow customers to run any type of penetration test they want?

No. PCI DSS requires you to support customer external penetration testing, but you can impose rules of engagement that protect other tenants and service stability. Put the boundaries in writing and document exceptions. (PCI DSS v4.0.1 Requirement 11.4.7)

What counts as “support” for customer external penetration testing?

“Support” should be visible as an operating program: a request path, written authorization, defined scope boundaries, and coordination so testing can occur safely. If customers can’t realistically test without being blocked, assessors may view that as a gap. (PCI DSS v4.0.1 Requirement 11.4.7)

Can we require customers to test only in a sandbox, not production?

You can, if a sandbox provides a realistic external attack surface for the customer’s use case. If production is the only meaningful target, create a controlled production testing path with guardrails rather than default denial. (PCI DSS v4.0.1 Requirement 11.4.7)

What if a customer’s tester triggers our SOC and incident response?

Build a notification and tagging process so the SOC can distinguish approved testing from unknown hostile activity. Keep monitoring active; route alerts with context instead of silencing them broadly. (PCI DSS v4.0.1 Requirement 11.4.7)

Do we need to collect the customer’s full penetration testing report?

The requirement is about supporting the customer’s testing, not forcing report sharing. Retain evidence of authorization, scope, dates, and closure; if findings affect provider-controlled components, document triage and remediation outcomes. (PCI DSS v4.0.1 Requirement 11.4.7)

How do we handle customers who want to test shared infrastructure components?

Create an exception process. Offer supervised windows, provider-run testing in shared zones, or a dedicated environment, then record the decision, safeguards, and any compensating controls. (PCI DSS v4.0.1 Requirement 11.4.7)