PCI DSS ASV scanning

PCI DSS ASV scanning means an Approved Scanning Vendor runs external vulnerability scans at least every three months under Requirement 11.3.2. This page covers who must scan, what a passing scan means, timing, initial assessments and the SAQ A rule.

On this page

What PCI DSS ASV scanning requires and who must run it

Requirement 11.3.2 requires external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor (ASV). The obligation sits with your organization, not with the ASV or any consultant. When an acquirer or payment brand asks for quarterly scan evidence, the question is whether your own external attack surface was scanned by an approved vendor on schedule and whether the last scan passed. An implementation partner can help you build the inventory of internet-facing addresses, confirm which ones are in scope, and work through remediation with your engineers. Only the ASV produces the scan report and decides whether it passes. DeployOpen does not issue scan reports, attestations or validation, so the ASV's report is the document you submit alongside your Attestation of Compliance.

The answer changes with the validation type you file. Under a Report on Compliance or a Self-Assessment Questionnaire that includes Requirement 11.3.2, quarterly ASV scanning applies to the systems your validation covers. If you are an e-commerce merchant using SAQ A, the rule is different: ASV scans are required for the merchant webpages that redirect to a third-party payment provider or embed its iframe, even though payment processing is fully outsourced. Confirm with your acquirer which validation path applies before you buy scanning, because scanning the wrong set of addresses leaves the real gap open. Also confirm your scope with your QSA or acquirer early, since scope drives how many addresses the ASV needs to see.

A significant change to the environment brings a separate external scan duty under Requirement 11.3.2.1. Those scans may be performed by qualified internal personnel rather than an ASV, so a change to a firewall rule, a new internet-facing service or a migration to a new hosting provider may require a scan that your own team can run, while the quarterly ASV scan continues on its own calendar. Plan for both. Check the ASV's status on the PCI SSC list before you sign, since an ASV can lose its status or be placed In Remediation, which would leave your scan evidence in question.

Who must run quarterly ASV scans in PCI DSS

Requirement 11.3.2 applies to any entity whose validation path includes external scanning, and several parallel groups fall into it for different reasons. Your acquirer and the card brands decide applicability, so confirm your group before you buy a scan.

Merchants and service providers on a ROC or SAQ

Any merchant or service provider whose validation method includes Requirement 11.3.2 must run external vulnerability scans at least once every three months through a PCI SSC Approved Scanning Vendor. This applies whether you validate with a Report on Compliance or a Self-Assessment Questionnaire that contains the requirement. Confirm with your acquirer or payment brand which questionnaire or report you submit, since that choice determines whether the requirement is in your path.

SAQ A e-commerce merchants on redirects

Merchants that fully outsource payments but host webpages that redirect to a third-party provider or embed its iframe must still run ASV scans on those pages under SAQ A. Outsourcing the payment processing does not remove this scanning duty. Confirm whether your checkout pages, redirect pages and embedded frames are in the scan scope, and ask your ASV how it will treat any page your payment provider hosts.

Entities required by card brands

Visa requires quarterly ASV network scans for Level 1 to 3 merchants, both service provider levels, and Level 4 merchants where applicable. Other card brands and acquirers set their own validation requirements, so the brand's rules may apply even if your questionnaire does not obviously include scanning. Confirm your merchant or service provider level with your acquirer and check the brand's compliance validation page for the scanning obligation that applies to you.

Organizations with no external components

Some organizations have no public-facing IP addresses, hosted pages or externally reachable systems that touch the cardholder data environment. Their scanning obligation may be narrow or absent, but that conclusion needs evidence. Document the external footprint, confirm it with your acquirer or assessor, and recheck it after infrastructure changes, because a new public address can bring the requirement into scope.

Entities with significant changes

Requirement 11.3.2.1 requires external scans after a significant change to the environment, and these may be performed by qualified personnel who are not an ASV. Quarterly ASV scans therefore do not cover every scan event. Set a change process that flags new external exposure, and confirm with your assessor which changes trigger a scan and who may perform it.

How an ASV scan runs from scheduling to a passing report

