What should the report prove?
Your pentest report should explain the failed control and the demonstrated consequence, not just assign a severity. Look for tenant pairs, transaction states and workload permissions, reproducible observations and affected owners. Coverage gaps and untested consequences must remain visible so the report supports a defensible decision.
An executive view with bounded conclusions
Identify where a legitimate API call becomes an unauthorised operation, where workload credentials can cross service boundaries and what a realistic fix must preserve.
Summarise tested functions, relevant risks, controls that held and decisions requiring ownership. Explain assumptions and assistance rather than presenting the broadest possible compromise claim.
A technical record that can be checked
- Scope, versions, dates, roles and authorised test conditions.
- Architecture and tested trust paths, with clear boundaries.
- UTC timestamps, requests, responses and redacted evidence excerpts.
- Findings with reproduction conditions, affected assets and limits.
- Coverage gaps, denied paths and actions deliberately not performed.
A treatment plan for each finding
Identify immediate containment separately from the durable repair. Assign the system or process owner and note dependencies on suppliers, releases or operational approval. Define what must be observed before an item can be closed.
A record of validation
A passed retest identifies the changed version, tested principal and actual result. A proposed retest is labelled pending. Detection replay and restoration exercises are recorded separately from vulnerability closure, because each answers a different question.
Inspect the format before procurement
The fictional Fintech AG assessment provides 68 pages with diagrams, three scenarios, twelve findings, technical evidence and control mapping. It demonstrates the reporting format and is not a report of real client work.
