How Long Does a Penetration Test Take? The Stage-by-Stage Breakdown

Penetration test duration depends on what’s being tested. As a working rule, most engagements involve three to ten days of hands-on testing. The full process runs four to eight weeks from the first conversation to the finished report. Testing itself is only one stage. Understanding each stage explains why the overall number is usually bigger than people expect.

Here’s what actually happens between booking a test and receiving a report, and where the time goes.

Stage one: scoping

Before a single system gets touched, a tester needs to know what they’re allowed to test. That means IP ranges, application URLs and user roles. It also means naming any systems that are off-limits, and agreeing the testing style: black-box, grey-box or white-box. Building this document usually takes a day or two for a straightforward job. It takes longer for a multi-site organisation, or one with legacy systems nobody fully documented.

Rushing scoping is a false economy. A vague scope leads to gaps in testing. It can also lead to disputes about what was covered, or a tester spending booked days on discovery work that proper scoping would have handled up front.

Stage two: scheduling

Once scope is agreed, you need a start date that works for both sides. This step commonly adds one to three weeks to penetration test duration overall. It takes longer with in-demand providers. It also takes longer if you need testing to avoid a business-critical window, such as year-end reporting or a product launch.

Stage three: active testing

This is the part most people picture when they think about how long does a penetration test take: the tester actually attempting to find and exploit weaknesses. How many days this takes depends heavily on scope and methodology.

A black-box test starts with no inside knowledge. The tester spends real time on reconnaissance before finding a way in. A white-box test moves faster, because testers get source code or architecture documentation up front and that groundwork is already done. Grey-box testing, with partial access such as a low-privilege login, sits in between.

Rough figures by test type: external infrastructure runs one to five-plus days, depending on the size of the IP range. Internal infrastructure typically takes three to five days. A web application ranges from two days for something simple to ten or more for a large platform with many roles. A mobile app needs three to five days per platform. Wireless networks take one to two days per site. Red team exercises run two to six weeks. They simulate a sustained real-world attack rather than a fixed audit.

Stage four: reporting

Testing doesn’t end when the last exploit attempt does. Findings need documenting with evidence, risk ratings and remediation guidance a non-specialist can act on. As a rough guide, expect roughly a day of report writing for every day of testing. Most providers cap this, so a two-day test doesn’t sit waiting for a report for two weeks. A draft usually follows within a few working days of testing finishing.

Stage five: retesting

After you’ve fixed what the report flagged, a retest confirms the fixes actually work. This is quicker than the original test, typically two to five business days, because the tester checks specific findings rather than exploring the whole environment again. Many organisations schedule it thirty to ninety days after remediation. There’s no need to wait that long once fixes are genuinely done.

The National Cyber Security Centre has flagged that at some organisations, a year or more passes between tests. That leaves a long stretch where new weaknesses go unchecked. A planned retest closes that gap far sooner and gives you documented proof, not just an assumption, that the fixes held.

What a day of active testing actually involves

A “testing day” isn’t eight uninterrupted hours of a tester breaking things. Time gets split between manual investigation, running and interpreting automated tooling, chasing down false positives, and documenting evidence as findings emerge. Skilled testers write notes as they go. Trying to reconstruct a full day’s work from memory at the end of an engagement is where quality slips and reports end up late.

This is also why adding more testers doesn’t shrink a schedule in a straight line. Some tasks, like exploiting a specific vulnerability chain, need one person following a thread through to the end rather than splitting the work across a team. A provider who promises to double the speed by doubling headcount on a tightly coupled scope is usually cutting corners somewhere else instead.

Why testing methodology changes the timeline

Buyers sometimes assume a penetration test means one standard process with one standard duration. It doesn’t. A test scoped for a compliance framework, such as PCI DSS or ISO 27001, often needs to cover defined control areas rather than whatever a tester finds most interesting. That adds structure and time, but it also adds assurance value for an auditor.

Environment access matters too. If a staging environment is only reachable during UK office hours, or credentials and VPN access aren’t ready on day one, the tester loses productive hours that don’t come back later. Out-of-hours testing avoids disrupting live systems, but it usually limits how many hours a tester can work each calendar day. That stretches the schedule even though the booked day count stays the same.

Putting a number on penetration test duration overall

Add the stages together and a realistic total looks like this: one to two weeks scoping, one to three weeks scheduling, three to ten days of active testing (or more, for red team work), and a few days to two weeks reporting. A retest follows weeks or months later, once fixes land. For most SME engagements, that lands the full cycle at four to eight weeks from enquiry to final report. Larger or compliance-driven projects run longer.

If you’re working to a fixed deadline, whether that’s a client audit, a Cyber Essentials Plus renewal or an insurer’s requirement, share that date at the scoping stage. A good provider sizes the engagement to hit it realistically, rather than promising a timeline they can’t keep.

Aardwolf Security scopes UK penetration testing engagements around your actual deadline, not a generic template. If you need a realistic day count and timeline before you commit to a date, get in touch and we’ll talk it through.

Frequently asked questions

What’s the shortest a penetration test can realistically take?

A small, tightly scoped external infrastructure test can be completed in a single day of active testing. Scoping and reporting still add time around it.

Is a longer test always better?

Not necessarily. Longer penetration test duration usually means a bigger or more complex scope. It doesn’t automatically mean a more thorough test of the same systems. What matters is whether the scope and time match your actual attack surface.

Can you speed up scoping?

Yes. Have your IP ranges, application inventory and user roles documented before your first call with a provider. Incomplete information is the most common cause of scoping delays.

Does black-box testing always take longer than white-box?

Generally, yes, because reconnaissance has to start from nothing. Some organisations deliberately choose black-box testing anyway, because it mirrors what an outside attacker actually faces.

How long after remediation should a retest happen?

As soon as fixes are deployed and verified internally, rather than waiting for an arbitrary calendar date. Thirty to ninety days is common practice, but it isn’t a rule.

Does the number of testers change the total timeline?

Sometimes, but not always in proportion. Adding a second tester can shorten a broad, easily split scope. Many findings depend on one person following a single thread of investigation from start to finish, so extra headcount has limited effect on that part of penetration test duration.