How to Scope Your First Pentest Engagement Like a Pro

Learn how to scope your first pentest with rules of engagement, approved targets, and a statement of work. A practical checklist for software engineers.

You've been asked to organize a penetration test. Maybe a customer questionnaire asked for your last pentest report, or your compliance auditor flagged it as a requirement, or your CTO simply said "we need a pentest before the next release." Whatever the trigger, you're now staring at a blank document wondering what exactly should go into the scope, what rules of engagement look like, and how a statement of work protects everyone involved.

Here's the good news: scoping a pentest is not rocket science. It's a structured process with clear inputs, predictable outputs, and well-documented standards. The bad news? Getting it wrong can mean paying for a test that misses your riskiest assets, accidentally knocking production offline, or ending up with a report that doesn't satisfy the auditor who asked for it in the first place.

This guide walks you through the three pillars of a well-scoped engagement: the rules of engagement (ROE), the approved targets list, and the statement of work (SOW). By the end, you'll have a repeatable checklist you can use whether you're running a pentest internally, hiring a consultancy, or using a platform like Pentest Today to create an engagement with built-in scope guards and human approval gates.

Rules of Engagement: Setting the Boundaries Before Anyone Touches a Keyboard

Rules of engagement are the behavioral contract between the testing team and the organization being tested. They answer a deceptively simple question: what is the tester allowed to do, and what is off-limits? Skip this step and you're handing someone a set of lock picks without telling them which doors are yours.

What Belongs in the ROE

A strong ROE document covers six areas. Think of them as the who, what, when, where, how, and "what if" of the engagement.

Authorized personnel. Name every person who will perform testing, and name the internal stakeholders who can authorize scope changes or escalations in real time. Include phone numbers, not just email. When a tester triggers an intrusion detection alert at 2 a.m., your SOC analyst needs a direct line to verify it's authorized activity.

Testing window. Define the dates and hours during which active testing may occur. If your application serves customers across multiple time zones, decide whether testing should happen during business hours (to observe normal traffic patterns) or off-hours (to reduce blast radius). Document both the start date and the hard stop date.

Communication protocols. Specify how the testing team will report critical findings discovered mid-engagement. A SQL injection that exposes patient records shouldn't wait for the final report. Most ROE documents define a "critical finding" threshold and require notification within a fixed window, often four hours or less.

Escalation and emergency contacts. If a test causes unintended service degradation, who gets called first? The ROE should include a "stop testing" trigger and the person authorized to pull that lever. This is separate from your general point of contact.

Social engineering boundaries. Will the test include phishing, vishing, or physical access attempts? If yes, define which employees or departments are in scope and whether the tester can impersonate specific roles. Many organizations exclude executive assistants or HR staff from phishing simulations for legal or ethical reasons.

Data handling requirements. The tester will likely encounter sensitive data during the engagement, from credentials to customer records. The ROE should state how that data is stored during testing, when it must be destroyed, and whether screenshots containing PII need to be redacted in the final report.

The NIST SP 800-115 Technical Guide to Information Security Testing and Assessment provides a thorough breakdown of these planning phases and is worth bookmarking as a reference for any ROE you draft.

Common ROE Mistakes

The most frequent mistake engineers make is writing an ROE that's either too vague or too restrictive. "Test our web application" tells the tester nothing about which environments, which authentication levels, or which functionality is fair game. On the other end, an ROE that forbids any automated scanning, restricts testing to a two-hour window, and excludes all authenticated functionality will produce a report so shallow it's barely worth the PDF it's printed on.

Another common pitfall: forgetting about third-party dependencies. If your app runs on AWS and uses a third-party payment processor, you cannot authorize testing against infrastructure you don't own. Your ROE needs to explicitly exclude third-party assets and document any cloud provider notification requirements. AWS, for example, no longer requires penetration testing pre-approval for most services, but other providers still do.

Building Your Approved Targets List: Precision Over Breadth

The approved targets list is the tactical complement to the ROE's strategic boundaries. Where the ROE says "you may test our web application," the targets list says "here are the exact domains, IP ranges, API endpoints, and environments you're authorized to touch."

Start with an Asset Inventory

Before you can decide what to test, you need to know what you have. This sounds obvious, but shadow IT and forgotten staging environments are the reason many pentests discover assets the engineering team didn't know existed.

Pull together a list that includes:

• Production domains and subdomains (e.g., app.example.com, api.example.com)
• Staging or QA environments if they share infrastructure or codebases with production
• IP addresses and CIDR ranges for any self-hosted infrastructure
• Mobile application package names if mobile is in scope
• API documentation URLs for any authenticated or internal APIs
• Cloud account identifiers if cloud configuration review is part of the test

Once you have the inventory, mark each asset as in-scope, out-of-scope, or conditional. Conditional means the asset can be tested only under specific circumstances, like "only after business hours" or "only with read-only test credentials."

The Allowlist Approach

The safest way to define targets is as a strict allowlist: if it's not explicitly listed, it's not in scope. This prevents scope creep and protects both parties. If a tester accidentally pivots to an out-of-scope system, the allowlist makes the boundary unambiguous.

Platforms that support engagement creation with scope enforcement make this easier to manage. When you start your pentest with Pentest Today, for example, you define approved targets during engagement setup, and scope guards prevent the testing agent from making requests outside the allowlist. That kind of automated enforcement removes the human error factor from scope compliance.

Scoping by Test Type

Your targets list will look different depending on the type of test:

