A professional penetration test should have a visible operating rhythm. Buyers should know what must be ready, what the testing team is doing, which decisions are due and how urgent risk will be communicated without asking for a daily list of attack steps.

The calendar varies with scope, environment and method. A focused web assessment may compress several stages into days; a multi-channel or production engagement may need more preparation and phased execution. The useful model is a sequence of evidence and decision gates, not a promise that every test lasts the same number of weeks.

The timeline below assumes a medium-sized engagement with a separate remediation and retest window. It can be scaled, but readiness, authorisation, coverage reconciliation, report review and closure should not disappear when the schedule is shorter.

Before Week 1: authorise and mobilise

Finalize the SOW, target inventory, environment, assessment type, data handling, rules of engagement, third-party permissions and named decision owners. The testing team should not infer authority from a purchase order alone.

Create secure communication and evidence channels and record escalation contacts, availability windows and stop authority. Schedule kickoff only after both sides can identify unresolved blockers.

  • Signed scope and written authorisation.
  • Rules, prohibited actions and emergency process.
  • Secure contacts and evidence channels.
  • Readiness owner and open-dependency list.

Week 1: kickoff and scope reconciliation

At kickoff, confirm objectives, tested release, architecture, identities, critical workflows, known operational constraints and the business decisions the evidence must support. Resolve ambiguous hosts and environments.

The provider converts scope into an initial coverage model. The buyer confirms which application, API, mobile, tenant, role and administrative paths are representative and supplies authoritative owners.

  • Objectives and success criteria.
  • Build, host and API baseline.
  • Role, tenant and workflow map.
  • Change and escalation procedure.

Week 1: prove technical readiness

Test accounts, MFA, VPN, allowlisting, binaries, API documentation, test data and monitoring are validated with small, recognisable checks. Problems are recorded against owner and due date.

A readiness failure should not silently consume testing time. The parties decide whether to repair, substitute an authorised route, defer affected scope or move dates, and record the resulting limitation.

  • Connectivity and source visibility.
  • Representative identities and states.
  • Stable data and workflows.
  • Operations recognition of test traffic.

Week 2: discover the reachable attack surface

The team maps routes, APIs, hosts, roles, client behaviour, exposed services and trust transitions using approved reconnaissance and authenticated exploration. Documentation is compared with observed behaviour.

Discovery is continuous, but early results shape the detailed plan. Newly found in-scope assets enter change control; out-of-scope systems are not tested simply because they are reachable.

  • Application and API inventory.
  • Authentication and session paths.
  • Integration and callback surfaces.
  • Observed versus declared scope.

Week 2: establish baseline control behaviour

Testers verify expected access, errors, state transitions and business outcomes for representative roles and objects. These controls make later negative tests interpretable.

The team begins authorization, input, configuration, session and information-exposure tests while preserving precise request, identity and environment context. Confirmed severe issues follow the urgent path immediately.

  • Permitted control cases.
  • Role-object-tenant matrix.
  • Input and protocol boundaries.
  • Early evidence review.

Week 3: deepen manual and workflow testing

Testing expands into alternate sequences, direct API calls, privilege boundaries, concurrency, replay, recovery, administrative operations and client-to-backend inconsistencies.

High-value workflows receive end-to-end validation against authoritative state. Scanners can support coverage, but analysts connect technical behaviour to exploitability and business impact.

  • Business-logic manipulation.
  • Cross-role and cross-tenant paths.
  • State, replay and race conditions.
  • Mobile, browser and backend differences.

Week 3: track coverage and constraints

The provider updates coverage against the plan, including untested roles, unavailable operations, rate restrictions and environment differences. The buyer resolves dependencies without directing technical conclusions.

A status update should describe progress and decisions, not expose sensitive exploit detail broadly. Material gaps are addressed while there is still time to test them.

  • Coverage completed and remaining.
  • Blocked or unstable targets.
  • Approved scope changes.
  • Forecast effect on milestones.

Any week: escalate critical risk safely

A confirmed critical vulnerability is communicated through the agreed urgent channel before the engagement ends. The notice includes affected target, concise impact, safe evidence, immediate containment options and the next coordination point.

Testing pauses or narrows if continued activity could increase harm. The buyer activates incident or vulnerability response as appropriate while preserving evidence and avoiding uncontrolled production experiments.

  • Confirmation and duplicate control.
  • Named recipient and acknowledgement.
  • Containment and stop decision.
  • Protected follow-up and root-cause scope.

Week 4: reconcile coverage and findings

Before report drafting closes, the team compares actual testing with the target, role, object, workflow and technique plan. Missing coverage is completed or declared as a limitation.

Potential findings undergo reproduction, evidence minimisation, duplicate removal, severity calibration and technical peer review. Unsupported suspicions remain observations or are removed.

  • Coverage-to-scope reconciliation.
  • Reproduction on the tested baseline.
  • Severity and business-context review.
  • Limitation and residual-uncertainty record.

Week 5: conduct controlled draft review

The buyer reviews factual accuracy: asset names, ownership, workflow context, environment and remediation feasibility. The provider retains independent control of technical conclusions and risk rationale.

Disagreements are logged and resolved through evidence. Drafts stay in restricted channels because they contain exploitable detail; executive and technical audiences receive appropriate views.

  • Factual-context corrections.
  • Evidence-based dispute resolution.
  • Executive and engineering readouts.
  • Protected distribution and version control.

Week 5: issue final evidence

The final package includes scope, baseline, method, coverage, limitations, findings, severity rationale and remediation guidance. It should state point-in-time limits and avoid a guarantee of security.

The buyer confirms owners, due dates, risk decisions and the intended corrected release. Open dependencies and retest entry criteria move into the remediation plan.

  • Final signed or controlled report.
  • Coverage and limitations appendix.
  • Finding ownership and priorities.
  • Retest scope and prerequisites.

Following weeks: remediate with traceability

Engineering fixes root causes, tests internally and records code, configuration and architecture changes. Shared-control weaknesses trigger review of related paths beyond the demonstrated request.

Security and risk owners assess compensating measures, accepted risk and release timing. The original report remains immutable; status lives in the remediation system and later retest record.

  • Root-cause correction.
  • Internal regression and security tests.
  • Exception and residual-risk approval.
  • Corrected release provenance.

Retest week: verify closure independently

The provider validates the corrected target, repeats each authorised proof and tests representative variants affected by the same cause. New work beyond agreed retest scope enters change control.

The closure record identifies the tested build and outcome for every finding. Partial fixes, inaccessible paths and regressions remain explicit rather than being converted into a clean status.

  1. Confirm retest readiness and corrected baseline.
  2. Repeat original proofs safely.
  3. Check systemic variants and regressions.
  4. Issue fixed, partial, open or cannot-verify outcomes.

Use NIST SP 800-115 for technical-assessment planning and execution concepts and the OWASP Web Security Testing Guide for application testing context. Adapt the sequence to authorised scope, environment risk and contractual milestones.

Manage the engagement through evidence gates

A reliable week-by-week plan gives every participant a clear responsibility without micromanaging the tester’s investigation. It creates early opportunities to correct readiness and coverage problems.

WIMD operates engagements through documented mobilisation, testing, escalation, quality review, reporting and retesting gates so the final assurance statement matches the work actually completed.