How to scope a penetration test so the result is worth having
The quality of a penetration test is decided before anybody touches the system. A scope written in a hurry produces a report full of findings you already knew about, and leaves untested the one thing that would have kept you awake. The scope document is the product you are really buying.
What a tester needs from you before quoting
Every serious supplier will ask for the same material. Preparing it once, properly, makes every quote better and faster.
- An asset list. Named applications, domains, hostnames, address ranges, mobile applications, interfaces, and anything reachable that you own. Say which are in scope and which are explicitly out.
- Environments. What exists — production, staging, a dedicated test environment — and how faithfully each mirrors the others.
- User roles. Every distinct permission level, including the administrative ones, and whether tenants or customers are separated inside the application.
- Authentication. How users sign in, whether federation or single sign-on is involved, whether a second factor will obstruct automated requests, and how a tester obtains accounts.
- Integrations. What the system calls and what calls it, including anything belonging to a third party, which needs its own permission.
- Data sensitivity. What kinds of data live there — personal information, health information, payment data — because it changes both the handling rules and the severity of a finding.
- Size. Rough counts of endpoints, screens or functions. This is the main driver of effort, and therefore of what the engagement costs.
Black box, grey box or white box?
Black box means the tester starts with what an outsider could learn. White box means full access to source, architecture and configuration. Grey box is in between: credentials for each role, a description of the architecture, and no source.
Grey box is usually the right answer, for an unglamorous reason. In a time-boxed engagement, hours spent rediscovering facts you already know are hours not spent attacking. Black box tests the question “can an outsider get in”, which is worth asking occasionally; grey box tests the question “what can go wrong here”, which is the question your risk actually turns on. White box finds the most per day and is worth the extra preparation for anything where a failure would be severe.
Refusing to hand over information does not simulate a real attacker, who has unlimited time and no contract. It simulates a rushed attacker, which is not the one you should plan for. The difference between this and a scheduled scan is set out in pentest vs vulnerability scan.
Production or a production-like environment?
Testing production gives results about the system that actually serves your customers, including its real configuration, its real data volumes and its real integrations. It also carries the risk of degraded performance, polluted data and triggered alerts.
Testing a staging environment removes that risk and introduces a subtler one: you learn about a system nobody uses. Staging environments drift — different configuration, older dependencies, missing integrations, a different reverse proxy, no rate limiting — and findings from a drifted environment are neither reliably true nor reliably false about production.
The workable compromise is to test a production-like environment, document the differences that are known, and agree a short list of read-only checks against production to confirm that the configuration findings hold there. If you do test production, agree the blast-radius limits in the rules of engagement and take a backup first.
Why refusing credentials usually wastes money
Most of what matters in a modern application is behind the login. Access control between users, between roles and between tenants is the first category of the OWASP Top 10:2025 and cannot be tested at all without at least two accounts at the same privilege level and one at each other level.
Ask for accounts to be created specifically for the engagement, named so they are obvious in your logs, and disabled afterwards. Provide at least two per role. If your application supports tenants, provide two tenants — the single most valuable pair of credentials you can hand over, because it is the pair that tests whether one customer can reach another’s data.
Time-boxing, and what a short engagement cannot reach
Testing is bounded by days, not by completeness. A short engagement covers the common categories across a narrow surface and reports what it found in the time available; it does not reach chained findings, subtle business logic, or anything requiring patient state manipulation. Those need a tester to build a mental model of the system first, and model-building takes days before it starts paying off.
Ask any supplier what they would not get to in the days quoted. The answer tells you more about their judgement than the methodology section does.
Agree the retest up front
You will fix things. Somebody then has to confirm the fixes work, and a fix that introduces a new problem is common enough to be worth planning for. Agree in the original scope how many retest days are included, how long after the engagement they remain available, and what the tester will produce afterwards.
Buying the retest later, as a separate engagement, means paying again for the tester to rebuild context they had at the end of the first one. It is the most reliably wasted money in the whole exercise. What the retest produces, and what it can and cannot claim, is covered in what a report should contain.
Rules of engagement
A short written document, agreed before anything starts, covering:
- Window. Dates and hours. Whether out-of-hours work is permitted, and whether it is preferred.
- Prohibited techniques. Denial of service, social engineering, physical access, anything touching a third party — each named and each either permitted or not.
- Immediate-notification triggers. What the tester tells you about at once rather than in the report: a critical finding, evidence of a prior compromise, exposed personal information.
- Contacts on both sides, including out of hours, with a phrase agreed in advance that means stop now.
- Data handling. What the tester may extract as evidence, how it is stored, and when it is destroyed.
Authorization: who signs, and why the tester will insist
Testing a system without permission is not a grey area. The permission has to come from somebody who can actually give it — the owner of the system, not the engineer who invited you in — and it has to be in writing, naming the assets, the window and the people performing the work.
Where the asset is hosted by somebody else, their terms may require their authorization too, and a tester who has done this before will ask about it before the window opens rather than on the morning it starts.
Treat a supplier who does not ask for a signature as a warning. It means either that they have not done this often, or that they are willing to work outside the paperwork — and a supplier willing to be careless about that is a supplier you are trusting with your production systems. Our own testing is carried out only with signed authorization, to a scope agreed in writing, which is the same standard any competent supplier will hold themselves to.
Writing scope so two quotes are comparable
Two quotes are comparable only when both answer the same four questions: what is in scope by name, which roles are tested from, how many days of work are planned, and what is delivered at the end. Write the scope once, as a document, and send the same document to everyone. Quotes written against different assumptions cannot be compared on price, which is exactly how a cheap quote wins work it should not.
Name the methodology too. For web applications the OWASP Web Security Testing Guide is the common reference and is the one this practice works to; naming it means both suppliers are proposing against the same map. Then ask each to state, in their response: the days of effort, the roles they will test from, whether retest is included, and what the deliverable contains. A redacted sample report is a fair thing to ask for — ours is published.
What drives the price, in rough order: the number of distinct functions in scope, the number of roles and tenants, whether source is provided, whether production is in scope, and whether retest is included. No figures appear on this site; engagements are quoted in writing against a scope, which is the only honest way to do it.
Where the result goes afterwards
Decide in advance who receives the report, because that changes what you ask for. If it is going to a customer or into a compliance file, ask for an executive summary written for a reader who was not involved, and check whether the supplier will produce a short covering letter confirming the engagement happened. If it is going to your engineers, prioritize reproduction steps and concrete remediation over narrative.
If the report is destined for a compliance file, check what the framework expects before you scope, not after — the sequencing questions are covered in readiness, and the testing service itself in penetration testing.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Should we tell our own team about the test?
Tell the people who would otherwise respond to an incident, and tell them what the engagement is and when it runs. Keeping the whole organization in the dark is a red team exercise, which is a different product with a different purpose.
What if we do not know our own asset list?
Not knowing your own asset list is a finding in itself, and the honest way to handle it is to scope a discovery phase first and then scope the test against what discovery found.
Can the scope change mid-engagement?
Scope can change mid-engagement, and it should when the tester finds something important just outside the boundary — but it changes by a written amendment that both sides sign, never by a conversation.
How do we make two quotes comparable?
Two quotes are comparable only when both answer the same four questions: what is in scope by name, which roles are tested from, how many days of work are planned, and what is delivered at the end.
Getting the scope right
Send what you have — an asset list, a rough description, or just the clause that started this. The reply is a scope you can send to several suppliers. More of our writing is indexed at writing.