The ASV scan sequence turns a list of external addresses into a dated scan report that can be filed with the Attestation of Compliance, but only when each phase closes with a documented output.

  1. Confirm scope and build the external asset list

    Your team defines which internet-facing systems belong in the scan, including public IP addresses, domains, load balancers, and hosts that reach the cardholder data environment from outside. The organization owns this list, and an implementation partner or assessor may challenge it. The step is done when you have a written external asset list that ties each address to a system owner and to the PCI DSS scope decision. Ask your QSA or assessor to confirm that the list matches the scope they will test.

  2. Engage an ASV and configure the scan

    Select an organization on the PCI SSC list of Approved Scanning Vendors whose scan solution is current, and check its status before you sign. You provide the asset list and any scan parameters the ASV needs, and agree how authorization for the scan is given and who receives the results. The output is a configured scan profile tied to the agreed asset list. Confirm the ASV's listing status again at this point, because the PCI SSC advises checking regularly that an ASV has not lost status or been placed In Remediation.

  3. Run the external scan

    The ASV runs external vulnerability scans against the agreed addresses from outside your network. Your team should confirm that the scanning source is not blocked by a control that would hide findings, and should record any change that could affect results during the window. The output is a raw scan result set for each address. The step is complete when the ASV confirms the scan finished and that every in-scope address was reached or the gap is explained.

  4. Review findings and remediate

    The ASV produces findings with severity scores. Your team triages each one against the passing criteria in the ASV Program Guide, including automatic-failure findings such as default accounts and external vulnerabilities scoring 4.0 or higher on CVSS. Owners patch, reconfigure, or retire the affected services, and record the change with a reference to the finding. The output is a remediation log linking each finding to a fix or a documented disposition. Only the ASV can state whether a disputed finding is a false positive, so keep the evidence you send for that review.

  5. Rescan until the scan passes

    After remediation, the ASV reruns the scan on the affected addresses, and you repeat the cycle as needed until the results meet the passing criteria. The output is a rescan report that shows the earlier failures as resolved or explains why they are not exploitable findings. Keep every intermediate report, because assessors look at how the path to a passing result was handled, not only at the final pass.

  6. Issue the passing ASV scan report

    When the scan meets the passing criteria, the ASV issues the scan report that names the scanned addresses, the dates, and the result. Your team checks that the report covers the agreed asset list and the correct date range. The output is the final ASV report, which you retain as scan evidence for the quarter. The PCI SSC does not endorse supplemental letters or certificates from ASVs, so rely on the report itself.

  7. File the report with the Attestation of Compliance

    The passing ASV scan report is submitted alongside your PCI DSS validation documents, such as the Attestation of Compliance for the relevant SAQ or Report on Compliance. Your assessor reviews it as part of Requirement 11.3.2 testing. The scan report alone does not prove that other PCI DSS requirements are met, as the PCI SSC clarifies in FAQ 1234. Your evidence for firewalls, configuration, patching, and access controls must be gathered separately. The step is complete when the assessor has the scan report, the remediation log, and the rest of the evidence set.

How a passing PCI DSS ASV scan is judged

A passing ASV scan generally means the external scan found no automatic-failure items and no external vulnerability scoring 4.0 or higher on CVSS. Automatic-failure items include things such as default accounts still active on an exposed service. PCI SSC FAQ 1152 describes this general pass condition, and the ASV Program Guide sets the detailed rules the scanning vendor applies. Read the report's summary and its list of findings, not just the word "pass" on the cover page, because the report shows which findings drove the result and which were marked as false positives or disputed.

A failed scan is not the end of the cycle. Requirement 11.3.2 expects rescans, performed by an ASV, until the ASV Program Guide conditions for a passing scan are met. Plan remediation time and a rescan window before the quarter closes, since FAQ 1087 treats 90 days as the maximum gap between quarterly scans and asks entities to rescan promptly if a scheduled scan is missed. Confirm with your ASV how rescans are billed, because they are often a separate line item in the quote.

A passing scan is not proof that your whole environment is compliant. An ASV scan report is not evidence that any other PCI DSS requirement is met, as FAQ 1234 states. It covers external vulnerabilities on the addresses you submitted, so the scan's IP scope must match your actual external footprint. Some organizations ask their ASV for a letter confirming a pass to share with customers or acquirers. The PCI SSC does not endorse supplemental certificates or letters from ASVs, so keep the full scan report with your assessment evidence and send the letter only as a cover note, never as a substitute. Confirm the ASV's listing status on the PCI SSC list before you rely on any result.

