How Long Does a Penetration Test Take? (2026) Timelines by Scope, From Scoping to Retest

Quick answer: Active testing on a single web application runs 2 to 20 days across published vendor scoping pages, with the tighter published bands sitting at 3 to 5 days (Precursor Security) and 5 to 20 days (Fortbridge). An external network test is 1 to 5 days, an internal network test 1 to 10 days, a mobile application 3 to 10 days, an API 3 to 9 days, and a cloud configuration review 3 to 5 days. Red team work is published in weeks: 2 to 14 weeks. Those figures cover active testing only. The full engagement, from first enquiry to delivered report, is published at 4 to 8 weeks of calendar time by both Fortbridge and Zensec, because scoping, scheduling, reporting and retesting all sit outside the testing days you are quoted.

Every duration on this page was read from a vendor scoping, pricing or methodology page on 5 September 2026 and links back to it. Ranges are labelled "typical, from vendor scoping pages" throughout, because they are published planning estimates rather than measured outcomes, and different publishers disagree by wide margins on the same engagement type.

Why the answer is a range, and why publishers disagree

A penetration test is not a fixed-length product. It is a number of tester days pointed at a scope, and the scope is set before anybody starts. That makes "how long does it take" a question with two honest answers that people constantly confuse.

The first answer is testing days, the count of days a tester is actively working your scope. This is the number in a statement of work, and it is the number that drives the price. It is also the smallest of the numbers on this page.

The second answer is calendar time, the elapsed period from the moment you decide to buy to the moment a report lands. It includes scoping calls, contracting, the queue in front of your booking, testing, report writing, quality review, and a retest after your fixes. It is typically four to eight times the testing figure, and it is the one that determines whether you make an audit date.

Publishers disagree because they scope differently and because they publish different things. One firm publishes 3 to 5 days for a web application and another publishes 6 to 12 days for the same phrase. Neither is wrong. The first is describing an unauthenticated or lightly authenticated application; the second is describing a multi-role platform with an authenticated surface behind it. Whenever two published ranges for the same engagement type diverge by a factor of two or more, the divergence is almost always about authentication depth and role count, not about pace.

The published numbers at a glance

• Web application, active testing: 3 to 5 days (Precursor Security), 5 to 20 days (Fortbridge), 6 to 12 days (EJN Labs), and 2 to 3 days for a simple site rising to 10 days or more for a large or complex application (Zensec).

• External network, active testing: 3 to 5 days (Precursor Security, Fortbridge and EJN Labs all publish this band), and 1 to 3 days for a small organisation rising to 4 or 5 days and more for a larger estate (Zensec).

• Internal network, active testing: 1 to 3 days for an estate of about 150 hosts (EJN Labs), 3 to 5 days for a mid-sized organisation (Zensec), 5 to 8 days for a larger estate (Precursor Security), and 5 to 10 days (Fortbridge).

• Mobile application, active testing: 3 to 5 days (Zensec) and 5 to 10 days for iOS and Android together (Fortbridge and EJN Labs).

• API, active testing: 3 to 5 days (Fortbridge) and 4 to 9 days (EJN Labs).

• Cloud configuration review, active testing: 3 to 5 days (Fortbridge) and 4 to 5 days for a single platform (EJN Labs).

• AI or LLM engagement, active testing: 5 to 7 days (EJN Labs) and 10 to 20 days (Fortbridge). This is the widest disagreement between two publishers anywhere on this page.

• Red team, active testing: 2 to 3 weeks for a focused engagement (EJN Labs), 2 to 6 weeks and sometimes longer (Zensec), and 2 to 14 weeks (Fortbridge).

• Published fixed assessment windows: 4 to 5 days, 5 days, and 14 or 365 days, attached to three named packages (Synack).

• Published booking lead time: engagements begin 2 to 4 weeks after a quote is accepted (Precursor Security), and a pentest can start in 3, 2 or 1 business days depending on contract tier (Cobalt).

