Penetration Testing Glossary
Penetrationstest-Bericht
A structured document that details the methods, findings, and recommendations of a penetration test. A professional penetration test report includes an executive summary, technical findings with CVSS scores, proof-of-concept, risk assessment, and prioritized recommendations.
A penetration test report is the final deliverable of a penetration test—and often the most important one. It must cater to two completely different audiences: senior management (executive summary, risk assessment) and the technical team (reproducible findings, proof of concept).
Structure of a Professional Penetration Test Report
1. Cover Page and Metadata
PENETRATION TEST REPORT
Client: Mustermann GmbH, Hauptstraße 1, 12345 Berlin
Contractor: AWARE7 GmbH, Gelsenkirchen
Test Type: Web Application Penetration Test
Scope: https://app.mustermann.de (Production System)
Test Methodology: Black Box / Gray Box (Mixed)
Test Period: February 10, 2026 to February 14, 2026
Report Date: 2026-02-20
Version: 1.0 (Final)
Classification: CONFIDENTIAL - For Client Use Only
Prepared by: Max Mustermann, OSCP, OSCE3
Reviewed by: Anna Schmidt, Lead Penetration Tester2. Executive Summary (for Management)
The Executive Summary should NOT contain any technical details.
It answers: "What did we find? What does this mean? What should we do?"
Structure:
┌────────────────────────────────────────┐
│ OVERALL RISK: CRITICAL │
│ Critical Findings: 2 │
│ High Findings: 5 │
│ Medium Findings: 8 │
│ Low Findings: 12 │
└────────────────────────────────────────┘
"During the penetration test, we were able to gain full database access to the
customer database containing 50,000 entries as an external attacker
without prior knowledge. Two critical
vulnerabilities made this possible within 4 hours.
We recommend immediately addressing the critical and high
findings (Findings 1–7) before developing new features."
Findings (Summary):
Risk Level | Count | Example
CRITICAL | 2 | SQL injection in the login form
HIGH | 5 | IDOR on /api/users/{id}
MEDIUM | 8 | Missing Rate Limiting
LOW | 12 | Missing Security Headers3. Technical Section - Findings Cards
Each finding is documented as a separate findings card:
══════════════════════════════════════════════
FINDING #01: SQL Injection in the User Form
══════════════════════════════════════════════
Severity: CRITICAL (CVSS v3.1: 9.8)
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE: CWE-89: Improper Neutralization of SQL Commands
CVE: N/A (custom application)
Status: Open / Under Fix / Fixed
Affected URL: POST https://app.mustermann.de/api/v1/users/login
Affected Parameter: `username`
Parameter:
DESCRIPTION:
The `username` parameter in the login form is inserted directly into an SQL query without validation
or parameterization.
This allows an attacker to execute arbitrary SQL commands
within the context of the database connection.
PROOF OF CONCEPT:
1. POST request to login endpoint:
username=admin'--&password;=anything
2. Manipulated SQL query:
SELECT * FROM users WHERE username='admin'--' AND password='...'
→ Comment (--) bypasses password verification
3. Successful login as admin without a password confirmed.
4. Database exfiltration (sqlmap):
sqlmap -u "https://app.mustermann.de/api/v1/users/login" \
--data="username=test&password;=test" \
--dbs --dump
5. Extracted data (excerpt):
Database: production_db
Table: customers (52,347 rows)
[email, name, address, IBAN, ...]
RISK ASSESSMENT:
Full database access without authentication.
GDPR reporting obligation in case of exploitation (Art. 33 GDPR).
Reputational damage if made public.
RECOMMENDATION:
IMMEDIATE ACTION (within 24 hours):
→ Implement prepared statements / parameterized queries
→ CORRECT: cursor.execute("SELECT * FROM users WHERE username=%s", (username,))
→ INCORRECT: cursor.execute("SELECT * FROM users WHERE username='" + username + "'")
MEDIUM TERM (within 7 days):
→ Enable WAF (virtual patch)
→ Restrict database access to least privilege
→ Include SQL injection in code reviews and SAST tools4. Attack Scenarios / Attack Chains
In addition to individual findings, a good report documents
the actual attack chain—how a real attacker proceeds:
Attack Chain #1: From SQL Injection to Complete Takeover
Step 1: SQL Injection (Finding #01)
→ Dump of all user data including password hashes (bcrypt)
Step 2: Password Cracking
→ 12% of hashes cracked (weak passwords)
→ Admin account compromised
Step 3: Admin Panel Access
→ Backup download possible (Finding #05 – insecure admin function)
Step 4: Backup contains DB credentials
→ Direct database access possible
Result: Complete database exfiltration in <2 hours
Affected data: 52,347 customer records (GDPR-relevant!)5. Action Plan
Prioritized Action Plan:
Priority | Finding | Effort | Responsible | Deadline
─────────────────────────────────────────────────
1 | SQL injection | 2h | Dev team | 24h
2 | IDOR /api/users | 4h | Dev team | 48h
3 | XXE in XML upload | 2h | Dev team | 48h
4 | Missing MFA Admin | 4h | IT Ops | 7 days
5 | Outdated jQuery | 1h | Dev Team | 7 days
...
20 | Missing HSTS Header | 30min | IT Ops | 30 days6. Appendix and Methodology
Appendix A: Testing Methodology
→ Tools Used: Burp Suite Professional, sqlmap, Nmap, ffuf
→ Standards: OWASP Testing Guide v4.2, PTES
→ Test start/end with timestamps
Appendix B: Scope
→ In-scope: app.mustermann.de, api.mustermann.de
→ Out-of-scope: mustermann.de (main website), internal systems
Appendix C: Tool Output (Raw Data)
→ Nmap scan output
→ Nikto report
→ OWASP ZAP baseline report
Appendix D: Communication Log
→ Who was notified?
→ Critical findings: immediate escalation to CTO (February 2, 2026, 2:32 PM)What Makes a Good Report
Good report: Bad report:
✓ Executive summary is understandable ✗ Only technical jargon
✓ Reproducible PoC steps ✗ "Found SQLi" without details
✓ Business impact described ✗ Only CVSS without context
✓ Prioritized actions ✗ Unsorted list of findings
✓ Screenshots / tool output ✗ No evidence
✓ Attack chains documented ✗ Isolated individual findings
✓ Retest results (if possible) ✗ No follow-up planned
✓ Delivered 2–4 weeks after testing ✗ Months-long waitRetest - Verify Findings
After resolving the findings:
→ Dedicated retest of the resolved vulnerabilities
→ New report section: "Resolved Findings"
→ Status update: "Open" → "Resolved" / "Partially Resolved"
Status Options:
Resolved (Closed): Vulnerability no longer exists
Partially Resolved (Partial): Main issue resolved, remainder still open
Accepted (Accepted Risk): Conscious decision not to fix
Open (Open): No resolution yet
