PCI DSS 4.0 Requirement 11.3: Internal vs ASV External Scans

PCI DSS 4.0 Requirement 11.3 splits vulnerability scanning into two obligations that are staffed differently, scored differently, and fail for different reasons: 11.3.1 internal scanning and 11.3.2 external scanning performed by a PCI SSC Approved Scanning Vendor (ASV). Teams that treat the two as one recurring chore usually find the gap during a QSA evidence review, when the assessor asks for four consecutive quarters of ASV Attestations of Scan Compliance and receives internal scan reports instead, or the reverse. This article covers what each sub-requirement demands, how a passing scan is defined for each, what authenticated internal scanning changed in v4.0, how to scope the cardholder data environment and connected-to systems correctly, what belongs in the evidence package, and the procedural reasons ASV scans fail on repeat.

Requirement 11.3.1 Internal Scanning versus 11.3.2 External ASV Scanning

The two sub-requirements share a quarterly cadence but almost nothing else. Internal scanning can be performed by internal staff or a third party, provided the person running the scan has organizational independence from the administrators of the systems being tested: a network engineer cannot scan and self-attest their own firewall estate. External scanning must be performed by a company the PCI Security Standards Council has certified as an ASV, using the methodology and automatic-fail conditions published in the ASV Program Guide, and the result has to clear the ASV’s own quality assurance process before it counts.

The independence requirement for internal scans trips up small security teams more than any other clause in 11.3.1. It does not require a separate company; it requires that the person reading the scan output is not the same person who would be graded on the result. A common, audit-safe pattern is to have the security team own the scan tool and reporting while system owners in IT operations own remediation, with tickets and close dates tracked separately from the scan schedule itself.

Quarterly Cadence, the Definition of a Passing Scan, and Rescan Rules

“At least once every three months” is generally read by assessors as four scans per rolling twelve-month period with no gap materially longer than 90 to 100 days between them. Sliding the schedule so two quarters compress together right before an assessment is a common finding. On top of the quarterly baseline, both 11.3.1.3 and 11.3.2.1 require an additional scan after any significant change: examples include adding a subnet to the CDE, replacing the perimeter firewall, or a major OS upgrade on a segmentation-relevant host. What counts as significant should be defined in the change management policy, not decided ad hoc when a QSA asks why no scan followed a given change ticket.

A passing internal scan means every vulnerability the organization’s own risk ranking classifies as high or critical has been resolved and confirmed by rescan. A passing external scan means no finding at or above a CVSS v3 base score of 4.0 and no automatic-fail condition, such as an unsupported SSL/TLS version or a leaking directory listing. Rescans are not optional paperwork: 11.3.1 and 11.3.2 both require a rescan that confirms the fix actually closed the finding, not just that a patch job reported success. Platforms that automate this step, such as SITEY, chain a retest against the specific finding to the remediation ticket’s close event, so a scan reports resolved only after the target has actually been reverified, not just marked done in a ticketing system.

If a passing scan cannot be achieved before the quarter’s window closes, do not skip the quarter. Submit the best available report, document the remediation plan and target date, and run the next scan as soon as the fix lands rather than waiting for the following quarter’s normal slot. Two consecutive failed or missing quarters is a materially worse finding than one late pass followed by a documented catch-up scan.

Authenticated Internal Scanning Expectations Introduced in 4.0

Requirement 11.3.1.2 requires internal scans to be authenticated, meaning the scanner logs in with valid credentials rather than probing from the network alone. This became a fully enforced control on 31 March 2025, so it is no longer treated as a future best practice in any assessment happening now. The reasoning is straightforward: an unauthenticated scan sees roughly what an outsider on the segment sees, while an authenticated scan sees the same patch level, installed software, and configuration state that a threat actor with a foothold, or a compromised low-privilege account, would see. Missing patches hidden behind a closed port are routinely invisible to unauthenticated scanning and routinely visible once credentials are supplied.

Three practical requirements come with this control. First, any system that genuinely cannot accept scan credentials, such as certain embedded appliances or network gear without a compatible agent, must be documented with the reason and a compensating scanning approach. Second, the scan account needs enough privilege to read patch and configuration state but not broad administrative rights across unrelated systems: a single domain admin account used for every scan target is a common but avoidable finding. Third, if the scan account can also be used for interactive login, it falls under the account management controls in Requirement 8.2.2, meaning it needs a unique identity and monitoring rather than being a shared, unmonitored service credential. Centralizing scanner credentials in one place, which is what scanner integration tooling such as SITEY’s is built to do, keeps that credential count small enough for a QSA to actually review during an assessment instead of chasing it across a dozen scan tool configurations.

