PCI Compliant Checkout: Hosted, iFrame or API? Which SAQ
Hosted page, iFrame or API? See which SAQ each PCI compliant checkout option triggers, which scans and scripts you must cover, and how to choose
If you process, store, or transmit card data, you’ve almost certainly seen “external vulnerability scan” and “pen test” used in the same breath, in a compliance checklist, a QSA email, or a vendor’s sales pitch. The two get lumped together so often that many merchants assume they’re two names for the same thing, or that doing one automatically covers the other. Neither assumption is true, and the gap between them is exactly where compliance findings and real breaches tend to happen.
This guide breaks down what an external vulnerability scan and a pen test actually are, how each fits into PCI DSS v4.0.1, and how to build a testing program that satisfies your QSA without over-buying services you don’t need.
Run your site through Secusy's free PCI compliance checker before you read any further; it takes two minutes and tells you exactly which controls, including scanning, apply to your business.
External Vulnerability Scan: An automated, unauthenticated check of your internet-facing IP addresses that identifies and ranks known security weaknesses, outdated software, open ports, weak cyphers, and misconfigurations. It catalogues exposures but does not attempt to exploit them.
Pen Test (Penetration Test): An authorised, simulated attack in which a human tester actively tries to exploit discovered weaknesses, including ones inside your network, to determine what a real attacker could actually achieve.
ASV (Approved Scanning Vendor): An organisation certified by the PCI Security Standards Council to perform the external vulnerability scans required under PCI DSS Requirement 11.3.2. Only ASV-certified vendors can produce results that count as evidence of compliance.
Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit cardholder data, plus anything connected to it.
PCI DSS v4.0.1: The current version of the Payment Card Industry Data Security Standard, the global framework for protecting cardholder data.
No. An external vulnerability scan is an automated sweep of your public-facing IP addresses that stops at identifying known weaknesses; a pen test is a human-led exercise that actively tries to exploit those weaknesses, inside and outside your network, to prove what an attacker could actually do.
They get confused because they sit in the same neighborhood: both target your attack surface, both show up in the same PCI DSS section, and both produce a report that looks similar at a glance. But an external scan never crosses the line into exploitation. It runs unauthenticated, from the outside, and hands back a list of findings ranked by severity; typically scored with the Common Vulnerability Scoring System (CVSS).
A pen test starts where that list ends: a tester tries the door, and if it’s unlocked, walks through and sees how far they can get, often chaining a weak external finding with an internal misconfiguration to reach cardholder data.
Merchants often ask for a “pen test” when what they legally need is a scan or budget for a “scan” when their SAQ actually requires full penetration testing. Getting this distinction right the first time saves both money and compliance headaches later.
PCI DSS Requirement 11.3.2 mandates a quarterly external vulnerability scan of every internet-facing IP address in your cardholder data environment, and it must be performed by a PCI SSC-Approved Scanning Vendor to count as compliance evidence.
The scan targets everything reachable from the public internet: web servers, firewalls, load balancers, and DNS infrastructure, checking for outdated software versions, open ports, weak encryption, and known misconfigurations. It requires no privileged access to your systems, because it’s simulating exactly what an outsider on the open internet would see before deciding whether to attempt a breach.
This is separate from internal vulnerability scanning (Requirement 11.3.1), which covers systems behind your perimeter and can be run by qualified in-house staff or a trusted third party; no ASV certification is required there. Both external and internal scans are mandatory for merchants validating via SAQ B-IP, C, D, or a full RoC, and both must run at least quarterly, with a passing result required as evidence.
The quarterly cadence isn’t bureaucratic overkill. New vulnerabilities are disclosed daily, and a server that passed a scan in January can be exposed by a March patch cycle you missed. A once-a-year snapshot doesn’t reflect a moving threat landscape.
Secusy's free PCI compliance checker maps your business against the right validation path in minutes.
PCI DSS v4.0.1 Requirement 11.4 mandates penetration testing at least annually and after any significant change to your environment, covering both the external perimeter and the internal network, for merchants and service providers whose validation path requires it.
Where an external scan stays outside your network and stops at detection, a pen test goes everywhere the scope requires: external systems, internal segments, applications, and, critically, the segmentation controls you may be relying on to shrink your PCI DSS scope in the first place.
That segmentation piece deserves its own callout. If you’ve isolated your CDE behind network segmentation to reduce audit scope, PCI DSS v4.0.1 requires you to prove, via penetration testing, that the segmentation actually holds. A firewall rule that looks airtight on a network diagram can still leave a path from an out-of-scope zone straight into card data, and that’s precisely the failure a segmentation test is designed to catch and something an external scan alone would never find.
PCI DSS doesn’t mandate a single testing methodology, but it does require the methodology to be documented and the tester to be qualified. Frameworks like PTES or OWASP (for web applications) are commonly accepted baselines, and credentials like OSCP or CREST accreditation carry real weight with QSAs, even though they’re not formally required.
The two controls differ across every dimension that matters for planning, scope, method, frequency, who's allowed to perform them, and cost, and PCI DSS treats them as parallel, non-substitutable requirements.
Dimension | External Vulnerability Scan | Pen Test |
|---|---|---|
Scope | External-facing IPs only | Entire CDE; external, internal, segmentation |
Method | Automated, unauthenticated | Manual + automated, active exploitation |
Frequency | Quarterly | Annually, plus after significant changes |
Who performs it | Must be a PCI SSC-Approved ASV | Qualified internal staff or external firm |
Output | Pass/fail scan report | Detailed findings, attack paths, remediation |
Relative cost | Lower, automation-driven | Higher, skilled-labor-driven |
A passing external scan does not satisfy Requirement 11.4, and a clean pen test does not excuse a missed quarterly scan. QSAs review these as two separate line items, and treating one as a substitute for the other is one of the most common findings in a PCI DSS review.
Your obligations depend on your validation path; SAQ A and B merchants generally carry minimal or no pen testing burden but may still owe quarterly external scans, while SAQ C, SAQ D, and full RoC entities must satisfy both quarterly scanning and annual pen testing in full.
The determining factor isn’t your revenue or your industry; it’s whether any IP address in your environment is both publicly reachable and connected to cardholder data flows. If yes, the external scan requirement applies regardless of how small the business is. Pen testing obligations scale up from there, expanding to cover segmentation validation and internal network testing as your SAQ level rises.
A “significant change” that triggers a fresh pen test is interpreted broadly under v4.0.1, a major software update, a new payment channel, or an architectural change to your network can all qualify. Waiting for the annual cycle to roll around after a significant change is one of the more common gaps QSAs flag during review.
Start with a compliant, passing quarterly external vulnerability scan; the most universally applicable requirement and the one most often found deficient, then layer in pen testing scoped to your SAQ or RoC obligations.
For most SMB merchants, the practical sequence looks like this:
Both controls are achievable at SMB budgets, and treating either as optional creates compliance risk and security risk at the same time.
An external vulnerability scan and a pen test are complementary, non-substitutable PCI DSS controls. The external scan required quarterly under Requirement 11.3.2 and performed by an ASV, automatically identifies and ranks known weaknesses on internet-facing systems. The pen test required annually and after significant changes under Requirement 11.4 goes further, actively exploiting weaknesses across your entire cardholder data environment, including segmentation, to prove real-world impact. Merchants need both to satisfy PCI DSS v4.0.1 and to actually defend their payment environment, not just their audit trail.
No. A scan is automated and stops at identifying known weaknesses on public-facing systems; a pen test is human-led and actively tries to exploit those weaknesses, including inside your network.
It depends on your SAQ type, but most merchants beyond the smallest SAQ A/B tiers need both, quarterly external scanning is nearly universal, while pen testing applies more broadly as environment complexity increases.
No. PCI DSS treats them as separate, non-substitutable requirements, a passing pen test does not satisfy the quarterly scanning obligation, and vice versa.
It's part of the pen test; it verifies that network segmentation used to reduce PCI DSS scope actually prevents access from out-of-scope zones into your cardholder data environment. An external scan doesn't test this.
If any of your internet-facing IP addresses connect to cardholder data flows, the quarterly external scan requirement applies regardless of business size.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.