Penetration Testing Pre-Engagement: Scoping and Agreements

Pre-engagement is the discovery pass that happens before anyone runs nmap. You clarify what the client wants to learn, list the assets, pick an assessment style, and confirm who owns each target. Only after that does penetration testing rules of engagement turn the scope into day-to-day testing rules.

This is a planning and documentation lesson; there are no exploitation commands to run. It matches what CompTIA PenTest+ tests under engagement management: objectives, agreements, target selection, and shared responsibility. It is not legal advice and it is not a substitute for your firm's counsel.

What is penetration testing pre-engagement?

PTES pre-engagement and NIST SP 800-115 both treat planning as a gate: define goals, boundaries, and deliverables before tools touch production.

The PTES customer interaction phase opens with questions about why the test is happening, what the client wants tested, and what type of testing they expect. Initial conversations establish why the customer wants the test and what they expect. The exact commercial sequence varies: preliminary scoping may occur before contracting, while detailed technical scoping may happen after an NDA or agreement is already in place.

The output is a scope package you can attach to the RoE. If you skip straight to scanning, you will eventually hit a subnet, SaaS integration, or third-party API nobody intended to include.

Penetration testing pre-engagement checklist

Use this list during kickoff calls and scoping workshops. Testing windows, allowed techniques, stop conditions, and escalation belong in the companion rules of engagement guide, not here.

• What business or security question should the test answer?
• Is testing required for compliance, assurance, a release, or incident follow-up?
• Which IPs, CIDRs, domains, APIs, apps, cloud accounts, and physical locations are in scope?
• Which tester source IP addresses, VPN ranges, or assessment infrastructure should the client expect traffic from?
• Who owns each target?
• Which assets and third parties are explicitly excluded?
• Is production included, or staging only?
• Is the assessment black-box, gray-box, or white-box?
• Which credentials, VPN access, source code, or diagrams will the tester receive?
• Are WAFs, IDS/IPS, load balancers, and other intermediary systems part of the assessment?
• What deliverables are expected (report format, executive summary, retest window)?
• Are provider approvals or SaaS/cloud testing policies required?
• Are there blackout periods or operational constraints that must be carried into the RoE?
• Who can approve scope changes?
• Is retesting included, and for how long after delivery?

Close every open item or document it as an explicit assumption before active testing starts.

Define the engagement objective

Scope depends on what the client actually wants to learn. PTES asks why the penetration test is being performed, whether compliance drives it, and what the customer expects to be tested before you finalize boundaries.

Common objectives:

• External exposure: Can an unauthenticated Internet attacker gain access?
• Internal assessment: What can a compromised employee account reach?
• Web application: Can users cross authorization boundaries or reach sensitive data?
• Compliance-driven: Assess systems or controls required by a particular compliance or assurance program, according to that program's testing requirements.
• Pre-release: Find exploitable issues before a new application goes live.

The objective determines what belongs in scope. A broad /24 network test and a deep assessment of one business-critical application may involve similar effort even though the target counts look very different. PTES emphasizes that mismatch because clients often underestimate it during sales.

Document the objective in the SoW. When the objective shifts mid-engagement, treat that as a scope change (see below), not an informal expansion.

Choose an assessment type

The assessment type drives credentials, starting position, and what "success" looks like in the report.

Credentialed versus unauthenticated is orthogonal to black-box or gray-box labeling. A gray-box internal test might supply standard user accounts but not domain admin. A white-box code review might include repository access without network penetration.

Document the type in the SoW and repeat it in the RoE. If the client expects a black-box test but hands you domain admin on day one, clarify whether post-exploitation from that account is in scope.

Common engagement shapes:

• External network: black-box or gray-box against perimeter IPs and VPN portals
• Internal network: credentialed or unauthenticated inside the LAN or zero-trust segment
• Web application: URL list, authenticated and unauthenticated roles, API endpoints
• Wireless: named SSIDs and sites; physical presence may need separate authorization
• Social engineering: only when the SoW and RoE explicitly include phishing, vishing, or physical tests

Do not assume a technique is permitted when the governing documents do not address it; carry the question into the RoE or approved change process before using it.

Penetration testing agreement types

Commercial pentests stack several documents. Each answers a different question.

Confidentiality does not authorize testing. Detailed technical target lists are normally better placed in the engagement-specific SoW or scope appendix than in the overarching MSA. The SoW might say "external network penetration test, ten business days, PDF report" while the scope appendix carries 198.51.100.0/24 and app.example.com.

Confidentiality before sensitive exchange

Put appropriate confidentiality terms in place before architecture diagrams, credentials, or internal hostnames change hands. That may be a standalone mutual NDA or confidentiality clauses already in the MSA or procurement agreement.

Watch for one-way NDAs that only bind the tester. Mutual NDAs are common when both sides share architecture details. Confidentiality terms by themselves do not authorize testing; explicit testing authorization must appear in the governing engagement documents.

MSA versus SoW

The MSA is the umbrella. You might perform quarterly retests under one MSA with a fresh SoW each time.

When an MSA governs the engagement, the SoW commonly references it and points to the applicable scope appendix or target list.

Terms of service (ToS) and acceptable use

Cloud consoles, SaaS admin panels, and some security appliances carry provider ToS or acceptable-use policies. Client authorization to test a tenant does not override those provider rules.

When scope includes Microsoft 365, AWS, Salesforce, or a hosted WAF, note in the SoW that the client confirms provider testing policies are satisfied. The companion rules of engagement guide walks provider-specific nuances; pre-engagement is where you flag that the check is required.

Define and validate the scope