Scan Scope: the CDE, Connected-to Systems, and In-scope Service Providers

Scope for both 11.3.1 and 11.3.2 extends beyond systems that directly store, process, or transmit cardholder data. It also covers connected-to and security-impacting systems, meaning anything that could affect the security of the CDE even without touching a PAN directly. Typical examples include:

• Jump boxes or bastion hosts used to administer CDE systems
• Directory services and identity providers that authenticate CDE administrators
• Patch management, configuration management, and monitoring servers with reach into the CDE
• NTP, DNS, and logging infrastructure the CDE depends on for integrity or forensics

Requirement 11.4 segmentation testing is what actually confirms these boundaries. When a segmentation control fails, systems previously treated as out of scope become in scope for that assessment cycle, and the next scan needs to reflect the corrected boundary. Reconciling the internal and external scan target lists against the current network diagram before each quarter, rather than reusing last quarter’s IP list by default, is the single most effective way to prevent scope mismatches. Keeping that reconciliation in one scan management view alongside the asset inventory, instead of a spreadsheet updated only before an assessment, is what keeps the target list from drifting silently between quarters.

For service providers, a third party that hosts or processes any part of the CDE either runs its own ASV scans and provides the resulting AoSC to the merchant, or the merchant scans whatever portion of the environment it can legitimately reach. Shared or multi-tenant infrastructure adds a wrinkle: the ASV Program Guide requires providers’ permission before scanning shared IP ranges, since an aggressive scan against a multi-tenant address can affect other tenants who never authorized it.

Evidence Package: Scan Reports, Remediation Records, and Four Consecutive Passing Quarters

A QSA or acquirer reviewing 11.3 compliance typically wants to see the following, organized by quarter rather than assembled retroactively:

• The four most recent internal scan reports plus rescan reports demonstrating that each high or critical finding closed
• The four most recent ASV Attestations of Scan Compliance, or documentation of the ASV dispute process for any contested finding
• A scope statement or network diagram that matches the IP and hostname list actually configured in the scan tool for that quarter
• Remediation tickets tied to individual findings, each with a close date that lines up with the corresponding rescan date

Organizations in their first PCI DSS cycle can show evidence covering the period since the program started rather than a full four quarters, but the target for business-as-usual operation is a rolling four consecutive quarters without a gap. A single scan run today often surfaces findings that map to more than PCI DSS alone: the same missing patch is relevant to ISO 27001 Annex A control language and to SOC 2 CC7, for instance. Tagging each finding once and mapping it to every applicable framework, which is the role a dedicated compliance mapping layer such as SITEY’s plays, avoids re-deriving the same evidence package by hand before every separate audit.

Procedural Reasons ASV Scans Fail and How to Prevent Repeat Failures

Many ASV scan failures have nothing to do with an actual vulnerability and everything to do with process. The recurring ones are worth checking before every quarterly window:

1. Firewall or WAF blocking the ASV’s scanning IP ranges mid-scan, which produces an incomplete result rather than a pass. ASVs publish their current scanning IP ranges each cycle; whitelist them again every quarter rather than assuming last quarter’s rule still matches, since ranges do change.
2. Scope drift. A new external IP, subdomain, or load balancer added after the last scope confirmation isn’t in the ASV’s target list at all, so it never gets scanned and the gap surfaces later as a compliance finding rather than a scan failure.
3. Legacy TLS or weak cipher suites left enabled on a load balancer to support one old internal client, triggering an automatic-fail condition even though the primary domain’s configuration looks correct.
4. Compensating controls disputed informally instead of through the ASV Program Guide’s formal vulnerability dispute process. An email to the acquirer explaining why a finding doesn’t apply does not change the scan result; only a documented dispute submitted to the ASV does.
5. Certificate rotation scripted without updating scope monitoring, so an expired or mismatched certificate gets flagged mid-cycle on a host nobody was actively watching.
6. Patch installed without confirming the service restarted, so the vulnerable process is still running from before the patch even though the package manager reports the update installed successfully.

That last case is the one worth building a rule around: a rescan needs to confirm the specific finding actually closed against the running target, not that a deployment job exited cleanly. Systems that automate this step, SITEY among them, re-test the exact finding rather than trusting the patch command’s exit code, which catches the restart-pending case before it shows up as a repeat failure on the next ASV cycle.

About SITEY

SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.