• Export the scanner's complete machine-readable format (XML, JSON or full CSV), never its PDF.
• Check scope, scan date and credential status before you write a word.
• Group findings into remediation actions and rank them by known exploitation first.
• Lead the report with decisions; move the raw detail to an appendix.

Step 1: export the right file

Every scanner offers a polished PDF and a raw data export. The PDF is designed to be read, so it summarizes; fields such as CVE lists, plugin output or detection details are often trimmed. The raw export keeps everything, which is what you need to build a report you can defend.

The export to use per scanner

Microsoft Defender Vulnerability Management and ConnectSecure have no export file to upload. Connect them to Varaxon Scan Hub directly instead, which keeps the complete record including software inventory. Defender needs Microsoft Defender for Endpoint Plan 2, Defender Vulnerability Management or Defender for Servers.

Step 2: check what the scan could see

Before reading findings, confirm the scan's boundary. A report built on a partial scan should say so on the first page.

• Scope. Compare the hosts in the export with the client's asset list. A missing server is a gap, not a pass.
• Date and feed age. Record when the scan ran and how current the scanner's checks were.
• Credentials. Note which hosts were scanned with working credentials. A failed login quietly drops a host to a network-only view; see credentialed vs non-credentialed scans.
• Filters. Some exports apply filters at download time, such as Greenbone's Quality of Detection threshold. Make sure nothing was hidden by accident.

Step 3: group findings into actions

Clients do not fix findings; they perform actions. Forty Windows findings across twenty laptops usually collapse into one action: apply the current cumulative update. Group by the remediation, then list the affected hosts under it. This turns a 600-row export into a list of 15 or 20 things to do, which is a list a client can actually schedule.

Keep the evidence attached When you group, keep each action linked to the scanner evidence behind it: the detected version, the plugin or check output, the CVE list. That is what lets a technician verify the fix and lets you answer the client's "how do you know?"

Step 4: put the actions in order

Rank actions by the strongest evidence of real-world risk first. A defensible order:

1. Anything in the CISA Known Exploited Vulnerabilities (KEV) catalog, with known ransomware use at the very top.
2. Critical findings (CVSS 9.0 or above) without a KEV match, especially on internet-facing systems.
3. Other findings with a CVE and meaningful severity, ordered by severity and EPSS.
4. Findings without a CVE that still matter, such as end-of-life software or weak remote access configuration.
5. Low and informational items, as context.

The reasoning behind this order is in CVSS vs EPSS vs CISA KEV. Varaxon Scan Hub applies exactly these six bands with deterministic code, so two reports from the same export always agree.

Step 5: write for the person who decides

The first page is for the business owner or IT manager. Say what was scanned, the three to five actions that matter most, what they protect against and roughly what each involves. Leave raw counts of Highs and Mediums off this page: they alarm without informing.

After the summary come the scope and method, the full prioritized action list with owners and target dates, and a technical appendix with per-host detail. The report template guide lists every section and what goes in it.

Step 6: hand over the work, then track it

A report is only useful if the actions become tickets someone closes. Agree target dates with the client (the remediation SLA guide has a starting matrix), create the tickets, and compare the next scan against this one so the client sees what was fixed and what is still open.

Varaxon Scan Hub covers steps 2 to 6 from the uploaded export: it checks coverage, groups and ranks the actions, writes the report, creates reviewed HaloPSA or ConnectWise PSA tickets and tracks each client between scans. See the sample reports, or try it on your own export with the free pre-flight check.

Common questions

Should I send the scanner's own PDF report to a client?

It is better as an appendix than as the report. Scanner PDFs are organized by finding and host, not by the actions the client needs to take, and some omit fields the raw export contains.

How long should a vulnerability report for a small business be?

Keep the decision part to one or two pages: a summary and the prioritized action list. The technical appendix can be as long as the scan requires, because only technicians read it.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• The classic Greenbone PDF format summarizes results and can leave out CVE details that XML and CSV include.
• The report filter, especially Quality of Detection (QoD), decides which results appear at all.
• Export the XML report for anything you will hand to a client or process with a tool.
• Many Greenbone checks have no CVE at all; that is Unknown, not clean.

The symptom

You run a scan in Greenbone Community Edition or a Greenbone appliance, download the PDF, and the report shows hosts and result summaries but few or no CVE identifiers. Sometimes the totals at the top count critical results that never appear in the tables below. Both problems come up repeatedly on the Greenbone community forum, and both have ordinary causes.

Cause 1: the PDF format leaves details out

