Before You Hack Anything — How Penetration Testers Define Scope and Rules of Engagement

Most people think penetration testing starts with running tools — Nmap, Metasploit, Burp Suite. But any experienced tester will tell you that the most important work happens before a single packet is sent.

If you walk into an engagement without a clearly defined scope and a signed Rules of Engagement document, you are not a penetration tester. You are just someone breaking into systems without permission.

I worked through a realistic client scenario — a multinational manufacturing company with 5,000 employees, OT/ICS systems, a recent ransomware incident, legacy infrastructure, and a legal team that was already nervous. The client handed over a minimal RFP with almost no details and said: figure it out.

This article walks through how I approached it — the scope decisions, the RoE fields, and five real ethical dilemmas that came up during planning.

The Client Situation

Target Widgets — a manufacturing company operating across three countries. Here is what the client told us:

• Production runs 24/7. Downtime costs approximately $50,000 per hour
• Manufacturing systems are network-connected, with OT/ICS devices present
• Some legacy systems are fragile and may fail under aggressive scanning
• The internal network is largely flat (minimal segmentation)
• Third-party vendor VPN connections exist
• Cloud services are in use but not fully inventoried
• A ransomware incident occurred last year
• Asset inventory is incomplete
• Some systems run unsupported operating systems
• HR, payroll, and engineering design data are on the network
• The legal team is specifically concerned about data being copied

Their ask: find security flaws from improper policies, poor patch management, and implementation weaknesses. That was the entire RFP.

No technical details. No system list. No defined boundaries.

Why Scope Definition Is Not Optional

When a client gives you a vague RFP, the instinct might be to start broad and test everything. That is exactly the wrong approach.

Consider what happens without a defined scope in this engagement:

• You scan the ERP system aggressively and it crashes — production halts and the client loses $50,000 in the first hour
• You pivot through a vendor VPN and land in a third-party network — you have now tested systems you had no authorization to touch
• You find exposed employee records and download them as proof — you have just violated data protection law regardless of client intent
• You reach manufacturing control systems and probe them — a safety system trips and physical equipment is affected

None of these are hypothetical. All of them have happened in real engagements. Scope documents and RoE are what prevent them.

Building the Scope Document

The scope document answers one fundamental question: what are we allowed to test, and what are we not?

1. Engagement Objectives

The goal for this engagement was to identify security vulnerabilities arising from:

• Weak or missing security policies
• Poor patch management and legacy system exposure
• Insecure network architecture (flat network, vendor access)
• Application and credential weaknesses
• Susceptibility to social engineering

2. Test Types Included

3. In-Scope Assets

• Corporate IT network (office systems, workstations, servers)
• Active Directory and identity infrastructure
• Web-facing applications and public-facing services
• Email and collaboration systems
• Approved cloud assets (inventoried subset only)
• VPN infrastructure (company-side only)

4. Out-of-Scope Assets

• OT/ICS and manufacturing control systems — excluded unless separately authorized
• Vendor VPN endpoints — excluded; third-party written consent required
• Safety-critical systems connected to the network
• Any cloud asset not appearing on the approved inventory list
• HR and payroll systems — read-only credentialed access only; no data extraction

5. Network Scope

The flat network architecture was noted as a significant risk factor. Because the internal network has minimal segmentation, lateral movement from a compromised workstation could reach production systems. This was documented and the client was explicitly warned that pivot paths into OT/ICS segments would be halted and reported rather than followed.

6. Cloud Scope

Cloud services were only partially inventoried. The decision: only systems appearing on the approved cloud asset list are in scope. Any cloud asset discovered during testing that was not on the list would be flagged and reported — not tested.

7. OT/ICS Scope Decision

Excluded from active testing.

OT/ICS systems were reachable from the network, but the risk of disrupting safety systems or manufacturing equipment was too high to justify active probing. The engagement would document reachability as a finding. Any deeper assessment of OT/ICS would require a separate, specialized engagement with appropriate safety controls in place.

8. Social Engineering Scope

Included with restrictions:

• Phishing simulation approved for IT staff only
• No pretexting involving employee personal information
• Physical tailgating or on-site social engineering excluded

9. Allowed Techniques

• Ping sweeps and host discovery
• Port scanning (rate-limited to avoid triggering IDS/IPS shunning)
• Vulnerability scanning (non-aggressive profiles on sensitive systems)
• Credentialed scanning where approved
• Manual exploitation of confirmed vulnerabilities
• Password spraying (with lockout thresholds respected)

10. Prohibited Techniques

• Denial of Service attacks of any kind
• Exploits that modify or delete production data
• Data exfiltration of real sensitive records
• Testing third-party or vendor systems
• Aggressive scanning of legacy ERP without specific approval
• Physical access attempts

11. Operational Constraints

• All testing occurs outside business hours unless otherwise agreed
• Emergency stop contact must be reachable at all times
• Any finding that creates immediate risk to production must be reported before the daily debrief
• No testing during scheduled production peaks

12. Assumptions

Since the client's RFP was minimal, the following assumptions were documented:

• The company-owned network ranges provided will be treated as the network boundary
• Any system not on the approved asset list is assumed out of scope
• Vendor-connected systems are assumed third-party until written consent is received
• Cloud assets not in the approved inventory are assumed out of scope

Completing the Rules of Engagement Document

The RoE is the operational agreement. It covers who, when, how, and what happens when things go wrong.

Key fields and how I filled them:

The IDS/IPS shunning issue deserved special attention. If the target network automatically blocks the testing team's IP addresses (as many enterprise networks do), this could look like a denial of service on the testing side. The mitigation: provide the client with all attack system IPs before testing begins, request whitelist entries, and define what happens if shunning occurs anyway — pause, notify, resume only after confirmation.

Five Decision Scenarios From the Real Engagement

This is where scoping becomes genuinely hard. These are not hypothetical — they are the real edge cases that come up in engagements like this one.

Scenario 1 — Sensitive Data Exposure

Situation: During testing, I discover exposed employee records. The client says: "Download several thousand records as proof."

Decision: Refuse.

The RoE is explicit — data encountered on compromised hosts is to be viewed only to confirm access, not extracted. Downloading thousands of employee records creates legal liability for the testing team, violates data protection regulations (GDPR, PDPA, and others depending on jurisdiction), and goes beyond what is necessary to demonstrate the finding.

Appropriate evidence level: A screenshot showing the directory or file listing, a record count, and a sample of non-sensitive metadata. The existence of the exposure is the finding — the records themselves are not the deliverable.

RoE rule: "Sensitive data encountered during testing shall not be copied, transmitted, or retained beyond what is minimally necessary to document the finding."

Scenario 2 — Fragile ERP System

Situation: The legacy ERP may crash under vulnerability scanning.

Decision: Include in scope with strict restrictions.

Excluding it entirely would leave a major system unexamined. But running a standard vulnerability scan against a fragile legacy system that the client has warned may fail is not acceptable.

Restrictions applied:

• Manual inspection and credentialed scanning only (no aggressive unauthenticated probes)
• Rate-limited to the lowest possible scan intensity
• Tested only during the lowest-traffic window with a dedicated rollback plan confirmed with the client
• Any sign of instability during testing triggers an immediate stop and client notification

Scenario 3 — OT/ICS Network

Situation: Manufacturing control systems are reachable from the network.

Decision: Exclude from active testing. Document reachability as a critical finding.

The risk profile here is fundamentally different from IT systems. OT/ICS environments often run proprietary protocols and real-time control loops that were never designed to handle network probe traffic. A scan packet in the wrong place can trip a safety interlock or halt a physical process.

Conditions required for any future OT assessment:

• Separate engagement with OT/ICS-specialized testers
• Physical safety controls in place before any digital probing
• Written authorization from both IT and operational management
• Testing on isolated or mirrored systems where possible

Scenario 4 — Vendor VPN

Situation: A third-party vendor's network is connected via VPN.

Decision: Exclude entirely.

Authorization to test Target Widgets does not extend to systems owned by another organization. Testing through the vendor VPN without the vendor's explicit written consent would be unauthorized access to a third-party network — regardless of what the client requested.

Process: Flag the vendor connection as an attack surface finding. If the client wants the vendor-side tested, that requires a separate authorization letter from the vendor and a new scope agreement.

Scenario 5 — Unknown Cloud Assets

Situation: Cloud services are in use but not fully inventoried.

Decision: Only test what is on the approved list. Treat everything else as out of scope.

Cloud assets not in the approved inventory may belong to shadow IT, individual business units, or even third parties. Testing an unknown cloud resource could mean testing a system owned by a cloud provider or SaaS vendor — again, unauthorized access.

Process: Deliver a finding that the cloud inventory is incomplete. Recommend a cloud discovery exercise before any cloud-focused penetration testing is conducted. This becomes a separate recommendation in the report.

The Bigger Picture — Why This Work Matters

Pre-engagement documentation is often seen as paperwork. It is not. It is the difference between a professional engagement and a liability incident.

Every decision made in a scope document is a risk decision. You are drawing a line and saying: on this side of the line, we have authorization and we accept the risk of testing. On the other side, we do not.

For this engagement with Target Widgets, the most important decisions were:

• Protect production — a $50,000/hour downtime cost changes how you approach every technical decision
• Exclude what you cannot control — OT/ICS, vendor systems, unknown cloud
• Document everything you assume — because when something goes wrong, your assumptions are what you are judged against

How to Verify Your Own RoE Is Complete

Before signing off on any RoE document, check these:

✅ All attack system IPs are listed and whitelisted
✅ Testing hours are explicitly defined
✅ Emergency stop contacts are reachable 24/7
✅ Data handling policy is written, not implied
✅ Third-party systems are explicitly excluded or separately authorized
✅ IDS/IPS shunning scenario is addressed
✅ DoS and dangerous exploits are explicitly prohibited
✅ Sensitive data evidence standard is defined
✅ All parties have signed

What I Learned

Ambiguity in the RFP is not the client's fault — many clients genuinely do not know what they are buying. Your job as a tester is to surface the questions they did not know to ask.

The RoE protects you as much as the client — if something goes wrong and you have a signed document with explicit boundaries, you are in a defensible position. Without it, you are not.

Flat networks are a scope nightmare — when every system can potentially reach every other system, you cannot define scope by IP range alone. You have to define scope by intent and document lateral movement limits explicitly.

Cloud is a permanent unknown — if a client cannot tell you what cloud systems they have, they cannot authorize you to test them. Incomplete inventory is itself a finding.

Common Mistakes in Pre-Engagement Documentation

Conclusion

A penetration test that damages production, leaks employee data, or triggers a safety system is not just a failed test — it is a legal and professional catastrophe. The scope document and the RoE are what prevent that.

The work of defining boundaries, documenting assumptions, and getting everything signed before testing begins is unglamorous. But it is the foundation that every technical phase of the engagement rests on.

If your RoE is not solid, your test results are not either.