• External network pentest: Public-facing IP ranges, domains, and ports. Exclude any IPs that belong to CDN providers or shared hosting you don't control.
• Web application pentest: Specific URLs, user roles to test (unauthenticated, standard user, admin), and any functionality explicitly excluded (e.g., "do not test the payment flow against the live payment processor").
• Internal network pentest: VLAN ranges, Active Directory domains, and whether the tester starts with a foothold (assumed breach) or must gain initial access.
• API pentest: Endpoint documentation, authentication tokens or test accounts, rate limit considerations, and whether the tester should attempt to bypass authorization controls.

A well-scoped targets list for a typical web application pentest might look like this:

Document this in a format that can be referenced programmatically, not buried in paragraph three of a contract addendum. The easier it is to verify scope compliance, the fewer misunderstandings you'll have mid-engagement.

The Statement of Work: Turning Scope into a Contract

The statement of work is where your rules of engagement and targets list become a formal, often legally binding, agreement. Think of the ROE as the "how we'll behave" and the SOW as the "what we'll deliver, by when, and for how much."

Essential SOW Components

A pentest SOW doesn't need to be fifty pages, but it does need to cover these elements without ambiguity:

Engagement objectives. State what the pentest is meant to achieve. "Identify exploitable vulnerabilities in the customer-facing web application and assess the risk of unauthorized data access" is better than "test our security." If the pentest is driven by a specific compliance requirement, name the framework. Readers working toward SOC 2, ISO 27001, HIPAA, or PCI DSS can see which frameworks Pentest Today maps to and generate reports that satisfy auditor expectations.

Methodology. Reference the methodology the tester will follow: OWASP Testing Guide for web apps, PTES for general pentesting, or your own internal standard. This sets expectations about the depth and rigor of the test.

Deliverables. Be specific. A typical pentest SOW promises:

1. 1.An executive summary for non-technical stakeholders
2. 2.A detailed findings report with severity ratings, reproduction steps, and remediation guidance
3. 3.A debrief meeting or call to walk through results
4. 4.A retest of remediated findings within a defined window (often 30 to 90 days)

Timeline and milestones. Break the engagement into phases: kickoff and credential provisioning, active testing, draft report delivery, final report delivery, and optional retest. Assign dates or SLA windows to each.

Pricing and payment terms. Fixed fee, time-and-materials, or a hybrid model. If it's time-and-materials, cap the hours so there's a ceiling on cost. Define when invoices are issued and what triggers payment.

Liability and indemnification. This is the clause nobody wants to write but everyone needs. It should address what happens if testing causes an outage, who bears the cost, and what the tester's liability cap looks like. Most pentest firms carry professional liability insurance specifically for this.

SOW Anti-Patterns to Avoid

The biggest anti-pattern is a SOW that describes scope in vague terms and leaves the targets list as "to be determined during kickoff." This creates a gray zone where the tester assumes certain systems are fair game and the engineering team assumes they're not. Pin down the targets list before signing.

Another common mistake is omitting the retest clause. A pentest without a retest is a snapshot with no follow-through. Your SOW should specify how many findings qualify for retest, the window for requesting it, and whether retesting is included in the original price or billed separately. If you're planning the full lifecycle, the natural next step after the report lands is building a remediation sprint with SLA tiers and finding triage.

Finally, don't treat the SOW as a static document. If scope changes mid-engagement (a new API goes live, or a system is taken out of scope due to a production incident), amend the SOW formally. A quick "yeah, go ahead and test that too" over Slack doesn't protect anyone.

Your Pre-Engagement Checklist: Putting It All Together

Before you kick off any pentest, whether it's your first or your fiftieth, run through this checklist to confirm you've covered your bases.

• Objective defined: You can explain in one sentence why this pentest is happening and what a successful outcome looks like.
• Targets inventoried: Every in-scope asset is documented with domain, IP, environment, and any access credentials the tester needs.
• Allowlist finalized: Out-of-scope systems are explicitly listed, especially third-party services and shared infrastructure.
• ROE drafted: Testing window, communication protocols, emergency contacts, data handling rules, and social engineering boundaries are all addressed.
• Test accounts provisioned: If authenticated testing is in scope, test accounts exist for every role level and are ready before day one.
• Cloud provider notifications sent: If your infrastructure runs on a provider that requires pre-approval, the notification is submitted and acknowledged.
• SOW signed: Objectives, methodology, deliverables, timeline, pricing, retest clause, and liability terms are documented and countersigned.
• Internal stakeholders briefed: Your SOC team, DevOps on-call, and any relevant infrastructure owners know the testing window and have the tester's contact information.
• Monitoring adjusted: Alert thresholds or SOC playbooks are updated so authorized test traffic doesn't trigger a full incident response.

If you're checking these boxes for the first time, you might also benefit from a broader walkthrough of how to scope and survive your first startup pentest, which covers budgeting and vendor selection alongside the scoping process.

Scoping a pentest well takes deliberate effort upfront, but it pays off in cleaner results, fewer surprises, and a report that actually moves the needle on your security posture. The ROE keeps everyone safe, the approved targets list keeps everyone focused, and the SOW keeps everyone accountable.

If you're ready to turn this checklist into action, Pentest Today lets you create an engagement with approved targets, scope guards, and a human approval gate so nothing runs until you've confirmed the scope is right. From there, you'll get automated finding triage, severity ratings, and a client-ready PDF report you can hand directly to your auditor or your board.