Greenbone generates reports through report formats. The long-standing PDF format is built for a human-readable summary and is not where Greenbone puts its maintenance effort; forum maintainers have confirmed that it can omit CVE details the other formats include. The XML, CSV and TXT formats carry the full reference list for each result.

Fix Download the report as XML. It is Greenbone's native format and holds every field: the NVT OID, severity, QoD, references (CVE, CERT-Bund, DFN-CERT), detection details and the solution. Use the PDF only as a quick visual check.

Cause 2: the report filter hides results

Every Greenbone report is generated through a results filter. The default filter typically includes min_qod=70, which hides results whose Quality of Detection is below 70 percent. QoD expresses how reliable the detection method is: a remote banner check scores lower than an authenticated package check. Filters can also apply severity thresholds, a row limit (rows=) or hide overridden results.

• Open the report in the web interface and look at the filter string before downloading.
• Lower or remove min_qod if you need the complete picture, then label low-QoD results as lower-confidence in your report.
• Remove the row limit so large reports are not truncated.
• Check whether overrides or false-positive markings changed severities.

Cause 3: the check has no CVE

Many Greenbone NVTs test for things that never received a CVE: deprecated TLS versions, weak SSH algorithms, default credentials, end-of-life operating systems, exposed services. Those results are real findings with an OID and a severity but an empty CVE list. A report that counts only CVE-backed findings will under-report them.

Varaxon Scan Hub reports CVE-based assessment for those findings as Unknown rather than zero, and can optionally map Greenbone OIDs to CVEs on the server where a reliable mapping exists. Either way the gap stays visible.

A checklist before you send a Greenbone report

1. Confirm the scan used credentials for the hosts where you expect local checks.
2. Check the filter: QoD threshold, severity threshold, row limit, overrides.
3. Download the XML report.
4. Compare the result count in the XML with the count shown in the web interface.
5. State in the report which results have no CVE and how they were prioritized.

Upload the XML to Varaxon Scan Hub to get a prioritized, client-ready report from it. The Greenbone / OpenVAS page and its sample report show the result.

Common questions

What does QoD mean in OpenVAS?

QoD, Quality of Detection, is a percentage expressing how reliable a detection method is. Authenticated package checks score high; remote banner checks score lower. Report filters often hide results below a QoD of 70.

Which OpenVAS report format includes CVEs?

The XML report format includes every result with its full reference list, including CVEs. CSV and TXT also include CVE references. The classic PDF format can omit them.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• There is no universal deadline; the client's policy, contract or framework sets it.
• Base SLAs on exploitation and exposure, not severity alone.
• A common starting point: known exploited and internet-facing within days, Critical 14 days, High 30, Medium 90.
• Track the age of open findings so missed SLAs are visible before the next review.

Why remediation SLAs matter

A scan without a deadline produces a report that ages on a shelf. Remediation service level agreements turn findings into commitments: who fixes what, by when. For an MSP they also define the scope of the service and protect both sides when something is exploited later.

Common timelines

Organizations set their own numbers, but published policies cluster around similar values. US federal agencies must fix vulnerabilities in the CISA KEV catalog by the due date CISA sets (Binding Operational Directive 22-01), commonly two to three weeks for newly added entries. Many security teams aim for 7 to 14 days on Critical, about 30 days on High, 60 to 90 days on Medium and the next maintenance cycle for Low.

A starting SLA matrix to adapt per client

These are a starting point for a conversation, not a standard. Agree them with each client in writing, and check any contractual or regulatory requirement first.

What frameworks say

• PCI DSS v4: critical security patches must be installed within one month of release (requirement 6.3.3), and internal scans must show high-risk and critical vulnerabilities resolved.
• CISA BOD 22-01: mandatory for US federal civilian agencies; widely used by everyone else as a benchmark for known exploited vulnerabilities.
• CIS Controls v8: Control 7 calls for a documented remediation process and risk-based remediation on a monthly or more frequent basis.
• HIPAA, SOC 2, ISO 27001: require a risk-based process and evidence that it is followed, rather than fixed day counts.

Handling exceptions

Some findings cannot be fixed in time: a legacy system the vendor no longer supports, a line-of-business application that breaks on the new version. Treat these as risk acceptances, not silent misses. Record the finding, the reason, any compensating control (isolation, restricted access, monitoring), who accepted the risk and a review date.

Tracking SLAs between scans

An SLA is only real if someone can see it being missed. Compare each scan with the previous one per client: what is new, what was fixed and how long each open finding has been open. Bring overdue items to the next client review with a reason.

