Penetration testing without a complete rules of engagement document is not a business risk to be managed. It is a legal exposure and an operational failure waiting to happen, for the organisation commissioning the test and for the tester conducting it.
Computer Fraud and Abuse Act (CFAA) violations do not require malicious intent. Unauthorised access to computer systems is a federal offense regardless of whether the tester believed they were authorised. The rules of engagement document, signed by someone with actual legal authority to grant it, is the paper trail that establishes authorisation and protects both parties if anything goes wrong.
Beyond the legal function, the rules of engagement document resolves every ambiguous operational decision in advance. When the tester discovers an unexpected system adjacent to the defined scope, the RoE answers whether to test it. When an aggressive scan rate begins affecting production systems, the RoE defines the halt procedure. When a critical vulnerability is found at 11 PM on a Friday, the RoE specifies who to call.
This guide covers every clause that should appear in a penetration testing rules of engagement document, what each clause protects against, and what happens in practice when it is missing.
Scope and rules of engagement are companion documents that together define the complete boundary of the engagement. They address different questions.
Scope defines what is tested: the specific systems, applications, user roles, environments, APIs, and IP ranges included in the assessment.
Rules of engagement define how testing is conducted: the techniques permitted, the techniques explicitly prohibited, the contacts for decisions and emergencies, the halt and escalation procedures, the timing and testing window constraints, the legal authorisation basis, and the data handling requirements.
Both documents should be completed, reviewed, and signed before testing begins. The penetration testing checklist before you start covers the full pre-engagement confirmation process. Penetration testing scope: how to define it before you start covers scope definition in detail. This post covers the rules of engagement specifically.
The first and most critical clause. The RoE must identify who is granting authorisation for the test and confirm that this person has legal authority to do so.
What it must include:
The name, title, and organisation of the authorising party. The scope of authorisation granted (must match the scope document). The period of authorisation (the testing window). An explicit statement that the authorising party has legal authority to grant permission to test the systems in scope.
Why authority matters: A project manager who commissions the engagement may not be the person with legal authority to authorise testing of the systems. In cloud environments, the systems may be hosted by a provider whose terms of service restrict security testing. If the person granting authorisation does not actually have that authority, the authorisation is invalid and the testing is unauthorised.
What goes wrong without it: A vendor conducts testing based on an email from a project manager. Testing disrupts a cloud service. The cloud provider investigates and determines that neither the project manager nor the testing vendor had authorisation under the terms of service. The violation is against the cloud provider's acceptable use policy, not just an internal operational issue.
Cloud provider authorisation: AWS, Azure, and GCP all have specific penetration testing policies. AWS does not require prior approval for testing customer-owned EC2 instances, RDS, CloudFront, and similar services, but prohibits testing of AWS-managed infrastructure and has specific prohibited techniques (DNS zone walking, DDoS testing). Azure requires notification for specific test types. GCP's policy allows customers to conduct security testing of their own infrastructure. The RoE should confirm which cloud providers host systems in scope and which provider-specific requirements apply.
The engagement should specify which techniques are explicitly permitted. This protects both parties: the tester knows what is authorised, and the organisation knows what to expect.
Categories to address:
Automated scanning: Is automated vulnerability scanning permitted? At what scan rate? Against production systems or staging only? Aggressive automated scanning of production systems can consume resources and affect availability. Many organisations restrict scan rates to avoid production impact.
Manual exploitation: Is active exploitation of discovered vulnerabilities permitted to demonstrate impact? Or should testers stop at identification and report potential vulnerabilities without confirming exploitability? Most engagements should permit exploitation: a finding confirmed through exploitation is worth significantly more than a potential finding from a scan signature match.
Privilege escalation: Is privilege escalation permitted? Local privilege escalation to root or SYSTEM? Domain privilege escalation from standard domain user to domain administrator? The answer should be yes for a thorough assessment, but it must be explicitly stated.
Credential attacks: Is password cracking against captured hashes permitted? Credential stuffing against authentication endpoints? Password spraying against Active Directory?
Social engineering: Is phishing, vishing, or physical intrusion in scope? Social engineering requires its own specific authorisation separate from technical testing authorisation. See social engineering penetration testing: testing your weakest link for the specific consent requirements social engineering engagements carry.
Wireless testing: Is wireless network testing in scope? Active association with wireless networks requires specific authorisation.
Physical security testing: Is physical access testing authorised? Tailgating, lock picking, badge cloning?
What the tester must not do, regardless of whether it might produce findings.
Standard prohibitions:
Denial-of-service testing: Production denial-of-service testing should be prohibited in virtually all engagements. The risk of service disruption outweighs the finding value in nearly every case. If DoS testing is specifically required (load balancer resilience, rate limiting validation), it should be explicitly authorised for a specific maintenance window.
Destructive data operations: Deleting, modifying, or corrupting data. Testing that requires demonstrating capability (can we write to this database?) should demonstrate through controlled means (write a test record with a clearly marked prefix) rather than destructive operations.
Exfiltrating real data: When testing demonstrates that data exfiltration is possible, testers should document what data could be extracted without actually extracting it, or extract only clearly synthetic test data. Real customer data, financial data, or personal data should not leave the test environment.
Persistence beyond the engagement window: Malware or backdoors installed for testing purposes should be explicitly noted, documented, and removed at the end of the engagement. The RoE should require a list of any persistence mechanisms installed during testing.
Third-party systems not in scope: Explicitly prohibit testing of systems belonging to third parties that share infrastructure, cloud providers' own infrastructure, and any system not listed in the scope document.
When testing is permitted to occur, and when it must stop.
What to specify:
The start and end dates of the authorised testing period. Whether testing is restricted to specific hours (business hours only, after-hours only, maintenance windows for specific test types). Whether specific dates are off-limits (end-of-quarter financial close periods, product launch weeks, scheduled maintenance windows).
Why testing windows matter: An automated scan running against production systems at 2 PM on a Tuesday produces different operational risk than the same scan at 2 AM on a Sunday. The security team receiving alerts from production systems during business hours without knowing a pentest is running creates unnecessary incident response work. Testing windows coordinate these expectations.
What goes wrong without it: The tester begins aggressive scanning at a time the organisation did not anticipate. The security operations team detects anomalous network traffic and escalates as a potential real incident. The incident response process activates, consuming hours of security team time, before someone realises the traffic is from the authorised penetration test.
Four contacts that must be identified before testing begins.
Primary technical contact: The person the tester calls during business hours for questions, access issues, or operational decisions. Must be reachable during testing hours and have authority to make operational decisions about the engagement.
Escalation contact: The person with authority to make decisions that exceed the primary contact's authority: approving scope expansion, authorising testing of newly discovered adjacent systems, stopping the engagement.
Emergency halt contact: Reachable 24 hours a day, 7 days a week. This is the person called if testing must stop immediately: the tester discovers an active breach, an exploit causes unintended production disruption, or a critical vulnerability is found that requires immediate notification.
Security operations notification contact: Whether the tester should proactively notify the security operations team when testing begins (so that generated alerts are understood as pentest activity rather than real incidents), and who that notification goes to.
What goes wrong without it: The tester discovers evidence suggesting that a real attacker has already compromised a system they are testing. This is an active breach situation that requires immediate escalation. Without a 24/7 emergency contact, the tester cannot reach anyone and faces the choice of continuing testing, stopping with no notification, or attempting to reach someone through non-urgent channels at midnight.
A sub-clause of escalation contacts, important enough to address separately. The RoE should specify what constitutes a critical finding requiring immediate notification, and what the notification procedure is.
What typically triggers immediate notification:
A vulnerability that allows unauthenticated access to systems containing sensitive data. Evidence of an existing breach or active attacker in the environment. A finding that could allow complete domain compromise. A vulnerability in a system the tester was not expecting to be as sensitive as it proved to be.
Notification procedure: When the tester discovers a critical finding, do they: notify the emergency contact immediately by phone? Send a secure written notification first? Document and report at the end of the day? The answer should depend on severity, with the most critical findings requiring immediate phone notification regardless of testing hours.
What goes wrong without it: The tester exploits a vulnerability and gains access to a production database containing customer payment data. They document the finding and include it in the final report delivered two weeks later. In the two weeks between discovery and delivery, an actual attacker exploiting the same vulnerability could cause significant harm that the timely notification would have allowed the organisation to prevent.
How testing stops when something unexpected happens.
The halt signal: A specific mechanism for the organisation to signal the tester to stop all testing immediately. This might be a phone call, a specific email address, or a dedicated Signal message. The tester must acknowledge the halt signal within a defined time window (fifteen minutes is common) and stop all active testing.
Tester self-halt: When does the tester halt on their own initiative? If testing is causing unintended production disruption. If the tester discovers systems that appear to be more sensitive than the scope suggested. If active exploitation causes unintended side effects. The RoE should establish that the tester will halt and notify when these situations arise rather than continuing.
Post-incident procedures: If testing causes an incident, what happens? Who documents the incident? Who conducts the post-incident review? Is the tester expected to participate in the root cause analysis?
What goes wrong without it: Aggressive scanning causes a production application to become unavailable. The operations team restarts the application and investigates. Without a defined halt procedure, the tester continues scanning. The application goes down again. The cycle repeats until someone happens to make the connection that the pentest is the cause.
What happens to data the tester accesses during the engagement.
Data the tester encounters:
Credentials: Credentials captured during exploitation must not be stored in plaintext beyond the testing period and must not be used for purposes outside the engagement.
Personal and sensitive data: If testing produces access to customer data, financial data, or personal data, the tester should document what was accessible without retaining copies of the actual data. The RoE should specify exactly what may be retained and for how long.
Testing evidence: Screenshots, request logs, and exploitation evidence retained for the report. These constitute sensitive security information and should be transmitted and stored securely.
Report confidentiality: The penetration test report is a document that describes exploitable vulnerabilities in the organisation's systems. It should be treated as strictly confidential, transmitted encrypted, and retained securely by both parties with defined retention and destruction timelines.
What goes wrong without it: A penetration tester retains a copy of credentials captured during an engagement for several months after the engagement closes. The tester's own systems are later breached. The retained credentials from the client's environment are exposed in the breach.
Different engagement types require additional RoE provisions beyond the baseline above.
Network and infrastructure testing: Scan rate limitations for production network testing to avoid congestion. Maintenance window requirements for specific exploit types (privilege escalation against production domain controllers, for example). See network penetration testing: what it covers and how it's done for the network-specific testing methodology that these provisions govern.
OT and industrial control system testing: Safety contacts with physical plant authority. Passive-first requirements before any active testing. Digital twin or lab environment requirements for controller-level exploitation. The OT penetration testing guide covers the full OT-specific constraint set that these provisions address.
Red team exercises: Whether the blue team (internal security operations) is aware of the exercise or operating blind. The specific objectives and success criteria for the campaign. Whether the red team may conduct physical intrusion or social engineering against specific individuals. Red team RoE provisions are substantially more complex than standard pentest RoE. Red team vs. penetration testing: what's the real difference covers the distinctions in engagement type that drive these differences.
Compliance-driven testing: When the engagement must produce evidence satisfying a specific framework (PCI DSS, SOC 2, ISO 27001), the RoE should reference the specific compliance requirements and confirm that the engagement methodology satisfies them. PCI DSS penetration testing requirements explained covers the specific requirements that shape PCI-scoped RoE provisions.
A penetration testing rules of engagement document is complete when it addresses all of the following:
Legal authorisation:
Permitted and prohibited techniques:
Testing window:
Contacts:
Critical findings:
Halt procedures:
Data handling:
Engagement-specific provisions:
For the complete pre-engagement picture including scope definition alongside the RoE, the penetration testing checklist before you start covers both dimensions and the full confirmation process.
For penetration testing services in the US, VAPT services, and PTaaS where RoE and scope are handled as part of a structured pre-engagement process, the 10x Pentest platform covers how continuous testing eliminates most of the per-engagement RoE negotiation overhead. See pricing or get in touch to discuss structuring an engagement with a clear RoE from the start.
Q1. What are penetration testing rules of engagement?
Penetration testing rules of engagement is a formal agreement that defines how a penetration test is conducted: which techniques are permitted, which are explicitly prohibited, who the contacts are for decisions and emergencies, when testing may occur, how critical findings are reported, how testing halts in an emergency, and how data accessed during testing is handled. It is a companion to the scope document (which defines what systems are tested) and together these two documents create the complete authorisation and operational framework for the engagement.
Q2. Why do penetration testing rules of engagement matter legally?
Penetration testing without proper written authorisation can constitute unauthorised access to computer systems under the Computer Fraud and Abuse Act in the US, the Computer Misuse Act in the UK, and equivalent legislation in other jurisdictions. The rules of engagement document, signed by someone with legal authority to grant permission to test the specified systems, establishes the authorisation that protects both the organisation and the testing vendor if any aspect of the engagement is later questioned. Without it, even a well-intentioned penetration test can create legal exposure if something unexpected occurs.
Q3. What should be in a penetration testing rules of engagement document?
A complete RoE document covers: legal authorisation (who authorises the test and what authority they have); permitted and prohibited techniques (what the tester may and may not do); testing window (when testing is authorised and any time restrictions); contacts (primary technical, escalation, and 24/7 emergency halt contacts); critical finding notification procedures; halt procedures (when and how testing stops in an emergency); data handling requirements (what happens to credentials and sensitive data encountered during testing); and any engagement-specific provisions (cloud provider policies, OT safety requirements, social engineering consent, compliance requirements).
Q4. Do cloud environments require special rules of engagement provisions?
Yes. AWS, Azure, and GCP each have specific acceptable use and penetration testing policies. AWS does not require prior approval for testing customer-owned instances but prohibits testing of AWS-managed infrastructure. Azure requires notification for specific test types. GCP allows security testing of customer-owned infrastructure. The rules of engagement should identify which cloud providers host systems in scope and explicitly confirm that the testing methodology complies with each provider's policies. Testing cloud infrastructure in ways that violate provider terms of service creates liability for the organisation and the testing vendor, regardless of organisational authorisation.
Q5. How does the rules of engagement document differ for red team exercises versus standard penetration tests?
Red team exercise RoE is substantially more complex than standard penetration test RoE because red team exercises involve sustained adversarial campaigns rather than scoped assessments. Key differences: whether the internal security team is aware of the exercise (which determines whether the exercise tests detection capability realistically); specific campaign objectives and success criteria rather than scope boundaries; authorisation for social engineering against specific individuals or roles; physical intrusion provisions; longer testing windows; and explicit provisions for what happens when the blue team detects the red team. Standard penetration test RoE is more straightforward because the scope, techniques, and timeline are more tightly bounded.
Cloud security assessments cover IAM configuration, network controls, storage access, workload security, and logging. This guide maps what each domain tests and what findings look like.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 
Kubernetes penetration testing covers RBAC misconfigurations, privileged pods, API server exposure, supply chain weaknesses, and container escape paths. This guide maps what each test covers.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
