How to write clear rules of engagement for a pentest

A penetration test is only as controlled as the agreement that governs it. Without a clear rules of engagement (ROE) document, even a well-intentioned penetration testing engagement can drift into legally grey territory, cause unintended system disruptions, or leave both parties unclear on who is responsible when something goes wrong. Getting the ROE right before testing begins is not a formality; it is the foundation that makes the entire exercise safe, legal, and useful.

This guide walks you through each element of a solid ROE document, from defining scope to getting final sign-off. Follow these steps in order and you will have a written agreement that protects your organisation, sets clear expectations for the testing team, and ensures the results are actionable.

What to Define Before Drafting Your ROE

Before a single word goes into the ROE document, gather the key stakeholders and align on the purpose of the engagement. Knowing why you are running the test shapes every decision that follows. Are you validating a specific control? Preparing for a compliance audit? Testing your incident response team? The answer determines what kind of testing is appropriate and what constraints are reasonable.

At this stage, collect the following information so the drafting process moves quickly:

• The name and contact details of the authorising officer within your organisation
• The legal entity or entities that own the systems being tested
• Third-party systems or cloud environments that may be in scope, and whether you have written permission from those providers
• Any regulatory requirements or compliance frameworks that apply to the engagement
• The intended start date, end date, and total testing window

Once you have these inputs confirmed, you are ready to begin drafting. Do not skip this groundwork; gaps discovered mid-engagement are far more disruptive than gaps caught before the first packet is sent.

Define the Scope and Out-of-Scope Boundaries

Scope definition is the most critical section of the ROE. It tells the testing team exactly where they are authorised to operate and, equally importantly, where they must not go. Vague scope language is one of the most common causes of testing incidents, so be precise.

1. List every in-scope asset explicitly: IP ranges, domain names, application URLs, physical locations if relevant, and any specific user accounts created for testing.
2. List out-of-scope assets with equal specificity. If a subnet sits adjacent to a target system, name it as off-limits. If a production database must not be touched, say so directly.
3. Clarify whether third-party infrastructure is in scope. Cloud providers, SaaS platforms, and shared hosting environments often have their own testing policies. Confirm authorisation in writing before including them.
4. State whether social engineering, physical access attempts, or denial-of-service testing are included or excluded.

After completing this section, read it back as if you were the tester seeing it for the first time. If any asset’s status is ambiguous, revise that entry before moving on. A tester who is unsure whether a system is in scope will either avoid it entirely or make a judgement call; neither outcome serves you well.

Set Permitted Techniques and Testing Constraints

With scope defined, the next step is specifying which techniques the testing team is authorised to use. This section translates the business intent of the engagement into technical boundaries that the testers can follow during execution.

1. Specify whether the test is black box, grey box, or white box, and what credentials or documentation the testers will receive at the start.
2. List permitted attack categories: network scanning, vulnerability exploitation, privilege escalation, lateral movement, data exfiltration simulation, and so on. Be explicit rather than using catch-all phrases.
3. Identify any techniques that are explicitly prohibited, such as destructive payloads, ransomware simulation, or actions that could corrupt live data.
4. Define testing hours. Many organisations restrict active exploitation to off-peak windows to reduce the risk of service disruption.
5. Clarify whether automated scanning tools are permitted and, if so, which categories of tools are acceptable.

Verify this section by asking whether a tester could read it and make confident decisions in the field without needing to contact you for clarification. If the answer is no, add more detail. The goal is a document that removes ambiguity, not one that delegates decisions to the tester in the moment.

Establish Escalation and Emergency Stop Procedures

Even a well-scoped test can encounter the unexpected. A tester may discover a critical vulnerability that poses immediate risk. A test action may trigger an alert that activates your incident response team. A system may behave in a way that suggests real attacker activity is happening alongside the test. The ROE must define exactly what happens in each of these situations.

1. Name a primary point of contact on the client side who can be reached at any time during the testing window. Include a mobile number, not just an email address.
2. Name a secondary contact in case the primary is unreachable.
3. Define the conditions that require the testing team to pause immediately and notify you. At minimum, this should include discovery of active compromise by a third party, accidental access to out-of-scope systems, and any action that causes unintended service degradation.
4. Define the emergency stop procedure: how the tester signals a halt, how your team confirms receipt, and what the tester does while waiting for instruction.
5. Specify how critical findings are communicated during the engagement, not just in the final report. Waiting until the report is delivered to learn about a critical exposure is not acceptable.

Once this section is drafted, share it with your IT operations and security teams before finalising. They need to know these procedures exist and understand their role if an escalation occurs. An escalation plan that only the testing team has read is not a plan.

Review and Sign Off the ROE with All Parties

The final step is converting the drafted document into a signed agreement. This is not a rubber-stamp exercise. A genuine review catches gaps, resolves misunderstandings, and ensures every party understands what they are authorising.

1. Share the draft with the testing team and ask them to confirm that the scope and constraints are technically workable. Testers sometimes identify practical conflicts at this stage, such as a testing window that is too short for the scope defined.
2. Have your legal or compliance team review the document, particularly the liability clauses and any references to third-party systems.
3. Confirm that the authorising officer has the actual authority to approve testing on all in-scope systems. This is especially important when cloud infrastructure or third-party environments are involved.
4. Collect signatures from the authorising officer on the client side and the lead on the testing team. Both parties should retain a copy.
5. Set a version number and date on the signed document. If scope changes during the engagement, issue an amended ROE rather than handling changes verbally.

With a signed ROE in place, the engagement can begin with confidence on both sides. If you would like support structuring or reviewing your penetration testing programme, get in touch with us and we can help you build an approach that fits your organisation’s risk profile and compliance requirements.