What Requirement 11.3.2 actually asks for
PCI DSS Requirement 11.3.2 asks organisations to run external vulnerability scans at least once every three months, and after any significant change to the cardholder data environment. The scans must cover every external-facing IP address and domain in scope, the results must reach a defined risk threshold, and any failures must be remediated with a rescan to confirm the fix.
Two details in that sentence carry most of the weight in practice. The first is scope: an external scan is only meaningful if it covers everything actually exposed, which in most estates is more than the asset register says. The second is rescan: the requirement is not satisfied by a scan that finds problems. It is satisfied by a passing scan, which means the finding-fix-verify loop is the real unit of work, not the scan itself.
Where the ASV designation comes in
An Approved Scanning Vendor is an organisation that the PCI Security Standards Council has tested and listed. The listing is not a claim a vendor can make about itself. It is a qualification granted by the Council, with an annual requalification, and it comes with a specific privilege: an ASV may issue the Attestation of Scan Compliance that your acquirer or qualified security assessor will ask to see.
The practical consequence is unambiguous. If your assessor needs the attestation, it must come from a vendor on the Council’s published list. No amount of methodological similarity substitutes for the listing. A scan can follow ASV methodology precisely, produce identical findings, and still not produce a document your assessor can accept, because the document’s value comes from who signs it.
AssurePort is not a PCI SSC Approved Scanning Vendor. Our PCI-DSS External Vuln Scan runs ASV-aligned methodology and produces a readiness report. It does not replace a scan by a listed ASV, and we say so on the product page, in the report itself, and here.
So what is a non-ASV external scan good for?
A great deal, as long as you are honest about which job it is doing. The quarterly ASV scan is a checkpoint. Most of the work that determines whether you pass that checkpoint happens between checkpoints, and that is where a non-ASV scan earns its place.
- Finding the failures before the checkpoint does. A failed ASV scan costs you a remediation cycle and a rescan on someone else’s schedule. Finding the same issue a month earlier costs you a ticket.
- Covering the gap between quarters. Certificates expire, a service gets exposed during a deploy, a dependency picks up a CVE. Ninety days is a long time to discover that by scan.
- Scoping honestly. External discovery frequently finds hosts nobody meant to expose. It is better to reconcile the asset register against reality on your own terms.
- Evidence for the rest of the framework. Requirement 11 is not the only one with a scanning dependency, and a dated report with reproducible detail supports more than one control.
Why a compliance scan should be non-intrusive
ASV scanning is expected to be non-disruptive: the scan proves exposure, it does not exploit it. This matters more than it sounds, because “we ran a pentest against production for the PCI scan” is a category error that can turn a compliance activity into an incident.
We had a version of this problem in our own product, and it is worth describing plainly because it is exactly the confusion this article is about. Our PCI engine was sold as ASV-style and non-intrusive, but internally it dispatched the same pipeline as our full web pentest — exploitation included. The engine label and the running code said different things. In August 2026 we forced exploitation off for that engine, corrected the agent count we advertised, and aligned the product page, the console and the code so all three describe the same behaviour.
The general lesson holds for any vendor you evaluate: ask what the compliance scan actually does to the target, and check the answer against the product’s own technical description rather than its marketing summary.
Reading the report: severity thresholds
The ASV programme has historically keyed failure to CVSS severity, with a threshold that fails a component on findings at or above a defined score. PCI DSS v4.0 continues to require that scans meet the programme’s pass criteria, and the CVSS 4.0 transition has changed how some vendors present scores. Two consequences are worth planning for:
- The same finding can be scored differently by different tools. Treat the score as an input to your prioritisation, not the whole of it. What matters for a fix decision is exploitability in your configuration.
- A pass is a point-in-time statement. It says the scanned scope met the threshold on the scan date. It does not say the environment is secure, and it should never be presented internally as if it did.
A practical sequence
The pattern we see work is unremarkable and effective:
- Reconcile scope first. Discovery before scanning, so the scan covers what is actually exposed.
- Run your own external scan early in the quarter, and fix what it finds.
- Book the ASV scan against a scope you have already cleaned.
- Keep scanning between quarters, so a change does not sit undetected for ninety days.
- Keep the evidence — dated reports, remediation notes, rescan results. Assessors ask for the loop, not the last screenshot.
None of this requires an expensive tool. It requires that someone owns the loop, and that the reports you keep say what they mean.
Frequently Asked Questions
Does PCI DSS require an ASV scan?
For external vulnerability scanning under Requirement 11.3.2, the attestation must come from a PCI SSC-listed Approved Scanning Vendor. Internal scans under 11.3.1 do not carry that requirement. Your acquirer or assessor defines exactly which evidence they need, so confirm with them before purchasing anything.
Can a non-ASV scan satisfy Requirement 11.3.2?
It cannot produce the Attestation of Scan Compliance, which is the artefact an assessor typically asks for. It is still useful for finding and fixing issues before the ASV scan runs, and for covering the ninety-day gap between quarterly scans.
How often must external scans run?
At least once every three months, and again after any significant change to the cardholder data environment. Passing is the objective, so plan for a remediation and rescan cycle rather than a single scan date.
Is AssurePort an Approved Scanning Vendor?
No. AssurePort is not listed by the PCI Security Standards Council as an Approved Scanning Vendor. Our PCI-DSS External Vuln Scan follows ASV-aligned methodology and produces a readiness report; it does not replace a scan by a listed ASV.
Should a PCI scan try to exploit what it finds?
ASV scanning is expected to be non-disruptive: it evidences exposure rather than exploiting it. Exploitation belongs in a scoped penetration test with its own authorisation, not in a routine quarterly compliance scan against production.