Three Vulnerability Metrics Every Board Should Track Before the PCI DSS QSA Asks
When the Qualified Security Assessor arrives for your annual PCI DSS assessment, the conversation about vulnerability management rarely begins with how many scans you ran. It begins with what you found, how quickly you fixed it, and whether you know what you missed.
The Payment Card Industry Data Security Standard requires organizations that process, store, or transmit cardholder data to identify and address security vulnerabilities through regular scanning and remediation. Most boards receive monthly reports showing scan counts and total findings. These numbers tell you that activity occurred, but they do not tell you whether your vulnerability management program works or whether it will satisfy your assessor.
PCI DSS vulnerability management board metrics that matter are operational: they measure speed, coverage, and accountability. Three metrics in particular predict the questions your QSA will ask and reveal whether your program protects cardholder data or simply generates reports.
Why Scan Counts Do Not Answer the Board's Question
A board's responsibility is to ensure that management has implemented controls proportionate to the risk. In the context of PCI DSS Requirement 11.3, that means ensuring that vulnerabilities in systems handling cardholder data are identified and remediated before they can be exploited.
Knowing that 47 scans ran last quarter and 312 findings were recorded does not answer the essential question: are we safer this month than last month?
The number of findings fluctuates with asset changes, software updates, and scanning tool configurations. A rising count may indicate deteriorating security or improved detection. A falling count may indicate effective remediation or shrinking coverage. Without operational context, the board cannot distinguish between progress and drift.
Your QSA will not ask how many scans you completed. The assessor will ask whether your scans cover all systems in the cardholder data environment, whether high-risk findings are remediated within your own policy timelines, and whether exceptions are justified and monitored. These questions require different metrics.
Metric One: Remediation Velocity for Critical Findings
Remediation velocity measures the time between discovery of a critical or high-severity vulnerability and its closure, either through patching, compensating controls, or formal risk acceptance.
PCI DSS does not prescribe a specific remediation timeline for all findings, but it requires that organizations define their own risk-based approach and follow it consistently. Most mature programs set a 30-day window for critical vulnerabilities and 90 days for high-severity findings. The board should know whether management meets these timelines.
Track the median and 90th-percentile remediation times for critical findings each month. The median tells you what typically happens; the 90th percentile reveals whether outliers are managed or ignored.
If your median remediation time for critical findings is 12 days but your 90th percentile is 87 days, you have a process that works most of the time and fails predictably. Your QSA will ask why. More importantly, an attacker scanning your perimeter will find the same outliers.
Boards should ask three questions each month:
- What is our current median remediation time for critical findings, and is it within our policy limit?
- How many critical findings are currently open beyond our policy deadline?
- What is preventing closure of the oldest critical finding, and who owns the decision?
These questions shift the conversation from activity to accountability.
Metric Two: Coverage Percentage Across Cardholder Data Environments
Coverage percentage measures the proportion of in-scope systems that were successfully scanned during the most recent cycle.
A vulnerability management program that scans 95 percent of the cardholder data environment each month is not 95 percent effective—it is incomplete. The 5 percent you did not scan may include the payment gateway, the database server that was rebooted during the scan window, or the new point-of-sale terminal that was deployed but not added to the asset inventory.
Attackers do not skip systems because they were missed in your scan schedule. Your QSA will not either.
Coverage gaps arise from four common causes: incomplete asset inventories, authentication failures during scanning, systems taken offline during maintenance windows, and scope creep as new cardholder data flows are introduced without updating the scanning plan.
Boards should expect coverage to be 100 percent each cycle, with documented explanations for any gap and a remediation plan to close it before the next cycle. If coverage falls below 98 percent for two consecutive months, the program has a structural problem, not a temporary issue.
Ask management:
- What percentage of in-scope systems were scanned in the last cycle?
- Which systems were not scanned, and why?
- When will those systems be scanned, and who is accountable?
Coverage is a binary question: either you know the security posture of your entire cardholder data environment, or you do not.
Metric Three: Exception Age
Exception age measures how long a vulnerability has remained open under a formal risk-acceptance or compensating-control arrangement.
Not every vulnerability can be remediated immediately. Legacy systems may lack vendor patches, business-critical applications may require extended testing windows, and some risks may be accepted when the cost of remediation exceeds the risk. PCI DSS permits these exceptions, but it requires that they be documented, justified, and reviewed regularly.
Exception age reveals whether your risk-acceptance process is a deliberate governance mechanism or a backlog in disguise.
If your oldest exception is six months old, was reviewed last month, and remains justified by a documented business case and compensating controls, that is governance. If your oldest exception is 18 months old, was accepted by an IT manager who has since left the organization, and has never been reviewed by the board, that is technical debt masquerading as risk management.
Your QSA will review your exception register and ask whether each exception is still necessary, whether compensating controls are still effective, and whether the accepting authority is still appropriate. The board should ask the same questions before the assessor arrives.
Track the count and age of open exceptions each month. Set a policy that no exception may remain open longer than 12 months without board-level review and reauthorization. Require that every exception document the vulnerability, the business justification, the compensating controls in place, the residual risk, and the review date.
Boards should ask:
- How many vulnerabilities are currently under exception, and what is the oldest?
- When was each exception last reviewed, and by whom?
- What is the plan to eliminate or renew each exception before the next assessment?
Exception age is a measure of governance discipline. A rising average age indicates that risk acceptance has become risk neglect.
What These Metrics Tell Your QSA
When your Qualified Security Assessor reviews your vulnerability management program, the evidence trail begins with these three metrics.
Remediation velocity demonstrates that you have a functioning process to close gaps quickly. Coverage percentage demonstrates that you know your entire attack surface. Exception age demonstrates that risk decisions are deliberate, documented, and reviewed.
Together, these metrics answer the assessor's core question: does this organization manage vulnerabilities, or does it simply scan for them?
A board that tracks these metrics monthly can answer that question confidently. A board that sees only scan counts cannot.
Building the Metrics Into Your Program
These metrics require three operational components: an accurate and current asset inventory, regular authenticated scanning of all in-scope systems, and a remediation tracker that records finding ownership, target closure dates, and exception justifications.
Most organizations have the scanning tools but lack the process discipline to turn scan output into actionable metrics. The gap is not technical; it is operational.
A mature vulnerability management program includes defined remediation timelines based on risk severity, a formal exception and risk-acceptance process with board-level oversight for long-lived exceptions, and monthly reporting that shows trends in velocity, coverage, and exception age rather than point-in-time counts.
Boards should fund the program components that produce these metrics: asset discovery and inventory maintenance, authenticated scanning with credential management, and a remediation tracker that integrates with your ticketing and change-management systems.
The return on that investment is not faster scans—it is fewer surprises during your assessment and fewer opportunities for attackers between assessments.
How We Support Vulnerability Management for PCI DSS Environments
Our Vulnerability Management Program service is designed to produce the metrics and evidence that boards and QSAs require. We run or mature your vulnerability management through four operational components: asset inventory and scanning scope definition, regular authenticated scanning of internal and external systems, risk-ranked findings assigned to responsible owners, and remediation follow-up with reporting against agreed timelines.
Deliverables include a vulnerability management standard that defines your remediation timelines and exception process, monthly vulnerability reports that track the three metrics discussed in this article, a remediation tracker that records ownership and target dates for each finding, and an exception and risk-acceptance register that documents justifications and review dates.
The service operates on an ongoing monthly cycle, providing continuous visibility into your vulnerability posture and ensuring that your program remains aligned with PCI DSS requirements and your board's governance expectations.
We support organizations across SAMA CSF, NCA ECC, and PCI DSS frameworks, ensuring that vulnerability management integrates with your broader compliance and risk management programs.
If your board is preparing for a PCI DSS assessment and needs to move beyond scan counts to operational metrics, we can help you build or improve the program that produces them.
