PCI ASV scan vs penetration testing

PCI ASV scan vs penetration testing: which one your PCI DSS program needs

A passing quarterly ASV scan does not close your penetration testing obligation. The Approved Scanning Vendor scan supports requirement 11.3.2, which covers external vulnerability scanning on a quarterly cadence. The penetration test supports requirement 11.4, which requires internal and external tests at least every 12 months and after significant changes. Each activity answers a different question, so a team with a clean scan still needs the penetration test on its own schedule. Confirm with your Qualified Security Assessor which systems form your cardholder data environment and which tests and scans they expect to see as evidence.

Choose the ASV scan as the primary activity for the recurring external check, when you need an independent, vendor-validated record that the internet-facing footprint was scanned each quarter. Choose the penetration test as the primary activity when the question is whether a weakness can be exploited. PCI SSC's Penetration Testing Guidance v1.1 describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the penetration testing requirement. A scan typically finishes in seconds to minutes per host, while a penetration test may take days or weeks depending on scope.

Combine both in one program when you want the scan to inform the test. Run the ASV scan each quarter, schedule the penetration test annually and after significant changes such as new payment flows or segmentation changes, and use scan results to sharpen test scope. Under requirement 11.4.4, exploitable findings must be corrected according to your risk ranking and the test repeated to verify the fixes. Ask your tester to show how its methodology covers the elements of requirement 11.4.1, including application-layer and network-layer testing and segmentation validation. PCI SSC's list of Approved Scanning Vendors is the place to confirm vendor status before you sign.

How an ASV scan and a penetration test differ on PCI DSS

This table compares the quarterly ASV external scan with the annual penetration test across the PCI DSS requirements, method, duration, scope and retest steps they involve. Read each row as a question an assessor will ask, and note that the two activities answer different questions, so neither can stand in for the other.

Factor	ASV external scan	Penetration test
PCI DSS requirement satisfied	Requirement 11.3.2 for external vulnerability scans, validated by an Approved Scanning Vendor	Requirement 11.4.1 for the penetration testing methodology, with 11.4.2 and 11.4.3 for internal and external tests, and 11.4.4 for correction and retesting
Required frequency	At least once every three months (requirements 11.3.1 and 11.3.2)	At least every 12 months and after significant changes (requirements 11.4.2 and 11.4.3)
Who may perform it	An organization on the PCI SSC Approved Scanning Vendor list, using its own tools and services	A qualified tester using a documented methodology; PCI SSC guidance treats it as essentially a manual process, so confirm tester qualifications and independence with the assessor
Method	Mostly automated identification and ranking of vulnerabilities from outside the network	Manual exploitation of vulnerabilities, with automated tools used to support the work, not to replace it
Typical duration per PCI SSC guidance	Seconds to minutes per host	May last days or weeks depending on scope
Scope	External scanning requirements of 11.3.2 for the internet-facing systems in scope	Entire CDE perimeter and critical systems, tested from inside and outside the network, including segmentation validation and application-layer and network-layer testing
Retesting	A rescan after remediation is part of the quarterly cycle, validated by the ASV	Exploitable findings must be corrected by risk ranking and the test repeated to verify the fix (requirement 11.4.4)
Output an assessor expects	ASV scan report showing the results of the external scan	Report showing methodology, coverage, exploited findings, segmentation results and retest evidence
What a passing result proves	External scan results met the ASV validation for the period scanned	Coverage and exploitability were tested against the stated methodology; a passing scan does not establish this

Which PCI DSS requirement each activity satisfies

An ASV scan is a vulnerability scan run by a PCI SSC Approved Scanning Vendor against your external network. Under PCI DSS, the external scanning requirements are 11.3.1 and 11.3.2, which call for internal and external vulnerability scans at least once every three months. The ASV's role is to validate that the external scan meets the standard's expectations for requirement 11.3.2. Its output shows what automated checks found at the perimeter on the day of the scan. It does not show whether an attacker could chain those weaknesses into access to the cardholder data environment.

Requirement coverage: A passing ASV scan supports requirement 11.3.2 for external scanning. It does not satisfy the penetration testing requirements in 11.4.
Frequency: Scans recur at least quarterly, and rescans are needed after changes that affect exposure. Confirm the rescan rules with your ASV and your assessor.
Automation: The work is largely automated, which is why an ASV scan finishes quickly compared with a manual test.
Scope: The scan covers the external footprint the ASV is given. Missing hosts in the scope list mean missing findings, so reconcile the list against your asset inventory.
Remediation: Findings still need correction and a rescan to confirm the fix, but the ASV process does not replace manual exploitation of the findings.

