PCI DSS Requirement 11.3: the scanning schedule that actually passes

The schedule Requirement 11.3 sets

Requirement 11.3 of PCI DSS v4.0.1 governs vulnerability scanning of the cardholder data environment, and unlike most security frameworks it doesn’t leave the cadence to your judgement. Three controls set the floor:

Do the arithmetic before you design anything. Four internal scans and four external scans a year is the minimum — before a single significant change happens. Each significant change adds an internal scan on top, so a year with a platform migration and two big releases isn’t a four-scan year on the internal side. Budget the work accordingly, including the remediation and re-checking that follows what the scans find, which is where most of the actual hours go.

Two properties of this schedule shape how you should run it. First, quarters don’t backfill. A quarter that passes without a scan is a permanent gap in the evidence — there’s no scan in month five that retroactively covers month two. That makes scanning a scheduling problem before it’s a technical one: the organisations that fail 11.3 rarely lack a scanner; they lack a schedule that runs without a human remembering. Second, the external scans aren’t yours to run. 11.3.2 requires an Approved Scanning Vendor — a vendor approved by the PCI Security Standards Council — so your own tooling pointed at your perimeter doesn’t count for this control, however capable it is. Get the ASV relationship and its quarterly rhythm established early; it’s a dependency you don’t fully control.

ISO 27001 handles the same discipline differently, and it’s worth knowing if you hold or want both. Annex A 8.8, Management of Technical Vulnerabilities, is the ISO cousin: same ground, but risk-based cadence instead of a fixed calendar. If you run the PCI schedule, you’ll generally have strong evidence for the ISO control as a side effect — the reverse is not true.

Authenticated scanning: the part that changes the result

11.3.1.2 is the control that quietly rewrites what “we scan quarterly” means. It requires internal scans to be authenticated — the scanner logs into targets with privileged credentials rather than probing them from outside.

The two scan types answer different questions. An unauthenticated scan sees what a stranger on your network sees: open ports, service banners, whatever responds to a probe. An authenticated scan with privileged credentials sees what an administrator sees: the installed packages, the actual versions, the configuration as it really is. A host can look clean from the outside and carry a long list of known-vulnerable software visible only from within — which is precisely why the authenticated requirement exists. A clean unauthenticated result isn’t a clean host; it’s an unexamined one.

This control brings operational obligations that deserve planning rather than improvisation. Privileged scanning credentials are exactly what they sound like — credentials with broad reach across your environment — so they need the same care as any other privileged account: stored properly, scoped to the scanning function, and watched. It also brings coverage questions: an authenticated scan only authenticates to hosts it can reach with credentials that work, so failed authentications need to show up in your scan review, not vanish silently into a smaller report. A scan that authenticated to half the estate looks reassuringly green while proving very little.

What the standard actually 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, not 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

What most people get wrong

The quarterly half of 11.3.1 gets all the attention, because a calendar is easy. The half that fails assessments is “after any significant change” — a trigger, not a date, and triggers need wiring.

Two things go missing. First, the definition: “significant change” never gets written down, so no change ever quite qualifies, and the trigger never fires. Second, the hook: even with a definition, nothing in the change process actually raises the scan — the change ships, everyone moves on, and the environment runs on the pre-change scan results until next quarter. Then the assessor reads your change records next to your scan records and asks the obvious question: here are the changes, where are the scans they triggered?

The fix is procedural and cheap. Define significant change in your change management process, make the post-change scan a closure condition for changes that meet it, and keep the pairing — this change, that scan — retrievable. When the assessor asks, the answer is a lookup, not a scramble.

How Secure60 handles this

Tools hand you a to-do list. We do the list — and run the security behind it. Our vulnerability management capability runs the internal schedule — quarterly and change-triggered, authenticated with properly managed privileged credentials — then does the part the scanner can’t: triaging findings, prioritising what’s actually 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; we make sure what those scans find gets fixed.