PCI Compliance

PCI ASV Scanning vs. PCI Penetration Testing: Which Do You Need (and When Do You Need Both)?

• 8 min read
PCI ASV Scanning vs. PCI Penetration Testing: Which Do You Need (and When Do You Need Both)?

If you're working through PCI DSS for the first time, the testing requirements can look like overlapping checkboxes. Two separate controls. Two different vendors. Two budget line items. The natural question is whether you actually need both, or whether one can do the job of the other.

PCI ASV scanning vs. penetration testing isn't really a choice. They're two different controls under PCI DSS v4.0.1, answering two different questions about your security posture. ASV scanning is required for most merchants. Penetration testing is required for a specific subset, depending on which Self-Assessment Questionnaire (SAQ) applies to your environment, or whether you validate via Report on Compliance (RoC). And even when pentesting isn't formally required, it's a strong security practice that we recommend for any merchant handling payment data.

This post breaks down what each control does, who has to perform it, when it's required, and how to plan them so they reinforce each other instead of duplicating effort.

The Short Answer: They Solve Different Problems

ASV scans are about breadth. They run automatically, every quarter, against everything you have exposed to the internet. Their job is to flag known vulnerabilities that an attacker scanning the open web could find without much effort. Think of them as the regular check-up: frequent, broad, surface-level.

Penetration tests are about depth. They run at least annually, and they involve a human attacker trying to actually exploit your environment. Their job is to find the things automation can't, like business logic flaws, chained vulnerabilities, and authentication weaknesses that need a person to recognize.

Neither one substitutes for the other. PCI DSS v4.0.1 puts them in separate requirements (11.3.2 for ASV scanning, 11.4 for penetration testing) precisely because they answer different questions.

What Is an ASV Scan?

An ASV scan is an external vulnerability scan performed by a company that the PCI Security Standards Council has formally certified as an Approved Scanning Vendor. Only ASVs can issue the attestations your acquirer or QSA needs to confirm compliance with Requirement 11.3.2.

Cadence: At least once every three months, plus after any significant change to your external environment (new infrastructure, firewall changes, network topology shifts).

Scope: Externally facing IP addresses, domains, and web applications reachable from the internet. ASV scans don't cover internal networks. That's a separate control under Requirement 11.3.1.

  • What "passing" means: Per the ASV Program Guide, every vulnerability scored CVSS 4.0 or higher must be remediated, and any "automatic fail" conditions must be resolved. If a scan fails, you remediate and rescan within the same quarter until you achieve a passing result.
  • Who can perform it: Only a vendor on the PCI SSC's official ASV list. A capable scanner is not the same thing as an ASV. Tools like Nessus or OpenVAS are legitimate vulnerability scanners, but they can't issue PCI-compliant attestations. If you're evaluating providers, our guide on how to choose a PCI ASV walks through what to ask before signing.
  • What it doesn't do: No exploitation. No business logic testing. No internal network coverage. No segmentation validation. ASV scans are a snapshot of known external vulnerabilities, not a full security assessment.

What Is a PCI Penetration Test?

