Most organisations do not buy a penetration test because they woke up wanting one. They buy because a customer sent a security questionnaire, an insurer asked at renewal, an investor raised it in diligence, or something happened that made the question urgent.

If that is where you are, here is what the process actually looks like — so you can prepare properly and get a useful result rather than an expensive PDF.

Step one: work out what you are protecting

Before contacting anyone, answer one question: what would hurt most if it were compromised?

Customer data in an application? Test the application. Your internal network and file shares? Test infrastructure. Everything in Microsoft 365? Review the cloud configuration. The answer determines which test you buy, and buying the wrong one is the most common and most expensive mistake first-time purchasers make.

If a specific trigger prompted this — a questionnaire, a contract clause — go back and read the exact wording. It often specifies the type of test, and occasionally an accreditation requirement, both of which decide your shortlist before you speak to anyone.

Step two: gather scoping information

Testing is priced in tester days, and days are estimated from scope. The more precisely you can describe what exists, the more accurate your quote and the less likely you are to face a mid-test conversation about work that was not costed.

For infrastructure:

• How many live external IP addresses — live ones, not the size of your range
• How many internal hosts, and roughly how many subnets
• How many physical locations
• Whether the network is segmented, and if so, how
• Whether you run Active Directory

For applications:

• How many distinct applications
• How many user roles, and what separates them
• Whether there is an API, and whether it should be in scope
• Which environment will be tested — production, staging or development
• Any third-party integrations or embedded components

For cloud: which platforms (Microsoft 365, Azure, AWS), how many tenants or subscriptions, and roughly how many users.

Do not worry about being exact. Part of an external test is discovering things you did not know were exposed — that is a finding, not a scoping failure.

Step three: choose where to test

For applications, you will be asked whether to test production or staging.

Production gives the honest answer, because it is the environment your customers and any attacker actually use. The risk is that testing generates load, fills logs with alerts, and can create test data in live systems.

Staging is safer, but only useful if it genuinely mirrors production. A staging environment with different configuration, older code or a sanitised database will produce findings that do not reflect reality — and, more dangerously, will miss ones that do.

Our usual recommendation is production, tested during agreed hours with your team aware it is happening. If that is not possible, staging is workable provided someone can confirm it genuinely matches.

Step four: tell the right people

This gets forgotten, and it causes real problems.

• Your IT team or MSP — otherwise they will see the testing, treat it as an attack, and respond. That is a good sign for your monitoring and a waste of everyone's afternoon.
• Your hosting provider — some require notification before testing on their infrastructure.
• Whoever runs your WAF or DDoS protection — if a protective layer blocks the tester at the edge, you have paid to test the appliance rather than the application behind it.

Whether to allowlist the tester's IPs is a genuine decision, not an oversight. Leaving protections active tests your defences as they stand; allowlisting tests the underlying application. Both are legitimate. Some organisations do both in sequence. Decide deliberately.

Step five: the test itself

Testing usually runs over several days. Most of it happens without you noticing. What you should expect:

• A confirmed start and end date, not a vague window
• Immediate notification of anything critical. If a tester finds something serious on day one, you should hear that day, not in the report two weeks later. Ask about this — the answer tells you a lot about a provider.
• A named point of contact on both sides

Step six: reading the report

A good report has three parts, aimed at different readers.

The executive summary is for people making decisions about money. It should say how exposed you are and what to do about it, in language that does not require a security background.

The technical summary is for the people fixing things — the shape of the problems and how they relate.

The detailed findings give each issue with its risk level, how hard it is to exploit, reproduction steps, and specific remediation advice. "Upgrade to a supported version" is advice. "Apply patch X to host Y" is useful advice.

Findings are usually rated by severity. Two things worth knowing: a long list of low-severity findings is normal and not cause for alarm, and severity is contextual. A medium-rated issue on a system holding your customer database may matter more to you than a high-rated one on an isolated test box. Push back if the ratings do not reflect your environment — a good tester will engage with that.

Step seven: what happens afterwards

This is the step most first-time buyers underestimate. The report is not the end of the work; it is the start of it.

Prioritise by exploitability and impact rather than working down the severity list, fix in that order, and then get the fixes verified. A retest confirms the issues are genuinely resolved and produces an updated report — which is usually what the customer or auditor who triggered this actually wants to see. We include retesting and reissue the report with updated status for exactly that reason.

Then plan the next one. Penetration testing is a snapshot; your environment changes. Annually is the common cadence, with additional testing after significant change. Between tests, managed vulnerability scanning covers the gap by catching newly disclosed issues as they emerge rather than eleven months later.

What it will cost

Our starting prices run from £500 for an external infrastructure test to £2,000 for mobile application testing, with full figures in our UK penetration testing cost guide.

If you would rather skip the research, describe what you are running and we will tell you what we would test, what it would cost, and how long it would take. If we think you need something other than a penetration test, we will tell you that instead.