8 min read

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

Likely False Positives

The same sentence can overstate a finding to a developer and understate it to a board. These are the patterns a reviewer catches in a prose pass, before the client does.

  • Can for could: An attacker can extract the customer database in a finding demonstrated only on a staging replica, or could in a finding that was proven end to end. Both misstate the evidence, and the second gets discounted.
  • Impact stated as a category: SQL injection was found describes the class, not the consequence. The reader has to infer the risk and will usually infer less than is there.
  • Fear as severity: Language that escalates tone without a matching CVSS score reads as advocacy, and the client discounts the finding along with the tone.
  • Passive voice hiding the actor: Malicious input was accepted leaves out who could send it and from where, which is the part the risk depends on.
  • Vague quantities: Many records and several systems understate scope the evidence already quantifies. If the number is known, print it; if it is not, say so.
  • Acronyms on first use: A reader who meets an unexpanded acronym assumes the report is not for them and stops reading, which understates every finding after it.
  • Remediation as imperative only: Implement proper validation reads as a fix while leaving the actual change unspecified, so nothing gets fixed and the finding returns.

Fixing the Artefact

Claims and evidence

  • • Replace can with could wherever the finding was not demonstrated, and the reverse where it was
  • • Print the number the impact statement already implies
  • • Name the actor and the starting position in every impact statement

Structure

  • • Lead each finding with the consequence, then the mechanism
  • • Keep one term per concept across the report instead of using synonyms
  • • Define each acronym at first use, then drop the expansion

Audience split

  • • Move mechanism and payload detail out of the executive summary
  • • Keep business consequence out of the reproduction steps
  • • Name the framework version each compliance claim maps to

Final pass

  • • Read the report aloud for sentence length
  • • Have someone who was not on the engagement read the executive summary
  • • Search for stacked hedges such as could potentially possibly before sending

Related Topics

Report Templates

Full templates to apply these writing techniques.

Screenshot Guide

Visual evidence that complements clear writing.

Executive Summary

Apply these principles to executive summaries.

Finding Template

Structure individual findings effectively.