PCI DSS penetration testing requirements: what Requirement 11.4 asks for

PCI DSS penetration testing requirements are the rules in Requirement 11.4 of PCI DSS v4.0.1. They say you must run external and internal penetration tests at least once every 12 months and after any significant change, using a documented methodology, a qualified and independent tester, and a retest that proves the fixes worked. If you isolate card systems with segmentation, you must test that too.

That is the short version. Below you get each sub-requirement (11.4.1 to 11.4.7), the line between a pentest and a vulnerability scan, and who may do the work. Then comes scoping for a web application, and the evidence your assessor will ask to see.

What does PCI DSS Requirement 11.4 say?

Requirement 11.4 states that "external and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected." It has seven numbered sub-requirements. Two of them apply only to service providers.

The PCI Security Standards Council published PCI DSS v4.0.1 on 11 June 2024 as a limited revision. Its announcement says it adds and deletes no requirements, so the numbering below matches v4.0. The council retired v4.0 on 31 December 2024, so your assessor now works from v4.0.1.

The Verizon 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way in, and 48% of breaches involve ransomware. The IBM Cost of a Data Breach Report 2026 puts the global average cost of a breach at 4.99 million US dollars, up 12% on the year before. Of everything in Requirement 11, the pentest is the control that tests whether someone can get through your own application. A scan only tells you whether a known weakness exists.

The seven sub-requirements at a glance

The table gives the substance of each sub-requirement in plain words. For the exact wording, download the standard from the PCI SSC Document Library.

The table follows the wording in Microsoft's Requirement 11 mapping, which quotes the defined-approach wording. Check the final wording against your own copy of the standard.

11.4.1: what the methodology must include

Your assessor reads the methodology first. It must include nine elements:

• Industry-accepted penetration testing approaches.
• Coverage for the entire CDE perimeter and critical systems.
• Testing from both inside and outside the network.
• Testing to validate any segmentation and scope-reduction controls.
• Application-layer testing for, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
• Network-layer tests covering all components that support network functions and operating systems.
• Review of threats and vulnerabilities experienced in the last 12 months.
• A documented approach to assessing and addressing the risk from exploitable findings.
• Retention of test results and remediation results for at least 12 months.

The PCI SSC's own Penetration Testing Guidance names accepted starting points: OSSTMM, NIST SP 800-115, the OWASP Testing Guide and the Penetration Testing Execution Standard. For web applications, most teams pick the OWASP Web Security Testing Guide. NIST SP 800-115 covers the overall process.

11.4.4: the retest clause people skip

Finding a flaw is half of the requirement. The other half is that you correct exploitable vulnerabilities "in accordance with the entity's assessment of the risk" and repeat the test to verify the corrections. A report with open critical findings and no retest is a gap, even when the test itself ran on time.

How often is a PCI DSS penetration test required?

At least once every 12 months for both internal and external tests, and again after any significant infrastructure or application upgrade or change. Segmentation tests follow the same 12-month rhythm, or every six months for service providers.

The calendar date is easy. The hard part is "significant change", because PCI DSS does not define it for you.

What counts as a significant change?

The PCI SSC guidance says a significant change "is not prescribed by PCI DSS" and depends on your risk assessment and configuration. Its test is practical. If a change could affect network security or open a route to cardholder data, treat it as significant. The aim is to confirm that the controls you assume are in place still work afterwards.

For a software company, these triggers belong in your methodology:

Write your threshold down and apply it. Teams that ship weekly tend to pair a yearly full test with lighter continuous pentesting routine, covered in continuous penetration testing.

What is the difference between a PCI penetration test and a vulnerability scan?

A vulnerability scan is mostly automated and finds known weaknesses. A penetration test is a manual process that shows how far an attacker can push those weaknesses. PCI DSS requires both, on different clocks, and neither replaces the other.

The PCI SSC Information Supplement sets the two side by side, and the table follows its comparison. The supplement dates from September 2017 and cites the older 11.3.1 and 11.3.2 numbering. Read it for intent, and read the v4.0.1 text for the rules.

