PCI DSS Penetration Testing: Scope, Methodology and Choosing a Provider

Consider a hypothetical case. A small payment service provider processes card payments for online shops. In the spring, the team moved its tokenization service into a new cloud segment: different security groups, a new bastion host for administrators, updated rules between the cardholder data zone and the corporate network. The assessor visits in a month, and the evidence folder holds last year's penetration test report. Opening it, the head of security sees three problems. The scope covered external IP addresses only. There was no segmentation test at all. And some of the internal checks were run by the administrator who had configured the firewalls himself.

This is an invented example, not the story of a real company. But every question in it is real. Was the migration a significant change that calls for a new test? Has the separation of the cardholder data environment (CDE) been tested, and how often must a service provider in particular do that? Is the tester independent enough? PCI DSS penetration testing is worth exactly as much as the answers to these questions given before work starts. Below we cover what the current version of the standard requires, how to derive scope from data flows, how to plan the test so the report holds up to an assessor's questions, and how to choose a provider on evidence rather than on day rate.

What PCI DSS v4.0.1 Requires from Penetration Testing

PCI DSS is a baseline of technical and operational requirements for protecting payment account data. It applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to entities that could affect the security of the CDE. The current version is 4.0.1. The PCI Security Standards Council published it on 11 June 2024 as a limited revision: compared with 4.0, no requirements were added and none were deleted. Version 4.0 was retired on 31 December 2024. A statement of work should therefore reference 4.0.1, and exact wording for formal documents should be checked against the official text.

Penetration testing is covered by Requirement 11.4. Unlike many industry topics, the frequency here is written down explicitly, and it pays to know it precisely.

Internal and External Testing: Every 12 Months and After Significant Changes

Requirement 11.4.2 calls for internal penetration testing, performed according to the methodology the entity itself has defined, at least once every 12 months and after any significant infrastructure or application upgrade or change. Requirement 11.4.3 sets the same conditions for external penetration testing.

Two details matter more than they seem. The first is the phrase "according to the entity's methodology". The methodology document is not a formality: it is what the assessor will compare the work against. The second is the change trigger. In our example, moving tokenization into a new cloud segment with a new bastion is hard not to treat as a significant change, and last year's report no longer describes it. What counts as significant depends on the environment, but PCI DSS supplies a minimum set of considerations: new or substantially upgraded hardware and software in the CDE; changes to account-data flows or storage, the CDE boundary or assessment scope, and supporting infrastructure such as directory, time, logging and monitoring services; and changes to third parties or services that support the CDE or meet PCI DSS requirements on the entity's behalf. The entity should document its own criteria on top of that minimum and be able to explain its decision for a particular change. How to run testing on events rather than on a calendar is covered in detail in our piece on change-triggered penetration testing.

Segmentation Testing: Every 12 Months When Used, Every Six for Service Providers

Where segmentation is used to isolate the CDE from other networks, Requirement 11.4.5 applies to every such entity: all segmentation controls and methods are penetration-tested at least once every 12 months and after any change to them. Testing must confirm that the controls are operational and effective and isolate the CDE from every out-of-scope system; where systems with different security levels are separated, that isolation is tested too.

Requirement 11.4.6 is additional and applies only to service providers: the same type of test is performed at least once every six months and after any change to segmentation controls or methods. The six-month interval should not be extended to every merchant, but the general annual obligation in 11.4.5 must not be omitted where segmentation is used. In our example, changing the rules between zones triggers an out-of-cycle test on its own. Separately, Requirement 11.4.7 requires a multi-tenant service provider to support customers’ external penetration tests under 11.4.3 and 11.4.4: it must provide prompt access for customer testing or evidence of comparable testing on the infrastructure to which the customer subscribes. Results may be redacted if the remaining information is sufficient to show every element of those requirements. After 31 March 2025 this is a requirement, not a best practice.

Who May Perform the Test

The standard allows either an internal or an external resource, provided it is qualified and organizationally independent. Neither a QSA nor an ASV is required to perform the penetration test. Independence means the tester does not assess their own work: the administrator who configured the firewalls is a poor candidate for testing their rules, however skilled he may be.

What a Penetration Test Is Not

Regular vulnerability scanning is set out in separate PCI DSS requirements and does not replace testing under 11.4, just as a penetration test does not replace scanning. Moreover, a penetration test report is evidence that the assessor evaluates, not a certification, an attestation or an opinion on compliance. A good report makes the assessment easier, but it does not by itself confirm compliance.

PCI DSS Pentest Scope: Start from Card Data Flows, Not an IP List

