Skip to content

How Long Does a Penetration Test Take?

How long a penetration test takes, from scoping to retest: durations by test type, what makes a test run long, and how to plan around an audit deadline.

Invadel TeamSeptember 4, 20269 min read

Here is the short answer: a typical penetration test runs about one week of hands-on testing, followed by reporting. Here is the more useful answer. The testing week sits in the middle of a five-phase engagement, and the calendar around it decides when the report lands. Scoping, onboarding, reporting, remediation, and the retest each take time. Deadlines are usually missed in the phases nobody planned for.

This guide covers each phase, what sets the duration for each type of test, what makes a test run long, and how to prepare.

The timeline at a glance

Phase What happens Typical timing
Scoping You describe the target; we agree the scope and a fixed price in writing A scoping call or our online questionnaire
Onboarding Kickoff, access, credentials, rules of engagement Begins within 24 hours of a signed proposal
Testing Manual testing of the agreed scope Typically starts within a week of scoping; about one week for a standard scope
Reporting Executive and technical reports, readout Follows the testing window
Retest Verification of your fixes On your schedule, once remediation is done

Larger and multi-component scopes take longer than a week, and red team engagements run for weeks rather than days. The rest of this guide explains both.

Phase 1: Scoping

Scoping sets everything that follows, including the price and the dates. A real scoping conversation asks how many applications, user roles, API endpoints, hosts, and environments are in play. It also asks which compliance framework the report must satisfy and when the test has to be finished. The output is a written scope and a fixed price, agreed before any work starts.

The fastest way through this phase is to arrive with an inventory. Our guide to scoping your first penetration test lists what to gather. A firm that quotes without asking these questions is guessing, and the guess gets corrected mid-engagement, in the calendar as well as the invoice.

Phase 2: Onboarding

Once the proposal is signed, onboarding begins within 24 hours. The engagement gets its named tester, a point of contact on your side, and its rules of engagement. Those rules cover testing windows, systems that are off limits, and how critical findings will be raised. Access gets sorted out at the same time. That means test accounts for every role, API documentation, VPN or appliance access for internal work, and WAF allowlisting.

Testing typically starts within a week of scoping. Access is the variable that moves that date. A test cannot start against an application whose credentials have not arrived, or a staging environment that is not yet standing up.

Phase 3: Testing, by type and size

For a standard scope, testing takes about one week regardless of type. What changes between types is what “standard” means and what expands it. The starting prices below apply to a standard scope. Larger scopes are quoted after scoping and take longer.

Web application

The drivers are the number of pages and features, the number of user roles, and the complexity of the workflows. Authenticated testing across roles is where the time goes, because every access-control check is repeated for each role against each function. Payment flows, file uploads, and multi-tenant designs each add work. A single application with a couple of roles fits the standard week; a platform with an admin console, a customer portal, and a partner API does not. Web application penetration testing starts at $5,200.

API

Endpoint count is the main driver, followed by the number of authentication schemes and roles. Every endpoint needs object-level and function-level authorization checks for each role. That is why a documented API tests faster than an undocumented one: an OpenAPI specification or a Postman collection at kickoff saves days of discovery. API penetration testing starts at $4,000.

External network

The drivers are the number of live hosts and the number of exposed services on them. Discovery comes first, because the real internet footprint is nearly always larger than the asset list. External testing needs the least from your team, which makes it the easiest engagement to schedule quickly. External penetration testing starts at $4,200.

Internal network

Host count, the number of Active Directory domains, and the number of network segments set the duration. A flat network with one domain is a standard scope. Multiple forests, several sites, or a segmentation test across many zones take longer. Most internal tests run through a small appliance or virtual machine inside your network, so provisioning that device is on the critical path. Internal network testing starts at $6,000.

Cloud

The number of accounts, subscriptions, or projects matters more than the size of any one of them. The range of services in use and the complexity of the identity model matter next. A cloud test usually pairs configuration review with exploitation from a low-privilege starting point, and each additional account repeats that cycle. Cloud penetration testing starts at $6,800.

Mobile

Both platforms are tested when both exist. The backend API the app talks to is usually part of the scope, because serious findings often live there. Jailbreak and root detection, certificate pinning, and offline features add reverse engineering time. Mobile application testing starts at $6,000 with both platforms included.

