This chapter covers the critical legal and contractual foundations that govern every penetration test: scope, rules of engagement (RoE), and legal considerations. For the PT0-002 exam, approximately 5-10% of questions touch on planning and scoping, with direct emphasis on defining scope, obtaining authorization, and understanding legal constraints. Mastering these concepts ensures you can distinguish between a properly authorized penetration test and an illegal intrusion, a distinction that is both exam-critical and career-critical.
Jump to a section
A penetration test is like a medical autopsy performed by a forensic pathologist. Before any incision, the pathologist must obtain a signed consent form from the next of kin, specifying exactly which organs may be examined, what procedures are allowed, and the time window for the examination. This is the legal equivalent of the Rules of Engagement (RoE). The scope document is like the autopsy request form: it names the decedent (target systems), lists the specific questions to answer (testing objectives), and excludes any areas not listed (out-of-scope assets). The pathologist works within a sterile, controlled environment (the morgue) analogous to a dedicated testing network. If the pathologist accidentally cuts into an organ not listed on the consent form, they have violated the agreement and may face legal consequences. Similarly, a penetration tester who touches an out-of-scope system breaches the RoE and invalidates the entire engagement. The signed consent is the tester's authorization to proceed; without it, any testing is illegal. The chain of custody for evidence mirrors the tester's logs and screenshots. Just as a pathologist must follow strict protocols to ensure findings hold up in court, a tester must adhere to the RoE to ensure the report is admissible in a legal or compliance context. Any deviation can lead to lawsuits, loss of certification, or criminal charges.
What Are Scope, Rules of Engagement, and Legal Considerations?
Scope, Rules of Engagement (RoE), and legal agreements form the contractual and operational framework that transforms a penetration test from a potential criminal act into a legitimate, authorized security assessment. Without these elements, any testing performed on systems you do not own constitutes unauthorized access, which is illegal under laws such as the Computer Fraud and Abuse Act (CFAA) in the US, the Computer Misuse Act in the UK, and similar legislation worldwide.
Scope defines the boundaries of the test: which IP addresses, domains, applications, physical locations, and types of testing are included. It also explicitly lists what is out of scope. Scope is typically documented in a Statement of Work (SoW) or a Scope of Work document. Key elements include:
In-scope targets: IP ranges, URLs, wireless SSIDs, physical locations
Out-of-scope targets: production systems explicitly excluded, third-party systems, employee personal devices
Testing types allowed: network penetration, web application testing, social engineering, physical security assessment
Time window: start and end dates, including any blackout periods (e.g., no testing during peak business hours)
Rules of Engagement detail the specific constraints and procedures the tester must follow. RoE answers questions like:
Are denial-of-service (DoS) attacks permitted? (Almost never without explicit written approval)
What is the maximum impact allowed? (e.g., no service disruption, no data modification)
What are the escalation procedures if a critical vulnerability is discovered?
What communication channels are used for updates?
What is the process for handling sensitive data discovered during testing (e.g., PII, credit card numbers)?
What are the hours of testing? (e.g., 9 PM to 5 AM local time)
What is the point of contact for the client?
Legal Considerations include:
The signed contract or SoW that includes scope and RoE
A signed authorization letter (often called a "get out of jail free" card) that the tester can present to law enforcement or internal security if questioned
Insurance requirements (professional liability, cyber liability, errors & omissions)
Compliance with relevant regulations (GDPR, HIPAA, PCI DSS) regarding data handling and breach notification
Non-disclosure agreements (NDAs) to protect client data
How Scope and RoE Work Internally
From a process perspective, the lifecycle of a penetration test engagement follows these phases:
Pre-engagement Interaction: The tester (or their organization) meets with the client to understand objectives, identify assets, and negotiate terms. This results in a signed SoW and RoE document.
Scope Finalization: The client provides a list of in-scope targets. The tester performs a discovery scan to verify the scope and identify any discrepancies (e.g., a new IP that was not listed). Any deviation must be approved in writing.
Rules of Engagement Agreement: Both parties agree on the rules. Common RoE include:
- No social engineering without explicit approval - No phishing campaigns without prior coordination - No exploitation of vulnerabilities that could cause data loss or service interruption - Immediate notification of any critical findings (e.g., remote code execution) - Use of specific testing tools or avoidance of certain aggressive techniques
Testing Execution: The tester operates strictly within the defined scope and RoE. Any action outside these boundaries constitutes a breach of contract and potentially a crime.
Reporting: The final report includes evidence of findings, but only for in-scope systems. Any accidental discovery on an out-of-scope system should be reported to the client but not included in the formal report unless authorized.
Key Components, Values, Defaults, and Timers
While there are no technical defaults like TCP timers, there are industry-standard practices and common values in RoE:
Testing window: Often defined as a specific date range (e.g., 2025-03-01 to 2025-03-15) or as business hours (e.g., 9:00 AM – 5:00 PM local time). Some engagements allow 24/7 testing.
Blackout periods: Days when no testing is allowed (e.g., during financial quarter-end, holiday sales).
Notification time: Typically within 1 hour of discovering a critical vulnerability.
Data handling: Any PII discovered must be immediately deleted or securely transferred to the client. Screenshots must not include sensitive data if avoidable.
Tool restrictions: Some clients prohibit specific tools (e.g., Metasploit exploits that are destructive) or require pre-approved tool lists.
Configuration and Verification Commands
There are no CLI commands for scope and RoE themselves, but tools like Nmap can be used to verify scope:
nmap -sL -n 192.168.1.0/24 # List scan to verify host discovery without sending packetsFor web testing, a simple curl to confirm reachability:
curl -I https://in-scope.example.comAlways verify that out-of-scope IPs are not accidentally scanned. Use exclusion lists in tools:
nmap -iL in-scope.txt --excludefile out-of-scope.txt -sVInteraction with Related Technologies
Scope and RoE intersect with: - Vulnerability scanners: Configuration files must restrict scanning to in-scope IPs and avoid dangerous plugins. - Proxy tools (Burp Suite): Scope settings in Burp Suite limit interception to specific URLs. - Web application firewalls (WAFs): The client may whitelist the tester's IP to avoid blocking. - SIEM systems: The client's SOC may monitor for the tester's activities; RoE should include notification to the SOC.
Legal Framework Details
Computer Fraud and Abuse Act (CFAA): 18 U.S.C. § 1030. Makes unauthorized access to a protected computer a crime. The key defense is "authorization" — the signed contract provides that authorization.
Computer Misuse Act 1990 (UK): Similar to CFAA; unauthorized access is illegal.
GDPR: If testing involves personal data, the tester may be a data processor and must have a data processing agreement. Any data breach must be reported to the supervisory authority within 72 hours.
PCI DSS: Requirement 11.3 requires penetration testing at least annually and after significant changes. The test must be performed by a qualified tester (e.g., QSA or ASV) and scope must align with the CDE (cardholder data environment).
Common Pitfalls
Scope creep: The tester finds a vulnerability on an out-of-scope system and decides to test it. This is a violation.
Insufficient authorization: The signatory does not have the authority to authorize testing (e.g., a department head but not the legal team).
Oral agreements: Verbal approval is not sufficient; everything must be in writing.
Missing escalation procedures: The tester discovers a critical vulnerability but has no defined process to report it immediately, leading to potential damage.
Exam Relevance
For PT0-002, you must be able to:
Identify the components of a proper scope document
Understand the difference between scope and RoE
Recognize legally required elements: signed authorization, insurance, NDA
Apply these concepts in scenario-based questions (e.g., "A client asks you to test a range of IPs but you discover an interesting server outside that range. What should you do?")
Know the consequences of violating RoE: contract termination, legal liability, certification revocation
Summary of Key Terms
Statement of Work (SoW): Defines scope, deliverables, timeline, and cost.
Rules of Engagement (RoE): Defines how testing is conducted.
Authorization Letter: A physical document signed by an authorized representative, granting permission to test.
Out of Scope: Any system or activity not explicitly authorized.
Blackout Period: Time when testing is prohibited.
Escalation Procedure: Process for reporting critical findings.
References
PT0-002 Objective 1.2: Given a scenario, analyze the target environment and scope for a penetration test.
PT0-002 Objective 1.3: Explain the importance of legal concepts and compliance when performing a penetration test.
Initial Client Meeting
The tester meets with the client to understand the business objectives, identify critical assets, and discuss constraints. The tester asks about compliance requirements (PCI DSS, HIPAA, etc.), any prior testing, and the client's risk tolerance. The tester takes notes on the network topology, application architecture, and any third-party dependencies. This step establishes the foundation for the scope document.
Draft Scope Document
Based on the initial meeting, the tester drafts a scope document that lists in-scope IP addresses/ranges, URLs, wireless SSIDs, physical locations, and testing types (e.g., network, web, social engineering). Out-of-scope items are explicitly listed. The document includes the testing window (start and end dates) and any blackout periods. The draft is sent to the client for review.
Define Rules of Engagement
The tester and client agree on the rules: allowed techniques (e.g., no DoS), hours of testing, communication channels, escalation procedures for critical findings, data handling protocols, and tool restrictions. The RoE also specifies who the point of contact is and how to handle accidental discoveries (e.g., PII). The RoE is appended to the scope document.
Obtain Legal Authorization
The client provides a signed authorization letter on company letterhead, signed by an individual with legal authority (e.g., CISO, VP of IT, or legal counsel). The letter explicitly grants permission to perform the described testing on the listed systems. The tester also signs an NDA if required. Insurance certificates are exchanged if stipulated in the contract.
Verify Scope with Discovery
Before active testing, the tester performs a passive discovery scan (e.g., using Nmap ping sweep) to verify that the in-scope IPs are reachable and that no out-of-scope systems are inadvertently included. Any discrepancies are reported to the client and resolved in writing. The tester also checks that testing tools are configured to respect scope boundaries.
Enterprise Scenario 1: PCI DSS Compliance Testing
A large e-commerce company must perform an annual penetration test to maintain PCI DSS compliance. The scope is carefully limited to the cardholder data environment (CDE): specific IP ranges hosting payment processing servers, the web application handling credit card inputs, and the database storing encrypted card numbers. Out-of-scope includes the corporate network, employee workstations, and public-facing marketing website. The RoE prohibits any testing that could cause service interruption, especially during peak shopping hours (November-December). The testers are required to use a dedicated testing VLAN that is logically isolated from production. During the test, the tester discovers that a web application firewall (WAF) is blocking their scans. According to RoE, they must contact the client's SOC to temporarily whitelist their IP. The final report only includes findings from the CDE; any accidental discovery on the corporate network is reported separately and excluded from the formal compliance report. Common misconfiguration: The client accidentally includes a public DNS server in the scope, which is a third-party service. The tester must flag this and obtain written authorization before testing it, as testing third-party systems without permission could violate the CFAA.
Enterprise Scenario 2: Red Team vs. Penetration Test
A financial institution wants a full-scope red team exercise, including social engineering, physical intrusion, and network exploitation. The scope is broad: all internal IPs, all corporate web applications, and the physical headquarters building. The RoE allows phishing but prohibits physical destruction of property. The tester must sign a strict NDA and carry an authorization letter at all times. During the physical penetration test, the tester is stopped by security. They present the authorization letter, which includes a 24-hour contact number for the CISO. The security team verifies and allows entry. A common mistake: The tester forgets to coordinate with the SOC, so the SOC treats the tester's activities as a real incident and calls law enforcement. The RoE should include a notification to the SOC before testing begins. Another pitfall: The tester discovers a critical vulnerability in a third-party SaaS application used by the client. The scope does not include that SaaS provider. The tester must stop and inform the client; further testing requires authorization from the SaaS provider, which is unlikely to be granted.
Scenario 3: Government Contract
A defense contractor requires a penetration test of a classified network. The scope is extremely narrow: only three specific servers in a closed lab environment. The RoE forbids any data exfiltration and requires the tester to use only government-issued tools. The tester must be cleared to the appropriate security level (e.g., Secret or Top Secret). The authorization letter must be signed by the program manager and approved by the security office. The tester cannot take any notes or screenshots out of the lab; all evidence stays in the lab. A common issue: The tester accidentally scans an IP that belongs to a different government agency's network. This is a serious breach that could lead to revocation of security clearance and legal action. The tester must immediately stop and report the incident.
What PT0-002 Tests on This Topic
Objective 1.2: "Given a scenario, analyze the target environment and scope for a penetration test." This includes identifying appropriate scope, RoE, and legal requirements. Objective 1.3: "Explain the importance of legal concepts and compliance when performing a penetration test." The exam tests your ability to apply these concepts in scenario-based questions. Expect questions where you must choose the correct course of action when scope or RoE is violated.
Common Wrong Answers and Why Candidates Choose Them
"Proceed with testing anyway" when a tester discovers an out-of-scope system with a vulnerability. Candidates think they are being helpful by including it. Reality: This is a breach of contract and potentially illegal. The correct action is to stop and inform the client.
"Verbal approval is sufficient" when the client says "go ahead" but hasn't signed anything. Candidates underestimate the legal requirement for written authorization. Reality: Verbal approval is not defensible in court. You must have a signed document.
"Include all findings in the report" even for out-of-scope systems. Candidates think full disclosure is always best. Reality: Out-of-scope findings should be reported separately or not at all unless authorized. Including them in the formal report can cause legal issues.
"DoS testing is allowed unless explicitly prohibited" – a dangerous assumption. Candidates may think that because the RoE doesn't mention DoS, it's allowed. Reality: DoS is almost never allowed without explicit written permission because it can cause service disruption. The default is to prohibit DoS unless specifically authorized.
Specific Numbers, Values, and Terms That Appear on the Exam
The term "get out of jail free card" is used in the exam to refer to the authorization letter.
PCI DSS requires testing at least annually (every 12 months) and after significant changes.
GDPR breach notification must occur within 72 hours.
The CFAA is the US law most often referenced.
The Computer Misuse Act 1990 is the UK equivalent.
Edge Cases and Exceptions
Third-party systems: If a client's application uses a third-party API, testing that API without the third party's permission is out of scope. The tester must only test the client's integration, not the third-party service.
Cloud environments: The tester must ensure they have authorization from the cloud provider (e.g., AWS penetration testing policy) as well as the client. Some providers require prior notification.
Mergers and acquisitions: If the client acquires a new company during the test, the new assets are not automatically in scope. The scope must be updated in writing.
Critical vulnerabilities: If a tester discovers a critical vulnerability that could cause immediate harm, the RoE should specify an emergency contact. Testing must stop until the issue is communicated.
How to Eliminate Wrong Answers
Look for the answer that prioritizes written authorization and adherence to scope.
Eliminate any answer that involves testing beyond the defined scope without explicit written permission.
If the question involves legal consequences, the correct answer will reference signed documents and contracts.
Beware of answers that sound helpful but violate RoE (e.g., "test the out-of-scope system because it's a critical risk").
Always obtain a signed authorization letter before starting any penetration testing activity.
Scope must explicitly list in-scope and out-of-scope targets; never test beyond scope without written approval.
Rules of Engagement define the allowed techniques, testing hours, escalation procedures, and data handling rules.
DoS testing is prohibited by default unless explicitly authorized in writing.
Verbal approval is not legally sufficient; all authorizations must be documented in writing.
Out-of-scope findings must be reported to the client separately and not included in the main report unless authorized.
The authorization letter is often called a 'get out of jail free card' and should be carried during physical testing.
Compliance with regulations like PCI DSS, HIPAA, and GDPR may impose additional scope and RoE requirements.
These come up on the exam all the time. Here's how to tell them apart.
Scope of Work (SoW)
Defines what is tested (targets, types of testing, time window).
Focuses on the boundaries of the test.
Lists in-scope and out-of-scope assets.
Is part of the contract/SoW.
Answers 'what' and 'where'.
Rules of Engagement (RoE)
Defines how testing is conducted (techniques, hours, communication).
Focuses on constraints and procedures.
Specifies allowed techniques, escalation procedures, data handling.
Is a separate document or appendix to the contract.
Answers 'how' and 'when'.
Mistake
Verbal approval from a manager is sufficient to start a penetration test.
Correct
Verbal approval is not legally defensible. The tester must have a signed authorization letter from an individual with legal authority (e.g., CISO, legal counsel). Without written authorization, the tester could be prosecuted for unauthorized access under laws like the CFAA.
Mistake
If a system is vulnerable and out of scope, it's ethical to test it and include it in the report.
Correct
Testing an out-of-scope system violates the contract and potentially the law. The tester must immediately stop and inform the client. The client can then decide whether to expand the scope in writing. Including such findings in the report without authorization is a breach of the rules of engagement.
Mistake
The rules of engagement are optional guidelines; the tester can use professional judgment to deviate.
Correct
The RoE are binding contractual terms. Deviating from them without written consent is a breach of contract and can lead to legal liability, termination of the engagement, and loss of professional reputation. The tester must adhere strictly to the RoE.
Mistake
A penetration test automatically includes social engineering and physical security testing.
Correct
Social engineering and physical testing are separate testing types that must be explicitly included in the scope and RoE. If not mentioned, they are out of scope. Many clients do not allow social engineering due to employee privacy concerns.
Mistake
Once the contract is signed, the tester has unlimited access to all client systems for the duration of the engagement.
Correct
Access is strictly limited to the in-scope systems defined in the scope document. The tester cannot access any other systems, even if they are on the same network. The scope is not a blanket authorization.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Scope defines the boundaries of the test: which systems, networks, applications, and locations are included, and what types of testing are allowed. Rules of Engagement define how the testing is conducted: the specific techniques allowed, hours of testing, communication protocols, escalation procedures for critical findings, and data handling rules. Scope answers 'what' and 'where'; RoE answers 'how' and 'when'. Both are essential for a legal and controlled engagement.
The tester must immediately stop testing that system and inform the client point of contact. They should not proceed with further testing on the out-of-scope system. The client can then decide whether to expand the scope in writing to include that system. If the client authorizes it, the tester obtains a signed amendment to the scope document before continuing. The finding should be reported separately and not included in the main report unless authorized.
No, verbal approval is not sufficient. The tester must have a signed authorization letter or contract that explicitly grants permission to test the defined scope. Verbal approval is not legally defensible; without written authorization, the tester could be prosecuted under computer crime laws such as the CFAA. Always obtain written, signed authorization before any testing begins.
It is a colloquial term for the signed authorization letter that a penetration tester carries during the engagement. The letter states that the tester has permission to perform security testing on the specified systems. It is used to present to law enforcement, internal security, or anyone who questions the tester's activities. The letter should include contact information for the client's authorized representative who can verify the authorization.
No, DoS testing should never be performed without explicit written permission from the client. DoS attacks can cause service disruption, data loss, and financial damage. Even if the rules of engagement do not explicitly prohibit DoS, the default assumption is that it is not allowed. The tester must obtain separate, written authorization that specifically permits DoS testing, including the scope and conditions.
Testing without authorization can lead to criminal charges under laws like the Computer Fraud and Abuse Act (CFAA) in the US, which carries penalties including fines and imprisonment. Civil lawsuits for damages are also possible. Additionally, the tester may lose professional certifications, face termination of employment, and suffer reputational damage. Always ensure proper authorization is in place.
PCI DSS Requirement 11.3 requires that penetration testing be performed at least annually and after any significant changes to the cardholder data environment (CDE). The scope of the test must cover the CDE and any connected systems that could impact the security of the CDE. The tester must be qualified (e.g., a QSA or ASV) and the test must be performed according to a methodology that includes both network-layer and application-layer testing. The RoE must align with PCI DSS requirements, such as not causing service disruption.
You've just covered Scope, Rules of Engagement, and Legal — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?