Retesting and remediation support should be agreed in the original VAPT contract because closure becomes urgent after findings are delivered. Define what is included, which findings qualify, how many cycles and variants are covered, what constitutes a retest-ready build, the availability window, advisory boundaries, turnaround, evidence and pricing for expanded scope or additional cycles.
Start with the assurance requirement
Clarify whether the buyer needs technical clarification, remediation design guidance, implementation review, independent retest, a closure letter or all of them. Each has different effort and independence implications.
Record the requesting party, framework or contract clause, assessment boundary, evidence period, due date and decision the evidence must support. Confirm the interpretation with the auditor, assessor or customer where possible. A penetration test can contribute strong assurance, but a report cannot guarantee an audit outcome or replace the organization’s wider control evidence.
Create a traceable evidence index
- Requirement or control identifier and the assertion being supported.
- In-scope systems, interfaces, environments, identities and important exclusions.
- Assessment dates, methodology, tester identity or competence evidence and authorization.
- Finding identifiers, severity rationale, remediation owner, status and exception reference.
- Retest evidence, closure date, residual risk and the location of protected technical detail.
Include original scope and findings, included clarification hours, remediation workshops, response times, retest eligibility, number of cycles, submission format, environment and version, evidence prerequisites, variant sampling, positive tests, turnaround, closure deliverable, exclusions, expiry and additional rates.
Separate support from verification
Advice can help fix a weakness, while retest independently determines whether it is closed.
- Define clarification.
- Define remediation workshop.
- Define design review.
- Define technical retest.
- Protect independent conclusion.
Do not condition the retest result on the buyer following the vendor’s preferred implementation.
Define eligible retest scope
State whether every finding, only fixed findings or one consolidated submission is included.
- Reference finding IDs.
- Set submission rules.
- Cover root-cause variants.
- Define new findings treatment.
- Address changed architecture.
Materially new scope should use change control; nearby variants necessary to validate the root cause should not be excluded arbitrarily.
Set readiness and timing
A stable build and complete remediation context prevent wasted retest cycles.
- Require deployed version.
- Provide fix summary.
- Restore accounts and fixtures.
- Set booking notice.
- Define result turnaround.
Pause the clock for inaccessible prerequisites and record who owns rescheduling.
Specify closure deliverables
Buyers need evidence that maps directly to the original findings.
- Require per-finding status.
- State build and date.
- List tested conditions.
- Describe limitations.
- Provide signed closure statement.
Risk acceptance or internal QA evidence should remain separate from independent closure.
Price predictable exceptions
Pre-agreed rates reduce friction when a second fix or broader change needs work.
- Price extra cycle.
- Price new scope.
- State travel or tax.
- Define expired-window rates.
- Cap approval authority.
Show included value and optional rates separately in the commercial schedule.
Operate the evidence workflow
- Confirm the requirement, evidence owner, reviewer and deadline.
- Freeze a versioned scope and record every approved change or exclusion.
- Collect assessment artifacts through a controlled, access-limited repository.
- Map findings and closure evidence without changing the tester’s original conclusion.
- Perform a completeness and consistency review before external sharing.
Reserve a provisional retest window during planning, then confirm after remediation triage. Use one coordinator and finding register for questions, readiness and outcomes.
Preserve evidence integrity and confidentiality
Keep the original signed or versioned report, evidence manifest and retest artifacts. Redact copies rather than overwriting the source. Restrict exploit steps, credentials, personal data and internal architecture to approved recipients. Record who received which version, under what authorization and for what purpose.
Quality checks before reliance
- Scope, dates and environment agree across the report, statement of work and evidence index.
- Every closure claim points to a finding identifier and retest result.
- Exceptions name an owner, rationale, review date and compensating controls.
- Control mappings distinguish direct evidence from supporting context.
- Sanitized summaries do not imply broader coverage or stronger closure than the source report.
Use framework language carefully
Use the applicable official control text and assessor guidance as the authority. The NIST Technical Guide to Information Security Testing and Assessment supports disciplined assessment planning and reporting, while the OWASP Web Security Testing Guide provides application testing context. Neither substitutes for framework-specific interpretation by the responsible auditor or assessor.
Report the assurance conclusion
The contract and final engagement file should show included support used, retest submissions, cycles, results, extra approvals and closure artifacts.
State observed facts, limitations and management decisions separately. Do not use “compliant,” “certified,” “secure” or “all vulnerabilities fixed” unless the authorized assessor and evidence genuinely support that precise claim.
The GRC decision
The best commercial model makes independent closure easy to invoke and hard to misunderstand. Price enough support to remove ambiguity while keeping implementation ownership with the customer.
Ask WIMD for written retest terms with clear readiness, turnaround, evidence and closure deliverables.