• Published reporting turnaround: 1 to 3 days after testing ends (Fortbridge), roughly one day of reporting for every day of testing with a draft within a few days (Zensec), findings in 24 hours on an autonomous test (Cobalt), and a same-day audit-ready report (Intruder).

• Published end-to-end calendar time: 4 to 8 weeks from first enquiry to delivered report (Fortbridge and Zensec publish the same band independently).

• Measured remediation time: median 10.5 days to fix a Critical and 38.0 days to fix a High, across 1,206 verified findings from 55 penetration tests (Stingrai State of Penetration Testing 2026).

Key takeaways

• Testing days are the smallest number in the project. Across every engagement type published here, active testing is 1 to 20 days. The end-to-end calendar figure published by two independent firms is 4 to 8 weeks. If you plan against the testing days you were quoted, you will be roughly a month short.

• Booking lead time is the phase that misses deadlines, and it is rarely on the quote. Precursor Security publishes that engagements begin 2 to 4 weeks after quote acceptance. That is a queue, not work, and it happens before a single day of your testing budget is spent. Ask for the start date in writing at quote stage, not at kick-off.

• Reporting is not a rounding error on longer engagements. Two conventions are published and they diverge sharply with scope. A flat 1 to 3 days is fine for a 3-day external test. Zensec's convention of roughly one reporting day per testing day means a 12-day web application test carries about 12 days of reporting behind it. On a long engagement, ask which convention the vendor uses before you commit to a delivery date.

• The widest published disagreement in this whole dataset is on AI and LLM testing. One publisher says 5 to 7 days, another says 10 to 20. That is a factor of three on the same nominal scope, and it is honest evidence that the category has not settled on what a complete AI engagement covers. Get the test plan in writing for this scope specifically.

• Remediation is longer than everything before it and nobody schedules it. A median Critical takes 10.5 days to fix and a median High takes 38.0 days in the Stingrai dataset. A programme that books the test but not the fix window and the retest has bought a report on a deadline rather than a security outcome on one.

Methodology

The verification pass for this page closed on 5 September 2026. Every duration printed here was read directly from a page the publisher controls, on that date, in the unit the publisher used.

What counted as a published timeline. A day count, week count or turnaround stated on a vendor's own scoping, pricing or methodology page, on a public URL with no login. Durations quoted by review sites, procurement marketplaces or aggregator "average pentest length" articles were excluded, because they carry no scope definition and no publisher accountable for the estimate.

These are estimates, and they are labelled as such. Every range in the tables below is typical, from vendor scoping pages. Vendors publish these figures to help a buyer plan and to set expectations at quote stage. They are not measurements of completed engagements, and no publisher on this page claims otherwise. Where two publishers disagree, both figures are printed and the disagreement is named rather than averaged away.

Ranges are not merged. Where three firms publish 3 to 5 days for an external network test, that agreement is reported as agreement. Where one firm publishes 5 to 7 days for an AI engagement and another publishes 10 to 20, both appear separately and no midpoint is invented. Nothing on this page is interpolated, averaged across sources, or modelled.

The one measured dataset is labelled separately. The remediation figures come from Stingrai's own analysis of 1,206 verified findings across 55 penetration tests, which is measured outcome data rather than a planning estimate, and it is used only for the remediation phase.

What was dropped. Several widely circulated "a pentest takes 1 to 3 weeks" figures trace to content marketing pages with no scope definition attached, and none of them are printed here. A framework document publishing red team phase durations could not be extracted in readable form during the pass, so no framework-published red team phase breakdown appears on this page, only the three vendor ranges. Where a publisher gave a duration without saying whether it covered testing days or calendar days, the figure was dropped rather than assigned to a phase by guesswork.

The five phases, and what each one costs in calendar time

An engagement has five phases before remediation even starts. Only one of them is the number you were quoted.

Scoping

Scoping is short in effort and long in elapsed time, which is why it is consistently underestimated. Fortbridge publishes 1 to 2 days of active work stretched across 1 to 2 weeks of calendar time, and Zensec publishes "a day or two" for straightforward engagements with longer for complex multi-site assessments.