Varaxon Scan Hub keeps reports per client and tracks the age of open findings between scans, so overdue known exploited vulnerabilities stand out. Remediation actions become HaloPSA or ConnectWise PSA tickets once you review and approve them. The priority bands map directly onto the matrix above.

Common questions

What is a reasonable SLA for critical vulnerabilities?

Between 7 and 30 days is common, shortened to days when the vulnerability is in the CISA KEV catalog or the system is reachable from the internet.

Who should own remediation, the MSP or the client?

Whoever controls the system. MSPs usually own patching on managed endpoints and servers, while line-of-business applications and vendor-managed systems need a named client or vendor owner in the report.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• A scan is automated, broad and frequent; a penetration test is manual, deep and periodic.
• Scans answer "what known weaknesses exist?"; tests answer "what could an attacker actually achieve?"
• Most clients need regular scanning all year and a penetration test annually or after major change.

Two different questions

A vulnerability scan uses an automated tool such as Nessus, Greenbone / OpenVAS, Qualys or Rapid7 to check systems against a database of known vulnerabilities and misconfigurations. It is broad, repeatable and cheap enough to run every month.

A penetration test is a time-boxed engagement in which a skilled tester tries to break in, chaining weaknesses together the way a real attacker would, and documents what they reached. It is deep, creative and expensive enough that most organizations do it once a year or after a major change.

Side by side

Vulnerability scan compared with a penetration test

Which does a client need?

• Ongoing hygiene: regular vulnerability scanning with remediation tracking. This is the core of a managed security service.
• Compliance: PCI DSS requires both quarterly scans and an annual penetration test; many other frameworks and customers ask for a penetration test periodically.
• Before a big change or after an incident: a penetration test of the affected environment.
• Cyber insurance: applications commonly ask about scanning and patching; some ask about penetration testing for larger policies.

A penetration test on an environment that is not scanned and patched regularly mostly finds the missing patches a scan would have found. Do the scanning first; the test is then worth more.

Explaining it to a client

An analogy that works: a vulnerability scan is checking every door and window in the building to see which are unlocked. A penetration test is hiring someone to try to get to the safe. You want the first done every month and the second once a year.

Varaxon Scan Hub is a reporting tool for the first: it turns the scanner's export into a prioritized, plain-language remediation report. It does not perform penetration tests or claim an environment is secure. See what a vulnerability assessment report should include.

Common questions

Can a vulnerability scan replace a penetration test for PCI DSS?

No. PCI DSS v4 requires both: vulnerability scans at least every three months (requirement 11.3) and penetration testing at least once every twelve months and after significant changes (requirement 11.4).

Is a vulnerability assessment the same as a vulnerability scan?

The terms are often used interchangeably. Strictly, the scan is the automated check, and the assessment includes reviewing the results, prioritizing them and recommending fixes, which is what the report delivers.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• PCI DSS requires internal and external scans at least every three months and after significant changes.
• HIPAA does not set a frequency today, but regular scanning supports the required risk analysis.
• Monthly authenticated scanning is a sensible baseline for most small and mid-sized clients.
• Scan internet-facing systems more often than internal ones.

The short answer

At least quarterly to meet most compliance requirements, monthly as a practical baseline, and continuously or weekly for internet-facing systems where you can. Then scan again after any significant change, such as a new firewall, a new server or a major upgrade.

PCI DSS

• Internal scans at least once every three months and after significant change (requirement 11.3.1), performed with authentication (11.3.1.2), with high-risk and critical vulnerabilities resolved and rescanned.
• External scans at least once every three months by a PCI SSC Approved Scanning Vendor (ASV), with a passing result (11.3.2), plus scans after significant change.

ASV scans are a specific service with their own attestation; a general vulnerability report is not a substitute for one.

HIPAA

The HIPAA Security Rule requires covered entities and business associates to perform an accurate and thorough risk analysis and to implement reasonable safeguards, but it does not name a scan frequency. Regular vulnerability scanning is the standard way to support that risk analysis with evidence. Proposed updates to the Security Rule published in early 2025 would add explicit vulnerability scanning and penetration testing requirements; check the status of that rulemaking for your clients.

CIS Controls and other frameworks

• CIS Controls v8, Control 7: automated authenticated and unauthenticated scans of internal assets at least quarterly (7.5), externally exposed assets at least monthly (7.6), and risk-based remediation at least monthly (7.7).
• SOC 2 and ISO 27001: no fixed interval, but auditors expect a defined cadence that you can show was followed.
• Cyber Essentials (UK): focuses on patching within 14 days for high and critical updates rather than a scan schedule.

