What determines the cost
See how scope, complexity, access, restrictions, reporting, and retesting change the amount of work.
Read nextTimeline guide
How long does a penetration test take?
There is no responsible fixed duration based on the word “pentest” alone. The active testing window and report-delivery date should be set after the systems, roles, environments, access, restrictions, and deliverables are understood. Trespass quotes those dates individually. If you are working toward a customer or audit deadline, plan the full path from clarification and authorization through reporting, remediation, and any required retest.
The end of active testing, delivery of the report, and delivery of final evidence are different milestones. Confirm which one the requester expects by its deadline before your company promises a date.
Primary references: NIST SP 800-115, OWASP reporting guidance
Published by Trespass Security
Count the whole job
A pentest does not begin when testing starts.
The calendar includes the decisions and preparation that make authorized testing possible, then the work needed to turn the result into usable evidence.
- Clarification and scope
Confirm what was requested, which systems and roles are involved, what is excluded, and what the requester expects to receive.
- Agreements and authorization
Complete the applicable agreements, written permission, Rules of Engagement, contacts, testing windows, and stop conditions.
- Access and readiness
Prepare the environment, accounts, roles, allowlisting, remote access, monitoring, backups, and third-party permissions.
- Active testing
Perform the authorized work across the approved targets and investigate potential findings in context.
- Reporting and review
Validate findings, document evidence and limitations, complete quality review, deliver the report, and discuss the results.
- Remediation and retesting
Your team addresses eligible findings, then the agreed fixes are checked within the approved retest window.
Name the milestone
“Done by Friday” can mean four different things.
The requester may need confirmation that testing is scheduled, active testing completed, a report delivered, or remediation retested. Those are not interchangeable dates.
Ask what decision happens on the deadline and which document or status the requester expects to have in hand.
A deadline in a procurement portal has a way of looking final before anyone has agreed on what must exist by that date.
What changes the schedule
The target count is only the beginning.
Two engagements with one application each can still require very different calendars.
- Roles, tenants, and workflows
Authentication paths, privilege levels, administrative functions, business logic, and tenant boundaries affect the work—not just the number of URLs.
- APIs and integrations
Supporting APIs, connected services, mobile clients, identity providers, and third-party boundaries may add coverage or permission questions.
- Environment and testing windows
Production restrictions, maintenance windows, prohibited actions, off-hours conditions, and fragile workflows shape when and how testing can occur.
- Access readiness
Unavailable roles, broken test accounts, VPN problems, allowlisting delays, or missing data states can stop coverage even when the calendar says testing has begun.
- Scope changes
New systems, newly requested roles, changed environments, or different evidence requirements may require a revised schedule.
- Findings and follow-through
Investigation, reporting, internal review, remediation work, and retesting affect when final evidence is actually ready.
Plan backward
Build the schedule from the evidence deadline.
Starting from the provider’s first available testing date can leave no room for the work that follows. Start from what the requester needs and move backward until every dependency has an owner and a date.
- Requester receives the evidence
Start with the actual external deadline and the expected deliverable.
- Internal review is complete
Leave time for the people responsible for security, engineering, legal, or customer communication to review what will be shared.
- Retesting is complete, if required
Account for engineering work and the agreed retest path when the requester expects updated finding status.
- The report is delivered
Confirm the report date separately from the last active testing day.
- Testing and preparation are scheduled
Work backward through the testing window, access validation, authorization, and final scope.
No mystery dates
The schedule should say what depends on your team and what depends on the provider.
A date is useful only when the scope, prerequisites, testing window, report delivery, and follow-up expectations behind it are clear.
Useful first message: “Our customer needs a response by October 30. We are confirming whether they need the final report or only a committed testing date by then. The production application and two user roles are likely involved. What must be decided before you can propose testing and report dates?”
Ask before approving the schedule
A useful proposal makes the calendar and its assumptions visible.
- What are the proposed active testing dates?
- When is the report expected to be delivered?
- Which access, accounts, permissions, and other prerequisites must be ready first?
- What happens to the dates if access fails or the scope changes?
- How will a material finding be communicated during testing?
- When does the report review occur?
- What is included in the retest path and when can it happen?
- Does the proposed schedule reach the requester’s actual evidence deadline?
If the request is urgent
Share the date early. Keep the promise narrow.
Tell the provider the hard deadline, what must happen on that date, and the earliest point at which your systems and people can be ready.
The responsible answer may be a feasible schedule, a narrower authorized scope, a clarification request to the third party, or a clear statement that the original date cannot support the expected evidence.
- Do not promise the customer a report date based only on the first testing day.
- Do not treat a signed scope as proof that accounts and access are ready.
- Do not schedule remediation and retesting before engineering has reviewed the findings.
- Do not assume an urgent request makes an unconfirmed scope safe to rush.
- Do not hide a hard deadline from the provider until the proposal is nearly complete.
Next step
Bring the deadline before you promise the date.
Send the request, likely systems, expected evidence, and hard deadline. We will identify what must be clarified before testing and report dates can be proposed.