Scoping a test for a client without being the tester

Penetration testing for MSPs › Scoping a client’s test

A client says they need a penetration test. What you have at that point is a sentence, and what a provider needs is a target list, a depth and a reason. Getting from one to the other is the piece of work in front of you, and it is worth being good at, because the alternative is forwarding the sentence and waiting a week while somebody else asks the client questions you could have answered yourself.

You do not need to know how testing is performed. You need to know what exists, who owns it, and why anybody is asking.

Start with the driver, not the systems

Before anything technical, find out what prompted the request, because it usually defines the scope more tightly than any conversation about systems will.

• An insurer. Renewal conditions are often specific and often narrower than they read. Ask for the wording rather than the client’s summary of it.
• A customer’s security questionnaire. Frequently asks whether testing is performed annually, not for a test of everything. Sometimes the honest answer is that an existing report covers it.
• A tender. Read the clause. It may name CREST, it may name a scope, it may name a maximum report age, and each of those changes what you buy.
• A board or an incident elsewhere in their sector. The loosest driver, and the one where scope needs the most shaping, because nobody has written anything down.
• A regulator or a framework. Usually prescriptive. Get the reference.

Getting the driver in writing is the highest-value ten minutes in the whole exercise. A surprising proportion of requests that arrive as "they want a pen test" turn out to name a specific system, a specific standard or a specific date, and everything else you were about to scope is nobody’s requirement.

Turning the estate into a target list

Now the part only you can do. Clients describe their systems the way they experience them, which is as "the website" and "the system" and "the portal". You know what those are. Translate.

For each thing the client named, write down what it actually is: a hostname or a URL, where it is hosted, who administers it, whether it has a login, and roughly how many distinct user roles it has. That is enough for a provider to quote. If you cannot answer the hosting question for something, that is itself a finding worth raising with the client separately.

Then add what the client did not name but should have. External IP ranges with anything live on them. Remote access routes. Anything internet-facing that was stood up for a project and never decommissioned. A staging environment with production data in it. VPN endpoints. On a managed estate these are visible to you and invisible to the client, and leaving them out of the conversation is how a client ends up with a certificate covering the website and an unpatched remote access appliance nobody tested.

Mark each item as in scope, out of scope, or to be decided. A target list with deliberate exclusions on it is a better document than one that pretends the estate is only what the client mentioned.

The answers that move the price

Six questions account for most of the variation between two quotes. Answer these and you will get a firm number quickly; leave them and you will get a range and a scoping call.

Scoping answers and what they do to a quote

Question	Why it moves the price
Does it have a login, and how many user roles?	The largest single multiplier. An application with four roles is a substantially bigger job than the same application with one, because the interesting flaws live between roles.
How many live hosts, not how many IP addresses?	Ten addresses with three services is small. Ten addresses sitting in front of forty virtual hosts is not, and both occupy one line in a scope document.
Is there an API behind the interface?	An application and its API are two surfaces. Testing one does not test the other, and clients rarely mention the API at all.
Who hosts it?	Shared hosting is frequently refused outright. Managed hosting needs the host’s written authorisation. A third-party SaaS platform is not the client’s to authorise.
Production or a representative environment?	Changes the constraints, the hours and sometimes the technique. It rarely changes the day count, but it always changes the plan.
Internal as well as external?	An internal network test is a different engagement with different logistics, not an extension of an external one.

None of these require you to be a tester. All of them require you to know the estate, which you do.

Requirements that are smaller than they sound

Worth knowing, because the client who asks for everything usually needs one thing, and quoting them for everything is how the project dies at the budget stage.

A questionnaire asking whether the organisation carries out regular penetration testing wants a yes and a date, not a test of the entire estate. An insurer asking for external testing means the perimeter, not the applications behind it. A customer asking for evidence about the platform they use means that platform, not the client’s office network. A tender asking for a report no older than twelve months may be satisfied by something the client already has and forgot about.

Our fixed-fee external infrastructure test covers up to ten IP addresses at £3,000 plus VAT, and an unauthenticated CMS website test is £2,500 plus VAT. A meaningful share of insurer-driven and questionnaire-driven requirements land inside one of those two. If yours does, say so to the client, because a small definite number closes far more quickly than a large approximate one.

There is a version of this that goes the other way. If the client’s requirement is genuinely a vulnerability scan with a report, say that too. A day rate of £250 to £500 usually buys exactly that: automated scanning inside a report wrapper. It is a legitimate product and it is not a penetration test, which is why accredited UK rates sit at roughly £800 to £1,200 a day. Selling a client a test they did not need is a short-term win and a long-term problem.

Settle the authorisation question at scoping

Two items, both cheap now and expensive later. First, does every target belong to the client’s legal entity, or does something sit with a parent, a subsidiary or a joint venture? Second, who at the client can sign the rules of engagement, and are they available in the window being discussed? It has to be somebody at the client who can commit them, which on most accounts is not the person who asked you to sort it out.

Ask both during scoping and you will know your real lead time. Standard is two to three weeks from agreed scope to testing, often within a week at short notice for a contained scope, and the signature is usually the binding constraint rather than the diary.

What good looks like when you hand it over

A scope you can send in one email contains: the driver, in the client’s own words or the clause itself; a list of named targets with hostnames, URLs or ranges; the hosting arrangement for each; whether each has a login and how many roles; anything deliberately excluded and why; the deadline and what it is driven by; and the name of the person who will sign the authorisation.

That is roughly fifteen lines. It is the difference between a quote in a day and a fortnight of email, and every item on it is something you already know or can find out in a single conversation with your own team.

When to stop scoping and get on a call

If the target is an application you did not build and do not administer, if the client’s own developers hold the answers, or if the requirement wording is ambiguous enough that two readings give two different scopes, stop writing and arrange a call. Twenty minutes with the right people removes more cost than an afternoon of inference. You can be on that call as the lead with us in the background, or not on it at all, whichever suits the account.