A penetration-test report arrives. Engineering needs to investigate the findings, plan fixes and deploy the changes. Only then does someone ask how long the testing firm will remain available to check the repairs.
That is an expensive time to discover that “retesting included” has conditions the delivery team never saw.
Compare proposals through the whole assignment: preparation, testing, the findings handoff and follow-up. CREST’s penetration-testing guide treats those phases as part of a managed programme. For a buyer, the practical consequence is straightforward: the testing dates and the engineering calendar belong in the same purchasing conversation.
Make the service name specific enough to price
“Test our SaaS product” leaves the provider to infer a large part of the assignment. List the application and environment, important user roles, connected systems and the business journeys that concern your team. Have the security lead distinguish what is included, what is excluded and what still needs clarification.
Service menus show why that distinction matters. Bishop Fox lists application penetration testing, secure code review, cloud security and network security separately. A proposal for one area should not be read as coverage of all the others.
Ask the provider to describe the information and access it expects. For an application test, that might include test accounts for agreed roles, relevant documentation and a stable environment. Your technical team should confirm what it can supply and when. Put a named owner next to each prerequisite.
Then ask the provider to explain its approach in relation to your scope. You need to understand what the proposed effort can reasonably cover and what a change in scope would do to the quote. A longer asset list with no discussion of depth is not enough to compare two offers.
Keep a buyer-owned scope sheet
Use one scope sheet for every finalist. The following is an original purchasing worksheet; your security and engineering leads should adapt it to the actual environment.
| Scope item | Decision to record before testing | Who needs to agree |
|---|---|---|
| Target and version | Exact environment and the release or configuration the test will cover | Engineering owner and testing lead |
| Roles and journeys | Included account types and important workflows | Product owner and security lead |
| Boundaries | Excluded systems, third-party dependencies and actions that require separate authorization | Authorized system owners and testing lead |
| Operating arrangements | Access readiness, communication channel, pause contact and change notification | Operations owner and testing lead |
| Outputs | Report format, finding detail, management discussion and engineering handoff | Report recipient and remediation owner |
| Follow-up | Retest eligibility, request deadline, charges and result format | Commercial owner and testing lead |
Treat access readiness as a real acceptance point. A slot in the provider’s calendar is less useful if the accounts do not work or a major release changes the environment halfway through. Ask what happens to timing and fees when your prerequisites are late.
Also name the person who can authorize a change or pause. The consultant should have a clear contact when the agreed conditions no longer hold. Those arrangements belong in the approved engagement, before any testing starts.
Read the retest window against the contract end date
Cobalt’s remediation documentation provides a concrete example. For its Agile and Comprehensive pentests, it lists six months of free retesting on Standard and twelve on Premium and Enterprise, subject to an active contract. The documented cutoff can be ten days before the contract ends. Starting near expiry can therefore leave a much shorter usable window than the tier name suggests.
That is one provider’s policy, not a market-wide rule. Ask each finalist to put the actual last request date for your engagement in the proposal. Have them explain whether the deadline concerns submission, scheduling or completed retesting. Confirm what happens if the contract renews, the product changes materially or a fix requires another attempt.
Keep a separate question about turnaround. A request accepted on time and a result delivered before your customer deadline are different commitments. Ask for both without assuming one follows from the other.
Rehearse the calendar with engineering
Consider an illustrative purchase. The test finishes before a planned release freeze. The report arrives while engineers are already committed to that release. A difficult finding needs a design change, so the first repair cannot be deployed until the next available release window. The retest entitlement ends before that window.
Nothing about the headline testing dates reveals this conflict. Walking through the delivery sequence does.
Before purchase, map the expected report delivery, initial engineering review, likely repair window, retest request deadline and the date by which the recipient needs an updated result. Treat repair timing as a planning assumption, not a promise that every finding can be resolved on schedule.
If the sequence does not fit, resolve it with the provider and your internal owner. Possible discussions include an earlier test, a different contract period, separately priced follow-up or more engineering availability. The right choice depends on the actual assignment; a nominally included retest has little value if nobody can use it.
Leave room for disagreement about a finding. Agree where the engineer asks questions, who responds and how a disputed item is recorded. A ticket marked “done” inside your tracker should not silently become a confirmed repair in the external report.
Commission a handoff that the next team can use
Request a sample report with sensitive details removed. Have the engineer who will own remediation read it. Can that person understand the affected area, the conditions described, the provider’s assessment and the information needed to discuss a repair? Ask how findings are exported or transferred into your team’s working system.
Include a handoff session in the scope if your team needs one. Specify who attends and what it should accomplish. A management presentation and an engineering discussion can serve different audiences; neither should be assumed to replace the other.
Agree how the final record distinguishes an unresolved issue, a retested repair and a decision by your organization to accept a remaining risk. Assign that last decision to an authorized internal owner. The testing firm’s commercial completion and your organization’s completion of follow-up are separate events worth tracking.
Accept the work without overstating what it proves
At closeout, compare the delivered coverage with the signed scope, record any limitations, and confirm that the promised outputs are accessible. Keep the version and dates with the report so its context survives being forwarded.
CREST describes penetration testing as limited by its selected targets and timing; it may not identify every weakness. Do not turn a completed engagement into an assurance that the whole product is secure or that a customer will accept a particular compliance claim.
The useful purchase is specific: a defined assessment, clear findings, an accountable repair process and follow-up terms that fit the team’s ability to act. Those are concrete enough to put side by side when the proposals arrive.
Sources
- CREST: A Guide to Penetration Testing 2022.
- Cobalt: Remediate Findings.
- Bishop Fox: offensive security services.
Frequently asked questions
Is retesting automatically included in a penetration test?
Do not assume it is. Ask what findings and test types qualify, what the retest costs, when the request must arrive, and whether contract expiry can shorten the stated window.
What should we require at the handoff?
Request the agreed report and findings format, a discussion with the engineers responsible for fixes, named owners, and a written process for submitting changes for retest.