The scan is not the test. Neither one is the audit.

The scope finder needs JavaScript. The reference below carries everything it would tell you, unfiltered: every test line, every validation route, every piece of evidence and every scope note.

Test lines

• External vulnerability scan by an ASV. Automated external scanning by a company on the PCI SSC Approved Scanning Vendor list. PCI SSC states the requirement calls for evidence of passing external scans at least once every three months, and this applies to e-commerce pages that only redirect to a provider as well as to a full cardholder data environment.
• Internal vulnerability scan. Scanning inside the cardholder data environment on the same three-month clock, with what it finds resolved rather than merely listed. Where a provider runs the whole environment, its scanning covers those systems and its attestation becomes your evidence.
• External penetration test. Manual, adversarial testing of the internet-facing perimeter of the cardholder data environment. Requirement 11 is the area that covers regularly testing networks; the clause reference and the interval are in the part of the standard behind the licence gate.
• Internal penetration test. Testing from inside the network on the assumption that an attacker already has a foothold. It answers the question a scan cannot: what one compromised machine turns into.
• Segmentation test. Testing the boundary you rely on to keep systems out of scope. PCI SSC guidance is explicit that this is more than port scanning: it should test remote access mechanisms, administrator workstations and shared services networks.
• Remediation and retest. Fixing what was found and showing it was fixed. A scan period is passed only once the rescans pass, and a penetration-test finding with no dated retest is an open finding.
• Retest on significant change. Several requirements fire on significant change rather than on the calendar, and PCI SSC publishes the list of activities that count.

How you validate

• Top-tier merchant. At six million transactions and above you are Level 1 for Visa, Mastercard and Discover: an annual Report on Compliance and an Attestation of Compliance. American Express sets its Level 1 at 2.5 million of its own transactions, so that programme will treat you the same way.
• Second-tier merchant. Between one and six million, Visa and Mastercard both place you at Level 2: an annual Self-Assessment Questionnaire. Mastercard adds that a Level 2 merchant completing SAQ A, SAQ A-EP or SAQ D must additionally engage a QSA or a certified internal security assessor for validation.
• Lower-tier merchant. Below one million you fall into Visa Level 3, Mastercard Level 3 or 4 and Discover Level 3: an annual Self-Assessment Questionnaire, which some brands only require on request. Mastercard states that Level 4 merchants must comply with PCI DSS even though validation to Mastercard is not required.
• Merchant level not stated. The level comes from your annual transaction count with each brand separately, and the thresholds differ: six million for Visa, Mastercard and Discover, 2.5 million for American Express. Your acquirer holds the number and will tell you which document you file.
• Service provider, upper tier. Above 300,000 transactions a year, Visa and Discover both place a service provider at Level 1: an annual on-site assessment by a QSA and an Attestation of Compliance. Visa requires QSA validation before a provider can be listed on its Global Registry of Service Providers.
• Service provider, lower tier. Below 300,000 transactions, Visa accepts a signed SAQ D or an Attestation of Compliance with a QSA signature, and Discover accepts SAQ D for Service Providers. Mastercard draws the same 300,000 line for data storage entities and payment facilitators.
• Service provider level not stated. Volume is not the only trigger. Mastercard places every third-party processor, token service provider, payment gateway and 3-D Secure provider at Level 1 whatever the transaction count. Confirm the category with the brand or with the entity that accepts your compliance.

Evidence an assessor expects

• A written scope. What is inside the cardholder data environment, what connects to it, and why anything else is out. An assessor starts here, and a boundary that exists only in a diagram is the most common way a project loses a month.
• ASV scan reports on the official template, plus the Attestation of Scan Compliance. PCI SSC recognizes only its own forms: a vendor certificate is not evidence of anything.
• Passing scans across four consecutive quarters, external and internal, together with the rescans that brought each period to a pass.
• Internal scan remediation records. Requirement 11.3.1 is satisfied by resolving what the internal scan found, so the fix trail is the evidence rather than the scan output.
• The penetration test report and its retest. Scope traceable to your documented cardholder data environment, exploitation shown rather than asserted, and a separately dated retest for everything you fixed.
• Segmentation test evidence. Not a port scan summary: attempts against remote access, administrator workstations and shared services networks, with what happened to each of them.
• A recorded decision about segmentation. If you cannot say whether you are segmented, an assessor has to treat the whole network as in scope until you show otherwise.
• Your providers' Attestations of Compliance, covering the services they actually run for you and no more than twelve months old. A merchant SAQ A attestation handed over by a provider is not sufficient evidence of that provider's own compliance.
• An account data inventory. Where the primary account number is stored, in what form, and what deletes it. Storage is the decision that makes every other requirement harder.
• Evidence that sensitive authentication data is not retained after authorization. Every brand relief programme starts with this condition, and so does every forensic investigation.
• A change record you can hand over. Several requirements fire on significant change, so the list of changes is what shows whether they fired.

Where this leaves your scope

• Your scope depends on a boundary. That is the right answer commercially and it comes with an obligation: the boundary has to be demonstrated, not asserted.
• Everything connected is in scope. There is no segmentation test to run, and no reduction either. Costing a segmentation project against a full-estate assessment is usually the first thing worth doing.
• Scope is undecided, so assume the maximum. A scoping exercise is the cheapest engagement available and the only one that changes the price of all the others.
• You own the whole environment. Internal scanning, internal testing and the segmentation boundary are all yours to evidence, and nobody else's attestation covers them.
• Cloud moves the work, not the duty. The provider covers the layers it runs and attests to them; the configuration, identity model and network boundaries you built on top are yours. PCI SSC published guidance in September 2024 specifically on scoping micro-segmented and multi-cloud environments.
• Outsourcing changes the scope, not the obligation. American Express puts it plainly: outsourcing may change the scope of your assessment, but you are still required to complete and report an annual assessment once a year and, where applicable, external quarterly network scans every 90 days.
• A mixed estate needs a written split. Requirements 12.8 and 12.9 exist because the line between what you run and what a provider runs is exactly where evidence goes missing.
• Your redirect page is in scope for scanning. PCI SSC added external ASV scanning to SAQ A in v4.x for this case: the page you host is what an attacker modifies in order to reach a payment you never handle.
• Nothing ticked. If no account data is stored, transmitted, processed or redirected by anything you run, the real question is whether you are in scope at all, and that is a conversation with your acquirer.