PCI DSS scope is tied to where card data is stored, processed and transmitted, and to the systems that can affect the security of the CDE. It is not automatically the whole enterprise. A sensible sequence is therefore the reverse of the usual one: first the data-flow diagram, then the inventory of systems on those flows, and only then the addresses and URLs to test.

What Usually Ends Up in Scope

As a rule, several groups of assets. Internet-facing payment pages, checkout APIs and the interfaces through which payment data passes. Internal CDE systems: tokenization, databases holding card data, transaction processing. The mechanisms that are supposed to separate the CDE from other networks: firewall rules, cloud security groups, routing. Administrative and remote-access paths: bastions, VPNs, cloud consoles and deployment pipelines that can change the CDE's configuration. And third-party components of the payment flow: the gateway, scripts on the payment page, acquirer webhooks.

For administrative paths, it helps to separate two kinds of credentials from the outset. Human logins are protected by multi-factor authentication, and the tester looks for ways around it, weak recovery flows and excessive privileges after login. Workload credentials — API keys, service accounts, pipeline tokens — are tested differently: where they are stored, who can see them, what they grant and what an attacker could do with a single one of them. Merge these checks into one line of the report and half the conclusion is lost.

Two Traps

The first is excluding systems because they are fragile or politically sensitive. An old processing server that is "best left alone" remains part of the CDE; excluding it undermines the point of the test and is very likely to draw the assessor's questions. Fragility is handled with constraints in the rules of engagement, not by removing a system from scope.

The second trap is including the whole enterprise "just in case". That inflates the budget, spreads testers' time thin and adds no confidence about the protection of payment data specifically. A documented boundary avoids both traps: every inclusion and exclusion has a recorded rationale, and the assessor has seen it before work starts.

The table below breaks scope down by attack boundary and shows which question each one answers.

If the CDE boundary in your environment is still fuzzy, a table like this is a convenient place to start the project conversation. The data-flow diagram and the rationale for inclusions can be discussed with Pentest.red on the pentest scoping page. The decision about what the standard requires in your case stays with you and your assessor.

Authorization and Rules of Engagement

Written authorization is a mandatory precondition, not paperwork. It must come from those actually empowered to decide about the target systems: the business owner, the person responsible for the infrastructure and, where their terms apply, hosting, cloud or managed service providers. If the payment gateway's API belongs to another company, the online shop owner's consent gives no right to attack that API.

Rules of engagement turn authorization into a working document. They record time windows, permitted and prohibited techniques (for example, no load attacks on processing during peak hours), test accounts and test cards, conditions for an immediate stop, and emergency contacts.

Data handling is agreed separately. If the tester encounters real card numbers, they capture the minimum evidence needed, mask the number, do not copy the data into their own systems and notify the responsible person immediately. Logs and screenshots are scrubbed of secrets and unnecessary personal data. The entity retains penetration-test results and remediation-activity results for at least 12 months, as 11.4.1 requires; access is restricted, while retention of a provider's copies is minimized separately by contract.

Methodology: NIST SP 800-115 as a Framework

Requirement 11.4.1 does not prescribe a branded methodology, but it does set mandatory minimum contents. The entity's methodology must use industry-accepted approaches; cover the entire CDE perimeter and critical systems, testing from inside and outside the network, segmentation and other scope-reduction controls; include application-layer testing for at least the vulnerabilities in 6.2.4 and network-layer testing of network functions and operating systems; consider threats and vulnerabilities experienced in the prior 12 months; and document how risk from exploitable findings is assessed and addressed. The methodology must provide for attempts at controlled exploitation: automation may assist, but a scanner alone, or exploitation limited to its findings, does not replace the work of a competent tester.

NIST SP 800-115 can provide a process framework for delivering that minimum. The technical guide to information security testing and assessment was published in September 2008 to replace SP 800-42. It helps organizations plan and conduct technical tests, analyze the results and develop risk-mitigation measures. Formally, the guide describes three assessment phases: planning, execution and post-execution, the last of which covers analysis of findings, reporting and recommendations.

The document says plainly that it is not meant to be a complete description of a testing program: it is an overview of key techniques with their benefits and limitations. That is exactly the approach that serves PCI work. A good report explains not only what was done but why each technique was chosen and what it could not have found. Because the guide dates from 2008, the content of application-level checks is better taken from newer sources, discussed below.

On top of NIST's three phases, it is practical to build your own remediation cycle: owners, risk-based deadlines, a retest. This is not the guide's wording but a working extension, without which Requirement 11.4.4 is hard to meet.

