Booking your first penetration test can feel like a big step. Most people are not sure what the tester needs from them, what will happen once it starts, or how much disruption to expect. In practice a well prepared test is smoother, cheaper and far more useful than one where half the first day is lost sorting out access. This guide walks through everything worth doing before the testing window opens, so you get the most out of the engagement.

First, know what a penetration test really is

A penetration test is not the same as a vulnerability scan. A scan is an automated tool that flags known weaknesses. A penetration test uses those tools as a starting point, then a real tester manually chains issues together the way an attacker would, to show how far someone could actually get and what it would cost you. The output is not a raw list of alerts. It is a prioritised set of findings, each with the business impact spelled out and clear guidance on how to fix it. Knowing that distinction up front helps you brief the right people internally and set the right expectations.

Work out which type of test you need

“Penetration testing” covers several quite different jobs, and the preparation for each is different too. The common ones are:

• External infrastructure. Everything of yours that faces the internet: servers, firewalls, VPNs, mail and remote access.
• Web application. A specific site or web app, including the logic behind logins, payments and user roles.
• Internal network. What an attacker or a rogue insider could do once they are already inside, including Active Directory.
• API. The interfaces your apps and partners talk to, which are a very common weak point.
• Mobile application. Your iOS or Android app and the servers behind it.
• Cloud. Your configuration in AWS, Azure or Google Cloud, where the risk is usually misconfiguration rather than a missing patch.

You do not need to know exactly which of these you want before you get in touch. Part of a good scoping call is working that out together. But having a rough idea of your biggest worry helps enormously.

Get clear on scope before anything else

Scope is the single thing that most affects the quality and the price of a test. It is simply the agreed list of what is in and what is out. For infrastructure that usually means IP ranges or hostnames. For an application it means the specific URLs, and often which user roles are included. Be explicit about anything you want left alone, for example a fragile legacy system or a live payment flow you would rather test out of hours.

One thing people often miss: if part of what you want tested is not fully yours, you may need permission from whoever owns it. A payment provider, a SaaS platform or a shared hosting environment can all sit inside your scope on paper but belong to someone else in practice. Flag those early so nobody tests something they are not allowed to.

Decide how much you want to share

Tests are usually described as black box, grey box or white box, and that just describes how much information the tester starts with.

• Black box means the tester begins with almost nothing, like a genuine outside attacker. It is realistic but slower, because time goes on discovery rather than depth.
• White box means full access to source code, documentation and accounts. It finds the most, but it is less like a real attack.
• Grey box sits in the middle, with some credentials and a bit of context.

For a first test, grey box is usually the best value. You are paying for the tester’s time, and handing over a few test accounts means that time is spent finding real problems rather than knocking on the front door.

Sort out access and accounts early

Nothing wastes testing time like access that was promised but never arrived. Depending on the type of test I might need test accounts at each permission level, a copy of the application in a staging environment, VPN access into an internal network or an allowlisted IP address so your own defences do not simply block me on day one. If your logins use multi-factor authentication, we need to agree how the tester gets through it. Get all of this ready and delivered securely before the start date, and the whole window is spent testing rather than waiting on a password reset.

Get authorisation in writing

This part is boring and it matters. Before any testing starts there should be a clear rules of engagement document that both sides sign, setting out what is in scope, when testing happens and who to call if something goes wrong. If you are testing systems hosted by someone else, check their rules too. Most cloud providers publish a penetration testing policy, and some kinds of testing need notice or are restricted. Sorting the paperwork out in advance keeps everyone protected and stops the test being paused halfway through.

Decide who needs to know

For most first tests, your own team should know it is happening. That way nobody panics when odd traffic shows up in the logs, and nobody spends a stressful afternoon thinking they are under real attack. If instead you want to see how your people and your monitoring react to an unexpected intrusion, that is a valid and valuable exercise, but it is a deliberate choice we plan for, not something that happens by accident. Either way, decide in advance who is in the loop.

Freeze big changes and take a backup

Try not to deploy major changes to the systems being tested during the testing window. A moving target is hard to test well, and it makes the results confusing, because nobody is sure whether a fix or a new feature changed the behaviour. Take a backup beforehand as a matter of routine. Testing is careful and controlled, but you are still working against live systems, and a backup is cheap insurance. If a system is business critical during office hours, we can schedule the noisier work for an evening or a quieter window to keep disruption to a minimum.

Understand how findings are rated and reported

A good report has two halves. There is a short summary written for management, which explains the overall risk in plain language and what it means for the business. Then there is the technical detail for the people doing the fixing, with each finding rated by severity, usually using a recognised scoring system, along with evidence and step by step guidance to reproduce and resolve it. Knowing this in advance helps you line up the right readers. Your board wants the summary. Your engineers want the detail. A report that only does one of those is only half a report.

Have a plan to act on the results

A test is only worth what you do with it. Before it even starts, think about who will own the fixes and roughly how fast you can turn them around. The clients who get the most value treat the report as a to do list, not a filing cabinet. Ask up front whether a retest is included, because confirming the fixes worked is the step that turns a report into genuine assurance you can show a client or an auditor.

What to expect once it starts

You should have a named point of contact and a direct channel to reach them throughout. Serious issues should be reported to you the moment they are confirmed, not held back for the final document, so you can start fixing the worst things straight away. At no point should it feel like the test is being done to you rather than with you. If it does, that is usually a sign you picked the wrong provider.

Your quick checklist

• Know roughly what you want tested and why
• Agree the scope in writing, including anything off limits
• Get permission for anything you do not fully own
• Prepare test accounts, access and any staging environments
• Sign off the rules of engagement
• Decide who internally needs to know
• Freeze major changes and take a backup
• Line up who will own the fixes
• Confirm a retest is included

Do that and your first penetration test will be far less daunting than you expect, and a good deal more valuable. If you are weighing one up and want to talk it through, a scoping call is a no obligation way to start.