How to Scope Your First Penetration Test

If you’ve never scoped a penetration test before, the process can feel opaque. A bad scope is the single biggest reason engagements go sideways. Here’s how to walk in prepared.

Start with why you need the test

The trigger shapes the scope more than anything else:

• A compliance requirement (SOC 2, PCI DSS, a customer security questionnaire) usually defines a specific system boundary you need tested.
• A proactive security investment gives you more flexibility: test what worries you most, whether that’s a new product launch or your internal network.
• A specific incident or concern (a near-miss, a new integration, a past finding) usually means a narrower, targeted scope.

Knowing which of these applies tells the testing firm what “done” looks like for you.

What to define before the scoping call

Come in with rough answers to:

• What’s in scope. Specific applications, domains, IP ranges, or environments; even an approximate list helps.
• What’s explicitly out of scope. Production systems you can’t risk touching, third-party systems you don’t control, anything with special handling requirements.
• Testing type. Web application, API, network (external, internal, or both), cloud, mobile, or a combination.
• Timeline. Any hard deadline (an audit date, a customer deal, a compliance renewal) and any blackout windows (busy season, a product launch) to avoid.
• Who needs to be looped in. Whoever owns the systems being tested should know testing is happening, even under NDA.

What a good scoping call covers

Expect the testing firm to ask about:

• The size and complexity of what you want tested (user roles, number of endpoints, number of hosts)
• Whether testing should be authenticated, unauthenticated, or both
• Any compliance framework the results need to map to
• Your environment’s sensitivity: anything that shouldn’t be tested aggressively (e.g., a payment processor in a shared environment)

Common scoping mistakes

• Scoping too broadly on the first engagement. Start with the systems that matter most; expand scope on future engagements once you know what testing surfaces.
• Leaving out the API behind the web app. If your web application has an API, decide explicitly whether it’s in scope. It usually should be.
• Not defining rules of engagement. Agree in writing on testing windows, what happens if testers find a critical issue mid-engagement, and how findings get communicated.
• Skipping the retest. A finding that’s “fixed” but never retested is still an open question to anyone reviewing the report later.

What you should walk away with

A good scope ends in a written proposal defining exactly what’s tested, the timeline, the fixed cost, and what the final report will include, agreed before any testing starts.

---

Ready to scope your first engagement? Get a quote and we’ll walk you through it on a short call, or read our full methodology first.