How Long a Penetration Test Takes, and Why Estimates Vary So Much

The honest answer to "how long does a penetration test take" is that the testing is the short part. A five-day test is rarely five days end to end, and the difference between the two numbers is where most of the frustration in this industry lives.

The two clocks

There is effort, measured in tester days, and there is elapsed time, measured from the first call to the report landing. A typical external web application engagement is three to ten days of effort and three to six weeks of elapsed time, and buyers who plan around the first number are the ones who end up chasing.

Elapsed time is made of scheduling, access, testing, writing, review and delivery. Only one of those is testing.

What drives the testing days

• Roles. Every additional user role multiplies the authorisation work, because each pair of roles is a boundary somebody has to attempt to cross. One role is a fraction of the work of four.
• Whether it writes. A read-only reporting tool is quicker than something that moves money, provisions access or calls another system on your behalf.
• Bespoke versus framework. A familiar authentication library is understood in an hour. A hand-rolled session mechanism is where the days go, and usually where the findings are too.
• Surface area. Not page count. Distinct functions: an application with forty pages and six real workflows is smaller than it looks.
• Integrations. Every external system reached is a boundary, and boundaries are where two teams assumed different things.

Reporting is not an afterthought

A good report typically costs somewhere between a fifth and a third of the testing effort, and a firm quoting no reporting days is either absorbing it, skimping on it, or handing you tool output. Ask which.

The writing is slower than people expect because the useful parts are slow: reproduction steps a developer can follow without calling you, impact described in terms of your system rather than the vulnerability class, and remediation that names the change. Every one of those takes longer than pasting a description from a database.

Where the calendar time actually goes

1. Scheduling. Good testers are booked weeks ahead. Two to six weeks from agreeing the work to the start date is normal, and shorter usually means somebody dropped out.
2. Access. The most common overrun in this business, and it is almost always the client side. Accounts that were promised for Monday, multi-factor going to somebody who is on leave, an allowlist request sitting in a queue.
3. Testing. The days you paid for.
4. Writing. Usually starts during testing and finishes after.
5. Review. A second tester checking the findings and the ratings. A day, and worth it.
6. Delivery and debrief. Sending it, then an hour explaining it to the people who have to act.
7. Retest. Weeks or months later, once you have fixed things. Usually a day or two.

Multi-week engagements behave differently

Past about ten days the arithmetic changes, because a test that runs across three weeks is not one long test. Testers rotate, findings accumulate before any of them are written up, and the client-side contact changes at least once.

Ask how a long engagement is structured. Good answers involve checkpoints: a short call at the end of each week saying what has been covered and what is next, and criticals reported as they are found rather than accumulated. Bad answers involve silence until a report arrives, by which time a finding from week one has been sitting undisclosed for a fortnight.

Long engagements are also where handovers happen, planned or otherwise. Ask what happens if the assigned tester is unavailable mid-engagement, because the honest answer involves a second person reading up, and you want to know whether that time comes out of your days or theirs.

How to compress it honestly

You cannot buy back testing days without buying less testing, but you can remove almost all of the waste.

• Have accounts working and tested from outside your network the week before, not the morning of.
• Supply documentation up front. Grey box testing finds more per day than black box because the days go on testing rather than reconnaissance.
• Name one contact who is present for the whole window and not on leave.
• Agree the report format before the test rather than iterating on it afterwards.
• Book the debrief when you book the test, or it slips by a fortnight.

When somebody promises it fast

A firm offering to start next week and deliver in three days may simply have a gap in the calendar, which happens. It may also be quoting for a scan with a cover page, and the way to tell is to ask how many of those days are manual testing and what will be done in them.

Speed at the reporting end is more suspicious than speed at the testing end. A report the same evening as the last test day generally means it was written from tool output, because the parts that take time are the parts a person has to think about.