1. Data-flow mapWhere card data enters, moves and is stored, and which systems can affect the CDE.
2. Authorization and rulesSignatures from empowered owners and providers, windows, prohibitions, data handling, stop conditions.
3. External, internal and segmentation testsTesting under 11.4.2 and 11.4.3; segmentation under 11.4.5, with the additional 11.4.6 frequency for service providers.
4. Risk-based remediationOwners and deadlines for each exploitable vulnerability in line with 11.4.4.
5. Retest and recordVerifying fixes in the agreed environment and recording which attack variants were rechecked.

The Payment Page and the Checkout API

For applicable web checks of payment pages, checkout APIs and administrative consoles, web testing standards are useful. The OWASP Web Security Testing Guide provides a set of test cases; the report should state the version used, for example 4.2. OWASP ASVS sets out verifiable requirements for web controls. In version 5.0.0 the project recommends citing requirements together with the version number, in a format such as v5.0.0-1.2.5, because numbering changes between versions. Such references make the scope verifiable, but they do not prove that the application conforms to the standard as a whole.

The OWASP Top 10, 2025 edition, is an awareness document about the most critical web application risks, not a test plan. A scope that stops at those ten categories is narrower than what WSTG and ASVS allow.

Sessions, Scripts and Cross-Origin Requests

Three mechanisms matter especially on a payment page. The first is sessions. HTTP itself does not link requests to one another, so the application typically keeps session state on the server and gives the browser an identifier in a cookie. The tester checks how that identifier is issued, whether it is renewed after login, and which flags and lifetime protect it.

The second is script loading. Content Security Policy lets you restrict where a page may load resources from and helps mitigate cross-site scripting and data injection. A third-party script executing in the payment page’s context may gain access to input; its necessity, origin and restrictions need separate review.

The third is CORS. This policy determines which foreign origins may read API responses. If the server dynamically allows an attacker-controlled Origin while also allowing credentials, a victim's browser may expose an authenticated response to that site when cookie rules and the endpoint's behavior actually permit those credentials to be sent.

Payment Business Logic

A separate area is logic that scanners barely see. A hypothetical example: the checkout API takes the amount from the client's request instead of recalculating it on the server. Another: the acquirer webhook handler sets the order status to "paid" without verifying the notification's signature. These are business-logic and message-authenticity flaws: if the relevant scenario is reachable, they can cause financial losses. How to plan such checks is covered in our article on business logic security testing, and the method for testing the API itself in our piece on REST API security assessment.

Trade-offs: Scanner or Manual Test, Production or Staging

NIST SP 800-115 treats vulnerability scanning and penetration testing as different techniques, each with its own strengths and weaknesses. A scanner covers many assets quickly and repeatably and suits frequent checks. A manual test is slower but finds logic flaws, chains of weaknesses and authorization gaps that a scanner does not connect. A convincing penetration test uses tools for breadth and people for depth. A report made up mostly of scanner output should raise questions.

The choice of environment is also a trade-off. Testing in production gives the most realistic picture but carries operational risk for processing. Staging is safer, yet it may differ in configuration, network rules and data, so its results cannot be carried over to production without caveats. If a copy is tested, the report must list known differences and state which conclusions need confirmation in the live environment. This applies above all to segmentation: rules in staging prove only properties of staging.

The tester's level of knowledge affects how much gets checked. Black-box testing simulates an outside attacker with no information. Grey- or white-box testing, with test accounts and architecture documentation, usually lets the team cover a noticeably larger part of the application in the same time. This is a practical observation, not a measured statistic, but the logic is simple: a tester cannot verify a control they never reached.

Finally, budget. Instead of buying a fixed number of person-days, describe the scope through the boundaries in the table above, applicable versioned ASVS and WSTG web checks, and separate criteria for infrastructure and other technologies, and then ask providers to estimate exactly that. An opaque effort estimate then becomes a comparable specification.

How to Rank Findings: Risk, CWE and Signs of Exploitation

Requirement 11.4.4 speaks of correcting exploitable vulnerabilities and security weaknesses according to risk, so the report needs clear prioritization. CWE classification helps here. The 2025 edition of the CWE Top 25 Most Dangerous Software Weaknesses highlights weakness classes that MITRE describes as often easy to find and exploit and capable of leading to system takeover, data theft or application outage. The companion list, the 2025 CWE Top 10 KEV Weaknesses, ranks weakness classes using CISA's catalog of known exploited vulnerabilities.

