How Long Does a Penetration Test Take?

For a single web application and its API, the hands-on testing window in the engagements we scope is usually five to ten working days, and the whole engagement from signed scope to final report usually runs four to eight weeks. We sell penetration testing, so those are our numbers about our own work rather than a market survey, and you should ask any firm you are evaluating for theirs in writing. The contrarian part is that the testing days are simultaneously the part of the calendar you cannot compress and the part that matters least to your date. NIST SP 800-115, which remains NIST's operative technical testing guide despite its September 2008 publication date, describes a four-stage methodology in Figure 5-1: Planning, Discovery, Attack and Reporting. Of the planning stage it says, flatly, "No actual testing occurs in this phase." That phase, and the retest at the far end, are where your weeks go.

Below: what each stage really consumes, the two stages with no testing in them, why a testing window is a window rather than a schedule, the remediation and retest loop that most plans omit entirely, and what a deadline actually buys you.

Key takeaways

• Testing days and engagement weeks are different numbers. Confusing them is why "the test takes a week" turns into a missed audit date.
• NIST SP 800-115 puts planning first and states that no testing happens in it. Scoping, authorization and rules of engagement are calendar, not overhead.
• Reporting is not a stage that starts when testing ends. NIST describes it as running simultaneously with the other three, which is why a firm that cannot show you a sample report structure is a scheduling risk as well as a quality risk.
• The attack stage loops back to discovery by design, so the testing window is bounded by agreement rather than by the work being finished. That is a feature, and it is why scope discipline is a date decision.
• The retest is the stage that most often lands after the deadline, because it depends on your engineering team, not on the testing firm.

The four stages, and what each one really consumes

NIST SP 800-115 section 5.2.1 lays out the methodology, and it maps onto a calendar more usefully than any vendor Gantt chart.

Planning. Rules are identified, management approval is finalized and documented, and testing goals are set. NIST's own summary is that this phase "sets the groundwork for a successful penetration test" and that no actual testing occurs in it. In practice this is where scoping conversations, the statement of work, target and exclusion lists, credentials for authenticated testing, and third-party authorization all happen. If your application runs on infrastructure you do not own, NIST notes that the owner of that network usually has to consent in writing too, and that consent has its own queue.

Discovery. NIST splits it in two: information gathering and scanning, then vulnerability analysis comparing what was found against vulnerability databases and the testers' own knowledge. It notes that manual processes "can identify new or obscure vulnerabilities that automated scanners may miss, but are much slower than an automated scanner". That sentence is the whole argument about why a credible test is not a scan with a cover page, and penetration testing versus vulnerability scanning covers the distinction properly.

Attack. Verifying the candidate vulnerabilities by attempting to exploit them. This is the stage buyers picture when they picture a penetration test, and it is a minority of the elapsed time.

Reporting. Here is the detail that changes how you should read a schedule. NIST says the reporting phase "occurs simultaneously with the other three phases of the penetration test", with written logs kept and periodic reports made during discovery and attack, and a report developed at the conclusion. A firm whose report only begins the day testing ends has added a stage that NIST does not have.

The two stages with no testing in them

Two things reliably consume more calendar than clients expect, and neither involves a tester touching a system.

Getting to a signed scope. A scope conversation that is doing its job is slow, because it is deciding what the test is for. Which application, which environment, authenticated or unauthenticated, production or staging, whose infrastructure, which hours, who gets called if something breaks. Every one of those is a question the testing firm cannot answer alone. Our guide to choosing a testing firm lists what to put in writing, and each item on that list is also a day or two of calendar.

Scheduling. Testing firms schedule senior people, and senior people are booked. This is the single most common reason a company that "needs a pentest" in March discovers that its report will arrive in May. It is also the most preventable, because it costs nothing to ask a firm for its next available window before you need it.

There is a related trap on the compliance side. If the test is evidence for an audit, the report has to be dated inside the audit period, not merely delivered before the audit. A report dated three days after your observation window closes is evidence for next year.

Why the testing window is a window and not a schedule

NIST's Figure 5-2 shows the attack phase looping back to discovery: gain access, escalate privileges, browse the system, install additional tools, and then feed newly discovered information back into the discovery phase. NIST describes penetration testing as "an iterative process that leverages minimal access to gain greater access".

The scheduling consequence is that the work does not have a natural end. It has a boundary you agree to in advance. A ten-day window means ten days of that loop, and a five-day window means five, and the difference is not that one finds everything and the other does not; it is how deep the loop gets to run. This is why scope is a date decision as much as a cost decision, and it is why a firm that quotes a fixed number of days without asking about your architecture is quoting a slot rather than a test.

NIST adds a sequencing note worth knowing when you plan a combined engagement: "If both internal and external testing is to be performed, the external testing usually occurs first." Plan the internal access, VPN credentials or on-site arrangements to be ready before the external half finishes, or you buy a gap between the two.

The stage that lands after the deadline

Almost every timeline we are shown by a client stops at report delivery. Almost every real project has two more stages after it.

