Every security leader eventually has to stand in front of a room that does not speak in CVE identifiers and answer one question. Is the vulnerability program working. The people asking are not hostile. They are accountable, and they want a number they can defend. The trouble is that the most available number, the raw count of open findings, answers the wrong question. It measures how busy the scanners are, not whether the organisation is safer than it was last quarter. A program can cut its open count in half by tuning a scanner to report less, and nothing about its actual exposure will have changed.
This article is about choosing the handful of metrics that survive that meeting. Not a long catalogue of everything a tool can chart, but the specific KPIs a security leader should put on a board slide, why each one earns its place, and how to read it without misleading yourself. Every metric described here is grounded in how PMAP computes it, because a KPI is only worth presenting if the number behind it is reproducible and scoped to the data the viewer is allowed to see. The goal is a dashboard a leader opens first thing in the morning and trusts enough to forward upward without rebuilding it in a spreadsheet the night before.
Analytics is the reading-back stage of the program. Findings get ingested, correlated, triaged, and remediated, and then the same records are read as evidence that the work happened. For the full program-level picture of how that evidence becomes board-ready reporting, start with the pillar on vulnerability risk analytics and reporting. This piece zooms into the metric layer underneath it: which KPIs, which SLA signals, and which rankings actually deserve a leader’s attention.
Why Counting Findings Is Not Reporting Progress
A count is a volume measurement, and volume is a poor proxy for risk. Ten thousand low-severity informational findings on isolated lab hosts represent far less exposure than forty critical findings on internet-facing production systems, yet a naive open-count makes the first program look two hundred and fifty times worse. The count rewards whatever inflates the queue and punishes whatever drains it, which is exactly backwards from how a security leader wants the organisation to behave.
Progress is a comparison, not a snapshot. It only exists relative to a previous state, a committed deadline, or a concentration of risk that should be coming down. That is why a credible KPI set never stops at a single number. It pairs the current value with the period before it, it measures how much of the backlog is breaching its service-level commitments, and it ranks where the remaining risk actually lives so effort goes to the assets that matter. A dashboard that shows only totals invites the wrong reaction, because a total that went up could mean the scanners found more or that the team imported a new estate, and a total that went down could mean real remediation or a quiet scope reduction.
PMAP draws a deliberate architectural line that makes these metrics trustworthy in the first place. Its analytics layer is a read-only intelligence surface that sits downstream of everything else in the platform. It does not own findings, assets, projects, or SLA timers. It reads them. Every aggregate is computed from the live records that triage and remediation already maintain, so a KPI can never drift away from the underlying data, and there is no separate reporting database to reconcile. The number on the executive’s screen and the finding the analyst is editing are two views of the same source of truth.
The KPI Snapshot a Leader Opens First
The top of the dashboard is a single-call KPI snapshot, and it is deliberately small. PMAP computes it in one aggregate query and surfaces it as a row of tiles: total assets, open findings, urgent findings, critical findings, SLA breaches, and active projects. There is also an integration count for operational context. Six headline numbers is not an accident of layout. It is the largest set a non-specialist can hold in working memory at once, and it covers the three things a leader needs in the first ten seconds. How much do we protect, how much is outstanding, and how much of the outstanding is severe or already late.
Each tile is built to answer for itself. Total assets is the denominator that keeps everything else honest, because an open-finding count means something very different across two hundred assets than across twenty thousand. Open findings is the live workload. Urgent and critical are broken out separately rather than buried inside the total, because severity is where a leader’s attention belongs. SLA breaches is the accountability number, the count of findings that have already passed the deadline the program committed to. Active projects gives the engagement context that explains why the other numbers look the way they do.
Because the snapshot is a single aggregate call rather than a fan-out of many queries, it loads fast enough to be the first thing the page paints. Speed matters more than it sounds. A dashboard that takes several seconds to settle is a dashboard a busy leader stops opening, and a KPI that nobody opens is not a KPI at all. The tiles are also clickable. Selecting one navigates straight into the filtered findings or assets list behind it, so the snapshot is not a dead end. It is the entry point into the detail when somebody asks the inevitable follow-up about which findings those are.
Current vs Previous Period With Trend Arrows
A number alone cannot tell you whether you are winning. Forty critical findings is alarming if it was twenty last month and reassuring if it was eighty. That is why PMAP layers a period comparison on top of the snapshot. A dedicated trends call returns a current period and a previous period side by side for six counts: new findings, open-new, urgent, critical, SLA breaches, and new assets. The tiles render with trend arrows so the direction of travel is visible before anyone reads the digits.
The comparison window is configurable, and the defaults are chosen for how people actually report. The period comparison defaults to a seven-day window and accepts up to ninety days, which maps cleanly onto a weekly stand-up, a monthly review, or a quarterly board cycle. Setting it to seven gives this week against last week. Setting it to thirty gives this month against the previous month. The point of the arrows is to move the conversation from the static question of how many findings exist to the dynamic question of whether the line is bending the right way, which is the only version of the question that measures progress.
Reading these arrows well requires one discipline. A rising new-findings count is not automatically bad and a falling one is not automatically good, because both are sensitive to scanning cadence and scope. The arrow that almost always means what it looks like is the SLA breach trend, because a breach is a deadline the program set for itself and then missed. When that arrow points up, the program is falling behind its own commitments regardless of how many new findings arrived, and that is the trend a leader should be most willing to escalate on.
Severity and Status Distributions That Drill Down
Two findings are not interchangeable, and a program that treats them as interchangeable will mis-spend its remediation budget. PMAP surfaces this through two distribution widgets that sit just below the snapshot. The severity distribution breaks every finding across the six severity levels the platform tracks, from urgent and critical down through high, medium, low, and informational. The status distribution breaks the same population across nine status values, from open and assigned through in-progress, retest, closed, reopened, false positive, accepted risk, and not accessible. Together they answer the two questions a snapshot cannot. How dangerous is the backlog, and where in the workflow is it stuck.
The severity donut is the shape of your risk. A backlog that is mostly informational with a thin band of critical is a very different management problem than a backlog evenly spread across high and critical, even when the totals match. The status bar is the shape of your process. A pile-up in the open or assigned columns points at a triage or capacity bottleneck, while a pile-up in retest points at verification lag rather than remediation lag. A leader who can see both shapes at a glance can tell the difference between a team that is overwhelmed and a team that is simply waiting on confirmation, and those two situations call for opposite responses.
Neither widget is a terminal display. Clicking a severity slice or a status segment navigates directly into the findings list filtered to exactly that slice. This drill-through is what keeps the dashboard honest in a meeting. When somebody points at the critical wedge and asks which findings those are, the answer is one click away rather than a separate query somebody has to run afterwards. The distributions also respect every active filter on the page, so a leader looking at a single subsidiary or a single project sees the severity and status shape for that scope alone, never the whole tenant blurred together.
SLA Health as a Headline Metric
Service-level commitments are where a vulnerability program stops being a best-effort activity and becomes an accountable one. A finding without a deadline is a suggestion. A finding with a deadline the organisation agreed to is an obligation, and the rate at which the program meets or misses those obligations is the single most defensible KPI a security leader can present, because it measures the program against its own promises rather than against an external benchmark.
PMAP exposes SLA health as a first-class analytics surface. The core call always returns the breach and compliant counts, the resulting breach rate, and the average days-to-close broken out by severity. Those four numbers form a complete accountability picture. The breach rate tells leadership what fraction of the workload is already late, and the average days-to-close by severity tells them how fast the team actually resolves issues at each level of urgency. Reporting days-to-close per severity rather than as a single blended average is deliberate. A program can hit its critical deadlines reliably while letting mediums drift for months, and a blended number would hide exactly that pattern. Splitting by severity surfaces it.
The SLA surface also offers optional depth that a leader can switch on without over-fetching by default. A breach trend can be returned at daily or weekly granularity to show whether the program is gaining or losing ground over time, and per-company and per-project health breakdowns can be requested to locate where the breaches concentrate. Those optional sections are gated behind explicit request parameters so the standard call stays lean, and the heavier breakdowns only load when somebody actually needs to answer where the problem lives. The breach rate belongs on the board slide. The per-company breakdown belongs in the follow-up conversation about which business unit needs help.
This article treats SLA as a metric you read. The mechanics of how those thresholds get set, how deadlines recalculate, and how breaches escalate are a configuration topic covered in SLA thresholds and three-level escalation routing. Here the point is narrower. Whatever your thresholds are, the breach rate and the per-severity days-to-close are the two SLA numbers that earn a place on the executive view.
Risk Rankings: Assets, Companies and Projects
Once a leader accepts that not all findings are equal, the next question follows immediately. Where is the risk concentrated. A flat list of findings cannot answer that, because risk is not evenly distributed across the estate. It clusters on a handful of assets, a few business units, and certain projects, and remediation effort produces the most exposure reduction when it is aimed at those clusters first. PMAP answers this with three ranking surfaces that sit on the same scoring foundation: per-asset, per-company, and per-project.
The asset risk ranking is the sharpest of the three. It scores every asset and exposes both a full list and a top-twenty shortlist ordered by risk descending, so a leader can ask for the twenty assets that should be hardened next and get a defensible answer rather than a gut feel. The company risk ranking rolls the same logic up to the business-unit level, reporting each company’s open findings, severity breakdown, average asset risk score, and the name of its single highest-risk asset, which is exactly the view a platform admin benchmarking subsidiaries needs. The project risk ranking does the equivalent for engagements, surfacing open findings, severity breakdown, and a weighted overall risk score per project.
These rankings turn the abstract idea of risk-based prioritisation into an ordered worklist. Instead of debating which fire to fight, the team works the top of the list down, and leadership can see the highest-risk asset by name on a single line. The rankings respect the same tenant scope as every other metric, so the shortlist a viewer sees is built only from the assets, companies, and projects their role is allowed to see.
How the Asset Risk Score Is Built
A ranking is only as trustworthy as the formula behind it, so it is worth being precise about how PMAP computes an asset risk score. It is not a black box. The base score weights the open findings on an asset by severity: each urgent finding contributes twelve points, each critical ten, each high seven, each medium four, and each low one. That base captures the simple intuition that severe findings should dominate the score, with the weights chosen so that one urgent finding outranks several mediums.
The base is then multiplied by three factors that reflect context the raw severity counts miss. The first is asset criticality: a critical asset multiplies the score by two, a high-criticality asset by one and a half, a medium-criticality asset by one, and a low-criticality asset by one half. The intuition is that the same vulnerability matters more on a business-critical system than on a disposable one. The second factor is an SLA penalty. If an asset has any findings that have breached their deadline, its score is multiplied by one and a quarter, pushing assets that are already late toward the top of the list. The third factor is exposure. If an asset is not internal, meaning it is reachable from outside, its score is multiplied by one and a fifth, because an internet-facing weakness is more dangerous than the same weakness behind the perimeter.
The full computation is base multiplied by criticality factor, multiplied by the SLA factor when breaches exist, multiplied by the exposure factor when the asset is external. Two assets with identical severity counts can therefore rank very differently if one is a critical internet-facing host with overdue findings and the other is an internal low-criticality box that is meeting its deadlines, which is exactly the discrimination a prioritisation list needs to be useful. Project risk scores use the same base severity weighting but omit the criticality, SLA, and exposure multipliers, because a project does not carry those asset-level attributes itself.
Trends, Age Buckets and Chronic Findings
A snapshot tells you where you are. A trend tells you where you are going. PMAP’s finding-trends surface returns a daily time-series of created, closed, and open counts over a configurable window that defaults to thirty days and extends to a full year. Plotted together, the created and closed lines reveal the dynamic that totals hide. When the closed line consistently sits above the created line, the backlog is draining. When created outpaces closed, the program is falling behind no matter how good any single day’s numbers look. The period selector lets a leader move between a tactical seven-day view and a strategic year-long view of the same three lines.
Trends explain motion. Age buckets explain stagnation. The age-bucket widget distributes open findings across bands, typically zero to seven days, eight to thirty, thirty-one to ninety, and over ninety days. This is a remediation backlog histogram, and its right tail is the part that should worry a leader most. Findings sitting in the over-ninety-day band are not new arrivals the team has not reached yet. They are issues the program has known about for a quarter and not resolved, and a growing right tail is an early warning that something structural is preventing closure long before it shows up as an SLA breach.
The most stubborn problems are the ones that keep coming back, and PMAP isolates them with a recurring and chronic summary. Recurring findings are those that have reopened at least once, meaning a fix did not hold or the issue resurfaced. Chronic findings are those seen across two or more scans, meaning they persist wave after wave. The summary reports both totals alongside a severity breakdown and the top five companies carrying them. This rollup is served from a pre-computed materialized view for sub-millisecond response even at enterprise cardinality, and every response carries a refreshed-at timestamp so a consumer can see exactly how current the number is. A high recurring count is a signal that remediation is treating symptoms rather than root causes, which is the most expensive failure mode a program can have because the same work gets paid for repeatedly.
Taxonomy MTTR: Which Vulnerability Classes Drag
Counts and rankings tell a leader how much risk exists and where it sits, but they do not explain why the same kinds of problems keep appearing. Answering that requires looking at findings by class rather than by location, and PMAP does this through its taxonomy analytics. Every finding can be tagged against canonical taxonomy codes along three dimensions: effects, root causes, and remediation techniques. The taxonomy distribution widget then reports finding counts and severity breakdown per code, so a leader can see at a glance whether the backlog is dominated by a few recurring root causes or spread thinly across many.
The metric that turns taxonomy from interesting into actionable is taxonomy MTTR. PMAP computes the mean time to remediate, in days, for each taxonomy code, calculated only on findings that have actually closed so the number reflects real resolution time rather than open-ended guesses. This surfaces which vulnerability classes drag. A category with a high MTTR is one the organisation is consistently slow to fix, and slow remediation usually points at a structural cause: a missing skill, an ownership gap, a vendor dependency, or a fix that is genuinely hard in the environment. Knowing that a particular root cause carries a thirty-day MTTR while others close in three is the difference between a vague sense that some things are slow and a specific case for investing in a root-cause elimination programme.
The taxonomy view also offers a trend dimension, a weekly new-finding count per code over a rolling window that defaults to ninety days and extends to a year, suitable for a sparkline that shows whether a given class is growing or shrinking. The three dimensions are validated strictly: a request for any dimension other than effects, root causes, or remediation techniques is rejected rather than silently reinterpreted, which keeps the data clean and the charts trustworthy. For a security leader, the combination of distribution, MTTR, and trend per class is what moves the program from chasing individual findings to eliminating the categories that generate them.
Team Performance and Capacity Planning
Metrics that only describe the backlog leave out the people working it, and capacity is often the real constraint a leader is trying to reason about. PMAP closes that gap with team performance analytics. For each team it reports the current open load, the count of findings closed this month, the average MTTR in days, and the top root-cause code that team is dealing with. The numbers are scoped to the viewer’s tenant like every other metric, and they are organised per team so a manager can compare load and throughput across the groups they oversee.
This is the view that makes capacity planning evidence-based instead of intuitive. A team carrying a heavy open load with a slow MTTR is a candidate for reinforcement or for reassignment of work, while a team closing a high volume this month with a fast MTTR has headroom that could absorb more. The top root-cause field adds a qualitative layer to the quantitative one, because a team whose dominant root cause is a single recurring category may be better served by fixing that category at source than by simply being handed more findings. Read alongside the age buckets and the recurring summary, team performance tells a leader not just that the program is behind, but whether the bottleneck is workload, throughput, or a structural problem that no amount of extra hands will solve.
Always Scoped, Always Current
Two properties decide whether a dashboard can be trusted in front of leadership, and PMAP enforces both in the data layer rather than leaving them to the front end. The first is scope. Every aggregate the analytics layer computes attaches the tenant scope from the authenticated user’s context to its query. Cross-tenant data never surfaces, even on a platform-wide aggregate, and even if a caller passes arbitrary company or project identifiers, because those filter parameters apply additively on top of the scope rather than overriding it. A user can narrow what they see to a subset of their own data, but they can never widen it beyond what their role permits. An executive looking at a company-wide KPI snapshot is seeing exactly the slice of data their role allows, no more and no less.
The second property is freshness. Because the analytics layer reads directly from the live finding, asset, project, and company tables, almost every metric reflects the current state of the platform at the moment of the query. There is no nightly export to fall out of sync and no separate reporting copy to reconcile. The one deliberate exception is the recurring and chronic summary, which is served from a materialized view to keep its heavy rollup sub-millisecond. That view is refreshed on a schedule, and every response carries a refreshed-at timestamp so a consumer can see precisely how current the number is rather than assuming it is live. Honesty about staleness is itself a feature, because a number that is slightly stale and labelled as such is more trustworthy than a number that pretends to be live and is not.
Together these two properties are what let a leader forward the dashboard upward without a disclaimer. The metric is the right scope by construction and it is current by construction, so the conversation can be about what the numbers mean rather than whether the numbers can be believed.
How PMAP Turns Data Into a Read-Only Intelligence Layer
Step back from the individual widgets and a single design decision explains why all of them hold up. PMAP’s analytics is a read-only intelligence layer. It writes nothing. It owns no records of its own. It is a lens over the same operational data that triage and remediation maintain, and that single architectural choice is what makes every KPI in this article reproducible rather than reported.
A read-only design has consequences that matter directly to a security leader. Because analytics never mutates a finding, it cannot accidentally change one while reporting on it, so there is no risk that opening a dashboard alters the data underneath it. Because it computes from live tables, the dashboard a manager sees and the finding an analyst is editing are guaranteed to be the same source of truth. And because every aggregate carries the tenant scope, the metric is right for the viewer by construction rather than by a layer of permission checks bolted on afterwards. The result is a metric surface that a leader can build a board narrative on, because the numbers behind the narrative are exactly the numbers the program runs on.
The practical takeaway is short. Do not report volume, report progress. Pair every count with the period before it, lead with the SLA breach rate because it measures the program against its own promises, rank risk so effort goes where exposure concentrates, and use taxonomy MTTR to attack the classes that keep coming back. Put those few metrics on the slide and the answer to whether the program is working stops being an opinion and becomes a number you can defend.
If you want the step-by-step mechanics of reading these surfaces inside the platform, the practitioner guide on reading risk analytics and SLA KPIs walks through each widget in order. To put the right metrics on your next board slide, read the risk analytics datasheet and start from the snapshot.
Frequently Asked Questions
Which vulnerability KPIs should go on an executive or board slide?
Lead with a small set. The six-tile snapshot of total assets, open findings, urgent, critical, SLA breaches, and active projects gives the headline posture in one glance. Pair it with the SLA breach rate, because that measures the program against its own committed deadlines, and add the period comparison so leadership sees direction, not just a static number. Risk rankings answer where to focus next, and taxonomy MTTR answers which classes keep dragging. Resist the urge to present raw open counts alone, because volume measures activity rather than risk.
What is the SLA breach rate and why is it the most defensible KPI?
The SLA breach rate is the fraction of findings that have passed the deadline the program committed to for their severity. PMAP computes it from breach and compliant counts in the same call that returns the average days-to-close by severity. It is the most defensible KPI because it judges the program against its own promises rather than an external benchmark. A breach is unambiguous: the deadline existed, it was agreed, and it was missed. When the breach trend points up, the program is falling behind its commitments regardless of how many new findings arrived.
How does PMAP calculate MTTR and taxonomy MTTR?
MTTR is mean time to remediate, measured in days. Taxonomy MTTR computes that mean per canonical taxonomy code along the effects, root-cause, or remediation-technique dimension, and it is calculated only on findings that have actually closed so the number reflects real resolution time. A high taxonomy MTTR identifies a vulnerability class the organisation is consistently slow to fix, which usually points at a structural cause worth a dedicated root-cause programme rather than case-by-case firefighting.
How is the asset risk score computed?
The base score weights open findings by severity: urgent twelve, critical ten, high seven, medium four, low one. That base is then multiplied by an asset-criticality factor (critical two, high one and a half, medium one, low one half), by one and a quarter if the asset has any SLA-breached findings, and by one and a fifth if the asset is external rather than internal. So a critical, internet-facing asset with overdue findings ranks far above an internal low-criticality asset with the same severity counts. Project risk scores use the same severity weighting but omit the criticality, SLA, and exposure multipliers.
How current are the numbers, and can one tenant see another tenant’s data?
Almost every metric is computed live from the finding, asset, project, and company tables at query time, so there is no nightly export to fall out of sync. The single exception is the recurring and chronic summary, served from a materialized view for speed, which carries a refreshed-at timestamp so you can see exactly how current it is. Cross-tenant data never surfaces. Every aggregate attaches the authenticated user’s scope, and company or project filters apply additively on top of that scope, so a viewer can narrow what they see but never widen it beyond what their role permits.
What is the difference between this and configuring SLA thresholds?
This article treats SLA as a metric you read: the breach rate, the per-severity days-to-close, and the breach trend. Setting the deadlines themselves, defining severity-to-hours thresholds with company and project overrides, recalculating deadlines, and routing breaches through escalation contacts is a configuration topic covered in SLA thresholds and three-level escalation routing. Read this piece to know which SLA numbers belong on the executive view, and read that one to set the thresholds those numbers measure against.
Can each role build its own view of these KPIs?
Yes. The metrics described here are the data behind the widgets, and how those widgets are arranged into per-role, persisted dashboards is its own topic. An executive landing view, an analyst drill-down board, and a team-lead capacity view can each be composed from the same KPI, SLA, severity, ranking, and taxonomy surfaces. The companion article on configurable security dashboards covers building those layouts, while this piece covers the metrics that fill them.
