How to Scope a Penetration Test: A Practical Guide
Most penetration testing quotes come back wildly different, and the reason is almost never the tester. It is the scope. Two providers looking at the same business will price very differently if one has been given a clear list of targets and the other has been told to have a look at our environment.
Scope is the single decision that controls what you pay, how long the test takes and whether the report tells you anything useful. Get it right and a penetration test earns its keep. Get it wrong and you pay for a week of work that confirms your marketing site is fine.
This guide walks through how to scope a penetration test as a small or mid sized Australian business. No jargon, no assumptions that you have a security team.
What scope actually means
Scope is the written answer to four questions. What are we testing, from where, under what rules, and what do we get at the end. Everything else is detail.
A tester cannot test everything. Time is finite, and a good tester spends it where risk actually sits. Your job in scoping is not to describe your whole environment. It is to point at the part of it that would hurt most if it failed.
Step one: name the risk before you name the assets
Start with a sentence, not a spreadsheet. What is the breach that would genuinely damage this business?
For a SaaS company it is usually one customer being able to read another customer’s data. For a professional services firm it is the file server and the mailboxes. For an online retailer it is payment flow and customer records. For a business bidding into government or defence work, it is often whatever the contract says you must protect.
Write that sentence down. Every scoping decision after this either serves it or does not. It is also the fastest way to stop a scoping conversation drifting into a tour of your network diagram.
Step two: list the targets, and count them
This is where quotes go wrong. Providers price on volume, so vague target lists get priced defensively. Give exact numbers and you get an exact quote.
For a web application
- The URL of the application, and whether staging or production is being tested
- Number of distinct user roles, for example admin, standard user, read only
- Whether there is an API, and if so how many endpoints
- Rough number of unique pages or screens behind login
- Whether the application handles payments, health data or identity documents
For infrastructure
- Number of live external IP addresses, not the size of your allocated range
- Number of internal hosts, if internal testing is in scope
- Cloud tenancies in play, such as Microsoft 365, Azure or AWS
- Whether remote access, VPN or Citrix is included
- Any segmented environments that must be tested separately
If you do not know these numbers yet, say so. A short discovery call or a vulnerability assessment will produce them, and that is a cheaper way to find out than paying a tester to spend day one counting.
Step three: decide how much you tell the tester
There are three broad approaches, and the differences matter more for your budget than most people expect.
Black box
The tester gets a name or a URL and nothing else. It simulates an outsider with no inside knowledge. It feels realistic, and it is the most common request from people new to testing.
The problem is that you are paying skilled people to spend a meaningful share of the engagement rediscovering things you already know. For a small business budget, that is expensive reconnaissance.
Grey box
The tester gets credentials and basic documentation, then tests as an attacker who has already got a foothold or a stolen login. For most Australian SMBs this gives the best findings per dollar, because it goes straight at the parts of the application that only appear after login.
White box
Full documentation, architecture, sometimes source code. Deepest coverage, highest cost, and usually reserved for a product where a flaw would be catastrophic.
If you are unsure, grey box is the sensible default. It is worth reading our guide to the types of penetration testing to see how these approaches map onto web, network, wireless and cloud testing.
Step four: set the rules of engagement
Rules of engagement are the boundaries you and the tester agree before anything starts. They protect your business and they protect the tester.
- Test windows. Business hours are usually fine and easier to support. Out of hours testing costs more and slows communication.
- Denial of service. Almost always excluded. Confirming that you can be knocked offline is rarely worth the outage.
- Production or staging. Production gives real results. Staging is safer but only useful if it genuinely mirrors production.
- Data handling. Agree what happens if the tester reaches real customer records, and how findings are stored and destroyed.
- Escalation. Name one person the tester calls immediately if they find something critical or evidence of a prior compromise.
- Third parties. If your application is hosted by a provider, check whether you need to notify them. Testing systems you do not control without permission is not acceptable.
Our checklist on how to prepare for a penetration test covers the practical side of getting accounts, allowlisting and approvals ready before the start date.
Step five: agree what you get at the end
Scope is not finished at the point testing stops. Decide upfront what the deliverable looks like, because this is where value is either created or lost.
- A technical report with findings, evidence and reproduction steps
- An executive summary that a non technical director can read
- A risk rating approach you understand, and that reflects your business context
- A live debrief where your team can ask questions
- A retest after remediation, and whether it is included or charged separately
- A summary letter you can share with customers or auditors, without exposing detailed vulnerability information
That last item matters more than people expect. If you are testing to satisfy a customer or an ISO 27001 auditor, a shareable summary letter is what actually closes the request. Ask for it while you are negotiating, not after.
Scoping for compliance rather than curiosity
If the test exists because a standard or a customer contract requires it, the scope is partly written for you. Read the requirement before you write the scope.
- ISO 27001 does not mandate a penetration test by name, but auditors commonly expect technical testing as evidence for controls covering technical vulnerability management and secure development. Scope should cover the systems inside your ISMS.
- SOC 2 does not name penetration testing as a required control either, but many auditors and most enterprise customers expect one. Scope should cover the systems in the service commitment.
- Customer contracts often specify frequency and sometimes scope. Read the clause before you buy, because a test of the wrong system satisfies nobody.
If a deadline is driving this, tell the provider. Scope, lead time and reporting turnaround all move when there is a date to hit.
Common scoping mistakes
Scoping everything at once
A first test that covers external perimeter, every internal host, the web app, wireless and social engineering will produce a report nobody has the capacity to act on. Test the highest risk area properly, fix what comes back, then widen.
Scoping only what you know is clean
It is tempting to point the tester at the system you have already hardened. It produces a comfortable report and no value.
Confusing a scan with a test
If the quote is very low and the deliverable is a tool output, you are buying a vulnerability scan. Both have a place, and the difference between penetration testing and vulnerability scanning is worth understanding before you commit.
Leaving remediation out of the plan
Book the remediation time when you book the test. A report that sits unread for three months has cost you money and changed nothing.
Common questions
How long should a penetration test take?
For a typical Australian SMB, a focused external or web application test commonly runs three to five testing days, plus reporting time. Larger applications and internal network testing take longer. If a provider quotes a single day for a complex application, ask what they intend to leave out.
Should I test staging or production?
Production, where you safely can. Staging environments drift from production, and a finding in staging is only useful if the same code and configuration run live. If you must use staging, confirm it is a true mirror and note the limitation in the report.
Do I need to include social engineering or phishing?
Not in your first test. Phishing simulations answer a different question, about people and process rather than technical exposure. Run them separately once your technical findings are under control.
Can I reduce scope to fit a budget?
Yes, and it is better than stretching a small budget across everything. Narrow the scope, test that part properly, and plan the next area for the following quarter. A thorough test of one system beats a shallow look at five.
How often should we retest?
After remediation, and then on a regular cycle or whenever something material changes. Our guide on questions to ask a penetration testing provider covers how to confirm retest terms before you sign.
Getting your scope right
Good scoping is mostly honesty. Name the risk that would hurt, count your targets, give the tester enough access to be efficient, agree the rules, and decide what the report has to prove. Everything else is negotiation.
Siege Cyber is a CREST accredited Australian penetration testing provider, and we scope engagements around what your business actually needs to protect rather than what fills a week. If you want a hand shaping a scope before you go to quote, get in touch and we will work through it with you.
Written by Peter Stewart, Technical Director, Siege Cyber.