If you have never bought a penetration test before, the market does not make it easy. Everyone uses the same words, the quotes vary by thousands of pounds for what looks like the same thing, and it is genuinely hard to tell what you are paying for. This is an attempt to set that out plainly.

A scan is not a test

The single biggest source of confusion is the difference between a vulnerability scan and a penetration test, because plenty of suppliers sell the former as the latter.

A vulnerability scan is automated. A tool connects to your systems, compares what it finds against a database of known issues and produces a list. It is fast, it is cheap and it is genuinely useful. It is also blind. It reports that a service is running an outdated version. It cannot tell you whether that actually matters in your environment, whether the flaw is reachable, or what an attacker could do next.

A penetration test uses those tools as a starting point and then a human being does the actual work. The tester verifies what is real, discards what is noise, and chains the surviving issues together to see how far they lead. The output is not a list of alerts. It is a set of findings, each one confirmed, each one rated on the risk it presents to your business, each one with clear guidance on the fix.

A rough test: if the report could have been produced without anyone reading it, you bought a scan.

Why chaining matters more than counting

Most reports that impress a client do not contain a single critical vulnerability. They contain four or five medium ones that, taken together, get an attacker from the internet to your domain controller.

A username enumeration flaw on its own is low risk. Combined with a weak password policy and no lockout, it is a route in. An outdated component with no known exploit is a note in the appendix. The same component with an exposed admin interface and default credentials is the whole engagement.

Attackers do not care about your vulnerability count. They care about the path. That is why the manual part is the part you are paying for.

The main types, briefly

Penetration testing is a category, not a product. The common assessments are:

• External infrastructure. Everything of yours that faces the internet, including servers, firewalls, VPNs, mail and remote access.
• Internal infrastructure. What someone could do once they are already inside, whether that is a malicious insider, a contractor or an attacker who got a foothold through phishing. Usually includes Active Directory.
• Web application. A specific site or application, including the logic behind logins, payments and user roles.
• API. The interfaces your applications and partners talk to, which are frequently weaker than the front end they sit behind.
• Mobile application. Your iOS or Android app and the infrastructure serving it.
• Cloud configuration review. Your setup in Microsoft 365, Azure or AWS, where the risk is nearly always misconfiguration rather than a missing patch.

You do not need to know which of these you want before you get in touch. Working that out is what a scoping call is for. What helps enormously is knowing what you are actually worried about, because that is usually the right starting point.

What you should get at the end

A report that does two jobs at once, because it has two audiences.

The first section is for management. It should explain, in plain language, the overall risk position and what it means for the business. No jargon, no tool output, no vulnerability names. If your board cannot read it and understand where they stand, it has failed.

The rest is for the people fixing things. Each finding rated by severity, evidence that it is real, steps to reproduce it and guidance specific enough to act on. Not a link to a vendor advisory and a shrug.

You should also get a retest. Confirming the fixes actually landed is the step that turns a report into assurance you can hand to a client, an auditor or an insurer. A test without a retest tells you where you were, not where you are.

What it costs you beyond the invoice

Some effort, and it is worth budgeting for. You will need to agree a scope, prepare test accounts and access, tell the right people internally so nobody panics at the logs, and take a backup as routine. Then somebody has to own the fixes afterwards.

The clients who get the most from testing are the ones who treat the report as a to do list rather than a filing cabinet. The findings are only worth what you do with them.

Do you need one

If you handle other people’s data, sell to organisations that ask about your security, operate in a regulated sector or are being asked for evidence by an insurer or a large customer, then yes, and probably sooner than you think.

If you are weighing up a first assessment and want to talk it through, a scoping call costs nothing and there is no obligation attached to it.