ExplainTheHack
← Back to Writing Professional Security Reports

Writing Professional Security Reports Brief

Core Skill

Write security reports where every finding is specific enough to reproduce, clear enough for a non-technical reader to understand the risk, and actionable enough that a remediation team knows exactly what to fix.

Writing Workflow

  • Organize raw notes and evidence by finding before writing
  • Write each title as a specific, descriptive sentence — not a generic vulnerability type
  • Explain root cause in the description, not just what you found
  • Include reproduction steps a different tester could follow without your context
  • Frame impact in business terms — what could happen to the organization
  • Assign severity with defensible reasoning, especially for High and Critical
  • Write specific remediation — what to change, where, and how
  • Review for consistency: do ratings align with impact? Are screenshots labeled?

Quality Bar

Every finding should be reproducible by a different tester, understandable by a non-technical reader, and actionable by a remediation team — without any of them needing to ask the original tester for clarification.

Common Pitfalls

  • Vague titles — 'Cross-Site Scripting' vs 'Stored XSS in User Profile Bio Field Executes in Admin Dashboard Context'
  • Overscoring severity — destroys credibility and makes it impossible for readers to prioritize real critical issues
  • Reproduction steps that assume the reader has your environment — a different tester should be able to follow them
  • Impact in purely technical terms — 'attacker can read the database' means nothing without 'which exposes 50,000 customer payment records'

Interview Framing

I structure every finding so a developer can reproduce it, a manager can understand the risk, and a compliance team can verify the severity. I write titles specific enough to triage without opening the finding. I score severity using CVSS with documented reasoning. The test I use: could someone who was not on the engagement pick up the report and act on every finding without calling me?

Finding Checklist

  • Title: specific enough to triage without opening?
  • Description: explains root cause, not just symptoms?
  • Reproduction: a different tester could follow without your context?
  • Impact: framed in business consequences, not just technical effects?
  • Severity: defensible with documented reasoning?
  • Remediation: specific enough for the dev team to act on?