The elapsed time is almost never the tester's. It is yours: assembling an asset inventory, getting test accounts provisioned across every role, confirming which environments are in scope, getting legal to sign an authorisation, and finding out that the third-party payment integration needs its own written permission. Every one of those items sits with your team.

The single largest scoping accelerant is having role-based test credentials ready before the scoping call rather than after it. Authenticated testing is where authorisation and business logic findings come from, and an engagement that starts with credentials still in flight loses testing days to waiting rather than testing.

Booking lead time

This is the phase nobody quotes and everybody feels. Precursor Security publishes plainly that engagements begin within 2 to 4 weeks of quote acceptance. Cobalt publishes start times of 3 business days on Standard, 2 on Premium and 1 on Enterprise, with a note that start times may vary by engagement type, which is the clearest published evidence that a faster start is a contract term you buy rather than a property of testing.

If you have a hard external date, an audit fieldwork window, a customer security review or a funding diligence deadline, this is the phase to negotiate. It is also the phase where continuous testing programmes differ structurally from one-off engagements: on a running programme the queue was cleared at contract signature, not per test.

Active testing

This is the phase the quote describes, and the tables below break it out by engagement type. Fortbridge publishes that active testing accounts for 60% to 70% of total engagement time, which is a useful sanity check: if a vendor's proposed schedule has testing at 20% of the calendar, the rest of the schedule is queue and paperwork, and you should ask which.

Reporting

Two conventions are published and they produce very different answers on longer engagements.

Fortbridge publishes a flat 1 to 3 days after testing. Zensec publishes "roughly one day for every day of testing", with a draft report within a few days of testing completion. On a 3-day external network test those two conventions agree almost exactly. On a 12-day web application test, one implies three days and the other implies about twelve.

Neither convention is dishonest. They describe different report products. A short turnaround usually reflects a structured, platform-generated report with findings written as they are confirmed. A day-per-day convention usually reflects a hand-written narrative report with an executive section, attack-path walkthroughs and evidence appendices. Ask which one you are buying, because an auditor and a board want different documents.

Two vendors publish the compressed end of this: Cobalt publishes findings in 24 hours on its Autonomous Pentest, and Intruder publishes a same-day audit-ready report usable as evidence for ISO 27001 and SOC 2.

Retest

The retest is the phase most often left out of a timeline entirely, and it is the phase that decides whether the engagement produced a security outcome or a document.

Precursor Security publishes that retesting within the assessment window is included and that additional retesting beyond the window is scoped by the number of retests required. That is the structure to look for: a defined window inside which verification is free, and a published rule for what happens outside it. A retest scheduled after your remediation window has closed is a second procurement cycle, and it will carry its own booking lead time.

Published testing days by engagement type

Every row is testing days only. Add scoping, booking lead time, reporting and retest around it. All figures are typical, from vendor scoping pages, read 5 September 2026.

Fixed assessment windows, published as a product

A separate convention exists in the subscription tier of this market, where the testing window is a fixed published property of the package rather than an output of scoping.

Notice what those windows do to the comparison. A 4 to 5 day window for one low complexity web application lines up almost exactly with the 3 to 5 day band that Precursor Security publishes for the same scope from a completely different pricing model. Where two unrelated commercial structures converge on the same duration for the same scope, the duration is probably real.

Cobalt takes a third approach and publishes the unit rather than the window: one credit is defined as the equivalent of eight hours of offensive security testing, which makes the credit count on a quote directly translatable into tester days.

What stretches a timeline, and what shortens it

These are the variables that move a quoted day count in either direction. They apply across every engagement type in the tables above.

What stretches it

• Authentication depth and role count. This is the single biggest driver, and it explains almost every disagreement between publishers on this page. An unauthenticated web application is a surface. An application with four roles, an admin console, tenant separation and an approval workflow is four surfaces plus the authorisation logic between them.

• Scope discovered mid-test. An asset inventory that was wrong is a schedule change, not a testing problem. Undeclared subdomains, an API gateway nobody mentioned and a legacy admin host are the three most common.

• Environment instability. Testing against an environment that is being deployed to, or one that rate-limits or blocks the tester's traffic, converts testing days into waiting days.

