A vulnerability assessment searches your systems broadly and repeatedly for known vulnerabilities and ranks them by severity; a penetration test tries to exploit some of them, as an attacker would, to show how far someone could get. The first answers "how many weak points do I have, and which do I fix first?", the second "would a real attack succeed?". They are not alternatives: the first is ongoing maintenance, the second an in-depth check at intervals.
Vulnerability assessment vs penetration test: the differences at a glance
The confusion arises because both start by surveying the systems and partly use the same tools. But the purpose, the way of working and the result you receive are different.
| Aspect | Vulnerability assessment | Penetration test |
|---|---|---|
| The question it answers | Which known vulnerabilities are there, and how serious are they? | Could an attacker get in, and how far would they get? |
| Breadth and depth | Broad: all hosts, services and applications in scope | Deep: an agreed scope and agreed objectives |
| Method | Automated scans, with verification of the results | Manual work by specialists, supported by tools |
| Exploitation of vulnerabilities | No: it identifies them without exploiting them | Yes, in a controlled and agreed way |
| Impact on systems | Low, if the scans are non-invasive | Needs planning: some tests can disrupt services |
| Typical frequency | Continuous or periodic, and after every change | Periodic (often annual) and after major changes |
| Result | A list of vulnerabilities with severity, CVEs and remediation, comparable over time | A report with the successful attack scenarios, the evidence and recommendations |
| Relative cost | Lower per cycle, repeatable | Higher per engagement, tied to the days of work |
The acronym VAPT (Vulnerability Assessment and Penetration Testing) refers to using the two activities together: first you map the weaknesses, then you check which ones can really be exploited.
What a vulnerability assessment is
A vulnerability assessment is a systematic check of your systems for known vulnerabilities: out-of-date software, services exposed for no reason, weak configurations, obsolete protocols and certificates, default credentials. Each finding is usually linked to a CVE identifier, from the public catalogue of vulnerabilities, and to a severity score.
Its strength is coverage: it looks at the whole perimeter, not a sample. And it becomes really useful when it is repeated over time. New vulnerabilities are published every week, and a system that is clean today may not be in a month's time. A continuous assessment tells you what has newly appeared, what you have fixed and what is still open: it is the operational tool of patch management.
The limit is just as clear: a vulnerability assessment does not prove that a vulnerability can be exploited in your context, and it does not see weaknesses that arise from an application's logic or from a combination of several minor problems.
What a penetration test is
A penetration test is a simulated attack, authorised and limited in scope, carried out by specialists. It starts from written rules of engagement: what may be touched, at what times, with which techniques, and who to alert if something goes wrong. The tester then tries to reach an objective, for example gaining administrator privileges, reading a confidential archive or moving from a web application into the internal network.
The value lies in depth. A tester can chain three medium-severity vulnerabilities and achieve a serious result, or find an error in an application's logic that no scanner would recognise. A distinction is often made between black box tests (no initial information), grey box tests (some credentials or documentation) and white box tests (full access to configurations or code).
The limit is the flip side of the strength: a penetration test is an in-depth snapshot of a narrow scope at a precise moment. It does not tell you what will happen after the next update or the next firewall rule that gets opened.
Automated, manual and false positives
It is often said that a vulnerability assessment is automated and a penetration test is manual. That is only partly true. Scanners work by comparing versions, responses and configurations with a library of tests, and so they produce two kinds of error:
- false positives: a vulnerability that is reported but is not actually there, for example because the vendor fixed the flaw without changing the version number;
- false negatives: a vulnerability that is present but the tool does not see, because the service does not respond as expected or the test does not exist yet.
A report full of false positives wastes time and, worse, erodes trust: after the third groundless alert, people stop reading it. That is why a good vulnerability assessment includes manual verification of the results and a way to mark a false positive once, without seeing it again at every scan. Penetration tests use automated tools too; what sets them apart is the human reasoning that connects the results and tries to exploit them.
CVSS: how to read severities
CVSS (Common Vulnerability Scoring System), maintained by the FIRST organisation, gives every vulnerability a score from 0 to 10. The qualitative bands are: low (0.1 to 3.9), medium (4.0 to 6.9), high (7.0 to 8.9) and critical (9.0 to 10). The latest version is 4.0, but many public sources still give scores calculated with 3.1.
The base score describes the intrinsic severity, not the risk to your company. A critical vulnerability on an isolated server that is switched off may matter less than a medium one on an internet-facing service that handles payments. CVSS helps you put the work in order; the final decision must be made on the context, that is with a risk analysis. It also matters whether the vulnerability is already being actively exploited, as happens with zero-days.
Internal, external and web application scanning
Both vulnerability assessments and penetration tests can be carried out from different points of view, and each one simulates a different attacker.
External
It starts from the internet and sees what anyone can see: public addresses, open ports, exposed services, VPNs, email. It is the point of view of any attacker, and it is worth repeating often, because the perimeter changes more than you might think. See the external network vulnerability assessment and attack surface monitoring.
Internal
It starts from the company network and simulates someone who is already inside: a disloyal employee, a PC infected by an attachment, a compromised device. This is where out-of-date servers, forgotten printers and devices, and shared folders open to everyone come to light. It requires a probe or access to the network, as in the internal network vulnerability assessment.
Web application
Websites, portals, CRMs and online management applications are often custom-built, so they can have flaws in the code as well as in the versions. A web application scanner finds misconfigurations, exposed panels, vulnerable components and some classes of error such as SQL injection; logic flaws (a user who sees another user's data by changing a number in the address) usually require a manual test. For websites there is the web application vulnerability assessment.
Frequency and cost compared
A vulnerability assessment lends itself to a regular frequency, weekly or even more often for the external perimeter, and to a check after every relevant change. The cost of a single cycle is contained because the work is largely automated, and it grows with the number of systems checked and the amount of manual verification included.
A penetration test is usually planned once a year, before putting an important application into production or after a significant change to the infrastructure. The cost depends on the specialists' days of work, and so on the scope, the complexity and the type of test. For the same budget, a penetration test covers much less surface, but explores it in depth.
A common mistake. Buying an annual penetration test and considering it enough. Between one test and the next there are twelve months of new vulnerabilities, new services and new configurations: exactly the gap that a continuous vulnerability assessment covers.
What NIS2, ISO 27001, PCI DSS and the GDPR require
Standards rarely say "do a penetration test": they ask you to manage vulnerabilities and to check that your measures work. The way to demonstrate it, though, almost always goes through these two activities.
- NIS2: the risk management measures include vulnerability handling and disclosure and procedures to assess the effectiveness of the measures adopted. The specifications of ACN, Italy's National Cybersecurity Agency, require vulnerabilities to be identified and treated; a periodic, documented assessment is the most direct way to do it. See the guide NIS2: who must comply.
- ISO/IEC 27001:2022: Annex A control 8.8 covers the management of technical vulnerabilities; control 8.29 covers security testing in development and acceptance. The standard does not mandate penetration testing, but an auditor will expect to see how you identify and treat vulnerabilities. See ISO/IEC 27001.
- PCI DSS v4.0.1, for organisations that handle payment cards: internal vulnerability scans at least every three months and after significant changes, quarterly external scans performed by an approved scanning vendor (ASV), and internal and external penetration testing at least once a year and after significant changes.
- GDPR: Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. Periodic scans are concrete evidence. See GDPR.
- DORA, for the financial sector: it requires a digital operational resilience testing programme and, for certain entities identified by the authorities, advanced threat-led penetration testing (TLPT). See DORA.
When you need one and when the other
For most SMEs the answer is a sequence, not a choice.
- First the vulnerability assessment, continuously. If you do not know your systems and their known vulnerabilities, a penetration test will find the same things a scanner would, at a higher cost.
- Then the penetration test, targeted. Once known vulnerabilities are under control, the test is there to look for what tools cannot see: attack chains, logic errors, configurations that look correct and are not.
A penetration test is particularly appropriate before publishing a web application that handles personal data or payments, after a migration or a reorganisation of the network, when a customer or a standard explicitly requires it, and when you want to check that your detection controls really notice an attack.
How Dottor Box helps
Dottor Box carries out continuous vulnerability assessment, not penetration testing. Scans are automated and semi-automated and non-invasive, covering the internal network (with the Cyber Drill probe), the external network and web applications, with more than 130,000 network tests and more than 6,500 checks for web applications. The scans are complemented by manual checks by qualified staff, to remove false positives and false negatives; a false positive that has been declared does not come back in later scans.
Every finding has a CVSS severity, CVE and a description in Italian and English, and at every round you see what is new and what has been fixed. When you need an actual penetration test, for example on a web application, it is a consulting engagement separate from the platform: you can discuss it with our specialists through specialist consulting.