CySA+ Vulnerability Management Reporting: Scan Reports, Scorecards, Action Plans and KPIs

Vulnerability management reporting is the stage that connects detection to remediation. Scanning finds weaknesses, but nothing is fixed until the people who own and run the systems understand the finding, accept responsibility for it and schedule the work. Reporting does that, and it also gives leaders the evidence they need to fund, prioritize and hold teams to account.

Objective 4.1 covers the outputs of the vulnerability program after findings have been prioritized:

• Vulnerability scan reports: the detailed findings, written for the people who fix them.
• Compliance findings: failures against a standard, regulation or internal baseline.
• Risk scorecards: summary ratings per business unit or asset group, for leaders.
• Action plans: who does what, by when, what each task waits for, and what happens when a deadline is missed.
• Inhibitors to remediation: the reasons a fix cannot simply be applied, and how the plan works around them.
• Stakeholder communication: who needs to know, who decides and what each needs to hear.
• Metrics and KPIs: trends, top risks and SLA compliance.

Two neighbouring objectives set the boundaries. Deciding which finding matters most (CVSS, exploitation, asset value) and choosing mitigations such as compensating controls belong to objective 2.3; risk concepts belong to 2.4. Incident reports, executive summaries for incidents and SOC metrics such as mean time to detect and respond belong to objective 4.2. Here those ideas appear only as inputs to reporting and planning.

A vulnerability scan report should contain what its audience needs to act, plus a clear statement of what the scan did and did not cover. The same scan feeds several reports: a technical view for the people doing the work, an owner view for the people accountable for the systems, and a summary for leadership.

Scope, exclusions and coverage

Every report must state its scope (target ranges and asset groups), its exclusions, and how hosts were assessed (authenticated or unauthenticated, which credentials). A report lists what the scanner found, so anything outside the targets simply does not appear, and an absent section reads exactly like a clean one. Only an explicit scope statement lets a reader tell "scanned, nothing found" from "never scanned". Month-on-month comparisons cannot catch the difference on their own, because fewer findings look like progress.

Coverage can also be partial. An authenticated scan inspects installed packages, registry keys and file versions; when the login fails, the scanner falls back to what it can see over the network and reports far less. A host assessed that way looks healthier than it is. Label such hosts as partially assessed, say why, and send that caveat with the report that goes out now; schedule the rescan separately rather than holding or patching up the report.

Detection evidence

Each technical finding should include the evidence behind it: the service banner, file version, package version or registry value the scanner actually observed on that host. Evidence is what makes a finding checkable. When an owner disputes a finding, the evidence shows exactly what the scanner saw, so both sides can confirm or correct it quickly. Severity explains how serious a flaw is in general; evidence explains why this particular host was flagged.

Recording disposition accurately

• False positive: the scanner was wrong; the condition it reported is not present.
• Not affected / not exploitable: the component is present but the vulnerable code is not reachable. Vendors publish these statements in a structured form called VEX (Vulnerability Exploitability eXchange), with a status such as not affected and a justification such as vulnerable code not present. When you cannot inspect a closed product yourself, the vendor's documented statement is the evidence: reference it on the finding so the decision stays traceable, and revisit it if the vendor's position changes.
• Open, pending fix: a true finding still waiting for remediation, whatever the reason.

Each status feeds the metrics differently, so the label must match the facts. A wrong label quietly changes every count and SLA figure built on the report.

Handling and sharing the report

Detailed scan reports must be handled as sensitive information and shared on a need-to-know basis, because a list of unpatched hosts, open services and exploitable CVEs is effectively an attack map of the network. Access follows the role someone plays in remediation, not seniority or interest.

• Match the detail to the purpose. A wide audience following progress needs aggregate metrics (percentage remediated, trend, SLA compliance). An auditor checking patch cadence needs SLA figures. Only the owners and teams fixing particular systems need the per-host detail for those systems.
• Minimise first, then protect. Controls such as encryption, access-controlled storage and confidentiality agreements protect what you send, but they do not change how much the recipient learns. Decide what the recipient needs first; protection comes second.
• Share by scope with third parties. An outside firm working on part of the estate, such as a contractor rebuilding the mail servers, receives the findings for its in-scope systems over a protected channel, not the whole report.
• Detail ages quickly. A report is useful to the people fixing things when it is current, and dangerous to everyone else for as long as the weaknesses remain, so time does not make broad publication safe.

