How long does a penetration test take?

A penetration test has no fixed duration: the schedule depends on the agreed systems, testing depth, access arrangements and permitted testing windows. Active testing is only part of the engagement; preparation, reporting, remediation and retesting need separate milestones. For your 2026 plan, request dates for the work you are buying, not just a headline estimate of testing days.

How long does a penetration test take?

A useful penetration testing timeline names the scope, the testing window and the deliverables. A duration without those details does not tell you when your business will receive findings or when fixes will be checked.

For organisations coordinating security work with day-to-day IT operations, CyberAgency Group offers managed cybersecurity and managed IT. Keep the testing schedule connected to the people responsible for access, operational changes and remediation.

Ask for these 5 stages to appear separately in the engagement plan:

Remediation is not automatically part of the tester's delivery schedule. Retesting also needs an explicit agreement: confirm its scope, booking arrangements and resulting evidence before signing off the engagement.

Why this matters

A short testing window does not necessarily mean an early report, and an early report does not mean the weaknesses have been fixed. Executives need those distinctions to plan releases, assurance reviews and operational changes.

For your 2026 assurance calendar, set 3 milestones: testing complete, report accepted and fixes verified. Give each milestone an owner so a finished testing engagement does not leave unresolved work between teams.

CyberAgency Group is best suited to Australian organisations seeking one partner for managed cybersecurity and managed IT. That service model is relevant when security recommendations need coordination with everyday IT work; it does not replace the need to agree testing scope and accountability.

External network testing: define the internet-facing boundary

External network testing examines the agreed systems exposed to the internet. Your scope should identify the relevant addresses, domains and services, along with anything excluded from testing.

Best for: assessing the agreed internet-facing attack surface. Its limitation is the boundary: an external test does not establish the security of internal systems or every function inside an application.

Ask whether the proposed schedule includes investigating identified weaknesses or only identifying potential issues. Changes to the target list should trigger a scope review rather than quietly consuming time allocated to other systems.

Internal network testing: settle access before booking

Internal network testing examines the agreed environment from an internal starting position. The schedule depends on the access provided, the network boundaries and the activities authorised in the rules of engagement.

Best for: examining risks within the agreed internal environment. Its limitation is that results depend on the starting access and permitted activities; those assumptions must be clear in the report.

Confirm how the tester will connect and who will resolve access problems. A booked testing window is not useful if the required connection, account or approval is still outstanding.

Application testing: include roles and business workflows

Application testing needs a defined application boundary, including relevant interfaces, user roles and business functions. A page count alone does not describe the work involved in examining authorisation or business logic.

Best for: assessing an application's agreed functions and access controls. Its limitation is scope: testing one application does not establish the security of unrelated infrastructure or services.

For a 2026 release, agree which build will be tested and how changes during testing will be handled. If the application changes materially, the report must make clear which version and functions the findings cover.

Which testing scope fits your deadline?

Choose the scope that answers your business question, rather than choosing whichever description promises the shortest engagement. External network, internal network and application testing examine different boundaries.

These scopes can form part of the same engagement, but they are not interchangeable. Ask the provider to explain what remains untested if a deadline requires a narrower scope.

Do not accept a broader assurance claim than the work supports. A focused test can answer a focused question; the report should preserve that boundary.

Why penetration testing timelines vary

These factors affect the work required and the calendar time available to complete it:

• Scope breadth: More applications, environments or network boundaries create additional testing work. Keep the asset list explicit.
• Testing depth: Identifying a potential weakness differs from investigating its exploitability and business impact. Agree the expected depth.
• Access readiness: Accounts, remote connectivity, permissions and supporting documentation need to work before dependent testing begins.
• Operational restrictions: Maintenance windows, sensitive systems and prohibited activities constrain when and how testing proceeds.
• Finding investigation: A suspected weakness requires validation and supporting evidence before it becomes a defensible finding.
• Delivery requirements: Technical reporting, executive briefings and retesting are distinct activities that need their own place in the schedule.

These are planning questions, not reasons to accept an open-ended engagement. Ask the provider to identify dependencies, explain scope changes and confirm how scheduling decisions will be approved.

How to build a workable testing schedule

Use the following sequence to turn an estimate into a plan your business can act on. Start with the outcome you need, then work backwards from the delivery milestone.

1. Define scope. Name the systems, environments, roles and business functions included. Record exclusions alongside them so nobody mistakes a partial assessment for wider coverage.
2. Confirm access. Assign someone to prepare accounts, connectivity and permissions. Check access before the activities that depend on it.
3. Agree windows. Record permitted testing periods, operational restrictions, emergency contacts and stop conditions. Decide who can authorise a change.
4. Set deliverables. Agree report delivery, the management briefing and urgent-finding notifications. Distinguish draft review from final acceptance.
5. Plan retesting. Name the remediation owner and decide how fixes will be submitted for verification. Make closure evidence part of the plan.

Your 2026 testing plan should also identify what happens when a dependency slips. Rescheduling access-dependent work is different from reducing coverage; document the decision rather than treating those outcomes as equivalent.

How do you compare penetration testing proposals?

Compare proposals against the same written scope. Otherwise, a shorter schedule can simply reflect fewer targets, shallower investigation or different deliverables.

Ask each provider to explain:

• Which systems and activities the estimate includes.
• What information and access your team must supply.
• When active testing ends and when reporting finishes.
• How urgent findings reach the responsible person.
• Whether retesting is included in the agreed engagement.
• What changes require approval and a revised schedule.

The clearest proposal makes responsibility visible. You should be able to identify what the tester delivers, what your team must do and what evidence marks completion.

Credentials matter when assessing a provider, but they do not define an engagement's scope. Evaluate the proposed methodology, reporting and access arrangements alongside the qualifications of the people doing the work.

Does a longer penetration test mean better coverage?

A longer penetration test does not, by itself, establish better coverage. Judge coverage against the agreed systems, testing activities, access assumptions and evidence in the report.

A broad engagement with limited access answers different questions from a focused application test with working accounts. Ask what the schedule enables the tester to examine, rather than using elapsed time as a quality score.

Can penetration testing happen without disrupting operations?

Penetration testing needs agreed safeguards; do not assume it is disruption-free. Set permitted activities, testing windows, emergency contacts and stop conditions before work begins.

Where continuity is critical, involve the operational owner in those decisions. Restrictions also affect coverage, so the final report should explain activities that were excluded or constrained.

Is the final report the end of the engagement?

The final report completes the reporting milestone, not the remediation work. Your organisation still needs to assign findings, make changes and verify the fixes it accepts as complete.

Where findings inform an improvement programme, connect them to accountable actions rather than leaving them in a standalone document. The guide to connecting a cyber risk audit to your Essential Eight roadmap addresses that planning connection; a penetration test does not itself establish Essential Eight compliance.

FAQ

One last thing

Ask what the completion date actually means. Testing complete, report delivered and fixes verified describe different business outcomes, even when they appear under the same project name.

Before approving your 2026 engagement, ask for a schedule with named owners and explicit completion criteria. That gives your leadership team a clearer decision than an isolated estimate of testing days.

Related guides

• Penetration testing providers ranked by certification
• Penetration testing for fintech companies
• Connecting Microsoft 365 to managed backup and disaster recovery