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.

🎯 Clarity

Be understood first time

📊 Precision

Accurate and verifiable

🤝 Professional

Constructive, not critical

Actionable

Clear next steps

Know Your Audience

Critical Concept

A penetration test report typically has multiple audiences with different needs. Write for all of them, but know which sections serve which readers.
👔

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

❌ Too long:

"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."

✅ Better:

"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

❌ Vague:

"Many user records could be accessed."
"The password policy was weak."

✅ Specific:

"50,847 user records were accessible."
"Passwords require only 6 characters with no complexity."

Writing Impact Statements

The Impact Formula

Effective impact statements follow this structure: What can happen + Who is affected + How severe + Business consequence

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. 1. Immediate mitigation - What can be done today
  2. 2. Root cause fix - The proper long-term solution
  3. 3. Detection - How to monitor for exploitation
  4. 4. Prevention - How to prevent recurrence
  5. 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

remediation-example.py
python
# 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"

"An attacker could potentially possibly gain access..."
"An attacker can gain access..." (if confirmed)

Use "can" for confirmed vulnerabilities, "could" for theoretical risks

Mistake: Acronym Overload

"IDOR in the REST API allows BOLA via JWT manipulation"
"Insecure Direct Object Reference (IDOR) in the API allows..."

Define acronyms on first use, limit to 2-3 per sentence

Mistake: Missing "So What?"

"X-Frame-Options header is missing."
"Missing X-Frame-Options enables clickjacking attacks that could trick users into performing unintended actions."

Always explain the impact, not just the finding

Mistake: Vague Remediation

"Implement proper input validation."
"Validate email format using regex, sanitize with htmlspecialchars(), limit to 254 characters."

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

Have a colleague review your report before delivery. Fresh eyes catch errors and unclear explanations. Build time for at least one review cycle into your project timeline.