"Penetration test" can describe very different scopes and depths. Ask what assets, identities and workflows are investigated, how findings are validated and what evidence is provided. A report label alone does not establish the work performed or guarantee protection.
Automated coverage and manual investigation serve different purposes.
Automated tools can identify known vulnerability patterns and configuration issues at scale. Their results still need validation, scope context and prioritisation. They do not by themselves establish coverage of the application's business rules or all possible attack paths.
In a manual-led engagement, the tester develops hypotheses, investigates roles and workflows, and validates permitted attack paths. Safe evidence, preconditions and limitations matter more than an inflated finding count. Testing must remain within the written authorisation.
What you should expect to receive
- An executive summary your leadership can read in five minutes.
- Each finding rated by real business risk, not just a generic score.
- Evidence: what was observed, the preconditions, safe reproduction steps and any unverified impact.
- Remediation a developer can act on.
- A defined retest scope and window, with outcomes recorded against the evidence observed.
Five things to have ready before you book one
- Scope. Which apps, APIs, networks or cloud environments are in, and which are out.
- Environment. Production or staging, and whether the data is real or seeded.
- Access. Test accounts for each user role.
- Timing. A window that will not disrupt customers.
- A point of contact. Someone who can answer questions quickly.
The point is not the report
The report should help owners prioritise and verify remediation. Share the tested scope, dates, unresolved issues and retest evidence accurately with clients or assurance teams. A point-in-time test cannot establish that no vulnerabilities remain.