Penetration Testing Evidence Destruction Certificate Template close out the long tail of retained engagement evidence
A free, copy-ready penetration testing evidence destruction certificate template. Nine structured sections covering header and engagement references, parties, retention window and basis for destruction, the artefact inventory in scope of the destruction, destruction method per category (cryptographic erasure, secure overwrite, physical destruction, processor token revocation, anonymisation), anonymised artefacts retained for internal training, third-party processors and residual lapse dates, framework and regulatory references (ISO 27001, SOC 2, PCI DSS, GDPR, HIPAA, DORA, TIBER-EU), and signature blocks. Pairs with the executed closure letter, rules of engagement, and engagement letter so the destruction inherits the retention plan rather than restating it. Aligned with PTES, NIST SP 800-115, NIST SP 800-88, and the CREST Defensible Penetration Test specification.
Close the retention loop on the same record the engagement opened on
SecPortal stores the destruction certificate alongside the engagement letter, SOW, ROE, findings, evidence pack, final report, debrief deck, attestation letter, and closure letter. One audit trail from RFP through to evidence destruction. Free plan available.
No credit card required. Free plan available forever.
Full template
Copy the full evidence destruction certificate template
Nine structured sections. The destruction discharges the retention obligation recorded in the executed closure letter, the rules of engagement, and the underlying engagement letter. Replace every {{PLACEHOLDER}} before signing.
1. Header and engagement references
The certificate opens with its own reference, the engagement reference, and the prior authorisation chain. The chain matters because the destruction discharges an obligation recorded in the closure letter, not a fresh decision. PTES Section 7 (Reporting), NIST SP 800-115 (closeout), and the CREST Defensible Penetration Test specification all assume a documented destruction event sitting on the same chain as the closure.
PENETRATION TESTING EVIDENCE DESTRUCTION CERTIFICATE
Certificate reference: {{DESTRUCTION_CERTIFICATE_REFERENCE}}
Engagement reference: {{ENGAGEMENT_REFERENCE}}
Certificate execution date: {{EXECUTION_DATE}}
Certificate effective date (destruction completion): {{DESTRUCTION_DATE}} {{DESTRUCTION_TIME}} ({{TIMEZONE}})
This certificate evidences the destruction or anonymisation of artefacts captured during 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}}
- Closure Letter reference: {{CLOSURE_LETTER_REFERENCE}}, executed {{CLOSURE_LETTER_DATE}}
This certificate executes the evidence retention and destruction plan recorded in the Closure Letter referenced above. The Engagement Letter authorisation lapsed on the closure date stated above; this certificate confirms that the evidence retention obligations recorded in Section 7 of the closure letter have been discharged in full.
2. Parties
Names the testing firm executing the destruction and the buyer to whom the certificate is delivered. The signatory on the testing party side is the engagement lead, the data protection officer, or a partner with equivalent authority. The buyer counter-signature is optional and depends on the contract.
Testing Party (the Vendor):
- Legal entity: {{TESTING_FIRM_LEGAL_NAME}}
- Registered address: {{TESTING_FIRM_ADDRESS}}
- Signatory for the destruction: {{TESTING_PARTY_SIGNATORY_NAME}}, {{TESTING_PARTY_SIGNATORY_TITLE}}
- Email: {{TESTING_PARTY_SIGNATORY_EMAIL}}
- Data protection officer (where applicable): {{TESTING_PARTY_DPO_NAME}}, {{TESTING_PARTY_DPO_EMAIL}}
Authorising Party (the Client):
- Legal entity: {{CLIENT_LEGAL_NAME}}
- Registered address: {{CLIENT_ADDRESS}}
- Recipient representative: {{CLIENT_RECIPIENT_NAME}}, {{CLIENT_RECIPIENT_TITLE}}
- Email: {{CLIENT_RECIPIENT_EMAIL}}
Counter-signature is required where the contract states it; otherwise the certificate is delivered to the recipient representative as evidence of destruction without a buyer signature.
3. Retention window and basis for destruction
Records the date the retention window opened, the date it lapsed, and the contractual or regulatory basis for destroying the evidence at this point. Tying the destruction to the basis prevents disputes later about whether the destruction was premature or overdue.
Retention window:
- Window opened on: {{RETENTION_START_DATE}} (typically the closure letter date or the date of remediation closure).
- Window lapsed on: {{RETENTION_END_DATE}}.
- Retention duration: {{RETENTION_DURATION}} days/months.
Basis for the retention duration (delete those that do not apply):
- Statement of Work clause: {{SOW_RETENTION_CLAUSE_REFERENCE}}.
- Master Services Agreement clause: {{MSA_RETENTION_CLAUSE_REFERENCE}}.
- Closure Letter Section 7 (evidence retention plan): {{CLOSURE_LETTER_SECTION_7_REFERENCE}}.
- Buyer-instructed early destruction request: {{BUYER_EARLY_DESTRUCTION_REQUEST_REFERENCE}}.
- Regulator or scheme instruction: {{REGULATOR_INSTRUCTION_REFERENCE}}.
- Termination event under the SOW or MSA: {{TERMINATION_EVENT_REFERENCE}}.
Trigger for executing the destruction at this date:
- Routine end-of-window destruction in line with the Closure Letter retention plan.
- Buyer-requested early destruction.
- Regulator-instructed destruction.
- Termination event under the SOW or MSA that ends the lawful basis for retention.
Where the destruction is executed before the routine end of the retention window, the supporting written instruction from the buyer or the regulator is retained on the engagement record and referenced above.
4. Inventory of artefacts in scope of the destruction
The exhaustive list of artefact categories captured during the engagement and now in scope of destruction. The list is categorical so a reviewer can see that no class of evidence has been omitted; engagement-specific volumes are recorded in approximate counts rather than exhaustive line items.
Artefact categories captured during the engagement and in scope of destruction:
Screenshots, screen recordings, and visual evidence:
- Approximate count: {{SCREENSHOT_COUNT}}.
- Storage location: {{SCREENSHOT_STORAGE_LOCATION}}.
Request and response captures (Burp Suite project files, mitmproxy captures, raw HTTP transcripts, GraphQL inspector exports):
- Approximate count: {{REQUEST_RESPONSE_COUNT}}.
- Storage location: {{REQUEST_RESPONSE_STORAGE_LOCATION}}.
Exploitation proofs of concept (working exploits, payload sequences, recovered credentials, recovered sessions, stolen tokens, lateral movement scripts):
- Approximate count: {{EXPLOIT_POC_COUNT}}.
- Storage location: {{EXPLOIT_POC_STORAGE_LOCATION}}.
Command output and shell histories (live terminal output, captured shell sessions, command logs):
- Approximate count: {{COMMAND_OUTPUT_COUNT}}.
- Storage location: {{COMMAND_OUTPUT_STORAGE_LOCATION}}.
Network captures (packet captures, DNS resolution logs, port scan output, traceroute output):
- Approximate count: {{NETWORK_CAPTURE_COUNT}}.
- Storage location: {{NETWORK_CAPTURE_STORAGE_LOCATION}}.
Exported scanner reports (Nessus .nessus exports, Burp Suite XML/JSON exports, SAST output in SARIF, SCA output, IaC scanner output):
- Approximate count: {{SCANNER_EXPORT_COUNT}}.
- Storage location: {{SCANNER_EXPORT_STORAGE_LOCATION}}.
Working notes (markdown files, mind maps, whiteboards photographed during the engagement, audio recordings of internal discussions):
- Approximate count: {{WORKING_NOTES_COUNT}}.
- Storage location: {{WORKING_NOTES_STORAGE_LOCATION}}.
Draft and final report files (engagement-specific draft, final, attestation, debrief deck artefacts):
- Approximate count: {{REPORT_FILE_COUNT}}.
- Storage location: {{REPORT_FILE_STORAGE_LOCATION}}.
Client data harvested in the course of testing (database extracts, file shares accessed, internal documents enumerated, mailbox contents, signed cookies, source code excerpts):
- Approximate count: {{CLIENT_DATA_COUNT}}.
- Storage location: {{CLIENT_DATA_STORAGE_LOCATION}}.
Other (named): {{OTHER_ARTEFACT_CATEGORY}}.
Categories not in scope of this certificate (delete where not applicable):
- Anonymised artefacts retained for internal training under Section 6 of this certificate.
- Artefacts retained beyond this certificate under a separate retention obligation: {{SEPARATE_RETENTION_REFERENCE}}.
- Artefacts already destroyed under the rules of engagement (operationally sensitive credentials, tokens, working exploits destroyed at engagement closure): see the Rules of Engagement reference in Section 1.
5. Destruction method per artefact category
The technical method by which each artefact category was destroyed. The method varies by storage medium: cryptographic erasure for full disk volumes, secure overwrite for filesystem objects, physical destruction for removable media, and token revocation for cloud locations the testing party no longer controls. Naming the method per category prevents the certificate from collapsing into a generic "all evidence destroyed" claim that an auditor cannot verify.
Destruction methods executed against the artefact categories in Section 4:
Method A: Cryptographic erasure
- Applied to: full-disk encrypted volumes containing engagement evidence (typically working laptops, dedicated engagement workstations, encrypted external drives).
- Mechanism: the volume encryption key is destroyed, rendering the entire volume unrecoverable. Confirmed by attempting to mount the volume after key destruction.
- Verification: post-destruction mount attempt fails with the expected unrecoverable-key error.
Method B: Secure overwrite
- Applied to: filesystem objects on shared storage, archive locations, and any volume not subject to full-disk cryptographic erasure.
- Mechanism: secure overwrite per the testing party's data destruction policy (single-pass NIST SP 800-88 clear, or multi-pass NIST SP 800-88 purge for higher-sensitivity media).
- Verification: post-overwrite read attempt returns the overwrite pattern rather than the original content.
Method C: Physical destruction
- Applied to: removable media (USB drives, optical media, external drives) and any device that cannot be reliably overwritten.
- Mechanism: physical destruction per the testing party's data destruction policy (shredding to ISO/IEC 21964 H-5 or equivalent, or degaussing for magnetic media followed by physical destruction).
- Verification: destruction is photographed and the photograph is retained against the engagement record.
Method D: Cloud token revocation and processor deletion request
- Applied to: artefacts held by third-party cloud processors (cloud storage buckets, email mailboxes, ticketing systems, chat platforms, SaaS engagement platforms).
- Mechanism: the testing party's access tokens are revoked, the artefacts are deleted from the processor under the terms of the testing party's contract with the processor, and a processor confirmation is retained where the processor offers one.
- Verification: post-deletion access attempt returns the expected not-found response; processor confirmations are referenced in Section 7.
Method E: Anonymisation (where artefacts are retained for internal training under Section 6)
- Applied to: a defined subset of artefacts retained for the testing party's internal training, methodology development, or case studies subject to the buyer's prior consent.
- Mechanism: redaction of personal data, secrets, client-identifying details, and operationally sensitive technical content. Replacement of identifiable values with hashes or synthetic equivalents.
- Verification: redaction is reviewed by the named reviewer in Section 6 and a redaction record is retained against the engagement.
Mapping methods to categories:
- Screenshots, screen recordings, visual evidence: {{SCREENSHOT_DESTRUCTION_METHOD}}.
- Request and response captures: {{REQUEST_RESPONSE_DESTRUCTION_METHOD}}.
- Exploitation proofs of concept: {{EXPLOIT_POC_DESTRUCTION_METHOD}}.
- Command output and shell histories: {{COMMAND_OUTPUT_DESTRUCTION_METHOD}}.
- Network captures: {{NETWORK_CAPTURE_DESTRUCTION_METHOD}}.
- Exported scanner reports: {{SCANNER_EXPORT_DESTRUCTION_METHOD}}.
- Working notes: {{WORKING_NOTES_DESTRUCTION_METHOD}}.
- Draft and final report files: {{REPORT_FILE_DESTRUCTION_METHOD}}.
- Client data harvested during testing: {{CLIENT_DATA_DESTRUCTION_METHOD}}.
Operator and reviewer:
- Destruction operator: {{DESTRUCTION_OPERATOR_NAME}}, {{DESTRUCTION_OPERATOR_TITLE}}.
- Destruction reviewer or witness: {{DESTRUCTION_REVIEWER_NAME}}, {{DESTRUCTION_REVIEWER_TITLE}}.
Where the testing party retains anonymised artefacts for internal training, methodology development, or case studies, this section names the retained artefacts, the redaction method, and the reviewer who confirmed the redaction. Conflating anonymisation with destruction is a common audit finding; treating the two events as distinct keeps the certificate defensible.
Anonymised artefacts retained by the Testing Party (delete this section if no anonymised artefacts are retained):
Basis for retention:
- The retention is permitted under the SOW or MSA clause: {{ANONYMISED_RETENTION_CLAUSE_REFERENCE}}.
- The buyer has provided written consent to the retention of anonymised artefacts: {{BUYER_CONSENT_REFERENCE}}.
- The retention is for the testing party's internal training, methodology development, or anonymised case studies; no client-identifying detail or personal data remains.
Inventory of anonymised artefacts retained:
- Description: {{ANONYMISED_ARTEFACT_DESCRIPTION}}.
- Approximate count: {{ANONYMISED_ARTEFACT_COUNT}}.
- Storage location after redaction: {{ANONYMISED_ARTEFACT_STORAGE_LOCATION}}.
- Retention end date for the anonymised set: {{ANONYMISED_RETENTION_END_DATE}} (after which the anonymised set is also destroyed).
Redaction method:
- Personal data removed or replaced: {{PERSONAL_DATA_REDACTION_METHOD}}.
- Secrets, credentials, and tokens removed: {{SECRETS_REDACTION_METHOD}}.
- Client-identifying details removed (legal entity, brand name, internal hostnames, asset references): {{CLIENT_IDENTIFIER_REDACTION_METHOD}}.
- Operationally sensitive technical content reviewed for residual identifiability: {{TECHNICAL_CONTENT_REVIEW_METHOD}}.
Redaction reviewer:
- Reviewer: {{REDACTION_REVIEWER_NAME}}, {{REDACTION_REVIEWER_TITLE}}.
- Review date: {{REDACTION_REVIEW_DATE}}.
- Redaction record reference: {{REDACTION_RECORD_REFERENCE}}.
Anonymised artefacts that fail review are removed from the retention set and destroyed under the methods in Section 5.
7. Third-party processors and residual lapse dates
Third-party processors that held a copy of the evidence (cloud storage, email, ticketing, chat, SaaS platforms) must be named alongside their confirmations of removal and any residual retention windows outside the testing party's direct control. Without this section a destruction certificate cannot evidence "destroyed everywhere"; it can only evidence "destroyed on the testing party's record".
Third-party processors that held copies of engagement evidence:
Processor inventory (delete those that do not apply):
- Cloud storage: {{CLOUD_STORAGE_PROCESSOR}} ({{CLOUD_STORAGE_PURPOSE}}).
- Email provider: {{EMAIL_PROCESSOR}} ({{EMAIL_PURPOSE}}).
- Ticketing or workflow platform: {{TICKETING_PROCESSOR}} ({{TICKETING_PURPOSE}}).
- Chat or messaging platform: {{CHAT_PROCESSOR}} ({{CHAT_PURPOSE}}).
- SaaS engagement platform: {{ENGAGEMENT_PLATFORM_PROCESSOR}} ({{ENGAGEMENT_PLATFORM_PURPOSE}}).
- Source code review tooling: {{CODE_REVIEW_PROCESSOR}} ({{CODE_REVIEW_PURPOSE}}).
- Other processor: {{OTHER_PROCESSOR_NAME}} ({{OTHER_PROCESSOR_PURPOSE}}).
Per-processor destruction confirmation:
- Access revocation date: {{PROCESSOR_ACCESS_REVOCATION_DATE}}.
- Deletion request date: {{PROCESSOR_DELETION_REQUEST_DATE}}.
- Processor confirmation of deletion (where the processor provides one): {{PROCESSOR_DELETION_CONFIRMATION_REFERENCE}}.
- Residual retention window in the processor (backup tier, point-in-time recovery, audit log retention): {{PROCESSOR_RESIDUAL_WINDOW}}.
- Date the residual retention window lapses on the processor: {{PROCESSOR_RESIDUAL_LAPSE_DATE}}.
The Testing Party confirms that no copy of the evidence remains under the Testing Party's direct control after the destruction date in Section 1. Where named processors retain residual copies in backup tiers or point-in-time recovery windows that the Testing Party cannot delete directly, those residual copies will lapse on the dates stated above and are subject to the named processor's data destruction policy thereafter.
8. Framework and regulatory references
Cites the controls or articles that govern the destruction obligation. The auditor reads the certificate against the framework; explicit references give the auditor a direct mapping rather than requiring them to derive it. Trim the list to the frameworks actually applicable to the engagement.
Framework and regulatory references applicable to this destruction event (delete those that do not apply):
ISO 27001 Annex A:
- A.8.10 Information deletion: information held in information systems is deleted when no longer required.
- A.7.10 Storage media: media containing information is managed through its lifecycle including secure disposal.
- A.8.12 Data leakage prevention: measures applied to systems, networks, and devices that handle sensitive information.
SOC 2 Common Criteria:
- CC6.5: data and software is removed from devices when no longer required.
- CC1.4 / CC2.2: integrity of the controls protecting the destruction event.
PCI DSS (where the engagement touched the cardholder data environment):
- Requirement 9.4.7: securely destroy media containing cardholder data when it is no longer needed.
- Requirement 3.2: do not store sensitive authentication data after authorisation.
UK GDPR / EU GDPR:
- Article 5(1)(e) Storage limitation: personal data is kept for no longer than necessary for the purposes for which it is processed.
- Article 17 Right to erasure: where applicable, personal data is erased on request or on lapse of the lawful basis.
- Article 5(1)(f) and Article 32 Integrity, confidentiality, and security of processing: destruction is performed in a manner that prevents unauthorised recovery.
HIPAA (where the engagement touched protected health information):
- 45 CFR 164.310(d)(2)(i) Disposal: implement policies and procedures to address the final disposition of electronic PHI.
- 45 CFR 164.530(c) Safeguards: maintain reasonable and appropriate safeguards.
DORA (Regulation (EU) 2022/2554):
- Article 26 Threat-led penetration testing and the related ICT risk management framework: artefacts produced under TLPT are retained, processed, and destroyed under the framework.
Other scheme references:
- CHECK / CREST OVS / CREST STAR: scheme-specific destruction language is carried from the scheme documentation.
- FedRAMP: artefacts produced under FedRAMP penetration testing are destroyed under the FedRAMP guidance.
- TIBER-EU: artefacts produced under TIBER-EU testing are destroyed in line with the TIBER-EU framework.
- MAS TRM TLPT: artefacts produced under MAS TRM threat-led penetration testing are destroyed under the MAS TRM Notice expectations.
Other regulator or framework: {{OTHER_FRAMEWORK_REFERENCE}}.
If no framework applies to the engagement, this section reads: "Not applicable. The engagement is not subject to a framework or regulator that mandates a specific destruction discipline."
9. Attestation and signature
The signed attestation that the destruction has been performed in line with the rest of the certificate. Counter-signature by the buyer is optional and depends on the contract; where required, the buyer recipient counter-signs to acknowledge receipt of the certificate. The signed certificate is filed alongside the engagement record so the audit chain runs from RFP to closure to destruction without gaps.
Attestation by the Testing Party:
The Testing Party named in Section 2 confirms that:
- The artefacts in scope of this certificate (Section 4) have been destroyed under the methods stated in Section 5.
- No copy of the in-scope artefacts remains under the Testing Party's direct control after the destruction date in Section 1.
- Anonymised artefacts retained for the purposes stated in Section 6 (where applicable) have been redacted under the redaction method stated and the reviewer named.
- Third-party processors named in Section 7 have removed their copies, subject to the residual retention windows stated.
- The destruction has been performed in line with the framework and regulatory references in Section 8 that apply to this engagement.
- This certificate is delivered to the Authorising Party named in Section 2 as evidence of the destruction.
Signed for and on behalf of the Testing Party:
Name: {{TESTING_PARTY_SIGNATORY_NAME}}
Title: {{TESTING_PARTY_SIGNATORY_TITLE}}
Signature: ____________________________
Date: ________________________________
Counter-signature by the Authorising Party (where the contract requires it; otherwise this block is left blank):
Name: {{CLIENT_RECIPIENT_NAME}}
Title: {{CLIENT_RECIPIENT_TITLE}}
Signature: ____________________________
Date: ________________________________
This certificate is effective on the latest of the signature dates above, save that the destruction date and time stated in Section 1 govern the moment from which the destruction is to be treated as complete. The signed certificate is filed alongside the Engagement Letter, Statement of Work, Rules of Engagement, Test Plan, Findings, Evidence Pack, Draft Report, Final Report, Debrief Deck, Retest Evidence, Attestation Letter, and Closure Letter so the audit chain is preserved through the destruction event.
How to use this template
Confirm the executed closure letter references are accurate. The certificate executes the retention plan recorded in Section 7 of the closure letter; mismatched references break the audit chain through the destruction.
Confirm that the retention window in Section 3 has actually lapsed before destroying anything. Premature destruction breaches the retention obligation; overdue destruction breaches the storage limitation principle. The window is concrete (a date) rather than aspirational (“when convenient”).
Inventory artefact categories in Section 4 exhaustively. The cleanest discipline is one row per category captured during the engagement, with approximate counts and storage locations. Categories not in scope (anonymised retention, separate retention, operationally destroyed under the rules of engagement) are listed explicitly so the auditor can see the partition.
Pick one destruction method per artefact category in Section 5. Mixing methods within a category (some screenshots overwritten, others physically destroyed, others on cloud) without breaking the category down further produces an ambiguous record; either split the category or document the per-item method.
Use Section 6 only when the testing party retains anonymised artefacts. The redaction method, the reviewer, and the residual retention end date are all named. Leaving Section 6 vague is the most common audit finding because it conflates destruction with retention.
Section 7 (third-party processors) is the part most often left blank. Every cloud storage, email, ticketing, chat, and SaaS platform that held a copy is named, the deletion request and processor confirmation are referenced, and the residual retention windows are captured. A certificate without Section 7 cannot evidence “destroyed everywhere”.
Trim Section 8 to the framework or regulator that actually applies. Citing every framework on every certificate is noise; citing the relevant control or article gives the auditor a direct mapping.
The Testing Party signs the attestation in Section 9. Counter-signature by the buyer is optional and depends on the contract; where the contract requires it, deliver the certificate to the recipient representative for counter-signature within the timeline the contract states.
File the signed certificate alongside the engagement record (RFP, proposal, SOW, ROE, engagement letter, test plan, draft report, debrief deck, final report, retest evidence, attestation letter, closure letter) so the chain runs from RFP to destruction without breaks.
Methodology and scheme references
PTES Section 7 (Reporting) and the CREST Defensible Penetration Test specification both treat closeout artefacts as part of the engagement record. See the SecPortal CREST penetration testing framework page for the closeout chain.
NIST SP 800-115 closeout phase covers the destruction of test artefacts. See the SecPortal NIST SP 800-115 framework page for the full lifecycle.
For ISO 27001 Annex A control 8.10 (Information deletion) walkthroughs, see the SecPortal ISO 27001 framework page.
For SOC 2 Common Criteria CC6.5 (data and software removal), see the SecPortal SOC 2 framework page.
For PCI DSS Requirement 9.4.7 (secure destruction of cardholder data media) where the engagement touched the cardholder data environment, see the SecPortal PCI DSS framework page.
For DORA TLPT and TIBER-EU artefact handling in financial services engagements, see the SecPortal TIBER-EU framework page.
Where the destruction certificate sits in the engagement
The full paper trail for a regulated penetration testing engagement runs RFP, proposal, SOW, ROE, engagement letter, test plan, kickoff, active testing (interrupted as needed by stop-test letters and resume notices), draft report, debrief deck, final report, retest evidence, attestation letter, closure letter, and (at the end of the retention window) the evidence destruction certificate. The certificate is the artefact that closes the long-tail evidence retention obligation set up in the closure letter. It pairs with the executed closure letter (the document that records the retention plan), the rules of engagement (the document that destroyed operationally sensitive artefacts at engagement end), and the engagement letter (the underlying authorisation that started the chain).
For the evidence pack workflow that ran during the engagement and now feeds this destruction event, see the pentest evidence management workflow.
For the report delivery workflow that produced the deliverables retained alongside the evidence, see pentest report delivery.
For the credential handover and rotation workflow that runs alongside engagement closure (and feeds the credential destruction in this certificate), see the credential handover for pentests workflow.
This template is provided as a starting point for a penetration testing evidence destruction certificate. It is not legal advice. Have the final certificate 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 retention obligations.