🛡️ Methodology Checklist
- Map each finding to CVSS score and severity tier
- Include remediation timeline recommendations (immediate/30/90 day)
- Executive summary: risk posture overview, top 3 priorities
- Technical findings: step-by-step reproduction for each issue
- Appendix: raw scan data, methodology description
- Proofread for client-appropriate language (no unnecessary jargon)
- Deliver in agreed format (PDF + editable Word/DOCX)
🎯 Operational Context
Think Dumber First: The report IS the deliverable. Clients don’t see your shell — they see your document. Start the report during the assessment, not after. Capture evidence (screenshots, command output) as you find findings — recreation post-assessment is inaccurate and time-consuming. Executive Summary: no CVE IDs, no port numbers — business risk language only.
When you land here: Assessment complete or wrapping up. Structure: Executive Summary → Risk Rating Summary Table → Findings (Critical → High → Medium → Low → Info) → Appendix (methodology, scope, tools). Every finding needs: title, CVSS, description, evidence, impact, recommendation.
⚡ Tactical Cheatsheet
| Command | Tactical Outcome |
|---|---|
| (No CLI commands — reporting framework) |
🔬 Deep Dive & Workflow
Core Concept
Automated tools find vulnerabilities. The report bridges the gap between technical findings and client action. Must be readable by both technical staff and non-technical executives.
Report Structure
1. Executive Summary
- Audience: C-Suite / Executives (non-technical)
- High-level risk overview, immediate priorities
- Include bar charts by severity for visual posture
2. Overview of Assessment
- Methodology used
- Tools leveraged (Nessus, OpenVAS, Nmap, etc.)
3. Scope and Duration
- Authorized target IP ranges/domains
- Testing window (specific dates and times)
4. Vulnerabilities and Recommendations
- Audience: IT / Developers / Security Team
- Findings AFTER eliminating false positives through manual verification
- Group by issue type or severity
Standard Finding Elements (Every Finding Must Include)
- Vulnerability Name
- CVE identifier
- CVSS Score
- Description of Issue
- References (vendor links, patch notes)
- Remediation Steps (actionable)
- Proof of Concept (screenshots / reproduction steps)
- Affected Systems
Best Practices
- Clarity: Write so any audience can understand
- Reproducibility: Technical descriptions must allow reader to reproduce
- Conciseness: Point sentences, proper grammar
- Never submit raw Nessus/OpenVAS PDF as final deliverable — use as appendix only
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| Client disputes finding severity | Different risk tolerance from vendor | Walk through CVSS metrics; offer rescoring with Environmental modifiers; document consensus; never remove valid findings |
| Finding marked ‘won’t fix’ by client | Business decision | Document as ‘Risk Accepted’; include client justification; note in report that risk acceptance does not eliminate vulnerability |
| Evidence screenshots are blurry or incomplete | Screen capture quality issues | Capture command output to text files with tee; prefer code blocks over screenshots in reports; include raw output |
| Technical jargon in executive summary | Wrote for technical audience instead of C-suite | Rewrite: no CVE IDs, no port numbers, no command syntax; focus on business risk, regulatory exposure, and impact |
| Report is 200+ pages and client won’t read it | Information overload | Executive summary: max 2 pages; Critical/High: full narrative; Medium/Low: table format only; move scan data to appendix |
📝 Reporting Trigger
Finding Title: (VA_Reporting is methodology — no vulnerability. Deliverable quality findings should have: Title, CVSS v3.1 Score + Vector String, Severity, Affected Asset(s), Description, Technical Impact, Business Impact, Evidence [screenshot/output], Recommendation, References [CVE/CWE].)