What does a pentest including retest cost?

Context and background

A penetration test followed by a retest is the standard way not only to find issues but to prove that critical findings were actually fixed. Many clients underestimate remediation effort: patches, configuration changes and sometimes architecture updates take time—the retest confirms the gap is closed and no regression slipped in.

The “50 assets” scope here usually means a focused set of IP addresses, hosts, URLs or applications explicitly in scope. Anything not named—adjacent test systems, partner VPNs or unmaintained legacy apps—stays out and should be recorded in writing. That avoids expectation gaps and keeps the engagement within a realistic window (here roughly four weeks including reporting and one retest).

External and internal describe two perspectives: from the internet (like an external attacker) and from the internal network (insider paths, compromised clients, lateral movement). The combination is valuable because many attacks only pivot internally after the first foothold. We align scope, time windows and escalation paths with you so testing stays productive and avoids unplanned outages.

Management and technical reports should not only list CVEs but contextualise risk: exploitability, affected data, business impact and remediation priority. Development teams benefit from reproducible steps and clear fix guidance; security teams from KPIs comparable across cycles. A retest validates the most important high/critical findings and supports trust with customers, auditors or the board.

Cost drivers include application complexity, number of environments, authentication models and edge cases (mainframes, mobile apps, high-traffic APIs). More assets or multiple retest rounds push the range upward; a narrow scope (one critical web app plus API) can be lower. The band shown is a solid guide for mid-market and agency-style setups.

After testing we recommend pushing findings into your ticket system, naming owners and setting deadlines. Where fixes take longer, temporary compensating controls (monitoring, WAF rules, reduced exposure) can be discussed—documented transparently. For following years you can define a cadence (e.g. annual full test, quarterly targeted retests) that matches regulatory expectations and risk appetite.

If you want implementation help, pentest results can feed directly into hardening or architecture work—tighter IAM, segmentation or CI/CD security. Our security and audit services continue where the test ends: sustainable protection rather than a one-off PDF.

A retest targets the closed high-risk findings—it does not always mean a full re-scan of the entire attack surface. Scope, time box and acceptance criteria are agreed upfront (e.g. re-checking the same attack vectors). That keeps costs controlled while still providing credible evidence that critical gaps were not reopened.

Many clients need mapping to normative or sector frameworks. Pentest findings can be bridged sensibly to ISO/IEC 27001 controls, BSI modules or TISAX—without mistaking the test itself for certification. We clearly label what was demonstrated versus what still needs separate audits or processes.

Handover to development works best with reproducible steps, screenshot/request traces and clear severities. Optional triage SLAs define who prioritises, when a fix plan is due and when retest is scheduled—so critical findings do not stall in backlogs while customer or regulatory deadlines approach.

Release windows, change freezes and peak load periods (e.g. peak sales, year-end closing) should shape planning. A pentest right before go-live without fix buffer increases pressure and cost. We recommend scheduling test and remediation phases ahead of critical business events—or a split approach (pre-production test, production after stabilisation).

APIs, mobile clients and admin consoles often share business logic but expose different attacker surfaces. The scope should state whether GraphQL/REST endpoints, partner integrations or only the public web UI are in scope—including rate limits, object-level authorisation and error handling that does not leak sensitive data. A crisp scope avoids later debate about “forgotten” entry points.

Many framework agreements and RFPs ask for a current pentest attestation or at least traceable security artefacts. We structure reports so they support vendor questionnaires and due diligence without oversharing technical detail. Where needed we add a short management attestation summarising timelines, scope and retest status.

Logging and monitoring should be tuned so analysts see relevant traces during and after the test—without the pentest flooding production telemetry. We align test windows, sampling rules and alert thresholds with your SOC or operations so exercises stay distinguishable from real incidents and do not trigger false major incidents.