A Bad Scope Sinks More Pentests Than Bad Testers. How to Get Your First One Right

When a penetration test goes sideways, people usually blame the testers. In my experience the problem started weeks earlier, in a scoping conversation nobody prepared for. A bad scope is the single biggest reason engagements go wrong.

If you have never scoped a test before, the process can feel opaque. You are asked questions about your own systems that you have never had to answer in one place, and the person asking seems to expect you to know the vocabulary.

You do not need the vocabulary. You need a handful of decisions made before the call, a sense of what the testing firm will ask, and an awareness of the mistakes first-time buyers make. That is what this piece covers.

Begin with the reason, not the systems

Before anyone talks about domains or IP ranges, be clear about why you are buying the test. The trigger shapes the scope more than anything else, and it usually falls into one of three buckets:

• A compliance requirement. A SOC 2 penetration test, PCI DSS or a customer security questionnaire usually defines a specific system boundary that has to be tested. The boundary is largely decided for you.
• A proactive security investment. Here you have more freedom. Test what worries you most, whether that is a product about to launch or your internal network.
• A specific incident or concern. A near-miss, a new integration or a finding from an earlier test usually calls for a narrower, targeted scope.

When I know which of these applies, I know what "done" looks like for the client. A compliance-driven test is done when the required boundary has been covered and the report maps to the framework. A concern-driven test is done when that concern has been examined properly. Saying the reason out loud at the start saves a lot of back and forth later.

If you are a startup facing your first enterprise security review, you are most likely in the first bucket, even if nobody has written the requirement down yet.

Five answers to have ready before the call

You do not need a finished specification. Rough answers are enough, and an approximate list is far better than none. Come in with a view on these five things:

• What is in scope. The specific applications, domains, IP ranges or environments you want tested.
• What is explicitly out of scope. Production systems you cannot risk touching, third-party systems you do not control, and anything with special handling requirements.
• The type of testing. Web application, API, network (external, internal or both), cloud, mobile, or a combination of these.
• The timeline. Any hard deadline, such as an audit date, a customer deal or a compliance renewal, and any blackout windows to avoid, such as a busy season or a product launch.
• Who needs to know. Whoever owns the systems being tested should be told that testing is happening, even when the engagement is under NDA.

The out-of-scope list deserves as much thought as the in-scope one. Testers will treat anything you have not excluded as fair game within the agreed targets, so a system you quietly assumed was off limits needs to be written down.

The last item is the one people forget. An operations engineer who sees unusual traffic and has not been told about the test will treat it as an attack, and they would be right to.

What a good scoping call should cover

A competent testing firm will lead the call. You should expect questions along these lines:

• How big and complex the target is: the number of user roles, endpoints or hosts.
• Whether testing should be authenticated, unauthenticated or both.
• Which compliance framework, if any, the results need to map to.
• How sensitive the environment is, and whether anything should not be tested aggressively. A payment processor in a shared environment is a typical example.

These questions are not small talk. Size and complexity drive the effort, the authenticated or unauthenticated choice decides how deep testers can get, and the framework decides how the report is written. If a firm quotes you without asking any of them, treat that as a warning sign about what you would be buying.

Four mistakes first-time buyers make

Most scoping problems I see come from the same few habits.

• Scoping too broadly on the first engagement. It is tempting to test everything at once. Start with the systems that matter most, and expand the scope on later engagements once you know what testing tends to surface in your environment.
• Leaving out the API behind the web app. If your web application talks to an API, decide explicitly whether API testing is in scope. It usually should be, because that is where much of the application logic lives.
• Not defining rules of engagement. Agree in writing on testing windows, on what happens if testers find a critical issue in the middle of the engagement, and on how findings get communicated. Deciding this during an incident is much harder than deciding it on a calm afternoon.
• Skipping the retest. A finding that is "fixed" but never retested is still an open question to anyone who reads the report later, whether that is an auditor or a customer.

A finding that is fixed but never retested is still an open question to anyone reviewing the report later.

What the scope should turn into

A good scoping process ends with a written proposal, agreed before any testing starts. It should define exactly what is tested, the timeline, the fixed cost, and what the final report will include.

That document protects both sides. You know what you are paying for and what you will receive. The testers know where their authorisation begins and ends. If anything about the engagement is unclear later, the proposal is the reference point, so it is worth reading slowly before you sign it.

The short version

• Start from the reason for the test: compliance, a proactive investment or a specific concern. It shapes everything else.
• Bring rough answers on what is in scope, what is out, the testing type, the timeline and who needs to know.
• Expect the firm to ask about size, authentication, compliance mapping and sensitive systems, and be wary of one that does not.
• Keep the first scope focused, include the API, put rules of engagement in writing and plan for the retest.
• Finish with a written proposal covering scope, timeline, fixed cost and report contents before testing begins.

This article is based on Invadel's guide "How to Scope Your First Penetration Test": https://invadel.com/blog/how-to-scope-your-first-penetration-test/ — read it for the full detail. Mark Kiss is the founder of Invadel, a penetration-testing firm — https://invadel.com/ has the services and fixed prices.