Nmap to report: the guide

You already ran the scan. The distance between an Nmap XML file and something you can put your name on and send to a client is real work, and it is the part nobody enjoys. Here is the path from one to the other.

The good news: the scan already holds most of the content. The effort is in the last stretch.

Run it so the output is usable

Use service and version detection and export to XML: nmap -sV -oX scan.xml <target>. The XML carries the structure, ports, services, versions, script output, that you lose the moment you copy from the terminal.

Grepping a text dump is how findings go missing. Machine-readable output is what lets anything downstream be reliable.

A list of open ports is not a report

An open 3306 is a fact, not a finding. The finding is 'MySQL is reachable from an untrusted network, here is why that matters and what to do'. The value you add is the context around the raw observation.

This is the step where a scan becomes an assessment: severity, impact in this environment, and a fix the client's team can carry out.

Correlate, deduplicate, prioritise

Run more than one tool and you get the same issue three times. Nmap, Nessus and Nuclei will all report the same exposed service in their own words. One finding with three pieces of evidence reads far better than three near-duplicates.

Then rank by what actually matters: CVSS, whether the service is exposed, whether the flaw is known to be exploited. The top of the list is what the client fixes first.

Write for the reader, then put your name on it

The last stretch is the deliverable itself: an executive summary in plain language, remediation grouped by priority, verification steps, and your firm's branding on every page.

That final 20% is exactly what Dossier automates, from the export you already have to a reviewed report, so you spend your time on the testing rather than the formatting.