Before relying on an ASV report, confirm with your assessor which scope and dates they will accept as evidence for requirement 11.3.2.

What an ASV scan finds and misses versus what a penetration test proves

An ASV scan and a penetration test answer different questions. The scan checks whether known weaknesses are visible from outside, while the penetration test checks whether a tester can chain weaknesses into real access to the cardholder data environment. The cards below show where each method stops and what a QSA or buyer should confirm before treating one as proof for the other.

Known vulnerabilities at scale

An ASV scan matches externally visible services and versions against known vulnerability signatures across many hosts in a short window. This is the work PCI SSC describes as mostly automated, and it is what the quarterly external scan under requirement 11.3.2 is for. The limitation matters when the estate is large or changes often, because a scan only reflects the moment it ran. Check that the ASV's scope covers every public IP and that rescans follow significant changes.

Logic flaws and chained exploitation

Automated scans rarely find flaws such as broken authorization, abusable workflows or a low-severity misconfiguration that becomes critical when combined with another. A penetration test follows the chain manually, which is the mainly manual exploitation PCI SSC's guidance describes. This matters most for payment flows, admin consoles and multi-role applications. Ask the tester to show each exploit path and the business impact, not just a list of findings.

Segmentation and application gaps

Requirement 11.4.1 expects a documented methodology that covers the CDE perimeter, critical systems, testing from inside and outside the network, segmentation validation, and both application and network layers. An external ASV scan does not test these paths from an insider position or inside a flat internal network. This gap matters when out-of-scope networks can reach the CDE. Confirm the test plan names each segmentation control and each application in scope.

Exploitable findings and retesting

Requirement 11.4.4 requires exploitable vulnerabilities found in a penetration test to be corrected according to the entity's risk ranking and the testing repeated to verify the fix. A passing ASV scan does not show that an exploit was closed, because the scan may not reproduce the original attack path. This matters whenever a penetration test has findings. Agree the retest scope and evidence format in the statement of work before the first test runs.

Why a passing ASV scan never replaces requirement 11.4

A passing ASV scan does not satisfy requirement 11.4, and the reason is in how PCI SSC defines the two activities. An Approved Scanning Vendor validates adherence with the external scanning requirement, 11.3.2, by running automated checks against your external addresses. PCI SSC's Penetration Testing Guidance states that simply running an automated tool does not satisfy the penetration testing requirement. Penetration testing is essentially a manual process that exploits vulnerabilities and may last days or weeks depending on scope, while a scan typically completes in seconds to minutes per host. Before your next cycle, ask the assessor to show in writing which of your tests were manual exploitation, not just tool output.

Requirement 11.4.1 asks for things a scan cannot produce on its own. You need a documented penetration testing methodology using industry-accepted approaches, coverage of the entire cardholder data environment perimeter and critical systems, testing from both inside and outside the network, segmentation validation, and testing at both the application layer and the network layer. An ASV scan covers only external addresses and does not document a methodology, test from inside the network, or check whether segmentation controls actually stop traffic between your cardholder data environment and out-of-scope networks. Confirm with your QSA or internal assessor which of these elements each report must contain, and check that your methodology names the tools and techniques used.

The scan still earns its place. Quarterly external scans under 11.3.2 catch newly exposed services, misconfigurations and missing patches between the annual penetration tests, which is the ongoing exposure detection that a once-a-year exercise cannot provide. Treat a clean ASV result as evidence that the external perimeter has no known automated findings on that date, and keep the penetration test as the separate proof that exploitable paths were examined and that corrections under 11.4.4 were retested. A team that reports a passing scan as its penetration test will fail the assessment, so put the two activities in separate calendar entries, separate statements of work and separate evidence folders.

How to combine quarterly scans and annual penetration tests

This sequence shows how an ASV scan, an annual penetration test and the remediation cycle fit together so each produces evidence the other cannot. Each step closes with an output you can hand to your QSA or acquirer.