A compliance finding records a failure to meet a defined requirement (a regulation, an industry standard such as PCI DSS, a configuration benchmark such as a CIS Benchmark, or the organization's own security standard). A vulnerability finding records a weakness that could be exploited, usually a software flaw identified by a CVE and rated with CVSS. The two overlap but are not the same, and reports keep them separate.

Compliant is not the same as secure

A baseline checks settings; a vulnerability scan checks for known flaws. A database can meet every setting in its hardening baseline and still run a version with a published remote-code-execution flaw. The two results are independent, so report each in its own category with its own owner and due date. A pass in one never closes, cancels or reclassifies a finding in the other.

The reverse also holds. A requirement can fail without any CVE involved, for example an internal standard that requires a year of audit-log retention on servers that keep thirty days. That gap is a compliance finding in its own right. It is tracked like any other finding, with an owner and a remediation date, and it is rated by the requirement it fails rather than by a CVSS score.

Making compliance findings actionable

A bare pass/fail per host gives an owner nothing to change. Each compliance finding should name the specific control or requirement that failed and show the value found versus the value required. With both, the owner knows exactly what to change and can confirm the fix by re-running the same check.

Reporting priority

Priority comes from context, not from the severity label alone. A finding that fails a mandatory control in a regulated environment, with a fixed external deadline such as an assessment, can outrank a higher-rated flaw on an isolated system that holds no sensitive data: the regulatory, contractual and business consequences are part of the risk. Under PCI DSS, a compensating control is accepted only when it is documented (on the Compensating Controls Worksheet) and validated by the assessor, so it is a planned alternative rather than a quick substitute for fixing the requirement.

A risk scorecard is a summary that gives each business unit, asset group or service a vulnerability exposure rating, often colour-coded, and compares it with earlier periods so leaders can see at a glance where exposure is concentrated and whether it is improving. It is built from scan data but written for decision-makers: a one-page executive view per unit is a scorecard, not a scan report, an action plan or a compliance log.

Weight findings by risk, not by count

Raw finding counts measure volume, not danger: a unit with many minor findings on low-value devices can look worse than a unit with a handful of critical findings on the systems that earn its revenue. A useful rating weights each finding by both its severity and the criticality of the asset it affects, then sums or averages those weighted values per unit. A simple version multiplies a severity weight by an asset-criticality weight. Either factor on its own misleads: severity alone ignores what the asset is worth, and criticality alone ignores how bad the flaw is.

Pair every rating with coverage

A rating describes only what was scanned, so any rating can be improved by scanning less. Report scan coverage as a share of the unit's asset inventory next to the rating. Then a unit that drops systems from its schedule shows a falling coverage figure, instead of an improving rating that nobody questions.

Design for the reader who must act

Business-unit heads usually control budgets and staff but have little technical background. Lead with what they control and can act on:

• their unit's overall rating and its change since the last period (where it stands and which way it is moving); and
• their unit's overdue critical findings measured against the SLA (a clear, owned problem that needs people or money).

Material about other units, scanner operations or unweighted volume belongs in other reports, because it does not show a leader their own exposure or what to do about it.

A remediation action plan turns findings into tracked work: each item has a task, an owner, a due date (set by the remediation SLA for its severity), any dependencies it waits for, any interim mitigation while it waits, a verification step (normally a rescan) and an escalation path for when it slips.

Escalation

Escalation moves an overdue or blocked item up to someone with the authority to make it happen. Without a defined path, an overdue item stays with the one person who has not acted, and nobody with more authority hears about it. A good escalation path names who is told, in what order, and what triggers each step (a missed due date, a number of days overdue, a severity). A path to the owner's manager, then a director, then the CISO is typical.

• Follow the defined order. When an item meets a trigger, it goes to the next named level, which gets its chance to act before the level above it is involved.
• Escalation reaches someone new. Its purpose is to put the item in front of a person with more authority than the one who has not acted.
• Only the accountable owner can accept risk. An unanswered finding stays open and keeps escalating; no one else can treat silence as a decision.
• Conflicts go to whoever sets both priorities. When remediation competes with other mandated work for the same people or change slots and the teams cannot settle it, the analyst raises the conflict with the leader who has authority over both, early enough for a decision before the due date. The analyst brings the facts and the options but does not resolve the conflict alone, for example by moving deadlines.

Exceptions

When a finding genuinely cannot be fixed within its SLA, the plan routes it to a formal exception decided by the accountable risk owner. The analyst prepares it: the reason, the compensating control (where policy requires one), the residual risk, an expiry date and a recommendation. The risk owner approves or rejects. An approved exception keeps the finding visible and owned until the fix lands, and it is reviewed when it expires. (Which compensating control to choose is covered under objective 2.3.)

Governance delays use governance routes

Change control exists so that production changes are approved and recorded. When a fix is too urgent for the normal approval cycle, for example because a flaw is being actively exploited, the organization's emergency change process is the route: approval within hours or days, with the same accountability as a normal change. It applies to every change to the organization's systems, including changes that a vendor or provider carries out.

A dependency is anything a remediation task must wait for before it can proceed: another team's upgrade, a vendor release, a vendor's certification of a patch, a partner's software update. The plan records each dependency with an owner and an expected date, adds an interim mitigation where exposure would otherwise sit unprotected, and sequences tasks so nothing runs before its prerequisite.

The test for a dependency is simple: could the task start or succeed without it? If not, it is a dependency. A network team opening the firewall rule a new patch server needs is one; so is a platform upgrade the patch requires, or a vendor's sign-off on a customized system. Deadlines, follow-up checks such as the verification scan, and unrelated scheduled work are not dependencies: they do not have to finish before the task can run.

When the fix waits on someone else, the plan does two things at once: it tracks the dependency to its date, and it reduces exposure in the meantime. A web application firewall rule, tighter access to the affected interface or extra monitoring all buy time without breaking the supported configuration. Change the bundled components of a vendor's product yourself only when the vendor supports it.

Sequencing under operational constraints

Real plans combine dependency order with operational limits: how many systems may be out of service at once, how often a system may be interrupted, and checkpoints that must pass before work continues. Build the order that satisfies every limit at once:

• Prerequisites first, per system. The dependent change can only succeed once its prerequisite is in place on that system.
• Verify as you go. Checking each step on each system before the next one catches a fault on the first system, not after it has been repeated everywhere.
• Batch the work for each interruption. If every interruption costs the business, do all the work a system needs during a single visit.

Partial readiness

When several consumers depend on what you are changing and they become ready at different times, move each one as soon as it is ready, then narrow the remaining exposure to only those that still need the old behaviour. Suppose an outdated SSH algorithm must be retired, and two backup appliances still use it, but only one has updated software available. Update that appliance now, then allow the old algorithm only from the remaining appliance's address until its update ships. Exposure shrinks immediately and no service breaks.

Inhibitors to remediation are the conditions that stop a known fix from being applied on time. CySA+ names seven. Identifying the right one matters because each has a different remedy.

The near-twins

• Contractual vs governance: who made the rule? An outside party's terms are contractual; the organization's own policy or approval process is governance.
• Business process interruption vs degrading functionality: is the problem the act of applying the fix (downtime while rebooting) or the effect of the fix once applied (a feature stops working or slows down)? A patch that installs without downtime but breaks a partner feed is degrading functionality.
• Legacy vs patch availability: no routine fixes because support has ended is legacy; no fix yet from a vendor that still supports the product is patch availability. (Some vendors sell paid extended support for a while after end of life; a product still on such a programme is receiving fixes.)
• Proprietary vs patch availability: if the fix exists (for example a public fixed version of an embedded open-source library) but you cannot put it into the vendor's closed product, the inhibitor is proprietary.
• Proprietary vs legacy: proprietary is about who can change the product; legacy is about whether the product is still supported. A product can be both.

The plan responds to an inhibitor by reducing risk now, documenting why the normal deadline cannot be met, and keeping the real fix tracked until it lands. It does not hide the finding by descoping it, closing it as accepted risk by default or calling it a false positive.

Choosing among workable options

Harder scenarios offer several defensible actions, and the stated constraints decide between them. Before weighing options, list what may not change, what must stay online and what the contracts promise; then discard any option that breaks one of them. A mitigation that switches off a convenience feature is acceptable when nothing commits the business to that feature. An option that takes a service offline is not, if the business has promised that service will stay available. The best answer is the one that reduces the exposure most while keeping every stated commitment.

When no patch exists, the plan's dates are review dates (recheck the vendor's advisories, reassess the interim control), not patch deadlines. The asset stays in scan scope, so the exposure stays visible and the scanner confirms the fix once it is applied.

