The report
Sample penetration test report
This is what you receive. The report is written so management understands the business risk and your developers can actually fix the issues.
Demo report — illustrative data only
The report shown here is a demo for a fictional system called example.test. The findings, figures and evidence were written for illustration only and do not refer to any real customer. This page contains no exploit code or real personal data.
Demo report — illustrative data only
Application penetration test report — example.test
A fictional sample system. No real customer findings, real identifiers or exploit code.
Executive summary
The test was performed within the agreed scope, against a test environment and within a coordinated time window, after written authorization. The most significant finding lets a signed-in user reach another user's data by changing an identifier in a request. The fix is concentrated in the server-side authorization layer.
- Findings
- 4
- High
- 1
- Scope
- Web + API
Findings table (illustrative)
APP-01 · Access control bypass between users
Authorization
APP-02 · Unnecessary fields exposed in an API response
API / Data exposure
APP-03 · Missing session renewal after password change
Session
APP-04 · Missing security headers in application responses
Configuration
APP-01 — Access control bypass between users
Business impact: A signed-in user can view another account's data. In a multi-tenant system, this means data exposure between customers.
Evidence: Screenshots and request/response records from the authorized test environment, using fictional identifiers only.
Reproduction: A step-by-step description of what was done in the authorized test environment, with no ready-to-use exploit code.
Remediation: Verify resource ownership on the server side at every endpoint, rather than hiding it on the client.
Prioritization and what happens after the report
- 1. Fix authorization and authentication findings — first priority.
- 2. Fix API data exposure and session management.
- 3. Harden configuration and security headers.
- 4. Review call with the team to clarify findings and recommendations.
- 5. Retest within the agreed scope, once fixes are in place.
The report reflects the system's state at the point in time and within the scope tested. It does not guarantee that every existing vulnerability was found.
What each part of the report tells you
Executive summary
The big picture in business language: the main risk, the possible impact and the recommended order of handling.
Scope and methodology
What was tested, what was out of scope, in which environment and time window. OWASP serves as an accepted methodological framework.
Severity and business impact
A severity rating together with what it means for your system and customers, not just a technical description.
Evidence and reproduction
Documentation from the authorized test environment and described reproduction steps, with no ready-to-use exploit code.
Prioritized remediation
What to fix first and how, written for your development team rather than as a generic tool list.
Review call and retest
A call to clarify findings, and retesting of fixed findings according to the agreed scope.
Further reading: how to build a penetration test report that leads to remediation →
What the report doesn't guarantee
- The report reflects the system's state at a point in time and within the scope tested
- It does not guarantee that every existing vulnerability was found
- It does not state that the system is immune or fully secure
- Acceptance of the report by an enterprise customer depends on that organization's requirements
Training is a separate HPI School service, subject to scoping, and is not included in the penetration test.