Buying a penetration test is uncomfortable if you have never bought one. The deliverable is a document, the work is invisible while it happens, and the quality gap between a good engagement and a bad one is not obvious until much later. Here is what the work actually involves.
Before anything starts: scoping
Scoping decides what the test is worth. It establishes which applications and environments are in play, which user roles will be tested, when testing can run, and what is explicitly off-limits.
The most common scoping mistake is testing without credentials. An unauthenticated test only reflects what an anonymous visitor sees, which excludes most authorization flaws — and authorization flaws are where the serious findings usually live. If a proposal does not ask for test accounts covering every role, ask why.
Reconnaissance
The tester maps the application: routes, parameters, roles, third-party integrations, and the technology stack behind it. This is unglamorous and matters enormously — anything not discovered here does not get tested later.
Expect this to surface things you had forgotten: a staging subdomain, an old API version still answering, an admin panel that was supposed to be IP-restricted.
Automated baseline
Tooling runs early to clear well-known ground quickly — outdated components, missing headers, common misconfigurations. This is the part people imagine is the whole test. It is not; it is the part that frees up human hours.
A report that is obviously raw scanner output with a cover page is the clearest sign of an engagement that was not worth its fee.
Manual testing
This is the engagement. A tester works through the application by hand, in every role, looking for the things automation cannot reason about: business logic that can be subverted, authorization checks applied inconsistently, workflows that can be completed out of order.
Typical findings here include being able to view another tenant's records by changing an identifier, completing a paid action without payment, or reaching an administrative function because the check happened in the interface rather than on the server.
Exploitation and impact
A finding is confirmed by demonstrating it, then assessed for what it actually enables. This matters because severity without context is close to useless: a vulnerability on an isolated internal tool is not the same risk as the same vulnerability on your customer portal.
Good reports explain impact in business terms. 'An authenticated user can read any other customer's invoices' is actionable. 'IDOR, CVSS 7.5' is not.
Reporting, walkthrough, and retest
You should receive an executive summary, technical findings with reproduction steps and evidence, and specific remediation guidance. A walkthrough with your engineers is worth insisting on — it resolves ambiguity far faster than an email thread.
Then fix, and retest. Retesting is what converts a report into an assurance you can hand a customer. If it is not included, budget for it.
How long it takes
Most web application engagements run one to three weeks of testing, plus reporting. Anything advertised as a two-day web application test is a vulnerability scan with better marketing.