How long does a penetration test take?

The honest answer is that it depends on three things: how much is in scope, how complicated that scope is, and how ready you are when the engagement starts. Only the first is usually written down before anyone asks. And whatever the testing itself occupies, the calendar time from "we have decided to do this" to "we have a clean retest and a closure letter" is almost always longer — often several times longer — because the test is one stage in a chain, and most of the other stages wait on someone inside your organisation.

Testing time versus calendar time

This is the single most useful distinction a buyer can take into a procurement conversation, and the one most often missed. There are two clocks running, and providers quote the one you did not ask about.

Testing time is the period a tester spends working against your systems. It is what a proposal prices, because it is the part the provider controls and the part that consumes skilled attention. Calendar time is everything from the first scoping call to the point where you can hand something to an auditor, a customer or a board: scoping, rules of engagement, contracting and authorisation, access provisioning, kickoff, testing, reporting, debrief, remediation, retest, closure letter.

Count the stages. The test is one of eleven, and rarely the longest. Scoping stalls on an internal decision nobody has made yet — which system, which question, whose budget. Contracting runs at the speed of your legal function and, where a hosting partner must consent, at the speed of theirs. Access provisioning is the classic silent delay: credentials requested on signature, delivered after kickoff, at the wrong privilege level, for the wrong environment. Reporting is bounded and predictable. Remediation is bounded not by us but by your release cycle, your engineering capacity and your change-control process — and the retest can only follow remediation, so it inherits every delay remediation accumulates.

Buyers who plan around testing time alone discover, uncomfortably late, that the assessment finished on schedule while the deliverable they actually needed — a report with findings closed and evidenced — is still some way off. The assessment was never the bottleneck.

What makes a test take longer

Duration is driven by how much distinct behaviour has to be understood, and by how much friction stands between the tester and the system. The first set of factors are properties of your estate.

Scope breadth. More assets means more work, but not proportionately. Endpoints behind one gateway, sharing a framework and an authorisation model, are understood once and then confirmed. Two genuinely different applications share nothing: two mental models, two authorisation matrices, two sets of framework-specific weaknesses. Breadth measured in different things predicts duration far better than breadth measured in counts.

The number of distinct roles and permission levels. The most consistently underestimated driver. Access-control testing is a matrix, not a checklist: for every sensitive operation, a tester establishes which roles may perform it, attempts it as each role that may not, and separately attempts to reach another user's or another tenant's data as each role in turn. One additional role does not add one check. It adds a pass over every privileged operation, a set of new role pairings to probe in both directions, and another account with seeded data to maintain.

Bespoke business logic. Conventional record handling has a well-understood weakness surface. Logic that prices things, moves money or enforces a regulatory rule exists only in your application, and must be learned before it can be attacked — the flaws are found by understanding intent and then violating it, skipping a step, replaying one, supplying a value the designer assumed impossible. That comprehension cannot be parallelised.

Multi-tenancy. Isolation makes every data-access question two-sided and requires at least two provisioned tenants holding distinguishable data. Enforced consistently in one place it is quick to assess; enforced per query, per service or per cache key, every path must be checked separately.

Unusual authentication. Custom token formats, home-grown single sign-on, federation across several identity providers, step-up authentication, device binding, signed client-side state. Each needs analysis before testing proper begins. Well-trodden authentication does not.

The second set are properties of the engagement, and they add duration without adding assurance.

• Production constraints. Testing the system that actually exists is usually right, but real limits on destructive activity mean slower, more careful work and sometimes an inconclusive answer that has to be reached another way.
• Restricted windows. Testing is cumulative: a tester holds a model of the system in their head and rebuilds context after every interruption. A narrow daily window does not deliver a proportionate fraction of the testing. It delivers less, because that overhead recurs.
• Out-of-hours work. Sometimes genuinely required for systems that cannot tolerate disruption during trading or clinical hours. It also stretches the calendar, because the same effort is spread thinner.
• Slow access provisioning. The commonest delay of all, and the only one here with no compensating benefit whatsoever.
• Unstable environments. One that falls over under ordinary testing, or that is simultaneously hosting a release, costs time twice: once in the outage, and again in separating a genuine finding from a broken deployment.
• Heavy change control. Where every tool, source address and category of activity needs individual approval, the engagement proceeds at the speed of that process while a tester waits.

What you control

A large share of the calendar belongs to you, which is good news: it is the share you can compress without losing anything.

Deciding the question. Engagements stall before they start because the organisation has not settled what it wants to know. "We need a pen test" is a budget line, not a scope. "Can a customer reach another customer's data?" is a scope, and it can be planned and tested. The time spent reaching that sentence internally is better spent before you go to market than during contracting. Our methodology page sets out how we work through it from the first call.

Having credentials and environments ready on day one. One working account per role, verified by someone who has actually logged in with it. Two tenants where the application is multi-tenant. Realistic, distinguishable data in each account — an empty environment is close to untestable for access control, because with nothing to reach there is nothing to attempt unauthorised access to. Allowlisting done, rate limiting and bot protection cleared, session timeouts long enough to be workable. An engagement that opens by chasing access never recovers that stretch.

Naming a contact who can act, not relay: someone who can reset a locked account, confirm whether an error is a finding or a deployment, and answer an architecture question without raising a ticket. The gap between a contact who can act and one who can only forward is a large source of slippage inside the testing stage itself.

