Pentest Rules of Engagement Template sign before you scan
A free, copy-ready penetration testing rules of engagement (ROE) template. Eleven structured sections covering parties and authorisation, scope, out-of-scope items, testing window, allowed and prohibited techniques, communications and severity SLAs, evidence handling, social engineering and physical access, stop-test conditions, reporting and retests, and signatures. Aligned with PTES, NIST SP 800-115, and the CREST Defensible Penetration Test specification.
SecPortal stores the ROE alongside the engagement, the findings, the report, and the retests. One audit trail from kickoff to closure. Free plan available.
No credit card required. Free plan available forever.
Full template
Copy the full ROE template
Eleven sections, each replaced with engagement-specific values. Aligned with PTES Section 1 (Pre-engagement interactions), NIST SP 800-115 planning guidance, and the CREST Defensible Penetration Test specification. Replace every {{PLACEHOLDER}} before signing.
1. Parties and authorisation
Names the contracting parties, the engagement reference, and confirms written authorisation to test the listed assets. PTES Section 1 (Pre-engagement) and CREST Defensible Penetration Test both treat this as non-optional.
Client (the Authorising Party): {{CLIENT_LEGAL_NAME}}
Authorising representative: {{CLIENT_AUTHORISING_NAME}}, {{CLIENT_AUTHORISING_TITLE}}
Email / Phone: {{CLIENT_AUTHORISING_CONTACT}}
Testing organisation (the Testing Party): {{TESTING_FIRM_LEGAL_NAME}}
Engagement lead: {{ENGAGEMENT_LEAD_NAME}}
Email / Phone: {{ENGAGEMENT_LEAD_CONTACT}}
Engagement reference: {{ENGAGEMENT_REFERENCE}}
Statement of Work reference: {{SOW_REFERENCE}}
The Authorising Party confirms that it owns or has the right to authorise security testing of every asset listed in Section 2 (Scope) of this document, and grants the Testing Party permission to conduct the activities described herein during the testing window defined in Section 4. Where any in-scope asset is hosted, processed, or operated by a third party, the Authorising Party warrants that it has obtained that third party's written permission before the asset appears in scope.
2. Scope
List every asset in scope by exact identifier (FQDN, IP/CIDR, application name, repository, account ID). Anything not listed here is out of scope by default.
Explicit exclusions reduce ambiguity at the boundary. Anything that could be confused with the scope, or that the client has elected not to include, belongs here.
The following are explicitly out of scope and must not be tested:
- Production systems outside the asset list in Section 2.
- Third-party services not owned or operated by the Authorising Party (including SaaS dependencies, payment processors, identity providers, and content delivery networks) unless explicit written permission is attached as an Annex to this document.
- Any asset that resolves to an IP outside the ranges in Section 2, even if reached from an in-scope host.
- Production data, including personal data of identifiable individuals, beyond the minimum required to demonstrate impact. Where personal data is unavoidably accessed, it must be masked in evidence and not retained beyond engagement closure.
- Denial of service or volumetric techniques against any asset in or out of scope, unless explicitly authorised under Section 6 (Allowed and prohibited techniques).
- Social engineering of named individuals not listed in an attached Social Engineering Annex.
- Physical access to client premises unless explicitly authorised under Section 8 (Physical and social engineering).
4. Testing window and intensity
Capture exact start and end times in the client local timezone, blackout periods, and intensity. The window should cover discovery, exploitation, and any retests inside the contract.
Primary testing window: {{START_DATE}} {{START_TIME}} ({{TIMEZONE}}) to {{END_DATE}} {{END_TIME}} ({{TIMEZONE}})
Off-hours / maintenance window for high-impact tests: {{OFF_HOURS_WINDOW}}
Blackout periods (no testing): {{BLACKOUT_PERIODS_REASON}}
Source IP addresses the Testing Party will operate from: {{SOURCE_IPS}}
Testing intensity expectations:
- Reconnaissance and surface analysis: full intensity throughout the window.
- Active exploitation against production systems: limited to the agreed intensity level and the off-hours window where applicable.
- Password attacks: rate-limited to {{LOGINS_PER_MINUTE}} per account to avoid lockout, with account lockout monitoring delegated to the client.
- Any testing activity expected to take a system offline must be coordinated in writing in advance via the channels in Section 7 (Communications).
5. Allowed and prohibited techniques
Techniques, not tools. Naming tools tends to age the ROE. Capture restrictions imposed by regulators (CHECK, OVS, STAR) by reference rather than by tool name where possible.
Allowed techniques include, without limitation:
- Network and service discovery against in-scope assets.
- Vulnerability identification, validation, and safe exploitation against in-scope assets.
- Authenticated and unauthenticated testing of web applications and APIs in scope.
- Source code review of in-scope repositories where source access is granted.
- Lateral movement and post-exploitation inside in-scope environments to demonstrate impact.
Prohibited techniques include:
- Destructive payloads, including disk wiping, encryption of client data, and irreversible configuration changes.
- Live denial of service or stress testing without explicit written authorisation under Section 4.
- Real social engineering of any individual not listed in a Social Engineering Annex.
- Use of zero-day exploits whose impact cannot be predicted on production systems.
- Any technique that would cause the Testing Party to access regulated data (PHI, cardholder data, financial records) outside the minimum required to demonstrate impact.
6. Communications and severity SLAs
Findings without a defined communication SLA tend to sit in draft documents while exploitation windows close around them. Define them by severity, with named contacts.
Communication channels:
- Primary: secure messaging inside the engagement portal hosted by the Testing Party.
- Secondary: email to the addresses listed below, with PGP encryption available on request.
- Out-of-band: phone numbers below for critical findings and stop-test events.
Named contacts:
- Client engagement lead: {{CLIENT_LEAD_NAME}}, {{CLIENT_LEAD_EMAIL}}, {{CLIENT_LEAD_PHONE}}
- Client security escalation: {{CLIENT_SECURITY_ESCALATION_NAME}}, {{CLIENT_SECURITY_ESCALATION_CONTACT}}
- Testing lead: {{TESTING_LEAD_NAME}}, {{TESTING_LEAD_EMAIL}}, {{TESTING_LEAD_PHONE}}
- Testing escalation: {{TESTING_ESCALATION_NAME}}, {{TESTING_ESCALATION_CONTACT}}
Finding severity SLAs:
- Critical: communicated within the same business day, ideally within four hours of discovery, by phone followed by written confirmation in the portal.
- High: communicated within one business day in the portal with a summary email to the client lead.
- Medium: visible in the portal as logged and summarised at the agreed checkpoint cadence ({{CHECKPOINT_CADENCE}}).
- Low and informational: consolidated into the final report.
7. Evidence and data handling
Define how proof of compromise is captured, stored, transmitted, retained, and destroyed. This is where ROEs that work in practice differ from templates that fall apart at audit.
Evidence types collected may include:
- Request and response captures.
- Screenshots demonstrating impact.
- File hashes and small file samples where impact cannot be demonstrated otherwise.
- Configuration excerpts and command output.
Storage and transmission:
- Evidence is encrypted at rest using AES-256 or stronger inside the engagement workspace operated by the Testing Party.
- Credentials provided for authenticated testing are stored encrypted at rest, are not shared by email, and are rotated by the Authorising Party within {{CREDENTIAL_ROTATION_DAYS}} days of engagement closure.
- Personal data and other regulated data observed during testing is masked in evidence and not retained beyond engagement closure unless the Authorising Party requests otherwise in writing.
Retention and destruction:
- Evidence is retained for {{EVIDENCE_RETENTION_PERIOD}} after engagement closure for retest, audit, and dispute purposes.
- At the end of retention, evidence is securely destroyed and a destruction certificate is issued on request.
- Final reports and engagement records are retained per the data protection terms attached to the SOW.
8. Physical access and social engineering (annex)
Only include this section if physical or social engineering is in scope. Where included, it must list named individuals or buildings, written authorisation, and a get-out-of-jail letter.
Physical and social engineering activities are ONLY authorised where this section is signed and a get-out-of-jail letter is attached as an Annex.
In-scope locations: {{PHYSICAL_LOCATIONS}}
In-scope individuals (social engineering): {{SE_TARGET_NAMES_OR_ROLES}}
Authorised techniques: {{PHYSICAL_AND_SE_TECHNIQUES}}
Prohibited techniques: tailgating known to result in a confrontation, pretexts that imply legal authority the testers do not have, and any technique that places a target individual at personal risk.
Get-out-of-jail letter:
- Issued by: {{CLIENT_AUTHORISING_NAME}}, {{CLIENT_AUTHORISING_TITLE}}
- Signed: {{LETTER_DATE}}
- 24/7 verification phone number: {{LETTER_VERIFICATION_PHONE}}
- Carried in physical form by every tester operating on site.
9. Stop-test conditions
Stop-test clauses let either side pause without penalty if something goes wrong. PTES, NIST SP 800-115, and CREST all assume the engagement can be paused on short notice.
Either party may invoke a stop-test at any time without penalty. Stop-test triggers include:
- Discovery of an active third-party compromise unrelated to the engagement.
- Accidental impact to a production system or to data outside scope.
- Evidence that regulated data exists outside the agreed scope and would be unavoidably accessed by continuing.
- A finding that cannot be safely demonstrated without operational risk to the client.
- Any signal from the Authorising Party or its escalation contacts that the test must pause.
Mechanism:
- A stop-test is invoked by phone using the contacts in Section 6, followed by written confirmation in the engagement portal.
- The Testing Party halts active testing within fifteen minutes of receipt and confirms back to the Authorising Party.
- Resumption requires written confirmation from the Authorising Party. The cause of the stop-test, the actions taken, and the resumption authorisation are recorded in the engagement record.
10. Reporting, retests, and closure
Reporting and retest mechanics belong in the ROE because they govern operations, not just commercial expectations.
Reporting:
- Findings are logged inside the engagement workspace with severity, CVSS 3.1 vector, evidence, and remediation guidance as they are discovered.
- An interim report is delivered at the engagement midpoint where the testing window exceeds {{INTERIM_REPORT_THRESHOLD}} business days.
- A final report is delivered within {{FINAL_REPORT_DAYS}} business days of the testing window closing.
- The final report includes an executive summary, methodology citation (PTES, NIST SP 800-115, OWASP WSTG, MASVS, or as agreed), scope, findings with severity and remediation guidance, and a closure summary.
Retests:
- Findings rated Low and above are eligible for retest within a {{RETEST_WINDOW_DAYS}} day window after final report delivery.
- Retest results are paired to the original finding and recorded in the same engagement workspace.
- Retest invocation: {{RETEST_INVOCATION_CHANNEL}}.
Closure:
- The engagement is formally closed when the Authorising Party signs off the final report or the retest window expires, whichever is later.
- The engagement record (ROE, findings, evidence, report, retest evidence) is retained per Section 7.
11. Signatures
A senior representative from the client with authority to authorise testing of the listed assets must sign, alongside the engagement lead from the testing side.
For the Authorising Party:
Name: {{CLIENT_AUTHORISING_NAME}}
Title: {{CLIENT_AUTHORISING_TITLE}}
Signature: ____________________________
Date: ________________________________
For the Testing Party:
Name: {{ENGAGEMENT_LEAD_NAME}}
Title: {{ENGAGEMENT_LEAD_TITLE}}
Signature: ____________________________
Date: ________________________________
How to use this template
Confirm the scope, intensity, and depth with the client. Use the pentest scoping calculator to validate the asset count, complexity, and tester-day budget before the ROE is drafted. If the engagement went through a competitive procurement, the agreed scope and methodology should already match the penetration testing RFP the client issued, and the contractual record should already be locked in the statement of work. The ROE inherits commercial constraints from the SOW.
Replace every {{PLACEHOLDER}} with engagement-specific values. Do not leave placeholders in the signed document.
Add scheme-specific clauses where required (UK CHECK, CREST OVS, CREST STAR, FedRAMP, DORA TLPT). The relevant scheme reference belongs in Section 5 alongside the methodology citation.
Get the document signed by both sides before any reconnaissance starts. Reconnaissance is testing for the purposes of authorisation. Where the engagement runs under a regulated scheme, pair the signed ROE with the engagement letter that authorises a specific instance of testing to begin under this ROE.
Store the signed ROE alongside the engagement record so scope, authorisation, communications, and stop-test conditions live with the work for audit and retest purposes. When a stop-test condition actually triggers during active testing, execute the halt formally with the pentest stop-test letter template so the pause and resume conditions sit on the engagement record alongside the ROE that defined the trigger.
When the retention window opened by the closure letter eventually lapses, execute the destruction promised in Section 7 of this ROE with the pentest evidence destruction certificate template so the destruction is recorded as a discrete event on the engagement record rather than a silent retention drift.
Methodology references
PTES Section 1 (Pre-engagement interactions). 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.
OWASP Web Security Testing Guide (WSTG) and Mobile Application Security Testing Guide (MASTG).
This template is provided as a starting point for a penetration testing rules of engagement document. It is not legal advice. Have the final ROE reviewed by counsel and aligned with the contracts and data protection terms that govern the broader engagement.