How to scope your first penetration test

The hardest part of a penetration test is usually not the test. It is deciding what to test, why, and what counts as success. Get the scope right and the engagement runs smoothly. Get it wrong and you pay for a thorough look at the wrong thing.

Here is how we help first-time buyers scope an engagement that actually answers their question.

Start with the fear, not the asset list

Before listing servers, finish this sentence: "If we got breached, the thing that would hurt most is ___."

Customer data? Payment flows? Downtime on the platform your revenue depends on? Your answer points the whole engagement. A test scoped around your real worst case is worth ten tests scoped around whatever was easiest to put in a spreadsheet.

Decide what the attacker knows

Penetration tests usually run in one of three modes, and the right one depends on what you are trying to prove.

• Black box. We start with nothing but your name, like an outside attacker. Realistic, but slower, because we spend time on reconnaissance you could have just told us.
• Grey box. We get some access, like a normal user account. This is the sweet spot for most web and app tests. It mirrors a phished employee or a malicious customer.
• White box. We get full access, documentation, sometimes source code. Fastest path to deep coverage when your goal is to find as much as possible, not to simulate a specific attacker.

Most first tests should be grey box. It balances realism against the hours you are paying for.

Define the boundaries clearly

Good scope is specific about what is in and what is out. List the exact domains, IP ranges, applications, and accounts. Just as importantly, list what we must not touch: production systems with no failover, third-party services you do not own, anything under active incident.

This is also where rules of engagement live. When can we test? Do you want to know in advance, or do you want your team tested too, blind? Who is our emergency contact if something looks genuinely on fire?

Agree on what "done" looks like

A test should end with more than a list. Decide up front that you want:

• Findings ranked by real business risk, not just raw severity.
• Proof for each finding, so nobody argues about whether it is real.
• Clear remediation guidance your team can actually action.
• A retest after you fix things, to confirm the fixes hold.

If a provider will not retest, ask why. Fixing a finding and never verifying the fix is how the same issue shows up in next year's report.

Be honest about timing

The two most common scoping mistakes are testing too late and testing too rushed. Book the test before a launch, not the week of it, so you have time to fix what we find. And give the engagement enough days to go deep. A serious application needs more than an afternoon.

The short version

Scope around your worst case, pick the access model that matches the threat you care about, draw clear boundaries, and define success as proof plus a fix plus a retest. Do that and your first penetration test will feel less like a leap of faith and more like the routine it should become.

When you are ready, talk to an operator and we will help you scope it properly.