When PCI DSS ASV scans must happen, and what a missed scan means

Requirement 11.3.2 expects external vulnerability scans at least once every three months, and each scan must be performed by a PCI SSC Approved Scanning Vendor (ASV). PCI SSC FAQ 1087 treats three months, or 90 days, as the maximum gap between scans, so the schedule has no slack beyond that limit. The routine cycle is the most visible part of the requirement and the one assessors check first, because it produces a dated record for each quarter.

  • Interval: Plan each scan so the gap between consecutive scans never exceeds three months.
  • Scanner: Only an ASV scan satisfies the quarterly routine, and the ASV must be listed as valid on the PCI SSC list at the time of the scan.
  • Passing result: Rescan until the ASV Program Guide criteria for a passing scan are met, then keep the passing report.
  • Coverage: Confirm the scan targets match the external IP addresses and hostnames in your documented scope.

Before relying on an ASV, check the PCI SSC list yourself, because an ASV can lose status or appear as In Remediation.

Initial assessments and the four passing scans question

For a first PCI DSS assessment, the question is whether you must show four passing ASV scans from the previous year. The SAQ D note to Requirement 11.3.2 says you do not, provided three conditions hold: the most recent external scan passed, your policies require quarterly scanning, and any vulnerabilities found were corrected and then rescanned until the scan passed. Meeting those conditions means the first assessment can rest on a shorter scan history, but only if the latest scan itself is clean and the remediation trail is documented.

The shortcut is not a free pass. PCI SSC FAQ 1152 states that entities normally need passing scans in each of the previous four quarters, so the reader should treat the note as an allowance for newcomers rather than the default. Assessors look at what the scan record shows about how the environment was run during the year. A single recent passing report with no prior scanning history, or with rescans that were never documented, leaves the assessor with little to rely on. For organizations that began scanning late, the gap between the four-quarter expectation and their actual record is the risk to plan around.

Before you rely on the initial-assessment provision, confirm with your QSA and your acquirer or payment brand how they will treat your existing history. Ask whether they accept fewer than four quarters, what they need to see for the remediation and rescan trail, and whether scans from a previous ASV or a different scanning configuration will count. Ask them, too, how they expect you to show that quarterly scanning was required by policy from the start. Getting these answers in writing early avoids discovering a gap during the assessment itself.

Which external scan fits each PCI DSS situation

This table compares the routine quarterly ASV scan under Requirement 11.3.2, the external scan after significant change under Requirement 11.3.2.1, and the rescan after remediation. Read each row to match a trigger to who may run the scan and what evidence it produces, and note that an ASV report supports only the scanning requirement.

Scan typeWho may perform itEvidence it produces
Routine quarterly scan (Requirement 11.3.2): at least once every three months, with rescans until a passing scanA PCI SSC Approved Scanning Vendor using an approved scan solutionASV scan report showing a passing result, to be retained with the assessment evidence
External scan after significant change (Requirement 11.3.2.1): triggered by a significant change to the environmentQualified personnel who are not necessarily an ASV, as the standard allowsScan results and records showing the change was assessed and scanned, confirm the scope with your assessor
Rescan after remediation: run once vulnerabilities are corrected, until the ASV Program Guide passing criteria are metA PCI SSC Approved Scanning Vendor for the quarterly-type scan that passesPassing ASV rescan report that shows the corrected findings no longer appear
Missed quarterly scan: scheduled scan not run within the three-month window (illustrative)A PCI SSC Approved Scanning Vendor, rescanned promptlyRescan report, plus a record of why the gap occurred and how it was closed
Initial assessment with a passing latest scan, quarterly policy in place, and fixes rescannedA PCI SSC Approved Scanning VendorLatest passing scan and remediation records, confirm with your assessor whether earlier scans are needed
SAQ A e-commerce page that redirects to or embeds a third-party payment iframeA PCI SSC Approved Scanning VendorQuarterly ASV scan report covering the merchant payment pages, even when processing is fully outsourced

What to have in place before the first ASV scan

An ASV scan only tests what you tell the vendor to test, and a passing result only counts if the surrounding process holds up. The six items below cover the inventory, the validation path, the remediation workflow, the scanning policy, the change triggers and the scan history that an assessor will check first.

Current inventory of external addresses

