PENTEST.RED / REPORT
Example penetration test report
The example shows how one risk connects to an executive decision, an engineering task, and a verifiable outcome. Dangerous payloads and operational secrets are deliberately omitted.
Every organization, system, event, and conclusion on this page is fictional. It demonstrates document structure and does not claim that an engagement took place.
01 / DECISION
Executive summary
Within the agreed test scope of the fictional Example Workspace SaaS product, one cross-organization data-isolation scenario was confirmed. It required a valid low-privilege account and knowledge of a test-object identifier. No destructive action or access to real data occurred. The priority is to restore server-side ownership checks and assess equivalent operations.
Risk-owner decisions
- Assign remediation ownership to the API team.
- Review the shared object-authorization control rather than patching one route only.
- Do not extend the conclusion to untested services or environments.
02 / BOUNDARIES
Scope and limitations
This example shows how a report separates actual coverage from exclusions. A real document should name versions, dates, roles, and test environments.
Tested
- Test web application and API v2.
- Two test organizations and Member / Manager roles.
- Project-object read and update operations in agreed scenarios.
Not tested
- Production and real-user data.
- Load, availability, and resilience behavior.
- Administration console and third-party file service.
03 / FINDING-001
Technical finding
Insufficient object-ownership check when updating a project
A user in one test organization could address an object belonging to another organization through the API. The server required a valid session but did not verify object ownership for one update operation.
Safe evidence
The test log records a successful response after changing a purpose-built marker field on a test object. Identifiers, tokens, and response content are redacted. In a real engagement, this evidence would be delivered in a protected report appendix; it is not published on this demonstration page.
Observed impact
Within the test data, the scenario allowed modification of another organization’s object. No claim is made about other object types because their routes would require separate validation.
04 / REMEDIATION
Remediation plan
The fix should restore the server-side trust boundary and cover the class of equivalent operations.
- 01
Resolve the object only within the organization derived from a server-validated session.
- 02
Apply a shared authorization policy to every object read and update operation.
- 03
Add negative integration tests across organizations and roles.
- 04
Log rejected cross-tenant access without storing sensitive values.
05 / ACCEPTANCE
Retest and acceptance
Retesting begins after the team identifies the build, environment, and changed components. It covers the original scenario and reasonable bypasses in the same control class.
Retest acceptance criteria
- A user in organization A cannot read or change test objects owned by organization B.
- The control applies to direct API calls and does not depend on UI restrictions.
- The expected denial is consistent for tested roles and does not disclose whether the object exists.
- Valid owner operations continue to work.
Remediated — acceptance criteria met in test build 2.4.1. Production was not tested. This status is part of the synthetic example.
06 / LIMITS
Limits of the conclusion
A pentest supports conclusions about an agreed scope and period; it does not guarantee the absence of vulnerabilities. Later changes, excluded components, and unavailable roles require separate assessment.
PENTEST.RED
Apply this structure to your engagement
Start by defining assets, roles, prohibited actions, and the decisions the report must support.