Red team

A red team engagement is a different shape entirely, and it runs for weeks rather than days. It models a real adversary: reconnaissance, initial access through phishing or an exposed service, persistence, lateral movement, and progress toward agreed objectives. Part of that time is deliberate pacing to test whether your detection and response function notices. Red team assessments start at $12,500.

What “larger” means

Scope grows in depth when one target has more roles, endpoints, hosts, or accounts than a standard scope. It grows in breadth when the engagement covers several components, such as a web application, its API, and the cloud environment beneath them. Both extend the testing window, and both are settled in scoping so the dates in the proposal are the dates you get.

Phase 4: Reporting

Reporting follows the testing window, and it is real work rather than an export. Each finding needs reproduction steps a developer can follow and evidence that it is real. It also needs a severity rating that will survive an auditor’s questions and remediation guidance specific to your stack. The result is two documents: an executive report for leadership and auditors, and a technical report for the people fixing things. Findings are also delivered through a findings platform, which is included, so your team can track remediation and request retests without emailing PDFs.

Our methodology page describes how we run an engagement from scoping through retest, and our sample report shows the deliverable.

Phase 5: Remediation and retest

This phase decides the total calendar, and it is mostly on your side. The test can run for a week and the report can follow promptly, but if remediation takes two months, the retest happens two months later. Plan engineering time for fixes before the test starts, not after the report arrives.

The retest verifies each remediated finding and updates the report to show it closed. It is free on every engagement, with phishing campaigns as the exception, since they produce no findings to remediate. After the retest we issue an attestation letter summarizing scope, dates, and outcome for customers and auditors who do not need the full report.

What makes a test run long

The same handful of problems account for nearly every delayed engagement:

  • Credentials that arrive late. Test accounts for every role should exist before kickoff, not on day two of testing.
  • Environments that are not ready. A staging environment that goes down, gets redeployed mid-test, or differs from production costs testing days.
  • Blocking without allowlisting. A WAF or intrusion prevention system that bans tester addresses turns an hour of testing into a day of tickets.
  • Missing documentation. An API with no specification means the tester spends the first days mapping it instead of attacking it.
  • Scope changes mid-engagement. Adding a second application on day three restarts scoping, pricing, and scheduling.

How to prepare so it does not

Most of that list is avoidable with a week of preparation:

  1. Finish the inventory before scoping: applications, roles, endpoints, hosts, cloud accounts, and environments.
  2. Create test accounts for every role in scope and confirm they log in.
  3. Stand up and freeze the test environment, or agree on production testing windows.
  4. Allowlist tester addresses on the WAF, IPS, and rate limiters, and tell the SOC the dates.
  5. Share API specifications, architecture diagrams, and prior reports at kickoff.
  6. Name one technical contact who can answer questions within the day.
  7. Reserve engineering time for remediation in the weeks after the report.

Planning around an audit deadline

A SOC 2 Type II report needs the test, the remediation, and the retest inside the observation period. PCI DSS expects testing at least annually and after significant changes. NYDFS 23 NYCRR 500 expects annual penetration testing of covered systems. Our SOC 2 evidence checklist covers what the auditor will ask for.

Work backward from the date the evidence is due. Set the retest date first, then reserve the remediation time your engineering team will need, then place the report and the testing week before that. Add the week between scoping and the start of testing, and you have the latest date to sign the proposal. Tell the testing firm the deadline during scoping. A firm that knows the date can schedule around it; a firm that learns it after testing starts cannot.

Frequently asked questions

Can a penetration test be done in a day? A vulnerability scan can run in hours. A manual penetration test of a standard scope takes about a week. The work that finds business-logic flaws, broken access control, and chained exploits is human work, and it does not compress well. Anything sold as a one-day penetration test deserves a close read.

How soon can testing start? Onboarding begins within 24 hours of a signed proposal, and testing typically starts within a week of scoping. The main dependency is access: credentials, environments, and allowlisting on your side.

Ready to put a date on the calendar? Scope your assessment and tell us the deadline. We will return a fixed price and a testing window in one proposal, and starting prices for every engagement type are on the pricing page.

Written by

Invadel Team

Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →

Find out what an attacker sees.

Tell us what to test and see your fixed price.

Prefer the full scoping questionnaire? 
Start the conversation