Having remediation capacity ready before the report lands. Buyers almost never plan this, and it dominates the back half of the calendar. If the report arrives and the engineers who would fix the findings are already committed to the next release, the retest waits — and so does everything downstream of it. Reserve the capacity when you book the test, not when you read the findings.

The sequence, stage by stage

Each stage has an input it needs, something you have to do, and a thing that blocks it. The shape matters more than any number.

Stage sequence and dependencies. Layout implies no durations.

  scoping
    you provide: asset list, roles, objectives, constraints
    blocked by:  no internal decision on the question
        →
  rules of engagement
    you provide: windows, exclusions, escalation contacts
    blocked by:  unresolved third-party hosting consent
        →
  contracting & authorisation
    you provide: signatory, written authorisation to test
    blocked by:  legal review, asset ownership in doubt
        →
  access provisioning  ──►  kickoff
    you provide: one account per role, seeded data, allowlisting
    blocked by:  wrong privileges, wrong environment, late delivery
        →
  testing
    you provide: a contact who can act, a stable environment
    blocked by:  outages, narrow windows, piecemeal approvals
        →
  reporting  ──►  debrief
    you provide: attendees who can make decisions
    blocked by:  nothing on your side
        →
  remediation
    you provide: engineering capacity, deployment
    gated by:    YOUR release cycle  <— the usual long pole
        →
  retest
    you provide: fixes deployed where the tester can reach them
    blocked by:  partial fixes, fixes only in a branch
        →
  closure letter
    blocked by:  findings still open or accepted without a decision

Scoping and rules of engagement. We establish what is in scope, what is explicitly out, which windows apply, who to call if something breaks, and what the test is meant to answer. You supply the asset list, the roles and the constraints. It is blocked by an internal decision nobody has made.

Contracting and authorisation. Commercial terms plus written authorisation to test the assets named. Where a third party hosts or operates part of the scope, their consent belongs here too — frequently the slowest item in the chain, because it sits outside both parties.

Access and kickoff. Credentials, documentation, specifications, network access, allowlisting. Kickoff confirms everyone is ready and the contacts are live. The failure mode is a kickoff held while access is still outstanding, which converts the opening of the testing stage into provisioning work.

Testing. The stage people picture when they ask this article's question. You need to be reachable; otherwise the work is ours. Serious findings are raised as they are confirmed, not held for the report.

Reporting and debrief. Findings written up with the evidence needed to reproduce and fix them, then a conversation about what matters and in what order. You can see the format of what arrives — structure, evidence, severity reasoning — in our sample report, which is worth reading before you buy rather than after.

Remediation. Yours, gated by your release cycle. We cannot forecast this stage, and neither can anyone else, because it depends on your engineering capacity and your change process.

Retest and closure. The retest verifies that fixes close the issue rather than moving it, and it follows remediation by definition. The closure letter reflects the position after retest, which is why it cannot be dated in advance.

Planning backwards from a deadline

If you have an audit date or a release date, plan from the end of the chain, not the beginning. The deliverable most deadlines actually require is not a report; it is a report with the serious findings closed and verified. That means the retest, not the test, is the stage you have to land on time.

Book in this order. First, the testing slot: a senior tester's availability is the scarcest thing in the chain and the only item you cannot create at short notice. Second, contracting and third-party authorisation, started in parallel rather than after, since neither depends on the test being scheduled. Third, access provisioning, raised the day the engagement is confirmed rather than the day it starts. Fourth, and most importantly, the engineering capacity for remediation and the retest slot, reserved alongside the test itself.

Slippage comes from predictable places, and only one of them is the provider: internal indecision during scoping, legal review running long, third-party consent for hosted components, credentials arriving late or wrong, an environment that is also hosting a release — and, dominating all of them, remediation colliding with a release plan that was already full.

The single most common planning mistake is leaving the retest out of the plan entirely — treating the report as the finish line, discovering the auditor wants evidence of closure, then trying to arrange remediation and verification inside slack that was never there. If your deadline is fixed, work backwards from the closure letter and insist every provider does the same. We structure penetration testing engagements around that whole chain rather than the testing stage alone.

When a faster test is the wrong answer

Sometimes the calendar genuinely will not move, and the only lever is the test itself. There are two ways to make a test shorter, and they are not equivalent.

Compressing scope means testing less, thoroughly. You name the systems that matter most, test them properly, and record plainly what was excluded: a defensible answer about part of your estate and an honest gap about the rest. Phased properly — crown jewels now, long tail next — this is usually the right decision under pressure, and the one we will suggest.

Compressing depth means testing the same scope, less thoroughly. Nothing is excluded on paper, which is precisely the problem: coverage is now uneven in ways the document does not disclose. What gets lost is specific and predictable. The access-control matrix is sampled rather than traversed, which is where the severe findings usually live. Business logic goes untested, because understanding it is the expensive part and so the first thing to go. Chained findings disappear: the issue that only matters because it combines with another is reported in isolation, or not at all, because nobody had time to try the combination. Verification thins, so more findings arrive as "possible" rather than demonstrated. And the report starts to describe tool output rather than attacker behaviour.

The outcome is worse than a smaller test, because a narrow report tells you what you do not know, whereas a thin report tells you nothing is wrong. You then decide on the strength of a document that was never load-bearing — and compressing the test does not shorten remediation or retest, so the saving lands in the one stage where depth mattered most.

If the date cannot move, cut breadth and write down what you left out. And if someone offers to keep the scope while shortening the test, ask which of the things above they intend to drop. The answer is the useful part of that conversation.