• Credentials arriving late. Every day the tester spends without working accounts for every role is a day spent on the unauthenticated surface you cared about least.

• Compliance-driven methodology requirements. A test that must evidence a specific control set carries mandatory coverage and mandatory documentation. That is structure worth having, and it costs time.

• Third-party authorisation. Cloud providers, payment processors and hosting partners can each require their own written permission, and each of those is a calendar item with an external owner.

What shortens it

• A complete asset inventory delivered at scoping. Every hostname, every API, every environment, with owners named.

• Role-based test accounts provisioned before kick-off. Provisioned, tested and confirmed working, not promised.

• A stable, production-like test environment that is not being deployed to during the window.

• A named technical contact who can answer within the working day. Testing blocked on a question is the cheapest avoidable delay in the whole engagement.

• A contracted programme rather than a one-off purchase. Cobalt's published 1 to 3 business day start times are contract tiers. A running programme has already paid the queue cost.

• A narrower authenticated scope, deliberately chosen. Testing two roles properly beats testing five roles shallowly, and it is a legitimate way to fit a real test into a real window.

Calendar time: the number to actually plan against

Two firms publish an end-to-end figure independently and they agree: 4 to 8 weeks from first enquiry to delivered report, per both Fortbridge and Zensec.

Set that against a typical published testing figure of 3 to 5 days and the ratio is stark. On a 5-day web application test, roughly one week of the eight is testing. The other seven are scoping, contracting, queue, reporting and verification.

Two worked plans, built only from published figures:

A 5-day external network test, planned backwards from an audit date. Scoping and contracting, 1 to 2 weeks. Booking lead time, 2 to 4 weeks. Testing, 3 to 5 days. Reporting, 1 to 3 days on the flat convention. That lands at roughly 4 to 7 weeks before the report exists, and the retest sits after your remediation window on top of that. To have a report in hand for fieldwork, start the conversation about two months out.

A 12-day web application test on a multi-role platform. Scoping, 1 to 2 weeks, longer if credentials are not ready. Booking, 2 to 4 weeks. Testing, 6 to 12 days. Reporting, up to about 12 days on the day-per-day convention. That is roughly 7 to 10 weeks to a delivered report, before remediation and retest.

The practical rule that falls out: take the testing days you were quoted, and plan the project at six to eight times that figure in calendar time. Then add the remediation window below.

Remediation: the phase that outlasts the test

Everything above ends when a report is delivered. The security outcome does not arrive until the findings are closed and verified, and that phase is longer than all the others combined.

Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests, with a 0.74% false-positive rate, and 92.7% of those tests surfaced at least one High or Critical finding. Across findings with a tracked resolution time, the median Critical took 10.5 days to fix and the median High took 38.0 days.

Those are measured medians, not estimates, and they reframe the whole schedule. A 5-day test that surfaces a High, which 92.7% of tests in that dataset did at some severity, has a median 38-day tail attached to it before a retest can honestly pass. Add the retest itself and its own scheduling, and the gap between "the test started" and "the finding is verifiably closed" is routinely three to four months.

Three consequences worth planning around.

First, the remediation window belongs in the project plan at scoping, with engineering capacity reserved. A finding that waits for the next sprint planning cycle has already spent two weeks of its median.

Second, the retest window must be long enough to contain the remediation median. A vendor who includes retesting inside a 30-day assessment window has covered the median Critical comfortably and has not covered the median High at all. Read the window length against the 38-day figure before you sign.

Third, the false-positive rate is a schedule input, not just a quality metric. Every false positive consumes engineering triage time inside the same window as the real findings. A 0.74% rate means roughly one report in the dataset's typical finding count carries no wasted triage at all; a noisier report spends your remediation window arguing about validity.

For a scope-by-scope view of what drives the price of those days, see the 2026 penetration testing cost guide and the day rate and cost per hour analysis. For how often the cycle should repeat, see how often you should run a penetration test.

Autonomous testing against hybrid timelines, stated honestly