Ambiguous scope causes more disputes than any single missed vulnerability. Replace slogans with inventories, then confirm the client owns or may test each entry.

Weak scope lines:

• "All public-facing systems"
• "The corporate website and related infrastructure"
• "Anything in the DMZ"

Defensible scope lines:

Out-of-scope examples to name explicitly:

• payroll.internal.example.com and the HR VLAN
• Neighbor IPs on shared hosting outside the listed range
• Production payment gateway (test only the client's integration endpoint)
• Acquired subsidiary otherco.example unless legal confirms authority

List exclusions with the same precision as inclusions. "Do not test anything else" is weaker than naming the backup datacenter link and the SAP production VLAN.

Validate ownership before finalizing scope

PTES warns that a responding address may belong to another organization. Validate ranges and names before you treat them as in scope:

• Confirm IP or CIDR ownership or the hosting relationship (whois, client attestation, cloud console export).
• Confirm domains and subdomains belong to the client or are explicitly delegated for testing.
• Identify CDN front-ends, shared hosting, SaaS platforms, and managed services where the client controls only a tenant or configuration.
• Record cloud subscription, project, or account IDs rather than relying on DNS alone.
• Obtain third-party permission where the asset is not wholly client-owned.
• Exclude anything whose authorization cannot be established and note it in the out-of-scope column.

Lab scope parallel

On the course VirtualBox lab, a written scope might look like:

In this example, 192.168.56.127 is the only in-scope target. Kali at 192.168.56.120 is tester infrastructure/source traffic. Other addresses on 192.168.56.0/24 are not automatically in scope.

Cloud and SaaS scope

Cloud engagements fail when the SoW says "cloud pentest" but nobody lists who patches the OS, who configures the security group, and who owns the SaaS tenant settings.

Exact responsibilities depend on the service model and provider.

Client authorization covers assets the client owns or is contractually permitted to test. It does not override a cloud or SaaS provider's testing restrictions.

Cloud scoping checklist:

• Subscription IDs, projects, or organization units in the scope appendix
• Whether production, staging, or both are included
• Confirmation that provider penetration-testing policies were reviewed
• Regions, tenants, data stores, or datasets excluded because of residency, privacy, or regulatory requirements

Worked example: scope appendix for a fictional client

The block below is a teaching example for Example Corp. Adapt with legal review before client use.

SCOPE APPENDIX A — Example Corp external and web assessment
Effective: 2026-09-01 through 2026-09-15

Objective
  Determine whether an external attacker can gain unauthorized access to
  customer-facing web properties or the external /24 perimeter.

In scope
  IPv4: 198.51.100.0/24
  Hostnames: www.example.com, api.example.com, vpn.example.com
  Web: https://shop.example.com (unauthenticated and customer role)
  Azure: subscription 11111111-2222-3333-4444-555555555555,
         resource groups prod-edge, prod-api (read-only staging creds supplied)

Out of scope
  198.51.101.0/24 (internal WAN — separate SoW)
  payroll.example.com, *.dev.example.com
  Third-party payment processor (client integration URL only if listed later)

Excluded assessment types
  Social engineering
  Denial-of-service testing
  Physical security testing

Tester source
  203.0.113.200/32

Assessment type
  Gray-box external network plus authenticated web application testing

Authorization
  Per MSA dated 2026-06-01 and SoW #EX-2026-091, signed by authorized client representative

The tester source entry helps the client with allowlisting, SOC correlation, and distinguishing tester traffic from unrelated activity.

Pair this appendix with an RoE that names techniques, hours, and escalation. The sample RoE outline in the rules of engagement guide picks up where the scope list ends.

Handle scope changes in writing

Discovering another hostname during recon does not automatically put it in scope. PTES treats scope creep as a documented change, not a silent expansion.

When you find a new asset:

1. Pause testing against it.
2. Confirm ownership and whether the client wants it included.
3. Document the requested change (email, change log, or revised appendix).
4. Update the SoW, scope appendix, or approved change record before resuming.
5. Adjust timeline and fee if the added work is material.

The same rule applies when the client asks to "just check one more subnet" on day three. Do not rely on informal verbal approval for a scope expansion; record the approval through the engagement's agreed change process before testing the new asset.

Pre-engagement checks before testing begins

Scoping meetings produce action items that must close before day one:

• Missing network diagram or asset inventory
• NDA or SoW countersignature pending
• Cloud account ownership unclear
• Staging versus production ambiguity
• Credential or VPN delivery not completed
• Third-party permission outstanding
• WAF or monitoring team notification not confirmed

Tools such as Cervantes help organize findings and reports after testing starts. During pre-engagement, a shared checklist or project ticket is enough. The goal is zero open questions about target lists when the first scan runs.

Common pre-engagement mistakes

Summary

Pre-engagement starts with why the client wants a test, not with a subnet list. Define the objective, walk the checklist, and pick black-box, gray-box, or white-box assessment types before you draft agreements.

NDAs and MSAs protect confidentiality and frame the relationship. The SoW names objectives, deliverables, and scope references. The scope appendix lists CIDR blocks, domains, URLs, cloud IDs, and tester source addresses with validated ownership and explicit exclusions.

When boundaries change, document them in writing before you test new assets. When open scoping questions are closed, draft the RoE for techniques, windows, and escalation. In your own lab, the same discipline is a written IP table before the first scan against Metasploitable.

References

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• PTES — Pre-engagement
• AWS shared responsibility model
• AWS Penetration Testing policy
• Microsoft shared responsibility in the cloud
• Microsoft Azure Penetration Testing Rules of Engagement
• Google Cloud penetration testing policy