Penetration Testing Retest Request Form Template trigger remediation verification on the same record the engagement opened on
A free, copy-ready penetration testing retest request form template. Eleven structured sections covering header and engagement references, parties and signing authority, the authorisation basis (inside the retest window, addendum, or fresh statement of work) and retest type (retest only, retest plus regression, delta retest), the findings in scope with original IDs and remediation summaries, the verification method per finding (reproduce, re-scan, code review, configuration review, hybrid), the access and credential plan, the deliverable expected and the disposition matrix for verified-fixed, partially fixed, not fixed, and regressed outcomes, the commercial basis and schedule, evidence handling and confidentiality, framework and regulatory references (PCI DSS 11.4, ISO 27001 8.8, SOC 2 CC4.1 and CC7.2, DORA Article 26, HIPAA, GDPR), and signature blocks. Pairs with the executed engagement letter, statement of work, rules of engagement, original report, and closure letter so the retest sits inside the existing authorisation chain rather than reopening it. Aligned with PTES, NIST SP 800-115, OWASP WSTG, and the CREST Defensible Penetration Test specification.
Run retests on the same record the engagement opened on
SecPortal pairs every retest to the original finding so the lineage from initial capture through fix to verified-fixed runs on one record. The retest request form lives alongside the engagement letter, SOW, ROE, original findings, evidence pack, final report, debrief deck, attestation letter, closure letter, credential handover form, rotation log, and (at the end of the retest) the retest report and any updated attestation. Free plan available.
No credit card required. Free plan available forever.
Full template
Copy the full retest request form template
Eleven structured sections. The form triggers the verification work that the executed closure letter authorised, runs against findings raised in the original pentest report, and pairs every retest result back to the original finding so the lineage stays intact. Replace every {{PLACEHOLDER}} before signing.
1. Header and engagement references
Opens with the form reference, the engagement reference, and the prior authorisation chain. Tying the request to the engagement letter, statement of work, rules of engagement, original report, and (where it exists) the closure letter that declared the retest window matters because the retest is happening under one of two authorisation bases: the original engagement letter inside the retest window, or a fresh statement of work or addendum if the window has lapsed.
PENETRATION TESTING RETEST REQUEST FORM
Form reference: {{RETEST_REQUEST_REFERENCE}}
Engagement reference: {{ENGAGEMENT_REFERENCE}}
Form execution date: {{EXECUTION_DATE}}
Retest window opens (verification work begins): {{RETEST_WINDOW_OPENS}} ({{TIMEZONE}})
Verification deadline (retest report due by): {{VERIFICATION_DEADLINE}}
This form requests a retest under the penetration testing engagement opened by:
- Engagement Letter reference: {{ENGAGEMENT_LETTER_REFERENCE}}, executed {{ENGAGEMENT_LETTER_DATE}}
- Statement of Work reference: {{SOW_REFERENCE}}, executed {{SOW_DATE}}
- Rules of Engagement reference: {{ROE_REFERENCE}}, executed {{ROE_DATE}}
- Master Services Agreement (where applicable): {{MSA_REFERENCE}}, executed {{MSA_DATE}}
- Final Report reference: {{REPORT_REFERENCE}}, delivered {{REPORT_DELIVERY_DATE}}
- Closure Letter reference (where executed): {{CLOSURE_LETTER_REFERENCE}}, executed {{CLOSURE_LETTER_DATE}}
The retest window declared on the closure letter (or, where no closure letter was executed, the retest window stated in Section {{SOW_RETEST_SECTION}} of the statement of work) runs from {{RETEST_WINDOW_DECLARED_OPEN}} to {{RETEST_WINDOW_DECLARED_CLOSE}}. This request is being made on {{EXECUTION_DATE}}, which is {{INSIDE_OR_OUTSIDE}} the declared window.
2. Parties and signing authority
Names the buyer raising the retest request and the testing firm receiving it. The signatory on the buyer side is the engagement sponsor or a delegated equal whose authority covers the systems being retested. The signatory on the testing party side is the engagement lead named in the original engagement letter, or a partner with equivalent authority where the engagement lead has rotated off.
Requesting Party (the Client):
- Legal entity: {{CLIENT_LEGAL_NAME}}
- Registered address: {{CLIENT_ADDRESS}}
- Requesting signatory: {{CLIENT_SIGNATORY_NAME}}, {{CLIENT_SIGNATORY_TITLE}}
- Signing authority basis: {{CLIENT_SIGNING_AUTHORITY_BASIS}}
- Email: {{CLIENT_SIGNATORY_EMAIL}}
- Operational contact for the retest: {{CLIENT_OPERATIONAL_CONTACT_NAME}}, {{CLIENT_OPERATIONAL_CONTACT_EMAIL}}, {{CLIENT_OPERATIONAL_CONTACT_PHONE}}
Receiving Party (the Vendor):
- Legal entity: {{TESTING_FIRM_LEGAL_NAME}}
- Registered address: {{TESTING_FIRM_ADDRESS}}
- Receiving signatory: {{TESTING_PARTY_SIGNATORY_NAME}}, {{TESTING_PARTY_SIGNATORY_TITLE}}
- Email: {{TESTING_PARTY_SIGNATORY_EMAIL}}
- Engagement lead for the retest: {{ENGAGEMENT_LEAD_NAME}}, {{ENGAGEMENT_LEAD_EMAIL}}
- Data protection contact (where applicable): {{TESTING_PARTY_DPO_NAME}}, {{TESTING_PARTY_DPO_EMAIL}}
Signing authority confirmation: the requesting signatory confirms that the authority to retest the systems listed in Section 4 sits with this signatory or a named delegate, and that this authority is the same authority that authorised the original engagement (or, where the original signing party has rotated, that the new signatory holds equivalent authority and a brief delegation note is attached).
3. Authorisation basis and retest type
Names the authorisation under which the retest happens and which type of retest is being requested. The three retest types differ in scope, deliverable, and price; naming the type up front prevents the retest from being scoped on the wrong basis.
Authorisation basis (tick one):
- [ ] Inside the retest window declared by the closure letter or SOW. The retest runs under the original engagement letter, no fresh SOW required.
- [ ] Outside the retest window, but the buyer requests retest under a new addendum to the original engagement letter. Addendum reference: {{ADDENDUM_REFERENCE}}.
- [ ] Outside the retest window, fresh statement of work required. Fresh SOW reference: {{FRESH_SOW_REFERENCE}}.
Where neither of the above is yet executed, the retest cannot start. This form is contingent on the executed authorisation; the dates above must be filled before the retest scope in Section 4 is treated as authorised.
Retest type (tick one):
- [ ] Retest only: verify previously reported findings have been remediated. No regression scope, no fresh discovery scope.
- [ ] Retest plus regression scope: verify the fixes and check for new exploit paths the fix may have introduced on the same or paired findings.
- [ ] Delta retest: a focused fresh engagement that retests only the assets or routes that have changed since the last full test (NOT covered by the original engagement letter; needs a fresh SOW even if inside the original retest window).
For delta retests, this form is a marker for the request only; the delta retest itself runs under its own engagement record with its own kickoff, ROE, test plan, and report.
4. Findings in scope of the retest
The exhaustive list of findings the buyer is asking the testing party to retest, with the original finding identifier, severity, and the remediation summary. One finding per row. The remediation summary is the buyer side input that lets the testing party plan the verification method on a per-finding basis.
For every finding requested for retest, complete one row. Add additional rows as needed.
FINDING ROW {{ROW_NUMBER}}:
- Original finding ID: {{ORIGINAL_FINDING_ID}}
- Original finding title: {{ORIGINAL_FINDING_TITLE}}
- Original severity: {{ORIGINAL_SEVERITY}} (Critical / High / Medium / Low / Informational)
- Original CVSS vector (where applicable): {{ORIGINAL_CVSS_VECTOR}}
- Affected asset, URL, route, repository, or configuration scope: {{AFFECTED_ASSET}}
- Environment in which remediation was applied: {{REMEDIATION_ENVIRONMENT}} (production / staging / dedicated test tenant / isolated VPC)
- Remediation summary (what was changed): {{REMEDIATION_SUMMARY}}
- Remediation date or change reference (commit SHA, change ticket, configuration change ID): {{REMEDIATION_REFERENCE}}
- Operator on the buyer side who implemented the fix: {{REMEDIATION_OPERATOR}}
- Risk acceptance status (if a finding is being retest-confirmed despite a partial fix): {{RISK_ACCEPTANCE_REFERENCE}}
- Any pre-retest evidence the buyer attaches (screenshot, request response, configuration export): {{PRE_RETEST_EVIDENCE}}
Findings excluded from this retest (findings the buyer explicitly asks the testing party not to retest, with the reason):
- {{EXCLUDED_FINDINGS}}
Where the original report listed informational observations rather than findings, those are out of scope of this retest unless the buyer adds them as explicit rows above. Informational observations are not normally retested.
5. Verification method per finding
The verification method per finding determines what evidence the testing party will produce. Picking the right method is what separates a retest that catches partial fixes from one that signs off on a fix that does not actually close the exploit. The form is the place where the buyer and the testing party agree on the method before the retest starts so there is no debate at delivery.
For each finding row in Section 4, indicate the requested verification method. The testing party may propose a stronger method during scoping; this section captures the buyer ask.
VERIFICATION METHOD MATRIX:
- Reproduce the original attack path: {{REPRODUCE_ATTACK_PATH}} (Y/N) - the strongest verification, recommended for findings that exploited a vulnerability rather than a configuration drift.
- Re-scan the previously affected route or asset: {{RESCAN_ROUTE}} (Y/N) - appropriate where the original finding was surfaced by an automated scanner and the fix should be visible to the same scanner profile.
- Review the code change in the repository: {{CODE_REVIEW}} (Y/N) - appropriate where the fix was a code patch and the testing party can validate the patch covers the exploit path.
- Review the configuration change: {{CONFIG_REVIEW}} (Y/N) - appropriate where the fix was a configuration update and the testing party can validate the configuration matches the remediation guidance.
- Hybrid (combine two or more of the above): {{HYBRID_METHOD}} - specify combination, for example "reproduce plus scan" or "code review plus reproduce".
For each row, the buyer commits to providing the inputs the verification method needs:
- For reproduce: a usable test environment matching the production fix, plus the credentials and access listed in Section 6.
- For re-scan: the scan profile or scope used in the original engagement, or an equivalent permission to scan the same route.
- For code review: read access to the repository and the commit reference for the fix.
- For configuration review: read access to the relevant cloud or platform console, or an export of the relevant configuration.
Where the buyer cannot provide the inputs the chosen method requires, the testing party will recommend an alternative method or note the verification limit explicitly in the retest report.
6. Access, credentials, and environment
Records the access plan for the retest. Where the original engagement issued credentials, the form restates whether those credentials are still active or whether new credentials need to be issued. Where the retest needs an environment that did not exist during the original engagement (a dedicated retest tenant, a staging slot mirroring production), that environment is named here.
Environment for the retest:
- Primary environment: {{PRIMARY_RETEST_ENVIRONMENT}} (production / staging / dedicated retest tenant / isolated VPC)
- Pairing to original test environment: {{ENVIRONMENT_PAIRING}} (same as original / different from original; if different, the difference is noted)
- Window for the retest (operational change windows, regulator windows, customer maintenance windows): {{RETEST_WINDOW_HOURS}}
Credentials and access for the retest (tick all that apply):
- [ ] Original credentials issued under the credential handover form are still active and may be reused. Credential handover form reference: {{CREDENTIAL_HANDOVER_REFERENCE}}.
- [ ] Original credentials were rotated at engagement close. Fresh credential handover form is being executed for the retest: {{NEW_CREDENTIAL_HANDOVER_REFERENCE}}.
- [ ] No credentials needed (retest of an unauthenticated finding, configuration review, code review).
- [ ] VPN or jump-host access required: {{VPN_ACCESS_DETAILS}}.
- [ ] Repository read access required: {{REPO_ACCESS_DETAILS}}.
- [ ] Cloud or platform console read access required: {{CLOUD_ACCESS_DETAILS}}.
- [ ] Source IP allowlist or scanner allowlist refresh required: {{ALLOWLIST_DETAILS}}.
Domain verification refresh (where any retest target is a domain that was previously verified for the original engagement):
- Verification status: {{DOMAIN_VERIFICATION_STATUS}} (still verified / re-verification required)
- Re-verification method (where required): {{DOMAIN_REVERIFICATION_METHOD}} (DNS TXT, meta tag)
7. Verification deliverable and disposition
Names the deliverable expected at the end of the retest and how each possible verification outcome will be recorded against the original finding. Pre-agreeing on disposition prevents partial fixes and regressions from becoming the source of disputes between buyer and testing party at retest delivery.
Deliverable expected (tick all that apply):
- [ ] Retest report (mandatory): per-finding verification result with evidence, paired to the original finding ID.
- [ ] Updated attestation letter naming the verified-fixed findings (optional, often requested when the buyer needs to share verification with their own customers or auditors). Attestation letter scope: {{ATTESTATION_SCOPE}}.
- [ ] Regression annex (where the retest type in Section 3 includes regression scope): the annex lists any new findings paired to the original via the regression lineage.
- [ ] Updated findings register on the engagement record: status of each retested finding flipped from Open to Verified Fixed, Partially Fixed, Not Fixed, or Regressed.
- [ ] Branded client portal update so the buyer audit trail surfaces the retest result on the same record as the original finding.
Disposition matrix (how each verification outcome is recorded; this is pre-agreed to prevent litigation at delivery):
- Verified Fixed: original finding closed with a verified-fixed status. Verification evidence (request response, screenshot, configuration export, scan output) is attached to the original finding record. The aging clock for the finding stops at the verified-fixed date.
- Partially Fixed: original finding remains open with a partial-fix annotation. The retest report names what changed and what remains exploitable. The aging clock keeps running on the original capture date. A partial fix is not a verified fix and the buyer should not present it as such to auditors.
- Not Fixed: original finding remains open with a not-fixed annotation. The retest report names why the proposed remediation did not change the exploit path. The aging clock keeps running on the original capture date.
- Regressed: original finding remains open and a new finding is opened paired to the original via the regression lineage. The new finding has its own severity, CVSS vector, and evidence; the lineage link makes the relationship to the original finding explicit. The aging clock for the new finding starts at the regression date; the aging clock for the original finding keeps running on the original capture date.
Where the buyer asks for a verification result the testing party cannot evidence (a verified-fixed claim where the inputs in Section 5 were not provided, an unaudited risk acceptance), the testing party will record the verification limit on the retest report and decline to issue an unsupported claim.
8. Commercial impact and schedule
Records the commercial basis on which the retest is being run and the schedule for the verification work. Inside the retest window, retests are typically free at the point of use under the original engagement letter. Outside the window or for delta retests, the form names the price basis and the invoice reference.
Commercial basis (tick one):
- [ ] Inside the retest window, no fresh fee. The retest count remaining under the original engagement letter is: {{RETEST_COUNT_REMAINING}}.
- [ ] Inside the retest window but the retest scope exceeds the contractual retest count. Excess retest fee: {{EXCESS_RETEST_FEE}} {{CURRENCY}} per finding (or per day, whichever the SOW specifies).
- [ ] Outside the retest window, addendum or fresh SOW basis. Fee: {{ADDENDUM_OR_SOW_FEE}} {{CURRENCY}}, basis: {{FEE_BASIS}} (fixed, time and materials, day rate).
Invoice and payment terms:
- Invoice reference: {{INVOICE_REFERENCE}}
- Invoice raised against: {{INVOICE_RAISED_AGAINST}} (engagement record, separate retest record)
- Payment terms: {{PAYMENT_TERMS}}
Schedule:
- Buyer ready date (the earliest date the buyer side can have remediation evidence and access ready): {{BUYER_READY_DATE}}
- Testing party start date (the earliest date the testing party can begin the verification work): {{TESTING_PARTY_START_DATE}}
- Verification target date: {{VERIFICATION_TARGET_DATE}}
- Retest report delivery date: {{RETEST_REPORT_DELIVERY_DATE}}
- Updated attestation letter delivery (where requested): {{ATTESTATION_DELIVERY_DATE}}
Schedule slips: where either side cannot meet the dates above, written notice is given on the engagement record before the deadline and a revised schedule is agreed. Slips that are not recorded turn into disputes about whether the retest happened inside the window.
9. Evidence handling and confidentiality
Records the evidence retention and confidentiality posture for the retest. The retest produces fresh evidence (request and response captures, screenshots, configuration exports, code review notes) that pairs to the original finding. The retention plan inherits from the original engagement evidence retention plan rather than restating it.
Evidence handling for the retest:
- Retest evidence is stored on the engagement record alongside the original finding.
- Retest evidence inherits the retention period agreed in the original engagement letter or closure letter: {{ORIGINAL_RETENTION_PERIOD}}.
- Where the retention period had elapsed before this retest started, the retest restarts the retention clock for the affected findings only.
- Encryption at rest: {{ENCRYPTION_AT_REST_DETAILS}}
- Encryption in transit: {{ENCRYPTION_IN_TRANSIT_DETAILS}}
- Access control on the retest evidence: {{RETEST_EVIDENCE_ACCESS_CONTROL}}
Confidentiality and out-of-band copies:
- The retest produces no out-of-band copies. Evidence sits on the engagement record only.
- Where the buyer requests an export (a PDF report, an evidence pack), the export is a controlled artefact tracked on the engagement record.
Personal data handled during the retest (where applicable):
- Categories of personal data the retest will incidentally process: {{PERSONAL_DATA_CATEGORIES}}
- Lawful basis: {{LAWFUL_BASIS}}
- Data Processing Addendum reference (under the master services agreement): {{DPA_REFERENCE}}
Stop conditions during the retest (the retest halts on the same triggers that would halt the original engagement):
- Production incident attributable to the retest activity
- Credential leak suspected or confirmed during the retest
- Scope-out asset accessed unintentionally
- Regulator instruction
- Buyer-instructed halt in writing
Where any stop condition is triggered, the testing party stops the retest, raises a stop-test letter against the engagement, and resumes only on a signed resume notice.
10. Framework and regulatory references
Cites the relevant framework controls or regulatory articles where the engagement is regulated or scheme-tested. Trim the list to what actually applies; citing every framework on every form is noise. The point is to give the auditor a direct mapping from the retest event to the framework.
Where the retest is regulated, this form cites the following controls or articles. Delete those that do not apply.
PCI DSS v4.0:
- 11.4.2 Internal penetration testing remediation verification
- 11.4.4 External penetration testing remediation verification
- 11.4.5 Segmentation control remediation verification
- 6.3.1 Security vulnerability identification and remediation processes
ISO/IEC 27001:2022 Annex A:
- 8.8 Management of technical vulnerabilities
- 5.27 Learning from information security incidents
SOC 2 Trust Services Criteria:
- CC4.1 Monitoring controls and remediation tracking
- CC7.1 Detection and identification of security events
- CC7.2 Response to security incidents
HIPAA Security Rule (US healthcare engagements only):
- 45 CFR 164.308(a)(1)(ii)(B) Risk management
UK GDPR / EU GDPR:
- Article 32 Security of processing (technical measures)
DORA (EU financial services TLPT engagements):
- Article 26 Threat-led penetration testing
- Article 27 Requirements for testers
- EBA Guidelines on ICT and security risk management, post-test remediation verification
Penetration testing methodology references:
- PTES Section 7 (Reporting), retest scope
- NIST SP 800-115 Section 6 (Post-Testing Activities), remediation verification
- OWASP WSTG retest expectations
- CREST Defensible Penetration Test specification, retest scope and verification
Pentest scheme references where applicable:
- CHECK retest expectations
- CREST OVS, CREST STAR, CREST GBEST retest expectations
- TIBER-EU remediation testing
- FedRAMP penetration test retest expectations
11. Signatures and effective date
Signature blocks for the requesting party and the receiving party. The form is effective from the latest signature date; the retest is not authorised until the form is executed and the authorisation basis in Section 3 is in place.
Signed for the Requesting Party (the Client):
Name: {{CLIENT_SIGNATORY_NAME}}
Title: {{CLIENT_SIGNATORY_TITLE}}
Signature: ____________________________
Date: ________________________________
Signed for the Receiving Party (the Vendor):
Name: {{TESTING_PARTY_SIGNATORY_NAME}}
Title: {{TESTING_PARTY_SIGNATORY_TITLE}}
Signature: ____________________________
Date: ________________________________
This form is effective on the latest of the signature dates above. The retest is authorised from that date and runs against the findings listed in Section 4 under the authorisation basis named in Section 3. The signed form is filed alongside the Engagement Letter, Statement of Work, Rules of Engagement, Test Plan, original Findings, Evidence Pack, original Final Report, Debrief Deck, original Attestation Letter, Closure Letter, Credential Handover Form, Rotation Log, and (at the end of the retest) the Retest Report and any updated Attestation Letter or Regression Annex, so the verification trail preserves on the engagement record from original capture through verified-fixed.
How to use this template
Confirm the authorisation basis in Section 3 before listing findings. A retest inside the window runs under the original engagement letter; outside the window needs an addendum or a fresh statement of work first. Listing findings before the authorisation is in place is the most common reason a retest stalls at the testing party side.
Pick the right retest type in Section 3. Retest only verifies fixes. Retest plus regression also looks for new exploit paths the fix may have introduced. Delta retests are fresh engagements that need their own kickoff, not a single retest request form.
One finding per row in Section 4 with the original finding ID. Reusing one row for multiple findings breaks the per-finding pairing in the retest report and is the most common cause of disputes at delivery.
Match the verification method in Section 5 to what the fix actually changed. Reproduce the original attack path is the strongest verification for vulnerabilities that were exploited. Re-scan is appropriate for findings surfaced by automated scanners. Code review is appropriate for code patches. Configuration review is appropriate for cloud or platform configuration changes. Hybrid is appropriate when one method alone is insufficient.
Section 6 names the access plan. Where original credentials were rotated at engagement close, a fresh credential handover form is needed. Where domain verification has lapsed, re-verification happens before the retest starts.
Section 7 pre-agrees on disposition. Verified Fixed, Partially Fixed, Not Fixed, and Regressed each have a defined record disposition. Pre-agreement prevents litigation when a retest produces a partial fix or a regression.
Section 8 names the commercial basis. Inside the retest window, the retest is usually free at the point of use under the original engagement letter (subject to the contractual retest count). Outside the window, the form pairs to a fresh SOW or addendum.
Section 9 inherits the evidence retention plan from the original engagement. Where retention had elapsed for the affected findings, the retest restarts the retention clock for those findings only.
Trim Section 10 to the framework or regulator that actually applies. Citing every framework on every form is noise; citing the relevant control or article gives the auditor a direct mapping from the retest event to the framework.
Both parties sign in Section 11. The retest is not authorised until the form is executed and the authorisation basis in Section 3 is in place.
File the signed form alongside the engagement record (RFP, proposal, SOW, ROE, engagement letter, test plan, original findings, evidence pack, draft report, debrief deck, final report, attestation letter, closure letter, credential handover form, rotation log) so the chain runs from RFP through verified-fixed without breaks.
Methodology and scheme references
PTES Section 7 (Reporting) and the CREST Defensible Penetration Test specification both treat retest verification as part of the engagement record. See the SecPortal CREST penetration testing framework page.
NIST SP 800-115 Section 6 (Post-Testing Activities) covers remediation verification and the retest record. See the SecPortal NIST SP 800-115 framework page.
OWASP WSTG retest expectations and OWASP ASVS verification levels both inform how a retest report frames the verification result. See the SecPortal OWASP framework page and OWASP ASVS framework page.
For PCI DSS v4.0 Requirements 11.4.2 and 11.4.4 (penetration test remediation verification), see the SecPortal PCI DSS framework page.
For ISO 27001:2022 Annex A control 8.8 (Management of technical vulnerabilities) walkthrough, see the SecPortal ISO 27001 framework page.
For SOC 2 Common Criteria CC4.1 and CC7.2 (monitoring controls and incident response), see the SecPortal SOC 2 framework page.
The full paper trail for a regulated penetration testing engagement runs RFP, proposal, SOW, ROE, engagement letter, test plan, kickoff, credential handover, active testing, draft report, debrief deck, final report, attestation letter, closure letter (declaring the retest window), retest request (this form), retest report, updated attestation letter, rotation log, and (at the end of the retention window) the evidence destruction certificate. The retest request form is the trigger that opens the verification work inside the window the closure letter declared, or under the addendum or fresh SOW that authorises a retest after the window has lapsed.
For the retest workflow this form triggers, see the pentest retesting use case.
For the closure letter that declared the retest window this form is operating inside, see the pentest closure letter template.
For the remediation tracking workflow that produced the fix evidence the buyer attaches in Section 4, see the remediation tracking use case.
This template is provided as a starting point for a penetration testing retest request form. It is not legal advice. Have the final form reviewed by counsel and aligned with the master services agreement, statement of work, rules of engagement, engagement letter, and closure letter that govern the broader relationship and the retest authorisation.