How to scope a penetration test (a checklist you can reuse)

We are regularly asked to review a report from a previous provider that the customer found underwhelming. In most cases the testing was competent. The scope simply did not permit the test to answer the question the buyer actually had. That is a procurement failure, and it is avoidable.

Start from a decision, not from an asset list

Before you list IP ranges, write one sentence: what decision will this test inform? The sentence forces the scope to be useful.

• We need to know whether a compromised employee laptop leads to customer data. → Assumed-breach internal test with a data-access objective.
• We need evidence for a supervisory authority that our controls are effective. → Claim-scoped test with retest, mapped to specific obligations.
• A customer's security questionnaire demands an annual pentest. → Scope the systems the customer cares about, and ensure the report is shareable.
• We are about to launch a new API and want it examined before customers hit it. → Authenticated application and API test with full documentation and multiple role levels.
• We want to know whether our SOC would notice an intrusion. → Red team or purple team exercise. A penetration test will not answer this.

The questions a competent provider will ask you

Use this as a filter. A provider who quotes from an IP count alone, without asking most of these, is pricing a scan.

1. What decision are you trying to inform, and who reads the report?
2. What would a bad day look like for you? Which data, which system, which process?
3. What is explicitly out of scope, and why? Is the exclusion technical, contractual, or political?
4. Is testing authenticated? With how many roles, and do you have the accounts ready?
5. Is this production or a staging environment, and how faithfully does staging mirror production?
6. Are third parties involved — cloud providers, SaaS, managed service providers — and do you hold testing rights?
7. Are there availability constraints, change freezes, or business-critical windows?
8. Should the security and operations teams be informed, and if not, who is the control contact?
9. Is remediation support and retesting included, and within what window?
10. How will findings be delivered — during the test for critical issues, or only at the end?

Authenticated versus unauthenticated: the decision that changes everything

An unauthenticated external test answers one question: what can an anonymous internet attacker reach? For most modern estates the honest answer is a login page and a marketing site. The interesting risk is behind authentication.

Supplying credentials is not cheating. It reflects reality: credentials are phished, reused, or bought. A test that refuses to assume a breach is testing a threat model that stopped being the dominant one years ago.

Exclusions that quietly destroy value

Every exclusion is defensible on its own. The problem is cumulative — five reasonable exclusions can carve out the entire attack path that matters.

• Excluding the identity provider. It is usually the highest-impact system in the estate. If it is out of scope, say so prominently in the report so nobody mistakes silence for safety.
• Excluding social engineering entirely. Reasonable for a technical test — but then the report cannot speak to initial access, and should say so.
• Excluding production. Staging environments differ in configuration, data, integrations and scale. Findings do not transfer cleanly, and absence of findings transfers even less well.
• Excluding anything managed by a third party without checking your contract. Often you do hold testing rights and never exercised them.
• Time-boxing so tightly that only automated tooling fits. A three-day test of a large application is a scan with a human writing the summary.

Sizing: how much time is enough

There is no formula, but there are sanity checks. For a web application, count authenticated roles and distinct workflows rather than pages. For infrastructure, count distinct system types rather than hosts — 200 identically-built workstations is close to one system, while 12 bespoke servers is twelve. For APIs, count endpoints with distinct authorisation logic.

If a provider's estimate is far below others for the same scope, ask what they will not do. Usually the answer is manual business-logic testing, which is where the findings that matter live.

Rules of engagement: the short version that actually gets used

Long rules-of-engagement documents get signed and forgotten. Keep a one-page operational version that the testers and your on-call actually read.

• Test window, including any hours when testing must pause.
• Source IP addresses the testing will originate from.
• Named contacts on both sides, with out-of-hours numbers.
• Stop conditions: what triggers an immediate pause, and who can call it.
• Critical finding protocol: how a critical issue is reported mid-test, and to whom.
• Explicit prohibitions: no denial of service, no destructive actions, no exfiltration of real personal data beyond proof of access.
• Evidence handling: how proof is captured, stored, and destroyed after the engagement.
• The agreed definition of done, including whether retesting is inside the contract.

Before you sign, confirm these four things

1. Retesting is included, with a stated window and no additional mobilisation fee.
2. Findings are reproducible — each one includes the steps, the request, and the observed result.
3. Critical issues are reported immediately rather than held for the report.
4. You receive the raw evidence, not only the narrative. You will need it for your ticketing system and for any auditor.