Confirm scope and the cardholder data environment
Before any test runs, document the cardholder data environment (CDE), its perimeter and the systems that connect to it, including the in-scope external IP addresses and hostnames. Your QSA or acquirer should confirm that this scope matches what your assessment covers, because the ASV scan and the penetration test must both reach the same boundary. The output is a signed scope document that both the scanning vendor and the penetration tester work from.
Run the quarterly external ASV scan
An Approved Scanning Vendor runs the external vulnerability scan against the in-scope external addresses at least once every three months, as required by requirements 11.3.2 and the internal scan counterpart 11.3.1. The ASV scan validates the external scanning requirement, and it is mostly automated, so it finds known weaknesses quickly but does not prove that any of them can be exploited. The output is a scan report and, when it passes, a compliance status for the scan period.
Schedule the penetration test at the annual interval
Book the internal and external penetration test so it occurs at least every 12 months, and also after any significant change to infrastructure or applications, as set out in requirements 11.4.2 and 11.4.3. Ask your QSA or acquirer which changes they treat as significant and whether a change triggers a test before the annual date. The output is a dated test plan that names the methodology and the tester.
Perform manual exploitation and segmentation checks
A qualified tester performs a manual penetration test using a documented methodology that covers the entire CDE perimeter, critical systems, testing from inside and outside the network, segmentation validation, and both application-layer and network-layer testing under requirement 11.4.1. Automated tools may assist, but PCI SSC's guidance says simply running an automated tool does not satisfy the requirement. The output is a report that records each exploited path, its impact and the evidence that supports it.
Triage findings by the entity's risk ranking
Combine the ASV scan findings with the penetration test findings in one register, then rank each exploitable vulnerability using your own documented risk ranking. Requirement 11.4.4 requires corrections to follow that ranking, so record the rationale for each priority and the owner responsible for the fix. The output is a prioritized remediation plan that your QSA can trace back to each finding.
Correct exploitable vulnerabilities
Remediate the exploitable vulnerabilities in the order set by the risk ranking, applying patches, configuration changes or compensating controls where a fix is not yet possible. Track each change in your change management system so that you can show when and how each issue was closed. The output is a remediation record linking each finding to a change and a closure date.
Repeat testing to verify corrections
Retest the corrected findings to confirm the exploit no longer works, as requirement 11.4.4 requires, and document the result for each item. A passing ASV scan alone does not verify this, because the scan cannot confirm that a manually exploited path is closed. The output is a retest report that your QSA reviews alongside the original penetration test and the quarterly scan results.
Confirm evidence requirements with your QSA or acquirer
Before the next cycle, ask your QSA or acquirer which scan and test reports they will accept, who must perform the ASV scan and penetration test, how they want the retest evidence packaged, and whether any reporting format or timing applies to your merchant or service provider level. Record their answers in writing, because the exact evidence expected can differ between assessments. The output is a written confirmation that becomes the template for the next cycle.

What drives the cost and effort of each activity

An ASV scan and a penetration test answer different questions, so they cost and take effort in different ways. The cards below separate the drivers for each activity. No prices are given here, and the written scope is what turns these drivers into a quote.

External IP count and scan scope

An ASV scan is priced and timed around the external addresses and hosts in scope for the quarterly scan. The more internet-facing addresses you own, the more the scan and its review cover. Before you ask for a quote, confirm with your ASV which addresses are in scope, how the scope is recorded, and whether scope changes between quarters are billed separately. Keep your external inventory current so the scope you contract for matches what is actually exposed.

Rescans after remediation

Failed external scan items must be fixed and then rescanned until the scan passes, so remediation can add recurring rescan effort between quarters. Ask the ASV whether rescans are included in the quarterly fee, how many are allowed, and how long a rescan takes to schedule. Your team's effort is driven by how quickly fixes are made and how many findings come back. Assign an owner for each finding before the scan window opens.

CDE perimeter and critical systems

A penetration test must cover the entire cardholder data environment perimeter and critical systems, so the size of that perimeter is the main cost driver. A larger CDE, more connected systems and more segmentation boundaries mean more hosts to map, more attack paths to test and more time to report. Ask the tester to state in writing which systems, networks and data flows are included and which are excluded, and why.

Application roles and authenticated access

Each application role, such as customer, merchant administrator or support agent, can expose different functions and data, and each role typically needs its own testing time. Testers also need valid accounts to test authenticated paths. Ask the provider how many roles will be tested, how test accounts are provisioned and removed, and whether role-based access checks are part of the quoted scope.

Internal and external viewpoints