Build a list of every public IP address, hostname and domain that belongs to the cardholder data environment or could affect its security. Check it against DNS records, cloud load balancers and firewall NAT rules, because stale or missing entries are the most common reason a scan misses a live system. Your team owns the inventory and its accuracy. An implementation partner can script discovery and reconcile results with your asset records, but the scope decision stays with you and your assessor.

Confirmed validation path

Decide whether the organization validates with a Self-Assessment Questionnaire or a Report on Compliance before scheduling scans, because that choice determines which scans and reports you need and what the scan vendor will deliver. Confirm the choice with your acquirer or the payment brand requirements that apply to you. An implementation partner can document the scope that supports the choice, while the acquirer or payment brand decides the validation level.

Remediation process with named owners

A scan that fails needs a documented path from finding to fix to rescan. Assign an owner for each class of asset, set how findings are triaged by severity, and record who signs off on a fix before the rescan is requested. Ask the scan vendor how it reports findings and whether it supports rescans within the window your policy sets. The organization owns the owners and the deadlines. An implementation partner can build the ticketing workflow and reporting templates.

Written quarterly scanning policy

Requirement 11.3.2 expects external scans at least once every three months, so your policy should name the scan frequency, the approved vendor and the person accountable for scheduling. Check that the policy matches what your calendar and your scan contract actually do. Scanning on a fixed schedule with a named backup is the simplest way to avoid a missed quarter. Your leadership approves the policy. An implementation partner can draft it and map it to the calendar and the evidence it produces.

Significant change trigger process

External scans are also required after significant changes, and those may be run by qualified personnel other than an ASV. Define what counts as significant in your environment, such as a new public endpoint, a changed firewall rule or a new payment page, and route each change to a rescan decision. Test the trigger by walking through a recent change and confirming it would have been caught. Your change management team owns the definition. An implementation partner can wire the trigger into existing change tickets.

Retained record of prior scans

Assessors look for a continuous record of passing scans, including failed scans, the fixes behind them and the rescans that followed. Confirm that your vendor portal lets you export full reports and attestations, and store them in a location you control with access logs. Keep a simple index of scan dates, results and remediation tickets so an assessor can trace each quarter quickly. The organization owns retention. An implementation partner can set up the archive and index without taking custody of the reports.

Who owns each step of a PCI DSS ASV scanning program

This table compares who does what at each stage of quarterly external scanning under Requirement 11.3.2, from scope confirmation through the final report. Read the organization column as the owner of every decision and the partner column as the party that prepares systems and evidence. Only the ASV issues the scan report, and the validation process, not the partner, decides what the Attestation of Compliance records.

StepThe organizationImplementation partner such as DeployOpenASV or assessor
Scope confirmationDecides which public IP addresses and hostnames are in the cardholder data environment and signs off the scope listInventories internet-facing assets, maps them to systems and documents the list for reviewChecks that the scan list matches the external attack surface the ASV can reach
ASV selectionChooses an ASV from the PCI SSC list and confirms its status is current, not In RemediationGathers the scope and access details the ASV needs to quote and onboardHolds approved status through annual re-approval and states its scan solution in the engagement
SchedulingSets a recurring calendar so no quarter passes without a scan, keeping the 90-day maximum in viewConfigures recurring reminders and change triggers that feed the calendarRuns the scan on the agreed date and reports any scheduling problems
Scan executionAuthorizes the scan window and any firewall or hosting provider notices neededMakes sure in-scope assets are reachable and that no temporary blocks interferePerforms the external scan using its approved solution
RemediationFixes or formally addresses findings, including any automatic-failure items and vulnerabilities scoring 4.0 or higherPrepares patch and configuration changes, tracks tickets and records fixes as evidenceDoes not fix systems; explains findings and what a passing scan requires
RescanningRequests rescans until the scan passes under the ASV Program GuideSchedules rescans after fixes and checks the results against the ticket trailPerforms the rescan and marks the result as passing or failing
Evidence retentionKeeps scan reports, remediation records and scope approvals for assessor reviewStores copies in an organized evidence store and maps each report to Requirement 11.3.2Keeps its own records under its program obligations; a scan report is not evidence for other requirements
Final report and AOCSubmits the assessment and signs the Attestation of Compliance for the validation method it usesPrepares the summary of scan results and supporting documents for the assessorIssues the ASV scan report only; it does not issue the Attestation of Compliance, which a QSA or the validation process handles

