Penetration Testing Engagement Letter Template authorise testing to begin without leaving the audit trail behind
A free, copy-ready penetration testing engagement letter template. Eleven structured sections covering engagement references, parties, scope summary, testing window, the substantive authorisation statement, the named engagement team, communications, scheme references (CHECK, CREST OVS, CREST STAR, FedRAMP, DORA TLPT), third-party permissions, physical and social engineering annex, and signatures. Sits at the front of the engagement record, inherits scope from the Statement of Work, and inherits operational rules from the Rules of Engagement. Aligned with PTES, NIST SP 800-115, and the CREST Defensible Penetration Test specification.
Run the engagement on the same record as the letter
SecPortal stores the engagement letter alongside the SOW, the ROE, the findings, the report, and the retest evidence. One audit trail from authorisation to closure. Free plan available.
No credit card required. Free plan available forever.
Full template
Copy the full engagement letter template
Eleven structured sections. The letter inherits scope and operational rules from the executed statement of work and rules of engagement. Replace every {{PLACEHOLDER}} before signing.
1. Header and engagement references
The letter opens with the engagement reference, the date, and the documents it inherits from. PTES Section 1 (Pre-engagement), NIST SP 800-115, and the CREST Defensible Penetration Test specification all expect a traceable authorisation chain back to the SOW and ROE.
PENETRATION TESTING ENGAGEMENT LETTER
Engagement reference: {{ENGAGEMENT_REFERENCE}}
Letter date: {{LETTER_DATE}}
This letter is the formal authorisation for the testing party named below to commence the penetration testing engagement defined under:
- 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}}
- Vendor proposal of record: {{PROPOSAL_REFERENCE}}, dated {{PROPOSAL_DATE}}
Where any term of this letter conflicts with the SOW or ROE, the underlying executed document governs and this letter is to be interpreted as an instruction to proceed against those terms rather than a variation.
2. Parties
Names the contracting client (the Authorising Party) and the testing firm (the Testing Party). The signing authority on the client side must hold delegated authority to authorise testing of the listed assets.
A concise summary of the in-scope assets, depth, and methodology. The detailed scope lives in the SOW and the ROE; the letter restates the headline so the signing executive can confirm what they are authorising without paging through both documents.
Scope summary (full scope per the SOW and ROE):
- Asset categories in scope: {{ASSET_CATEGORIES}}
(for example: external web applications, internal network ranges, cloud accounts, mobile applications, source code repositories)
- Counted asset units: {{ASSET_COUNTS_PER_CATEGORY}}
- Test depth: {{TEST_DEPTH}} (PTES Level 1 reconnaissance / Level 2 standard / Level 3 advanced, or equivalent)
- Methodology: {{METHODOLOGY_REFERENCES}} (PTES, NIST SP 800-115, OWASP WSTG, OWASP MASTG, OWASP ASVS, CREST as applicable)
- Out of scope: explicit exclusions per Section 3 of the ROE, including any third-party hosted assets without written authorisation.
The Authorising Party confirms that this summary aligns with the scope locked in the SOW and ROE. Any divergence is to be resolved through the change control mechanism in the SOW before testing begins.
4. Testing window and operating premises
Captures the agreed start, end, and any blackout periods. The letter is an instruction to proceed inside this window; it does not authorise testing outside it.
Primary testing window: {{START_DATE}} {{START_TIME}} ({{TIMEZONE}}) to {{END_DATE}} {{END_TIME}} ({{TIMEZONE}})
Off-hours window for high-impact tests: {{OFF_HOURS_WINDOW}}
Blackout periods (no testing): {{BLACKOUT_PERIODS}}
Source IPs the Testing Party will operate from: {{SOURCE_IPS}}
Operating premises (where testers will be physically located): {{OPERATING_PREMISES}}
Outside this window, this engagement letter does not authorise any testing activity. Retests after the testing window close are governed by the retest clause in the SOW or by a separate addendum to this letter.
5. Authorisation statement
The substantive permission to test, expressed clearly so an auditor or scheme reviewer can find it without parsing the surrounding text. This is the clause that converts a contract into an instruction-to-proceed.
The Authorising Party authorises the Testing Party, through its named engagement lead and the engagement team identified in Section 6, to perform the activities defined in the Statement of Work and Rules of Engagement against the assets summarised in Section 3, during the window in Section 4.
The Authorising Party warrants that:
1. It owns or has the right to authorise security testing of every asset within scope.
2. Where an asset is hosted, processed, or operated by a third party, written permission has been obtained and is referenced in Section 9.
3. It has notified internal stakeholders (security operations, incident response, change control, business owners) whose detection or response activity may overlap with the testing window.
4. A change-freeze sufficient to keep scope stable across the testing window has been put in place where this is required by the SOW or scheme.
The Testing Party undertakes to operate within the rules in the ROE, to communicate findings within the agreed severity SLAs, and to invoke a stop-test under the conditions defined in Section 9 of the ROE.
6. Named engagement team
Lists the testers authorised to operate under this letter. Regulated schemes (CHECK, OVS, STAR, DORA TLPT) require named individuals with verifiable accreditations. The list is the boundary of who is covered by the authorisation in Section 5.
The following individuals are authorised to perform testing under this engagement letter:
1. {{TESTER_1_NAME}}, {{TESTER_1_ROLE}}, accreditations {{TESTER_1_ACCREDITATIONS}}
2. {{TESTER_2_NAME}}, {{TESTER_2_ROLE}}, accreditations {{TESTER_2_ACCREDITATIONS}}
3. {{TESTER_3_NAME}}, {{TESTER_3_ROLE}}, accreditations {{TESTER_3_ACCREDITATIONS}}
Substitutions: any change to the named team during the engagement requires written notice from the Testing Party engagement lead to the Authorising Party representative. Substitutions affecting scheme-accredited roles (CHECK Team Member, CREST Registered Tester, OVS, STAR) require written acknowledgement from the Authorising Party before the new tester operates under this authorisation.
7. Communications and escalation
Restates the named contacts and severity SLAs from the ROE so the signing executive sees the live escalation path attached to the authorisation. Detailed mechanics live in Section 6 of the ROE.
Primary communication channel: secure messaging inside the engagement workspace operated by the Testing Party.
Secondary channel: email to the addresses below, with PGP encryption available on request.
Out-of-band escalation: phone numbers below, available during the testing window.
Authorising Party contacts:
- Engagement lead: {{CLIENT_LEAD_NAME}}, {{CLIENT_LEAD_EMAIL}}, {{CLIENT_LEAD_PHONE}}
- Security escalation: {{CLIENT_SECURITY_ESCALATION_NAME}}, {{CLIENT_SECURITY_ESCALATION_CONTACT}}
- 24/7 stop-test contact: {{CLIENT_STOP_TEST_PHONE}}
Testing Party contacts:
- Engagement lead: {{TESTING_LEAD_NAME}}, {{TESTING_LEAD_EMAIL}}, {{TESTING_LEAD_PHONE}}
- Engagement escalation: {{TESTING_ESCALATION_NAME}}, {{TESTING_ESCALATION_CONTACT}}
Severity SLAs (per ROE Section 6):
- Critical: same business day, ideally within four hours, by phone followed by written confirmation.
- High: one business day in the workspace with a summary email to the Authorising Party lead.
- Medium: visible in the workspace as logged and summarised at the agreed checkpoint cadence.
- Low and informational: consolidated into the final report.
8. Scheme references and regulatory context
Where the engagement runs under a scheme (CHECK, CREST OVS, CREST STAR, FedRAMP penetration testing, DORA TLPT, MAS TRM TLPT) the letter cites the scheme and the requirement that the scheme imposes on the authorisation chain.
Scheme references applicable to this engagement (delete those that do not apply):
- UK CHECK: testing performed under the CHECK scheme by accredited team members. CHECK requires a named authorising individual with documented authority over the listed assets.
- CREST Defensible Penetration Test: methodology aligned with the CREST DPT specification, with named CREST Registered Testers per Section 6.
- CREST OVS / STAR: scheme-specific scope and methodology constraints carried from the SOW and ROE.
- FedRAMP penetration testing: aligned with FedRAMP penetration test guidance, with reporting templates per the FedRAMP requirement set.
- DORA TLPT (where applicable to financial entities subject to DORA): testing performed under the threat-led penetration testing requirements of Regulation (EU) 2022/2554.
- MAS TRM TLPT (Singapore-regulated entities): aligned with MAS TRM Notice expectations.
- Other regulator or scheme: {{OTHER_SCHEME_REFERENCE}}.
Where the scheme requires evidence of the authorisation chain (signed letter, accreditation register entries, regulator notification), the Testing Party will retain the artefacts as part of the engagement record per Section 7 of the ROE.
9. Third-party permissions
Where any in-scope asset is hosted or operated by a third party, the letter records the permission reference. This is the clause that prevents authorised testing of an asset the client does not own from becoming unauthorised testing of someone else system.
Third-party permissions referenced under Section 5(2):
1. Third party: {{THIRD_PARTY_1_NAME}}
Asset(s) covered: {{THIRD_PARTY_1_ASSETS}}
Permission reference: {{THIRD_PARTY_1_PERMISSION_REF}}, dated {{THIRD_PARTY_1_PERMISSION_DATE}}
2. Third party: {{THIRD_PARTY_2_NAME}}
Asset(s) covered: {{THIRD_PARTY_2_ASSETS}}
Permission reference: {{THIRD_PARTY_2_PERMISSION_REF}}, dated {{THIRD_PARTY_2_PERMISSION_DATE}}
3. Third party: {{THIRD_PARTY_3_NAME}}
Asset(s) covered: {{THIRD_PARTY_3_ASSETS}}
Permission reference: {{THIRD_PARTY_3_PERMISSION_REF}}, dated {{THIRD_PARTY_3_PERMISSION_DATE}}
If no in-scope asset is hosted or operated by a third party, this section reads: "Not applicable. All in-scope assets are owned and operated by the Authorising Party."
10. Physical access and social engineering (annex)
Only included if physical or social engineering is in scope. The annex carries the get-out-of-jail letter language so a tester or operator can produce it on demand at a target premises.
Physical access and social engineering activities are ONLY authorised where this section is signed and the get-out-of-jail letter referenced below is attached and carried by every operator on site.
In-scope locations: {{PHYSICAL_LOCATIONS}}
In-scope individuals or roles for social engineering: {{SE_TARGET_NAMES_OR_ROLES}}
Authorised techniques: {{PHYSICAL_AND_SE_TECHNIQUES}}
Get-out-of-jail letter:
- Issued by: {{CLIENT_AUTHORISING_NAME}}, {{CLIENT_AUTHORISING_TITLE}}, {{CLIENT_LEGAL_NAME}}
- Date: {{LETTER_DATE}}
- 24/7 verification phone: {{LETTER_VERIFICATION_PHONE}}
- Quoted authorisation statement: see Section 5 of this engagement letter.
- Carried by: every tester or operator working on site at the listed locations.
If physical access and social engineering are out of scope, this section reads: "Not applicable. The engagement is restricted to remote technical testing per the SOW and ROE."
11. Signatures and instruction to proceed
The closing block converts the letter into an executed authorisation. A senior representative from the Authorising Party with delegated authority must sign, alongside the Testing Party engagement lead.
Signed for and on behalf of the Authorising Party:
Name: {{CLIENT_AUTHORISING_NAME}}
Title: {{CLIENT_AUTHORISING_TITLE}}
Signature: ____________________________
Date: ________________________________
Signed for and on behalf of the Testing Party:
Name: {{ENGAGEMENT_LEAD_NAME}}
Title: {{ENGAGEMENT_LEAD_TITLE}}
Signature: ____________________________
Date: ________________________________
Effective on the latest of the two signature dates above. Testing may not commence before the effective date.
How to use this template
Confirm that the executed statement of work and rules of engagement are in place. The engagement letter is an instruction to proceed against those documents, not a substitute for them. If the SOW or ROE is not yet signed, the letter cannot be issued.
Confirm scope and tester-day budget against the validated scoping output. The pentest scoping calculator produces the asset count, complexity, and depth assumptions referenced in Section 3.
Replace every {{PLACEHOLDER}} with engagement-specific values. Do not leave placeholders in the executed letter. Pay particular attention to Section 6 (named engagement team) where regulated schemes require accredited individuals.
Add or trim Section 8 (scheme references) so only the schemes actually applicable to this engagement remain. CHECK, CREST OVS, CREST STAR, FedRAMP, and DORA TLPT each impose distinct authorisation expectations.
Where physical access or social engineering is in scope, complete Section 10 and produce the get-out-of-jail letter as a standalone artefact for testers operating on site. Where it is not, mark Section 10 as not applicable.
Get the document signed by both sides before any reconnaissance starts. Reconnaissance is testing for the purpose of authorisation; an unsigned letter does not authorise reconnaissance any more than it authorises exploitation.
Store the signed engagement letter alongside the engagement record so the authorisation chain (proposal, SOW, ROE, engagement letter) lives with the work for audit, scheme review, and retest purposes.
Methodology and scheme references
PTES Section 1 (Pre-engagement interactions) treats the authorisation chain as non-optional. See the SecPortal PTES framework page for the operator-first walkthrough.
NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, planning phase.
CREST Defensible Penetration Test specification and CREST CHECK / OVS / STAR scheme documentation. See the CREST penetration testing framework page for accreditation context that may belong in Section 6.
For severity-driven communications under Section 7, the vulnerability remediation SLA calculator produces a defensible severity rubric you can carry into the SOW and ROE this letter inherits from.
Where the engagement letter sits in the engagement
The clean paper trail for a regulated penetration testing engagement runs RFP, proposal, SOW, ROE, engagement letter. The letter is the last artefact before testing starts and the first artefact a scheme reviewer or auditor checks when they reconstruct the authorisation chain. The accepted vendor proposal flows into the SOW; the SOW carries operational rules into the ROE; the ROE binds testers to conduct; the engagement letter authorises the team to begin.
For the operational decomposition of the SOW into the day-by-day work the team will execute under this authorisation, see the pentest test plan template. The plan is acknowledged by the client at kickoff against the executed engagement letter.
For pre-engagement intake and kickoff workflow against the engagement letter, see pentest client onboarding.
For retests authorised by an addendum to the letter, see pentest retesting.
For the closeout artefact that lapses this authorisation cleanly at the end of the engagement, see the pentest closure letter template. The closure letter pairs to this engagement letter and records the retest scope, evidence retention plan, and lapse of authorisation.
This template is provided as a starting point for a penetration testing engagement letter. It is not legal advice. Have the final letter reviewed by counsel and aligned with the master services agreement, statement of work, and rules of engagement that govern the broader relationship.