Cyber insurance

Underwriting questionnaires increasingly ask whether you scan regularly, whether internet-facing systems are covered and how quickly critical vulnerabilities are patched. Requirements vary by insurer and policy, so read the client's application. The most useful evidence is a dated history of reports showing findings being fixed.

Setting a cadence per client

A practical starting cadence

A higher cadence is only useful if the reports get read. Match scan frequency to how often the client can act, and use remediation SLAs to keep the two in step. Varaxon Scan Hub keeps every report per client, so a monthly cadence builds the dated evidence trail auditors and insurers ask for.

Common questions

Is an annual vulnerability scan enough?

Rarely. New vulnerabilities are published every day and many are exploited within weeks. Annual scanning leaves most of the year unmeasured and does not meet PCI DSS or CIS Controls expectations.

Should I rescan after patching?

Yes. A rescan confirms the fix worked and gives you evidence that the finding was resolved, which PCI DSS explicitly requires for high-risk and critical internal findings.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• CVSS answers "how bad could this be?", EPSS answers "how likely is exploitation soon?", KEV answers "is it being exploited now?"
• Fix KEV-listed vulnerabilities first, use EPSS to order the rest, use CVSS for impact.
• Absence from KEV is not evidence of safety; it means no confirmed exploitation yet.

Why severity alone is not enough

A typical scan of a small business returns dozens of Critical and High findings. Sorting by CVSS puts them all near the top, and the team ends up working through a list where most items will never be exploited while a few medium-scored flaws that attackers actively use wait their turn. Three public signals, used together, fix that.

CVSS: how severe a vulnerability could be

The Common Vulnerability Scoring System, maintained by FIRST, rates a vulnerability from 0 to 10 based on how it can be attacked and what an attacker gains. Most scanners and the US National Vulnerability Database publish the base score. Version 3.1 is still the most common; version 4.0, released in 2023, is appearing in more records.

CVSS qualitative severity ratings

Strength: a consistent, widely available measure of impact. Limit: the base score ignores whether anyone is exploiting the flaw and how exposed the affected system is.

EPSS: how likely exploitation is in the next 30 days

The Exploit Prediction Scoring System, also from FIRST, estimates the probability that a CVE will see exploitation activity in the next 30 days. It is published daily for every CVE as a probability between 0 and 1, plus a percentile showing how the CVE ranks against all others.

• An EPSS of 0.02 means about a 2 percent chance of observed exploitation activity in 30 days.
• A percentile of 0.95 means the CVE scores higher than 95 percent of all scored CVEs.
• Most CVEs have very low EPSS scores, which is exactly why it is useful for thinning a long list.

Strength: a data-driven likelihood signal that changes as threat activity changes. Limit: it is a forecast that moves daily, it only covers vulnerabilities with a CVE, and a low score is not a guarantee.

CISA KEV: confirmed exploitation in the wild

The Known Exploited Vulnerabilities catalog is maintained by the US Cybersecurity and Infrastructure Security Agency. A CVE is added only when there is reliable evidence of active exploitation and a clear remediation is available. Each entry includes a due date, which is mandatory for US federal civilian agencies under Binding Operational Directive 22-01, and a field showing whether the vulnerability is known to be used in ransomware campaigns.

Strength: the strongest public evidence that a vulnerability matters right now. Limit: it lists only confirmed cases, so it is deliberately incomplete. A vulnerability can be exploited for weeks before it is added.

Never report a KEV miss as "not exploited" If a CVE is not in KEV, the accurate statement is "no confirmed exploitation recorded by CISA". Clients read "not exploited" as a guarantee.

Putting them together

What each signal tells you

A practical order: KEV entries with ransomware use, then other KEV entries, then CVSS 9.0 or above, then the remaining findings with a CVE ordered by severity and EPSS, then findings without a CVE that still matter, then low and informational items. Adjust within each group for exposure: an internet-facing system goes ahead of an isolated one.

Varaxon Scan Hub uses exactly this order as six fixed priority bands. KEV matching fails closed (if the KEV data cannot be checked, the report says so rather than assuming no match), and EPSS is shown for every finding but never moves one down a band, because a probability that changes daily should not decide what a client signs off on. See it in the sample reports.

Common questions

What is a good EPSS threshold?

There is no universal one. Many teams treat an EPSS probability above roughly 0.1, or a percentile above 0.95, as worth fast-tracking, but the right threshold depends on how many findings you can realistically fix each cycle.

How often is the CISA KEV catalog updated?