A PCI penetration test is a manual, methodology-driven assessment where a qualified tester actively attempts to exploit weaknesses in your environment. Unlike an ASV scan, the goal isn't to identify vulnerabilities, it's to demonstrate what an attacker could actually do with them.

  • Cadence: At least once every 12 months, and after any significant infrastructure or application upgrade or change
  • Scope: Both external and internal perspectives. PCI DSS Requirement 11.4 explicitly requires testing at the network layer and the application layer, covering the entire cardholder data environment (CDE) perimeter and critical systems. If you use segmentation to reduce PCI scope, segmentation testing is a separate sub-requirement (11.4.5 for merchants annually, 11.4.6 for service providers every six months).
  • Methodology: Requirement 11.4.1 requires a defined methodology based on industry-accepted approaches such as NIST SP 800-115. The PCI SSC publishes a Penetration Testing Guidance Information Supplement that expands on this.
  • Who can perform it: A qualified internal resource with organizational independence (meaning the tester can't be the same person who configures or manages the systems being tested) or a qualified external third party. The tester does not need to be a QSA or an ASV.
  • What it produces: A methodology-based report documenting findings, exploitation evidence, and remediation guidance. Critical findings must be remediated and the test repeated to verify the corrections (Requirement 11.4.4).

If you're scoping a PCI engagement, our compliance penetration testing overview covers what a complete PCI-aligned pentest includes.

ASV Scanning vs. Penetration Testing at a Glance

Dimension

ASV Scan (Req. 11.3.2)

Penetration Test (Req. 11.4)

Cadence

Every quarter, plus after significant change

Every 12 months, plus after significant change

Performed by

PCI SSC Approved Scanning Vendor only

Qualified internal or external tester with organizational independence

Scope

External-facing IPs, domains, web apps

External + internal network and application layers; full CDE perimeter

Method

Automated scanning

Manual, methodology-driven (e.g., NIST SP 800-115)

What it proves

Known vulnerabilities are identified and remediated

Vulnerabilities cannot be chained or exploited to compromise the CDE

Output

ASV attestation suitable for acquirer/QSA

Methodology-based report with exploitation findings and validated remediation

When Do You Need Both?

Whether you need both controls depends on how your organization validates PCI DSS compliance. The two main paths are a Report on Compliance (RoC), conducted by a QSA, or a Self-Assessment Questionnaire (SAQ).

Report on Compliance. Level 1 merchants (more than 6 million transactions per year) and most service providers validate via RoC. RoC validation covers the full PCI DSS standard, which means both ASV scanning and penetration testing are required.

Self-Assessment Questionnaire. Levels 2 through 4 typically validate via SAQ. There are 10 SAQs under PCI DSS v4.0.1, and they don't all carry the same testing obligations. Pentest requirements in particular vary significantly.

Here's how it breaks down:

SAQ

Who it's for

ASV scan required?

Pentest required?

SAQ A

E-commerce/MOTO merchants who fully outsource cardholder data handling

Yes (when redirect/iframe applies)*

No

SAQ A-EP

E-commerce merchants whose website affects payment security but doesn't receive card data

Yes

Yes

SAQ B

Merchants using imprint machines or standalone dial-out terminals

No

No

SAQ B-IP

Merchants using standalone IP-connected payment terminals

Yes

No (segmentation testing only)

SAQ C

Merchants with payment applications connected to the internet, no electronic CHD storage

Yes

No (segmentation testing only)

SAQ C-VT

Merchants using a virtual terminal on an isolated device

No

No

SAQ P2PE

Merchants using PCI-validated point-to-point encryption solutions

No

No

SAQ SPoC

Merchants using PCI-validated software-based PIN entry on COTS devices

No

No

SAQ D Merchant

Catch-all for merchants who don't fit other SAQs

Yes

Yes

SAQ D Service Provider

Service providers eligible to self-assess

Yes

Yes

* Under PCI DSS v4.0, SAQ A merchants whose websites redirect to or embed third-party payment forms must run quarterly ASV scans. This took effect April 1, 2025.

The short version: Pentesting is formally required if you validate via RoC, SAQ A-EP, SAQ D Merchant, or SAQ D Service Provider.

The SAQ table above tells you what's required. It doesn't tell you what's prudent.

A merchant on SAQ B-IP isn't off the hook for security just because their attestation doesn't ask for a pentest. Compliance defines a floor. Pentesting helps you understand what an actual attacker could do with your environment, including business logic flaws, authentication weaknesses, and segmentation gaps that automated scanning will never surface. We recommend pentesting for any merchant handling payment data, regardless of which SAQ you complete. If you've ever been through breach response, you already know that the questions an investigator asks are not the same questions on a self-assessment questionnaire.

If you're not sure which SAQ applies to you, that's the conversation to have with your QSA or acquirer before scoping any testing.

How to Sequence Them So They Reinforce Each Other

A workflow we've seen work well:

  1. Get continuous external visibility in place first.Before you schedule any formal scan or pentest, make sure you actually know what's on your external attack surface. Forgotten subdomains, cloud assets spun up outside the security team's view, and IP ranges acquired through M&A are the most common reasons ASV reports come back incomplete. Ongoing external vulnerability management (https://www.halosecurity.com/external-vulnerability-management) helps make sure your quarterly scan window isn't the first time you're discovering an asset.
  2. Run your ASV scan and remediate.Clear automated findings before pentesters arrive. You don't want a skilled tester spending billable hours documenting CVEs that automation could have caught. The cleaner your ASV results, the more time pentesters can spend on the work tools can't do.
  3. Then run the pentest.With known vulnerabilities resolved, pentesters can focus on business logic flaws, chained attacks, authentication weaknesses, and segmentation validation. That's where the real value is.

This sequencing also makes budgets go further. Our guide on planning your next penetration test covers the same principle in more detail.

Common Misconceptions That Cause Compliance Gaps

A few patterns we see often:

  • Our ASV scan covers our pentest requirement.It doesn't. They're different requirements under PCI DSS, and a QSA will ask for both when both apply.
  • ASV scans cover internal vulnerabilities.They don't. ASV scans are external only. Internal scanning is a separate control under Requirement 11.3.1.
  • We just had a pentest, so we can skip this quarter's ASV scan.Cadence is independent. Quarterly is quarterly.
  • We're SAQ A so we don't need anything.Under v4.0.1, SAQ A merchants who redirect or embed third-party payment forms now have ASV scan obligations.
  • Any vulnerability scanner will satisfy 11.3.2.Only a vendor on the PCI SSC's ASV list can issue PCI-compliant attestations.

Frequently Asked Questions

Does an ASV scan count as a penetration test?

No. ASV scans are automated external vulnerability assessments. Penetration tests are manual, adversarial assessments performed against the methodology requirements in PCI DSS Requirement 11.4. PCI DSS treats them as separate controls (Requirement 11.3.2 for ASV scans, Requirement 11.4 for pentests), and a QSA will expect evidence of both when both apply.

Which SAQs require penetration testing?

Pentesting is required for merchants who validate via SAQ A-EP, SAQ D Merchant, or SAQ D Service Provider, as well as any organization validating via Report on Compliance (which includes Level 1 merchants and most service providers). It's not formally required for SAQ A, B, B-IP, C, C-VT, P2PE, or SPoC, though it remains a strong security practice regardless of attestation type.

Can the same vendor do both my ASV scanning and my pentest?

Yes, and there are advantages to consolidating. A single vendor that handles both can correlate findings between the two, reducing duplicate reporting and simplifying remediation. The pentester does not need to be a QSA or an ASV, but the ASV scan must be performed by a vendor on the PCI SSC's official ASV list. Halo Security operates as TrustedSite, LLC on that list (certificate 5078-01-11) and provides both services.

What counts as a "significant change" that triggers a re-test?

PCI DSS doesn't publish an exhaustive list, but common triggers include new infrastructure (servers, firewalls, cloud environments), changes to network topology or segmentation, major application upgrades, changes to how cardholder data is stored or transmitted, and any modification that alters the scope of your CDE. When in doubt, treat the change as significant and document the rationale.

What happens if we fail an ASV scan?

You remediate the failing findings and run a rescan. The passing rescan must be completed within the same quarter as the original failed scan. Disputes over false positives are handled directly between you and your ASV per the ASV Program Guide; they aren't escalated to the PCI SSC.

Plan Your PCI Testing With Confidence

PCI DSS v4.0.1 makes the testing landscape clearer, but it also raises the bar. Quarterly ASV scans, authenticated internal scans, annual pentests where required, segmentation testing, and tamper-detection on payment pages are all now part of the same compliance picture.

The teams that handle this well plan both controls together rather than running them as separate compliance exercises. Consolidate where it makes sense, sequence the work so each control reinforces the other, and treat your ASV and pentest reports as inputs to the same security program.

If you'd like to talk through your specific testing requirements, our PCI compliance team is happy to help.