Scoping a Penetration Test Without Guessing

To scope a penetration test without guessing, count roles, authentication paths and trust boundaries rather than pages or hosts, ask the same seven questions every time, collect the answers in one structured document, and write the exclusions as carefully as the inclusions. Nearly every unprofitable engagement was mis-scoped rather than mis-delivered: an estimate built from a description of the system, a kick-off call where the surface turns out to be larger, and a fixed price that now has to absorb the difference.

Count what drives effort

Host counts and page counts are proxies, and poor ones. What drives effort is distinct functionality and distinct trust boundaries: how many roles exist, how many authentication paths, how many places user input crosses into another system.

An application with forty pages and one role is smaller than one with eight pages and five roles, because the second has ten role pairs to test authorisation across and the first has none. Roles multiply; pages add.

The seven questions worth asking every time

1. Roles and credentials. Is the test authenticated, how many distinct user types are there, and can you provide a working account for each before day one?
2. The API. Is there one separate from the interface, is it documented, and is the documentation current? An undocumented API is discovery work before it is testing work, as testing an API without a specification explains.
3. What sits behind the hostname. One URL routinely turns out to be an admin console, a customer portal and a legacy component with its own session handling. Which components are hosted by somebody else, and who owns them contractually?
4. Environment fidelity. Is the test environment a true copy of production, and if not, precisely where does it differ? If it does not match, you will find issues that do not exist and miss ones that do, and somebody should decide that knowingly.
5. Defensive interference. Are there rate limits, WAFs, bot protection or alerting that will get in the way, and can they be relaxed for tester source addresses?
6. Fragility. Is anything in scope that cannot be reset if it breaks?
7. Escalation. Who can authorise access if something blocks us on day two, and are they available that week?

The last one is not a formality. Waiting for credentials is the most common way a fixed-price engagement quietly loses a day, and it is entirely preventable at scoping by naming a person rather than a mailbox.

Collect the answers in one structured document

Scoping conducted over an email thread produces answers scattered across replies, and the version that reaches the estimate is whichever one the estimator happened to read last. When the disagreement arrives six weeks later, nobody can reconstruct what was agreed.

A structured questionnaire the client completes, kept with the engagement records, means the scope everyone signed is the scope everyone can still see. It also means the answers arrive in one pass rather than five, which clients notice and appreciate more than they say. A penetration testing scoping questionnaire is a good place to start yours.

Write the exclusions as carefully as the inclusions

Each of these should be explicitly in or out, in writing, every time:

• Denial of service and resource exhaustion.
• Social engineering, including phishing of client staff.
• Physical access and site visits.
• Third-party hosted components the client does not own.
• Destructive testing, and anything touching production data.
• Testing outside agreed hours, and what happens if something breaks out of hours.

A scope listing only inclusions leaves every ambiguity to be resolved mid-test, under time pressure, by whoever happens to be holding it. The list belongs in the statement of work, not in an email.

Time-box the genuine unknowns

Where scope cannot be pinned down, say what you will do with the time rather than pretending precision. "Two days on the API, prioritised by the role matrix, with a written note on anything we could not reach" is an honest scope that a client can accept or extend.

A number invented to look confident is not, and it will be quoted back to you at the exact moment you have least room to move.

Quote the retest at the same time

Pricing verification later, once findings exist, makes it look like an upsell triggered by bad news. Including it in the original quote makes it a normal part of the engagement, which is better for the client and considerably better for the proportion of your findings that ever get fixed. Pricing penetration testing work covers the rest of what to charge for separately.

A scope that cannot be read aloud on the kick-off call without somebody saying "wait, does that include..." is not finished.

Scoping a multi-phase engagement

Everything above assumes one body of work. Larger engagements are several: an external phase, an internal phase, a web application, sometimes months apart and sometimes with different testers.

Phases are worth treating as first-class rather than as sections of a single blob, for reasons that show up later rather than at scoping.

• Each phase has its own scope and test days, and often its own authorisation window. Collapsing them loses the ability to say precisely what was in scope at a given point, which is exactly the question that gets asked.
• Coverage is per phase. The checklist for an internal phase is not the checklist for a web application, and demonstrating coverage means demonstrating it per phase.
• Findings belong to a phase. The same weakness found externally and internally is two findings with different exposure, not one finding mentioned twice.
• Reporting can still be one document. Clients want a single deliverable; that is a formatting decision, not a reason to lose the structure underneath it.

Price scope drift before it happens

The estate is larger than described more often than not, and the moment to agree what happens then is while nobody is under pressure. Agree in writing what constitutes a change, who decides, and whether the response is more days or a narrower scope.

Without that, the tester absorbs it quietly, the coverage silently narrows to fit, and the report goes out describing a test that was never performed as scoped. That is a worse outcome for the client than an awkward conversation on day two.