Stakeholders in vulnerability management are everyone who owns, runs, uses, funds, changes or must be told about the affected systems. Identifying them early, and knowing which of them decides and which only needs to be informed, is what turns a finding into a scheduled fix.

The short rule is owners approve, custodians implement, others are informed. The business owner is accountable for what the system does for the business, usually the function that pays for it and decides how it is used, so the business owner decides when it may be taken offline. The team that runs the system day to day is a custodian: it carries out the change but does not decide whether the business can absorb the outage. When a third party performs changes under contract, timing is agreed with the business owner and through the provider's contracted change process. Teams that only need to expect the change, such as monitoring and support staff, are told the window and the expected effects.

Tailor the message

Match the content to the decision the audience must make. An executive deciding whether to fund unplanned work needs the business exposure in plain terms, the cost, the options and the date by which the decision is needed. Technical identifiers and estate-wide statistics belong in other reports. An administrator needs the opposite.

When a fix itself harms the business, for example by making a critical job run longer, the analyst's role is to measure the impact and present it, with the security risk, to the business owner, who decides the trade-off. Choosing between business impact and security risk is the owner's call, not the analyst's.

Vulnerability management KPIs show whether risk is going down and whether commitments are being kept. CySA+ names three families: trends, top risks and service-level agreement (SLA) performance. (Incident and SOC metrics such as mean time to detect and mean time to respond belong to objective 4.2.)