CISA adds entries whenever it confirms new exploitation, often several times a week. Check against the current catalog every time you produce a report.

Is CVSS 4.0 replacing CVSS 3.1?

CVSS 4.0 was released by FIRST in 2023 and is being adopted gradually. Many scanners and databases still publish 3.1 scores, so reports should state which version a score comes from.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• Clients buy a managed outcome, not a scan. Package scanning, reporting and remediation together.
• A monthly report should show what changed: new, fixed and still open.
• Send remediation into the PSA as tickets so the work is tracked where your team already works.
• In the QBR, show trend and overdue items, not raw counts.

Sell the outcome, not the scan

Clients rarely understand why they need a vulnerability scan, and a one-off scan tells them very little. What they understand is a managed outcome: known weaknesses found every month, fixed on an agreed schedule, with a report that shows the business is getting safer. That framing also justifies a recurring fee.

A typical managed vulnerability service has four parts: scheduled scanning (internal credentialed and external), a monthly or quarterly report, remediation of the items within the MSP's scope, and a review with the client.

Pick a cadence you can act on

Monthly is the common baseline for small and mid-sized clients; regulated or internet-heavy clients need more. The constraint is usually not the scanner but the time to review results and do the work. How often to run vulnerability scans covers framework minimums.

The monthly report

The monthly client report should answer three questions on its first page:

1. What is new since last month, and does any of it need urgent action?
2. What did we fix?
3. What is still open, and is any of it overdue against the agreed timeline?

Put known exploited vulnerabilities at the top, keep the language non-technical and move host-level detail to an appendix. The report template gives the full structure.

Hand the work to the PSA

Findings that live only in a PDF do not get fixed. Turn each remediation action (not each finding) into a ticket with the affected hosts, the fix and the due date from the remediation SLA. Review tickets before they are created so the queue is not flooded with duplicates.

What to show in the QBR

• Trend: open findings by priority over the quarter, ideally falling, with an explanation if not (for example, credentialed scanning was added).
• Known exploited exposure: how many KEV-listed vulnerabilities were found and how quickly they were closed.
• Overdue items: what missed its timeline, why, and what is needed from the client (budget, downtime, a vendor).
• Risk acceptances: anything the client chose not to fix, with the reason and review date.
• Next quarter: the few larger projects that would reduce the most risk, such as replacing end-of-life systems.

Avoid opening a QBR with a total like "we found 1,200 vulnerabilities". It sounds alarming, says nothing about progress and invites the question of what you were doing.

Making it repeatable across clients

The work that does not scale is turning raw scanner exports into a report each client can read. Varaxon Scan Hub takes the export from the scanner you already use, ranks findings into six fixed priority bands, writes the report under your brand, creates reviewed remediation tickets in HaloPSA or ConnectWise PSA, and keeps each client's history so new, fixed and overdue items appear automatically. See the sample reports or view pricing.

Common questions

How do MSPs charge for vulnerability management?

Most bundle it into a per-device or per-user security tier, or sell it as a fixed monthly add-on per client. Pricing the outcome (scanning, reporting and remediation) rather than the scan avoids a race to the bottom on scanner cost.

Should MSPs white-label vulnerability reports?

Usually yes. The client relationship is with the MSP, so the report should carry the MSP's name and logo, with the client named separately.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• Seven sections: summary, scope, method, prioritized actions, remediation plan, limitations, appendix.
• The summary is for the decision-maker; everything technical goes later.
• Every finding needs evidence, a fix and an owner, not just a severity.
• State what the scan could not see. It protects you and the client.

Write for two readers

A vulnerability assessment report has two audiences. The decision-maker (owner, director, IT manager) reads the first page or two and decides what gets budget and time. The technician reads the action list and appendix and does the work. A report that tries to serve both on the same page serves neither. The template below separates them.

The template, section by section

1. Executive summary

One page, plain language. What was assessed and when, the overall picture in two or three sentences, and the three to five actions that matter most with what each protects against. No CVE numbers, no tables of counts.

2. Scope

The networks, hosts or applications in scope, anything explicitly out of scope, the scan dates and who authorized the assessment.

3. Method

The scanner and version, the check feed date, whether the scan was credentialed, and how findings were prioritized. If you rank by known exploitation, say so and name the source (CISA KEV, EPSS, CVSS).

4. Prioritized actions

Findings grouped into remediation actions, in priority order. For each action: what to do, why it ranks where it does, the affected hosts and the evidence (detected version, check output, CVEs).

5. Remediation plan

