Scoping a penetration test properly

Two quotes for a penetration test can differ by a factor of three and both be honest. The difference is almost always scope: what is being tested, from what starting position, with how much knowledge, and how deep the tester is permitted to go.

Understanding those variables lets you compare proposals properly and, more importantly, get a test that answers a question you actually care about.

Start with the question, not the target list

The most useful thing you can do before requesting a quote is decide what you want to find out. Common questions, each of which implies a different test:

• Can someone on the internet get into our network? An external infrastructure test.
• If someone gets a foothold, how far can they go? An internal test, usually starting from an assumed compromised workstation.
• Can a customer of our application access another customer's data? An application test with multiple user roles.
• Would our staff fall for a convincing phishing email? A social engineering exercise, which has consent and HR implications worth thinking about.
• Is our cloud configuration exploitable? A cloud configuration review, which overlaps with but is not the same as a penetration test.

A test scoped without a question tends to become a vulnerability scan with commentary. Useful, but not what most people think they bought.

The variables that move the price

Number of targets

Counted in IP addresses, applications, user roles, or API endpoints depending on the type. This is the most obvious driver and the easiest to get wrong, because organisations frequently do not know their own external footprint.

Run a discovery pass before requesting quotes. What you find is often larger than the list you would have provided, and finding it yourself is cheaper than being surprised mid-test.

How much the tester is told

Black box means the tester starts with nothing but a target. It simulates an outsider realistically but spends a significant portion of the time on reconnaissance you could have simply provided.

Grey box means the tester gets some information: network ranges, application credentials for each role, an architecture summary. Most tests should be grey box. You are paying for depth, not for the tester to rediscover facts you already know.

White box means full access to documentation and sometimes source code. This finds the most, and it is the least realistic simulation of an attack. For an application handling sensitive data, that trade is usually worth making.

Application complexity

For application tests, the meaningful measure is not page count but the number of distinct user roles, the number of functions that change data, and whether there is an authorisation model to test. An application with five roles requires testing whether each role can reach each other role's data, which grows quickly.

Depth of exploitation

There is a large difference between confirming a vulnerability exists and demonstrating what an attacker could do with it. Chaining several issues to reach a meaningful outcome takes far longer and produces a far more persuasive report.

Decide which you want. If the report needs to convince a board to fund remediation, demonstrated impact is worth paying for.

What to exclude, and why

Exclusions are not weakness. Testing everything is rarely the best use of a fixed budget.

Reasonable exclusions:

• Denial of service testing, unless you specifically want it. It is disruptive and the finding is usually predictable.
• Third-party hosted services you do not control. You typically need the provider's permission, and you cannot fix what you find.
• Systems mid-migration or being decommissioned. Testing something that will not exist in a month wastes the budget.
• Physical and social engineering, unless deliberately in scope with the right approvals.

Unreasonable exclusions, which are worth pushing back on:

• Production, on the grounds that it is risky. A test against a staging environment that differs from production tests the staging environment. If production genuinely cannot be tested, that is a finding in itself.
• The legacy system nobody wants to look at. That is usually where the problems are.

The practical details that cause problems

Testing window. Agree whether testing happens in or out of business hours, and whether your own team should be told. Telling your SOC turns it into a straightforward technical test; not telling them turns it into a detection exercise as well, which is valuable but should be a deliberate choice with someone senior aware.

Emergency contact. A named person on each side, reachable during testing, with authority to stop it. Tests occasionally cause unexpected effects and the ability to call a halt in minutes matters.

Rules of engagement, written. What is in scope, what is out, what the tester must not do, and what happens if they find something critical mid-test. Critical findings should be reported immediately rather than held for the report.

Retest included. Confirm whether a retest of fixed findings is included and for how long after the original test. Without it, you have a report and no evidence that remediation worked, which is what an auditor or customer will ask for.

Authorisation. A written authorisation to test, signed by someone with the authority to grant it. If any part of the infrastructure is hosted by a third party, their permission may also be required.

What you should receive

A report that is useful rather than merely thorough:

• An executive summary that a non-technical reader can act on.
• Findings ranked by risk in your context, not just by generic severity score.
• Enough reproduction detail that your team can confirm the issue and verify the fix.
• Specific remediation advice, not "apply vendor patches".
• A clear statement of what was tested and what was not, so the report's limits are visible.

That last item is the one to check first when reviewing a proposal. A tester who is precise about the boundaries of their own work is usually precise about the rest of it too.

A note on frequency

Annual testing is a common baseline and is often driven by a compliance requirement rather than by risk. The more useful trigger is change: a significant application release, a migration, a new external service, a merger.

A test six months before a major architectural change tells you about a system that no longer exists.