How to Write a Penetration Test Report: KaliLinux.net Practical Guide

A penetration test is not finished when the last service is enumerated or the final session closes. On KaliLinux.net the report is treated as the primary deliverable because it carries the findings, risk context, and remediation guidance that clients actually use. A clean report also protects the tester by documenting scope, authorization, and exactly what was performed during the engagement.

Before opening a document editor, open the Kali workspace. The evidence collected through nmap, Wireshark, Metasploit, and manual testing becomes the raw material for every section. If a finding cannot be supported by a command, screenshot, or log, it does not belong in a professional report.

Why the Report Is Part of the Test

A penetration test has no real finish line without documentation. The client may never see the terminal session, the Metasploit module output, or the time spent pivoting through an authorized lab network. What the client receives is the report, and that report is how technical work turns into decisions about patching, segmentation, and budget.

The Penetration Testing Execution Standard (PTES) technical guidelines define reporting as one of seven main phases. That standard exists because even a strong technical test loses value when the findings are buried, vague, or unsupported. On KaliLinux.net the rule is simple. If the evidence is not in the report, the finding does not exist.

A useful report also limits scope creep. It shows exactly which systems were tested, which tools were used, and which actions were authorized. That is important for legal protection and for building trust with the client.

Collect Evidence While You Work in Kali

Waiting until the end of the engagement to collect evidence is a common mistake. Kali Linux makes evidence collection easier when you save output as you go. For example, nmap can write results in three formats with one command using the -oA flag. That gives you normal, grepable, and XML output from a single scan.

Wireshark captures should be saved with descriptive filenames that include the target, date, and test phase. Metasploit can log console output with the spool command. These small habits save hours later because you do not need to rerun scans or reconstruct what happened during the authorized test.

Screenshots matter just as much as raw tool output. Take them when a service responds, when a vulnerability confirms, and when a control blocks an attempt. Annotate the screenshot immediately so the context does not disappear. A picture of an open port means little. A picture with the target IP, timestamp, and tool command makes a clear piece of evidence.

Build a Report Structure That Repeats

A penetration test report should follow the same structure from engagement to engagement. That does not mean every report looks identical, but consistency helps clients find what they need. A practical structure starts with the executive summary, then scope, methodology, detailed findings, and remediation steps.

Scope is not filler. List the authorized IP ranges, URLs, applications, and testing types. If a client approved only internal network testing, say so. This protects both sides if a question arises later about what was allowed. Methodology should explain the testing approach without becoming a textbook chapter.

The detailed findings section is where technical readers spend most of their time. Every finding should identify the affected asset, the risk level, the evidence, and a clear remediation. Order the findings by severity so the most urgent issues appear first. Use consistent naming for assets so the report is easy to search.

Turn Tool Output into Findings

Raw tool output is not a finding. An nmap scan that shows an open port is only a starting point. The finding should explain why the open port matters in the context of the authorized test. For example, an outdated SMB service that allows unauthenticated access to a sensitive share is a real finding. An open port with no exposure beyond expected service operation may not be.

Metasploit output can show whether a module succeeded or failed, but the report needs to state what the success means. If a lab test confirms a vulnerability with a Metasploit module, include the module name, target host, and result. Do not simply paste the entire console log. Select the lines that matter and explain them.

Wireshark evidence is useful for network-based findings. A pcap can show plaintext credentials, suspicious traffic, or missing encryption. But a large packet capture without explanation is not helpful. Label the relevant packets and summarize what they prove.

Severity ratings should be consistent. Use a simple scale such as critical, high, medium, low, and informational. Define the scale in the methodology section so readers understand the difference between high and critical.

Write the Executive Summary for People Who Approve Budgets

The executive summary should not be an afterthought. Many decision makers read only that section and the remediation table. It needs to answer three questions quickly. What was tested, what is the overall risk, and what should the organization do next.

Avoid security jargon in the executive summary. Instead of saying that an attacker chained CVE-2024-1234 with a weakly configured service, say that a remote unauthenticated user could access sensitive internal data. Then state the business impact and the immediate action.

Keep the summary short. Two or three paragraphs are enough. Follow with a short table of key findings, but do not make the summary feel like a wall of data. This is also where KaliLinux.net recommends putting the overall risk rating and a clear statement about whether the environment is improving or needs immediate attention.

Quality Checks Before Delivery

A penetration test report should be reviewed the same way code is reviewed. Check asset names, IP addresses, and tool output for accuracy. A report with the wrong IP address can send the client team in the wrong direction.

Read every finding with one question in mind. Could someone outside the test understand what happened and what to do next? If the answer is no, rewrite that section. Remove vague words like maybe, possibly, or could be without saying what the tester actually observed.

The final check is scope confirmation. Verify that every action described in the report was authorized and performed inside the agreed boundary. This protects the tester, the client, and the value of the report.

When the report is clean, specific, and evidence-based, the next penetration test becomes easier. The client knows what to fix, the tester has a clear record, and the Kali tool output finally supports a decision instead of just filling a folder.