A vulnerability assessment is an automated review that scans your systems and returns a list of known flaws. A penetration test, or pentest, is a manual exercise in which someone actually tries to get in, chaining those flaws together as an attacker would, until they demonstrate how far they can go.
The difference in one sentence: one tells you which doors appear to be open and the other shows you what is inside the house.
Both are necessary and they do different things. The problem, which I have seen many times, is that they are sold as if they were the same thing.
What exactly does a vulnerability assessment do?
A tool scans the addresses, ports, and services you specify, compares what it finds against a database of known flaws, and produces a report with everything that matches, sorted by severity.
It is fast, it is inexpensive, it can be repeated every week, and it can be fully automated. That is why it is the foundation of any program of vulnerability management that works.
And it has two limits worth knowing before relying on the report.
It does not know whether the flaw is exploitable here. It reports that a flaw exists, not that it can be used. A critical vulnerability on a server that is not exposed and that no one can reach is, in practice, less urgent than a medium one on the portal all your customers use. The tool does not make that distinction because it does not know your business.
It does not chain anything. It sees each flaw separately. And real attacks almost never use a single serious flaw: they use three small ones, one after another, that no one would have prioritized individually.
And what does a pentest do?
A person with judgment tries to get in. They use tools, of course, but what they contribute is what no tool does: deciding which path to try next based on what they just found.
That work produces three things a scan cannot produce:
- Proof. Not a theoretical flaw, but proof that this flaw leads to a specific place. With screenshots, with the steps, and with what could be seen.
- Chain. The complete path, which is usually the most valuable finding and the most surprising: three minor issues that together grant administrative access.
- Context. Someone who understands that your customer database matters more than the test server, and prioritizes accordingly.
How do they differ, point by point?
| Vulnerability assessment | Penetration test | |
| Who performs it | A tool | A person, with tools |
| What it delivers | A list of possible flaws | Demonstration of real access |
| How long it takes | Hours | One to several weeks |
| How often | Weekly or monthly | Once or twice a year, and after major changes |
| False positives | Quite a few; they need to be filtered | Very few, because each one is verified |
| What it answers | What do I still need to patch? | How far could someone get? |
Why is the confusion so costly?
Because the reports look alike. Both arrive as PDFs, both include a list of findings color-coded by severity, and both allow you to state in a compliance document that the test was done.
What changes is the price and what you know afterward. I have seen companies pay for what they thought was a penetration test and receive, weeks later, the output of an automated scan with the vendor’s logo on top. Nothing delivered was false. It simply was not what was needed.
The way to know in advance is to look at three things before signing:
- How many person-hours it includes and who performs them. If the proposal does not state hours, it is not a pentest.
- Whether the report includes the complete path of at least one access achieved, with its steps, and not just a list.
- What methodology it follows. A serious pentest relies on public frameworks such as the OWASP testing guide, and the vendor should be able to tell you which one it uses without hesitation.
What should the report include?
This is where you see whether what you bought was what you thought. A serious pentest report, following what is set out in the NIST technical guide to information security testing, includes six pieces:
- The scope and the dates. What was tested, what was left out, and when. Without this, the report cannot be compared with next year’s.
- An executive summary that can be understood without being technical and that states what matters: whether access was achieved, how far, and what it means for the business.
- Each finding with its reproduction. The exact steps to achieve it again. If your team cannot reproduce it, it cannot verify that it fixed it either.
- At least one complete chain, told from start to finish. This is the part that distinguishes a pentest from a dressed-up scan, and it is the first thing to look for when you open the document.
- Prioritization that speaks to your business, not just technical scores. A medium flaw in the billing system can matter more than a high one on a test server.
- Concrete recommendations, what to change, with what, and in what order. Not “apply best practices.”
And one piece that is almost never requested and always should be: a follow-up verification test. That is, the vendor comes back a few weeks later to verify that what you fixed really stayed fixed. Without that, the report is a snapshot of problems that no one confirmed were resolved.
What if they find nothing?
It happens, though less often than people think. And when it does, it is worth reading carefully, because there are two very different interpretations.
One is that your external exposure is reasonably well locked down, which is good news and deserves to be said.
The other is that the scope was too narrow or the time too short. Two weeks on three internet addresses can end without serious findings and say little about the rest of your company.
The question that separates one interpretation from the other is simple: what was left out of scope? If the answer is “almost everything,” the clean report does not mean what it seems.
What types of pentest are there?
They are classified by two things: how much information the tester is given, and where the test is run from.
By information. In black box, the tester is given nothing and simulates an external attacker starting from scratch. In gray box, the tester is given regular user credentials, which is the most realistic scenario because it simulates someone who has already obtained an account. In white box, the tester is given everything, including the code, and it produces the most findings per hour invested.
Black box is the most impressive and the least productive: a good part of the contracted time goes into figuring out things you already knew.
By position. An external test probes what is visible from the internet. An internal test starts from inside your network and answers the question of what would happen if someone already got in, which is the most uncomfortable question and the one almost no one pays for.
Which one do I need, and how often?
For a mid-size company, this is what makes sense:
- Continuous vulnerability assessment, automated, with someone reviewing the results. Without this, the rest makes no sense, because a pentest on an unpatched environment only confirms the obvious.
- One penetration test per year on what is exposed to the internet, plus an extra one when something important and new is launched or the architecture changes.
- An internal test when there is budget, because it is usually the one that brings the most surprises.
If budget forces you to choose just one thing, start with continuous assessment. It is less impressive and more useful.
And it is worth understanding what neither of the two covers: both are snapshots of a moment. The day after the report is delivered, your company changes again. From then on, what remains is actively hunting and continuous monitoring.
Frequently asked questions
Does a pentest guarantee that my company is secure?
Is a pentest the same as a red team exercise?
How much does each one cost?
Can a pentest break something?
Does any standard require it?
A list is not a test
Confusing the two is not a vocabulary problem. It is a problem of expectations: you pay believing someone actually checked whether it was possible to get in, and what you receive is a list of what could fail.
Both are needed. But only one of them answers the question that really keeps you up at night, which is not how many flaws I have, but how far someone who seriously tried would get.