Remediation is yours. It is bounded by your engineering team's sprint cadence and by how many of the findings turn out to be architectural rather than local. Nobody, including us, can tell you how long this takes before the findings exist.

The retest verifies the fixes, and it is a contractual variable more than a technical one. Whether one retest round is included, how long the window runs after final delivery, and whether the retest covers only the fixed findings or the full original scope are three separate questions with three separate answers, and is a cheap pentest worth it treats them as pre-signature questions for good reason.

If you are doing this for PCI DSS, the retest is not optional. The 11.4.x family requires verification of fixes by retesting under 11.4.4, alongside the testing cadence in 11.4.2 and 11.4.3; how often to run a penetration test walks the whole family, including the tighter segmentation testing intervals that catch service providers.

So the honest end-to-end number for a compliance-driven test is not four to eight weeks. It is four to eight weeks, plus your remediation, plus a retest window, and the audit date has to sit after all three.

What a deadline actually buys you, and what it does not

A deadline can buy you a faster start. Firms hold capacity, and asking early is free.

A deadline cannot buy you a deeper loop. Compressing the testing window compresses the discovery-to-attack iterations, which is where the findings that matter tend to come from. NIST is explicit that penetration testing "is labor-intensive and requires great expertise", and labor-intensive work does not parallelize the way clients hope.

A deadline also cannot compress your own remediation, which is the part of the calendar most likely to move. If the deadline is an audit date, the sequencing that works is to test early enough that remediation and retest both fit before the period closes, rather than to test as late as possible so the report looks current.

The honest caveat, which argues against buying from us

Two cases where the right answer to "how long does it take" is that you should not be booking one yet.

If you have never run a vulnerability scan and closed what it found, a penetration test will spend its first days rediscovering things a scanner would have handed you in an hour, and you will pay senior-tester rates for it. Scan first, fix what it finds, then test. The report is better and the engagement is shorter.

If the only reason for the test is a checkbox on a questionnaire and nobody intends to fix the findings, the calendar question is moot, because the engagement has no output you will act on. Penetration testing beyond checkbox compliance makes that argument at length, and it is the argument that has cost us the most work.

And if what you actually want is continuous coverage rather than a point-in-time report, the timeline question changes shape entirely; what platform-delivered testing is covers that model and where it does and does not substitute.

Where Top Floor fits

Our penetration testing engagements state the testing window, the manual-to-automated balance, the named testers and the retest terms in the statement of work, because all four are scheduling facts as well as quality facts. Where the test exists to support an attestation, we sequence it against the audit period rather than against the invoice date, which matters for SOC 2 evidence and matters more for PCI DSS, where the retest requirement is written into the standard.

For what an engagement costs rather than how long it takes, our penetration testing cost breakdown carries the published ranges and the sourcing behind them. This article deliberately states no price.

How to decide this week

Ask three questions and you will have a real date.

First, what is the date the report has to exist by, and is that an audit period close, a customer deadline, or a preference? Only the first two are constraints, and only the first has a hard edge you cannot negotiate.

Second, ask your shortlisted firms for their next available testing window, not their turnaround time. Availability is the variable that actually moves your date, and it is the one nobody volunteers.

Third, ask each firm to write down, in the statement of work, the length of the testing window, when the draft report arrives, how long you have to comment, and whether a retest is included and for how long after final delivery. Add those four numbers together. That total, plus your own remediation, is your real timeline, and it is usually two to three times the number in the sales conversation.

Frequently asked questions

How many days of testing does a web application need?

For a single web application plus its API, the hands-on window we typically scope is five to ten working days, and larger or more complex scopes run longer. Treat any quote given without a scoping conversation as a slot rather than an estimate: NIST SP 800-115 describes the attack phase as looping back into discovery, so the depth achieved depends on how many iterations the agreed window allows, which cannot be known without knowing the architecture.

Why does the whole engagement take weeks when the testing takes days?

Because testing is one of four stages. NIST SP 800-115 puts planning first and states that no actual testing occurs in it, and that stage covers scoping, authorization, rules of engagement, credentials and any third-party consent. Reporting, in NIST's model, runs simultaneously with the other stages rather than after them, but final report production, your review, and scheduling availability at the firm all sit on the calendar too.

Does the retest count as part of the timeline?

Yes, and it is the stage most often left out of the plan. Remediation is bounded by your engineering cadence rather than by the testing firm, and the retest window is a contractual term that varies. For PCI DSS the retest is mandatory: requirement 11.4.4 covers verification of fixes by retesting. If an audit or customer deadline is driving the work, the deadline has to sit after remediation and retest, not after report delivery.

Can a penetration test be done in a week if we have a deadline?

Sometimes, and it changes what you get rather than only when you get it. A shorter window means fewer iterations of the discovery-to-attack loop that NIST describes, which is where the non-obvious findings come from. If the deadline is real, the better lever is usually a narrower, well-defended scope tested properly than the full scope tested shallowly, and the honest version of that trade should appear in the statement of work rather than in a conversation nobody wrote down.