Report Creation
Objectives: By the end of this topic, you will be able to…
- Properly document a technical activity
- Organize findings with clarity and order
- Produce reproducible and exportable reports
- Recognize the importance of professional reports in audits and pentests
Why is it important to know how to write cybersecurity reports?
An excellent technical analysis loses value if it is not communicated well. In cybersecurity, reports are the primary means of documenting findings in audits, pentests, or forensic analyses, recommending mitigation actions, and communicating risks to non-technical stakeholders such as executives or management. They also serve as evidence records in legal or regulatory contexts.
“If it is not documented, it does not exist.”
Structure of a cybersecurity technical report
| Section | Contents |
|---|---|
| Cover / Title | Name of analysis, author, date, confidentiality |
| Table of contents | For fast navigation of the document |
| Introduction | Objective of the analysis, scope, client context |
| Scope & Rules of Engagement | Testing boundaries, authorized targets, exclusions, legal constraints, and agreed-upon limitations |
| Methodology | Techniques, tools and sources used |
| Findings | Detailed list of vulnerabilities with description, evidence, impact, severity, and mitigation |
| Conclusions | Technical summary of the security status |
| Appendices | Extensive details, complete outputs, scripts, configuration |
Differences between technical and executive reports
| Characteristic | Technical Report | Executive Report |
|---|---|---|
| Audience | Security teams, sysadmins | Managers, directors, customers |
| Language | Specific, with technical terminology | Clear, simplified, impact oriented |
| Contents | Technical details, commands, evidences | Summary of findings and business implications |
| Length | Long (may include appendices) | Short (2-4 pages max.) |
Both reports may be derived from the same work, but should be written with different objectives in mind.
Best practices for technical writing
Good technical writing demands clarity, consistency, and objectivity: use precise, unambiguous language; apply consistent terminology throughout; and base all statements on facts and evidence rather than speculation or personal judgment. On the formatting side, maintain a clean structure with tables, numbering, and styles that aid navigation, include exact commands, tool versions, and configurations for full reproducibility, and cite relevant CVEs, standards (OWASP, MITRE), and tool documentation to support your findings.
A good report not only shows a problem, but also how it was discovered and how to solve it.
Evidence collection and organization
Technical evidence takes many forms: screenshots of terminals, browsers, or tools; file hashes, traffic logs, and activity logs; configuration files or scripts used; and raw command output from tools like nmap, whois, and dig. Regardless of type, every piece of evidence should be named clearly and stored in an orderly structure, captured at the moment of discovery without alteration, timestamped or annotated with context, and accompanied by a SHA-256 hash to verify its integrity later. Each screenshot should appear alongside explanatory text so that anyone reading the report can understand what it shows without having to ask.
Tools for generating professional reports
| Tool | Description |
|---|---|
| Markdown | Lightweight language ideal for reproducible technical documentation |
| Typora / Obsidian / VS Code | Markdown-friendly editors with PDF export |
| LaTeX | For academic reports or reports with complex formatting |
| LibreOffice / Word | Visual templates for executive or formal reports |
| CherryTree | Structured technical notes during the analysis |
| Flameshot | Quick screenshots with annotations |
Document from the beginning of the analysis, not at the end. The report is a process that runs parallel to the technical investigation.
Hands-on lab
Requirements: Kali Linux, Metasploitable 2 (deployment guide), CherryTree
Part 1: Structure and analysis of technical reports
- Review the example of a simulated technical report
- With your partner, identify and discuss the purpose of each section
Part 2: Capturing and documenting evidences
- Deploy the Metasploitable 2 machine using the attached guide
- Execute a controlled network scan:
nmap -sS -A -T4 192.168.1.10 -oN nmap_scan.txt- Analyze and highlight findings: open ports, service versions, known vulnerabilities
- Create a findings table:
| Port | Service | Short description | Estimated risk |
|---|---|---|---|
| 22 | SSH | Service accessible from local network | Medium |
| 80 | HTTP | Website with possibly sensitive information | High |
? Which open port in your findings table represents the highest risk, and why? What additional information would you need to determine whether it is actually exploitable?
Part 3: Organization with CherryTree
- Create a
.ctdfile with the following hierarchy:
Project: Host scanning and analysis
-- Methodology
-- Results
-- Evidences
-- Recommendations
-- Notes by tool
- Insert screenshots, text snippets with tool outputs, notes and observations
? What criteria did you use to decide which information belongs in each CherryTree node? Would someone who was not present during the scan be able to reconstruct the analysis from your notes alone?
- Export to
.pdfor.html
Part 4: Best practices for technical writing
- Review a draft of a technical finding with your partner and improve clarity, objectivity, and references
? What were the most common clarity or objectivity problems you found in the draft? Why does objectivity matter more in a security report than in other forms of technical writing?
- Write at least one full finding using:
Finding title
---------------------
Summary:
Technical description:
Attached evidence:
Recommendations:
Submission
- PDF report generated using CherryTree (or original
.ctdfile) - Screenshots used as evidence
- Generated
nmap_scan.txtfile - Technical findings table
- Personal reflection (max. 1 paragraph)
Key concepts
| Term | Definition |
|---|---|
| CVE | Standardized identification system for known vulnerabilities |
| Pentesting | Authorized security assessment that simulates real attacks |
| Rules of Engagement (RoE) | Agreed-upon boundaries defining what can be tested, how, when, and what is excluded, protecting both tester and client |
| Hash | Function that generates a unique fingerprint of a file to verify its integrity |
| Nmap | Network scanning tool for host and service discovery |