Penetration testing or vulnerability assessment — which do you need?

The two are often talked about as if they were the same service at different prices. They are not. A vulnerability assessment is a broad review that tells you what is weak. A penetration test is an authorised attempt to reach one stated goal, and it tells you whether the weakness can actually be used. One is a list; the other is a demonstration.

The assessment: what is weak

An assessment works through everything in scope and reports on all of it, which makes it the better first look at a system nobody has examined from outside. It is also the one that makes sense as a habit, because the second assessment can be compared with the first.

• Services reachable from the internet, including the ones nobody remembers switching on.
• Software versions and patch levels, against what is known about them.
• Accounts and permissions: who has administrative rights, and whether that is still justified.
• Encryption, certificates and how sessions end.
• Logging and backups, because an incident nobody can see is one nobody can stop.

The test: whether it can actually be done

A test begins with one goal, written in a sentence you have approved, and works along the paths a real attacker would take to reach it. Findings tend to be fewer and heavier than in an assessment: not "this library is old", but "from this old library, we reached the customer table".

• Whether somebody outside can reach customer records, payments or staff data.
• Whether an ordinary user can reach what belongs to another user, or to an administrator.
• Whether a workflow can be abused — a discount applied twice, an approval skipped, a price altered in the request.
• Whether an account that should have been closed still opens a door.

Which one you need

• If nobody outside has ever looked at your systems, start with an assessment. Breadth before depth, then fix what it finds.
• If a client, a bank or an investor has asked a specific question, that question is a penetration test: you are buying evidence, not a survey.
• If you have just changed something significant — a new payment route, a new integration, a move of hosting — scope the work to the change rather than paying for the whole system again.
• If it is an ongoing obligation, an assessment at an agreed interval with a test on the part that matters most is more useful than a single deep test once.
• If you are not sure, ask what decision the output has to support. That answers the question every time.

What neither of them proves

Both are photographs of a moment. A test finds what was reachable while it ran, on the systems that were in scope, using the techniques that were agreed. It does not prove that a system is secure, and a report that does not say what was excluded is not telling you the whole story. If a supplier offers certainty rather than findings, limits and dates, the offer is worth less than it sounds.

Both start with authorisation

Whichever you buy, the first deliverable is a document rather than a scan: the systems in scope and the ones deliberately excluded, who has signed for it, the hours work may run in, the techniques permitted, the condition that stops everything, the person to call if a system misbehaves, how evidence is stored and when it is destroyed, and what will be retested afterwards. If your site or system sits on somebody else's infrastructure, their rules may require notice before testing, and that notice belongs in writing before anything starts.

We run both, and we will tell you which one your situation actually calls for — including when the honest answer is that you should close what an earlier report already listed before buying another one. A report is only worth its cost if somebody acts on it, which is why every engagement ends with a retest of the agreed fixes and a conversation with the people who will do them.