What PCI DSS 11.3 vulnerability scanning asks for
Requirement 11.3 asks for two streams of vulnerability scanning, each on a quarterly cycle, plus scans after significant changes. Internal scans are run by your own team or a provider you engage, and they must be authenticated with sufficient privileges so the scanner can see installed software and missing patches. External scans must be performed by a PCI SSC Approved Scanning Vendor (ASV), and they examine the internet-facing addresses in scope. If you are the compliance lead or engineer who must prove this works, your evidence is the scan reports, the ticket trail showing each finding was resolved, and the rescans that confirm the fix. Internal scans do not need a QSA or ASV, but the testers must be qualified and independent of the systems they scan. The reason for this cycle is simple: unpatched operating systems, libraries and applications inside the cardholder data environment (CDE) are a common route into card data, and new flaws are published continuously. A quarterly schedule alone does not satisfy the requirement. Assessors look for evidence that high-risk and critical vulnerabilities were fixed and that the fix was verified by a rescan, and they expect lower-risk findings to be handled under a documented, targeted risk analysis. Confirm your own cadence against the current SAQ or ROC template and your ASV's program rules before you rely on it.
Three things make 11.3 hard in practice. The first is inventory: a scanner cannot test hosts, containers or cloud instances it does not know about, so gaps in asset lists show up as unscanned systems at assessment time. The second is credentials: authenticated internal scans need accounts with enough rights to read the software inventory, and maintaining, rotating and protecting those accounts is an ongoing task that owners often underestimate. The third is the remediation backlog. Scans that run on time but produce tickets nobody closes will fail the intent of the requirement even when the paperwork looks complete. Ask your scanning provider, or your internal team, to show how findings are assigned, how exceptions are approved, and how rescans are triggered and recorded before the next assessment begins.
Which systems and networks PCI DSS 11.3 scanning covers
Scanning under Requirement 11.3 is only as complete as its target list. The scan scope has to match the cardholder data environment (CDE) and connected systems in your own PCI DSS validation, so each of the decisions below changes which hosts, segments and addresses get scanned and who must confirm them.
The cardholder data environment boundary
Start with the CDE as documented in your validation, including every system that stores, processes or transmits cardholder data or sensitive authentication data. Internal scans must reach these hosts with authenticated access, so each in-scope server, database and workstation needs a scan target and credentials. Ask your assessor to confirm that the scan inventory and the CDE diagram describe the same systems.
Connected systems that can affect the CDE
PCI DSS also reaches systems that could affect the security of the CDE, such as directory servers, jump hosts, monitoring tools and management consoles that share a network or credentials with payment systems. These often sit outside the obvious payment segment and are easy to miss. Document each connected system and its path to the CDE, then add it to the scan targets with the same rigor as core components.
In-scope network segments and IP ranges
Scan targets are usually defined as IP ranges or segments. Each range covering in-scope systems should appear in the scan configuration, and any segment added to the CDE through a routing change, VLAN extension or new subnet must be added before its first scan. Compare the scanner's discovered host list against your network inventory each quarter to catch hosts that were never configured as targets.
Cloud accounts and containers
Cloud workloads change faster than data center hardware. Confirm which cloud accounts, subscriptions, virtual networks, load balancers and container clusters hold in-scope systems, and how the internal scanner reaches them. Ephemeral instances and containers can appear and disappear between scans, so ask how new workloads are registered as scan targets and how image-level findings are tracked.
Third-party hosted components
Payment pages, APIs and hosted services run by a third party may sit inside your CDE boundary or be covered by the provider's own validation. Your scope determines whether you scan those endpoints or rely on the provider's attestation and responsibility matrix. Request the provider's scope statement and confirm in writing which components your external and internal scans must cover.
Externally visible IP addresses
The external scan covers every public IP address and hostname that provides access to the CDE or to systems in scope, including load balancers, DNS-resolved names, VPN gateways and cloud public addresses. A new public address, a forgotten test host or a retired service still answering on a public IP changes the external scan target list. Reconcile public address inventories with the ASV scope each quarter and after any change to DNS or perimeter routing.
How an assessor tests PCI DSS vulnerability scanning
This table lists the steps an assessor takes for internal scanning (11.3.1, 11.3.1.1, 11.3.1.2) and external scanning (11.3.2), the evidence each step asks for, and the findings that most often lead to a gap. Read each row as a test the assessor performs and the proof you should have ready before the assessment starts.
| Test step | Evidence the assessor requests | Common finding |
|---|---|---|
| Review scan schedule and internal scan scope (11.3.1) | Scan calendar showing internal scans at least every three months, and a scope list of in-scope network segments and hosts | Scans run quarterly on paper but skip segments that hold cardholder data or connect to the CDE |
| Confirm internal scans are authenticated (11.3.1.2) | Scan configuration showing credentialed access, the account used, and its privilege level | Scan results are based on unauthenticated probing, so local patch gaps are missed |
| Sample reports across four quarters (11.3.1) | Four consecutive quarterly internal scan reports, or the initial-assessment record described in SAQ D | Only the most recent report exists, or reports cover different host lists with no explanation |
| Check resolution of high-risk and critical findings (11.3.1) | Remediation tickets linked to each high-risk and critical finding, plus the rescan that confirms the fix | Findings are marked closed without a rescan, or the rescan was never run after the patch |
| Check targeted risk analysis for lower-risk findings (11.3.1.1) | Documented risk analysis that explains how lower-risk findings are prioritized and when they are addressed | No written criteria for lower-risk findings, or the analysis is a generic statement with no decisions recorded |
| Check external scans by an ASV (11.3.2) | ASV scan reports at least every three months, with a passing status under the ASV Program Guide | Scans were run by the internal team, or the scanning vendor is not listed as an Approved Scanning Vendor |
| Match external scans to in-scope addresses (11.3.2) | List of public IP addresses and domains in scope, compared against the addresses in the ASV report | Scans omit a load balancer, cloud IP or payment-related subdomain that is exposed to the internet |
| Check rescans after failed external results (11.3.2) | Rescan reports showing every failing item resolved until the passing criteria are met | Report shows a failing result, and no later scan proves the fix |
| Confirm scans after significant changes | Change records linked to scans run after each significant change to the environment | Scans run only on the quarterly cycle, with no scan after a major network or application change |
Implementing quarterly scans and the fix-and-rescan cycle
This sequence turns Requirement 11.3 into a repeatable cycle: a defined scope, authenticated internal scans, an ASV-run external scan, and documented fixes verified by rescans. Each step leaves a record an assessor can sample.
Confirm scope and the asset inventory
The organization confirms which systems fall inside the cardholder data environment and which connected systems could affect it, then reconciles that list against an asset inventory of hosts, network devices, and public-facing addresses. The owner of the CDE scope signs off on the result. The output is a scope document listing every internal range, external address, and component to be scanned, with the date it was approved. Gaps found here, such as unlisted hosts, should be resolved before any scan runs.
Set up authenticated internal scanning
The security or platform team configures internal scans to log in to targets with credentials of sufficient privilege, so the scanner can see installed packages and patch levels rather than only open ports. Each credential is created for scanning use, stored in a vault, and recorded in a credential record that names the account, its owner, its privileges, and the systems it covers. A test scan against a few known hosts confirms that authenticated checks actually return package data. Requirement 11.3.1.2 makes this authentication mandatory, so the credential record is a core piece of evidence.
Select an ASV for external scans
The organization chooses an Approved Scanning Vendor from the PCI SSC list and agrees the external scope with it in writing, including the public addresses and any cloud or hosted ranges. External scans must be performed by an ASV, so an internal tool cannot produce this result. Ask the vendor to explain how it handles scan failures, rescans, and disputed findings, and confirm the terms cover the full quarterly cycle. The output is a signed scope agreement and the ASV's scan schedule.
Define a schedule no longer than 90 days
The team sets a recurring calendar for internal and external scans so that no interval between quarterly scans exceeds three months, or 90 days. The schedule names the owner of each scan, the target ranges, and the date of the next run, and it is stored with the scan policy. Assessors check the actual scan history against this schedule, so a missed run is visible. The output is a dated scan calendar and a policy statement that requires quarterly scanning.
Set remediation rules for each severity
The organization writes a remediation standard that requires high-risk and critical vulnerabilities to be resolved within a stated timeframe, with a rescan to confirm the fix. It also defines a targeted risk analysis for lower-risk findings, so that each deferred item has a documented rationale, an owner, and a review date. Timeframes must be set by the organization and approved by its governance owner, because no duration is fixed by the standard for this purpose here. The output is an approved remediation standard and a risk analysis template.
Open tickets and track each finding
Each scan result is triaged, and every finding that requires action is converted into a remediation ticket with the affected asset, severity, owner, and target date. Duplicates across scanners are merged, and false positives are closed only with a written justification reviewed by a second person. Tracking tools such as DefectDojo can import scanner output and deduplicate findings, though the team should confirm the import formats it uses. The output is a set of tickets linked to scan IDs and a log of accepted risks.
Rescan until each finding is resolved
After a fix is applied, the team reruns the relevant scan to confirm the vulnerability is gone, and the ticket closes only when the rescan shows it resolved. External scans continue until the ASV's passing criteria are met, so the ASV may need to be engaged more than once in a quarter. Recurring failures on the same asset are escalated to the owner of the configuration or patch process. The output is rescan results attached to each closed ticket and a final passing ASV report for the quarter.
Scan again after significant changes
When a significant change occurs, such as a new system in the CDE, a major software upgrade, or a network change, the team triggers a new internal and external scan in addition to the quarterly schedule. The change record links to the scan so an assessor can trace the link between change and test. The output is a scan result tied to the change ticket, along with any new findings routed through the same remediation cycle. Teams should confirm with their assessor what counts as significant in their environment.
Evidence that passes a PCI DSS 11.3 scanning review
An assessor reviewing requirement 11.3 wants a dated trail, not a single good report. The core set is the scan schedule and reports across the whole assessment period, scan configurations that show internal scans ran with credentials and sufficient privileges, and a scope list that matches the systems in the cardholder data environment (CDE) and connected networks. For external scanning, the key document is the ASV attestation report showing a passing status for each scan. Internal and external reports should each name the targets scanned, the scan date, the credentials used (recorded by account type, not by password), and the scanner version and plugin feed date. Confirm with your ASV and your scanner vendor which fields their reports include, because an assessor will look for them.
Remediation evidence is where most reviews stall. For each high-risk and critical internal finding, keep a ticket that links the finding to the fix, the owner, and the rescan report that confirms the vulnerability is gone. Lower-risk findings need a documented risk analysis explaining how they were prioritized under 11.3.1.1, since they are not all fixed on the same clock. For external scans, the ASV passing criteria in the current ASV Program Guide govern the result. As a working reference, PCI SSC FAQ 1087 treats 90 days as the maximum gap between quarterly scans, and a passing external scan generally carries no vulnerabilities scored 4.0 or higher on CVSS, per FAQ 1152. Confirm the exact criteria in the current guide before you set internal thresholds.
Keeping this current between audits is mostly administration. Store every report, ticket and attestation in one repository with a dated index that lists each scan, its type, its targets and its result. Run a monthly check that every quarter in the period has at least one internal and one external passing scan, and that every scan target still exists in the CDE asset inventory. Three common gaps appear repeatedly. Scans run without credentials, which produces a shallow report that does not meet the authenticated-scan requirement. Findings are marked closed without a rescan. Asset lists drift, so new servers or retired hosts are not added to or removed from the scan targets. Each gap is easy to prevent with a monthly check and a rule that a ticket closes only after a rescan.
What PCI DSS vulnerability scanning costs to run
This table lists each cost component of running Requirement 11.3 scanning, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to build a line-item request for quotes, and confirm the ASV fees and auditor evidence expectations before you commit to a scope.
| Cost component | Who is paid | One-time or recurring | Main drivers and how to keep it down |
|---|---|---|---|
| Scanner tooling or licenses | Scanner vendor, or no license fee for self-hosted open-source tools | Recurring if commercial; open-source removes license spend but not operating effort | Number of hosts and scan engines. Ask for scanner licensing as a separate line item in any written quote, and confirm whether the chosen tool is accepted for authenticated internal scan evidence. |
| Engineering time to configure authenticated scans and credentials | Your team or the implementation partner | One-time setup, with recurring credential rotation | Number of operating system types and privileged account models. Standardize scan accounts and document the privilege level each scan uses. |
| ASV external scan fees | PCI SSC Approved Scanning Vendor | Recurring, typically each quarter and after rescans where the vendor charges for them | Number of external IP addresses and domains in scope. Request ASV fees, rescan terms and any re-scoping charges as explicit line items in a written quote. |
| Remediation labor for high-risk and critical findings | Your system owners, patch teams or a contracted service | Recurring, driven by each scan cycle | Volume of findings and patch cadence. Reduce it by reducing the in-scope estate, fixing shared base images once, and tracking ownership per asset. |
| Rescan effort after fixes | Your team, and the ASV for external rescans | Recurring, after each remediation cycle | Number of fixes that must be verified. Group fixes into batches and confirm with the ASV how many rescans are included before passing. |
| Lower-risk finding triage and risk analysis | Your security team | Recurring, with an annual policy review | Volume of medium and low findings. A documented targeted risk analysis keeps this proportionate, and the risk rationale must be recorded for assessors. |
| Evidence upkeep | Your compliance or security operations staff | Recurring each quarter and after significant changes | Number of scan reports, tickets and approval records retained. Use a central findings tracker so reports and remediation records link to the same asset. |
| Scans after significant changes | Your team, and the ASV if external scope changes | Recurring, event-driven | Frequency of infrastructure and application changes. Tie scan triggers to the change management process so unplanned scan effort is visible. |
| Assessor sampling during the audit | Your QSA or assessor, through the audit engagement | Recurring each assessment cycle | Sample sizes the assessor selects and the completeness of your records. Ask the assessor in advance what scan evidence, date ranges and ticket trails they expect. |
Self-hosted tools that produce PCI DSS scanning evidence
Requirement 11.3 needs scan results that an assessor can trace from discovery through remediation and rescan. The tools below cover different parts of that chain: finding vulnerabilities on your own systems, inventorying installed software, and tracking findings to closure. None of them replaces an Approved Scanning Vendor for external scans.
Greenbone Community Edition (OpenVAS)
Greenbone Community Edition is built on OpenVAS and is licensed under AGPL-3.0-or-later. The gvmd service schedules scan tasks, stores results in PostgreSQL, and manages users and permissions, so you can show who ran each internal scan and when. Teams review results in the Greenbone Security Assistant web interface. Confirm that authenticated scans run with the privileges your assessor expects, and check how your team will handle the AGPL obligations if you modify and host the software for others.
Wazuh vulnerability detection
Wazuh is licensed under GPL-2.0-only. Each agent collects a software inventory from monitored endpoints, and the Wazuh manager correlates that inventory with the Wazuh CTI vulnerability repository or a locally hosted offline copy. This covers the operating system and installed applications, which gives you a continuous record of exposure between quarterly scans. Confirm whether your environment can reach the CTI repository or whether the offline copy must be maintained and dated, since assessors will ask how current the vulnerability data was.
Fleet host vulnerability matching
Fleet is licensed under MIT and detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. It suits fleets of workstations and servers where you need a current software inventory tied to vulnerability data. Before relying on it for 11.3 evidence, confirm which of these sources cover your operating systems and how the match results will be exported for your assessor.
DefectDojo finding tracking
DefectDojo is licensed under BSD-3-Clause and imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition. It deduplicates findings using per-tool hashcode fields and tracks remediation, so high-risk and critical findings can be followed to a fix and a rescan. Confirm that the report formats from your scanners are supported and that your remediation workflow and retention settings meet your own policy.
Who runs scans, who certifies them, and what to outsource
Your organization owns Requirement 11.3. That means it owns the scope of what is scanned, the credentials used for authenticated internal scans, the scan schedule, the remediation of findings, and the targeted risk analysis for lower-risk vulnerabilities. No outside party can take over that accountability, and an assessor will ask your staff, not a vendor, to explain why a finding was accepted or deferred.
- Scope and asset list: Decide which systems are in the cardholder data environment and connected networks, and keep the list current as systems are added or retired.
- Authenticated scan credentials: Approve and manage the privileged accounts that internal scans use, and record who holds them and when they were reviewed.
- Remediation decisions: Assign owners and deadlines for high-risk and critical findings, and document a risk-based decision for any lower-risk item that is deferred.
- Scan schedule and rescans: Set the quarterly internal cadence, trigger scans after significant changes, and confirm that fixed high-risk and critical items are rescanned.
- Management sign-off: Review scan results and exceptions regularly so the process is visibly operated, not only configured.
Before engaging any partner, confirm internally who signs off on risk acceptance and who answers assessor questions about scan history.
An implementation partner can prepare the systems that produce scan evidence, but it does not decide what is acceptable risk and does not replace your control owners. DeployOpen is one example of this role: it works inside the client's own infrastructure to configure scanners, connect inventory data, and set up the evidence and remediation workflow. Scope, decisions and sign-off stay with the client.
- Scanner configuration: Install, harden and schedule internal scanning tools, and set up authenticated scanning using credentials the client approves.
- Asset inventory feeds: Connect endpoint and software inventory so scan results map to the systems in your scope list.
- Evidence index and fix workflow: Store scan reports, tickets, rescan results and exception records in a form an assessor can trace from finding to closure.
- Rescans and reporting: Run rescans for the client after fixes and produce reports, with the client reviewing and accepting them.
- Documentation handover: Document configuration and runbooks so your staff can operate the process after the engagement.
When reviewing a proposal, ask the partner to state in writing which tasks it performs and which remain with your staff. A partner that offers to issue an ASV scan or attest to compliance is outside its role.
External scans must be run by a PCI SSC Approved Scanning Vendor, and the ASV is the party that attests to those results. The QSA or other assessor tests the whole Requirement 11.3 evidence set in the ROC or SAQ and issues the attestation for the assessment. Neither should design the controls they are testing, because a party that built the process cannot independently judge it.
- External scans: An ASV runs quarterly external scans and rescans until the passing criteria in the ASV Program Guide are met.
- Internal scan testing: A QSA samples internal scan reports, credentials, remediation tickets and rescans. A QSA or ASV is not required to perform internal scans.
- Independence limits: An assessor that wrote your scan procedures or configured your scanners cannot also validate them in the same assessment without a documented independence problem.
- What only the assessor issues: Only the QSA or the approved assessor issues the ROC or SAQ attestation. A consultant's report or a scanner's dashboard is not a validation.
- Questions to ask a QSA: Confirm which services the QSA is offering, how it separates consulting from assessment, and which evidence it will sample.
Before the assessment, check the ASV's current status on the PCI SSC list of approved vendors and confirm the assessor's qualifications for your entity.
Questions buyers ask about PCI DSS 11.3 scanning
Does an internal vulnerability scan need a QSA or an ASV?
No. Internal scans under Requirement 11.3.1 do not need a Qualified Security Assessor or an Approved Scanning Vendor, but they do need qualified, independent testers. The organization decides who runs them, and the work must be done by someone with the skill and separation from the systems being scanned that an assessor would accept. External scans are different: under Requirement 11.3.2, they must be performed by a PCI SSC Approved Scanning Vendor. Confirm with your QSA how they will judge tester independence in your environment, because that judgment sits with the assessor, not the scanning tool.
How often do PCI DSS vulnerability scans have to run?
Both internal and external scans must run at least once every three months. PCI SSC FAQ 1087 treats three months, or 90 days, as the maximum gap between quarterly scans, so a scan schedule that drifts past that window fails the requirement even if the findings are clean. Scans are also needed after significant changes to the environment, so the schedule should include a trigger for changes as well as the calendar. Your scan records should show each run date, its scope and the follow-up, because assessors check the dates against the schedule you documented.
Does an initial PCI DSS assessment need four passing quarterly scans?
No, not in every case. Under the note to Requirement 11.3.2 in the Self-Assessment Questionnaire D for Service Providers, an initial assessment does not need four passing quarterly scans when three conditions hold: the most recent scan passed, your policies require quarterly scanning, and any vulnerabilities found were corrected. PCI SSC FAQ 1152 covers the same question. Treat the conditions as a checklist you must evidence, not a shortcut, and confirm with your assessor that your situation qualifies before you rely on it.
What does PCI DSS scanning require from the team in staff time and credentials?
The main effort is people and access, not licenses. Internal scans must be authenticated with sufficient privileges under Requirement 11.3.1.2, so the team needs service accounts with rights to read system configuration and installed software, and those accounts must be managed under the access controls of Requirement 7 and Requirement 8. Someone must review results, triage lower-risk findings through the targeted risk analysis required by Requirement 11.3.1.1, and track high-risk and critical items to resolution with rescans. Ask any provider to state which of these tasks they perform, which your staff keep, and how credentials are stored and rotated.
Can a self-hosted scanner be used for PCI DSS internal scans?
Often yes, but confirm it with your assessor before you commit. Requirement 11.3.1 does not name a product, so an open-source scanner can satisfy the internal scanning requirement if it runs authenticated scans, covers the in-scope systems, produces reports you can retain, and is operated by qualified staff. Greenbone Community Edition, for example, schedules scan tasks and stores results in PostgreSQL, while Wazuh vulnerability detection correlates endpoint software inventory with vulnerability data. Neither should be assumed to meet every expectation. Ask the assessor to review the scanner configuration, credential method, scan coverage and report retention before the first assessment.
What does an ASV do, and how does an external scan pass?
An Approved Scanning Vendor runs the external scan against your internet-facing systems under the PCI SSC scanning program and issues the scan results that your validation depends on. Under Requirement 11.3.2, rescans continue until the ASV Program Guide passing criteria are met. According to PCI SSC FAQ 1152, a passing external scan generally has no vulnerabilities scoring 4.0 or higher on CVSS. Plan remediation time for each finding, because the scan will not pass while those vulnerabilities remain. Check the current ASV list on the PCI SSC website before selecting a vendor, and confirm which IP addresses and domains your scope covers.
Should we run PCI DSS scanning in-house or hire a partner?
The decision depends on who has the skills, time and access to run scans reliably every quarter and to keep evidence the assessor will accept. In-house teams suit organizations that already operate scanners, have people who can triage findings and can keep a quarterly calendar. A partner is useful when the work includes planning the scanner deployment, configuring authenticated scans, building the evidence pack or preparing systems before an assessment. External scans still come from an ASV, and the QSA issues the assessment conclusions. DeployOpen implements and documents self-hosted scanning platforms in the client's own infrastructure and prepares evidence for assessors, but it does not perform the ASV scan or issue any report. Ask for a fixed written scope that names deliverables, owners and dates.
How DeployOpen prepares 11.3 scanning evidence
DeployOpen plans and builds self-hosted open-source scanning inside your own infrastructure, so internal scan results, remediation records and rescans are documented in a form your assessor can test. Your organization owns the controls, and an Approved Scanning Vendor issues the external scan results that PCI DSS requires.
How we scope
- We agree the written scope in advance, listing the in-scope networks, hosts and cloud accounts that internal scans must cover.
- We identify which external addresses and services need an Approved Scanning Vendor scan, and where those scans fall outside our work.
- We confirm with your assessor and ASV which scanning cadence, authentication method and rescan rules apply to your environment.
How we build
- We deploy open-source scanners such as Greenbone Community Edition inside your network with credentialed access for authenticated internal scans.
- We configure scheduled quarterly scan tasks and rescan workflows so high-risk and critical findings are retested after remediation.
- We connect scan output to a findings tracker such as DefectDojo, so duplicate findings are removed and each item has an owner and status.
How we hand over
- We document scan procedures, scan schedules, scope lists, roles and remediation steps in a form your team can maintain without us.
- We deliver scan reports, remediation tickets and rescan results as an evidence package mapped to the 11.3 requirement for your assessor.
- We train your staff to run scans, review results and explain how significant changes trigger additional scanning.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement ends.
- We can keep scanner feeds, platform versions and scan schedules current so evidence stays consistent between assessments.
- Any change to scope, such as a new network segment or cloud account, is agreed in writing before we update the scanning configuration.