The quarterly scan rules sit in 11.3, not 11.4. A common slip is to hand the assessor a clean ASV scan as if it were the pentest. It is not, and the standard lists them as separate controls. Our notes on vulnerability scanning and DAST explain why a scanner cannot tell you whether one customer can read another's invoices.

What must a PCI penetration test cover for a web application?

For a custom web application, the test must cover at least the attack types in Requirement 6.2.4 at the application layer. It must also cover the network layer of the supporting components. Code written by or for your organisation is in scope for both.

Requirement 6.2.4 lists the classes below. Use them as the minimum test plan for the application half of 11.4.1.

The Requirement 6.2.4 list as a test plan

Access control gets the most real-world findings

The OWASP Top 10:2021 ranks broken access control first. It found some form of the flaw in 94% of the applications tested, with over 318,000 occurrences in the contributed data. In a PCI context this is the flaw that lets a signed-in customer read other customers' card-related records. Our terms on broken access control, IDOR and tenant isolation explain the pattern.

The PCI SSC guidance makes the same point. When an application needs authentication, testers should try each type of access, including accounts with no explicit authorisation to cardholder data, and confirm those accounts cannot compromise it. On multi-tenant platforms, it says to test with a customer-level credential and check that access stops at that customer's own data.

6.2.4 names business logic as well. A refund issued twice is a typical case, and only a human or an engine that reasons about the app will catch it. See business logic flaw and exploited, not suspected.

Who can perform a PCI DSS penetration test?

Either a qualified internal resource or a qualified external third party, provided they are organisationally independent of the systems under test. The tester does not need to be a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV).

The PCI SSC guidance defines independence this way: the tester must sit outside the reporting line that manages the systems under test. A firm that does your PCI DSS assessment cannot also run the pentest if it helped install, maintain or support those systems. For a product team, this usually rules out the engineers who built and run the payment service testing their own work.

What does "qualified" mean?

The standard leaves "qualified" to you. The guidance offers things to check rather than a licence to demand. It lists OSCP, CEH, GIAC certifications, CREST and CHECK as indicators only, and says the council neither validates nor endorses them. It also says certifications alone cannot prove experience.

More buyer questions are in how to choose a penetration testing company and the term choosing a pentest provider.

Which tester set-up passes the independence test?

Independence comes from reporting lines, not job titles. The table applies the guidance to common set-ups.

Does a WAF or Requirement 6.4 replace a PCI penetration test?

No. Requirement 6.4 protects public-facing web applications; Requirement 11.4 tests them. PCI DSS asks for both, and one does not stand in for the other.

The Microsoft Learn copy of the defined-approach text shows two routes in 6.4.1 for public-facing web applications. One is an application vulnerability assessment by a specialist, at least every 12 months and after significant changes. The other is an automated technical solution that continually detects and prevents web-based attacks. Requirement 6.4.2 then requires that automated solution, commonly a web application firewall, with audit logs and either blocking or immediately investigated alerts.

How the four controls differ

File the evidence for each control separately, so your assessor can sample them one by one.

What is PCI DSS segmentation testing?

Segmentation testing is a penetration test aimed at the controls that separate your cardholder data environment from everything else. It proves that out-of-scope systems cannot reach the CDE, which is what lets you keep them out of PCI scope.

Requirement 11.4.5 applies only if you use segmentation. Test every segmentation control and method in use, at least once every 12 months and after any change to them. The test must confirm they are operational, effective, and isolate the CDE from out-of-scope systems. Service providers repeat this every six months under 11.4.6.

The guidance describes the approach as actively hunting for routes from networks outside the CDE into it. In a large network the tester need not start from each LAN segment. They must cover each type of segmentation method, such as firewall rules or VLAN access control lists, so the result holds wherever that method is used.

How do you scope a PCI DSS penetration test?

Scope the entire CDE perimeter and each critical system, plus anything that can affect the security of the CDE. For a software company that usually means the payment application, its APIs and admin interfaces, the infrastructure underneath, and the systems staff use to manage them.

The guidance defines the CDE as the people, processes and technology that handle cardholder data or sensitive authentication data. It adds that scope should include the assets staff use to maintain CDE systems, since compromising them could hand an attacker credentials or a route in.

What to hand the tester

