PCI DSS 4.0 and what changed for vulnerability management.
Requirement 11 did not get much stricter. It got much more specific — and the specifics are where the audit findings live.
8 min read
The headline in PCI DSS 4.0 is the move to customisable approaches. The change that affects security teams most is smaller: requirement 11 now enumerates what a vulnerability management programme has to demonstrably contain.
What is now explicitly required
| Obligation | What auditors will ask for |
|---|---|
| Rankings established | A documented method, and the ranking output per finding |
| Scope documented | Which systems and services are in the programme, and when it changed |
| Coverage documented | Authenticated scans, internal and external, at the defined cadence |
| Change detection | New vulnerabilities identified between scans are addressed on a defined schedule |
| Re-testing | Evidence that fixes were verified, with the rescan date |
Notice how much of that is evidence rather than capability. The scan is the cheap part; producing an auditor-readable trail of rankings, coverage and re-tests is what separates a programme that passes from one that spends six weeks in remediation.
The two that catch teams out
First, change detection. If a new asset appears between your scheduled scans, 11.3.2 expects a defined process for it. Programmes that scan weekly by cron and then discover the subdomain in question was up for nine weeks do not have that process.
Second, and more subtly, the requirement for authentication in internal vulnerability scans was added. Scanning only from the outside proves very little about segmentation. Most internal findings still surface as unauthenticated external findings, and auditors have started asking why.
How to get there without a rebuild
- Start with scope and coverage. If you cannot state them precisely, no tool will save you.
- Make ranking a function of recorded inputs so the method is reproducible.
- Attach the verification event to the finding, not to a spreadsheet.
- Export the register quarterly and keep it. Auditors have started asking for the previous one.
None of this requires new tooling. It requires deciding that the programme's output is a register rather than a report — which is the same shift described in every other piece we have written on this blog.
keep reading
Compliance · 8 min