Your first penetration test should be smaller than you think

Almost every first-time buyer we speak to opens with some version of the same sentence: we would like everything tested. It is an entirely reasonable instinct. You do not yet know where you are weak, so testing the lot feels like the responsible choice.

It is usually the wrong one, and not for the reason you would expect. The problem is not cost. The problem is that a wide first engagement produces findings faster than your team can absorb them, and the ones that matter get buried.

What actually happens with a wide first test

A broad engagement across applications, infrastructure and cloud typically returns somewhere between forty and eighty findings. Perhaps three of them are genuinely urgent. The rest range from worth-doing to noise.

Your team now has a spreadsheet. The urgent three compete for attention with fifty medium findings that all look similarly official in the report. Six months later a meaningful fraction is still open, the report is out of date, and the exercise has taught the organisation that penetration testing produces homework rather than clarity.

Start where attackers start

Opportunistic attackers are not creative. They take two routes with overwhelming frequency: something exposed on your perimeter that should not be, and your main customer-facing application. Almost everything else in a first engagement is a refinement of a picture you have not drawn yet.

So for a first test, we almost always recommend the same pairing:

• An external network test. Short, usually three to six days, and it answers a question you cannot answer from the inside: what is actually reachable from the internet, including the things nobody meant to expose
• Your primary web application. The one that handles accounts, money or sensitive records. Five to ten days, tested authenticated, across every user role

That combination is affordable, finishes in a fortnight, and produces a findings list a small team can genuinely close. More importantly, it tells you whether your problem is exposure, code quality, or process, which is the thing that determines what you should buy next.

What to deliberately leave out the first time

Not because these do not matter, but because they answer questions you are not yet ready to ask.

1. Red team. Red team measures whether detection and response work. If you do not yet have a detection capability to measure, you are paying specialists to confirm something you already know
2. Every application you own. Test the important one properly rather than five of them shallowly. Findings in your main app usually indicate patterns that repeat across the others, and patterns are what you want
3. Internal network, on the first pass. Valuable, but it assumes a breach has already happened. Establish whether the front door is locked before mapping the corridors

When wide is actually right

There are real exceptions, and it would be dishonest to pretend otherwise.

If a framework dictates your scope, the framework wins; PCI-DSS in particular will tell you what is in and out, and arguing with it is not a strategy. If you are being acquired or are closing an enterprise deal with a security review attached, breadth may be the point rather than depth, because the buyer wants coverage evidence. And if you have tested for years and close findings quickly, you have earned the right to go wide, because you will actually action the results.

The honest summary

Buy the smallest engagement that answers a question you cannot currently answer. Close what it finds. Then buy the next one with better information than you had the first time.

Firms that sell testing by the day have an obvious incentive to talk you out of this. That is worth remembering when you are reading a proposal that has grown considerably since the first conversation.