Autonomous testing genuinely compresses part of this timeline. It is worth being precise about which part, because the marketing in this category routinely implies it compresses all of it.

What it compresses. The booking queue and the reporting phase. Three vendors publish this end of the range: Cobalt publishes findings in 24 hours with proof of exploit and remediation guidance on its Autonomous Pentest, Intruder publishes a same-day audit-ready report usable as evidence for ISO 27001 and SOC 2, and Stingrai publishes same-day results on its Autonomous tier. Where a traditional engagement spends 2 to 4 weeks in a queue and 1 to 12 days writing, an autonomous test can put confirmed findings in front of an engineer on the day it runs.

What it does not compress. Scoping still needs an asset inventory, authorisation and working credentials. Remediation still takes a median 10.5 days for a Critical and 38.0 for a High, because that number is a property of your engineering process, not of the testing method. And a retest still has to happen after the fixes.

What that means for a plan. Autonomous testing can move a project from roughly 4 to 8 weeks of calendar time down to days for the discovery half, which is decisive when the driver is release velocity, a customer security questionnaire arriving with a two-week deadline, or a regression check after a significant change. It does not turn a three-month remediation and verification cycle into a one-week one.

At Stingrai, certified penetration testers work concurrently with Snipe, our autonomous AI agent for web application penetration testing, across the whole engagement. Snipe is custom-trained on thousands of disclosed vulnerability reports and on Stingrai's own testing methodology, and it is built to hunt the classes that take a human tester the longest to reach: broken authorisation, IDOR, business logic flaws and access-control failures. It runs black-box dynamic testing and white-box source review, opens AutoFix pull requests for what it finds, and can sit as a gating check on every pull request, which moves part of the remediation tail forward into the development cycle rather than after the report. The pricing page publishes both models: an Autonomous Pentest from US$3,000 one-time with same-day results, and a Hybrid Pentest at US$6,800 one-time, each covering one web application and its APIs with retesting included, and the same two tiers at US$450 and US$1,275 per month on a 12-month engagement for teams that want testing running continuously rather than once a year. Stingrai is a Toronto-headquartered, CREST-accredited penetration testing service provider founded in 2021, and its penetration testing supports SOC 2, ISO 27001, PCI DSS and HIPAA programmes by producing the scope statement, technical report, remediation record and retest evidence those programmes consume. Scopes beyond one application are quoted through Get a Quote.

What this means for buyers

• Ask for two dates, not one. The testing start date and the report delivery date. A quote that gives you tester days without a calendar is not a schedule.

• Put the booking lead time in writing at quote stage. A published 2 to 4 week queue is normal and manageable if you know about it in July. It is a crisis if you find out in September.

• Ask which reporting convention the vendor uses. Flat turnaround or a day per testing day. On any engagement longer than about five days, that question is worth a week of your calendar.

• Read the retest window against the 38-day median High. If verification is only free inside a window shorter than your realistic remediation time, the retest is a second purchase and you should price it now.

• Have credentials and the asset inventory ready before the scoping call. This is the only lever on this page that is entirely yours and it moves both the schedule and the quality of what the test finds.

• If the driver is a fixed external date, buy the queue position. Faster starts are published as contract terms. Treat speed as a line item to negotiate, not a favour to request.

• Plan the remediation window with engineering before the test, not after the report. The report is the middle of the project, not the end of it.

Frequently Asked Questions

How long does a penetration test take in 2026?

Active testing runs 1 to 20 days for most engagement types, with red team work published in weeks at 2 to 14 weeks. A web application is published at 3 to 5 days (Precursor Security) through 5 to 20 days (Fortbridge), an external network at 3 to 5 days, and an internal network at 1 to 10 days depending on estate size. The full engagement from first enquiry to delivered report is published at 4 to 8 weeks of calendar time by both Fortbridge and Zensec, because scoping, booking lead time, reporting and retesting all sit outside the testing days you were quoted. All figures are typical, from vendor scoping pages.

How long does a web application penetration test take?