How to check an ASV before you sign

An ASV scan only counts if the vendor and its scan solution hold current PCI SSC approval when the scan runs. The checks below cover the listing, its status, the tool, and what you receive, so you can confirm the scan will support your Requirement 11.3.2 evidence.

Confirm the vendor is listed

Start by searching the PCI SSC Approved Scanning Vendors list for the company's exact legal name, not a reseller or marketing brand. A vendor that is not on the list cannot produce a scan that validates Requirement 11.3.2, however thorough its tooling looks. Save the listing page or record with the date you checked it, so the file shows the vendor was approved at the time of each scan.

Check status and re-approval

ASVs go through annual re-approval, and the PCI SSC advises checking its list regularly because a vendor may lose status or be listed as In Remediation. Ask the vendor to confirm in writing that it holds current approval and that no remediation notice applies to its scan solution. A scan run while a vendor is In Remediation or unapproved may not be accepted as evidence.

Verify the scan solution

Approval applies to the ASV's scan solution, not only to the company. Ask the vendor to name the specific solution it will use for your external scan and confirm that solution appears in its approved listing. If the vendor offers a different tool for a different service, that tool may not carry the same approval.

Ask how disputes are handled

Scans often flag false positives or findings you have already fixed. Ask how the vendor handles a dispute: who reviews it, what evidence you submit, how long the process takes, and whether the vendor can rescan the affected address before you request the next report. Get the dispute steps in writing, since you will need a passing scan within the rescan cycle described in the standard.

Ask what the report contains

Request a sample report before you buy. Check that it lists each external IP address and host scanned, each finding with its CVSS score, the pass or fail result, and the date and scan identifiers. Confirm whether the vendor issues a compliance attestation. Note that an ASV scan report is not evidence that other PCI DSS requirements are met, so do not expect it to cover them.

Recheck the listing before each scan

Approval can change between quarters, so repeat the listing check before every scheduled scan, not only when you sign the contract. Compare the vendor and solution against the current list, then record the result in your evidence folder. This habit protects you if a scan is later questioned, and it helps you spot a lapse before a missed quarter becomes a gap.

Questions buyers ask about PCI DSS ASV scanning

Do SAQ A merchants need quarterly ASV scans?

Yes, in some cases. An SAQ A merchant whose e-commerce payment page redirects to a third-party payment provider or embeds that provider's iframe must have external scans run by an Approved Scanning Vendor, even when payment processing is fully outsourced. The PCI SSC addressed this in FAQ 1604, and its July 2024 ASV resource guide explains the same point. Merchants that take payments without any web page touching cardholder data in this way may not have this scanning obligation, so confirm your own page flow before assuming either answer. Ask your acquirer which path applies to your checkout, because the scan obligation follows the way your payment page is built, not the questionnaire label alone. Start by mapping the URLs a shopper actually loads during payment, then decide whether each one falls into the scanned set.

Is an ASV scan required after a significant change?

Yes. Requirement 11.3.2.1 calls for external vulnerability scans after any significant change to the environment, in addition to the quarterly schedule. The important difference is who may perform these post-change scans: they can be carried out by qualified internal personnel or a third party other than an ASV, so your team can often handle them. A significant change might include a new internet-facing system, a changed firewall rule set that opens a path from the internet, or a new payment page integration. Define what counts as significant in your change management policy so that the trigger is consistent and auditable. Keep the scan output, the change record and the date together, since an assessor will look for the link between the two.

How much effort does the organization need to put into quarterly scans?

Most of the effort falls on your team in preparation and remediation, not on the scan itself. You must maintain an accurate list of external IP addresses and domains in scope, give the ASV access to scan them, schedule each quarterly run, and review the report. Expect ongoing work to assign owners for each finding, fix vulnerabilities, and rescan until the report passes under the ASV Program Guide. Effort rises with the number of internet-facing hosts, the age of the systems and how often they change. Ask any ASV to explain its scanning workflow, its dispute process and how it handles rescans before you sign, so you know which steps are yours and which are the vendor's.

Can our own team run the quarterly scans instead of an ASV?