Owners and target dates per action, agreed with the client. Link this to the client's remediation policy or a standard SLA matrix.

6. Limitations

Hosts that could not be assessed or were only partially assessed, findings without CVE data, checks that could not run and anything else the scan cannot support. This is not a disclaimer to hide; it is part of the result.

7. Technical appendix

Per-host and per-finding detail for technicians, including informational findings. This is where the scanner's raw output belongs.

What every finding entry needs

Fields for each finding or action

Mistakes that get reports ignored

• Opening with a pie chart of 400 findings by severity.
• Listing the same missing patch once per host instead of once per action.
• Calling a host or finding "clean" when the scan simply could not see it.
• Recommendations like "apply vendor patches" without the version that fixes it.
• No dates, so the client cannot tell whether the report is current.

Generating the report from a scan export

Varaxon Scan Hub produces this structure from an uploaded scanner export: an executive summary written in plain language, scope and coverage statements, actions grouped and ranked into six priority bands, the fixed version for each action where one is known, and a technical appendix tied to the scanner evidence. MSPs can add their own logo and name the client separately. Download a sample report to compare it with this template, or read the step-by-step export guide.

Common questions

Is a vulnerability assessment report the same as a penetration test report?

No. A vulnerability assessment report covers automated scan findings and their remediation. A penetration test report documents what a tester could actually exploit and how. See vulnerability scan vs penetration test for the differences.

Should informational findings go in the report?

Keep them in the technical appendix. They are useful context, such as open ports and detected software, but putting them in the summary buries the actions that matter.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• Check scope and credential status before reading a single finding.
• Nessus severity comes from CVSS; it says how bad a flaw could be, not how likely it is to be used.
• Rank known exploited vulnerabilities (CISA KEV) first, then work down by severity and exposure.
• Hand the client actions, not plugin counts. Keep the raw detail as an appendix.

Why a raw Nessus report confuses clients

Nessus is built to be thorough. A routine scan of a 50-device office can return thousands of plugin results, including hundreds of informational items, many duplicates of the same missing patch across hosts, and a severity summary dominated by red. That output is accurate, but it answers the scanner's question (what did I detect?) rather than the client's question (what should we do this month?).

Reading a Nessus report well means separating three things: what the scan could see, what it found, and which of those findings deserve attention first. The rest of this guide takes them in that order.

Step 1: confirm what the scan could see

Before reading findings, look at the scope. A short list of clean-looking hosts can simply mean the scan never logged in.

• Targets and dates. Compare the scanned host list with the client's asset list. Missing hosts are a coverage gap, not good news.
• Plugin 19506, Nessus Scan Information. Every host has one. Its output shows the scanner version, plugin feed date, scan policy and whether credentialed checks ran.
• Plugin 21745, Authentication Failure - Local Checks Not Run. Its presence means the scanner could not log in and fell back to a network-only view of that host.
• Plugin feed date. An old feed misses recent vulnerabilities. Note the date in the report so the client knows how current the checks were.

Rule of thumb A host with credential failures should be reported as partially assessed. Presenting it beside fully credentialed hosts, with fewer findings, makes it look safer than it is. See credentialed vs non-credentialed scans.

Step 2: understand severity, CVSS and VPR

Nessus assigns each plugin a severity of Critical, High, Medium, Low or Info. That severity is derived from the CVSS base score of the underlying vulnerability, using the standard bands:

CVSS base score to severity

Tenable products also show a Vulnerability Priority Rating (VPR), Tenable's own threat-weighted score. VPR is useful inside Tenable, but it is proprietary, so it cannot be explained or reproduced outside that ecosystem. For a client report, public signals travel better: CVSS for impact, EPSS and CISA KEV for likelihood.

Step 3: read a finding properly

Each Nessus finding is a plugin result on a host and port. The fields that matter most for a report:

• Plugin ID and name. The stable identifier. Many plugins roll up several CVEs, for example a single "Microsoft Windows security update" plugin can cover dozens.
• Plugin output. The evidence: the installed version, the file path, the registry key or the banner the scanner saw. Always read this before calling something a false positive.
• Solution. Tenable's remediation text, usually "upgrade to version X or later" or a link to a vendor advisory.
• CVE and CVSS references. Present on most vulnerability plugins; absent on configuration findings such as weak TLS ciphers, which are real issues without a CVE.
• Exploit available. A flag that public exploit code or a framework module exists. It raises likelihood but is not the same as confirmed exploitation in the wild.

Group findings by remediation, not by plugin. Twenty plugins about one outdated browser are one action for the client: update the browser.

