Every vulnerability program eventually faces the same meeting. A leadership team or a board asks a simple question. Are we getting safer or not. The honest answer is rarely a single number. It lives in how many critical findings are still open, how fast the team closes them, which assets carry the most concentrated risk, and whether the trend is moving in the right direction. The problem is that this information almost always sits trapped inside the scanner consoles and ticket queues where the work happens. Translating it into something a non-technical audience can act on is hard, and many teams do it the night before the meeting with a spreadsheet and a lot of copy-paste.
This guide is about closing that gap. It walks through how raw findings become risk analytics, and how those analytics become reports that an executive or an auditor can read without a security background. Every claim here is grounded in how PMAP actually computes its metrics and builds its documents, because an analytics story is only credible if the numbers behind it are reproducible. If you build the rest of your vulnerability program well but cannot communicate its state, the program still looks like a cost center. Good analytics and reporting are what turn the same body of work into a visible, defensible risk reduction story.
You can read this top to bottom as a reference for designing your own metric set, or jump to the section that matches the question you are being asked right now. Analytics here is the final motion of the vulnerability management lifecycle. Findings are ingested, correlated, triaged, and remediated, and then the same data set is read back as evidence that the work happened.
Why Counting Findings Is Not Measuring Risk
The most common vulnerability metric is also the least useful one. A raw count of open findings tells you almost nothing about exposure. A program with ten thousand low severity informational findings on isolated test hosts is in far better shape than a program with forty critical findings on internet-facing production systems, yet a naive count makes the first look ten times worse. Counting findings measures activity. Measuring risk requires weighting those findings by severity, by the value and exposure of the asset they sit on, and by whether they are being handled inside the deadlines the program committed to.
PMAP draws a deliberate line here. Its analytics layer is a read-only intelligence surface that sits downstream of everything else. It does not own findings, assets, projects, or SLA timers. It reads them. Every aggregate it produces is computed from the live records that triage and remediation already maintain, which means a metric can never drift away from the underlying data. There is no separate reporting database to reconcile and no nightly export that can fall out of sync. The dashboard a manager sees and the finding an analyst is editing are two views of the same source of truth.
That read-only design has a second consequence that matters for trust. Because analytics writes nothing back, it cannot accidentally change a finding while reporting on it. The aggregation queries pull from the finding table, the asset table, the project and company tables, and a materialized view for the heaviest rollups, and they apply the same tenant scope filter that protects every other read in the platform. An executive looking at a company-wide KPI snapshot is seeing exactly the slice of data their role is allowed to see, no more and no less.
The frameworks that govern security measurement make the same distinction between activity and outcome. NIST SP 800-55 frames security metrics as a way to support decisions and demonstrate the effectiveness of controls rather than to count events for their own sake, and ISO/IEC 27004 treats monitoring, measurement, analysis and evaluation as a continuous discipline tied to defined objectives. The rest of this article follows that spirit. Every metric described below answers a decision, not a curiosity.
The KPI Snapshot Executives Need
Most reporting conversations start with the same handful of numbers. How many assets do we cover. How many findings are open right now. How many of those are urgent or critical. How many active assessment projects are running. How many findings have already breached their SLA. PMAP packages exactly this set into a single dashboard call so that the headline view of a program loads in one request rather than a dozen.
The KPI snapshot returns total assets, total findings, open findings, urgent and critical finding counts, the active project count, the current SLA breach count, and the number of connected integrations. These are the tiles at the top of an executive dashboard, the row of numbers that answers the at-a-glance health question before anyone scrolls. Each one is a live aggregate, not a cached figure, so the snapshot reflects the program as it stands the moment the page loads.
Alongside the headline tiles, the same layer produces two distribution views that give the headline numbers shape. The severity distribution breaks open findings across all six severity levels, from urgent and critical down through high, medium, low, and informational. The status distribution breaks findings across all nine workflow states, from open and assigned through in progress, retest, closed, reopened, false positive, accepted risk, and not accessible. A severity donut and a status bar chart together tell a richer story than any single count. They show not just how much work exists but how dangerous it is and where it sits in the pipeline.
This consistency of vocabulary is what makes the snapshot trustworthy across audiences. The six severity levels and nine status values are the same ones the triage team works with every day. An executive looking at a severity donut and an analyst working a queue are reading the same scale. Nothing is summarized into a softer, board-friendly version that quietly loses fidelity, because the reporting layer and the operational layer share one taxonomy.
SLA Analytics and Breach Rates
If KPIs answer how much risk exists, SLA analytics answer how well the program is keeping its promises. A service level agreement in vulnerability management is a commitment to remediate a finding of a given severity within a set window. SLA analytics measure whether the team is honoring those commitments, and they are often the single most scrutinized metric in a leadership review because they map cleanly to accountability.
PMAP’s SLA analytics always compute three core figures. The first is the count of findings closed within their SLA window. The second is the count closed after breaching it. The third is the average days to close, broken out per severity, so a slow tail on critical findings does not hide behind a fast average on low ones. Together these produce a breach rate, the proportion of findings that missed their deadline, which is the number most leadership teams anchor on.
The same panel can optionally expand into deeper cuts without forcing every query to pay for the heavier work. A breach trend can be added to show whether the breach rate is climbing or falling over time, at either daily or weekly granularity. A per-company health breakdown can be added to show which subsidiaries or clients are carrying the most breached load. A per-project health breakdown can do the same at the engagement level. These sections are activated only when requested, so a quick health check stays fast and a deep quarterly review can pull everything it needs.
What makes this credible as a compliance signal is that the SLA windows are not invented by the analytics layer. They come from the program’s own SLA configuration, where each severity maps to a remediation deadline, and they can be tightened per company or per project for stricter clients. The analytics layer simply measures performance against those committed windows. If you need to look at SLA primarily as audit evidence rather than as a performance metric, that lens is covered in the companion guide on compliance, SLA and audit evidence in vulnerability programs. Here the focus stays on SLA as a management number.
Risk-Based Prioritization Across Assets, Companies and Projects
A breach rate tells you whether the program is fast. It does not tell you where to point the team next. That is what risk ranking is for. PMAP computes a risk score at three levels of aggregation so that prioritization works whether you are an analyst deciding which host to fix first or an executive deciding which business unit needs attention.
At the asset level, the platform produces a ranked list of every asset with its computed risk score and a full severity breakdown, plus a top-20 shortlist for the cases where you only want the worst offenders. This is the heatmap an operations lead works from. It surfaces the small number of assets that carry a disproportionate share of the program’s risk, which is almost always where the highest-leverage remediation lives.
At the company level, the ranking aggregates open findings, the severity split, the average asset risk score, and the name of the single highest-risk asset for each company. In a multi-tenant or holding structure this is the view that answers which subsidiary or which client is the current exposure leader. At the project level, the ranking aggregates open findings and a severity breakdown into a weighted overall risk score, so an assessment program with a few critical findings ranks above one with many low ones. The three rankings share a vocabulary but answer three different questions, which is why the platform keeps them distinct rather than collapsing them into one number.
This program-level and board-level framing of asset risk is the counterpart to the asset-level setup described in the guide on attack surface and asset inventory. There the focus is on building trustworthy assets with criticality and exposure attributes. Here those same attributes feed a score that rolls up into management reporting.
How the Asset Risk Score Is Computed
The asset risk score is not a black box, and being able to explain it is part of why it earns trust in a review. The formula starts from a weighted base built from the asset’s open finding counts. Urgent findings carry the heaviest weight, critical findings slightly less, then high, then medium, then low, so the base already reflects severity rather than raw count. A single critical finding moves the base far more than a handful of low ones.
That base is then multiplied by factors that capture context the raw counts cannot. A criticality factor scales the score up for business-critical assets and down for low-importance ones, so the same vulnerability on a payment system outweighs it on a sandbox. An additional multiplier applies when the asset has any SLA breaches, because a breached deadline is itself a risk signal. A further multiplier applies when the asset is externally facing rather than internal, because exposure increases real-world likelihood. The final score is the weighted base times those factors.
The project risk score deliberately uses a simpler version of the same idea. It applies the same severity weights to a project’s open findings but omits the criticality, SLA, and exposure multipliers, because a project is not an asset and does not carry those physical attributes. This is a small example of a larger principle in how PMAP designs metrics. A score is only meaningful when its inputs actually exist on the thing being scored, so the platform does not borrow attributes a project never had. When a leadership team asks why one asset ranks above another, the answer is a short, defensible sentence rather than an appeal to a proprietary algorithm.
Trends, Age Buckets and Chronic Findings
A snapshot tells you where you are. Trends tell you where you are heading, and direction is usually what a board actually wants to know. PMAP produces a daily time series of findings created, closed, and still open over a configurable window of up to a year, defaulting to the most recent month. Plotted as three lines, this chart answers the core question of a program review at a glance. If the open line is falling while the closed line keeps pace with the created line, the program is winning. If the created line outruns the closed line, intake is outpacing remediation and the backlog is growing.
Trends alone can still flatter a program that closes easy findings fast and lets hard ones rot. The finding age histogram guards against that. It distributes open findings across age bands, from the freshest zero-to-seven-day bucket up through older bands and a final ninety-day-plus bucket for the long tail. A healthy program keeps most of its open findings in the younger bands. A growing population in the oldest bucket is an early warning that the team is deferring the difficult work, and it surfaces long before any single finding becomes a crisis.
The platform also isolates the findings that quietly drain a program over time. A recurring and chronic summary rolls up findings that keep coming back. Recurring findings are those that have been reopened at least once. Chronic findings are those that have appeared in two or more scans, meaning a fix never fully held or the same weakness keeps reappearing on the asset. The same rollup surfaces SLA-breached totals, a severity breakdown, and the top companies by recurring load. Because this view is read from a precomputed materialized view rather than aggregated on the fly, it returns near-instantly even at enterprise scale, and it reports its own freshness so a reader knows how recent the underlying refresh is. Chronic and recurring findings are the ones that make a program look busy without making it safer, and putting a number on them is often the most actionable insight in a quarterly review.
Taxonomy Analytics and MTTR
The metrics above answer how much and how fast. Taxonomy analytics answer why, and that is the layer that turns reporting into improvement rather than just scorekeeping. PMAP classifies findings along a canonical taxonomy with three dimensions. One dimension captures the effect of a vulnerability, one captures its root cause, and one captures the remediation technique that resolves it. Analytics can slice findings by any of these three dimensions, which lets a program move from listing symptoms to understanding patterns.
The taxonomy distribution shows finding counts and a severity breakdown for each canonical code within a chosen dimension. Grouped by root cause, it answers a question that a simple finding list never can. Are most of our problems coming from missing patches, from misconfiguration, from weak authentication, or from insecure code. That single insight redirects a program more effectively than any individual finding, because it points at the systemic cause rather than the symptom.
Sitting alongside distribution is taxonomy MTTR, the mean time to remediate per taxonomy code, computed only on findings that actually closed so the number reflects real remediation speed rather than open-ended guesses. MTTR by root cause reveals which classes of problem the team resolves quickly and which ones consistently drag. A high MTTR on a particular root cause is often a process signal rather than a technical one, pointing at a handoff or an ownership gap rather than a hard vulnerability. A taxonomy trend rounds out the set with weekly new-finding counts per code over a rolling window, so a class of problem that is suddenly accelerating shows up as a rising sparkline before it becomes a backlog.
The same MTTR thinking extends to people through team performance analytics. For each team the platform reports open load, findings closed in the current month, average MTTR in days, and the team’s most common root cause. This is not about ranking individuals. It is about spotting where capacity is overloaded and where a particular team keeps hitting the same class of problem, which is exactly the kind of operational insight a security manager needs and a board rarely sees.
Side-by-Side and Year-Over-Year Comparison
Absolute numbers are easy to argue with. Comparisons are harder to dismiss, which is why leadership reviews so often turn on whether things improved relative to something. PMAP supports two kinds of comparison that cover the two questions most often asked.
The first is side-by-side comparison. Two companies or two projects are placed against each other on a standardized metric shape that includes total, open, and closed findings, the severity split, the SLA breach rate, the closure rate, average remediation days, and the retest success rate. The platform computes the delta between them field by field, so the answer to which client improved more, or which business unit is the laggard, is a calculated difference rather than an eyeballed guess. The same standardized shape powers multi-project comparison, where several projects are lined up at once on identical metrics, which is how a portfolio of assessments gets reviewed in one table.
The second is the year-over-year view, which is the comparison a board is most likely to ask for directly. It produces a monthly or quarterly time series of findings created, closed, open, critical, and high spanning multiple calendar years. Laid out as a multi-year chart, it answers the are-we-getting-better-over-time question with actual history rather than a feeling. A program that can show a falling critical line across three years has the single most persuasive slide in any security budget conversation, because it demonstrates outcome over time rather than effort in a moment.
There is also a vendor performance scorecard for organizations that work with external consulting or pentest firms. It rates each firm on projects completed, total and closed findings, average closure time, average critical count, retest pass rate, and SLA breach rate. This turns the question of which testing partner actually delivers from an opinion into a record, which matters when contracts come up for renewal.
Configurable Dashboards for Every Role
A single fixed analytics page never satisfies everyone, because a CISO, a team lead, and an operations analyst are each asking different questions of the same data. PMAP solves this with configurable dashboards. Every user can build, save, and manage their own widget-based layouts rather than living inside one shared screen.
A dashboard is a named, ordered arrangement of widgets, where each widget maps to a single analytics data type and carries its own placement on the grid, chart type, date range, and scope. A user can keep as many dashboards as they want, flag one as the default landing view, and rearrange or reconfigure widgets without affecting anyone else, because dashboard records are owned per user and never shared by accident. The supported widget types cover the core analytics surfaces, including KPI cards, severity distribution, status distribution, the findings trend, top risk assets, company risk distribution, the SLA overview, and the project risk summary. Each widget can render as a bar, line, pie, or table where that makes sense, so the same severity data can be a donut on one dashboard and a bar on another.
When a user creates a dashboard without specifying a layout, the platform seeds a sensible six-widget default covering KPI cards, severity and status distributions, a thirty-day findings trend, top risk assets, and an SLA overview. That default is a working executive view out of the box, and it can be reshaped from there. The composition layer stays deliberately thin. It owns only the saved layout and delegates every metric to the analytics layer, which means a widget can never show a number that disagrees with the main analytics page. To keep the heaviest widgets responsive at scale, the platform refreshes its wave-visibility materialized views on a short cycle in the background, so dashboard reads stay fast without each request paying the full aggregation cost. If you want a deeper look at saved layouts and reusable views, the configurable dashboards and saved views datasheet covers the surface in detail.
Async Report Generation in PDF, DOCX and HTML
Dashboards answer the live, exploratory question. Reports answer the need for a fixed artifact that can be attached to an email, filed as evidence, or handed to someone who will never log in. PMAP’s report engine produces multi-format security documents from the same live data, covering six first-class report types. There is a project technical pentest report, an executive summary, a company risk posture report, a selected-findings report, an asset exposure sheet, and a selected-assets report. Each one has its own structure and layout, drawn from a shared data model so the numbers stay consistent across formats.
Every report type can render as a PDF, a DOCX, or HTML from a single shared pipeline. The PDF path renders through headless Chromium for a polished, print-ready document. The DOCX path renders natively so a client can open and edit a Word file without a conversion step. The HTML path supports inline viewing and embedding. Choosing the format is a per-report setting, not a separate tool, so an executive summary and a technical report draw from the same underlying view model regardless of how they are exported.
Generation runs asynchronously, which matters more than it sounds. When a user triggers generation, the request returns immediately with a queued status, and a background worker moves the report through generating to completed or failed. A large company risk posture report does not freeze a browser tab while it builds. The status machine is visible throughout, so the UI can show exactly where a report sits. Every successful generation is also versioned. A new timestamped file is written rather than overwriting the previous one, so the full history of a recurring report remains downloadable and an old version can always be retrieved for comparison or audit. The report engine reads its content selection and per-section filters from the same finding and asset data the rest of the platform uses, and a reporting templates and delivery datasheet documents how templates shape that output.
Executive Narrative and Report Signing
The hardest part of any board report is the prose at the front, the paragraphs that explain what the numbers mean to someone who will not read the tables. PMAP includes a rule-based executive narrative generator that produces a multi-section written summary in English or Turkish from the live report data. It is a local, deterministic text generator rather than an external service, which means the narrative is reproducible and contains no data leaving the platform. The narrative can be previewed live before a report is regenerated, so an author can read the summary the numbers will produce before committing to a build.
For documents that need to stand as evidence, the engine can sign a report. Signing computes a cryptographic integrity hash of the generated file and stores it, returning a QR code that points at a public verification endpoint. A recipient who later wants to confirm that the PDF they hold is the exact file that was generated, and has not been altered, can verify the hash without logging in. For a regulated industry or an audit handoff, that single feature turns a report from a document that could have been edited into an artifact whose integrity can be proven. Both the narrative and the signature are configured per report rather than bolted on afterward, so a board-ready document carries its own provenance.
Sharing Reports Securely
A finished report usually has to reach someone outside the platform, and that is exactly where uncontrolled sharing creates risk. Emailing a sensitive PDF to a personal inbox or dropping it in a shared drive is how confidential findings leak. PMAP keeps distribution inside controlled channels so a report can travel without losing its protections.
The first channel is share tokens. An authenticated user can create a time-limited, optionally password-protected public link for a specific report. A recipient downloads through that link with no login, and the link can carry an expiry so access does not outlive its purpose and a password so it cannot be forwarded freely. Tokens can be listed and revoked at any time, so access granted today can be withdrawn tomorrow without re-issuing the report.
The second channel is encrypted email delivery. A report can be sent as an email attachment to multiple recipients, in more than one format at once, with the delivery outcome logged per recipient so there is a record of who received what. When a delivery password is set, the PDF attachment is encrypted before it leaves the platform, so even the file in transit is protected. Together these give a clear answer to the question every compliance reviewer eventually asks. Who received this report, when, and could anyone else have opened it. The answer is a logged, revocable, optionally encrypted trail rather than a guess.
How PMAP Connects Findings to the Boardroom
Step back from the individual features and a single arc emerges. A scanner reports a finding. Triage governs its severity and assigns an owner and a deadline. Remediation closes it and proves the fix. Then the analytics layer reads that same record back as a weighted risk score, a trend point, an SLA data point, and a taxonomy bucket. The report engine assembles those reads into a document, writes an executive narrative over them, signs it, and delivers it through a controlled channel. Nothing in that chain is a separate copy of the truth. Every number in the boardroom traces back to a finding an analyst can open.
That continuity is the real product claim. Many tools can draw a chart. The harder thing is to guarantee that the chart, the SLA report, the risk ranking, and the signed PDF all describe the same underlying state, computed with formulas you can explain and scoped to exactly the data a viewer is allowed to see. Because PMAP’s analytics layer writes nothing and reads everything through one tenant scope filter, and because the report engine builds from that same data, the journey from raw finding to board-ready report is a single source of truth viewed at different altitudes. For the broader argument about which metrics matter and how to design a program around them, the ebook on measuring what matters in vulnerability analytics and the risk analytics, SLA and KPIs datasheet go deeper than any single article can.
The payoff is a vulnerability program that can answer the board’s question with evidence instead of anecdote. Are we getting safer becomes a falling critical-findings line, a shrinking breach rate, a dropping count in the oldest age bucket, and a signed report that proves the work behind those numbers actually happened.
Frequently Asked Questions
What is vulnerability risk analytics?
Vulnerability risk analytics is the practice of turning raw findings into weighted measures of exposure and program performance rather than simple counts. In PMAP it covers KPI snapshots, severity and status distributions, SLA breach rates, asset, company, and project risk rankings, finding trends and age buckets, taxonomy and MTTR analysis, and side-by-side and year-over-year comparisons. The point is to answer decisions such as where to focus remediation and whether the program is improving, not just to report how many findings exist.
How does PMAP calculate an asset risk score?
The asset risk score starts from a weighted base built from the asset’s open finding counts, where urgent and critical findings carry the most weight and low findings the least. That base is then multiplied by a criticality factor for how important the asset is, an additional factor when the asset has SLA breaches, and a further factor when the asset is externally facing rather than internal. The final score reflects severity, business importance, deadline performance, and exposure together, so it can be explained in a sentence rather than treated as a black box. Project scores use the same severity weighting but omit the asset-specific multipliers.
What report formats and types does PMAP support?
PMAP generates reports in PDF, DOCX, and HTML from a single shared pipeline, covering six report types. These are project technical pentest reports, executive summaries, company risk posture reports, selected-findings reports, asset exposure sheets, and selected-assets reports. Choosing a format is a per-report setting, and every successful generation is versioned with a timestamped file so previous versions stay downloadable.
Can reports be generated automatically on a schedule?
Yes. A report can be scheduled to generate once at a set time or to recur on a cron schedule, and a background runner fires due reports automatically. Combined with email delivery, a recurring executive summary can be produced and distributed without anyone triggering it by hand, which is how many teams keep a monthly board pack current.
How does PMAP keep shared reports secure?
Reports can be shared through time-limited, optionally password-protected share tokens that recipients open with no login and that can be revoked at any time. They can also be delivered by email to multiple recipients with per-recipient delivery logging, and when a delivery password is set the PDF attachment is encrypted before it leaves the platform. A report can additionally be signed with an integrity hash and a verification QR code, so a recipient can confirm the file has not been altered.
What is the difference between dashboards and reports in PMAP?
Dashboards are live, interactive, per-user widget layouts for exploring analytics on screen, where each user can build and save their own arrangement of KPI, distribution, trend, and risk widgets. Reports are fixed, generated documents in PDF, DOCX, or HTML, built for sharing, filing, and evidence. Both read from the same analytics layer, so the numbers stay consistent, but dashboards answer the exploratory question while reports produce the durable artifact.
Are analytics scoped correctly in a multi-tenant environment?
Yes. The analytics layer applies the same tenant scope filter that protects every other read in the platform, so each aggregate reflects only the data the viewer’s role is permitted to see. Company and project filters are additive on top of that scope, which means a manager can narrow a view to one subsidiary or one engagement but can never widen it beyond their granted access.