PCI DSS requires testing from inside and outside the network, so each viewpoint adds its own setup, access and reporting work. An external test starts from the internet, while an internal test needs network access, credentials or an agreed starting point. Confirm whether both viewpoints are quoted separately or as one engagement, and whether segmentation validation is included in the internal work.

Methodology documentation and retesting

Testers must follow a documented methodology, and exploitable findings must be corrected and then retested to verify the fix. Retest effort depends on how many findings are exploitable and how much of the original test must be repeated. Ask whether a retest is included in the quote, what happens if a fix is incomplete, and whether the methodology documentation is delivered as part of the report. Ask the provider to show the methodology before work starts.

What you receive from each engagement

This table sets the deliverables of a quarterly ASV scan against those of an annual penetration test, so you can see what evidence each produces before you buy. Read it as a checklist: confirm in writing before work starts which items each provider will actually include in its report.

Deliverable	ASV external scan	Penetration test
Primary output	Scan report validated by an Approved Scanning Vendor for the external scanning requirement	Methodology-based report of scope, testing performed, findings and exploitation evidence
Scope definition	External, internet-facing addresses in scope for the scan	Defined targets covering the cardholder data environment perimeter and critical systems, agreed in a written scope
Evidence of exploitation	Vulnerabilities identified and ranked, generally without manual exploitation	Findings include proof of exploitation where a vulnerability was confirmed, as PCI SSC guidance describes a manual process
Methodology documentation	Scanning tool and ASV process, not a tester-driven methodology	Documented penetration testing methodology using industry-accepted approaches, which you should ask the provider to name
Segmentation validation	Not applicable	Included when segmentation controls are in scope, so the report must show whether out-of-scope networks can reach the cardholder data environment
Retest results	Rescan evidence showing that flagged issues were resolved, if the ASV supports a rescan	Retest of exploitable findings after correction to confirm the fix, as the requirement on correcting and repeating tests describes
Format and detail	Standardized ASV report format	Format set by the provider, so confirm the level of technical detail, screenshots and reproduction steps before signing
Who signs off	ASV organization validates the scan result	Testing firm and named testers, so confirm their qualifications and independence in writing

Questions buyers ask about PCI ASV scans and penetration tests

Can a quarterly ASV scan replace the annual penetration test?

No. An ASV scan validates adherence with the external scanning requirement, 11.3.2, and it runs at least once every three months. Penetration testing is a separate requirement, 11.4, that runs at least every 12 months and after significant changes. PCI SSC's Penetration Testing Guidance describes penetration testing as essentially a manual process that exploits vulnerabilities, while a scan mainly identifies and ranks them with automated tools. A clean scan shows that known issues were not detected by the tool. It does not show that an attacker could not chain weaknesses, bypass controls or reach the cardholder data environment. Both tests belong in your annual plan.

What drives the cost of a PCI penetration test?

The price follows the written scope, so ask for the scope before comparing numbers. The main drivers are the size of the cardholder data environment and its perimeter, how many applications and user roles need testing, whether both internal and external testing are included, whether segmentation validation is part of the work, and how many retest rounds are planned. Fees are paid to the tester for tester time, and a quote should list each of those items separately. Ask whether retesting after corrections is included, since requirement 11.4.4 requires the testing to be repeated to verify fixes. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a PCI penetration test take?

Duration depends on scope. PCI SSC's Penetration Testing Guidance says a penetration test is a mainly manual process that may last days or weeks depending on scope, while an automated vulnerability scan takes seconds to minutes per host. The biggest schedule factors are the number of applications and roles, the amount of environment preparation, how quickly test accounts and access are provided, and how many findings need validation. Scheduling the test with the annual cycle and any significant change window also affects calendar time. Ask the provider for a timeline in the written scope, and confirm when the report and the retest are due.

What must our team provide before a penetration test starts?

Provide a defined scope, test accounts and current architecture records. Write down which systems make up the cardholder data environment and its perimeter, which network segments are meant to be out of scope, and which applications and user roles the tester must cover. Requirement 11.4.1 expects a documented methodology and coverage of the CDE perimeter, critical systems, both internal and external testing, and application and network layers. Supply test accounts for each role you want exercised, and keep them isolated and time-limited. Share change records from the last 12 months so the tester knows what has moved since the previous test, and agree on a rules of engagement document before testing begins.

Can our internal staff run the penetration test under PCI guidance?

