Scope it right, and the test is worth having.
The scope is the single decision that determines whether your penetration test tells you something true or hands you a clean-looking PDF. Here is how to scope one properly: assets, environment, depth, rules of engagement, and the questions that flush out a real test from a checkbox exercise.
A bad scope buys you a false sense of safety.
Everything about a pen test flows from the scope. Get it right and the test answers the question you actually have. Get it wrong and you can run a flawless, expensive engagement that proves nothing.
The trap is scoping narrow to save money: the testers find little because there was little inside the lines you drew, the report comes back green, and the breach lands through the subdomain you left out. A pen test isn’t a grade to pass. It’s your chance to find your worst problems on your own terms. Scope it to surface bad news, not to avoid it.
Build a scope you can actually quote against.
Work down the decisions, or start from a common scenario below. There are no wrong answers: rough it out, and we’ll shape the final scope with you. A live draft builds on the right, yours to keep as a PDF whether you send it to us or not.
Nothing you put in here goes to us unless you choose to send it.
Name everything. Then name what is off-limits.
The scope is a written list of exact assets, not a vibe. Vague scopes produce vague tests and arguments about whether something was “in”. Be specific enough that a stranger could read your scope and know precisely what they may touch.
- Networks and IP ranges Write down the exact CIDR blocks and individual hosts. “Our internal network” is not a scope. 10.0.0.0/16 is. If a range belongs to a third party, a cloud host or a SaaS vendor, you usually need their permission too, and the tester will ask.
- Domains and subdomains List the apex domains and the subdomains you care about. Then ask whether the tester should enumerate the ones you forgot. Forgotten subdomains are where breaches live, so resist the urge to trim them out to save money.
- Applications and APIs Name each web app, mobile app and API by URL or endpoint. Note which user roles exist and whether the tester gets accounts for each. An app tested only as an anonymous visitor leaves most of the attack surface untouched.
- Cloud accounts and identities Give the account or subscription IDs, the regions in use, and the read-only access the tester needs to review configuration. Cloud findings often come from a misconfigured role, not a vulnerable server.
- What is explicitly out Name the systems that must not be touched: a fragile legacy box, a partner’s infrastructure, anything mid-migration. Out-of-scope is a promise, and it carries the same weight as in-scope.
Production or staging, and the trap in choosing staging.
Where you test changes what the test is worth. Production is the most honest answer and the one with real risk. Staging is safer and only useful if it genuinely mirrors the real thing.
- Production The real thing, with real data and real defences. This is the most honest test: you find what an attacker would actually hit. The trade-off is the small but genuine risk of disruption, so the rules of engagement matter most here.
- Staging or UAT A copy that keeps risk away from customers. The catch: it has to match production, or you test a fiction. Different data, missing WAF rules, a stale config; any of these can hide the flaw that mattered or invent one that does not exist.
- A note on parity If you test staging, get the tester a written list of how it differs from production. Then plan a lighter, agreed pass against production for the highest-risk findings. A flaw confirmed only in staging is a hypothesis until you prove it lives in prod.
A broad sweep, or a named objective.
Decide what the test is for before it starts. A wide, even pass tells you where you stand everywhere. A pointed objective answers one frightening question with a clear yes or no. Both are valid. Mixing them up by accident is where budget gets wasted.
- Broad sweep Cover the whole surface at a consistent depth. Good for a first test, an annual baseline, or a compliance requirement that asks you to look everywhere. You learn where you stand across the estate. You go less deep on any single path.
- Named objective Point the test at a goal: “reach the payments database”, “take over an admin account from the public internet”, “move from a low-privilege user to domain admin”. This buys realism and a clear yes-or-no answer to the question that keeps you up at night.
- How to choose New to testing, or covering a wide estate? Start broad. Have a specific fear, a crown-jewel system, or a board that wants to know about one scenario? Set the objective and let the tester chase it. Many engagements do a broad pass first, then a targeted one the year after.
Black box, grey box, white box.
The “box” is just how much information the tester starts with. Less knowledge means a more realistic outsider. More knowledge means deeper coverage for the same money. Pick by the question you are answering, not by which one sounds toughest.
Black box
Just the company name or a domain, like an outside attacker. It shows what someone with no inside knowledge can reach from the internet. The downside: testers can spend days finding what you could have handed them in an email, so you pay for recon instead of depth.
Grey box
A set of login credentials, some documentation, a network diagram. It models a malicious insider or a customer who turns hostile, and it is the best value for most tests. The tester skips the busywork and spends the budget breaking things.
White box
Full documentation, credentials for every role, sometimes source code. Nothing is hidden, so the tester finds the deepest flaws rather than only the reachable ones. Pick this when you want maximum coverage and the highest assurance, and you trust the tester with the keys.
For most first tests, grey box is the sensible default. Black box looks impressive on paper, but you often end up paying skilled people to discover things you could have handed them on day one.
↑ Back to the scope builderThe ground rules, in writing, before anyone touches a thing.
A pen test is a controlled exercise. The rules of engagement set out how it runs so there are no surprises for either side, and no scramble when something goes sideways at an awkward hour.
- Timing and blackout windows Agree the testing days and hours up front, and name the periods when testing stops cold: a peak sales day, month-end close, a product launch. Put the blackout dates in writing so nobody has to make a judgement call at 2am.
- Allowed and forbidden Spell out the techniques that are off the table. No denial-of-service. No destructive payloads. No social engineering unless you have asked for it. Be explicit about whether the tester may pivot from an in-scope host into one that is out of scope.
- Data handling Decide what happens if the tester reaches real customer records. Usually the rule is: prove access, capture the minimum evidence, stop. Agree how that evidence is stored, encrypted and destroyed when the engagement closes.
- Escalation of critical findings If the tester finds something that is being actively exploited, or a flaw so severe it cannot wait for the report, you want a call within the hour. Name the threshold and the contact now, not after.
- Deconfliction contacts Name a person on each side, with a phone number, reachable during testing hours. If your SOC spots the activity, they confirm it is the test in two minutes instead of triggering a real incident response and burning a weekend.
- Written authorisation Signed permission to test the named assets, and only those. This is the document that separates a sanctioned test from a crime. No reputable tester starts without it, and if you do not own an asset, get the owner’s sign-off too.
The questions that separate a real test from a checkbox.
Ask these before you sign. The answers tell you whether you are buying genuine offensive work or a scanner run with a logo on the cover. Ask them of yourself too; half of these are scoping decisions you own.
- 01
Is this manual testing or a scan with a report wrapped around it?
A scanner finds known patterns. A human chains three small flaws into a breach and judges what actually matters in your context. Ask how many hours are hands-on-keyboard versus tool output, and what the split looks like.
- 02
Who actually does the testing, and what have they done before?
Not the sales engineer on the call. The operator on your environment. Ask for their experience, their certifications if that matters to you, and whether the same person who scopes the work is the one who runs it.
- 03
Is a re-test included?
You fix the findings, then someone has to confirm the fix held. A test without a re-test leaves you guessing. Ask whether re-testing is in the price, how long you have to remediate, and what counts as a re-test versus a new engagement.
- 04
How are findings ranked?
A raw CVSS score in a vacuum is close to useless. You want findings ordered by real risk in your environment: an internet-facing flaw on a payments system outranks a theoretical issue behind three firewalls. Ask how they decide what goes first.
- 05
What evidence do I get?
For every finding you want reproduction steps clear enough that your own engineers can see it, plus proof of impact: what was actually reached. If the report just asserts a problem and waves at it, you cannot triage it and you cannot trust it.
- 06
What methodology do you follow?
A named, repeatable methodology means the test does not depend on one tester remembering everything. Expect to hear PTES, the OWASP testing guides, NIST SP 800-115, or an equivalent. Vague answers here predict vague findings.
The scoping checklist.
Work top to bottom. By the end you have a scope a tester can quote against and a statement of work you will not have to renegotiate halfway through.
- 1
List every asset by name
IP ranges as CIDR, domains and subdomains, apps and APIs by URL, cloud accounts by ID. Write the out-of-scope list with equal care.
- 2
Pick the environment
Production or staging. If staging, document every way it differs from production and plan a confirming pass against prod for the worst findings.
- 3
Set the depth and the goal
Broad sweep, named objective, or a broad pass followed by a targeted one. Decide what question this test has to answer.
- 4
Choose the box
Black, grey or white. For most first tests, grey box gives the best value: hand over credentials and docs so budget goes to depth.
- 5
Provision access early
Test accounts for every role, read-only cloud access, VPN or allow-list entries. Do this before day one, or you pay testers to wait.
- 6
Write the rules of engagement
Timing, blackout windows, forbidden techniques, data handling, the escalation threshold for criticals.
- 7
Name deconfliction contacts
One person each side, phone numbers, reachable during testing hours. Tell your SOC the test is happening and when.
- 8
Get written authorisation signed
For every named asset. Where you do not own an asset, get the owner’s permission in writing too.
- 9
Confirm the deliverables
Manual testing, ranked findings, reproduction steps, proof of impact, a debrief, and a re-test of every fix.
- 10
Agree the remediation window
How long you have to fix, and when the re-test happens. Put it in the statement of work so it does not slip.
Common scoping mistakes.
Every one of these produces a report that looks fine and means little. Catch them at the scoping table, where they cost nothing to fix.
- Scoping too narrow to save money Trim the scope hard enough and you buy a clean-looking report that proves nothing. The asset you cut to save a day is often the one an attacker walks through. Cut depth before you cut coverage of anything internet-facing.
- Calling a scan a pen test Automated scanning has its place, but a scan report is a list of maybes. If the “pen test” is a scanner run and a PDF export, you have paid for a tool licence and a false sense of safety.
- No objective and no priorities A test with no stated goal and no risk ranking gives you a flat wall of findings and no idea what to fix first. Decide what matters before testing starts, so the report comes back ordered by your reality.
- Testing everything except what matters It is easy to scope the systems that are simple to test and skip the messy, business-critical one because it is fragile or political. The crown jewels are exactly what an attacker is after. Test those, carefully, or the exercise misses the point.
The standards worth reading.
If you want the underlying methodology and the shared vocabulary the industry scopes against, start here. These are the references reputable testers work from.
- PTES (Penetration Testing Execution Standard) →
An end-to-end methodology for how a real engagement runs, from pre-engagement scoping through to reporting.
- NIST SP 800-115 (Technical Guide to Information Security Testing) →
The US government’s technical guide to security testing and assessment. Solid grounding for planning and rules of engagement.
- OWASP Web Security Testing Guide →
The canonical reference for what good web application testing actually covers, test by test.
- OWASP Top 10 →
The widely used list of the most common web application risks. Useful shared vocabulary when you talk to a vendor.
- CREST →
An accreditation body for penetration testing providers. A reference point if you need to vet a vendor’s credentials.