What you're actually buying when you hire a pentest firm
A penetration testing engagement is a time-boxed, scoped exercise. You agree on what's in scope (a set of URLs, an API surface, specific user roles), sign a statement of work, and the firm allocates a fixed number of consultant-days to your project. When those days are done, you receive a report.
That report reflects the state of your application at the time of testing. It lists what was found, severity ratings, and typically recommendations for remediation. The invoice is issued when the report is delivered. The engagement is complete.
This is important: the engagement is complete. What happens after — your team reads the report, developers start fixing things, someone asks "are we done?" — falls outside the original scope.
What happens after the report
The typical cycle after receiving a pentest report:
Triage
Engineering lead reviews findings. Critical and high-severity items get immediate tickets. Medium items get scheduled. Low items go into a backlog.
Remediation
Developers fix the issues. This can take days to weeks depending on severity and how deeply the vulnerability is embedded in the application architecture.
Internal verification
Someone on the team manually retests, or the developers check their own fix. This is often incomplete — the people who wrote the code aren't the best at testing whether their fix actually holds under the attack pattern.
The question nobody has a clean answer to
"Should we run another pentest to confirm the fixes?" This is where the economics get awkward.
Retesting: what firms offer and what it costs
Retesting — verifying that specific findings from the original engagement have been correctly remediated — is handled differently by different firms. There's no industry standard.
Some firms include a limited retest window in the original engagement, typically scoped to confirming that specific vulnerabilities are no longer present (not a full re-assessment). Others treat it as a separate line item billed at a day rate. Some require a new statement of work entirely.
What this means in practice: if you fix your findings and want independent confirmation from the same firm, you should expect to pay something. Whether that's a half-day rate, a fixed retest fee, or a new engagement depends on your contract and the firm's model. The original invoice did not include it.
For organisations that run quarterly pentests, the cycle looks like this: test → report → fix → wait until next quarter → retest everything again as part of the new engagement. Remediation from the previous cycle gets picked up incidentally in the next scheduled test, not in a dedicated verification run.
The gaps this creates
The point-in-time, quarterly-at-best model has structural gaps that are worth understanding clearly:
Three months of unverified surface
Between engagements, your application changes. New features ship. Dependencies are updated. A developer makes a well-intentioned refactor that reintroduces a pattern from a previous finding. None of this is caught until the next quarterly test.
No fast loop on remediation
You fixed a CORS misconfiguration. Is it actually fixed? Unless you re-run the same attack sequence, you don't know. Developers testing their own fixes are less reliable than an independent re-run of the original attack.
Budget pressure on test depth
Because each engagement has a fixed day rate, teams often scope narrowly to control cost. The new API surface that shipped last month may not be in scope for the current engagement.
The pentest becomes a compliance checkbox
When the primary driver of running a pentest is an annual compliance requirement rather than genuine security coverage, the engagement gets scheduled once a year, produces a report that satisfies the auditor, and sits in a drawer until next year.
Where automated scanning changes the economics
Automated vulnerability scanning doesn't replace manual pentests. A scanner can't assess complex business logic, chain multi-step attack paths that require human judgment, or satisfy a compliance auditor that requires a named testing firm. Those are genuine limitations.
What it can do is fill the gaps:
Continuous coverage between engagements
Run a scan on every deployment. If a new vulnerability is introduced in Tuesday's release, you know by Tuesday. You're not waiting until the next quarterly pentest to find out.
Instant re-verification after fixes
Developer fixes a SQL injection finding. Run a scan. The finding either reappears with HTTP proof or it doesn't. No waiting, no additional invoice, no scheduling a retest window with the pentest firm.
Clearing the OWASP Top 10 before the pentest starts
Manual pentest engagements are priced by consultant-day. If a significant portion of those days are spent finding OWASP Top 10 issues that an automated scanner would have caught, you're paying for expensive time on problems that didn't require it. Run a scan first. Clear the obvious issues. Give the pentest team the surface area that actually requires human judgment.
Evidence for the remediation cycle
A dated scan report showing which findings were present, when they were found, and which are now resolved is a useful artifact — for internal tracking, for the next pentest firm scoping conversation, and for auditors who want to see that remediation actually happened.
What a combined workflow looks like
The teams that get the most from both approaches treat them as complementary layers, not competing alternatives:
Run an automated scan 2–4 weeks before the engagement. Fix everything the scanner confirms. Provide the scan report to the pentest firm as context for scoping. The engagement starts from a higher baseline.
Let the manual team focus on attack chains that require human judgment: business logic flaws, multi-step privilege escalation, authentication edge cases, logic that a scanner can't model.
As developers remediate findings, re-run automated scans to verify each fix. No additional cost per re-run. The scanner confirms remediation faster than scheduling a formal retest window.
Run scans on every deployment or at minimum weekly. New surface area gets scanned as it ships. Regressions are caught before the next quarterly pentest.
Bring a history of scan results showing coverage, findings, and remediation. The pentest firm can focus on what's changed and what requires depth rather than repeating the previous engagement.
What automated scanning doesn't replace
To be direct: if you need a penetration test for a compliance mandate (SOC 2, PCI DSS, ISO 27001, a specific enterprise contract clause), a scan report from an automated tool will not satisfy it. Auditors require a report from a named testing firm with qualified consultants. That's a real requirement and automated scanning doesn't address it.
Similarly, if your application has complex business logic — multi-actor workflows, financial transaction chains, trust boundary abuse scenarios — a scanner won't find those. They require a human who understands the application's intended behaviour and can test for deviations from it.
The honest framing is: automated scanning handles the coverage problem between engagements, speeds up the remediation verification cycle, and helps your pentest budget go further by clearing the obvious issues first. It doesn't handle the depth problem or the compliance certification requirement.
Run before your pentest. Run on every deploy. Verify every fix.
Nautillo Pro runs automated vulnerability scans against your web application and generates dated reports with confirmed findings and HTTP proof-of-concept evidence. Free to start — no credit card required.