Scoping by email thread
A prospective client wants 'a pen test'. Your sales lead books a scoping call with a senior tester. On the call it turns out they mean an external infrastructure test, a test of their customer portal, and maybe something on their Microsoft 365 set-up. The tester asks how many IP addresses, how many user roles in the portal, whether there is an API, where it is hosted. The client does not know and promises to find out.
Over the next fortnight answers trickle in. A spreadsheet of IP ranges arrives, some of which belong to a hosting provider. A developer sends a partial list of roles. Nobody mentions the staging environment until the tester asks. Your senior tester, who is also booked on client work, has to re-read the thread each time to remember where things are.
The quote finally goes out. The client signs. And on day one of the test, the tester finds a whole API the scope did not include.
At the other end, when the client asks next year for the same test again, most of what was learned during scoping is buried in that thread, and the process starts almost from scratch.
Why scoping takes so long
- Clients buy 'a pen test' and do not know what information a tester needs.
- Each test type (web application, API, external or internal infrastructure, cloud configuration, mobile) needs different questions.
- Answers come from several people at the client: IT, developers, a hosting provider.
- Senior testers are the only people who can judge scope, and they are billable elsewhere.
- Scope details live in emails and call notes, not in a structured record.
Scoping is where the size of the job, the price and the client's expectations are all set. Doing it loosely makes everything after it harder.
What loose scoping costs a testing firm
| Scoping gap | Consequence |
|---|---|
| Asset count underestimated | Test overruns, or coverage is thinner than sold |
| Environment unclear | Tester waits on day one for access or clarity |
| Third-party hosting not identified | Authorisation missing, test delayed |
| Senior testers on scoping calls | Billable time lost |
| Slow quote | Client goes with a firm that answered faster |
The scoping workflow we build
- After the first conversation, the client receives a scoping form tailored to the test types they are interested in, with plain explanations of why each question matters.
- The form can be shared inside the client's business, so their developer answers the application questions and their IT lead answers the infrastructure ones.
- Answers are checked as they come in: IP ranges validated, URLs checked for format, hosting providers noted for authorisation, and missing items listed back to the client.
- Your scoping rules (for example, days per application size band or per number of roles and API endpoints) turn the answers into a draft day estimate for each test type.
- A senior tester reviews the draft scope and estimate in one screen instead of a thread, adjusts it, and adds any caveats.
- The agreed scope becomes the basis of the quote and statement of work, and later the tester's briefing pack for the engagement.
We can build this into your existing CRM or practice system, or as a small portal on your own domain. The estimating rules stay yours and are easy to change.
What scoping looks like afterwards
Clients get a clear list of what you need, in language they understand, and can pass sections to the right colleague. Most scopes arrive complete, or with gaps named and chased automatically. Senior testers spend a short review on each scope rather than several calls. Quotes go out faster and match what the tester finds on day one.
And when the same client comes back next year, last year's scope is the starting point, with a simple 'what has changed?' form.
Signs your scoping needs work
- Scoping takes several calls and a long email thread.
- Senior testers spend significant time on unpaid scoping.
- Tests start with scope surprises on day one.
- Estimates vary depending on who scoped the job.
- Returning clients are re-scoped from scratch.