Rules of Engagement (RoE) establish the authorised parameters, constraints, and guidelines that govern how a penetration test will be conducted. They sit alongside the scope document to form the complete contractual and technical framework for an engagement, and establish what the testing team is permitted to do, what is explicitly prohibited, and how both parties should respond if something unexpected occurs.
These rules go beyond the simple scope definition in order to specify which testing techniques are permitted, the allowed timeframes for testing activities, and the escalation procedures if/when critical vulnerabilities are discovered.
For example, a web application may be in scope, but the RoE determines whether authenticated testing is permitted, if denial-of-service techniques can be used, whether automated scanning is restricted to certain hours, and what the tester should do if they discover evidence of an active third-party compromise during the engagement.
The rules of engagement essentially forms the contract between the organisation and the testing team to ensure that everyone understands what is allowed, prohibited, and how to handle unexpected situations that may arise during testing.
What a rules of engagement document covers
A well-constructed RoE document sits alongside the scope and the written authorisation to test, and typically covers the following areas.
| Area | Covers |
|---|---|
| Testing windows | When active testing may take place: business hours, overnight windows, or specific maintenance periods |
| Permitted and prohibited techniques | The boundary between authorised testing and actions that could cause harm, such as denial-of-service or data deletion |
| Social engineering and physical testing | Explicit authorisation for phishing simulations, pretexting calls, or physical access attempts, since these fall outside the implied scope of a technical assessment |
| Escalation and notification | Who to contact, within what timeframe, and through which channel if a critical vulnerability is found |
| Credential and data handling | How credentials, sensitive documents, or personal data encountered during testing must be treated and retained |
| Emergency contacts | A named technical contact at the organisation with authority to halt testing, and a lead consultant contact on the testing side |
Testing windows
Production systems often carry restrictions to business hours, overnight windows, or specific maintenance periods to reduce the risk of disruption to both users and the business itself.
Some organisations permit unrestricted testing against isolated staging environments but may apply tighter controls to customer-facing infrastructure.
Permitted and prohibited techniques
Destructive techniques such as denial-of-service attacks, data deletion, or exploitation of vulnerabilities in ways that could cause permanent damage are commonly excluded.
The RoE should be specific, and a blanket "no destructive testing" instruction is less useful than explicit guidance on, for example, whether parameter tampering on transactional endpoints is permitted and to what degree.
Social engineering and physical testing
Phishing simulations, pretexting calls, and physical access attempts fall outside the implied scope of a technical assessment and should only be conducted where the RoE specifically permits them.
Escalation and notification
If a tester finds evidence of a live data breach, identifies an exploit path to critical financial systems, or a flaw that presents immediate business risk, then the rules of engagement should specify who to contact, within what timeframe, and through which communication channel.
Credential and data handling
Credentials discovered during an engagement, sensitive documents accessed to demonstrate a finding, or personal data observed during testing all require clear handling instructions.
Such material shouldn't be retained beyond the engagement window and is documented only to the extent necessary to evidence findings.
Emergency contacts
Named contacts on both sides ensure that testing can be paused or stopped quickly if an unintended disruption occurs, or in some cases if there are any general scheduling issues from the client or the provider.
Rules of engagement and written authorisation
From a legal perspective, the rules of engagement forms part of the written authorisation that distinguishes authorised security testing from unauthorised computer access. Without it, even well-intentioned testing can carry legal risk for the testing team and for the individuals who have commissioned the engagement.
A thorough rules of engagement document protects the organisation by ensuring testing remains controlled and proportionate, and protects the testing team by establishing clear authorisation for the activities they perform.
Engagements that proceed without agreed rules of engagement are more likely to encounter avoidable disruption, scope disagreements, and uncertainty about liability if something goes wrong.