Possibly, but the test must meet PCI requirements, and the guidance is clear that running a tool does not count. PCI SSC's Penetration Testing Guidance v1.1 describes the work as essentially manual, so internal staff need the skills to exploit and validate findings, a documented methodology, and independence from the systems they administer. Ask your assessor how they will treat an internal team's work before you commit, because the assessor decides whether the evidence is acceptable. Many organizations use an external provider for the annual test to meet the independence expectation and to produce evidence the assessor can rely on. Confirm the assessor's position in writing.

How does retesting work after we fix exploitable findings?

Retesting verifies that corrections worked. Under requirement 11.4.4, exploitable vulnerabilities found in a penetration test must be corrected according to your risk ranking, and the testing must be repeated to confirm the fixes. Your remediation plan should assign each finding an owner and a target date based on its risk rank. The tester then re-exercises the affected paths and records whether each issue is closed, partly closed or still exploitable. Ask whether retest rounds are included in the fixed scope or billed separately, and confirm how retest evidence will be filed for your assessor. Keep the original report, the remediation records and the retest report together.

Do we need a penetration test after a significant change?

Yes. PCI DSS requires internal and external penetration tests after significant changes, in addition to the annual test, under requirements 11.4.2 and 11.4.3. A significant change could be a new payment application, a changed network segmentation design, a new cloud region or a major infrastructure upgrade. Your change management process should flag these events and route them to the security owner for a test decision. Ask your assessor to confirm which changes count as significant in your environment, since the definition depends on your architecture and risk. Record the decision and its reasoning, whether or not a test was run.

How DeployOpen scopes and supports PCI testing work

DeployOpen plans, runs and documents security testing and prepares the evidence a compliance assessment will ask for, but it does not issue audit reports or certifications. For PCI work, the quarterly external scan under requirements 11.3.1 and 11.3.2 must come from an Approved Scanning Vendor, and the penetration test under requirement 11.4 is a separate deliverable that the entity's assessor reviews. A PCI Qualified Security Assessor or the relevant assessor makes the compliance determination. Before engaging any provider, confirm with your assessor which artifacts they expect, such as the documented penetration testing methodology, scope definition, segmentation evidence and retest records.

Most engagements are fixed-scope, so the written agreement is where the boundaries of the work are set. For a PCI penetration test, the scope should name the cardholder data environment perimeter, the critical systems, the internal and external viewpoints, the application and network layers, and any segmentation checks the entity needs. Ask for the list of deliverables, the testing dates, the access and test accounts you will provide, and how exploitable findings will be handed back for correction under requirement 11.4.4. A quote follows from that written scope, so a change to the systems in scope will change the quote and should be recorded as a change to the agreement.

Retesting after remediation is a separate decision. Requirement 11.4.4 requires the test to be repeated to verify corrections, so plan a retest window into the original scope or add it through an optional retainer. Ongoing retainers can also cover periodic retesting, upgrades and continuous testing between annual penetration tests, which does not replace the annual requirement. Confirm with your assessor whether any retainer work will be presented as evidence for the assessment period, and ask for the retest records in the format your assessor expects.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, tests and documents self-hosted open-source platforms inside the client's own infrastructure. For PCI ASV scan vs penetration testing work, we agree a written scope that separates what the quarterly ASV scan covers from what the annual penetration test must cover, so each activity has a named owner and evidence.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which in-scope systems, network segments and application roles the penetration test covers, from inside and outside the network.
We confirm which activities the approved scanning vendor performs and which the penetration tester performs, so neither is assumed to cover the other.

How we build

We document a penetration testing methodology that follows industry-accepted approaches and records how each in-scope system was tested.
Testing combines tester-driven exploitation with automated tooling, and we record where manual validation confirmed or ruled out each finding.
Where segmentation is in scope, we plan validation of the boundary between the cardholder data environment and out-of-scope networks as part of the written scope.

How we hand over

Deliverables include a written report of exploitable findings, the steps used to validate them and the risk ranking proposed for remediation.
We plan a retest of corrected findings so the client holds evidence that fixes were verified, which the assessor will ask to see.
We confirm with your assessor, before testing starts, which report format and evidence they expect for the penetration test and ASV scan.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which can cover the annual test cycle between engagements.
We can help you prepare systems, controls and evidence for your compliance assessment, but independent assessors make the compliance determination.
Ask any provider, including us, to confirm in the quote who is paid for scanning, testing, retesting and evidence preparation, and which items recur each year.

PCI ASV scan vs penetration testing