A typical penetration test takes between 5 and 15 working days, depending on the scope, test type, and complexity of the target environment. Smaller engagements like an external network scan might wrap up in 3 days. Larger projects – internal infrastructure assessments or red team exercises – can run 2 to 4 weeks or longer.
That range is wide on purpose. Every engagement is different, and the honest answer is always “it depends on what we’re testing.” But there are reliable patterns. This post breaks down what affects the timeline, what each phase looks like, and what you should expect from the moment you pick up the phone to the day you receive the final report.
Table of contents
Typical Timelines by Test Type
The figures below are typical ranges based on our experience across UK engagements. Actual durations depend on scope, and your penetration testing provider should give you a specific estimate after the scoping phase.
| Test Type | Typical Duration | Key Variables |
|---|---|---|
| Web application | 5-20 days | Number of user roles, pages, forms, and integrations |
| API testing | 3-5 days | Number of endpoints, authentication mechanisms, data sensitivity |
| External network/infrastructure | 3-5 days | Number of public IP addresses and exposed services |
| Internal network/infrastructure | 5-10 days | Network size, segmentation, Active Directory complexity |
| Mobile application (iOS + Android) | 5-10 days | Platform count, backend API complexity, local storage |
| Cloud configuration review | 3-5 days | Number of accounts/subscriptions, services in use, IaC maturity |
| Red team engagement | 2-14 weeks | Objectives, threat model, physical/social engineering scope |
| LLM engagement | 10-20 days | Number of models/agents, integration complexity (RAG, APIs, tool use), number of entry points, sensitivity of data the model can access |
A few things stand out from this table. For example, web application tests have the widest range because “web application” can mean anything from a 5-page marketing site with a contact form to a 200-endpoint SaaS platform with role-based access control across six user tiers. The test for each of those is a fundamentally different job.
Red team engagements are in a different category entirely. They simulate real attackers working toward specific objectives – gaining access to the CEO’s email, exfiltrating customer data, or moving laterally to a production database. That takes time because real attackers don’t operate on a 3-day sprint.
Phases of a Penetration Test
Understanding where time goes during a pentest helps set expectations. Testing itself is the biggest chunk, but it’s not the only part that matters.
Scoping and Pre-Engagement
Typical duration: 1-2 days of active work
Before any testing starts, the penetration testing team needs to understand what they’re testing and why. This means defining the target scope (which systems, which environments, which IP ranges), agreeing on rules of engagement, confirming testing windows, and getting the right credentials and VPN access sorted.
Scoping sounds simple but it directly affects the quality of the test. A vague scope produces vague results. When we scope an engagement at Fortbridge, we ask pointed questions: How many authenticated user roles exist? Are there third-party integrations we need to avoid? Is the staging environment a genuine replica of production, or is it three versions behind?
The calendar time for this phase is often longer than the active work. You might spend one day on a scoping call and another exchanging details over email, but the back-and-forth can stretch across a week or two depending on how quickly your team can provide access and documentation.
Active Testing
Typical duration: 60-70% of the total engagement
This is where the bulk of time goes. Active testing typically follows a pattern: reconnaissance and enumeration first, then vulnerability identification, then exploitation and proof-of-concept development. Experienced testers don’t just run automated scanners and call it done – they follow threads, chain lower-severity findings together, and test business logic that scanners can’t understand.
On a 10-day web application test, you might see 6-7 days of active testing. The first day or two focuses on mapping the application and understanding how it works. Days 3-5 are typically the most productive for finding vulnerabilities, once the tester knows the application well enough to spot where things don’t behave as expected. The final testing days are for exploiting findings, testing edge cases, and documenting proof-of-concept attacks.
Reporting
Typical duration: 1-3 days
A pentest report is the deliverable you’re paying for. It needs to be accurate, clear, and useful to both technical teams who will fix the issues and senior stakeholders who need to understand the risk.
Good reporting takes time. Each finding needs a description, impact, steps to reproduce, evidence (screenshots, HTTP request/response pairs), a risk rating, and a specific remediation recommendation. A complex engagement might produce 20-40 individual findings, each requiring careful write-up.
At Fortbridge, we build reporting into the testing process itself, documenting findings as we go rather than reconstructing everything from notes at the end. This means our testers stay focused on testing throughout the engagement, while the final report comes together efficiently without sacrificing quality. The result: a thorough, well-structured report delivered promptly after testing concludes, without cutting corners on content or QA.
The key quality signal isn’t how quickly a report is delivered, it’s what’s in it. Watch out for reports that are vague, lack reproducible steps, or read like auto-generated boilerplate. A quality report should give your team everything they need to understand, prioritize, and fix every finding.
Remediation Support and Retesting
Duration varies – typically included as a follow-up window
After you receive the report, your development team gets to work fixing the identified issues. Once remediation is complete, retesting is a valuable next step – it confirms that fixes actually work and haven’t introduced new problems.
Don’t skip retesting. We’ve seen plenty of cases where a “fix” addressed the specific proof-of-concept demonstrated but didn’t resolve the underlying vulnerability. A slightly different input, a different parameter, or a different endpoint, and the same class of bug reappears.
Retesting can be scoped and priced separately from the original engagement, which actually gives you more flexibility — you choose the timing based on when your team is ready, and you only pay for what you need. At Fortbridge, we offer retesting as a separate, dedicated engagement, ensuring the same testers who found the issues can verify the fixes with full context.
Factors That Affect Duration
The estimates above are starting points. Several factors push timelines up or down.
Number of targets. An external network test covering 10 IP addresses is a different job from one covering 500. A web application with 15 API endpoints takes less time than one with 150. This is the single biggest factor in determining test duration.
Authentication complexity. Applications with multiple user roles (admin, manager, standard user, read-only viewer, API consumer) need testing from each perspective. Privilege escalation testing between roles adds significant time, but it’s where some of the highest-severity findings live.
Compliance requirements. If the pentest supports a specific compliance framework – PCI DSS, ISO 27001, SOC 2, or a sector-specific standard – the methodology may need to cover specific control areas. PCI DSS penetration testing, for instance, has explicit requirements about what must be tested and how. This adds structure and time.
Environment access and availability. Testing against a staging environment that’s only available during UK business hours limits how much can be done per day. VPN issues, credential problems, or environments that break mid-test all eat into productive testing time. The smoother the access, the more efficient the engagement.
Retesting scope. If your engagement includes retesting, factor in the time between the initial report and the retest. Your development team needs enough time to implement fixes, and the testing team needs enough time to verify them properly.
Application complexity beyond size. Some applications are small but technically dense. A financial trading platform with 20 endpoints but complex transaction logic, race conditions, and real-time data feeds can take longer to test than a straightforward CRUD application with 100 endpoints. The tester’s time goes to understanding business logic, not just clicking through pages.
Why Rushing a Pentest Is a Bad Idea
We occasionally get requests to compress a 10-day test into 3 days because of a deadline – a contract renewal, an audit date, a product launch. We understand the pressure. But a rushed pentest is worse than it sounds.
When time is cut short, testers prioritise breadth over depth. They’ll scan more and probe less. Automated tools cover the obvious vulnerabilities – missing headers, outdated software versions, default credentials. But the findings that actually matter – the business logic flaws, the chained vulnerabilities, the authentication bypasses that require understanding how the application works – those require time to discover.
A 3-day engagement that should have been 10 days gives you a false sense of security. You get a report with a few medium-severity findings, your compliance box gets ticked, and the critical vulnerability that needed 5 days of manual testing to uncover stays right where it is.
If budget or timeline constraints are real, a better approach is to reduce scope rather than reduce depth. Test your most critical application properly rather than testing everything superficially. Your penetration testing provider should be honest with you about what can realistically be covered in the time available.
From First Contact to Final Report
Here’s what the end-to-end timeline typically looks like for a standard engagement. These are calendar-day estimates, not working days of effort.
- Initial enquiry and proposal (1-5 business days) – You contact us, we discuss your requirements, and we send a proposal with a scope of work and quote.
- Scoping and scheduling (1-2 weeks) – We finalise the scope, agree on dates, and sort out access requirements. This is often the longest wait because it depends on your team’s availability and how quickly credentials, VPN access, and environment details come through.
- Active testing (1-4 weeks depending on scope) – The testing itself. We’ll flag any critical findings immediately rather than waiting for the report.
- Reporting (1-3 business days after testing) – We deliver the full report with findings, evidence, risk ratings, and remediation guidance.
- Debrief call (typically within a week of report delivery) – We walk your team through the findings, answer questions, and discuss remediation priorities.
- Retesting (after your team completes fixes) – We verify that remediations work and issue an updated report or retest letter.
From first contact to final report delivery, a typical engagement takes 4-8 weeks of calendar time. The testing itself might be 5-10 days, but the surrounding logistics add up. If you have a hard deadline, start the conversation early. The most common cause of timeline pressure isn’t the testing – it’s the weeks spent waiting for environment access.
Get a Realistic Timeline for Your Test
Every organization’s testing needs are different. The timelines in this post are typical ranges, not fixed commitments. The right way to get an accurate estimate is to talk through your specific requirements with a testing provider who will ask the right questions.
Fortbridge is a CREST-accredited penetration testing company based in the UK. We test web applications, APIs, cloud environments, mobile apps, and internal infrastructure for organizations across sectors. If you need a penetration test and want a straight answer on how long it will take, get in touch.
Frequently Asked Questions
How long does a penetration test take on average?
Most penetration tests take between 5 and 15 working days of active testing. Smaller scopes like an external network assessment may take 3-5 days, while larger web applications or internal infrastructure tests typically require 5-10 days. Red team engagements are significantly longer, typically running 2-14 weeks depending on scope and objectives. LLM and AI security assessments generally take 10-20 days, though more complex environments involving multiple models or agentic workflows may require additional time.
Can a penetration test be done in one day?
A meaningful penetration test cannot be completed in a single day. A one-day assessment is essentially an automated vulnerability scan with minimal manual verification. It will miss business logic flaws, chained vulnerabilities, and authentication issues that require time to understand and exploit.
How far in advance should I book a penetration test?
Allow 4-6 weeks from initial enquiry to the start of testing. Most of this lead time is for scoping, scheduling, and arranging environment access rather than the testing itself. If you have a compliance deadline, start the process at least 8-10 weeks beforehand.
What takes the most time during a penetration test?
Active testing accounts for 60-70% of the total engagement time. Within that, manual testing of business logic, authentication flows, and access controls is the most time-intensive work – and also where the most significant findings tend to appear.
Does the size of the application affect how long a pentest takes?
Yes. The number of endpoints, user roles, and integrations directly affects test duration. A web application with 10 pages and one user role is a different job from one with 200 endpoints, six user roles, and API integrations. Complexity matters more than raw size – a small application with complex transaction logic can take longer than a large but straightforward one.
About Post Author