Published bands run from 2 to 3 days for a simple site up to 10 days or more for a large or complex application (Zensec), with 3 to 5 days (Precursor Security), 5 to 20 days (Fortbridge) and 6 to 12 days (EJN Labs) all published for the same nominal scope. The spread is almost entirely about authentication. An unauthenticated marketing site sits at the bottom of that range and a multi-role SaaS platform with an admin console and tenant separation sits at the top.

How long does a network penetration test take?

External network testing is published at 1 to 5 days, with three firms independently publishing a 3 to 5 day band and Zensec publishing 1 to 3 days for a small organisation rising to 4 or 5 days and more for a larger estate. Internal network testing is published at 1 to 10 days: 1 to 3 days for about 150 hosts (EJN Labs), 3 to 5 days for a mid-sized organisation (Zensec), 5 to 8 days for a larger estate (Precursor Security) and 5 to 10 days (Fortbridge). Host count is the driver.

How long does a red team engagement take?

Red team work is published in weeks rather than days: 2 to 3 weeks for a focused engagement (EJN Labs), 2 to 6 weeks and sometimes longer (Zensec), and 2 to 14 weeks across the full range (Fortbridge). The length is a function of objective rather than asset count: a red team is testing whether a goal can be reached and whether your detection and response notice, which takes time by design. Stingrai's red teaming service scopes those engagements individually.

How long after the test do I get the report?

Two conventions are published. Fortbridge publishes a flat 1 to 3 days after testing ends. Zensec publishes roughly one day of reporting for every day of testing, with a draft within a few days of completion. At the compressed end, Cobalt publishes findings in 24 hours on its Autonomous Pentest, Intruder publishes a same-day audit-ready report, and Stingrai publishes same-day results on its Autonomous tier. Ask which convention applies before you commit to a delivery date on anything longer than a five-day engagement.

How far in advance should I book a penetration test?

Precursor Security publishes that engagements begin 2 to 4 weeks after a quote is accepted, and scoping adds another 1 to 2 weeks in front of that. Working backwards from a hard date, start the conversation about two months out for a short engagement and closer to three for a large one. On contracted platform tiers the queue shrinks: Cobalt publishes start times of 3, 2 and 1 business days on its Standard, Premium and Enterprise tiers, which shows that a faster start is generally a commercial term rather than a testing constraint.

How long does remediation take after a penetration test?

Longer than the test. Across 1,206 verified findings from 55 penetration tests in Stingrai's State of Penetration Testing 2026, the median Critical took 10.5 days to fix and the median High took 38.0 days. Those are measured medians rather than planning estimates. Reserve engineering capacity at scoping rather than after the report lands, and check that the retest window your vendor publishes is longer than the 38-day median High, or the verification step becomes a separate purchase with its own booking lead time.

Can a penetration test be done in a day?

For a genuinely small scope, yes. Zensec publishes 1 to 2 days for a single-site wireless test and 1 to 3 days for external infrastructure at a small organisation, and EJN Labs publishes 1 to 3 days for an internal network of about 150 hosts. What a single day cannot cover is an authenticated multi-role application, because the authorisation and business logic testing that produces the highest-severity findings needs time across roles. Autonomous testing changes the arithmetic at the discovery end: Stingrai publishes same-day results on its Autonomous tier for one web application and its APIs.

Does an AI or LLM penetration test take longer?

The published figures disagree more here than anywhere else on this page. EJN Labs publishes 5 to 7 days for AI and LLM penetration testing, while Fortbridge publishes 10 to 20 days for an LLM engagement. A factor of three on the same nominal scope is honest evidence that the category has not converged on what a complete AI engagement covers. For this scope specifically, ask for a written test plan naming the classes in scope before you accept a duration.

Why do two vendors quote different lengths for the same test?

Because they are scoping differently, not working at different speeds. The recurring driver is authentication depth and role count: an unauthenticated surface and a four-role authenticated platform are quoted under the same words and are not the same job. Secondary drivers are whether the estimate covers testing days or calendar days, whether reporting is inside the figure, and whether a retest is included. When two quotes differ by more than about 50% on the same asset, ask each vendor for the role list and the authenticated scope they priced, and the gap usually explains itself.

