"How long will it take?" is usually the second question a buyer asks, right after "how much?". The honest answer has two parts: the number of tester-days of hands-on work, and the calendar time around it for planning, reporting and retesting. Both matter when you are working to an audit date or a product launch.
Tester-days versus calendar days
Providers price and plan in tester-days: one tester working one day. Ten tester-days might be one person for two weeks or two people for one week. The calendar time you see depends on how the work is staffed.
Adding testers shortens the calendar, but not in a straight line. Some work splits cleanly, such as testing a web front end and a mobile client in parallel. Other work does not. Chaining a low-risk information leak into an account takeover needs one person who has seen the whole system. A good provider will tell you which parts can run in parallel and which cannot.
Typical effort by test type
The ranges below assume a gray box approach and a moderately complex target. Simple targets sit at the lower end; large or unusual ones sit above it.
| Test type | Typical tester-days | What pushes it up |
|---|---|---|
| Web application | 5–12 | Many roles, complex workflows, multi-tenant data |
| API | 3–10 | Large operation count, several auth schemes, no specification |
| Mobile app (per platform) | 4–8 | Custom crypto, offline storage, heavy native code |
| External network | 2–5 | Many live hosts, VPN and remote access portals |
| Internal network | 5–15 | Several sites, flat networks, large domains |
| Cloud | 5–15 | Many accounts or subscriptions, mixed providers |
| Active Directory | 4–10 | Multiple forests, trusts, hybrid identity |
| Red team | 15–40+ | Longer objectives, stealth requirements, social engineering |
These are planning ranges, not promises. A proper estimate comes from a scoping conversation; our scoping guide lists the details providers need.
The full timeline, start to finish
From the first email to a clean retest, a typical engagement passes through six stages.
- Scoping and proposal. A call or questionnaire, then a written proposal. Usually a few days, longer if several stakeholders must sign off.
- Contract and authorization. NDA if needed, statement of work, and written permission to test. Speed depends on your procurement process.
- Scheduling and preparation. Booking testers, creating accounts, allow-listing source IPs. Commonly one to two weeks of lead time.
- Testing. The hands-on work. Critical issues are reported as soon as they are confirmed, not held for the report.
- Reporting and review. Write-up, evidence, severity rating and peer review. Usually three to five business days after testing ends.
- Remediation and retest. Your team fixes; testers verify. The retest itself is often one or two days.
What slows engagements down
Most overruns have nothing to do with the testing. They come from preparation that was not finished in time.
- Broken or missing accounts. Testers cannot assess role separation without working logins for each role.
- Blocked source addresses. A web application firewall that silently drops tester traffic wastes days before anyone notices.
- Unstable test environments. Staging systems that go down or get redeployed mid-test interrupt progress.
- Slow answers. If a question about a feature waits three days for a reply, those three days are lost.
- Scope creep. New targets added during testing either stretch the timeline or dilute coverage.
How to shorten the calendar
If you are up against a deadline, these steps help most:
Lock scope early
Agree targets and knowledge level in the first conversation. Every week spent going back and forth on scope comes straight out of your buffer.
Prepare access in advance
Have accounts, API keys and VPN credentials tested and ready before the start date. Run a short pre-test check call to confirm everything works.
Split by component
Where components are independent, run them in parallel with separate testers. Web and mobile clients, or separate cloud accounts, often split well.
Use interim updates
Ask for a daily or mid-point summary of confirmed issues. Your engineers can start fixing before the final report arrives, which pulls the retest forward.
An illustrative timeline
For a single web application with an API behind it, a realiztic plan might look like this. Week one: scoping call and proposal. Week two: contract, authorization and access set-up. Weeks three and four: around eight tester-days of testing, with critical issues flagged as they appear. Week five: report delivered and debrief held. Weeks six and seven: fixes deployed. Week eight: retest and updated report. Every stage can compress if your side is ready, but this is a comfortable default.
Is a longer test always better?
No. Beyond a certain point, extra days on the same target yield fewer new findings. The useful question is whether the effort matches the attack surface. A short test of a complex multi-tenant platform will miss things. A long test of a five-page marketing site is wasted money.
For systems that change frequently, a series of shorter tests often beats one long annual engagement. Our guide on how often to pentest covers cadence, and continuous pentesting spreads effort across the year.
Planning around an audit or launch
Deadlines rarely move, so build slack into the plan rather than hoping each stage runs to its shortest time.
Work backwards from the date you need a clean report. Allow time for scheduling, testing, reporting, fixing and retesting. For a single application, six to eight weeks from first contact to retest is a comfortable plan; four weeks is achievable if access is ready and fixes are quick. If the deadline is tight, tell providers at the first conversation; it affects which testers they assign and when. Read the remediation and retesting guide to plan the second half of that window.
Frequently asked questions
Can a pentest be done in a single day?
A very small target, such as a brochure website or a handful of external IPs, can be covered in a day or two. Anything with logins, roles or business logic needs more time to test properly.
Why is there a gap between testing and the report?
Findings need to be validated, rated, written up with evidence and reviewed by a second tester. That quality step usually takes a few business days after the last day of testing.
Does running more testers in parallel shorten the test?
Up to a point. Splitting a large scope across testers shortens the calendar, but some tasks, such as chaining findings, need one person with the full picture.
Working to a deadline? Estimate effort with the pentest cost calculator or request a quote with your target date and we will propose a schedule.