Report Writing Guide
Your technical skills are only as valuable as your ability to communicate them. This guide covers professional writing techniques that transform raw findings into actionable, persuasive security reports.
Be understood first time
Accurate and verifiable
Constructive, not critical
Clear next steps
Know Your Audience
Critical Concept
Executive Leadership
CISOs, CTOs, board members, risk managers
They care about:
- • Business risk and impact
- • Compliance implications
- • Cost of remediation vs breach
- • Competitive/reputational risk
- • Resource allocation decisions
Write with:
- • Business language, minimal jargon
- • Dollar figures when possible
- • Risk ratings (Critical/High/Med/Low)
- • Clear recommendations
Technical Teams
Developers, sysadmins, DevOps, security engineers
They care about:
- • Exact reproduction steps
- • Root cause analysis
- • Specific code/config fixes
- • Integration with their workflow
- • False positive clarification
Write with:
- • Technical precision
- • Code samples
- • Step-by-step PoCs
- • CWE/CVE references
Compliance & Audit
Auditors, compliance officers, regulators
They care about:
- • Methodology documentation
- • Scope and limitations
- • Mapping to frameworks
- • Evidence chain of custody
- • Remediation verification
Write with:
- • Standard references (OWASP, NIST)
- • Clear methodology
- • Objective language
- • Traceable evidence
Professional Tone
❌ Avoid This Tone
"Your security is terrible. Anyone could hack this in 5 minutes."
Problem: Condescending, unprofessional, unhelpful
"We pwned the domain controller and dumped all credentials lol"
Problem: Informal language, lacks professionalism
"This is a critical vulnerability that shows a complete disregard for security best practices."
Problem: Judgmental, attacking the team
✅ Use This Tone
"Multiple critical vulnerabilities were identified that could allow unauthorized access to sensitive systems."
Better: Objective, factual, professional
"Domain administrator access was achieved through credential extraction from the domain controller."
Better: Technical, precise, neutral
"This critical vulnerability represents a significant risk that should be prioritized for remediation."
Better: Constructive, action-oriented
Active vs Passive Voice
Use active voice for findings and recommendations. Use passive voice sparingly when you want to focus on the action rather than the actor.
Active (Preferred)
- • "The application accepts malicious input..."
- • "An attacker can exploit this..."
- • "We identified SQL injection in..."
- • "Implement input validation to..."
Passive (Use Sparingly)
- • "Malicious input was accepted..."
- • "This vulnerability can be exploited..."
- • "SQL injection was identified..."
- • "Input validation should be implemented..."
Writing for Clarity
Technical Jargon Translation
| Technical Term | Executive Translation |
|---|---|
| SQL Injection | Database manipulation allowing data theft or modification |
| Cross-Site Scripting (XSS) | Malicious code execution in users' browsers, enabling session hijacking |
| Remote Code Execution (RCE) | Complete server compromise allowing full system control |
| Privilege Escalation | Gaining unauthorized administrative access from limited permissions |
| IDOR | Unauthorized access to other users' data by manipulating identifiers |
| SSRF | Using the server to access internal systems or cloud resources |
| Credential Stuffing | Using leaked passwords from other breaches to access accounts |
| Lateral Movement | Spreading access from one compromised system to others |
Sentence Structure Tips
Keep Sentences Short
"The application was found to be vulnerable to SQL injection attacks in the login functionality which could allow an attacker to bypass authentication and gain access to the admin panel where they could then modify sensitive data."
"SQL injection was identified in the login form. This allows authentication bypass. An attacker could access the admin panel and modify sensitive data."
Use Specific Numbers
"Many user records could be accessed."
"The password policy was weak."
"50,847 user records were accessible."
"Passwords require only 6 characters with no complexity."
Writing Impact Statements
The Impact Formula
Impact Statement Examples
Critical - SQL Injection
"An unauthenticated attacker could extract the entire customer database containing approximately 250,000 records including names, email addresses, and hashed passwords. This would result in mandatory breach notification under GDPR and CCPA, estimated regulatory fines of $1-5M, and significant reputational damage."
High - Stored XSS
"An attacker could inject malicious scripts into user profile pages affecting all visitors to those profiles. This enables session hijacking of administrative accounts, potentially compromising the entire platform. The attack requires no user interaction beyond viewing a profile."
Medium - Information Disclosure
"Error messages expose internal server paths, framework versions, and database types. While not directly exploitable, this information aids attackers in identifying known vulnerabilities and crafting targeted attacks against the infrastructure."
Writing Remediation Guidance
Remediation Structure
- 1. Immediate mitigation - What can be done today
- 2. Root cause fix - The proper long-term solution
- 3. Detection - How to monitor for exploitation
- 4. Prevention - How to prevent recurrence
- 5. References - Links to documentation
Example: SQL Injection
Immediate: Apply WAF rule to block SQLi patterns on /login endpoint
Fix: Use parameterized queries (see code sample below)
Detect: Monitor for SQLi signatures in application logs
Prevent: Implement SAST scanning in CI/CD pipeline
Reference: OWASP SQLi Prevention Cheat Sheet
Including Code Samples
# Vulnerable Code (Include for context)
query = "SELECT * FROM users WHERE username = '" + user_input + "'"
cursor.execute(query)
# Recommended Fix
query = "SELECT * FROM users WHERE username = %s"
cursor.execute(query, (user_input,))
# Or using ORM (best practice)
user = User.objects.filter(username=user_input).first()Common Writing Mistakes
Mistake: Overusing "Could"
Use "can" for confirmed vulnerabilities, "could" for theoretical risks
Mistake: Acronym Overload
Define acronyms on first use, limit to 2-3 per sentence
Mistake: Missing "So What?"
Always explain the impact, not just the finding
Mistake: Vague Remediation
Be specific enough for developers to implement
Pre-Submission Checklist
Content Quality
- All findings have clear impact statements
- Remediation is specific and actionable
- Executive summary is business-focused
- Technical details are accurate
- Scope and limitations clearly stated
Writing Quality
- Spell check completed
- Grammar reviewed
- Consistent terminology throughout
- Professional tone maintained
- Read aloud for flow
Pro Tip: Peer Review