Any US business that stores, processes or transmits payment card data has to show its assessor regular penetration testing. Under PCI DSS v4.0.1 that obligation sits in Requirement 11.4, and it is more specific than many teams expect. It covers who may run the test, which networks must be included, how often segmentation is checked and what has to happen after findings are reported. This guide explains each part so you can plan a test that holds up at assessment time.
Scans and penetration tests are different requirements
PCI DSS splits technical testing into two parts, and teams often blur them. Requirement 11.3 covers vulnerability scanning: internal and external scans every quarter, and the external ones must come from a vendor on the PCI SSC list of Approved Scanning Vendors (ASVs). Requirement 11.4 covers penetration testing: a person tries to exploit weaknesses, chain them together and reach card data.
One does not replace the other. A clean ASV scan shows that known issues are not visible from the internet. It says nothing about whether a logged-in user can reach another customer's stored card, or whether a compromised office laptop can talk to the payment database.
| Activity | PCI DSS reference | Minimum frequency | Who performs it |
|---|---|---|---|
| External vulnerability scan | 11.3 | Quarterly | A PCI SSC Approved Scanning Vendor |
| Internal vulnerability scan | 11.3 | Quarterly | No ASV needed; your team or a provider |
| Internal and external penetration test | 11.4 | Every 12 months and after significant change | Qualified internal resource or qualified, independent third party |
| Segmentation testing (merchants) | 11.4 | Every 12 months and after changes to segmentation | As above |
| Segmentation testing (service providers) | 11.4 | Every six months and after changes to segmentation | As above |
A documented methodology comes first
Requirement 11.4.1 asks you to define, document and follow a penetration testing methodology. Assessors will want to see it, so it should exist before testing begins rather than be written up afterwards. A useful methodology document answers a few practical questions:
- How the boundary of the cardholder data environment (CDE) is identified and which systems sit inside it
- Which layers are tested: network, operating systems, applications and the interfaces that carry card data
- How testing from outside the network differs from testing from inside it
- Which industry methods the testers follow, for example NIST SP 800-115, PTES or the OWASP testing guides
- How findings are rated, how quickly critical issues are reported and how fixes are verified
- How long test results and evidence are kept
If you buy testing from a provider, ask for their methodology during scoping and check it covers these points. Ours is described on our how it works page and adapted per engagement.
Internal and external testing
The external test looks at your environment the way someone on the internet would: public IP ranges, web applications that accept card data, payment pages, remote access gateways and anything else exposed outside your perimeter. Our external network pentest and web application pentest cover this ground.
The internal test assumes an attacker already has a foothold on your corporate network and asks whether they can reach the CDE. Common routes include weak service account passwords, shared admin credentials, flat networks and Active Directory privilege paths. An internal network pentest paired with an Active Directory review usually answers this best.
Both views matter. Many merchants find that external exposure is tight while internal paths to payment systems are short.
Segmentation testing
Segmentation is optional in PCI DSS, but it is the main way to keep the rest of your network out of assessment scope. If you rely on it, you must prove it works. The test tries to reach CDE systems from each out-of-scope network segment and confirms that the controls between them block that traffic.
Merchants must test segmentation at least every 12 months. Service providers must test at least every six months. Both must also retest after any change to the segmentation controls themselves, such as new firewall rules, a cloud network redesign or a moved payment server. If you are a service provider, plan two segmentation tests into the year from the start rather than discovering the second one late.
What counts as a significant change
PCI DSS asks for a new test after significant change but leaves the definition to you. Write your own list into policy so engineering teams know when to ask for one. Typical items include:
- A new or rebuilt payment page, checkout flow or card-handling API
- Moving card systems to a new data center or cloud account
- Major operating system or platform upgrades inside the CDE
- New network connections into the CDE, including vendor access
- Changes to how users authenticate to card systems
A focused test of the changed component is usually enough. It does not need to repeat the full annual engagement.
Who may perform the test
PCI DSS lets you use either a qualified person on your own staff or a qualified outside firm, as long as the tester has organizational independence from the systems being tested. A network engineer cannot test the firewall rules they wrote. The tester does not have to be a Qualified Security Assessor (QSA).
For clarity: BugFoe, which operates PentestProviders, is not a QSA or an ASV. We run the penetration and segmentation tests and document them for your assessor. Your quarterly external scans must still come from an ASV, and your assessment, where one is required, comes from a QSA or your internal assessor.
Fixing and retesting findings
PCI DSS expects exploitable vulnerabilities found during penetration testing to be corrected and the correction verified by retesting. A report full of open findings is not the end state your assessor wants. Plan for three steps:
- Prioritize findings by severity and by how close they sit to card data.
- Fix and deploy changes to the environment that was tested.
- Retest each exploitable finding and keep the retest record with the original report.
Our retest service is free for findings from our own engagements. The remediation and retesting guide covers how to organize the work.
Preparing for a PCI penetration test
- A current data-flow diagram showing where card data enters, travels and is stored
- A list of CDE systems and the network segments around them
- Test accounts for any application that handles card data, one per role
- VPN access or a test device on each segment the internal test must start from
- Your methodology document, or agreement to use the provider's
- Written authorization signed by someone who controls every system in scope
Settle the test dates against your assessment calendar. A test finished a week before the assessor arrives leaves no time to fix and retest.
Frequently asked questions
Does our penetration tester have to be a QSA?
No. PCI DSS asks for a qualified internal resource or a qualified external third party with organizational independence. A QSA assesses your compliance; the tester can be a different firm. We are not a QSA or ASV.
Do quarterly ASV scans replace the annual penetration test?
No. Requirement 11.3 covers quarterly internal and external vulnerability scans, and the external ones must come from an Approved Scanning Vendor. Requirement 11.4 is a separate, deeper exercise. You need both.
How often must segmentation be tested?
At least every 12 months for merchants and at least every six months for service providers, and after changes to segmentation controls. The test should show that out-of-scope networks can't reach the cardholder data environment.
Planning your next PCI DSS cycle? See compliance pentesting, size the effort in our dollar calculator, or request a fixed price for your scope.