PCI DSS Vulnerability Management Checklist for Municipal and Utility Environments

Here is a situation many utility and municipal IT teams actually live with: your SCADA historian runs on a Windows Server 2008 R2 box that the vendor says they can no longer support, but replacing it requires a three-year capital project. Your patch window is 4am on a Sunday if grid load is cooperating. And your PCI DSS auditor wants quarterly scan evidence showing you remediated CVEs within 30 days of discovery.

Those two realities do not reconcile neatly. But the auditors are not wrong, and the operational constraints are not disappearing. The teams that pass PCI DSS audits in these environments do not patch everything in 30 days — they document why they cannot, what they did instead, and they produce the evidence trail to prove it.

This guide covers what PCI DSS v4.0 specifically requires, what QSAs actually sample in utility environments, and how to build a vulnerability program that is defensible even when your infrastructure has constraints that a pure-cloud SaaS company never has to think about.

What PCI DSS v4.0 actually requires for vulnerability management

PCI DSS v4.0 (mandatory as of March 2024) tightened several requirements that hit infrastructure-heavy environments hard. The key requirements for vulnerability management:

• Requirement 6.3: Security vulnerabilities must be identified and addressed through a documented process — not just running scans, but tracking findings from discovery through to closure.
• Requirement 11.3: External and internal vulnerability scans must run at least quarterly AND after significant infrastructure changes. For utilities with frequent infrastructure changes — SCADA upgrades, substation additions, firmware updates — "after significant changes" means your scan cadence may need to exceed the quarterly minimum.
• Requirement 11.3.1.1: All applicable vulnerabilities — not just Critical and High — must be managed per a risk-based policy with defined remediation timeframes. This catches teams that only track their top-severity findings and let Medium findings accumulate unmonitored.
• Requirement 12.3.2: A targeted risk analysis must support any deviation from PCI DSS requirements, including delayed remediation timelines for operational reasons. This is your compensating control framework — and it is explicitly allowed.

The single biggest misconception: PCI DSS does not say you must patch every critical vulnerability in 30 days with no exceptions. It says you must have a policy, follow it, and document when you deviate and why. Your operational constraints — uptime requirements, vendor support gaps, maintenance window schedules — can be accommodated through a risk-based exception process. What QSAs cannot accept is an undocumented delay with no evidence of compensating controls.

The five controls QSAs sample first in utility environments

1. Documented scan cadence with timestamped evidence of execution

Quarterly scans are the minimum, but the evidence has to show the cadence is real — not just documented as a policy. QSAs ask for scan reports with timestamps. Not "we run quarterly scans" but "here are the scan exports from March 15, June 20, September 12, and December 8 with coverage maps showing which systems were included."

For environments with seasonal maintenance windows — utilities often schedule planned outages in spring and fall — document how your scan schedule aligns with those windows. If your quarterly scan has to shift because of a planned outage, document the reschedule and when the scan ran. A 10-day slip with a written record is defensible. A gap with no explanation is a finding.

2. Cardholder data environment scope and segmentation validation

Municipal utilities process customer payments — billing portals, in-person payment stations, online bill pay. Every system that touches cardholder data, or connects to a system that does, is potentially in PCI DSS scope. This includes back-office billing systems, payment terminals, and any network segment that can communicate with those systems.

Segmentation reduces your scope. An OT network that is physically and logically separated from the billing system is not in CDE scope. An OT network that shares a VLAN with billing systems — or where a workstation has access to both environments — is. Segmentation documentation is one of the first things QSAs examine: network diagrams, firewall rule exports, and penetration test evidence that the segmentation actually holds up under testing. "We believe they are separated" is not validation.

3. Finding-level remediation records with SLA tracking

Scan outputs alone are not sufficient. QSAs want to trace findings from discovery through remediation and closure. That means:

• Each critical and high finding has a ticket with an owner and a target remediation date.
• Ticket history shows the progression — not just the current state, but the work that happened.
• Findings that exceeded your remediation SLA have an exception record explaining why and what compensating controls applied.
• Closed findings have verification evidence — typically a rescan showing the finding is resolved, not just a technician saying it was fixed.

"We patched it" without a ticket trail does not satisfy a QSA sample request. The documentation of the remediation action is as important as the action itself.

4. Compensating controls for deferred remediation

When a critical CVE cannot be patched within your SLA — because the vendor has not released a patch, patching requires a maintenance window that is 45 days out, or the system is end-of-life — you need a compensating control record. This is not optional under PCI DSS v4.0. It is the documented alternative to meeting the standard requirement that the framework explicitly permits.

A compensating control record should include: the finding being excepted, the business reason for the delay, the specific controls applied (network isolation, enhanced monitoring, vendor-recommended workaround), who approved the exception, and when it expires. An exception without an expiration date is always an audit finding. Reviewers read stale exceptions as evidence that the process is not being managed.

5. Executive reporting demonstrating program oversight

PCI DSS requires evidence that senior management receives information about the security posture. QSAs look for vulnerability data reaching leadership — typically through monthly or quarterly reporting showing risk trend, open critical and high findings, SLA performance, and exception approvals.

This does not require a custom report. A concise dashboard export or a one-page summary with leadership acknowledgment satisfies this requirement. What QSAs cannot accept is security data that lives exclusively in the security team's ticketing system with no executive visibility or engagement.

Evidence QSAs commonly request from utility clients

If you can produce all of the following within 24 hours of a QSA request, your program is audit-ready. If locating any of these takes more than a few hours of manual effort, your evidence infrastructure needs attention before your next audit cycle.

• Last four quarters of scan reports for in-scope systems, with timestamps and asset coverage documentation.
• Your vulnerability management policy and SLA definitions for each severity tier.
• A sample of 5–10 critical and high findings from the past 12 months showing the full lifecycle: discovery, assignment, remediation action, and closure verification.
• Your current exception log with approvals, compensating controls documented, and expiration dates.
• Network segmentation documentation — diagrams, firewall configurations, and penetration test evidence that segmentation has been validated.
• Evidence of leadership reporting — meeting records, dashboard reports, or distributions showing vulnerability status reached management.

Three mistakes that create PCI DSS findings in utility environments

Treating OT systems as out of scope by default

If your SCADA network is truly air-gapped with no connection to cardholder data systems, it is out of scope. But many utility environments have partial connections — a historian server that feeds both the OT side and an analytics platform that is also connected to the enterprise network. When QSAs test segmentation and find a path that was supposed to not exist, that becomes a scope violation that can invalidate the entire prior compliance period.

Running scans without covering everything in scope

Quarterly scans that cover 80% of the CDE are not compliant. QSAs compare your asset inventory to your scan targets. Systems in scope that were not scanned generate findings regardless of whether they have known vulnerabilities. Keep your asset inventory and your scan scope synchronized, and document any system that was temporarily excluded from a scan and why.

Exceptions without expiration dates

An exception created three years ago with no expiration date is a flag that every QSA catches. Either the exception is still valid — in which case, renew it annually with current approval and updated compensating controls — or it should have been closed when the finding was remediated. Stale exceptions signal that the exception process is not being actively managed.