No, not for the quarterly requirement. Requirement 11.3.2 specifies that the scheduled external scans must be performed by a PCI SSC Approved Scanning Vendor, and the ASV's scan solution must be approved by the PCI SSC. Your internal scanner, even a capable one, does not satisfy that requirement. Internal staff can still run the post-change scans described under Requirement 11.3.2.1, and they can run their own vulnerability scanning for other purposes. Remember that an ASV must be approved annually, so check the PCI SSC ASV list before engaging one, and verify that the vendor is not listed as In Remediation.

What happens if a quarterly scan is missed?

The gap is a compliance problem you need to close quickly. PCI SSC FAQ 1087 treats three months, or 90 days, as the maximum interval between quarterly scans and asks entities to rescan within a day or two if a scheduled scan is missed. Waiting for the next quarter is not an acceptable fix. Document the cause, run the scan as soon as possible, and record the remediation in your evidence set. Build a calendar with reminders and a named owner for each scan, and confirm that the ASV's scheduling system alerts you before a window closes. Assessors will look at scan dates across the year, so a gap that is later explained and corrected is far easier to defend than one that is discovered during the assessment.

Does a passing ASV scan prove that we are PCI DSS compliant?

No. A passing ASV scan is evidence for one requirement only. PCI SSC FAQ 1234 states that an ASV scan report is not evidence that any other PCI DSS requirement is met. A passing scan generally means no automatic-failure findings, such as default accounts, and no external vulnerabilities scoring 4.0 or higher on CVSS. Compliance also depends on your firewall configuration, access controls, logging, penetration testing and every other requirement in scope. Also be cautious about supplemental letters or certificates from ASVs, because the PCI SSC does not endorse them. Submit the full scan report as evidence and do not rely on a summary badge or letter as validation.

What drives the cost of ASV scanning and remediation?

Cost has two parts: the scanning service and the internal or contracted work to fix what the scans find. The scanning fee is driven mainly by the number of external IP addresses and domains in scope, the frequency of scans, and whether you need rescans and post-change scans. No public price figure is supplied for this topic, so request a written quote that itemizes each of these units. Remediation cost is harder to predict. It depends on the age of your internet-facing systems, the number of vulnerabilities, how quickly patches can be applied and whether any finding requires a redesign. Reducing scope, such as by consolidating public endpoints or outsourcing payment pages, lowers both parts over time. Ask vendors to state what is one-time, such as onboarding, and what recurs each year or quarter.

How do we confirm the scanning requirement with our acquirer or payment brand?

Ask your acquirer or payment brand directly, in writing, which validation level and questionnaire apply to you and whether quarterly ASV scans are required. Under PCI DSS, the payment brands decide who must comply and validate, and the PCI SSC does not enforce compliance, so the answer you need comes from them. Visa, for example, publishes that quarterly ASV network scans apply to Level 1 to 3 merchants, to both service provider levels, and to Level 4 merchants where applicable. Ask for the reference that supports the answer, record it, and keep it with your evidence. If the acquirer's answer conflicts with your reading of the questionnaire, resolve it before your assessment starts.

How DeployOpen works on this

DeployOpen prepares the systems, network paths and evidence that an Approved Scanning Vendor needs to run quarterly external scans. The organization owns its scan program and its compliance decisions, and only an ASV issues scan reports and passing results.

How we scope

  • Confirm which external IP addresses, domains and hosted endpoints sit in the scan boundary for Requirement 11.3.2.
  • Agree in writing which public-facing systems are in scope and which are excluded, with the reasons recorded.
  • Identify whether an e-commerce page, redirect or embedded iframe brings the site into scope for ASV scanning.

How we build

  • Prepare externally reachable assets so the ASV can scan them, including firewall and load balancer rules that allow the scanner.
  • Set up a repeatable quarterly scan schedule with reminders that flag missed scans before the 90-day limit.
  • Review the findings from each scan with your team and plan remediation and rescans until the scan passes.

How we hand over

  • Deliver a written record of the scan boundary, scan schedule, ASV contact details and remediation tracking.
  • Document how significant changes trigger extra external scans and who on your team performs them.
  • Hand over evidence files in a structure your QSA or internal assessor can review, with clear notes on what a scan report does not prove.

How we support

  • Support fixed-scope engagements agreed in writing before work starts, with scope, deliverables and timelines defined.
  • Offer ongoing support, upgrades and continuous testing as a retainer after the initial work is complete.
  • Confirm with your ASV and your payment brand which scan status and validation path apply to your environment.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.