What a Real Penetration Test Should Include

Buyers often ask for a pentest, but not every assessment answers the same question. Some engagements produce a spreadsheet of findings. Stronger engagements explain how an attacker could actually move from a low-trust entry point to meaningful impact.

If the output will be used for launch decisions, buyer diligence, or remediation planning, the assessment needs to go beyond automated checks and validate real exploitability.

• Scoping that identifies environments, privileged workflows, and business-critical paths
• Attack-surface mapping that covers hidden routes, internal features, and adjacent trust boundaries
• Manual testing of authentication, authorization, workflow abuse, and exploit chains
• Validation of impact so findings reflect actual exposure rather than theoretical concern
• Reporting that gives leadership a clear summary and engineers enough technical detail to fix issues
• Retesting support so the engagement ends with verified closure rather than open questions

Automated tooling is useful for coverage, triage, and validation. It is not enough on its own. The issues that create the most business pain are often tied to workflow assumptions, tenant boundaries, hidden admin capability, or how multiple low-severity weaknesses combine.

• Business logic abuse in approvals, checkout, billing, or onboarding flows
• Authorization failures that only appear when roles or object references are manipulated manually
• Multi-step attack chains where each individual weakness looks minor in isolation
• Unsafe trust between the frontend, API, background jobs, and internal services

• Executive summary of the most important risk themes
• Risk-ranked findings with reproduction detail
• Proof-of-concept material such as requests, screenshots, or exploit notes
• Business impact framed in customer, operational, and compliance terms
• Clear remediation guidance and retest status

1. Who performs the testing and how much of it is manual?
2. How do you validate business logic and exploit chains?
3. What do deliverables look like for leadership and engineering?
4. What happens after the report is delivered?
5. Is retesting included or available?

If the answers sound generic, the engagement probably will be too. A serious pentest should leave your team with a clearer picture of risk and a realistic path to reducing it.