PCI DSS Requirement 11.3 Vulnerability Scanning Schedule

The schedule Requirement 11.3 sets

Requirement 11.3 of PCI DSS v4.0.1 governs vulnerability scanning of the cardholder data environment, and it fixes the cadence rather than leaving it to judgement. Three controls set the floor.

The minimum is four internal scans and four external scans a year, before any significant change occurs. Each significant change adds an internal scan, so a year containing a platform migration and two major releases is not a four-scan year on the internal side. The remediation and re-checking that follow the scan results account for most of the hours.

Two properties of this schedule shape the implementation. Quarters do not backfill: a quarter that passes without a scan is a permanent gap in the evidence, with no later scan covering it retrospectively. That makes scanning a scheduling problem before a technical one, and organisations that fail 11.3 usually have a scanner and lack a schedule that runs without human intervention. And the external scans are not yours to run: 11.3.2 requires an Approved Scanning Vendor approved by the PCI Security Standards Council, so your own tooling pointed at your perimeter does not satisfy the control. The ASV relationship and its quarterly rhythm are a dependency outside your direct control and worth establishing early.

ISO 27001 covers the same discipline differently. Annex A 8.8, Management of Technical Vulnerabilities, addresses the same ground with a risk-based cadence rather than a fixed calendar. Running the PCI schedule generally produces strong evidence for the ISO control; the reverse does not hold.

Authenticated scanning changes the result

11.3.1.2 requires internal scans to be authenticated, with the scanner logging into targets using privileged credentials rather than probing them from outside.

The two scan types answer different questions. An unauthenticated scan sees what a stranger on the network sees: open ports, service banners, and whatever responds to a probe. An authenticated scan with privileged credentials sees what an administrator sees: installed packages, actual versions, and the configuration as it stands. A host can present as clean externally while carrying a long list of known-vulnerable software visible only from within, which is why the authenticated requirement exists. A clean unauthenticated result indicates an unexamined host rather than a clean one.

The control brings operational obligations that need planning. Privileged scanning credentials have broad reach across the environment and require the same handling as any other privileged account: stored properly, scoped to the scanning function, and monitored. Coverage also needs verification, because an authenticated scan authenticates only to hosts it can reach with credentials that work. Failed authentications have to surface in the scan review rather than reducing the report silently, since a scan that authenticated to half the estate produces a clean-looking result over partial coverage.

What the standard says

Paraphrasing PCI DSS v4.0.1: control 11.3.1 requires internal vulnerability scans to be performed at least once every three months and after any significant change. Control 11.3.1.2 requires those internal scans to be performed via authenticated scanning, with the scanner using privileged credentials on the systems it assesses. Control 11.3.2 requires external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor. This is a paraphrase rather than the standard’s wording; the authoritative text is PCI DSS v4.0.1, available from the PCI Security Standards Council.

The equivalent control in other frameworks

The change trigger fails more often than the calendar

The quarterly half of 11.3.1 is straightforward to operate. The half that fails assessments is “after any significant change”, which is a trigger rather than a date and has to be wired into a process.

Two components go missing. The definition: where “significant change” is never written down, no change qualifies and the trigger never fires. And the hook: even with a definition, nothing in the change process raises the scan, so the change ships and the environment runs on pre-change scan results until the next quarter. The assessor then reads the change records alongside the scan records and asks which scans the recorded changes triggered.

The remedy is procedural. Define significant change in the change management process, make the post-change scan a closure condition for changes that meet the definition, and keep the pairing of change to scan retrievable.

How Secure60 handles this

Secure60 operates the scanning programme and keeps its evidence current. Our vulnerability management capability runs the internal schedule — quarterly and change-triggered, authenticated with properly managed privileged credentials — then covers what the scanner does not: triaging findings, prioritising what is exploitable in your environment, and keeping per-quarter evidence of scans and remediation ready for your assessor. External ASV scans stay with your Approved Scanning Vendor, as the standard requires, and we make sure what those scans find is remediated.