Step 4: decide what goes first

A defensible order for client work looks like this:

1. Vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalog, especially those with known ransomware use.
2. Critical findings (CVSS 9.0 or above) on systems reachable from the internet.
3. Other Critical and High findings, grouped by the patch or upgrade that fixes them.
4. Configuration findings without a CVE that still carry real risk, such as end-of-life software or weak remote access settings.
5. Low and informational items, kept as context.

This is close to the six priority bands Varaxon Scan Hub applies automatically. Band membership is calculated by code from the export and KEV data, so it is the same every time and can be explained line by line.

Step 5: export the right file

Nessus can export results as a .nessus file, CSV, HTML or PDF. Only the .nessus file is a complete, machine-readable record: it is XML containing the targets, the policy settings (with passwords stripped) and every result with its plugin output. CSV is convenient for spreadsheets but flattens structure; HTML and PDF are for reading.

If you plan to build a client deliverable, export the .nessus file. The export-to-report guide covers the equivalent choice for other scanners.

Turning the scan into a client report

A client report built from a Nessus scan should open with a short summary of the handful of actions that matter, in business language, then show the scope, the prioritized actions with owners and dates, and finally the technical appendix. The report template guide lists every section.

Varaxon Scan Hub does this from the .nessus file directly: it ranks the findings, groups them into remediation actions, writes the summary and keeps every statement tied to plugin evidence. Download the sample Nessus report to see the output.

Common questions

What file format does Nessus export?

Nessus exports scan results as a .nessus XML file, CSV, HTML and PDF. The .nessus file is the complete machine-readable export and the best input for any reporting tool.

What is plugin 19506 in Nessus?

Plugin 19506, Nessus Scan Information, records the scanner version, plugin feed date, scan policy and whether credentialed checks ran on each host. Check it first to confirm the scan's coverage.

Is Nessus severity the same as risk?

No. Nessus severity comes from the CVSS base score, which measures how severe a flaw could be in general. Risk also depends on whether the flaw is being exploited, how exposed the system is and how important it is to the business.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

• A credentialed scan logs in and reads installed software directly; a non-credentialed scan infers from the network.
• Credentialed scans usually find far more missing patches and produce fewer false positives.
• A failed login silently turns a credentialed scan into a non-credentialed one. Check for it on every host.
• Report coverage per host, so a partially assessed machine never looks cleaner than it is.

The difference in one paragraph

A non-credentialed (unauthenticated) scan sees a host the way an outside attacker does: open ports, service banners and responses to network probes. A credentialed (authenticated) scan also logs in, over SMB or WMI on Windows and SSH on Linux and macOS, and reads the installed software, patch level, registry and configuration directly. Both are useful. They answer different questions, and the report has to say which one it is answering.

What changes in the results

Typical differences between the two scan types

That last row matters for client conversations. The first time an MSP switches a client from network-only to credentialed scanning, the number of findings usually jumps. Nothing got worse; the scanner can finally see. Say so in the report before the client sees the chart.

The silent failure: credentials that did not work

When a scanner cannot log in, it does not stop. It completes a network-only scan of that host and moves on. The host then appears in the results with very few findings, which looks like good news.

• Nessus: check plugin 19506 (Nessus Scan Information) for whether credentialed checks ran, and look for plugin 21745 (Authentication Failure - Local Checks Not Run).
• Greenbone / OpenVAS: look for the authentication success or failure results the scan reports for SMB and SSH logins, and compare the QoD of results across hosts.
• Any scanner: compare finding counts per host. A Windows workstation with three findings next to identical machines with forty is almost always a credential problem.

Common causes are expired or rotated passwords, accounts without local administrator rights, firewalls blocking SMB or WMI, UAC remote restrictions on Windows and SSH key or sudo configuration on Linux.

How to report coverage honestly

1. State the scan type in the method section: credentialed, non-credentialed or mixed.
2. List hosts where credentials failed as partially assessed, separately from fully assessed hosts.
3. Do not compare finding counts between credentialed and non-credentialed hosts as if they measured the same thing.
4. Make fixing the credential failures an action in the report itself, so the next scan covers them.

Varaxon Scan Hub reads credential status from the export and shows coverage, credential failures and missing host context at the top of every report, so a partially assessed host is never presented as clean. The Nessus report walkthrough shows where those signals live in a .nessus file.

Common questions

Is a credentialed scan safe to run on production systems?

Generally yes; credentialed checks read information rather than attack services. Use a dedicated scanning account, schedule scans in an agreed window and avoid enabling intrusive or denial-of-service checks on production systems.

