Scanning and penetration testing are two different requirements
This is the framework that says the quiet part out loud: PCI DSS requires vulnerability scanning under requirement 11.3 and penetration testing under 11.4, separately, and presenting one as the other is a common audit failure. Here is what each clause asks for.
The short answer
PCI DSS 4.0 requires internal and external vulnerability scans at least every three months (11.3), and internal and external penetration testing at least every 12 months and after significant change (11.4.2, 11.4.3). External scans must come from an Approved Scanning Vendor. These are separate obligations.
The requirements
What the PCI DSS text actually says
Internal vulnerability scans are performed at least once every three months; external vulnerability scans are performed at least once every three months by an Approved Scanning Vendor.
In practice: Quarterly scanning is a floor, not a target, and the external half must come from an ASV — check that status before switching scanning vendors, because a non-ASV scan does not satisfy the clause however good the tool is.
A penetration testing methodology is defined, documented and implemented, covering industry-accepted approaches, coverage of the CDE perimeter and critical systems, internal and external testing, and testing to validate segmentation.
In practice: The methodology document is itself an audit artefact. Assessors read it and then check that what you did matches it, so a vague methodology is safer than an ambitious one you did not follow.
Internal penetration testing is performed at least once every 12 months and after any significant infrastructure or application upgrade or change.
In practice: "Significant change" is yours to define and then live with. Write the definition down, and keep evidence of the tests that changes triggered — this is where teams most often come up short.
External penetration testing is performed at least once every 12 months and after any significant infrastructure or application upgrade or change.
In practice: The internet-facing perimeter of the cardholder data environment, tested by someone qualified. Automated continuous testing helps enormously with the "after significant change" half, which annual engagements cannot cover.
Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, and testing is repeated to verify the corrections.
In practice: Retesting is mandatory, not optional. A vendor that charges separately for verifying its own finding is charging you for a compliance requirement, which is worth factoring into the quote comparison.
Segmentation controls are tested at least once every 12 months to confirm they are operational and isolate the CDE; service providers test at least once every six months and after changes to segmentation controls.
In practice: If you rely on segmentation to reduce scope — and almost everyone does — the isolation itself has to be tested, not asserted. Service providers are on a six-month clock.
All payment page scripts are managed, with an inventory and written justification; a mechanism detects and alerts on unauthorised modification of HTTP headers and payment page content.
In practice: Mandatory since 31 March 2025, and aimed squarely at Magecart-style skimming. Practically it means knowing every script on your payment page and detecting when that set changes.
The Distinction That Fails Audits
A quarterly ASV scan and an annual penetration test are different obligations with different clauses, and the standard makes no attempt to blur them. Scanning enumerates known vulnerabilities across the environment; penetration testing attempts exploitation, tests segmentation, and reasons about paths a scanner cannot describe.
Presenting scan output where a penetration test is required is one of the more common findings, and it is easy for an assessor to spot: a scan report has no methodology statement, no exploitation narrative, and no segmentation validation. If your report cannot show an attempt, it is not a penetration test.
The reverse mistake also happens: teams commission an excellent annual penetration test and skip quarterly scanning because "we get tested". The clauses are cumulative.
Segmentation Is the Requirement People Underestimate
Most organisations reduce PCI scope by segmenting the cardholder data environment from everything else, which is sensible and dramatically cheaper than treating the whole estate as in-scope. The catch is that the segmentation becomes a control you must prove works — every 12 months, or every six if you are a service provider.
Testing it means attempting to reach the CDE from outside the segment: network paths, shared services, identity, jump hosts, cloud constructs like peering and shared load balancers. In cloud environments the segment boundary is usually a set of security groups, network policies and IAM roles rather than a firewall, and each of those is a place the isolation can quietly stop holding after a routine change.
This is also the clause where continuous testing earns its place: a segmentation boundary edited on Tuesday is a scope change, and finding out at the annual test means up to twelve months of exposure with a compliance problem attached.
Handling "After Significant Change"
Both penetration testing clauses attach to change as well as to the calendar, and the definition of significant is yours. A definition that is too broad creates testing obligations you cannot meet; too narrow, and an assessor will challenge it against your change log.
A defensible definition names categories rather than sizes: changes to authentication or authorisation, to the segmentation boundary, to payment flows or the systems that touch card data, to internet-facing exposure, and major platform migrations. Then keep the evidence that each such change was followed by a test.
For teams deploying continuously, the practical answer is automated testing on every deploy plus the annual engagement. It satisfies the spirit of the clause and produces the change-linked evidence an assessor asks for, which a once-a-year test cannot.
What Changed in 4.0 That Still Catches People
The payment page script requirements (6.4.3 and 11.6.1) became mandatory on 31 March 2025 and are the ones teams most often discover late. They require an inventory of every script on a payment page with written justification, plus a mechanism that detects unauthorised change to scripts and HTTP headers. If your checkout page loads third-party tags, this clause is about you.
The customised approach introduced in 4.0 lets you meet an objective differently from the stated control, with documented risk analysis and assessor agreement. It is genuinely useful for modern architectures and it is more work, not less: the burden of demonstrating equivalence sits with you.
Evidence
What to hand your auditor
- ✓ASV scan reports for each quarter, showing passing scans or documented remediation and rescans
- ✓Internal scan results at the same quarterly cadence
- ✓A documented penetration testing methodology covering internal, external and segmentation testing
- ✓Internal and external penetration test reports within the last 12 months
- ✓Segmentation test results (within 12 months, or six for service providers)
- ✓Retest evidence for every exploitable finding, per 11.4.4
- ✓Your written definition of "significant change", and the tests triggered by changes that met it
- ✓Payment page script inventory with justifications, and evidence of the tamper-detection mechanism
Avoid
What costs teams an audit cycle
- ✕Submitting scan output as penetration testing evidence — the absence of a methodology and exploitation narrative gives it away immediately.
- ✕Using a non-ASV vendor for external scanning. The scan can be excellent and still not satisfy 11.3.2.
- ✕Skipping segmentation testing while relying on segmentation to reduce scope, which is the most consequential version of this mistake.
- ✕Defining "significant change" so broadly that your own policy obliges more testing than you perform.
- ✕Treating retesting as optional. 11.4.4 requires it, so budget it rather than negotiating it later.
- ✕Discovering the 6.4.3 and 11.6.1 payment script requirements during the assessment rather than before it.
FAQ
PCI DSS testing questions
Produce the evidence continuously, not the week before the audit
Penetrify tests on every deploy from $100/month, with retests included — so the trail of what was found, fixed and verified builds itself.
Start free scan