In procurement conversations these three terms get used interchangeably, which leads to misunderstandings on both sides. The comparison below helps establish what you actually need.
Comparison
| Vulnerability scan | Pentest | Audit | |
|---|---|---|---|
| Performed by | a tool | a person | a person |
| Question | what is known and unpatched? | can it be exploited? | does the process work? |
| Duration | hours | days to weeks | weeks |
| Outcome | list of CVEs | vulnerabilities with a PoC | compliance and process gaps |
| False positives | many | none | not applicable |
Vulnerability scan
A tool compares software versions and configuration against a database of known vulnerabilities. It is fast, cheap and repeatable, which is exactly why it should run continuously rather than once a year.
The limitation follows from how it works: a scanner reports whatever matches a pattern. It does not establish whether the vulnerable library is used at all, whether the service is shielded by another control, or whether two minor issues can be chained into one serious problem. Hence reports listing hundreds of entries of which perhaps a dozen matter.
Treat scanning as operational hygiene, not as a security test.
Penetration test
A specialist attempts to take control of the system the way an attacker would. The defining difference from a scan is proof of exploitation. The report does not stop at noting that a service listens on port 23; it describes taking over the device through that port, with supporting evidence.
This has three practical consequences. The report contains no false positives, because every finding has been confirmed. Vulnerabilities inaccessible to scanners surface: business logic flaws, chains assembled from seemingly minor issues, and defects in your own code. The conversation with the board rests on a concrete scenario rather than a table of CVSS scores.
With devices there is an additional layer absent from web application testing: hardware, firmware, diagnostic interfaces, radio communication and the update process.
Security audit
An audit assesses not the system but the process around it. It verifies whether a risk assessment exists, who approves changes, how a reported vulnerability is handled, and whether documentation reflects reality.
An audit answers the question of compliance, a penetration test the question of security. They do not substitute for each other. An organisation can hold complete documentation and still ship a device with a default administrator password baked into its firmware.
Which one to choose
If you are building the process from scratch, this order works well:
- Scanning running continuously, as part of maintenance.
- Penetration testing before a product launch and after every significant architectural change. It produces the material for technical documentation.
- An audit once an external requirement appears: the CRA, NIS2, ISO 27001 or a security questionnaire from a corporate client.
When comparing offers, one question is particularly useful: will the report include proof of exploitation for every reported vulnerability? A quote corresponding to a few hours of work almost always describes an automated scan, whatever it is called. Pricing is covered in how much a penetration test costs.
I test applications and infrastructure, and for devices and industrial systems I run a full analysis covering hardware, firmware, communication and the update process. The scope is described under services.
If you are unsure which of the three services fits your situation, get in touch and we will settle it in a single conversation.