Do I still need non-credentialed scans if I run credentialed ones?

Yes, for internet-facing systems. An external, unauthenticated scan shows what an attacker on the internet can reach, which a credentialed internal scan does not tell you.

Does PCI DSS require credentialed scanning?

PCI DSS v4 requirement 11.3.1.2 requires internal vulnerability scans to be performed with authentication, effective from 31 March 2025.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan
Founder, Varaxon Technologies

Most "zombie" findings come from a handful of causes. Here's how to tell them apart.

1. The patch is installed but not active

Many updates only take effect after a reboot or a service restart. The scanner checks the running version or a registry key that doesn't change until then, so the finding stays open.

Check: pending reboots on the affected hosts, and whether your patch policy lets users postpone restarts indefinitely.

2. An old copy is still on disk

The main application was updated, but an older copy still sits somewhere: a portable install in a user folder, a bundled runtime inside another product, or a leftover version after an upgrade. Java, .NET runtimes, OpenSSL libraries and browsers are frequent culprits.

Check: the file path in the finding's evidence or output section. If it points somewhere you didn't expect, that's the copy to remove.

3. The scan ran without credentials (or with the wrong ones)

Without a working login, a scanner has to guess from banners and open ports. It can't see installed patch levels, so it may keep reporting issues that were fixed, or miss ones that weren't. A credential that worked last month may have expired or lost rights since.

Check: whether the scan's authentication succeeded on that host. Most scanners report this as its own informational finding.

4. The fix needs configuration, not a patch

Some findings, like weak TLS settings, SMB signing not required, or default credentials, aren't fixed by updates at all. Patching the server won't touch them.

Check: the solution text in the finding. If it says "configure" or "disable" rather than "update", it needs a change ticket, not a patch run.

5. The risk was accepted but never recorded

Sometimes a finding stays open on purpose: a legacy machine the client can't replace, or a line-of-business app that breaks on the new version. If that decision isn't written down, it shows up as "unfixed" every month and looks like a failure.

Check: whether the client has signed off on the exception. Record it with an owner and a review date, and report it separately from open work.

Make recurring findings visible

The quickest way to catch zombies is to compare each scan with the previous one and flag findings that were marked fixed but came back. Those deserve a closer look before another patch ticket goes out. Grouping them by cause (reboot, leftover copy, credentials, configuration, accepted risk) also tells you which part of your process needs tightening.

Varaxon Scan Hub reads exports from the scanners you already use and builds client-ready reports with prioritized actions and PSA tickets after your review. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: Credentialed vs non-credentialed scans · Vulnerability remediation SLAs

Here is a structure that works for MSPs, MSSPs and consultants presenting to owners, office managers and finance leads.

Start with one sentence about the business

Before any numbers, say what the scan means for them in plain words:

"Your network is in reasonable shape, but two systems have problems attackers are actively using right now, and we'd like to fix those this week."

That sentence does three things: it sets the tone (calm, not alarming), it names the urgent work, and it gives a timeline. Everything after it is supporting detail.

Translate severity into consequences

"Critical" and "CVSS 9.8" don't mean much to a non-technical listener. Describe what could happen instead:

CVSS scores are still the right starting point for you. The client just needs the consequence, not the number.

Group findings into a few actions

Clients approve actions, not findings. Fifty findings caused by one outdated browser version are one action: "update Chrome on all PCs". A good client summary usually has three to six actions, each with:

• what we'll do
• which systems it affects
• when it will be done
• whether it needs anything from them (downtime, budget, a decision)

Put the "known exploited" items first

If a finding appears on CISA's Known Exploited Vulnerabilities list, attackers are using it in the wild today. That's the easiest priority to explain: "This isn't theoretical, it's being used against businesses right now." Lead with those, even if a higher-scored finding sits elsewhere in the list.

Be honest about what's not urgent

Clients trust you more when you tell them what can wait. Saying "these 200 low-risk items go into our normal monthly patching" stops the report from feeling like a sales pitch and keeps the conversation on the few things that matter.

Show progress over time

A single report is a snapshot. From the second month, open with what changed: what was fixed, what's new, what's still open. A falling line of open high-priority findings is the clearest proof your service is working.

Leave them one page

After the meeting, send a one-page summary: the opening sentence, the action list, and the dates. Keep the full technical report as an appendix for whoever needs it.

Varaxon Scan Hub turns exports from the scanners you already use into client-ready reports with plain-language summaries and prioritized actions. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: How to turn a scan export into a client report