PCI DSS 11.3.2: what ASV scanning requires

PCI DSS requirement 11.3.2 asks for external vulnerability scans of your in-scope perimeter at least once every three months, performed by a PCI SSC Approved Scanning Vendor, with a passing result. Three constraints, and each one trips people up differently.

The three constraints, plainly

Every three months. This is a floor, not a cadence recommendation. A quarter is roughly ninety days in which a security group can be widened, a service can be published, and a certificate can lapse — all of which will be true at the scan and none of which were true when the last one passed.

By an ASV. The scan has to come from a vendor the PCI Security Standards Council has approved and listed. Your own scanner, however good, does not satisfy 11.3.2 — the requirement is about who attests, not only about what was found.

With a passing result. Under the ASV Program Guide, a single vulnerability scoring 4.0 or higher on CVSS fails the entire scan. Not the finding. The scan. You remediate and rescan until the report comes back clean, and the passing report is the artefact your assessor wants.

There is also 11.3.2.1: an external scan after any significant change, with all vulnerabilities scoring 4.0 or above resolved. "Significant change" is your organisation's definition, documented in advance — which in practice means you should decide what counts before an assessor asks you to.

Why the quarterly floor is the wrong operating cadence

A passing quarterly ASV scan is evidence about one day. If a scan passes on the first of the month and a rule is widened on the fifth, you hold a valid, current, passing report describing infrastructure that no longer exists that way. Nothing about that is fraudulent, and nothing about it is protective either.

That gap is the same one an annual pentest leaves, compressed from twelve months to three. Shorter, still long enough for the failure modes that matter: a debug rule nobody removed, a container publishing a port past the host firewall, a service bound to 0.0.0.0 by a package default.

The practical answer is two scanning cadences with different jobs. The ASV scan is compliance evidence on the required schedule. Continuous or weekly scanning of the same perimeter is the operational control that tells you about a change in days rather than in months — and it is what makes the quarterly scan a formality instead of a surprise.

What to have ready before the scan

• A defensible scope. Every internet-facing IP and domain in the cardholder data environment, plus anything that could affect its security. An ASV scan against an incomplete list produces a passing report about the wrong systems.
• A current inventory. The most common failure is not a vulnerability, it is an asset nobody listed.
• Somewhere to put remediation. A rescan loop against a CVSS 4.0 floor is a lot of small fixes; tracking them in the scan report itself does not survive the second quarter.
• Your significant-change definition, written down, so 11.3.2.1 does not get interpreted for you during an assessment.

Where CyberSpec fits, and where it does not

CyberSpec is not a PCI SSC Approved Scanning Vendor, and a CyberSpec scan does not satisfy requirement 11.3.2. It is the other cadence: scheduled external scanning that tracks the open-port and finding set per asset over time, so exposure that would fail your next ASV scan shows up as a change now rather than as a fail later. Findings map to the PCI DSS control families they touch alongside SOC 2 and ISO 27001 — see compliance coverage.