These signals should not be overstated. A finding belonging to a class on the KEV list is a reason to look at it more closely, but CWE classification by itself does not prove that this particular vulnerability can be exploited or has been exploited. What decides is confirmation in your environment: reachability, preconditions, what the attacker gains and how close that is to card data. How to combine these factors is covered in detail in our article on risk-based vulnerability prioritization.

CWE tagging has a second use too. CISA's Secure by Design alerts address entire defect classes: cross-site scripting, OS command injection, directory traversal, buffer overflow. Once findings are tagged, recurring classes can be fed back into development standards and eliminated systematically rather than one at a time.

Remediation and Retesting Under Requirement 11.4.4

Where a penetration test finds exploitable vulnerabilities or security weaknesses, the report alone is not the end of the work. Requirement 11.4.4 calls for correcting them according to the risk assessment defined in 6.3.1 and repeating testing to verify the corrections. The retest should therefore be estimated and scheduled in the original contract, not discussed after the report arrives: how much time the team has for fixes, who rechecks and in which environment.

A retest conclusion is limited to what was actually checked. "Fixed" means that, in the agreed environment, for the listed attack variants, as of the stated date, the original chain no longer works. Within the agreed retest scope, checking close variants is useful: if one API parameter was fixed but a neighbouring one still accepts the amount from the client, a point verification must not be presented as elimination of the whole class. How to build such verification is described in our piece on penetration test remediation validation.

The second table is a practical list of what to demand when accepting results.

A Report That Withstands the Assessor's Questions

A report's value is defined by whether you can act on it. Each finding needs the affected asset, the conditions under which it was confirmed, evidence sufficient for authorized re-verification, a CWE class where applicable, references to versioned ASVS requirements or WSTG areas only for suitable web checks or another technical criterion, and a risk rationale in the context of the payment environment. A finding without reproducible evidence is hard to fix and hard to defend before an assessor. A separate section should describe limitations: what was not tested and why, and where the environment differed from production.

It is useful to link results to risk management more broadly. The NIST Cybersecurity Framework 2.0 helps organizations understand and improve how they manage cybersecurity risk, and its profiles make it possible to show leadership that testing the payment environment is part of an overall program rather than a one-off audit task. Recurring classes of findings in purchased software should be passed on to suppliers. CISA's Secure by Design approach holds that manufacturers should take on a larger share of the security burden, and the Secure by Demand guide is written precisely for customers negotiating purchases. Evidence from a penetration test is a strong argument in that conversation.

How to Choose a PCI DSS Penetration Testing Provider

It makes sense to move to choosing a provider once scope, methodology and reporting expectations are defined: only then can proposals be compared fairly. Ask each candidate to describe how their process maps to the NIST SP 800-115 phases, which WSTG and ASVS versions their applicable web tests use and what criteria cover the other technologies, how they test segmentation and where automation ends. Request an anonymized sample report and assess it against the acceptance table above. If the sample lists scanner output with generic advice, the depth of the service is clear whatever the price.

Check qualifications through people: what experience the specific testers have with payment applications and infrastructure, who controls report quality, how organizational independence is ensured. Check references yourself. QSA or ASV status is not required for testing under 11.4 and, on its own, does not establish the quality of penetration testing.

Commercial terms should cover the retest, handling of card data if it is encountered, authorization paperwork with each owner, immediate notification of critical findings during the work, and secure transfer and storage of the report. Compare proposals not on price per IP address or per day but on the scope and evidence each one commits to deliver. If you want to discuss such a scope and evidence format for your own payment environment, look at the description of our penetration testing service and come to the conversation with a data-flow diagram in hand. How compliance is validated depends on the assessment route applicable to the entity, such as an SAQ or an assessment resulting in a ROC. The pentest report can provide technical evidence to that process, but it does not replace the required self-assessment, assessor review or PCI DSS validation documents.

Conclusion

A PCI DSS penetration test pays off when compliance is treated as the minimum and risk reduction as the goal. Requirement 11.4 in version 4.0.1 sets the frame: a methodology with the 11.4.1 minimum and at least 12 months of result retention; separate internal and external tests at least once every 12 months and after significant changes; segmentation testing under 11.4.5 annually and after any change, with an additional at-least-six-month frequency for service providers; and risk-based remediation with retesting. Within that frame, quality depends on: scope derived from data flows, authorization from those entitled to give it, a methodology with clear phases, application checks against versioned requirements and a report that can be reproduced.

Back to the hypothetical provider from the opening. It does not need "another pentest". It needs an out-of-cycle test after the migration, a segmentation test at the right frequency and a tester who is not checking his own rules. Framing the task this way supplies reviewable grounds for reducing risk and understanding the limits of the evidence, rather than merely filling a tidier folder of documents.