Related Reading

• Penetration Testing Cost in 2026, the scope-driven cost guide behind the day counts on this page.

• Penetration Testing Cost Per Hour and Day Rates (2026), which turns a published day rate and a published day count into a project price.

• How Often Should You Do Penetration Testing? (2026), the cadence question this page's timeline feeds into.

• PTaaS Pricing Compared (2026), including the published assessment windows attached to subscription packages.

• Penetration Testing Methodologies, the frameworks that structure the testing phase.

• The State of Penetration Testing 2026, the findings dataset behind the remediation medians.

References

1. Fortbridge. How Long Does a Penetration Test Take? Read 5 September 2026. https://fortbridge.co.uk/pentesting/how-long-does-a-penetration-test-take/. Publishes phase durations for scoping, testing and reporting, the 60% to 70% share of engagement time spent in active testing, an end-to-end calendar band of 4 to 8 weeks, and testing day ranges for eight engagement types including LLM engagements.

2. Zensec. How Long Does a Penetration Test Take? Read 5 September 2026. https://zensec.co.uk/blog/how-long-does-a-penetration-test-take/. Publishes scoping duration, the day-per-day reporting convention with a draft within a few days, testing ranges for external, internal, web application, mobile and wireless engagements, red team duration, and the same 4 to 8 week end-to-end band.

3. Precursor Security. Penetration Testing Cost. Read 5 September 2026. https://www.precursorsecurity.com/services/offensive-security/penetration-testing/cost. Publishes tester-day counts for web application, external network, internal network and full assessment engagements, a 24 hour quote turnaround, a 2 to 4 week booking lead time after quote acceptance, and retesting included inside the assessment window.

4. EJN Labs. Penetration Testing Cost UK. Read 5 September 2026. https://ejnlabs.com/penetration-testing-cost-uk/. Publishes durations for twelve engagement types including web application, mobile, API, cloud, external and internal infrastructure, secure code review, AI and LLM testing, social engineering and red team exercises.

5. Synack. Pricing. Read 5 September 2026. https://www.synack.com/pricing/. Publishes fixed assessment windows of 4 to 5 days, 5 days, and 14 or 365 days against defined package scopes.

6. Cobalt. Pricing. Read 5 September 2026. https://www.cobalt.io/platform/pricing. Publishes pentest start times of 3, 2 and 1 business days by contract tier, findings in 24 hours on the Autonomous Pentest, and the definition of one credit as the equivalent of eight hours of offensive security testing.

7. Intruder. Pentest pricing. Read 5 September 2026. https://www.intruder.io/pentest-pricing. Publishes a same-day audit-ready report usable as evidence for ISO 27001 and SOC 2, with unlimited retesting inside the per-test price.

8. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, a 0.74% false-positive rate, 92.7% of tests surfacing a High or Critical, and median remediation times of 10.5 days for Critical and 38.0 days for High.

9. Stingrai. Pricing. Read 5 September 2026. https://www.stingrai.io/pricing. Published package prices for one web application and its APIs, retest inclusion, and same-day results on the Autonomous tier.

10. Stingrai. Penetration Testing Cost 2026. https://www.stingrai.io/blog/penetration-testing-cost-2026. Scope variables behind a quote, by engagement type.

11. Stingrai. Penetration Testing Cost Per Hour and Day Rates 2026. https://www.stingrai.io/blog/penetration-testing-cost-per-hour-2026. Published day rates and the arithmetic that turns a day rate and a day count into a project price.

Ready to put a start date against your scope?

A duration is only meaningful against a defined scope and a confirmed start date. Stingrai publishes both sides of that: an Autonomous Pentest from US$3,000 one-time with same-day results, and a Hybrid Pentest at US$6,800 one-time where certified penetration testers work alongside Snipe throughout the engagement, each covering one web application and its APIs with retesting included, plus the same tiers at US$450 and US$1,275 per month on a 12-month engagement. Book a free scoping call to get a scoped duration and a start date, get a quote for a network, cloud, mobile or red team scope, or read the packages on the pricing page.