The guidance recommends giving the tester documentation wherever possible. It lists:

1. A network diagram of all segments in scope.
2. A cardholder data flow diagram.
3. The services and ports you expect to be open at the CDE perimeter.
4. Details of how authorised users access the CDE.
5. A list of the network segments isolated from the CDE to reduce scope.

For a web application, also supply test accounts for each type of access and your API documentation (OpenAPI or GraphQL schema). Add the source code if you want white-box depth. Our terms on pentest scope, rules of engagement and authenticated testing cover the mechanics.

How do you fix and retest findings for PCI DSS?

Correct each exploitable finding in line with your own risk ranking from Requirement 6.3.1, then repeat the penetration test to verify the corrections. The retest belongs to the requirement (11.4.4). It is not an optional extra.

A retest workflow that stands up to an assessor

1. Rank. Apply the risk ranking from your 6.3.1 process to every finding, and record severity separately from how sure the tester is. See severity vs confidence.
2. Assign. Give each finding one owner and a due date based on severity. Write your remediation SLAs down in advance.
3. Fix. Change the code or configuration, then look for the same flaw in other endpoints.
4. Replay. Re-run the original exploit against the fixed build and keep the new request and response. This is the idea behind a closed-loop retest.
5. Record. Link the retest result to the original finding, and store both for at least 12 months.
6. Decide. For anything you cannot fix, record the reason and a risk acceptance with an owner and expiry.

What should a PCI DSS penetration test report contain?

It should say what was tested, how, and what happened, with enough proof for your assessor to trace each finding to its fix. The PCI SSC guidance warns that a bare list of vulnerabilities "does not meet the intent of the penetration test".

The guidance wants the path to any compromise: each step, the attack vector and the vulnerability exploited. It also recommends listing findings that were not exploited but still carry risk, with the reason. The report should show how each severity ranking was derived. To learn to read these documents, see our posts on what belongs in a finding and the term pentest report.

Evidence checklist for your assessor

If a change counts as significant, keep the record showing it triggered a new test. Assessors often ask, "What changed this year, and did you test it?"

What are the most common PCI DSS penetration testing mistakes?

The mistakes below come from reading the requirements against how software teams usually work, not from any published failure statistics.

Mistakes that cause a finding at assessment

• Submitting an ASV scan as the pentest. The standard treats the two as separate controls with different clocks.
• Testing only the network. 11.4.1 asks for application-layer testing against the 6.2.4 attack classes as well.
• Letting the builders mark their own work. Independence is organisational, so the engineers who run the system cannot be the tester.
• No retest. 11.4.4 expects you to repeat the test and verify the corrections.
• Ignoring significant change. A pentest dated before a major release does not cover the release.

What is a practical PCI DSS penetration testing plan for 2026?

Pick a yearly date, add triggers for significant change, test the application and the network separately, and close the loop with retests. This plan suits a software team that ships often.

Work in this order: methodology, CDE map, independent tester, accounts and documents, external and internal tests, segmentation, triage, retest, retention. Then add one question to your release checklist: "Is this a significant change?"

Our VAPT checklist and PCI DSS 11.4 term give extra detail, and penetration testing cost explains what drives the cost of an engagement.

Where does Cyberlop fit in PCI DSS pentesting?

Cyberlop covers the web application and API part of the work. It finds vulnerabilities with black-box, grey-box and white-box pentesting and reports only what it exploited, so a finding arrives with the request, the response, a screenshot where a person can see it and, in white-box mode, the line of code.

That maps to parts of 11.4 where evidence matters. It checks business-logic flaws and cross-account access, which are two of the 6.2.4 classes, keeps severity and confidence apart, and proves a fix by re-running the exact exploit against the new code, which is the 11.4.4 retest. It can also run on a schedule or in CI/CD and gate a build, so a payment change gets tested as it ships. See how it works and what the evidence looks like.

What it does not replace

Network-layer and segmentation tests are a different discipline, and the methodology, scoping and independence decisions stay with you and your assessor. Treat Cyberlop's output as application-layer testing evidence, and agree with your QSA how it fits your programme. Our honest page lists what we do not claim. If source code cannot leave your network, read about private scanning.