Non-intrusive compliance scan

PCI-DSS external scan: quarterly evidence, and an honest label.

PCI DSS external vulnerability scanning under Requirement 11.3.2 is a quarterly checkpoint. This engine helps you pass it — and it is not, and does not claim to be, an ASV attestation.

$149 per scan ~35 min typical run 10 AI agents EU-only processing No subscription

The short version. A non-intrusive external scan of your in-scope footprint, graded by CVSS in the way an ASV scan grades, producing a readiness report. AssurePort is not listed by the PCI Security Standards Council as an Approved Scanning Vendor, so this does not replace a scan by a listed ASV.

What this engine does

Most of the work that decides whether you pass the quarterly scan happens between quarters. That is the gap this engine is for.

  • External vulnerability detection across the hosts and domains you place in scope.
  • CVSS grading against the threshold an ASV scan applies, so a failing item here would fail there.
  • TLS and cipher posture — deprecated protocol versions and weak suites.
  • Security header and cookie configuration relevant to the requirement.
  • Exposed administrative interfaces and services reachable from the internet.
  • A readiness report stating clearly what would fail and why.

What it deliberately does not do

Two exclusions matter here, and the second is the one vendors are vague about:

  • No exploitation. ASV scanning is expected to be non-disruptive: this engine evidences exposure and stops. Exploitation belongs in a scoped penetration test with its own authorisation.
  • No ASV attestation. AssurePort is not on the PCI SSC list of Approved Scanning Vendors. Only a listed vendor can sign the Attestation of Scan Compliance your assessor will ask for.
  • No compliance verdict. The report says what would fail a scan; it does not declare you compliant, because that is not ours to declare.
  • No scanning without authorisation. DCV or attestation, as with every engine.

How we prove you are allowed to run it

Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. Cardholder-environment scope is your determination. The engine assesses what you authorise and place in scope; it does not decide what belongs there.

Where your data goes, and when it is deleted

Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.

  • The report — kept two years, so you can hand it to an auditor next year.
  • Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
  • The anonymous homepage preview — content erased after 24 hours.
  • The authorisation record — kept, because it is the evidence that the scan was permitted.

The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.

How a run actually works

The scan runs the same analysis pipeline as our Web engine with exploitation forced off, which is what “non-intrusive” means in practice rather than in marketing. That is also why its agent count is lower than the Web engine's: the exploitation and post-exploitation agents never run.

We changed this in August 2026 after finding that the engine was dispatching the full exploitation track while being sold as ASV-aligned. The behaviour and the description now match, and we wrote about the fix publicly.

What you get at the end

A readiness report: every finding CVSS-graded, each one marked as pass-affecting or not, with remediation. Suitable as internal evidence and as preparation for the ASV scan — and explicit, on its own cover, that it is not an attestation.

What this engine cannot find

What this engine cannot do for your PCI programme:

  • Produce the Attestation of Scan Compliance — only a PCI SSC-listed ASV can.
  • Assess internal scanning requirements under 11.3.1.
  • Determine your cardholder-data-environment scope for you.
  • Prove exploitability, since exploitation is deliberately disabled here.
  • Cover requirements outside the external scanning obligation.

We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.

Frequently Asked Questions

Can this replace our ASV scan?

No. Only a vendor listed by the PCI Security Standards Council can issue the Attestation of Scan Compliance. This engine helps you find and fix what would fail, before that scan runs.

Is AssurePort an Approved Scanning Vendor?

No, and we say so on the product page, in the report and here. Any vendor unclear on this point is worth a second look.

Does the scan exploit what it finds?

No. ASV scanning is expected to be non-disruptive, so exploitation is disabled for this engine — enforced in dispatch, not left to configuration.

How often should we run it?

The obligation is quarterly plus after significant change. Running your own scan early in each quarter leaves time to remediate before the ASV scan.

What does the report actually give an assessor?

Evidence of the find-fix-verify loop between quarters. The attestation itself must still come from a listed ASV.