Trends

A trend compares the same measure over time: open findings by severity, average age, coverage, rating per unit. Read trends for causes, not just direction:

• Recurring findings point to a source. If the same findings keep reappearing on newly deployed systems, the thing they are built from (a golden image, a template, a container base image) is reintroducing them. A flat backlog can hide this, because fixes and new findings cancel out. Fixing the source stops the recurrence; fixing each new system does not.
• A change in scope or method breaks a trend. Authenticated scanning sees more than unauthenticated scanning, and newly added hosts bring their existing findings with them. Either change raises counts because visibility improved, not because posture got worse. Annotate the trend where the change happened and compare like with like (the same hosts, scanned the same way) on both sides of it.

Top risks

A top-risks report gives leaders a short list of the most significant risks to key services, in business terms, each with an owner and a status. It answers "what could hurt us most, and who is handling it?" Volume, spread and severity totals answer different questions.

SLA performance

Remediation SLAs set a deadline per severity, for example a set number of days for critical and for high findings, defined by the organization's policy. The core KPI is the percentage of findings remediated within their SLA: each finding's verified fix date compared with its due date, for the findings that fell due in the period.

Calculate it honestly. Suppose 50 high-severity findings fell due in a quarter: 41 were fixed by their due dates, 5 were fixed afterwards and 4 were covered by approved exceptions.

• The numerator is on-time fixes only: 41 of 50, or 82%.
• Exceptions are reported as their own line (4), because an exception is a decision to carry risk, not a fix.
• Late fixes are reported as missed (5), even though nothing from that group is still open.
• Count only verified closures. A finding counts as remediated only once a rescan confirms it is gone. Otherwise the metric rewards closing tickets, and a team whose closed findings keep reappearing can top the table.