Penetration Testing Credential Handover Form Template open the credential lifecycle on the engagement record, not in chat
A free, copy-ready penetration testing credential handover form template. Ten structured sections covering header and engagement references, parties and signing authority, authentication models in scope (cookie, bearer, basic auth, form login, mTLS, API key, OAuth, SSH, VPN, AD/IAM), per-credential role tier and environment, named recipients on the testing party, storage method and access controls, the rotation plan at engagement close, the rotation log reference, framework and regulatory references (ISO 27001, SOC 2, PCI DSS, DORA, GDPR, HIPAA), and signature blocks. Pairs with the executed rules of engagement, engagement letter, and (at close) the closure letter and evidence destruction certificate so the credential lifecycle inherits the authorisation chain rather than restating it. Aligned with PTES, NIST SP 800-115, OWASP WSTG, and the CREST Defensible Penetration Test specification.
Run credential handover on the same record the engagement opened on
SecPortal stores the credential handover form alongside the engagement letter, SOW, ROE, findings, evidence pack, final report, debrief deck, attestation letter, closure letter, and rotation log. Credentials live in the encrypted vault with AES-256-GCM at rest. Free plan available.
No credit card required. Free plan available forever.
Full template
Copy the full credential handover form template
Ten structured sections. The form opens the credential lifecycle that the executed rules of engagement scoped, runs through testing under the engagement letter, and closes on rotation at the closure letter. 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 form to the engagement letter, SOW, and rules of engagement matters because the credential issuance executes the credential ask recorded in those documents rather than a fresh decision. PTES, NIST SP 800-115, OWASP WSTG, and the CREST Defensible Penetration Test specification all assume a documented credential handover sitting on the same chain as the engagement.
PENETRATION TESTING CREDENTIAL HANDOVER FORM
Form reference: {{HANDOVER_FORM_REFERENCE}}
Engagement reference: {{ENGAGEMENT_REFERENCE}}
Form execution date: {{EXECUTION_DATE}}
Form effective date (credentials active from): {{CREDENTIALS_ACTIVE_FROM}} ({{TIMEZONE}})
Credentials valid until: {{CREDENTIALS_VALID_UNTIL}}
This form opens the credential lifecycle for 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}}
This form executes the credential ask recorded in Section {{ROE_CREDENTIAL_SECTION}} of the rules of engagement. Credentials issued under this form are bound to the engagement scope set by the engagement letter; out-of-scope use is a stop condition under the rules of engagement.
2. Parties and signing authority
Names the buyer issuing the credentials and the testing firm receiving them. The signatory on the buyer side is the engagement sponsor or a delegated equal whose authority covers the systems the credentials grant access to. The signatory on the testing party side is the engagement lead named in the engagement letter, or a partner with equivalent authority.
Issuing Party (the Client):
- Legal entity: {{CLIENT_LEGAL_NAME}}
- Registered address: {{CLIENT_ADDRESS}}
- Issuing signatory: {{CLIENT_SIGNATORY_NAME}}, {{CLIENT_SIGNATORY_TITLE}}
- Signing authority basis: {{CLIENT_SIGNING_AUTHORITY_BASIS}}
- Email: {{CLIENT_SIGNATORY_EMAIL}}
- Operational contact for credential issues: {{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: {{ENGAGEMENT_LEAD_NAME}}, {{ENGAGEMENT_LEAD_EMAIL}}
- Data protection contact (where applicable): {{TESTING_PARTY_DPO_NAME}}, {{TESTING_PARTY_DPO_EMAIL}}
Signing authority confirmation: the issuing signatory confirms that the authority to issue credentials granting access to the systems listed in Section 4 sits with this signatory or a named delegate. Lower-level handovers produce ambiguous accountability and are out of scope of this form.
3. Authentication models in scope
Inventories the authentication models in scope of the engagement. Each model is named explicitly so a reviewer can see no class of credential has been omitted. Models not in scope are listed under "out of scope" so the partition is clear.
Authentication models in scope of this credential handover (tick all that apply):
- [ ] Scoped application test accounts (one account per role tier; not real users)
- [ ] Cookie session tokens captured at kickoff browser handover
- [ ] Bearer tokens minted for API authentication
- [ ] API keys issued from a developer portal or API gateway
- [ ] Basic auth pairs for internal admin endpoints
- [ ] Form-login fields where the application requires more than username and password
- [ ] mTLS client certificates and the corresponding private key
- [ ] OAuth client credentials for confidential clients (client_id, client_secret)
- [ ] SSH keypairs for jump-host or bastion access
- [ ] VPN client profiles with embedded credentials
- [ ] AD or LDAP user accounts for internal network engagements
- [ ] IAM access keys and assumed-role credentials for cloud reviews
- [ ] Repository read access tokens for code review engagements
- [ ] Mailbox credentials for phishing simulation infrastructure
- [ ] Password-protected documents (architecture diagrams, threat models, prior reports)
- [ ] Other (specify): {{OTHER_AUTHENTICATION_MODEL}}
Out of scope of this form (no credentials to be issued for these models on this engagement):
- {{OUT_OF_SCOPE_MODELS}}
Multi-factor and step-up authentication on the issued credentials:
- MFA seed or recovery code provided: {{MFA_SEED_PROVIDED}}
- MFA bypass for testing approved: {{MFA_BYPASS_APPROVED}} (requires explicit ROE clause)
- Step-up authentication on sensitive transactions: {{STEP_UP_AUTH_NOTES}}
4. Credential inventory and per-credential metadata
The exhaustive list of credentials issued under this form, with role tier, environment, identity provider link, and expiry. The list is structured so the rotation log later can pair to each credential by its row identifier. Each credential is one row.
For every credential issued under this form, complete one row. Add additional rows as needed.
CREDENTIAL ROW {{ROW_NUMBER}}:
- Credential ID: {{CREDENTIAL_ID}}
- Authentication model: {{AUTHENTICATION_MODEL}} (from Section 3)
- Role tier: {{ROLE_TIER}} (read-only / standard user / admin / billing / support impersonation / IAM role / AD group)
- Environment: {{ENVIRONMENT}} (production / staging / dedicated test tenant / isolated VPC)
- System or application: {{SYSTEM_NAME}}
- Identity provider (where applicable): {{IDENTITY_PROVIDER_NAME}}
- IdP user or service principal reference: {{IDP_PRINCIPAL_REFERENCE}}
- IdP event log entry where the issuance was recorded: {{IDP_EVENT_LOG_REFERENCE}}
- Issuance method: {{ISSUANCE_METHOD}} (manual provisioning / automated provisioning / vault entry / hardware delivery)
- Issue date: {{ISSUE_DATE}}
- Expiry date: {{EXPIRY_DATE}}
- Test plan reference this credential supports: {{TEST_PLAN_REFERENCE}}
- Notes: {{CREDENTIAL_NOTES}}
Bypass credentials (credentials that bypass the buyer is identity provider; flag explicitly):
- {{BYPASS_CREDENTIAL_LIST}}
Where a bypass credential is on the inventory, the buyer confirms awareness of the out-of-band path and the testing party agrees to flag any use of the bypass credential in the report so the audit trail captures the dual track.
5. Named recipients and storage method
Names the individuals on the testing party who hold each credential and the storage method protecting the credential at rest. Role-based access controls on the storage are recorded so the auditor can see segregation of duties on engagement credentials.
Named recipients on the testing party who hold credentials issued under this form:
- {{RECIPIENT_1_NAME}}, {{RECIPIENT_1_TITLE}}, {{RECIPIENT_1_EMAIL}}
- {{RECIPIENT_2_NAME}}, {{RECIPIENT_2_TITLE}}, {{RECIPIENT_2_EMAIL}}
- {{RECIPIENT_3_NAME}}, {{RECIPIENT_3_TITLE}}, {{RECIPIENT_3_EMAIL}}
- (add additional rows as needed)
Storage method (tick the primary; document any secondaries):
- [ ] Encrypted credential vault on the engagement record (AES-256-GCM at rest, role-based access, activity log)
- [ ] Hardware security key delivered out of band
- [ ] Sealed envelope with chain-of-custody log (physical engagements only)
- [ ] Other (specify): {{OTHER_STORAGE_METHOD}}
Storage location: {{STORAGE_LOCATION_REFERENCE}}
Encryption at rest: {{ENCRYPTION_AT_REST_DETAILS}}
Encryption in transit: {{ENCRYPTION_IN_TRANSIT_DETAILS}}
Access control on the storage:
- Role-based access list: {{ROLE_BASED_ACCESS_LIST}}
- Named individuals who can read each credential: {{NAMED_INDIVIDUALS_BY_CREDENTIAL}}
- Activity log capturing every read: {{ACTIVITY_LOG_REFERENCE}}
- Roles explicitly excluded from read access (for example, billing): {{EXCLUDED_ROLES}}
Storage methods that are not in scope of this form (document explicitly so there is no ambiguity later):
- Unencrypted email attachments
- Chat platform messages without retention controls
- Personal password managers outside the engagement record
- Plain text working notes (markdown files, mind maps, whiteboards)
6. Data classification and processor disclosure
Records the data classification of any data the credentials grant access to, and names the third-party processors that hold copies of the credential. Processor disclosure prevents the most common audit gap, which is "credentials shared but processors not declared".
Data classification of data accessible via the credentials issued under this form:
- {{DATA_CLASSIFICATION}} (Public / Internal / Confidential / Restricted / Regulated)
- Sensitive data categories accessible: {{SENSITIVE_DATA_CATEGORIES}} (personal data, cardholder data, protected health information, financial data, intellectual property)
- Regulatory regime where applicable: {{REGULATORY_REGIME}} (GDPR, UK GDPR, CCPA, HIPAA, PCI DSS, GLBA, FERPA, sector-specific regimes)
- Lawful basis for processing under the applicable regime: {{LAWFUL_BASIS}}
Third-party processors that hold or transit the credential under this form (name every one; "none" is acceptable but the box is not blank):
- Encrypted credential vault provider: {{VAULT_PROVIDER_NAME}}, processor agreement reference: {{VAULT_DPA_REFERENCE}}
- Email or messaging system involved in the issuance flow: {{MESSAGING_PROVIDER_NAME}}, processor agreement reference: {{MESSAGING_DPA_REFERENCE}}
- Hardware security key issuer (where applicable): {{HSK_VENDOR_NAME}}
- Identity provider (where the IdP is a third party): {{IDP_VENDOR_NAME}}, processor agreement reference: {{IDP_DPA_REFERENCE}}
- Other processors: {{OTHER_PROCESSORS}}
The receiving party confirms that no copy of the credential will be created outside the storage location named in Section 5 without a written variation to this form.
7. Rotation plan at engagement close
Records the rotation plan in advance: who rotates each credential, by what method, by when, and how the rotation will be evidenced. The rotation plan is referenced by the rotation log (Section 8) and by the closure letter so the credential lifecycle closes cleanly.
For every credential issued under this form, the rotation plan is as follows:
Default rotation trigger: engagement close (closure letter execution date).
Earlier rotation triggers (any of these triggers immediate rotation regardless of close):
- Stop-test letter executed under the rules of engagement
- Credential leak suspected or confirmed
- Scope-out asset accessed unintentionally with the credential
- Regulator instruction to terminate the engagement
- Buyer-instructed early rotation (in writing)
- Identity provider event indicating credential compromise
- Engagement-related security alert that names the credential
Rotation method per credential category:
- Application test accounts: password reset by the application owner, account disabled or deleted; evidence: pre-rotation login fails for the testing party
- Cookie or session tokens: session invalidation in the application; evidence: token replay returns 401
- Bearer tokens: token revocation at the issuer; evidence: revocation event in the issuer log
- API keys: key rotation in the developer portal or API gateway; evidence: rotation event in the gateway log
- Basic auth pairs: password reset on the underlying account; evidence: pre-rotation login fails
- mTLS certificates: certificate revocation list update; evidence: CRL or OCSP entry showing revocation
- OAuth client credentials: client_secret rotation; evidence: rotation event in the IdP
- SSH keys: public key removal from authorized_keys; evidence: pre-rotation key fails to authenticate
- VPN profiles: profile revocation in the VPN concentrator; evidence: VPN concentrator log
- AD or LDAP accounts: account disabled, password reset, group membership removed; evidence: AD audit log
- IAM access keys and assumed roles: key deactivation, role policy revocation; evidence: cloud audit log entry
Named operator on the buyer side responsible for the rotation: {{ROTATION_OPERATOR_NAME}}, {{ROTATION_OPERATOR_TITLE}}, {{ROTATION_OPERATOR_EMAIL}}.
Rotation deadline (relative to engagement close or the earlier trigger): {{ROTATION_DEADLINE}}.
Where the rotation deadline cannot be met (operational change window, regulator window), the buyer notifies the testing party in writing before the original deadline and a revised deadline is agreed on the engagement record.
8. Rotation log reference
Points to the rotation log where the rotation evidence will be recorded. The rotation log is a separate artefact from this handover form so the audit chain has two distinct events: issuance (this form) and revocation (the rotation log).
Rotation log reference: {{ROTATION_LOG_REFERENCE}}
Rotation log location: {{ROTATION_LOG_LOCATION}}
The rotation log records, against each credential row from Section 4, the following:
- Credential ID (matches Section 4)
- Rotation date and time
- Rotation method (matches the method in Section 7 for that credential category)
- Named operator on the buyer side who confirmed the rotation
- Named operator on the testing party who verified the rotation took effect
- Post-rotation evidence (link to the IdP event, the audit log entry, the screenshot of the failed login, or other documented confirmation)
- Notes (where the rotation deviated from the plan, what was different and why)
Where the rotation log is the same artefact across multiple engagements, the rotation entries for this engagement are tagged with the engagement reference so they can be filtered for audit.
The rotation log is delivered to the buyer with the closure letter and is referenced from the closure letter so the credential lifecycle closes on the same record the engagement opened on.
9. Framework and regulatory references
Cites the relevant framework controls or regulatory articles. 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 credential issuance to the framework.
Where the engagement is regulated, this form cites the following controls or articles. Delete those that do not apply.
ISO/IEC 27001:2022 Annex A:
- 5.16 Identity management
- 5.17 Authentication information
- 8.2 Privileged access rights
- 8.3 Information access restriction
- 8.5 Secure authentication
SOC 2 Trust Services Criteria:
- CC6.1 Logical access security
- CC6.2 User provisioning
- CC6.3 User access removal
- CC6.6 Authentication and access controls
PCI DSS v4.0:
- 7.2 Access to system components and data is appropriately defined and assigned
- 8.2 User identification and related accounts for users and administrators are strictly managed
- 8.3 Strong authentication for users and administrators is established and managed
- 8.6 Use of application and system accounts and associated authentication factors is strictly managed
UK GDPR / EU GDPR:
- Article 5 Principles relating to processing of personal data
- Article 32 Security of processing
HIPAA Security Rule (US healthcare engagements only):
- 45 CFR 164.308(a)(3) Workforce security
- 45 CFR 164.308(a)(4) Information access management
- 45 CFR 164.312(a)(2)(i) Unique user identification
- 45 CFR 164.312(d) Person or entity authentication
DORA (EU financial services TLPT engagements):
- Article 26 Threat-led penetration testing
- Article 27 Requirements for testers
Penetration testing methodology references:
- PTES Section 1 (Pre-engagement Interactions) and Section 2 (Intelligence Gathering)
- NIST SP 800-115 Section 4 (Review Techniques) and Section 5 (Target Identification and Analysis)
- OWASP WSTG Section 4.4 (Authentication Testing)
- CREST Defensible Penetration Test specification, Section 4 (Pre-engagement)
Pentest scheme references where applicable:
- CHECK pentest credential handling
- CREST OVS, CREST STAR, CREST GBEST credential handling
- TIBER-EU credential handling for financial sector engagements
- FedRAMP penetration test credential handling for US federal engagements
10. Signatures and effective date
Signature blocks for the issuing party and the receiving party. The form is effective from the latest signature date; credentials are not active until the form is executed and the rotation plan is recorded.
Signed for the Issuing 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. Credentials issued under this form are active from the date stated in Section 1 (CREDENTIALS_ACTIVE_FROM) and remain active until the date in Section 1 (CREDENTIALS_VALID_UNTIL) or until rotated under Section 7, whichever is earlier. The signed form 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, Closure Letter, Evidence Destruction Certificate, and Rotation Log so the credential lifecycle is preserved on the engagement record from issuance through to revocation.
How to use this template
Confirm the executed rules of engagement references are accurate. The form executes the credential ask recorded in the rules of engagement; mismatched references mean the credential issuance happens outside the documented scope.
Tick the authentication models in Section 3 against the engagement scope. Models out of scope are listed explicitly; the partition matters because an authenticated DAST that quietly receives bypass credentials produces ambiguity at audit.
Inventory every credential in Section 4 with its own row. One row per credential with role tier, environment, identity provider link, and expiry. Reusing one row for multiple credentials breaks the rotation log pairing in Section 8.
Name recipients in Section 5 by individual rather than by team. Storage methods that are not in scope are listed explicitly so there is no ambiguity later about whether a copy of the credential ever sat in chat or email.
Section 6 is the part most often skipped. Naming third-party processors that hold or transit the credential is the discipline that protects the audit chain when the credential leaves the engagement boundary, even briefly.
Section 7 is the rotation plan in advance. Default trigger is engagement close; earlier triggers are listed explicitly. Picking one rotation method per credential category prevents the most common audit finding, which is “rotated, but how is unclear”.
Section 8 references the rotation log where the rotation evidence will be recorded. The rotation log is a separate artefact so the audit chain has two distinct events: issuance (this form) and revocation (the rotation log).
Trim Section 9 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.
Both parties sign in Section 10. Credentials are not active until the form is executed and the rotation plan is recorded.
File the signed form alongside the engagement record (RFP, proposal, SOW, ROE, engagement letter, test plan, draft report, debrief deck, final report, retest evidence, attestation letter, closure letter, evidence destruction certificate) so the chain runs from RFP through credential issuance to credential revocation without breaks.
Methodology and scheme references
PTES Pre-engagement Interactions and the CREST Defensible Penetration Test specification both treat credential handover as part of the pre-engagement record. See the SecPortal CREST penetration testing framework page.
NIST SP 800-115 covers credential issuance and authenticated testing under Section 4 (Review Techniques) and Section 5 (Target Identification and Analysis). See the SecPortal NIST SP 800-115 framework page.
OWASP WSTG Section 4.4 (Authentication Testing) covers the authenticated test cases the credentials issued under this form support. See the SecPortal OWASP framework page.
For ISO 27001 Annex A controls 5.16, 5.17, 8.2, 8.3, 8.5 walkthroughs, see the SecPortal ISO 27001 framework page.
For SOC 2 Common Criteria CC6.1, CC6.2, CC6.3, see the SecPortal SOC 2 framework page.
For PCI DSS Requirements 7 and 8 (access control and authentication) where the engagement touched the cardholder data environment, see the SecPortal PCI DSS framework page.
For DORA TLPT and TIBER-EU credential handling in financial services engagements, see the SecPortal TIBER-EU framework page.
Where credential handover sits in the engagement
The full paper trail for a regulated penetration testing engagement runs RFP, proposal, SOW, ROE, engagement letter, test plan, kickoff, credential handover (this form), active testing (interrupted as needed by stop-test letters and resume notices), draft report, debrief deck, final report, retest evidence, attestation letter, closure letter, rotation log, and (at the end of the retention window) the evidence destruction certificate. The credential handover form opens the lifecycle that the closure letter and the rotation log close. It pairs with the executed rules of engagement (the document that scoped the credential ask), the engagement letter (the underlying authorisation that started the chain), and the closure letter (the document that triggers the rotation plan recorded in Section 7).
For finding triage and reporting on credentials surfaced during testing (for example, weak credentials uncovered in scope), see the default credentials and weak password policy vulnerability pages.
This template is provided as a starting point for a penetration testing credential handover 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, and engagement letter that govern the broader relationship and the credential handling obligations.